> 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/kuai-su-kai-shi/architecture.md).
# 架构
Rome 的各个组件如何协同工作——在 Solana 程序内部执行 EVM。
Rome 在 Solana 链上程序内部嵌入了一个 EVM 字节码解释器。在 EVM 密钥通道中，用户通过标准的 Ethereum JSON-RPC 向 Rome Proxy 发送已签名的 EVM 交易。代理会将其提交到 Solana 上的 Rome EVM 程序。一个 EVM 交易可能需要多笔 Solana 交易，才能把分块写入 holder 账户或执行迭代式运行。在 v1 Solana 密钥通道中，代理会编排该交易。Solana 钱包对其签名，并直接发送到 Solana RPC。这里没有需要保持同步的独立执行层——EVM 状态 *是* Solana 状态。
## 系统概览
## 组件
### Rome EVM 程序（链上）
Rome 的核心——一个包含完整 EVM 字节码解释器（SputnikVM 的一个分支）的 Solana BPF 程序。它：
* 接收已签名的 EVM 交易以及未签名的 EIP-1559 交易体，作为 Solana 指令。Solana 密钥可通过 Solana 费用支付者的签名或 Ed25519 验证器指令，对未签名交易体进行授权
* 在 Solana 运行时中执行 Solidity 字节码
* 将每个以太坊地址（H160）映射到按链划分的余额 PDA，其中包含其 nonce、原生余额和代码。独立的存储 PDA 与余额 PDA 关联。每个地址还拥有一个用于授权 Solana 调用的程序派生地址，称为其 **外部权限 PDA**。该 PDA 在程序的每条链上共享。它持有该地址的 SPL 代币账户，并为其跨程序调用（CPI）签名
* 公开了用于调用 Solana（CPI、System、Helper、Withdraw）以及以太坊预编译的预编译合约。缓存族新增 SystemCached（`0xff…04`）、SplCached（`0xff…05`）、ASplCached（`0xff…06`）和 WithdrawCached（`0xff…0b`）。工厂在这条缓存路径上部署包装器
* 将 EVM 状态（余额、nonce、代码、存储）存储为 Solana 账户数据
* 一个 Rome EVM 程序可承载多个 chain ID。chain ID 是余额和存储 PDA 地址的一部分，而不是外部权限 PDA 的一部分
### Rome Proxy（JSON-RPC 服务器）
Rome Proxy 是标准的以太坊 JSON-RPC 服务器。用户连接到 `https://hadrian.testnet.romeprotocol.xyz/` Hadrian（测试网）使用 `https://rubicon.mainnet.romeprotocol.xyz/` Rubicon（主网）使用
* `eth_sendRawTransaction` → 提交一个或多个 Solana v1 交易：原子 `DoTx`，holder 分块（`TransmitTx`）加上 `DoTxHolder`，或迭代式分支。池化 payer 签名并支付 SOL。池化费用接收方收取用户的 gas
* `eth_call` → 在模拟器中原生运行 EVM 解释器，读取通过 RPC 访问的实时 Solana 账户。Mollusk 会运行通过 CPI 访问到的 Solana 程序。它还会在代理测量计算单元时运行 Rome EVM 程序
* `eth_estimateGas` → 用于 gas 估算的模拟。一个 gas 单位等于一个 lamport 的 Solana 成本。估算值不会低于 21,000
* `eth_getBalance`, `eth_getCode`, `eth_getTransactionCount`, `eth_getStorageAt` → 通过模拟器读取实时 Solana 账户。 `eth_getBlockByNumber`，收据和日志来自 Hercules
它还公开 Rome 扩展： `rome_emulateTx`, `rome_emulateRegRollup`, `rome_mintId`, `rome_buildInfo` 和 `rome_getResources`。Solana 钱包方法包括 `rome_emulateCallAccounts`, `rome_composeUnsignedAtomicV1`, `rome_composeUnsignedIterativeV1`, `rome_submitSignedV1Plan`, `rome_relayUnsignedV1`, `rome_composeExternalDepositV1` 和 `rome_sendUnsignedTransaction`。代理还公开 `rome_solanaTxForEvmTx`.
### Hercules（索引器）
Hercules 监视 Solana 上的 Rome EVM 程序，并在 PostgreSQL 中重建与以太坊兼容的区块。这些区块包含交易、收据、日志和状态变更。在公有链上，它以按 slot 对齐模式运行，因此区块高度会映射到一个 Solana slot，并且同一个 slot 在任何索引器上都会得到相同的区块。代理会将这些区块提供给钱包和浏览器。
Hercules 会索引已确认的区块。它会在 finalized 时重新检查每个区块，如果 blockhash 已更改则重新加载它。该 [通过浏览器](/zh/rome-shang-de-ying-yong/via.md) 读取 Hercules 数据。
### 预编译
Rome 实现了 ecrecover、SHA-256、RIPEMD-160、identity、BN254 曲线运算和 blake2f，并采用以太坊语义，但 BN254 和 blake2f 的失败数据除外。BN254 或 blake2f 调用失败时，Rome 返回其 `Error(string)` revert 数据，而不是空缓冲区。Modexp（`0x05`）被禁用，并回退为 `"big_mod_exp 调用已禁用"`。blake2f 拒绝超过 1,000,000 轮的调用，而以太坊允许此类调用。
非 EVM 预编译可访问 Solana： **CpiProgram** (`0xFF…08`，任意 CPI）， **系统** (`0xFF…07`，PDA 派生和 base58 辅助函数）， **HelperProgram** (`0xFF…09`，ATA/PDA 创建、SPL 转账、gas↔lamports），以及 **提取** (`0x42…16`）。缓存族为 **SystemCached** (`0xff…04`), **SplCached** (`0xff…05`), **ASplCached** (`0xff…06`）以及 **WithdrawCached** (`0xff…0b`）。旧版 CPI 会立即运行，且仅适用于原子交易。缓存型 CPI 在执行期间记录，并在提交时发送。它们会随 EVM 一起回滚。它们可以在迭代式交易中运行。请参阅 [合约地址](/zh/can-kao/contract-addresses.md) 参考文档获取完整表格。
## 执行模式
Rome 以两种方式执行 EVM 交易：
### 原子式（VmAt）
单笔 Solana 交易。整个 EVM 交易在单笔 Solana 交易的计算预算内执行（约 140 万计算单元）。用于大多数操作——转账、普通合约调用、交换。
### 迭代式（VmIt）
用于超出单笔交易预算的工作。执行会拆分为多个 Solana 交易：
1. 每一步（一个 Solana 交易）都会执行尽可能多、且能装入其计算预算的 EVM 操作码——步长是自适应的，而非固定的
2. VM 状态会在步骤之间以 Borsh 序列化到一个 `StateHolder` 账户中
3. 执行期间，账户会被 TTL 锁定几秒
当计算单元、堆或指令数量无法装入一个 Solana 交易时，代理会回退到迭代式执行。单个会话最多 160 次迭代。因为旧版链路的 CPI 不能拆分到多个分支中，所以在迭代式交易中会拒绝旧版链路 CPI。缓存型链路 CPI 允许使用。
## 账户映射
每个以太坊地址都会根据 chain ID 和 Rome EVM 程序下的地址，确定性地映射到一个 Solana 余额 PDA。其原生 gas 余额是该 PDA 中的一个字段，同时还包括 nonce 和合约代码。存储槽位位于独立的存储 PDA 中。SPL 余额位于由独立外部权限 PDA 拥有的代币账户中。该权限在同一程序上的每条链之间共享。
## 两种接入方式
* **EVM 密钥通道：** 钱包向 Rome Proxy 发送一笔由 secp256k1 签名的 EVM 交易。代理会提交这些 Solana 交易。
* **Solana 密钥通道：** 钱包使用其 Solana 密钥授权一个未签名的 EIP-1559 交易体。对于直接的 v1 路由，代理会编排 Solana 交易。钱包签名后直接提交到 Solana RPC。中继路由则改为通过代理提交。较早的旧版路由要求钱包构建、签名并支付一个 `DoTxUnsigned` Solana 交易，程序从 Solana 签名者派生发送方。
一个 Solana 公钥会映射到合成地址 `keccak256(pubkey)[12:]`，即哈希的最后 20 个字节。参见 [Solana 与 EVM 如何在 Rome 上交汇](/zh/he-xin-gai-nian/how-solana-and-evm-meet.md).
## 谁会对发往 Solana 的调用进行签名
Rome EVM 程序会使用预编译合约的直接调用者的外部权限 PDA 对 CPI 进行签名。合约以其自身名义签名。要花费用户的 SPL 代币，合约需要该用户授予的 SPL 委托。用户通过 `HelperProgram.approve_spl(spender, amount, mint)`授予。用户的 EVM 或合成地址对预编译的直接调用会使用用户的外部权限 PDA。
## Holder 账户
Solana（v1）交易上限为 4 KB，但 EVM 交易（尤其是合约部署）可能大得多。Rome 会将大型交易拆分为 3,600 字节的分块，并按顺序写入 **holder 账户** （最多 80 KB）。随后它会组装每笔交易并在链上执行。Rome SDK 会透明地管理这一过程。每个分块的签名费用都会计入发送方的 gas。
## Gas 与定价
每条链都有自己的 gas 代币：SOL 或 SPL 代币。价格来源可以是 Hermes API、Meteora DAMM v1 池、Meteora DAMM v2 池或固定价格。它提供 gas 代币与 SOL 之间的换算，用于底层 Solana 交易费用。
* 一个 gas 单位等于一个 lamport 的 Solana 成本
* `eth_gasPrice` 是 gas 代币每 lamport 的 wei
* 发送方从其原生 gas 余额中向费用接收方支付费用。代理 payer 支付 SOL
* 在没有费用接收方时，如 Solana 钱包原子通道，不收取任何 EVM gas。钱包直接支付 SOL
* 原生余额保留 18 位小数。它由每条链程序钱包中持有的 gas 代币 SPL 支持
## 最终确定性
Rome 使用 Solana 的最终确定性。SDK 会等待 `已确认`。Hercules 会在 `已最终确定的` 重新检查每个已索引区块，如果 blockhash 已更改则重新加载它。
## 下一步
* [网络](/zh/wang-luo/networks.md) ——连接 Hadrian（测试网）和 Rubicon（主网）
* [快速开始](/zh/kuai-su-kai-shi/quickstart.md) — 部署你的第一个合约
* [执行模型](/zh/he-xin-gai-nian/execution-model.md) ——深入了解原子执行与迭代执行
* [代币互操作](/zh/he-xin-gai-nian/token-interop.md)
* [约束](/zh/he-xin-gai-nian/constraints.md)
* [从 EVM 调用 Solana](/zh/kai-fa-zhe-zhi-nan/call-solana-from-evm.md)
* [从 Solana 调用 EVM](/zh/kai-fa-zhe-zhi-nan/call-evm-from-solana.md)
* [预编译参考](/zh/can-kao/precompiles.md)
* [Solana 与 EVM 如何在 Rome 上交汇](/zh/he-xin-gai-nian/how-solana-and-evm-meet.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/zh/kuai-su-kai-shi/architecture.md?ask=&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.