从rollup角度探索跨链通信

本文将从rollup角度探讨不同L2跨链消息传递方法，着重探讨无需信任的跨链通信。我们将简要了解直接读取状态方法、轻客户端方法以及存储证明。我们还会涉及到证明聚合机制、可信第三方跨链消息传输和核心ZK跨链解决方案。最后，我们再来看当今不同的L2是如何实现跨链消息传递的。

1、跨链消息传递简介

对于跨链通信，所有各方（L2、L3等）必须能够直接访问最新的以太坊状态根。

所有存款层都有一个“内置”的跨链机制，可用来访问L1状态根，状态根将作为存款消息传递给L2。

1.1 状态根的两种访问类型

类型1：直接读取状态根——可以通过操作码或预编译完成。然而，至今还没有实现，所以不需要任何proof证明。

· Brecht Devos在一篇研究文章中描述了一种可能的直接读取状态的方法：“……我们可以公开一个预编译合约，它可以直接调用目标链上的智能合约。这种预编译直接在源链中插入并执行另一条链的智能合约代码。这确保了智能合约始终能够以高效且易于证明的方式访问最新的可用状态。”

· 在Optimism的RFP“远程静态调用概念证明”中亦有相关描述。

类型2：证明生成——即在另一个区块链上证明关于一个区块链的陈述。

“带证明的跨链消息传递”有两种方法：

· 无需信任的跨链通信——也就是说，没有可信的第三方（例如，使用轻客户端或存储证明）。无需信任的方法既可用于第三方生成证明，也可用于跨链通信参与者自己生成证明。

· 在不同的rollup之间共享证明，以确保跨链操作。这个方法本文不多做讨论，目前正处于研究和探索阶段，并且不被认为是一个可能广泛应用的解决方案。

1.2 “带证明的跨链消息传递”方法

1.2.1 轻客户端跨链消息传递

证明链B上的数据

· 从链B全节点（如需对某些历史状态进行存储证明则为archive归档节点）获取默克尔证明数据；

· 将与包含我们想要验证的状态的链B区块相对应的区块头和证明数据作为calldata发送给链A上的证明者合约；

· 证明者合约根据区块头数据计算区块哈希值，查询链A上的轻客户端智能合约（跟踪链B的区块哈希值），并检查哈希值是否有效；

· 证明数据是根据区块头中的bytes32状态根进行验证的。

1.2.2 存储证明

存储证明有两个“workflow”选项：

· 生成存储证明→在链上使用

· 生成存储证明→生成zk证明→在链上使用

也可能有一个实体将多个证明收集打包为单个证明（包括存储证明和zk证明）。这是一个可选的优化步骤，暂不讨论。

下面我们来看下存储证明“workflow”的三个主要阶段：生成存储证明、生成zk证明、链上使用。

（1）生成存储证明

· 存储证明允许我们使用机密承诺证明某些信息存在于区块链上，并且是真实的；

· 自1979年默克尔树出现之后，存储证明一直是加密领域的一部分。然而，vanilla储存证明通常相当大。现代创新在于将存储证明与可证明的计算相结合，创造出可以在链上验证的简洁证明。

要生成存储证明，必须提供特定的数据块及其在默克尔树中的关联Merkle或Verkle路径。该路径由使用相同的哈希算法重建根哈希值所需的兄弟哈希值组成。

要验证存储证明，接收方可以使用所提供的数据和Merkle或Verkle路径来重新计算根哈希值。如果重新计算的根哈希值与已知的根哈希值相匹配，则接收方可以确信该数据是真实的，是已提交数据集的一部分。

（2）生成ZKP（零知识证明）

然而，以太坊类型的存储证明约为4kb——对于将整个存储证明发布到目标链上来说相当大，因为证明验证将非常昂贵。因此，使用ZKP（例如，ZK-SNARK）进行压缩是合理的，可以使证明更小、验证成本更低。

（3）Unroll ZKP

获得ZKP后，目标链上的用户可以unroll他们获得的证明（例如，通过区块头或区块哈希值访问历史状态）。

Unroll可以通过如下方式进行：

链上积累：从证明中重建区块头的整个过程直接在区块链上执行。缺点：gas费高，耗费计算资源；优点：没有额外的证明时间，延迟很低，因为不需要在区块链之外生成证明。

链上压缩：从数据中删除冗余或不必要的信息，或使用为提高空间效率优化过的数据结构。压缩后的数据被发送到区块链，并可以在需要时解压缩。缺点：压缩和解压数据可能意味着需要额外的计算，但是这种延迟也许可以忽略不计。使用的压缩算法可能会对数据的安全性带来负面影响；优点：降低数据成本。

链下存储：将数据存储在链下，按需将特定数据块放在链上。这与出于某种原因需要存储大量数据的解决方案相关（例如，从创世区块开始的以太坊archive节点）。缺点：与链上压缩相同；优点：进一步降低数据成本。

1.2.3 可信第三方

完整的跨链解决方案还应涉及到具有可信第三方（如oracle、中心化桥等）的跨消息传递解决方案。

1.2.4 “通用”证明系统

在使用共享证明聚合平台机制的情况下，可以通过接收在聚合平台内结算的区块哈希值来加快消息传递速度，并且此处的结算还将处理消息传递（但是如果证明聚合平台出现了问题怎么办？）。

1.2.5 ZK跨链消息传递的一些不明问题

如果没有可信的第三方（可以是单个实体或多个实体），跨链消息传递是否可行？跨链消息传递的有效机制是什么？一般来说，对于以太坊L2（可以直接访问L1的区块哈希值）和以太坊本身来说，如果一条链可以在另一条链上运行轻客户端等，它就可以验证来自该外部链的区块头，这对无需信任的跨链消息传递来说足够了。

用于跨链证明生成的ZK电路是否规模适宜？在某些情况下，特别是当共识层（需要对跨链操作进行验证）非常大时，用于ZK跨链消息传递的电路可能比rollup和链上存储大几个数量级，并且计算开销也很大。推测这个问题可以通过更中心化的方法来克服。

2、跨链消息传递解决方案示例

· Succinct Labs使用轻客户端来验证从源链到目标链共识层的共识。具体想法是存在一个轻客户端协议，以确保节点可以同步最终区块链状态的区块头。ZKP用于生成共识证明。

· Lagrange Labs构建非交互式跨链状态证明。Lagrange证明网络负责创建状态根。每个Lagrange节点都包含一个分片私钥的一部分，用来证明特定链的状态。每个状态根都是一个阈值签名的Verkle根，可用于证明特定链在特定时间的状态。状态根是完全通用的，可以在状态证明中使用，以证明链中任何一个合约或钱包的当前状态。

· Herodotus使用ZKP存储证明提供智能合约，同步访问其他以太坊层的链上数据。针对验证，它使用原生的L1<>L2消息传递来同步以太坊rollup之间的区块哈希值。

· =nil; Foundation（Mina、L1）允许以太坊上的智能合约验证Mina状态的有效性。生成特殊用途的状态证明，在以太坊上进行验证的成本很低（在以太坊上进行本地Mina证明的成本很高）。假设（在未来的某个时候）应用程序可以直接使用Mina的证明生成工具来检查跨链交易的有效性。=nil; Foundation还有一个Proof Market（证明市场），用户/项目可以主要购买/出售SNARK证明，这些证明允许无需信任的数据访问。

· Axiom：如果Axiom已经为至今为止的账本生成了ZKP——它不需要为特定的数据块生成ZKP——它可以将这个ZKP传递给链（作为Relayer中继器），甚至可以提供对该ZKP的访问。

3、L2的跨链消息传递

声明：对于大多数L2来说，跨链消息传递仍在发展进步。下面的所有分析都是基于开源信息。也就是说，文中提到的解决方案可能正处于探索和测试阶段，rollup最终可能采用其他方法。

（1）Taiko

· Taiko存储每个链的区块哈希值。对于每对链，它都部署两个智能合约，存储彼此的哈希值。在L2←→L1的例子中，每次在Taiko上创建一个L2区块时，L1上的外围块的哈希值就存储在TaikoL2合约中。在L1←→L2的情况下也是同样的运行方式。

· 可以通过调用TaikoL1/TaikoL2合约上的getCrossChainBlockHash(0)来获取存储在目标链上的最新已知Merkle根，并获得要验证的值/消息。通过在“源链”上使用标准RPC调用eth_getProof请求，可以获得最新已知的Merkle根的兄弟哈希值。

· 然后，只需发送它们根据存储在“目标链”上列表中的最新已知区块哈希值进行验证。验证者将获取一个值（默克尔树上的一片叶子）和兄弟哈希值来重新计算Merkle根，并检查它是否与存储在目标链的区块哈希值列表中的根相匹配。

（2）Starknet

Starknet使用存储证明进行无需信任的跨链消息传递。

L2→L1消息传递协议

· 在Starknet交易执行期间，Starknet上的合约发送一条L2→L1消息。

· 然后将消息参数（包含L1上的接收方合约和相关数据）附加到相关的状态更新（主存储树）。

· L2消息存储在智能合约的L1上。

· 在L1上发出一个事件（存储消息参数）。

· L1上的接收方地址可以通过重新提供消息参数来访问和使用该消息作为L1交易的一部分。

· 跨链消息存储在主干树中。

L2 → L1

L1 → L2

（3）Optimism

· L1和L2之间的通信是由两个称为“messenger”的特殊智能合约实现的。

· 针对Optimism(L2)到以太坊(L1)的交易，有必要在状态根写入后提供关于L1上消息的默克尔证明。在该证明交易成为L1链的一部分之后，错误挑战期开始。在此等待期之后，任何用户都可以通过触发以太坊上的第二笔交易来“最终完成”交易，将消息发送到目标L1合约。

· 跨链消息存储在主干树中。

（4）Arbitrum

· Retryable tickets是Arbitrum用于创建L1到L2消息传递的规范方法，即初始化要在L2上执行的消息的L1交易。可以在L1上支付固定费用（仅取决于其calldata大小）提交一个Retryable。主状态树用于智能合约中自定义数据格式的跨链通信。在L1上提交retryable ticket与L2上的执行是可以分离/异步的。Retryables提供跨链操作之间的原子性。如果L1交易请求提交成功（即没有回滚），那么L2上的Retryable执行就有了一个强有力的保证，最终也会成功。

· Arbitrum有两个树干：Nitro链以以太坊的状态树格式进行维护，为Merkle树。Assertion Tree（证明树）存储通过“assertion”在以太坊上确认的Arbitrum链的状态。推进Arbitrum链的规则是确定性的。这意味着针对给定的一个链的状态和一些新的输入值，只有一个有效输出。因此，如果该证明树包含多个叶子，那么最多只有一个叶子可以表示有效的链状态。

· Arbitrum的Outbox系统允许任意L2到L1的合约调用，即从L2发起消息，最终在L1上执行。L2到L1消息（又名“outgoing message”）与Arbitrum的L1到L2消息（Retryable）有许多共同之处，尽管有一些明显的区别。Arbitrum链的L2状态的一部分——也就是每个RBlock中证明的部分——是链历史中所有L2到L1消息的默克尔根。在证明的RBlock被确认后（通常为证明后约一周），该Merkle根包含在Outbox合约中被发布到L1上。然后，Outbox合约允许用户执行他们的消息。

（5）Polygon zkEVM

· 该zkEVM的Bridge SC为参与通信或资产交易的每个网络使用一种称为Exit Tree的特殊默克尔树。

· 它使用Merkle根（在一个单独的状态树中），可以在github上找到一个桥接架构图。

· zkEVM Bridge SC的部署在以太坊2.0存款合约的基础上进行了若干改动。例如，它使用了专门设计的append-only默克尔树，但采用了与以太坊2.0存款合约相同的逻辑。其他差异与基本哈希值和叶节点有关。

· Polygon zkEVM Bridge智能合约的主要特点是使用Exit Tree和全局Exit Tree，其中全局Exit Tree的根是truth状态的主要来源。因此，L1和L2有两个不同的全局Exit根管理器，Bridge SC有一个单独的逻辑。

（6）Scroll

· 部署在以太坊和Scroll上的桥合约允许用户在L1和L2之间传递任意消息。在此消息传递协议之上，我们还构建了一个无需信任的桥接协议，以允许用户在L1和L2之间桥接ERC-20资产。为了从以太坊向Scroll发送消息或资金，用户调用Bridge合约上的sendMessage交易。中继器将在L1上索引此交易，并将其发送到排序器，以包含在L2区块中。在L2桥合约上，将消息从Scroll发送回以太坊的过程类似。

· 跨链消息存储在常规消息队列中。排序器从这个队列中摄取跨链消息，并将它们作为常规交易添加到链上。

（7）zksync Era

声明：本部分内容仅关于zksync Era，可能与ZK Stack上的跨链消息传递不同，ZK Stack是用于构建主权ZK超级链的模块化框架。

· 每个交易包都有一个单独的L2->L1消息。

· 不可能直接从L2发送交易到L1上。然而，你可以从zkSync Era向以太坊发送任意长度的消息，然后使用L1智能合约在以太坊上处理接收到的消息。zkSync Era有一个请求证明函数，该函数将返回一个布尔参数，指示消息是否成功发送到了L1。通过观察以太坊或使用zksync-web3 API的zks_getL2ToL1LogProof方法来检索消息包含的默克尔证明。

· 对于L1→L2，zkSync Era智能合约允许发送方在以太坊L1上请求交易，并将数据传递给zkSync Era L2。

· 桥合约：https://github.com/matter-labs/era-contracts/blob/main/ethereum/contracts/bridge/L1ERC20Bridge.sol

4、结论

跨链通信对于区块链大规模采用的“必备”应用程序是不可或缺的（例如，V神文章中描述的跨链社交恢复钱包）。目前使用的大多数跨链解决方案都是为L1←→L2设计的，以覆盖提款功能。这些解决方案可以扩展到更多的区块链。但与此同时，可以实施更先进的跨链通信解决方案，例如完全不需要证明的“直接读取状态”或无需信任的“存储证明”。对于大多数L2来说，跨链通信仍有发展进步的空间。