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