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

# 约束

在 Rome EVM 上构建时的限制——Solana 交易大小、约 140 万 CU 预算、账户上限、存储布局，以及 Rome 如何逐一规避这些限制。

在基于 Rome EVM 构建时需要注意的重要限制和边界。理解这些约束有助于你设计出可靠运行的合约。

## Solana 交易限制

| 约束          | 值              | 影响                                                   |
| ----------- | -------------- | ---------------------------------------------------- |
| 交易大小        | 4 KB（4,096 字节） | Rome 发送 Solana v1 交易；更大的 EVM 交易会暂存在 holder 账户中（透明处理） |
| 每笔交易的计算单元   | 约 140 万 CU     | 超过此值的操作将使用迭代模式，该模式有其自身的限制（见下）                        |
| 每笔交易的账户数    | 64 个地址         | v1 交易上限；EVM 交易及其 CPIs 触及的所有内容都计入，包括 Rome 自身账户        |
| holder 最大大小 | 80 KB          | 单个 EVM 交易的最大 RLP 大小                                  |

## EVM 执行限制

| 约束                    | 值                         | 说明                                                                                                                              |
| --------------------- | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| 合约存储槽                 | 每个存储账户 256 个              | 每个合约可创建多个存储账户                                                                                                                   |
| 每次迭代的操作码数             | 自适应                       | 根据每笔 Solana 交易的 CU 预算进行打包（VmIt）                                                                                                 |
| 账户锁定 TTL              | 3 秒（当会话触及超过 28 个账户时为 4 秒） | 在迭代执行期间；每一步都会续期                                                                                                                 |
| 迭代会话长度                | 160 步                     | 超过上限后，下一步会释放会话锁并结束会话，不提交任何内容                                                                                                    |
| 由 Rust Rome SDK 规划的分段 | 128                       | 迭代编排器的上限；实际调用通常远少于此                                                                                                             |
| 每个由钱包签名的计划中的交易数       | 64                        | 最多 `rome_submitSignedV1Plan` 单次调用可接受；参见 [代发调用和长调用](/zh/kai-fa-zhe-zhi-nan/call-evm-from-solana.md#relayed-calls-and-long-calls) |
| 财务钱包                  | 64                        | 费用池钱包                                                                                                                           |
| 合约大小限制                | 24 KB                     | 与以太坊相同（EIP-170，24,576 字节）                                                                                                       |

## CPI 约束

| 约束                     | 值                                                           | 说明                                                          |
| ---------------------- | ----------------------------------------------------------- | ----------------------------------------------------------- |
| CPI 深度                 | 最多 4 层                                                      | Solana 的 CPI 深度限制                                           |
| 每次 CPI 调用的账户数          | 在 64 地址的交易上限内                                               | 与交易触及的其他所有账户共享                                              |
| CPI + Transfer Hook 深度 | 使用 CPI 层级                                                   | CPI 内部的 transfer hook 可能会超过深度                               |
| 每个合约仅一个轨道              | 传统（`0xff…07/08/09`, `0x42…16`) **或** 缓存（`0xff…04/05/06/0b`) | 在同一笔交易中混合两者的变更调用会被拒绝                                        |
| 迭代模式下的传统 CPI           | 不允许                                                         | 迭代交易中的传统轨道 CPI 会失败并返回 `CpiProhibitedInIterativeTx`；允许缓存轨道效应 |

**CPI 深度是最关键的约束。** 当 Solana 调用 Rome 程序时，Rome EVM 会消耗一个 CPI 层级。如果你的 Solidity 合约随后通过 CPI 调用另一个 Solana 程序，那就是第 2 层。如果该程序再调用另一个程序，那就是第 3 层。你总共最多只有 4 层。

```
第 0 层：Solana Runtime → Rome EVM Program
第 1 层：Rome EVM Program → 你的 CPI 目标（例如 Jupiter）
第 2 层：Jupiter → 另一个程序（例如 Raydium）
第 3 层：Raydium → SPL Token（最大深度）
```

## Token-2022 Transfer Hook 约束

| 约束                   | 影响                                                   |
| -------------------- | ---------------------------------------------------- |
| 每个 mint 一个 hook      | Token-2022 mint 只有一个 transfer-hook 槽位                |
| `transfer_checked` 仅 | Hook 不会在普通 `transfer`。Rome 桥接操作使用 `transfer_checked` |
| mint/burn 不通过 hook   | 由 mint authority 控制，而非 hooks                         |

## Gas 和定价约束

| 约束        | 说明                                 |
| --------- | ---------------------------------- |
| Gas 定价来源  | Meteora DAMM 池，v1 或 v2（SPL gas 代币） |
| Gas 价格乘数  | 可按代理配置（`gas_price_mul`)            |
| 最低 gas 价格 | 由代理配置设置                            |
| gas 估算    | 提交前通过 Mollusk 模拟器在链下执行             |

## 特定网络约束

| 环境           | 链 ID   | rome-evm 程序 ID                                |
| ------------ | ------ | --------------------------------------------- |
| Hadrian（测试网） | 200010 | `RPTWwELXAY4KC9ZPHhaxp7Sq1hHtU3HNEgLbSegCcWf` |
| Rubicon（主网）  | 7531   | `RomePq9X3iAoTr813HR7uRarafFDUJty6GdiEceYpzX` |

## 预编译约束

| 预编译                    | 约束                                                                      |
| ---------------------- | ----------------------------------------------------------------------- |
| Modexp (0x05)          | **已禁用** —— 调用会回退并返回 `big_mod_exp 调用已禁用` 直到 Solana 启用 `big_mod_exp` 系统调用 |
| BN254 ecPairing (0x08) | 按程序定价约 22K CU，加上每对 12.8K；四对检查可放入一笔原子交易                                  |
| CPI 预编译（0xFF...08）     | 账户必须在 Solana 交易中预先声明                                                    |

## 交易验证

| 规则           | 影响                                                                                      |
| ------------ | --------------------------------------------------------------------------------------- |
| 签名可塑性（EIP-2） | 一笔已签名交易，其 `s` 高于曲线阶一半时会被拒绝                                                              |
| RLP 结构       | 其 RLP 列表在最后一项之后带有尾随字节的交易会被拒绝                                                            |
| 未实现的操作码      | 会中止整个交易（`IncompatibleVersionEVM(opcode)`）；不会提交任何内容，且调用合约无法吞掉该错误                         |
| Gas 计量       | Rome 没有按操作码划分的 gas 计费表：传递给 `CALL`/`CREATE` 的 gas 不会被强制执行，也没有 2300 gas 补贴——不要依赖基于补贴的重入保护 |

## 预言机约束

| 约束              | 值                                           |
| --------------- | ------------------------------------------- |
| 默认最大陈旧时间        | 60 秒                                        |
| 历史轮次数据          | 不支持—— `getRoundData(roundId)` 回退            |
| Switchboard EMA | 不支持—— `latestEMAData()` 在 SwitchboardV3 上回退 |
| 解析器偏移           | 经经验验证——在重新部署前必须重新验证                         |

## 设计建议

1. **保持 CPI 深度较浅。** 设计合约时尽量减少嵌套。如果你调用 Jupiter，而 Jupiter 再调用 Raydium，Raydium 又调用 SPL Token，那么你已达到 3 层——离上限非常近。
2. **优先使用原子模式。** 设计操作使其适配约 140 万 CU。迭代模式会增加延迟（3-4 秒锁定）、每个会话最多 160 次迭代，并且当钱包自行签署各分段时，Solana 通道上的每个分段都需要钱包提示。发起传统轨道 CPI 的调用根本无法以迭代方式运行。
3. **预先声明账户。** CPI 触及的所有 Solana 账户都必须在交易创建时已知（代理的模拟会发现它们）。CPI 调用内无法动态发现账户，且总数必须符合 64 地址上限。
4. **每个合约只选一种预编译轨道。** 调用自定义 Solana 程序（`invoke_signed`）属于传统轨道且仅支持原子模式；参见 [集成 Solana 程序](/zh/kai-fa-zhe-zhi-nan/integrate-solana-program.md).
5. **使用 `transfer_checked`.** 如果你在构建任何涉及 Token-2022 代币的内容，请始终使用 `transfer_checked` 以确保 hook 触发。
6. **测试 CU 消耗。** 从交易收据中测量真实的 Solana 计算单元（`computeUnitsConsumed`）—— EVM `gasUsed` 不能真实代表 Solana CU。对热点路径使用 Yul 进行优化。

## 接下来

* [计算预算](/zh/he-xin-gai-nian/compute-budget.md) —— 每个操作的详细 CU 成本
* [代币互操作](/zh/he-xin-gai-nian/token-interop.md) —— ERC-20 ↔ SPL 桥接模型
* [预编译参考](/zh/can-kao/precompiles.md) —— 每个 selector 及其分发类别


---

# 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/he-xin-gai-nian/constraints.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.