> For the complete documentation index, see [llms.txt](https://docs.rome.builders/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.rome.builders/ko/core-concepts/execution-model.md).

# 실행 모델

Rome EVM이 Solana에서 Ethereum 트랜잭션을 처리하는 방식 — 프록시 에뮬레이션, 원자적(VmAt) 모드와 반복적(VmIt) 모드, 그리고 전체 트랜잭션 수명주기.

Rome EVM은 솔라나 온체인 프로그램 안에서 Solidity 바이트코드를 실행합니다. 이 페이지에서는 EVM 트랜잭션이 어떻게 처리되는지 설명합니다.

## 트랜잭션 생명주기

```
1. 사용자가 EVM 트랜잭션에 서명함 (MetaMask / ethers.js)
                    ↓
2. Rome Proxy가 eth_sendRawTransaction을 통해 수신함
                    ↓
3. Proxy가 온체인 외부에서 트랜잭션을 에뮬레이션함 (Mollusk SVM 에뮬레이터)
   → 가스 추정, 원자성 확인, 필요한 계정 식별
                    ↓
4. Proxy가 EVM tx를 솔라나 instruction(s)으로 감쌈
   → tx가 하나의 솔라나 tx에 들어가면 → 원자적(VmAt)
   → tx가 CU 예산을 초과하면 → 반복적(VmIt)
                    ↓
5. 솔라나 검증자가 instruction(s)을 실행함
   → Rome EVM 프로그램이 EVM 바이트코드를 해석함
   → 다른 솔라나 프로그램에 대한 CPI 호출(있는 경우)
                    ↓
6. 상태 변경이 솔라나 계정에 커밋됨
                    ↓
7. Hercules가 이벤트를 인덱싱함 → EVM 블록을 생성함
```

## 원자적 실행(VmAt)

기본 모드입니다. 전체 EVM 트랜잭션이 하나의 솔라나 트랜잭션 안에서 실행됩니다.

**상태 머신:** `Lock → Init → Execute → Commit → GasTransfer → Exit`

**특성:**

* 전부 아니면 전무 실행 — 어떤 단계라도 실패하면 전체 트랜잭션이 되돌려집니다
* 솔라나 트랜잭션당 약 140만 컴퓨트 유닛 사용 가능
* 전송, 단순 컨트랙트 호출, 스왑, 대부분의 DeFi 작업에 적합
* 1초 미만의 최종성(솔라나 블록 시간)

**사용 시점:** 에뮬레이터가 트랜잭션이 하나의 솔라나 트랜잭션의 컴퓨트 예산 안에 들어간다고 판단하면 자동으로 선택됩니다.

## 반복적 실행(VmIt)

하나의 트랜잭션 예산을 초과하는 계산 집약적 작업용입니다. EVM 실행은 여러 솔라나 트랜잭션으로 나뉩니다.

**동작 방식:**

1. 각 단계(하나의 솔라나 트랜잭션)가 실행되며 **자신의 컴퓨트 예산에 들어가는 만큼의 EVM opcode를 실행합니다** — 고정된 개수가 아니라 적응형 단계 크기입니다
2. 각 단계 후 VM 상태가 (Borsh 형식으로) `StateHolder` 계정에 직렬화됩니다
3. 다음 단계가 상태를 역직렬화하고 실행을 계속합니다
4. 관련 계정들은 멀티스텝 실행 동안 **3\~4초** 동안 TTL로 잠기며, 세션은 **160단계**에서 상한이 설정되고; 그 이후에는 다음 단계가 세션의 잠금을 해제하고 아무것도 커밋하지 않은 채 종료합니다

**상태 머신:** `FromStateHolder → Lock → Init → Execute → Serialize → NextIteration → ... → Completed`

**계정 잠금:**

* 하나의 **배타적 잠금** 이 관리되는 계정(잔액 및 저장소 계정)마다 적용됩니다 — 한 번에 하나의 반복 세션만 계정을 보유할 수 있으며; 잠긴 계정에 쓰려는 원자적 트랜잭션은 `AccountLocked` 로 거부되고, 잠금이 만료될 때까지 클라이언트가 재전송합니다
* **TTL:** 3초이며, 매 단계마다 갱신됩니다(세션이 28개 이상의 계정을 건드리면 4초)
* **레거시 경로 CPI는 거부됩니다** 반복적 트랜잭션 내부에서는(`CpiProhibitedInIterativeTx`); 캐시된 경로의 효과는 스테이징되어 마지막에 커밋됩니다

**사용 시점:** 대규모 컨트랙트 배포, 깊은 호출 스택, 약 140만 CU를 초과하는 모든 작업. BN254 페어링 검증 하나만으로는 필요하지 않으며; [컴퓨트 예산](/ko/core-concepts/compute-budget.md).

## 에뮬레이션

트랜잭션을 솔라나에 제출하기 전에 Proxy는 **Mollusk SVM 에뮬레이터**를 사용해 오프체인에서 에뮬레이션합니다. 이는:

1. 가스 소비를 추정함
2. 원자적 모드 또는 반복적 모드가 필요한지 판단함
3. 트랜잭션이 접근할 모든 솔라나 계정을 식별함
4. 트랜잭션이 온체인에서 실패하지 않을지 검증함

에뮬레이터는 온체인 프로그램과 동일한 EVM 로직을 실행합니다 — `entrypoint!` 매크로는 프로그램과 에뮬레이터 코드베이스 양쪽에서 동일한 디스패치 테이블을 보장합니다.

**Mollusk SVM** 는 에뮬레이션 중 임의의 솔라나 BPF 프로그램도 실행할 수 있으므로 `eth_call` 및 `eth_estimateGas` SPL Token, Jupiter, Kamino 등으로의 CPI 호출을 올바르게 처리할 수 있습니다.

## 계정 매핑

모든 이더리움 주소는 하나의 솔라나 PDA로 매핑됩니다:

```
이더리움 주소(H160, 20바이트)
    ↓
PDA = findProgramAddress(
    [chain_id, "ACCOUN_SEED", H160, bump],
    ROME_EVM_PROGRAM_ID
)
    ↓
솔라나 계정(Pubkey, 32바이트)
```

**온체인에 저장되는 계정 유형:**

| 유형          | 시드                                           | 목적                      |
| ----------- | -------------------------------------------- | ----------------------- |
| 잔액          | `[chain, "ACCOUN_SEED", H160, bump]`         | Nonce, 잔액, 컨트랙트 코드      |
| 저장소         | `[chain, "STORAGE", H160, slot_index, bump]` | 컨트랙트 저장소(계정당 256 슬롯)    |
| TxHolder    | `[signer, "TX_HOLDER_SEED", index, bump]`    | 스테이징된 트랜잭션 데이터(최대 80KB) |
| StateHolder | `[signer, "STATE_HOLDER_SEED", index, bump]` | 반복 사이의 직렬화된 VM 상태       |

## Holder 계정

Rome은 솔라나 **v1 트랜잭션을 보냅니다**, 이는 4KB(4,096바이트)와 64개 주소로 제한됩니다. EVM 트랜잭션 — 특히 컨트랙트 배포는 — 훨씬 더 클 수 있습니다.

**분할 메커니즘:**

1. SDK가 RLP로 인코딩된 트랜잭션을 여러 청크로 분할합니다
2. 각 청크는 `TxHolder` 계정에 `TransmitTx` instruction을 통해 기록됩니다
3. 모든 청크가 스테이징되면 `DoTxHolder` instruction이 전체 트랜잭션을 조립하고 실행합니다
4. 최대 holder 크기: **80 KB** TxHolder당

이는 개발자에게 완전히 투명합니다 — Rome SDK가 분할과 재조립을 자동으로 처리합니다.

## 지원되는 트랜잭션 유형

| 유형               | EIP      | 설명                                                                                                                                          |
| ---------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| 레거시              | —        | 기존 이더리움 트랜잭션                                                                                                                                |
| 액세스 리스트          | EIP-2930 | 최적화된 상태 접근 패턴                                                                                                                               |
| 동적 수수료           | EIP-1559 | 기본 수수료 + 우선 수수료                                                                                                                             |
| 서명되지 않은 EIP-1559 | —        | 하나의 `0x02`형식의 본문으로 secp256k1 서명이 없고, 대신 솔라나 지갑의 Ed25519 서명으로 승인됩니다(솔라나 레인; [Solana에서 EVM 호출](/ko/developer-guides/call-evm-from-solana.md)) |
| 예치               | 유형 0x7E  | 예치 트랜잭션, 예: 브리지 인바운드 정산                                                                                                                     |

## 저널링된 상태

Rome EVM은 실행 중 상태 변경을 관리하기 위해 저널링된 상태 모델을 사용합니다:

* 모든 변경(Nonce, 잔액, 저장소, 코드)은 `저널`
* 에 추적됩니다
* 되돌리기 시: 저널 항목이 스냅샷으로 롤백됩니다
* 성공 시: 변경사항이 솔라나 계정에 커밋됩니다
* 비-EVM CPI instruction은 즉시 실행됩니다(솔라나 자체의 원자성 보장이 정확성을 보장함)

## 다음 단계

* [컴퓨트 예산](/ko/core-concepts/compute-budget.md) — CU 비용과 최적화 전략
* [제약 사항](/ko/core-concepts/constraints.md) — 중요한 제한과 경계


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.rome.builders/ko/core-concepts/execution-model.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.