L2 桥接风险架构：如何评估跨链桥安全性？

撰文：bartek.eth

编译：ETH 中文站

图片来源：由无界版图 AI工具生成

我和来自 Socket 的 Vaibhav Chellani 想要提议一个用来评估不同桥接架构安全概况的风险架构。

与各种 L2 的风险框架一样，我们的总目标在于，能够快速将某一解决方案「分类」到具有相似特征的某特定解决方案类别中，同时可以足够细致地向用户呈现他们使用这些桥接时需要接受的安全假设有哪些。

我们主要关注在以太坊和其他链之间的桥接，因为我们即将在 l2beat.com 上介绍这些 ( 译者注：目前桥接一栏已上线 )，但是，关于这些解决方案安全性的基本推理也适用于任何链与另一条链的桥接。此刻，我们正在寻找更广泛社区对这个提议框架的反馈。

桥接类型

对于终端用户来说，资产桥接是指从来源链（source chain）接收某种资产的存款，并将这笔资产打给处于目标链（destination chain）上的用户。

比如，典型的桥接流程就是，Alice 将资金转至 A 链的桥接合约，而后 Alice 在 B 链上收到来自桥接的资金。

广泛来说，这种流程有两种发生方式：

消息传递型桥接的安全性

在这一部分，我们会试着阐释这些被多个桥接协议使用的验证跨链消息的不同方式。如上图所示，代币桥接会利用消息传递型桥接的安全性。

轻客户端验证状态有效性

描述：在目标链上验证来源链状态转换有效性的桥接。该验证过程通过零知识证明实现 ( 状态转换过程伴随着一个 zk 证明的生成 ) 或是欺诈证明系统完成 ( 允许独立的验证者就新状态根的有效性提出争议）。

例子：所有 Rollup 都算是这里的例子，L1 会通过 FraudProof（欺诈证明）或 ValidityProof（有效性证明）验证 L2 的状态转换。

轻客户端验证共识

描述：在目标链上验证来源链共识的桥接。这取决于来源链所使用的共识机制，通常包括对当前验证者委员会的 quorum 签名的检查，如果其来源链使用的是 PBFT 式的提议和投票（propose-and-vote）共识协议（如 Tendermint、HotStuff、Casper FFG 协议）。或者，如果来源链使用 PoW 协议或“最长链”式的 PoS 协议（如 Ouroboros、ETH 2.0 LMD Ghost 等），则使用相关的分叉规则检查最长链。

例子：NEAR Rainbow 桥接（忽略与 NEAR 签名机制验证过程的复杂性相关的 Optimistic 构成部分），Polygon 的 PoS 桥接（检查 Heimdall 链的共识）以及 Cosmos IBC（验证另一条 Cosmos 链的签名）。

外部验证者集

描述：使用外部验证者作为事实来源的桥接，即形成一个独立委员会的验证者们，而不是来源链和目标链上的验证者。这取决于这些验证者所采用的实现，他们可能会使用 MultiSig （多签）、运行共识算法（通常是来自提议和投票的一类的算法）、使用 Threshold Signature 机制（TSS，门限签名机制）或 SGX 等……无论它们使用什么技术，都属于这种验证方式。

例子：Wormmhole、Multichain、Axelar、DeBridge、Synapse、Stargate。

乐观式验证

描述：具有挑战期（challenge period，译者注：指其他验证者发现桥接消息无效时，可以对其有效性进行挑战的时间段）的桥接。

这类验证方式中的诚实一方会在此期间内避免纳入欺诈信息。然而，这里有几个关键参数需要考虑：

1. 挑战期时长：越长越好
2. Watcher 集规模：无需许可 > 需要许可

例子：Hop Protocol、Connext Amarok、Across、Nomad Token Bridge。

混合验证方式

描述：有一种混合以上各种验证方式的结构。

流动性网络的安全性

除了真的跨链发送资产以外，还有另一种的方法：跨链兑换（swap），只通过易手而不用跨链移动资产，就能进行跨链兑换。（译者注：易手即一方资产成为另一方所有，即资产所有者发生更换。）