> 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/key-concepts.md).

# 关键概念

面向开发者的 Solana 与 Rome EVM 基础术语——program、account、PDA、CPI、SPL 代币，以及原子执行与迭代执行。

在 Rome Protocol 上构建所需的基础术语和概念。

## Solana 概念

**程序** — Solana 中相当于智能合约的概念。程序是部署在链上的无状态可执行体。Rome EVM 本身就是一个 Solana 程序。

**账户** — Solana 上的所有状态都存放在账户中。每个账户都有所有者（程序）、余额（lamports）和数据。不同于以太坊，代码和状态存储在不同的账户中。

**PDA（程序派生地址）** — 一个由种子和程序 ID 派生出的确定性地址。PDA 允许程序在没有私钥的情况下“拥有”账户。Rome 使用 PDA 将以太坊地址映射到 Solana 账户。

**CPI（跨程序调用）** — 一个 Solana 程序在同一笔交易中调用另一个程序。这就是 Rome EVM 合约与 Jupiter、Kamino、SPL Token 及其他 Solana 程序交互的方式。

**SPL Token** — Solana 的标准代币程序。相当于以太坊上的 ERC-20。Solana 上所有同质化代币（USDC、SOL 等）都是 SPL 代币。

**Token-2022** — 下一代 SPL 代币程序，支持 Transfer Hooks、Confidential Transfers 和 Permanent Delegates 等扩展。

**转账钩子** — 一种 Token-2022 扩展，在每次 `transfer_checked` 调用时触发一个程序。

**ATA（关联代币账户）** — 针对给定钱包 + 铸币对的确定性代币账户。每个用户对其持有的每种代币都有一个 ATA。

**Lamports** — SOL 的最小单位。1 SOL = 1,000,000,000 lamports（10^9）。

**计算单元（CU）** — 相当于以太坊 gas。每笔交易都有一个计算预算（默认约 200K CU，最大约 1.4M CU）。操作会消耗 CU。

## Rome 概念

**Rome EVM 程序** — 包含 EVM 字节码解释器的 Solana 程序。按环境部署在特定的程序 ID 上。

**链 ID** — Rome 上的每个应用都有自己的 EVM 链 ID。这创建了彼此隔离的 EVM 环境，但共享同一底层 Solana 状态。

**原子执行（VmAt）** — 在单个 Solana 交易内完全执行的 EVM 交易。用于大多数操作。

**迭代执行（VmIt）** — 跨多个 Solana 交易拆分执行的 EVM 交易；每一步打包尽可能多、且能放入单个 Solana 交易计算预算的 opcode（自适应，而非固定数量）。用于计算密集型操作，如 BN254 配对。

**持有者账户** — 一个链上缓冲区，用于存储超出 Solana（v1）4 KB 交易大小限制的大型 EVM 交易（最多可达 80 KB）。由 SDK 透明管理。

**StateHolder** — 一个链上账户，用于在迭代执行步骤之间存储序列化的虚拟机状态。

**Rome 代理** — JSON-RPC 服务器（端口 9090），将以太坊 API 调用转换为 Solana 交易。你的 MetaMask 和 Hardhat 连接到这里。

**Hercules** — 监控 Solana 上 Rome EVM 事件并生成兼容以太坊的区块数据的区块索引器。

**支付者** — 一个 Solana 密钥对，代表 EVM 用户签名并支付 Solana 交易费用。由 Proxy 通过支付者池进行管理。

## 代币概念

**SPL\_ERC20 / SPL\_ERC20\_cached** — 表示 Rome EVM 中某个 SPL 代币的 ERC-20 包装合约。对于钱包，包装合约会直接从底层 SPL 代币账户读取余额。由合约持有的代币存放在包装合约自身的托管代币账户中，并记录在包装合约的存储中（见 [集成 Solana 程序](/zh/kai-fa-zhe-zhi-nan/integrate-solana-program.md)）。工厂目前部署缓存变体。

**ERC20SPLFactory** — 一个为任意 SPL 代币部署包装合约的工厂合约。

**注册表** — 标准包装合约、Gas 代币和桥接配置在链下由 [rome-protocol/registry](https://github.com/rome-protocol/rome-registry)进行整理；不存在链上的代币注册表合约。这使每种资产都映射到单一的标准 SPL 铸币。

## 预编译

**标准以太坊预编译合约** — ecrecover (0x01)、SHA-256 (0x02)、RIPEMD-160 (0x03)、identity (0x04)、modexp (0x05)、BN254 ecAdd/ecMul/ecPairing (0x06-0x08)、Blake2f (0x09)。

**系统预编译合约** (`0xFF...07`）— 来自 Solidity 的 PDA 派生和 base58 转换。

**CpiProgram 预编译合约** (`0xFF...08`）— 跨程序调用（`invoke` / `invoke_signed`）以及跨状态读取快捷方式。

**HelperProgram 预编译合约** (`0xFF...09`）— ATA/PDA 创建、SPL 转账，以及 gas↔lamports 转换；这是用户通过 PDA 签名执行 SPL 操作的主要接口。

**Withdraw 预编译合约** (`0x42...16`）— 将 SOL 或 SPL 代币从 EVM 提回 Solana。

一个缓存轨道系列（`0xff…04/05/06/0b`）为更高 CU 效率的读取提供对应实现；合约会始终使用同一轨道。

## 交易类型

**RheaTx** — 单个 rollup 上的一笔 EVM 交易。最常见的类型。

**RemusTx** — 跨不同 rollup 的多笔 EVM 交易，原子执行。若任一交易失败，全部回滚。

**RomulusTx** — 在一次原子操作中，将 EVM 交易与原生 Solana 指令组合执行。最强大的一种类型——可在单笔交易中混合 Solidity 和 Solana。

## 接下来

* [执行模型](/zh/he-xin-gai-nian/execution-model.md) — 深入了解 EVM 交易如何在 Solana 上执行
* [代币互操作](/zh/he-xin-gai-nian/token-interop.md) — ERC-20 和 SPL 代币如何交互
* [约束](/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 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/key-concepts.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.