通过实时证明实现 Rollup 之间的同步可组合性
1. 基于汇总和实时验证
基于基础的Rollup是一种任何人都可以提议新区块的Rollup ，没有特权排序者。任何参与者都可以获取Rollup的当前状态，应用一组交易，并生成一个新区块。
当我们要求数据可用性有效载荷和有效性证明作为一个整体提交时，一个关键的设计优势便显现出来。在传统的Rollup设计中，数据先发布，证明随后提交，这造成了一个断层，使激励机制的设计变得复杂：谁来生成证明？何时生成？如何确保他们得到公平及时的补偿？
通过同时发布数据和证明，我们彻底消除了这一差距。The Block提议者负责执行和证明。如果证明无效或缺失，则The Block根本不存在。这极大地简化了激励机制：The Block提议者即为证明者，其奖励来自同一来源（例如交易费），无需单独的证明市场或挑战期。
这是通过实时证明实现的，它能够快速生成有效性证明，使其可以与代码块的构建同时进行，而不是作为异步的后续考虑。
实时证明正迅速成为现实。目前，证明一个完整的以太坊区块大约需要 12 个 GPU，平均证明时间约为 7 秒。尽管通过硬件改进和证明系统优化仍有很大的提升空间，可以进一步降低延迟，但很难准确预测其极限在哪里。证明者中心化是一个值得关注的问题：硬件要求并不低，而且并非所有区块创建者都能访问相同的证明基础设施。然而，证明本身具有并行化和商品化的特性，而且发展趋势显然是朝着使用更便宜的硬件实现更快证明的方向发展。
2. 什么是同步可组合性？
同步可组合性意味着在单个交易中，一条链（L1 或Rollup）上的智能合约可以调用另一条链（L1 或另一个Rollup）上的智能合约，并在相同的执行上下文中接收结果，就像两个合约都存在于同一条链上一样。
如今，跨链交互是异步的：你在链 A 上发送消息，等待它转发到链 B，然后单独处理结果。这破坏了以太坊 DeFi 生态系统赖以强大的可组合性模型。协议无法跨越Rollup边界进行原子性组合。
同步组合性恢复了这一点。从开发者的角度来看，调用另一个Rollup上的合约与调用同一条链上的合约在外观和行为上完全相同。交易要么在所有相关链上原子性地成功，要么完全回滚。
3. 简单情况：L2 到 L2 可组合性
在解决 L1↔L2 交互这个更难的问题之前，值得注意的是，仅 L2 卷包之间的可组合性相对简单。
如果只处理 L2 级别，我们可以将所有受影响的汇总状态的数据可用性打包到一个单独的 blob 中。The Block构建器会构建一个涉及多个Rollup状态的组合执行，将它们全部一起验证，并将结果作为单个原子数据可用性提交。由于所有受影响的状态转换都已一起验证和提交，因此自然而然地具备了可组合性：转换要么全部发生，要么全部不发生。
这一观察是基础。更难的问题在于，当L1智能合约参与交互时，如何才能使其有效运作。
4. 代理智能合约
实现跨链调用的核心机制是代理智能合约。代理智能合约部署在一条链上，代表另一条链上的智能合约。
当L1链上的合约想要调用Rollup R上的合约时，它并不会直接在R上执行代码。相反，它会调用位于L1链上的R合约的代理合约。该代理合约封装了跨链调用：它知道目标合约是什么，处理调用，在Rollup上应用相应的状态更改，并返回结果，所有这些操作都在同一笔交易执行中完成。
从调用者的角度来看，与代理交互与与真实合约交互并无区别。代理是远程合约的本地接口。
5. L1 ↔ L2 交互模型
当一笔交易同时涉及 L1 和 L2 智能合约时，其执行遵循一个结构化的流程：
第一步：确保代理合约存在
在执行之前，所有将与 L1 交互的 L2 合约的代理智能合约都必须部署完毕。如果要从 L1 调用Rollup R 上的某个合约，则该合约的代理必须已存在于 L1 上。
步骤 2：构建并提交执行表
执行表被构建并临时存储在 L1 状态中。该表是一系列条目，其中每个条目描述一个操作及其后果。每个条目包含：
- 行动：主要
CALL或RESULT。 - 一组 L2 状态转换：哪些汇总会受到影响，以及它们的状态根从什么状态转换到什么状态。
- nextAction ：接下来会发生什么，要么是返回结果（带有返回数据），要么是另一个调用（调用不同的 L1 智能合约）。
该表记录了跨链交互的完整轨迹。例如，考虑一个嵌套调用场景：
A ( on L1) calls B ( on Rollup 2 )→ B ( on Rollup 2 ) calls C ( on L1 )→ C ( on L1 ) returns→ B ( on Rollup 2 ) returns A ( on L1 ) continues execution在这种情况下，执行表将包含两条记录：
| # | Action | L2 State Transitions | nextAction | | ---|-----------------------|-------------------------------|---------------------| | 1 | CALL B ( on Rollup 2 ) - | Rup2: stateRoot₀ → stateRoot₁ | CALL C ( on L1) | | 2 | RETURN from C ( on L1) | Rup2: stateRoot₁ → stateRoot₂ | RETURN to A ( on L1) |第一条记录写道：“当 A 在Rollup 2 上调用 B 时， Rollup从 stateRoot₀ 转换到 stateRoot₁，接下来需要做的是调用 L1 上的 C。” 第二条记录写道：“C 返回后， Rollup 2 从 stateRoot₁ 转换到 stateRoot₂，最终结果返回给 A。”
执行表编码了整个调用/返回序列，以及每一步发生的所有Rollup状态转换。至关重要的是，该表附带一个有效性证明，保证表中每个执行步骤的正确性。该证明在提交表时验证一次。
步骤 3：使用代理解析执行 L1 任务
现在 L1 交易正常执行。当执行到 L1 合约调用代理合约时，代理合约执行以下操作：
- 在执行表中查找相应的
CALL操作。 - 验证并应用受影响汇总的状态根更改。
- 如果序列中有嵌套的 L1 调用，则执行它们。
- 从执行表中删除已消耗的条目（以避免浪费 L1 存储空间）。
- 将
RESULT返回给调用 L1 合约。
从L1执行环境的角度来看，调用正常发生并返回了结果。跨链交互的复杂性完全由代理和执行表抽象化了。
步骤 4：L2 发起的交易
从 L2 发起并与 L1 交互的交易遵循相同的模型，但执行表中的第一个操作是L2TX而不是CALL交易启动执行，任何对 L1 合约的调用都会成为表中的嵌套条目，并以相同的方式解析。
步骤 5：处理回滚
两个特殊操作： REVERT和REVERT_CONTINUE以类似于单个链内还原操作的方式处理跨链边界的还原操作。
当 L2 执行过程中发生回滚时，会向 L1 发送REVERT操作。L1 随后处理回滚，撤销回滚执行路径中所有嵌套的 L1 调用，并相应地更新受影响的Rollup状态根。L1 完成回滚调用的撤销后，会向 L2 发送REVERT_CONTINUE操作，允许执行恢复。最终结果是，回滚在单个链中的工作方式与当前相同。
6. 补充说明
账户抽象与激励机制协调
确保代理合约的部署以及用户与The Block创建者之间的激励机制正确匹配，可以使用现有的以太坊标准来实现——特别是EIP-7702 （设置 EOA 账户代码）和EIP-4337 （账户抽象）。这些标准提供了协调设置阶段所需的灵活性，而无需更改核心协议。
汇总不仅限于电子投票机
参与此系统的 Rollup 无需是 EVM 原生 Rollup。任何能够接受和生成对其他 Rollup 的 `CALL` 调用的Rollup均可参与。每个Rollup通过zkVerification 密钥定义自己的状态转换函数。Rollup 甚至可以拥有一个对其状态根具有完全控制权的拥有者。
主系统施加的唯一限制是以太币问责制：系统必须跟踪每个Rollup持有的以太币数量，并且不得允许Rollup发起“CALL”请求，其请求值高于其以太币总余额。
原生代币和价值转移
Rollup 可以定义自己的原生令牌。唯一的限制是，如果Rollup使用不同的原生令牌，则状态转换函数不应接受或发起来自或向外部Rollup发送的非零以太币值的CALL请求。这可以防止 Rollup 内部令牌与 L1 系统跟踪的以太币之间出现记账不匹配的情况。
无需 L1 叉车
整个机制无需对 L1 进行分叉即可实现。所有操作均通过部署在现有以太坊网络上的智能合约完成。
与预确认正交
该方案与预确认机制完全正交。它既不依赖于预确认，也不与之冲突。事实上，一旦L1预确认机制可用，该方案还能从中受益，因为更快的L1最终确认速度将降低跨链相互作用的延迟。
参考实现
这些智能合约的工作原理初稿可在以下网址获取： https://github.com/jbaylina/sync-rollups
