bridge是一种通信协议，有助于在区块链之间传输消息、资金或其他数据等信息。虽然有用，但搭建bridge是一项有风险的业务。区块链历史上一些最昂贵的黑客攻击仅针对bridge。
截至 2022 年，估计过去一年损失的资金中有 69% 是由于对桥梁的袭击，造成的损失高达数十亿美元。
在本文中，我们重点关注使用ZKP的桥梁建设的具体实施。虽然一些黑客攻击并不能仅仅因为使用 ZKP 就可以预防，但 ZKP 的稳健性将区块链共识协议的安全性扩展到了bridge。
bridge和ZKP
近年来，我们看到ZKP在 rollups 应用方面取得了巨大进步，其中稳健性允许安全和去中心化的应用程序。因此，也在探索 ZKP 以制定bridge结构是有道理的。在下文中，我们回顾并比较了该领域三个有趣的发展：
- Succinct verification of consensus with zkSNARKS ( Succinct Labs )：使用单个 zk-SNARK 实现以太坊 PoS（权益证明）轻客户端。
- Bringing IBC (Inter Blockchain Communication) to Ethereum with zkSNARKS ( Electron Labs )：Cosmos SDK (Tendermint) 上的工作原型，通过单个 zk-SNARK 连接到以太坊轻客户端。
- zkbridge：Trustless Cross-chain Bridges Made Practical ( Berkeley RDI )：使用两步递归 zk-SNARK 将 Cosmos SDK 实现到以太坊轻客户端，以太坊的轻客户端到 EVM compaBerkeley RDIible 区块链（本文未涵盖）
这些项目利用 zk-SNARKS 的特性来重新定义桥梁的设计方式。以上所有假设存在一个轻客户端协议，确保节点可以同步最终区块链状态的块头。将 ZKP rollups 背后的思想应用于bridge的两个主要挑战是，首先，bridge中涉及的电路规模比 rollups 大几个数量级，其次，如何减少链上的存储和计算开销。
共识证明的简洁验证（Succinct Labs）
Succinct Labs 为以太坊 2.0权益证明共识构建了一个轻客户端，以在Gnosis和以太坊之间构建信任最小化的桥梁，它使用 zk-SNARKS（非零知识）的简洁属性来有效地验证链上的共识有效性证明。
该设置由以太坊中每 27 小时随机选择的 512 个验证器组成的同步委员会组成。这些验证者被要求在他们的周期内签署每个区块头，如果超过 2/3 的验证者签署每个区块头，则以太坊状态被视为有效状态。验证过程主要包括验证：
- 标头的 Merkle 证明
- 同步委员会中验证者的 Merkle 证明
- 用于同步委员会正确轮换的 BLS 签名
上述验证需要每 27 小时在链上存储 512 个 BLS 公钥，并且对于每个标头验证都会验证签名，这会导致 512 条椭圆曲线添加（在曲线 BLS12–381 中）和配对检查-链，这是成本高昂的。这里的核心思想是使用 zk-SNARK (Groth16) 来生成有效性证明（大小不变），并且可以在 Gnosis 上进行有效的链上验证。
使用 zk-SNARKS 的简洁性来卸载链下昂贵的验证
以太坊轻客户端在 Gnosis 链上使用 solidity 智能合约，而链下计算包括构建 circom 电路以验证验证者及其 BLS 签名，然后计算 zk-SNARK 证明。之后，区块头和证明被提交给智能合约，然后智能合约在 Gnosis 链上执行验证。计算的 SNARK 部分的电路大小和证明时间总结如下：
snark 部分的电路尺寸
优化包括使用验证器的 512 个公钥 (PK) 输入作为使用ZK 友好 Poseidon 哈希的承诺。Poseidon 哈希解决了存储开销问题并减小了电路大小。电路大小的减少如下：受信任的委员会在 27 小时后更新，之前的委员会使用 SSZ（简单序列化），它采用 SHA256 序列对新委员会进行数字签名。而不是直接在创建大型电路的 SNARK 中使用它（每个位操作需要一个门，并且在 SHA 中有大量的位操作），承诺当前 PK 的使用 Poseidon 哈希，这是一个计算导致到相应电路的 SNARK 友好表示。
底线：使用的这种桥接方法非常特定于应用程序（依赖于共识协议），并且其安全性来自 zk-SNARKs 的稳健性。此外，通过优化，它实现了低存储开销、电路复杂度降低和简洁验证，并且具有可推广性。然而，zk-SNARK 的使用降低了信任假设，这也许正是我们最终想要的。
将 IBC 引入以太坊（Electron Labs）
Electron labs 旨在从Cosmos SDK生态系统（应用程序特定区块链的框架）构建bridge，该生态系统使用 IBC（区块链间通信）在框架中定义的所有主权区块链之间进行通信。
此设置类似于前面讨论的案例，但方向相反，轻客户端（来自 cosmos SDK）需要在以太坊上的智能合约中进行验证。从实际意义上讲，在以太坊上运行来自其他区块链的轻客户端似乎具有挑战性。在 cosmos SDK 中，Tendermint轻客户端在扭曲的爱德华兹曲线 ( Ed25519 ) 上运行，这在以太坊链上不受原生支持。因此，以太坊（BN254）上 Ed25519 签名的链上验证变得低效且成本高昂。
在 Cosmos 到以太坊bridge中使用 zkSNARKS
与我们之前的讨论类似，Cosmos SDK 上的每个区块头，每个区块头由曲线 ed25519 上的大约 128 个 EdDSA 签名组成，由一组验证者签名（验证一个区块需要 32 个高风险签名）。签名的验证会生成大型电路，这是一个重要的计算组件。因此，基本问题是如何在以太坊链上高效且廉价地验证来自 cosmos SDK 中任何区块链的 ed25519 签名。解决方案是构建一个 zkSNARK，它在链下生成签名有效性证明，并且只在以太坊链上验证证明本身。
circom 库支持曲线 BN128、BLS12–381 和 Ed448-Goldilocks，因此，为了对素数 p=2^(255)-19 的 ed25519 曲线执行模运算，将场元素的表示分解为更小的 85 位整数 (85*3=255) 用于高效的模块化算法。circom 生成的电路是 ed25519 签名验证电路的 R1CS 表示，由椭圆曲线点加法/加倍和上述定义的模块化算法组成。签名验证的电路是使用 circom 库构建的，每个签名验证导致大约 2M 的约束。
在见证计算之后，用于 ed25519 签名验证的 Groth16 证明由Rapidsnark 库生成。与 BLS 签名不同，ed25519 曲线签名不可聚合，因此无法为聚合签名生成单个 zk-SNARK 证明。相反，签名是分批验证的，并且可以观察到证明时间与批次中的签名数量呈线性关系。
因此，如果想要减少一批中的签名数量，它会缩短证明时间（减少延迟），但会增加成本（gas 费用），因为每批生成的证明数量增加。
底线：这种bridge方法也特定于它们的应用程序，并且享有 zk-SNARK 证明的稳健性的安全级别。特别是它验证了以太坊上 Tendermint 轻客户端的 ed25519 签名，而没有引入任何新的信任假设。场外模块化算法是对链上验证计算有价值的优化。与 Succinct Labs 方法类似的一个特定技术问题是延迟。cosmos SDK 的出块速度约为 7 秒，为了跟上这个速度，证明者时间应该显着降低。Electronlabs提出了用多台机器并行计算，以与块生产率相同的速度生成证明，并进行递归以生成单个 zk-Snark 证明。
zkbridge（伯克利 RDI）
与其他两个行业主导的 ZKP 桥结构不同，zkbridge 是一个可以在其上构建多个应用程序的框架。这个想法类似于前面讨论的两种方法，并且需要在两条链上都有一个轻型客户端和智能合约来跟踪摘要，对应于任何一方的最新状态。桥的核心组件是区块头中继网络、更新程序合约和应用程序特定合约（发送方：SC1，接收方：SC2）。
桥组件是灰色阴影区域。
区块头中继网络由中继节点网络组成，中继节点监听bridge链上的状态变化，并从区块中的完整节点检索区块头。bridge中继节点的主要功能是生成一个 ZKP，证明来自一条链的块头的正确性，并将其中继到另一条链上的更新程序合约。更新者合约验证并接受或拒绝来自中继网络中节点的证明。行业主导的方法与 zkbridge 之间的主要区别在于，信任假设基本上被简化为中继网络中存在一个诚实节点，并且 zk-SNARK 是可靠的。
这种结构的一个关键创新是并行使用zkSNARK：Virgo 证明者( deVirgo )，它具有简洁的验证/证明大小并且不需要可信设置。其动机是用于验证 N 个签名的电路基本上由 N 个相同子电路的副本组成，称为数据并行电路，每个子电路与其余子电路互斥。例如，在前面部分讨论的 ed25519 签名验证中就是这种情况。
Virgo 证明者的核心组件基于GKR 协议的零知识扩展，该协议为分层电路中的每个子电路和多项式承诺方案运行总和校验参数。deVirgo 泛化本质上是在一组中继节点上运行一个 Virgo 证明者，并通过将证明和多项式承诺聚合到一个主节点中来避免证明大小的线性增长。
在 deVirgo 证明器中证明 ed25519 签名的电路尺寸
对于验证 100 个签名和大约 10M 门的电路，证明大小为 210KB（与 Virgo 证明者相同）。Zkbridge 使用两步递归。第一步，生成 deVirgo 证明，然后使用 Groth16 证明器对其进行压缩。Groth16 验证器生成 deVirgo 电路执行的完整性证明。递归的主要目的是实现简洁（证明大小）并降低验证气体成本。
中继网络然后将 Groth16 证明提交给可以在链上验证它的更新程序合约。deVirgo 证明系统具有后量子抗性，因为它仅依赖于抗碰撞哈希函数，主要的计算瓶颈是大型电路中的数论变换 (NTT)。似乎没有提及的一件事是中继网络计算将遭受与 MPC 相同的通信复杂性，这也会影响证明者时间。对于中继网络中的 N 台机器，GKR 多层和校验协议的通信复杂度为 O(N log_2(gates per layer))。即使是32个签名的情况，在中继网络中有32台机器，这导致网络中的通信轮数比较多，
前面讨论的cosmos SDK-Ethereum light client验证ed25519签名的问题是使用上述方法解决的。bridge由一个中继网络组成，该网络获取 Cosmos 区块头并生成用于分布式证明生成的 deVirgo 证明。随后，由Electron-labs设计的优化签名验证电路（用于场外算法）的Gnark改编在递归的第二步生成 Groth16 证明。
ed25519 签名的证明时间 : RV: recursive Verifier
更新合约在以太坊上以 Solidity 实现，并跟踪 Cosmos 区块头和中继网络的 Groth16 证明。验证成本恒定 <230K gas，这是由于 Groth16 证明的恒定大小。此外，可以批量验证B个连续的区块头，并为B个头生成单一证明。然而，增加批次的大小也会增加证明者的时间，但由于链上的验证负担较小，因此降低了气体成本。和以前一样，硬件加速也可能会进一步改进 Gnark 证明器。
底线： zkbridge 是一个用于在桥上构建应用程序的框架。桥接设计使用中继网络来生成 zkp，并且具有最少的信任假设。只要可以克服中继网络中类似 MPC 的通信复杂性，就可以使用任何可并行化的 ZK 证明器。更具体地说，撇开 deVirgo 中继网络的 MPC 复杂性不谈，NTT 是中继节点的各个 Virgo 证明者组件中的瓶颈。
快速比较：
下面我们对本文讨论的三种桥梁结构的各种特征进行快速比较。
总之，使用 ZKP 设计bridge解决了去中心化和安全性问题，但由于电路规模大而造成计算瓶颈。
使用硬件加速可以改善计算开销问题，特别是使用 SNARKS 以及提交公共数据的技巧可以减少存储开销。由于大部分桥接工作都在证明数据并行电路，因此像 deVirgo 这样的 ZKP 并行化推广是有价值的研究方向。
此外，由于多链宇宙中的区块链是根据应用在广泛的领域（场、曲线）上定义的，因此场内和场外算法的优化是最低级别的重要构建块。通过 MPC 生成证明的并行性在通信复杂性方面带来了自身的瓶颈，这些瓶颈至今仍是悬而未决的问题。
为什么多链宇宙是碎片化的？
区块链生态系统的现状类似于泡沫宇宙（碎片化的多链宇宙）的异构分布，每个宇宙都有自己的共识机制、设计、应用和用例规则。截至撰写本文时，已有 100 多个L1区块链协议，用户数量不断增加，并且随着区块链用例的增加，这一数字可能还会增长。
区块链三难困境指出，很难同时实现理想区块链实现的三个基石：
- 权力下放
- 可扩展性
- 安全
区块链三难困境
根据用例的不同，除了吞吐量和成本之外，三个基石的重要性顺序可能会有所不同。三难困境中的不同权衡可以想象为三角形的变形，同时保持面积固定。自然地，当两个角相互接近时，第三个角移动得更远。这些权衡导致了区块链的不同概念化，从而使开发人员能够自由地为合适的应用程序选择不同的平台。这导致了支离破碎的多链宇宙，其中每个区块链基本上都是孤立运行的，完全没有注意到其他区块链的存在。
多链宇宙中的链间通信，通常称为互操作层，是充当不同区块链之间bridge的基础设施。bridge使用户能够在链之间传递消息，包括数字资产（加密货币）、链状态、合同请求、证明等。简而言之，跨链bridge“整理”了支离破碎的多链宇宙。因此，有很多研究和开发都集中在构建多链宇宙中的这个关键组件上。截至撰写本文时，有几个活跃的跨链bridge项目。
搭建bridge
bridge是一种双向通信协议，它向另一条链 C2 中的应用程序证明一条链 C1 中事件的发生，反之亦然。为简单起见，我们使用术语，源链 (C1) 和目标链 (C2)，尽管它们可以互换。C1 上的状态更改必须在 C2 上“链上”验证。这通常由轻量级客户端完成：C2 上的合约跟踪 C1 上的一组区块头，并使用与从源链提交的根相对应的 Merkle 证明来验证它们。一般来说，C1和C2可以在不同的域中运行，验证操作需要域外运算。除了不断增加的标头列表之外，客户端还需要在新标头出现时对其进行存储和验证。这会导致显着的计算和存储开销，并且通常效率低下。为了绕过这个问题，许多桥梁建设采用了更集中的方法。
Achilles heel：一种轻型客户端协议，带有一小组受信任的验证器来签署状态更改。
这通常是在资金转移的情况下，其中大量信任假设被放置在通常由少数受信任方组成的集中bridge实体上。尽管这违背了区块链的基本原则，但它带来了与审查和安全相关的问题。
区块链历史上一些最大的黑客攻击发生在桥梁上
安全漏洞的主要原因是由于网桥充当集中式存储单元的方式。大多数现有的桥梁（为了流动性）通过 Lock-Mint-Burn-Release 机制运行。典型的用户通过将链 C1 上的资金发送到将这些资金“锁定”到合约中的bridge协议来与桥交互，即这些资金在 C1 中无法使用。然后，该桥允许用户在另一个区块链 C2 中铸造等价资金。一旦用户花费了一些资金，并希望将剩余资金返还给C1，他就“销毁”了C2中的资金，bridge实体对此进行了验证，并“释放”了C1中的剩余资金。在这样的链间bridge中，大量资金可能存放在桥中，桥的安全性依赖于少数可信方，使其成为攻击的活跃目标。
总而言之，建造bridge的主要技术挑战是
- 低计算开销（高效处理跨域数据，场外算法）。
- 低存储开销。（简洁）
- 安全/无信任（Soundness）
