**TLDR：**本文从 Rollups 的角度探讨了不同 L2 跨链消息传递的方法，更多地关注不信任的跨链通信。我们简要解释直接状态读取方法、轻客户端方法和存储证明。我们还提到了证明聚合机制、可信第三方跨链消息传递和核心 ZK 跨链解决方案。最后，我们将介绍当今不同的 L2 如何处理跨链消息传递的示例。

第一部分：跨链消息介绍

• 两种访问类型：直接状态读取和证明生成

• “带证明的跨链消息传递”的方法：使用轻客户端的跨链消息传递、存储证明

• 值得信赖的第三方

• “通用”证明系统

• 关于 ZK 跨链消息传递的一些尚不清楚的问题

第二部分：一些ZK跨链消息解决方案

第三部分：不同 L2 跨链消息传递的不同方法

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

所有提供存款的层都已经具有“内置”跨链机制，可用于获取 L1 状态根。在这种情况下，状态根将作为存款消息传递到 L2。

类型 1：直接状态读取– 可以通过操作码或预编译来完成。然而，它尚未实施，因此不需要证据。

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

• 以及Optimism RFP “远程静态调用概念证明”中的内容。

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

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

• 不可信的跨链通信——即没有可信的第三方（例如，使用轻客户端或存储证明）。无信任方法既可以与第三方生成证明一起使用，也可以与跨链通信参与者自己生成证明一起使用。

• 不同rollup之间共享证明以保证跨链操作。此类别超出了本文的范围，因为它目前处于研究和探索阶段，并且不被认为是广泛使用的解决方案。有关更多详细信息，请查看共享欺诈证明的研究提案（由 Succinct Labs 和 Ellipsis Labs 提供）和共享证明聚合器机制的研究提案（由 Kalman Lajko 提供）。

使用轻客户端进行跨链消息传递

证明链B数据上链

• 从链 B 全节点获取 Merkle 证明数据（如果需要针对某些旧状态的存储证明，则为归档节点）；

• calldata 发送证明数据和对应于链 B 区块的标头，其中包含我们要验证的链 A 上证明者合约的状态 ；

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

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

存储证明

存储证明有两个“工作流程”选项：

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

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

还可能有一个实体将多个证明收集到单个证明中（在存储和 zk 证明的情况下）。这是一个可选的优化步骤，目前超出了范围。

下面我们回顾一下存储证明“工作流程”的三个主要阶段：存储证明生成、zk 证明生成、链上使用。

1. 生成存储证明

• 存储证明使我们能够使用加密承诺来证明某些信息存在于区块链上并且是真实的；

• 自 1979 年 Merkle 树发明以来，存储证明一直是密码学领域的一部分。然而，普通的存储证明通常非常大。现代世界的创新在于将存储证明与可证明的计算相结合，以创建可以在链上验证的简洁证明；

• 本文介绍了一个示例。

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

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

2.生成ZKP

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

3.展开ZKP

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

展开可以通过

1. **链上累积：**从证明重新创建块头的整个过程直接在区块链上执行。缺点：gas成本高，计算资源密集；优点：证明时间没有开销，延迟很低，因为不需要在区块链之外生成证明。

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

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

为了实现跨链解决方案的完整性，还应该提到与可信第三方（例如预言机、中心化桥接器等）的交叉消息解决方案。

假设使用共享证明聚合器机制将汇总结算到 L1。在这种情况下，可以通过接受在该聚合器内结算的块哈希来加快消息传递速度，并且此处的结算也将负责消息传递（但如果证明聚合器失败怎么办）。详细说明：链接。

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

• **用于跨链证明生成的 ZK 电路的大小是否合理？*在某些*情况下，特别是当共识层（跨链操作需要验证）很大时，ZK跨链消息传递的电路可能比rollups和链上存储大几个数量级，计算开销巨大，出色地。据推测，可以通过更集中的方法来克服这个问题。本文对此问题进行了探讨。

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

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

• **希罗多德*使用 ZKP 存储证明为智能合约提供同步*访问来自其他以太坊层的链上数据的功能。为了进行验证，它使用本机 L1<>L2 消息传递来同步以太坊汇总之间的块哈希。

• =无；基金会（Mina，L1）允许以太坊上的智能合约验证 Mina 状态的有效性。生成特殊用途的状态证明，在以太坊上验证该证明的成本较低（在以太坊上验证原生 Mina 证明的成本较高）。假设（在未来）应用程序可以直接使用 Mina 的证明生成工具来检查跨链交易的有效性。=无；基金会还有证明市场，用户/项目可以在其中购买/出售大部分 SNARK 证明，从而允许不信任的数据访问。

• Axiom：如果 Axiom 到目前为止已经为账本生成了 ZKP，那么它不需要为特定的数据生成 ZKP，它只需将此 ZKP 传递到链上（充当中继者），甚至可以提供对这个ZKP。

免责声明：对于大多数 L2 来说，跨链消息传递仍在进行中。以下所有分析均基于开源信息。也就是说，提到的解决方案可能正在探索和测试实施中，而汇总可能最终会使用其他方法。

Taiko

• Taiko 存储每个链的区块哈希值。对于每对链，它部署两个智能合约，存储彼此的哈希值。在 L2 ← → L1 示例中，每次在 Taiko 上创建 L2 区块时，L1 上封闭区块的哈希值都会存储在 TaikoL2 合约中。L1←→L2两个方向都是这样工作的。

• 通过调用 TaikoL1/TaikoL2 合约，可以获取目标链上存储的最新已知 Merkle 根 getCrossChainBlockHash(0) ，并获取值/消息进行验证。eth_getProof 人们可以通过“源链”上的标准 RPC 调用来获取最新已知 Merkle 根的同级哈希值 。

• 然后，只需发送它们以根据存储在“目标链”上的列表中的最新已知块哈希进行验证。验证者将采用该值（Merkle 树中的叶子）和同级哈希值来重新计算 Merkle 根，并检查它是否与存储在目标链的块哈希列表中的值匹配。

Starknet

Starknet 使用存储证明来实现无需信任的跨链消息传递。

L2→ L1 消息传递协议

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

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

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

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

• L1 上的接收者地址可以通过重新提供消息参数来访问和使用消息作为 L1 事务的一部分。

• 跨链消息存储在主树中。

L2→L1

L1 → L2

Optimism

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

• 对于 Optimism（L2）到以太坊（L1）的交易，需要在状态根写入后在 L1 上提供消息的 Merkle 证明。故障挑战期在该证明交易成为 L1 链的一部分后开始。在此等待期过后，任何用户都可以通过触发以太坊上的第二笔交易来“完成”交易，该交易将消息发送到目标 L1 合约。

• 跨链消息存储在主树中。

Arbitrum

• 可重试票据是 Arbitrum 创建 L1 到 L2 消息的规范方法，即启动要在 L2 上执行的消息的 L1 事务。可以在 L1 支付固定成本（仅取决于其调用数据大小）来提交可重试。主状态树用于在智能合约中使用自定义数据格式进行跨链通信。在 L1 上提交可重试票证与其在 L2 上的执行是分离的/异步的。可重试提供跨链操作之间的原子性。如果L1事务请求提交成功（即不恢复），那么L2上Retryable的执行也有强有力的保证最终成功。

• Arbitrum 有两棵树：Nitro 链以以太坊的状态树格式维护，组织为 Merkle 树。断言树存储仲裁链的状态，该状态通过“断言”在以太坊上得到确认。推进 Arbitrum 链的规则是确定性的。这意味着给定一个链状态和一些新输入，只有一个有效输出。因此，如果断言树包含多个叶子，则最多只有一个叶子可以代表有效的链状态。

• Arbitrum 的 Outbox 系统允许任意 L2 到 L1 合约调用，即从 L2 发起的消息，最终在 L1 上执行解析。L2 到 L1 消息（又名“传出”消息）与 Arbitrum 的 L1 到 L2 消息（可重试）有许多共同点，“相反”，但有一些差异。Arbitrum 链的 L2 状态的一部分（因此也是每个 RBlock 中断言的一部分）是该链历史中所有 L2 到 L1 消息的 Merkle 根。在断言的 RBlock 得到确认后（通常在断言后约 1 周），该 Merkle 根将发布在合约的 L1 上 Outbox 。然后，Outbox 合约允许用户执行他们的消息——验证 Merkle 包含证明并跟踪哪些 L2 到 L1 消息已经被使用。

Polygon zkEVM

• zkEVM 的 Bridge SC 对参与通信或资产交换的每个网络使用一种称为退出树的特殊 Merkle 树。

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

• zkEVM Bridge SC 的实现基于以太坊 2.0 存款合约，但有一些更改。例如，虽然它使用专门设计的仅追加的 Merkle 树，但它采用与以太坊 2.0 存款合约相同的逻辑。其他差异与基本哈希和叶节点有关。

• Polygon zkEVM Bridge 智能合约的主要功能是使用退出树和全局退出树，其中全局退出树根作为状态事实的主要来源。因此，L1 和 L2 存在两个不同的全局出口根管理器，并且桥 SC 存在单独的逻辑。

Scroll

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

• 跨链消息存储在常规消息队列中。排序器从该队列中挑选它们并将它们作为常规交易添加到链上。

zksync Era

免责声明：这仅与 zksync Era 相关，可能与 ZK Stack 上的跨链消息传递不同，ZK Stack 是用于构建主权 ZK 驱动的超链的模块化框架。

• 每个批次都有一个单独的 L2->L1 消息小树。

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

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

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

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

大多数 L2 的跨链通信仍在进行中。如果您对本文或现有或潜在的跨链通信方法有任何建议和意见，我们非常欢迎您分享和协作，共同构建最强大、高效、灵活的跨链通信解决方案。

资料来源：

• Ingonyama的文章“用零知识证明桥接多链宇宙” 。

• 文章“什么是存储证明以及它们如何改进预言机？” 由斯塔克韦尔提供。

• Vitalik 的文章“深入研究钱包和其他用例的跨 L2 读取”。

• 论文“zkBridge：Trustless Cross-chain Bridges Made Practical”，作者：Tian Cheng Xie、Jiaheng Zhu、Zerui Cheng、Fan Zhang、Yupeng Zhang、Yongzheng Jia、Dan Boneh 和 Dawn Song。

• Kalman Lajko 的研究提案“递归证明内快速交叉汇总消息传递和结算的研究”。

• Glaze的文章《ZK 跨链消息协议及其如何开辟跨链通信新方式》。

• Brecht Devos

探索我们的 招聘网站上的空缺职位。

要了解 Taiko 的最新动态：

• 网站：https:  //taiko.xyz

• 不和谐：  https: //discord.gg/taikoxyz

• GitHub：  https: //github.com/taikoxyz

• 推特：https:  //twitter.com/taikoxyz

为 Taiko 做出贡献并赚取 GitPOAP！您还将成为我们自述文件的贡献者。开始使用 贡献指南。

**TLDR：**本文从 Rollups 的角度探讨了不同 L2 跨链消息传递的方法，更多地关注不信任的跨链通信。我们简要解释直接状态读取方法、轻客户端方法和存储证明。我们还提到了证明聚合机制、可信第三方跨链消息传递和核心 ZK 跨链解决方案。最后，我们将介绍当今不同的 L2 如何处理跨链消息传递的示例。

第一部分：跨链消息介绍

• 两种访问类型：直接状态读取和证明生成

• “带证明的跨链消息传递”的方法：使用轻客户端的跨链消息传递、存储证明

• 值得信赖的第三方

• “通用”证明系统

• 关于 ZK 跨链消息传递的一些尚不清楚的问题

第二部分：一些ZK跨链消息解决方案

第三部分：不同 L2 跨链消息传递的不同方法

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

所有提供存款的层都已经具有“内置”跨链机制，可用于获取 L1 状态根。在这种情况下，状态根将作为存款消息传递到 L2。

类型 1：直接状态读取– 可以通过操作码或预编译来完成。然而，它尚未实施，因此不需要证据。

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

• 以及Optimism RFP “远程静态调用概念证明”中的内容。

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

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

• 不可信的跨链通信——即没有可信的第三方（例如，使用轻客户端或存储证明）。无信任方法既可以与第三方生成证明一起使用，也可以与跨链通信参与者自己生成证明一起使用。

• 不同rollup之间共享证明以保证跨链操作。此类别超出了本文的范围，因为它目前处于研究和探索阶段，并且不被认为是广泛使用的解决方案。有关更多详细信息，请查看共享欺诈证明的研究提案（由 Succinct Labs 和 Ellipsis Labs 提供）和共享证明聚合器机制的研究提案（由 Kalman Lajko 提供）。

使用轻客户端进行跨链消息传递

证明链B数据上链

• 从链 B 全节点获取 Merkle 证明数据（如果需要针对某些旧状态的存储证明，则为归档节点）；

• calldata 发送证明数据和对应于链 B 区块的标头，其中包含我们要验证的链 A 上证明者合约的状态 ；

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

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

存储证明

存储证明有两个“工作流程”选项：

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

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

还可能有一个实体将多个证明收集到单个证明中（在存储和 zk 证明的情况下）。这是一个可选的优化步骤，目前超出了范围。

下面我们回顾一下存储证明“工作流程”的三个主要阶段：存储证明生成、zk 证明生成、链上使用。

1. 生成存储证明

• 存储证明使我们能够使用加密承诺来证明某些信息存在于区块链上并且是真实的；

• 自 1979 年 Merkle 树发明以来，存储证明一直是密码学领域的一部分。然而，普通的存储证明通常非常大。现代世界的创新在于将存储证明与可证明的计算相结合，以创建可以在链上验证的简洁证明；

• 本文介绍了一个示例。

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

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

2.生成ZKP

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

3.展开ZKP

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

展开可以通过

1. **链上累积：**从证明重新创建块头的整个过程直接在区块链上执行。缺点：gas成本高，计算资源密集；优点：证明时间没有开销，延迟很低，因为不需要在区块链之外生成证明。

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

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

为了实现跨链解决方案的完整性，还应该提到与可信第三方（例如预言机、中心化桥接器等）的交叉消息解决方案。

假设使用共享证明聚合器机制将汇总结算到 L1。在这种情况下，可以通过接受在该聚合器内结算的块哈希来加快消息传递速度，并且此处的结算也将负责消息传递（但如果证明聚合器失败怎么办）。详细说明：链接。

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

• **用于跨链证明生成的 ZK 电路的大小是否合理？*在某些*情况下，特别是当共识层（跨链操作需要验证）很大时，ZK跨链消息传递的电路可能比rollups和链上存储大几个数量级，计算开销巨大，出色地。据推测，可以通过更集中的方法来克服这个问题。本文对此问题进行了探讨。

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

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

• **希罗多德*使用 ZKP 存储证明为智能合约提供同步*访问来自其他以太坊层的链上数据的功能。为了进行验证，它使用本机 L1<>L2 消息传递来同步以太坊汇总之间的块哈希。

• =无；基金会（Mina，L1）允许以太坊上的智能合约验证 Mina 状态的有效性。生成特殊用途的状态证明，在以太坊上验证该证明的成本较低（在以太坊上验证原生 Mina 证明的成本较高）。假设（在未来）应用程序可以直接使用 Mina 的证明生成工具来检查跨链交易的有效性。=无；基金会还有证明市场，用户/项目可以在其中购买/出售大部分 SNARK 证明，从而允许不信任的数据访问。

• Axiom：如果 Axiom 到目前为止已经为账本生成了 ZKP，那么它不需要为特定的数据生成 ZKP，它只需将此 ZKP 传递到链上（充当中继者），甚至可以提供对这个ZKP。

免责声明：对于大多数 L2 来说，跨链消息传递仍在进行中。以下所有分析均基于开源信息。也就是说，提到的解决方案可能正在探索和测试实施中，而汇总可能最终会使用其他方法。

Taiko

• Taiko 存储每个链的区块哈希值。对于每对链，它部署两个智能合约，存储彼此的哈希值。在 L2 ← → L1 示例中，每次在 Taiko 上创建 L2 区块时，L1 上封闭区块的哈希值都会存储在 TaikoL2 合约中。L1←→L2两个方向都是这样工作的。

• 通过调用 TaikoL1/TaikoL2 合约，可以获取目标链上存储的最新已知 Merkle 根 getCrossChainBlockHash(0) ，并获取值/消息进行验证。eth_getProof 人们可以通过“源链”上的标准 RPC 调用来获取最新已知 Merkle 根的同级哈希值 。

• 然后，只需发送它们以根据存储在“目标链”上的列表中的最新已知块哈希进行验证。验证者将采用该值（Merkle 树中的叶子）和同级哈希值来重新计算 Merkle 根，并检查它是否与存储在目标链的块哈希列表中的值匹配。

Starknet

Starknet 使用存储证明来实现无需信任的跨链消息传递。

L2→ L1 消息传递协议

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

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

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

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

• L1 上的接收者地址可以通过重新提供消息参数来访问和使用消息作为 L1 事务的一部分。

• 跨链消息存储在主树中。

L2→L1

L1 → L2

Optimism

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

• 对于 Optimism（L2）到以太坊（L1）的交易，需要在状态根写入后在 L1 上提供消息的 Merkle 证明。故障挑战期在该证明交易成为 L1 链的一部分后开始。在此等待期过后，任何用户都可以通过触发以太坊上的第二笔交易来“完成”交易，该交易将消息发送到目标 L1 合约。

• 跨链消息存储在主树中。

Arbitrum

• 可重试票据是 Arbitrum 创建 L1 到 L2 消息的规范方法，即启动要在 L2 上执行的消息的 L1 事务。可以在 L1 支付固定成本（仅取决于其调用数据大小）来提交可重试。主状态树用于在智能合约中使用自定义数据格式进行跨链通信。在 L1 上提交可重试票证与其在 L2 上的执行是分离的/异步的。可重试提供跨链操作之间的原子性。如果L1事务请求提交成功（即不恢复），那么L2上Retryable的执行也有强有力的保证最终成功。

• Arbitrum 有两棵树：Nitro 链以以太坊的状态树格式维护，组织为 Merkle 树。断言树存储仲裁链的状态，该状态通过“断言”在以太坊上得到确认。推进 Arbitrum 链的规则是确定性的。这意味着给定一个链状态和一些新输入，只有一个有效输出。因此，如果断言树包含多个叶子，则最多只有一个叶子可以代表有效的链状态。

• Arbitrum 的 Outbox 系统允许任意 L2 到 L1 合约调用，即从 L2 发起的消息，最终在 L1 上执行解析。L2 到 L1 消息（又名“传出”消息）与 Arbitrum 的 L1 到 L2 消息（可重试）有许多共同点，“相反”，但有一些差异。Arbitrum 链的 L2 状态的一部分（因此也是每个 RBlock 中断言的一部分）是该链历史中所有 L2 到 L1 消息的 Merkle 根。在断言的 RBlock 得到确认后（通常在断言后约 1 周），该 Merkle 根将发布在合约的 L1 上 Outbox 。然后，Outbox 合约允许用户执行他们的消息——验证 Merkle 包含证明并跟踪哪些 L2 到 L1 消息已经被使用。

Polygon zkEVM

• zkEVM 的 Bridge SC 对参与通信或资产交换的每个网络使用一种称为退出树的特殊 Merkle 树。

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

• zkEVM Bridge SC 的实现基于以太坊 2.0 存款合约，但有一些更改。例如，虽然它使用专门设计的仅追加的 Merkle 树，但它采用与以太坊 2.0 存款合约相同的逻辑。其他差异与基本哈希和叶节点有关。

• Polygon zkEVM Bridge 智能合约的主要功能是使用退出树和全局退出树，其中全局退出树根作为状态事实的主要来源。因此，L1 和 L2 存在两个不同的全局出口根管理器，并且桥 SC 存在单独的逻辑。

Scroll

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

• 跨链消息存储在常规消息队列中。排序器从该队列中挑选它们并将它们作为常规交易添加到链上。

zksync Era

免责声明：这仅与 zksync Era 相关，可能与 ZK Stack 上的跨链消息传递不同，ZK Stack 是用于构建主权 ZK 驱动的超链的模块化框架。

• 每个批次都有一个单独的 L2->L1 消息小树。

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

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

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

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

大多数 L2 的跨链通信仍在进行中。如果您对本文或现有或潜在的跨链通信方法有任何建议和意见，我们非常欢迎您分享和协作，共同构建最强大、高效、灵活的跨链通信解决方案。

资料来源：

• Ingonyama的文章“用零知识证明桥接多链宇宙” 。

• 文章“什么是存储证明以及它们如何改进预言机？” 由斯塔克韦尔提供。

• Vitalik 的文章“深入研究钱包和其他用例的跨 L2 读取”。

• 论文“zkBridge：Trustless Cross-chain Bridges Made Practical”，作者：Tian Cheng Xie、Jiaheng Zhu、Zerui Cheng、Fan Zhang、Yupeng Zhang、Yongzheng Jia、Dan Boneh 和 Dawn Song。

• Kalman Lajko 的研究提案“递归证明内快速交叉汇总消息传递和结算的研究”。

• Glaze的文章《ZK 跨链消息协议及其如何开辟跨链通信新方式》。

• Brecht Devos

探索我们的 招聘网站上的空缺职位。

要了解 Taiko 的最新动态：

• 网站：https:  //taiko.xyz

• 不和谐：  https: //discord.gg/taikoxyz

• GitHub：  https: //github.com/taikoxyz

• 推特：https:  //twitter.com/taikoxyz

为 Taiko 做出贡献并赚取 GitPOAP！您还将成为我们自述文件的贡献者。开始使用 贡献指南。