跨链安全模型的比较

在 第一部分 中，我们研究了一些理解跨链协议和评估其安全性的框架。在这篇文章中，我们将把这些想法应用于 IBC、Nomad、LayerZero 和 Axelar。加在一起，这些覆盖了一个不错的跨链协议类别。欢迎提出请求以添加更多内容。

IBC（跨区块链通信协议）

Github Discord Twitter

IBC 是跨链安全性的金标准。它通过将现有区块链转变为跨链协议本身，使其具备“读取”能力。理论上，IBC 适用于大多数即时最终性的链，但通常需要巨大的工程工作量进行集成。IBC 是 Cosmos SDK 的一部分，Celo 和 Polkadot 也在为他们的链构建 IBC 解决方案。

基础层 = 将一个链的共识层与另一链连接的轻客户端模块。仅适用于即时最终性链。

认证 = 两个链通过它们的轻客户端/IBC 模块进行握手。这些模块可以验证跨链消息。

运输 = 中继节点在区块链之间打开并维护一对一的通道。IBC 模块与智能合约虚拟机或其他模块之间的路由在区块链协议中写入，并依赖于跨链消息的内容。

接口 = 由协议定义的 IBC 分组语义。

安全性

通过 IBC 传输的消息承载着它们连接的基本链的安全性，毫不逊色。尤其在实践中，有轻微的活跃性保证降低。

基础层评估：

IBC 允许任何两个兼容链互相充当去中心化读取预言机，从而无需中介共识环境进行跨链通信。因此，IBC 被誉为最无信任的跨链解决方案。

轻客户端允许目标链的节点参与源链的共识，因此承载相似的安全性。如果基础层没有轻客户端，IBC 则没有替代方案。IBC 毫不妥协，因此其解决方案仅限于兼容链。

恶意攻击：

攻击仅限于 IBC 模块中的缺陷及这些模块与其他模块和共识的集成方式。

DDoS 或活跃攻击：

IBC 继承了底层网络的安全性和活跃性特征。活跃性通常很好，因为 IBC 与即时最终性的权益证明链一起工作，（DDoS 或有针对性的停机攻击不会危及安全性）。

目前，对于中继节点，经济上合乎理性的做法是社会化协调，因此在任何时刻只有一个中继节点为 IBC 通道提供服务。这导致活跃性有所降低，因为如果一个中继节点失败或被攻击，我们依赖社会协调让另一个中继节点接替它。然而，活跃性从未真正丧失，因为中继是开放且无需许可的。

失去活跃性的节点数量：

1/3 的注册验证人数量在连接链之一中。在此时，验证者停止生成区块。

节点集是否无需许可？

是的

Axelar 网络

Github Discord Twitter

Axelar 是一种无许可的权益证明协议，尽可能利用 IBC，但具有与 IBC 不兼容的链在智能合约层或直接在协议层进行通信的附加通用性。

这通常意味着轻客户端/全节点用于跨链读取，多方加密用于写入。Axelar 应用 Cosmos 的区块链互联网愿景，并将其扩展到任何共识类型。

基础：协议或应用层。在源链和目标链上安装的网关，由一个无需许可的验证者集控制。这些网关可以以智能合约的形式存在于适配链上，或通过多方加密等与其他协议功能交互，例如对于比特币，也采用相关的本地跨链协议，例如 IBC。

认证：无需许可的 PoS 验证者集，具有：

• 读取：每个验证者会通过轻客户端或全节点检查消息。
• 写入：由 Axelar 网络共同签署的消息在目标链上的一个“网关”（智能合约或简单账账号）进行验证。

IBC 认证支持是该链的本地功能，但仅适用于支持 IBC 的连接链。

运输：集线器与辐射模型，以线性增加复杂性而不是平方。路由在协议层管理。无信任中继节点将消息从源 → Axelar 和从 Axelar → 目标进行传递。

接口：由协议定义；网关包括用于发送/接收、代币转账等的接口。

安全性

轻客户端、全节点和 TSS/多重签名由一个无需许可的验证者集控制，提供强大的读取和写入安全性。依我看，这是继 IBC 之后最安全和去中心化的模型，但可以连接到任何链。

认证层评估：

无需许可的验证者集是 Axelar 的杀手级特性，使其在其他跨链模型中脱颖而出。工程设计出无需许可的验证者的添加和移除、惩罚以及顺利更新阈值密码私钥共享和轻客户端的同时进行是非常困难的。

秉承 Cosmos 的精神，该系统可以根据连接的特定生态系统的需求进行“定制”。

恶意攻击：

作为一个 Cosmos 链，Axelar 利用 Tendermint 和 Cosmos SDK 的现实世界战斗测试，并继承它们大部分的安全特性。

需要破坏 ⅔ 的验证者集才会破坏其安全性。

我对 Cosmos 的 Interchain Security 感到兴奋，因为它能够解决旧跨链经济安全问题，即将质押的代币的价值与网络保护的资产的价值进行扩展。Axelar 链可以利用多个网络的经济安全（包括某些连接的网络本身）来保护其自身的安全性。

我也很想看看关于验证者轮换的复杂性在未来是否会造成问题，因为该协议需要在验证者加入或离开时更新私钥分享和全节点。

Axelar 上的其他攻击是 IBC 中不可能发生的，例如对阈值加密方案的攻击，或对 Axelar PoS 网络本身的攻击。

DDoS 或活跃攻击：

破坏 ⅓–⅔ 的验证者将破坏活跃性，但不会破坏安全性。这意味着系统停止，但没有人会失去资金。

所有的中继都是完全开放的，并与安全性解耦，使得系统的活跃性与认证层和基础层（源、Axelar 和目标的验证者集）的活跃性保持一致。没有引入额外的活跃性假设。

失去活跃性的节点数量：

⅓ 的 Axelar 节点失去活跃性。中继是无需许可的，并且正在构建一个工具，以允许用户使用他们的网络浏览器自己中继消息。

多方加密的阈值通过治理进行调整。例如，对于 Avalanche，所有验证者必须签署每条跨链消息，或者 70% 的验证者。投票可以按股份加权或按数量加权。

节点集是否无需许可？

是的，通过委托的权益证明。

Nomad

Github Discord Twitter

Nomad 是一种乐观跨链协议，在其基础链上发布写预言机“更新”交易。这些更新由“观察者”验证，观察者被给予 30 分钟的时间来警告欺诈性更新。可以将其视为一种跨链汇总。

Nomad：

基础层 = 像队列中跨链转移消息一样。在源链上，通过优化时间窗口后将此数据结构复制到所有目标链。至今，它们必须始终利用像 EVM 这样的虚拟机。

认证 = 更新者、观察者和中继节点维护乐观共识，该共识已在源链上的智能合约上得到确认。消息如果在发布后的 30 分钟内没有观察者拒绝更新，则视为有效，即乐观共识。

运输 = 链之间的一对一连接。所有维护 Nomad 协议的各方协同工作以打开和维护新的连接。“处理器”监控源链上的认证消息并在目标链上执行它们。

接口 = Nomad 在智能合约层运作。每个应用程序建立自己的消息协议，并部署“路由”合约。

安全性

在乐观协议上可能发生几次攻击。它们主要围绕活跃性。

认证层评估：

由于提供了特别短的证明期为 30 分钟（相比较Arbitrum/Optimism 的 7 天），Nomad 更易受到这些攻击。Nomad 正在研究一种经济激励节点解决方案，以纠正其中一些活跃性漏洞。我奇怪的是，如果你打算依靠一组节点，为何不从一开始就使用 PoS 验证者网络，但让生态系统拥有多个创新树是件好事！乐观协议应该在栈的某一层级中在跨链上下文中有用。

我注意到在 Nomad 的材料中，他们将自己与“外部验证”跨链模型区分开。我不同意这一点。更新者、观察者、中继节点和处理器正在实施的乐观协议是一个外部过程，每个连接链之外的 IBC 是这个列表中唯一可以声称不被“外部验证”的选项。Nomad 确实利用在两个基础链上的“内部验证”智能合约，但是在提交交易到这些合约的节点集引入了额外的信任假设。

45 分钟的交易时间对我来说似乎非常长，特别是如果我们想建立一个高资本效率的金融体系。Connext 已与 Nomad 合作，利用中心化做市商提供更快的代币转账执行，但我更喜欢更快的去中心化解决方案 — 特别是在流动性紧张或类似最近与 Terra 看到的协调攻击期间。

恶意攻击：

在目标链上可能发生欺诈。如果一个恶敌（当前为许可制）更新者能够在目标链上发布一个包含恶性交易的副本更新而无法被伪造。这种欺诈的可能性是在降低Gas成本的情况下达成的妥协，Nomad 正在研发防护措施。

如果上述攻击发生，跨链应用程序开发人员选举的观察者将有时间（如果早早被捕，则为 30 分钟）来取消从 Nomad 到该特定应用程序的所有消息，从而阻止这些恶意更新的攻击消息的执行。这听起来有点像应用程序开发人员需要为用 Nomad 构建的每个跨链应用程序建立一个中心化的关闭开关。这听起来有点审查，但我可能错了。我还想知道 DDoS 等攻击是否会阻止观察者提供安全性。

Nomad 的协议目前仅在 EVM 链上运作，从中期来看，必须通过像 CosmWasm 或 Substrate Pallet 这样的虚拟机上的智能合约之外运行。这意味着它无法通过 IBC 连接到 cosmos 链，或通过 XCM 连接到波卡平行链。最近的虚拟机存在一些安全和可预测性问题，类似的问题导致了 Wormhole 黑客事件。

DDoS 或活跃攻击：

乐观协议对审查相当脆弱，即恶意观察者可以将有效更新标记为欺诈，从而阻止它进行交易。这称为“折磨”。Nomad 目前通过使观察者可信来解决此问题。Nomad 已经指出（而我倾向于同意）在其共识模型中，观察者单独永远不能造成安全隐患，只能 导致活跃性问题。

也就是说，在 Nomad 中，活跃性问题会破坏安全性。即攻击者可以利用 DDoS 或控制这个可信观察者集作为推动攻击通过系统的方法。这种活跃性与安全性之间的交集通常是禁忌的。

一个恶意更新者可以在网络崩溃、更新或失败之前发布一个欺诈更新，然后一旦网络在 31 分钟后再次上线，该更新将在目标链上被视为有效。实际上，观察者没有机会标记该消息。对此的修复正在开发中，其中使用区块高度进行调整，请参阅 此问题。区块高度对于像工作量证明这样的最长链共识协议来说相对不够稳定，但在我看来似乎是比区块时间更好的选择。

失去活跃性的节点数量：

理论上仅 1 个：更新者。更新者可能是一个去中心化网络，但在这种情况下，为什么不从一开始就使用 PoS 网络呢？

一个被破坏的观察者可以通过折磨打破活跃性。

节点集是否无需许可？

许可的更新者，许可的观察者。Nomad 正在研究一种用于无许可更新者的模型。

Layer Zero

Github Discord Twitter

最终，Layer Zero 是跨链消息的一种 2/2 多重签名，底层有一系列的应用层软件以辅助开发人员建立跨链应用。

我将 LayerZero 主要视为基础层。它是认证层不可知的。尽管在市场宣传材料中他们声称自己超越了他们的实际情况，但协议本身很好地高亮显示了认证栈中特定部分，以简单的智能合约语言表述。其他跨链模型中的逻辑深藏于基础工程之中。

基础 = LayerZero 指定的应用层软件。

认证 = 未声明：选定的 oracle 和中继节点之间的 2/2 多重签名。块头（1）和交易证明 + 消息（2）验证。应用程序开发人员选择两个方来处理认证（比如 1. Chainlink 和 2. 美国银行 :p）。

运输 = 未声明：由选定的认证层处理。基于选择的可信/无信任。

接口 = 消息格式由源链和目标链上的端点智能合约定义。

安全性

LayerZero 并不声明运输层或认证层，它只是基本层和消息接口。被选定的认证层 —— “Oracle”和“Relayer”—— 背后的一个与和关系，即一个 2 的 2 多重签名。因此，安全性和活跃性特征由此派生。

认证层评估：

推荐的认证层包括一个去中心化的 oracle，该 oracle 签署一个头部，以及一个“中继节点”提交交易 + 证明。LayerZero 表示（但并不坚持）使用 ChainLink 作为 oracle，但 ChainLink 已经宣布了一个竞争产品。LayerZero 向用户/开发者敞开了选择他们的中继节点，或自己操作的余地。

恶意攻击：

对 LayerZero 的攻击依赖于所选定 Oracle 和 Relayer 的安全性。也就是说，以下是对 LayerZero 所使用的 2 的 2 多重签名与权益证明进行比较的分析：

如果在 N 个 oracle 节点上存在 51% 的安全假设，则总体安全假设声称为，若想破坏系统，敌手必须破坏 (51% * N) && (1) — 即（单个）“Relayer”。如果敌手能腐蚀 51% 的 N节点，那他就可以最高腐蚀 (51%+1) 的节点，特别是他有选项运行自己的 +1。所以，作为消息中继的“1”节点并不会提供更多的经济安全性。相反，它引入了较差的活跃性特征，因为如果其中一个节点被破坏，整个系统将失去活跃性。将 2/2 多重签名更改为 1/1 并增强 oracle 的安全性，更多地引入一个额外的节点是更好的做法。我们知道，权益证明可以提供比多签名更好的安全性和活跃性（否则所有这些区块链将简单运行于简单的多签名下！）。

注意最近的一次桥梁黑客事件，其中 5/8 的多重签名签署者被朝鲜黑客攻破。中继节点被信任，并且仅对额外安全性的 oracle 提示上述协议的安全性极低。

DDoS 或活跃攻击：

攻击者可以选择 DDoS 攻击或以其他方式攻击 Oracle 或 Relayer 中较弱的一个。成功攻击任何一方将导致活跃性故障。理想情况下，Oracle 和 Relayer 的节点集都是无需许可的，在这种情况下，即使使用 PoS 网络，仍然具备跨链读取和写入能力，总体优于使用 Layer Zero。

失去活跃性的节点数量：

取决于所选 oracle/relayer，可能是 1 个。

节点集是否无需许可？

由于未声明认证层，这由应用程序开发人员决定。有趣的是，这可能使 LayerZero 成为对于希望拥有 KYC 的中继节点的私营公司和受监管机构的良好解决方案。不过，KYC 可以轻松加入到应用程序本身，而不是跨链协议层。

结论

到头来，讨论跨链安全性、吞吐量和活跃性就像争论区块链共识的类型。我的直觉是，跨链的最佳认证层与单链的相同：BFT 无需许可的权益证明。其他模型有不同的权衡，但安全性和无需许可性是加密的公理。应该尽可能使用 IBC，而对任何不支持 IBC 的生态系统使用 Axelar。

完全披露： 我是 Axelar 的社区成员，并且因在那里的贡献获得了基金会的资助。我正在构建一个跨链应用，而这项研究是独立进行的，以便告知我自己项目的跨链解决方案选择。

• 原文链接： 0xpostman.medium.com/par...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～