> 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/rome-shang-de-ying-yong/bloom/lanes.md).

# 双通道

一次代币部署，两种钱包世界。两条路径都执行 **相同的合约** 并采用 **相同的合规门控** ——它们唯一的区别在于由谁签名，以及交易如何到达链上。

## EVM 路径

标准的以太坊工具链，保持不变：钱包签署一笔 EVM 交易，链的 JSON-RPC 端点接受它，代币合约执行允许名单限制。无需集成任何 Bloom 特定内容——受门控转账的实测成本约为 3.1M gas（Rome gas 以 USDC 计价；为便于对比，普通原生转账约为 1.48M gas）。

## Solana 路径

Solana 钱包驱动相同的 EVM 合约 **以原生方式——任何地方都不存在 EVM 密钥**:

1. **身份。** 用户在 EVM 侧的地址是 *合成*：按确定性方式派生为 `keccak256(solana_pubkey)[12..32]`。Rome EVM 程序会在链上根据交易的实际签名者派生它——它无法被伪造，而且不存在对应的 secp256k1 私钥，因此 **只有 Solana 签名才能驱动这个地址**.
2. **发现。** 客户端向链的 RPC（`rome_emulateCallAccounts`）询问 EVM 调用将触及哪些 Solana 账户；仿真还会决定哪些账户可写（调用的 `value` 必须包含——接收方余额账户是否可写取决于它）。
3. **提交。** 客户端构建一个 `DoTxUnsigned` 指令——一个 *未签名的* 由 Solana 签名授权的 EIP-1559 载荷——再加上计算预算指令（250KB 堆，1.35M CU），以及费用池账户发现所省略的内容。钱包只需签署一笔 Solana 交易；完成。

   **在本次部署（2026-07-30）上测得的大小：** 一次商店购买会展开为 **22 个账户** 并序列化为 **1,061 字节** 相对于 1232 字节的旧版上限——还剩 171 字节的余量，大约还能容纳 5 个账户。因此它今天并不需要查找表。若状态涉及更多内容——例如尚未创建的关联代币账户、首次持有者——仍可能超出该上限，而一旦超过 1232 字节，客户端就会回退为通过其为此目的创建的地址查找表来发送 v0 交易。

   **这种回退对钱包来说代价很高：** 每个 ALT 扩展分块以及 v0 重新提交，都是单独的一次 `signTransaction`，因此一次购买会变成三到四次提示。Hadrian 已经有一个持久化的 dApp 表保存着这些合约的账户——改为引用该表才是解决方案，而路径客户端目前还做不到。
4. **确认。** 交易在 Solana 上确认；EVM 视图稍后片刻才跟上（工具会在发送下一次调用前轮询 nonce）。

### 仅限原子执行——该路径的硬边界

`DoTxUnsigned` 是 **一笔在一笔 Solana 交易中执行的 EVM 交易** 由 Rome 的原子 VM 执行。迭代 VM——即将一次 EVM 执行拆分到多笔 Solana 交易中分阶段完成的那种——目前还无法通过这条路径访问，因此 **无法以原子方式容纳的调用根本不能走这条路径。** 没有可用的回退方案，也不应新增；对于无法容纳的调用，解决办法就是把调用做得更小。

有两件事常被误认为是它，但两者都不是：

* **v0 + 查找表回退** 是一个更大的 *封装*，而不是不同的执行方式：它仍是同一条指令，只是装在一种可容纳更多账户密钥的交易格式中。今天测得的商店购买并不需要它（1,061/1232 字节），而即便需要，该调用也仍然是原子的。
* **多步骤旅程并不等同于多段执行。** Bloom 的 `Run` 将其步骤称为 *legs* ——先批准，再购买——而且每一步都是 **一笔完整交易，分别签名，本身即原子**。Rome 也把一次拆分执行中的各个片段称为 legs。这个应用只有前者，绝不能要求后者。术语会冲突；机制不会。

下表中的每一条流程都是一笔原子交易，其中最重的一条也只占每笔交易计算上限的略高于一半——因此，对 Bloom 目前所做的任何操作而言，这条边界都还很远。

在 Rome devnet 上测得，每项各需一次签名——以下为两条链上观察到的范围：

| Solana 路径流程                                | CU         |
| ------------------------------------------ | ---------- |
| 受门控的 RWA 转账                                | \~339–381K |
| wUSDC 批准                                   | \~189–191K |
| 商店购买（批准 + 购买 = 共 2 次签名）                    | \~730–796K |
| 现金腿清扫到钱包自身的代币账户                            | \~42–54K   |
| 普通数值转账                                     | \~47K      |
| `TestApprover.approve` ——允许名单准入， **由钱包签名** | 220,794    |

作为比较，Solana 的单笔交易计算上限为 1.4M CU——Bloom 最重的流程也只用了略高于一半。

## 托管：为何 RWA 保持在合成地址中

每一种受权限控制的资产都必须回答的设计问题： *代币会不会泄出合规边界？* 在 Solana 路径上，答案是结构性的，而非策略性的：

* **RWA 驻留在 EVM 状态中。** 其余额存储在 Rome EVM 程序的账户内部。这里没有 **SPL 铸币** ，没有对应的代币账户表示，也没有任何 Solana 原生对象可供转移。（这正是刻意设计——若存在包装/镜像版本，那就成了逃逸通道。）
* **Solana 侧的底层机制无法触及它。** 该路径中用于资产转移的 legs（`create_ata`、SPL 转账、清扫）都作用于 SPL 代币账户；EVM 存储余额并没有这种账户。不存在任何可将 EVM 余额转移到 Solana 代币账户的指令。
* **只有所有者的 Solana 签名才能驱动该合成**，而且它所能表达的每一种移动都是对代币合约的调用——而该合约会执行允许名单门控——因此，转账到未列入白名单的地址时，无论由 EVM 密钥还是 Solana 密钥签名，都会以相同方式回滚。
* **现金腿是刻意预留的例外。** wUSDC（收益、出售所得）由 SPL 支持，并且 *应当* 双向往返：退出腿（`transfer_spl`）将其从合成地址移至钱包自己的关联代币账户，并完成端到端验证。资产仍留在边界内；现金则可自由流动。

两项实际后果，直说如下：Solana 钱包 UI 不会显示 RWA 持仓（没有可列出的 SPL 代币）——Bloom 应用才是持仓展示界面；而丢失的 Solana 密钥则通过发行方流程恢复（[COMPLIANCE.md](/zh/rome-shang-de-ying-yong/bloom/compliance.md#issuer-powers-transfer-agent-shaped)），而不是通过带外转移资产——这正是受权限控制资产所需要的特性。


---

# 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/rome-shang-de-ying-yong/bloom/lanes.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.