> 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/zh/he-xin-gai-nian/execution-model.md).

# 执行模型

Rome EVM 在 Solana 链上程序内执行 Solidity 字节码。本页说明 EVM 交易是如何处理的。

## 交易生命周期

```
1. 用户签名 EVM 交易（MetaMask / ethers.js）
                    ↓
2. Rome Proxy 通过 eth_sendRawTransaction 接收
                    ↓
3. Proxy 在链下模拟交易（Mollusk SVM 模拟器）
   → 估算 gas，检查原子性，识别所需账户
                    ↓
4. Proxy 将 EVM 交易封装为 Solana 指令
   → 如果交易可容纳于一笔 Solana 交易中 → 原子式（VmAt）
   → 如果交易超过 CU 预算 → 迭代式（VmIt）
                    ↓
5. Solana 验证者执行该指令
   → Rome EVM 程序解释 EVM 字节码
   → 对其他 Solana 程序的 CPI 调用（如有）
                    ↓
6. 状态变更提交到 Solana 账户
                    ↓
7. Hercules 索引事件 → 生成 EVM 区块
```

## 原子式执行（VmAt）

默认模式。整个 EVM 交易在单个 Solana 交易内执行。

**状态机：** `Lock → Init → Execute → Commit → GasTransfer → Exit`

**特性：**

* 要么全部成功，要么全部回滚——如果任何一步失败，整个交易都会回退
* 每笔 Solana 交易约可用 140 万计算单元
* 适用于转账、简单合约调用、交换以及大多数 DeFi 操作
* 亚秒级最终确认（Solana 区块时间）

**何时使用：** 当模拟器判断交易可在单笔 Solana 交易的计算预算内完成时，会自动选择该模式。

## 迭代式执行（VmIt）

适用于超出单笔交易预算的计算密集型操作。EVM 执行会拆分到多笔 Solana 交易中。

**工作方式：**

1. 每一步（即一笔 Solana 交易）都会执行 **尽可能多的 EVM 操作码** ——这是自适应步长，而非固定计数
2. 每一步之后，VM 状态都会序列化（Borsh 格式）到一个 `StateHolder` 账户中
3. 下一步会反序列化状态并继续执行
4. 涉及的账户在多步骤执行期间会被 TTL 锁定 **3-4 秒** 期间

**状态机：** `FromStateHolder → Lock → Init → Execute → Serialize → NextIteration → ... → Completed`

**账户锁定：**

* **RoLock（共享只读）** —— 多个迭代式交易可以同时持有
* **RwLock（独占写入）** —— 同一时间只能有一个交易修改某个账户
* **TTL：** 3 秒（标准），4 秒（使用地址查找表时）

**何时使用：** BN254 配对验证、大型合约部署、深层调用栈，以及任何超过约 140 万 CU 的操作。

## 模拟

在将交易提交到 Solana 之前，Proxy 会使用 **Mollusk SVM 模拟器**在链下模拟它。这样可以：

1. 估算 gas 消耗
2. 判断需要原子式还是迭代式模式
3. 识别交易将接触到的所有 Solana 账户
4. 验证交易不会在链上失败

该模拟器执行与链上程序相同的 EVM 逻辑—— `entrypoint!` 宏确保程序与模拟器代码库中的分发表完全一致。

**Mollusk SVM** 在模拟过程中还可以执行任意 Solana BPF 程序，这意味着 `eth_call` 和 `eth_estimateGas` 能够正确处理对 SPL Token、Jupiter、Kamino 等的 CPI 调用。

## 账户映射

每个以太坊地址都会映射到一个 Solana PDA：

```
以太坊地址（H160，20 字节）
    ↓
PDA = findProgramAddress(
    [chain_id, "ACCOUN_SEED", H160, bump],
    ROME_EVM_PROGRAM_ID
)
    ↓
Solana 账户（Pubkey，32 字节）
```

**链上存储的账户类型：**

| 类型          | 种子                                           | 用途                 |
| ----------- | -------------------------------------------- | ------------------ |
| 余额          | `[chain, "ACCOUN_SEED", H160, bump]`         | Nonce、余额、合约代码      |
| 存储          | `[chain, "STORAGE", H160, slot_index, bump]` | 合约存储（每个账户 256 个槽位） |
| TxHolder    | `[signer, "TX_HOLDER_SEED", index, bump]`    | 已暂存的交易数据（最大 80 KB） |
| StateHolder | `[signer, "STATE_HOLDER_SEED", index, bump]` | 迭代之间序列化的 VM 状态     |

## Holder 账户

Solana 交易限制为 1,232 字节。EVM 交易——尤其是合约部署——可能大得多。

**拆分机制：**

1. SDK 会将 RLP 编码的交易拆分为多个分片
2. 每个分片都会写入到一个 `TxHolder` 账户，通过 `TransmitTx` 指令
3. 当所有分片都暂存完成后， `DoTxHolder` 指令会组装并执行完整交易
4. 最大 holder 大小： **80 KB** 每个 TxHolder

这对开发者来说完全透明——Rome SDK 会自动处理拆分与重组。

## 支持的交易类型

| 类型          | EIP      | 描述            |
| ----------- | -------- | ------------- |
| Legacy      | —        | 传统以太坊交易       |
| Access List | EIP-2930 | 优化的状态访问模式     |
| 动态费用        | EIP-1559 | 基础费用 + 优先费用   |
| Deposit     | 类型 0x7E  | 存款交易，例如桥接入账结算 |

## 日志化状态

Rome EVM 在执行期间使用日志化状态模型来管理状态变更：

* 所有变更（nonce、余额、存储、代码）都会记录在一个 `日志`
* 嵌套的 CALL/CREATE 操作会推入快照帧
* 发生回滚时：日志条目回退到快照
* 成功时：变更会提交到 Solana 账户
* 非 EVM CPI 指令会立即执行（Solana 自身的原子性保证了正确性）

## 下一步

* [计算预算](/zh/he-xin-gai-nian/compute-budget.md) — CU 成本与优化策略
* [约束](/zh/he-xin-gai-nian/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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.rome.builders/zh/he-xin-gai-nian/execution-model.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.