bridge为双向通讯协议,用于向目标链C2上某应用 证明 在源链C1上发生了某事件,或 用于向目标链C1上某应用 证明 在源链C2上发生了某事件。链之间传输信息可为:
源链C1上的state change可在目标链C2上进行链上验证,通常是以合约形式实现对方链的light client:C2上的合约持续跟踪C1链的区块头,以Merkle proof来验证源链提交的root。
通常C1、C2采用不同的field和曲线,验证操作需要out of field arithmetic。此外,随着区块头的持续增加,client需要存储并验证新的区块头,这将导致大量的计算和存储开销,且通常效率低下。为了绕过该问题,很多bridge采用了更集中的方式来构建:
上图这样的light client protocol构建存在致命的缺陷:一小组trusted validators来对state changes进行签名。其信任假设为信任中心化的bridging entity,通常为一小撮trusted parties,这与区块链的基础原则相违背,会带来censorship和security问题。
尽管桥很有用,但搭建风险也很大。区块链历史上一些最昂贵的Hack仅针对桥。根据Vulnerabilities in Cross-chain Bridge Protocols Emerge as Top Security Risk,过去一年来,69%的资金丢失源于对bridge的攻击,损失达数十亿美金:
根据 BlueHat IL 2022 - Niv Yehezkel - A primer on cross-chain bridges and how to break one 可知,这样的安全弱点的根本原因在于bridge充当了中心化的存储单元。大多数现有bridge(for liquidity)采用Lock-Mint-Burn-Release机制。经典的逻辑为:用户发送资金到C1链上的bridge合约以“lock”资金,即这些资金在C1中不再可用;然后bridge允许用户在C2链上mint出等量的资金;用户使用了部分资金之后,想要将剩余资金退回到C1链,可“burn” C2链上资金,一旦bridging entity验证通过后,可在C1链上“release”剩余的资金。这样的链间bridge,会有大量的资金待着bridge中,而其安全性仅依赖于少量的trusted parties,使其成为主动攻击的目标。
构建bridge的主要技术难点在于:
本文重点关注基于零知识证明(Zero Knowledge Proofs,ZKP)所构建实现的桥,主要对比了:
总之,使用ZKP设计的bridge解决了去中心化和安全性问题,但由于large circuit size,其引入了计算瓶颈问题。计算开销问题可通过以下手段改进:
由于bridge work的大部分工作是proving data-parallel circuit,使用类似deVirgo这样的可并行化ZKP方案是一个值得研究的方案。
此外,多链宇宙中的链采用了不同的field和curve,从最底层来说,对field arithmetic进行优化是关键基石。通过MPC来实现proof generation的并行化,将引入MPC本身存在的communication complexity瓶颈问题,这也是一个未决问题。
近年来,ZKP在rollups中的应用有了长足进展,ZKP的soundness属性支持安全、去中心化应用。这也意味着,ZKP可探索用于构建bridge,目前在该领域主要有3大有趣的开发方向:
以上项目借助zk-SNARKs的属性,重新定义了bridge的设计思想。以上所有方案,都假定了,存在某轻节点协议,使得节点可同步固化的区块链状态对应的区块头。
借鉴ZKP rollup技术 到 ZKP bridge,主要存在2大挑战:
Succinct Labs的Bridge方案为:Succinct Verification of Proof of Consensus,利用了zk-SNARK的succinct属性(而不是Zero Knowledge属性),来在链上验证consensus validity proofs。目前已在Gnosis链与以太坊链之间构建了a trust minimized bridge,具体见:
以太坊每27小时需随机选出512个validators组成sync committee。这些被选中的validators需在该27小时期间为每个区块头签名,若某区块头获得超过2/3 validators的签名,则认为其状态为有效状态。验证过程包含了:
以上验证要求每27小时在链上存储512个BLS公钥,验证每个区块头时需验证其签名,从而在链上会有基于BLS12-381曲线的512次Elliptic curve additions 和 1次pairing check,相应的开销是高昂难以承受的。Succinct Labs Bridge方案的核心思想为:
以太坊轻节点使用Gnosis链上的某solidity合约,而链下计算包含:
然后,区块头和相应的proof会提交到该智能合约,该合约会在Gnosis链上验证相应的区块头及其proof。
SNARK部分的circuit size和proving time总结为:
优化点包括:
Succinct Labs的Bridge方案的特点在于:
Electron Labs致力于使用IBC(Inter-Blockchain Communication)构建从Cosmos SDK生态 到 所有自治链的 bridge。
不过,不同于Succinct Labs的Bridge方案,Electron Labs的Bridge方案需在以太坊合约内验证某(Cosmos SDK)轻节点。实际上,在以太坊上运行其它链的轻节点看起来是充满挑战的。
在Cosmos SDK中,其Tendermint轻节点是运行在twisted Edwards curve(Ed25519)之上的,而以太坊链上并不原生支持Ed25519曲线。因此,在以太坊(BN254)链上验证Ed25519签名的效率不高且开销巨大。
Cosmos SDK的每个区块头都包含了约128个EdDSAq签名(基于Ed25519曲线),这些签名由一组validators签署(验证一个区块需要有32个high stake签名)。验证这些签名将生成large circuits——这将是相当大的计算组件。基本问题就在于,如何在以太坊链上高效验证来自其它链的ed25519签名。解决方案为,在链下生成signature validity proof,然后在以太坊链上仅验证该proof本身。
circom库支持BN128/BLS12-381/Ed448-Goldilocks曲线,而ed25519的base field为 p = 2 255 − 19 p=2^{255}-19 p=2255−19,为支持ed25519曲线的模运算,需将ed25519的单个field element以3个85 bit整数来表示,详细见:
circom生成的为Ed25519 signature verification circuit的R1CS表示,包含了上面定义的Elliptic curve point additions/doublings模运算。具体见:
借助circom构建的Ed25519 signature verification circuit对应为 每个验签约200万个约束。
witness computation之后,借助https://github.com/iden3/rapidsnark Rapidsnark库来为ed25519 signature verification生成Groth16 proof。由于ed25519 curve signatures不支持aggregation,因此,无法像BLS签名那样为aggregated signatures生成a single SNARK proof。不过,ed25519签名支持verified in batches,其proof-time与batch内的签名数量呈线性关系。
因此,若减少batch内的签名数量,可降低proof time(降低延迟),但由于会增加为每个batch生成的proof数量,会增加开销(gas费)。
Electron Labs Bridge方案的特点在于:
不同于以上2种industry-led ZKP bridge方案,zkbridge可基于多个应用来构建。其思想与前2种方案类似,在2条链上需要一个轻节点和合约来跟踪对应对方链的最新状态的digest。bridge的核心组件为:
block header relay network由一组relay nodes组成,这些relay nodes会监听所桥接链的状态改变,并从全节点中获取相应的block headers。
bridge中relay node的主要功能为:
Berkley RDI Bridge方案zkbridge的关键创新在于:
并行使用Virgo prover zkSNARK算法,具有succinct verification/proof size且不需要trusted setup,详细见论文:
动机在于:验证N个签名的circuit 本质上是包含了 N份完全相同的sub-circuits,名为data-parallel circuit,每个sub-circuit是相互排斥的。适于上面的ed25519验签场景。
Virgo prover是基于GKR protocol的zero knowledge扩展,其为layered circuit中的每个sub-circuit运行sum check arguments 和 a polynomial commitment scheme。deVirgo在一组relay nodes上运行a Virgo prover,避免the linear growth of the proof size by aggregating the proofs and polynomial commitments into a master node。以ed25519签名为例,相应的circuit size为:
对于验证100个签名的circuit,其有约1千万个gates,proof size为210KB(与Virgo prover相同)。zkbridge采用2-step recursion:
采用recursion的各奔目的是为了实现:
relay network会将Groth16 proof提交到updater contract进行链上验证。
deVirgo proof system为抗量子攻击的,因其仅依赖抗碰撞哈希函数,主要的计算瓶颈在于大size的circuit中的Number Theoretic Transforms(NTT)。
同时,zkbridge的relay network计算将存在与MPC一样的communication complexity问题,这同样会影响prover time。
GKR multilayered sum-check protocol的communication complexity为O(N log_2(gates per layer)),其中N为relay network中的机器数。以32个签名,32台机器为例,relay network中的communication轮数将相对较大,从而可能抵消分布式计算所带来的性能提升。
zkbridge包含一个relay network,负责fetch Cosmos区块头,并为分布式proof generation生成一个deVirgo proof。
然后,https://github.com/ConsenSys/gnark 的改编版(使用Electron-labs的https://github.com/Electron-Labs/ed25519-circom 中的优化signature verification circuit),用于以上第二步的recursion Groth16 proof生成。
以太坊端的updater contract以Solidity实现,持续跟踪Cosmos区块头以及relay network的Groth16 proof。由于Groth16 proof为constant size,相应的链上验证开销为<230K gas的常量值。未来,可能可批量验证B各连续的区块头,并为这B个区块头生成一个proof。但是,随着batch size的增加,prover time也将增加,不过由于减少了链上的验证压力,gas开销将随之减少。硬件加速可进一步改进Gnark prover。
zkBridge的特点在于:
根据An overview of the layer 1 blockchain ecosystem 可知,目前有多于100个Layer 1区块链协议,这些链具有其自身的共识机制、设计、应用、用户场景。
根据V神2021年博客 Why sharding is great: demystifying the technical properties 可知:
区块链协议存在不可能三角问题:
多链宇宙中的跨链通信,通常称为互操作层,作为不同链之间的bridge基础设施。bridge会是碎片化的多链宇宙 去碎片化,目前有很多跨链bridge项目,详细可参看:
[1] Ingonyama团队2022年10月博客 Bridging the Multichain Universe with Zero Knowledge Proofs