我和来自 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 协议）。或者，如果来源链使用 协议或“最长链”式的 协议（如 Ouroboros、 2.0 LMD Ghost 等），则使用相关的规则检查最长链。
例子： Rainbow 桥接（忽略与 NEAR 签名机制验证过程的复杂性相关的 Optimistic 构成部分），Polygon 的 PoS 桥接（检查 Heimdall 链的共识）以及 IBC（验证另一条 Cosmos 链的签名）。
描述：使用外部验证者作为事实来源的桥接，即形成一个独立委员会的验证者们，而不是来源链和目标链上的验证者。这取决于这些验证者所采用的实现，他们可能会使用 MultiSig （多签）、运行共识算法（通常是来自提议和投票的一类的算法）、使用 Threshold Signature 机制（TSS，门限签名机制）或 SGX 等……无论它们使用什么技术，都属于这种验证方式。
例子：Wormmhole、、Axelar、DeBridge、Synapse、Stargate。
描述：具有挑战期（challenge period，译者注：指其他验证者发现桥接消息无效时，可以对其有效性进行挑战的时间段）的桥接。
这类验证方式中的诚实一方会在此期间内避免纳入欺诈信息。然而，这里有几个关键参数需要考虑：
例子：Hop Protocol、Connext Amarok、Across、Nomad Token Bridge。
描述：有一种混合上述各种验证方式的结构。
除了真的跨链发送资产以外，还有另一种的方法：跨链兑换（swap），只通过易手而不用跨链移动资产，就能进行跨链兑换。（译者注：易手即一方资产成为另一方所有，即资产所有者发生更换。）
举个简单的例子：A 链上的 Alice 想要将资产转至 B 链。Bob（流动性提供者，LP）在 B 链上已经有了一样价值的资产，他用自己在 B 链上的这笔资产为 Alice 在 A 链上的余额提供兑换服务，并收取服务费。最终，Alice 会获得 B 链上的那笔资产，Bob 则能获得 A 链上的那笔资产 服务费。
这部分仅描述了“兑换”协议的安全性，即 LP 在接受了你在来源链上的存款后，有多大可能会携款潜逃。这些兑换资产拥有铸造出它们的消息传递型桥接的安全性。
也有一些其他兑换资产的方式：
免责声明: 文章源于会员发布，不作为任何投资建议
如有侵权请联系我们删除，本文链接：https://www.vrvkongtiao.com/zixun/98799.html
微信扫一扫 
