区块链桥的安全性和信任假设

一个著名的早期罗马传说描述了霍拉斯·科克莱斯（Horatius Cocles）几乎单枪匹马地保卫了一座桥，抵御了伊特鲁里亚的侵略者。

在过去几个月中，我们看到代币桥（token bridges）成为越来越复杂的攻击目标。这促使许多人讨论桥的实际安全性。因此，我们希望提供一个关于区块链桥中安全性和信任假设的全面概述。这将提供大多数消息协议、桥和互操作性项目的完整概述。此外，我们还将关注跨链消息协议和桥接的经济学，因为如果协议的代币使你能够对其进行政府控制，这也是非常关键的。

首先，让我们确定桥接相关协议中发生攻击问题的严重程度。

爆破攻击的比较

桥接攻击数量统计

显然，随着链的数量不断增加，桥接的攻击问题一直是一个巨大的问题。除非我们优先考虑安全性，否则这只会成为一种更系统性的风险，而我们作为用户需要在让协议负责任方面走在前列——毕竟这涉及到我们自己的资金。这也是我们撰写本文的原因——将重点放在互操作性领域的信任假设和安全性上。

同样，由于行业变得越来越多链、应用链和模块化，我们也在看到大量新区块链和层次的涌现。为了适应用户和流动性，互操作性是必需的。因此，我们看到桥，特别是代币桥的重要性和受欢迎程度随着越来越多区块链开始构建自己的生态系统而日益增加。这导致了对于将流动性从一个链转移到另一个链的需求。因此，代币桥的受欢迎程度增加。尽管这不是桥的唯一使用情况。此处我们特别指代一般的消息协议，例如 IBC，这通过其消息系统和标准启用了许多用例。

可以在这里看到不同链之间的资产桥接数量的精彩概述（特别感谢 CryptoFlows.info - 创作者还创建了其他优秀网站，如 L2Fees, CryptoFees）：

这明显显示了对桥的需求，并突显了在跨链消息协议和桥方面推动安全性的重要性——因为它们处理着巨大的价值，无论是在交易量方面，通常也是由多签智能合约控制的保管性解决方案。

在大多数桥接应用和跨链消息协议中，有一系列的操作有助于其有效性。这些主要如下所示。然而，它们依赖于特定的桥接/消息协议：

欺诈监视/监控：状态监控器，如轻客户端、验证者或预言机。

中继者：负责消息传递/中继的角色，通常只是一个信息传递者，而不是共识参与者，从源链到目标链传递信息，通常在链外操作。

共识：在监控链的参与者之间达成一致，这可能是以受信任的第三方验证集的形式，例如 Axelar 或者一个链外共识节点网络，甚至一个多签。

签名：桥接参与者以加密方式签署消息，这可以是验证者签署的加密签名，例如 IBC，或通过 ZKP（如 Plonky2）与 Polymer 来确认来自源链的验证者签名。

桥接参与者和总体架构

接下来，你可以将这些协议分类为四种主要类型：

托管桥接（Custodial Bridges，通常是资产特定的，但你甚至可以说交易所是托管桥）：提供用于抵押的包装资产，通过托管（第三方）或非托管（智能合约）方式。此类协议的一个示例是与中心化商户（如 BitGo）合作的 wBTC，然后在以太坊上铸造等值的 ERC-20 代币（以 wBTC 的形式）。我们稍后将讨论此类解决方案的信任假设和风险，但有些应通过这个解释就可以清楚明了。

多签链特定的（Multisig Chain-specific）：这些通常是两个链之间的双向桥接，例如 Harmony Bridge、Avalanche Bridge 和 Rainbow Bridge，所有这些都通过https://www.ethereum.org](https://www.ethereum.org)上的智能合约连接各自的链。用户通常将资产发送给协议，由此将其作为抵押品保存，并在目标链上发行基于该抵押品的桥接包装代币。这些通常由一定数量的验证者保护，甚至只有一个多签。我们已经看到这些解决方案在风险方面表现出脆弱性——尤其是与 Ronin Bridge 和最近的 Harmony Bridge 相关。

应用特定的（Application-specific）：提供访问多个链的应用，但仅用于特定应用，例如，Thorchain，它也运行自己的链并具有独立的验证者集。这些的信任假设通常集中在一个控制和处理跨网络不同智能合约/地址的消息和交易的单一验证者集上。

通用跨链消息（Generalised Cross-Chain Messaging）：允许在链之间进行通用消息传递的跨链消息协议，有设定的指令，例如 IBC。这些通常依赖于验证者集。在这里，信任位于连接的两个链的验证者集之内。对于 XCM，信任位于中继链（Polkadot）。你还可以将 Polymer 和 LayerZero 这样的消息协议加入其中，这些协议都是与链无关的。

• 跨链消息协议通常与流动性层结合使用，因为它们通常只处理基于其规范的 链之间的通信和标准。一个很好的例子是 Superform，它同时使用 LayerZero 和 Socket（作为流动性层）。你还可以将 Cosmos 基础的单独链视为 IBC 的流动性中心。

提到的桥接类型的简化运营架构

接下来的部分将涵盖跨链协议中的两个重要方面，即涉入的智能合约风险和需要考虑的其他信任假设。

智能合约风险

要讨论的最明显的安全风险之一是智能合约风险。智能合约在大多数不具有原生通用消息协议的跨链桥中被使用，因此确保它们的安全性至关重要。那么我们来讨论一些需要解决的风险。避免这些风险的最有效方法是完全不使用智能合约，而是依赖所涉及链的安全性。

1. 调用合约时要正确声明

   1. 哪些功能在执行前依赖预定义的条件。

   2. 断言条件以检查所有功能执行中需要保持为真的事物，例如桥接流动性合约的余额。

   3. 如果先前讨论的必要条件未满足，则触发的撤回声明。

2. 形式验证和严谨的测试

   1. 对合约进行形式验证，以确保在设定条件下该智能合约的正确性。数学结果是否合理？它是否按我所需的规范工作？

   2. 测试合约的所有功能——针对每次更新或更改。

   3. 测试随机性以确保如果安全属性受到侵犯，函数仍然能够保持真实。

   4. 有多种测试方法可以使用，例如单元测试、静态和动态分析等。如果你想讨论可以做什么，请联系 Runtime Verification 的人员。

      1. 一如既往，请记得审计你的合约，但要意识到审计并不是表明事情不会出错，它只是减少信任的另一种方式。漏洞赏金也可以有效利用，还有多种方式来实施这些措施 - 例如 Sherlock 和 ImmuneFi。

3. 可升级性与不可升级性

   1. 你的合约应该是不可变和不可升级的？这显然确保“恶意参与者”无法造成问题。然而，这降低了创新能力。需要创建一个新合约并迁移到新合约，这将需要经过我们之前讨论的许多检查点。另一个缺点是，如果合约存在缺陷而无法修复，它只会存在直到被利用。但不可升级的美妙之处在于，如果合约是坚固的，它就限制了利用的可能性；如果在没有适当安全措施的情况下对可升级合约进行更新，则可能导致漏洞——以往也见过类似情况。

   2. 然而，如果你选择可升级性（在大多数情况下是正确的选择），则有多种方式确保在最小化信任和最大化安全方面遵循：

      1. 准备应对失败——如果发生攻击，所需的升级是什么？我可以采取应急措施吗？

      2. 使用代理模式——在单独的合约之间分割状态（信息）和逻辑（执行）。这意味着你可以升级智能合约的逻辑（用新合约）而不干扰状态本身。

4. 紧急停止

   1. 有访问紧急停止功能的实体，关闭智能合约内可调用函数的访问权限。这只能在非常重要的情况下使用，以防止攻击的发生。这确实将权力集中在少数人手中，但有时可以帮助保卫合约中的函数，以防出现攻击。这是一个很好的方法，与下一个要点一起实施也是个好主意。

5. 监控（观看者）

   1. 对智能合约函数和执行的主动监控对于确保实时性和正确的追踪至关重要。你还可以利用各种监控工具，在与合约的实时性和安全性有关的重要触发器或函数上获得警报。

      1. 一种方法是在这里添加激励机制的观看者（如乐观 Rollup）以激励他们捕捉欺诈活动并进行报告。但是，这必须以实质性有效的方式实施，还有更紧迫的事情比保证有观看者更为重要。

6. 治理

   1. 如果智能合约的控制去中心化，并转交给你协议的代币持有者，需要确定治理系统的安全性。

   2. 需要考虑的是，大型代币持有者是否能够升级合约并将其功能变更为有利于他们的方式，这可能导致恶意攻击引发失误和资金损失——对此已经见过类似情况。

      1. 一个好的方法是考虑 Optimistic Approval，这是一种添加时间锁和否决过程的方法，以便使激励保持一致，并限制对某些参与者的权力，且有助于避免恶意提案。

      2. 这也涉及到使用时间锁，以防止智能合约在经过一段时间之前执行对系统至关重要的功能，这样可以在必要时提供应急功能。

      3. TWAP 投票也可用于减少快速的治理投票接管行为。

   3. 去中心化的治理系统可以很好地让社区成员在协议的未来中有发言权。然而，这确实也增加了风险和信任假设。

7. 访问控制

   1. 需要明确合约的特定功能，其调用者是谁。所有 EoA 是否都可以调用功能？功能应该是公开还是私有？是否只有在智能合约内部才能调用功能等……某些功能仅应由一些参与者访问，例如可升级性或代币铸造。

   2. 所有人是谁，他们能够执行哪些功能？权力完全归单一所有者所有，还是多签？通常，单独的角色可能会访问部分功能以限制中心化。无论如何，你应关注消除单点故障并最小化信任——以及聚焦于减少信任，以使信任变得尽可能少。

8. 重入

   1. 使用序列号、时间戳或加密证明以确保验证合约调用的有效性，避免重复提款。

9. 预言机操纵（中心化预言机）

   1. 对于依赖价格馈送或来自预言机的类似信息的智能合约，确保有安全的方法来识别操控并限制外部干预的可能性。

      1. 一个很好的研究论文是 Consolidated Price Feeds，它列出了在使用预言机时确保安全和最小化信任的方法。

正如上面所述，涉及智能合约风险时，有许多权衡因素。我们希望通过上述列表展示大部分相关风险，用户和开发者可以开始评估这些风险。

还应注意，即使一些跨链消息协议并不依赖于“智能合约”，它们仍然依赖于需要进行广泛审计和测试的代码和协议设计。这本不应该多说，但仍然值得注意。它们也应根据之前讨论的许多相同理念进行更新。最近一个非智能合约漏洞导致攻击的例子是 BNB 攻击，这是由过时的代码在旧 IBC 规范中未得到更新引发的。

信任假设

另一个重要的部分是用到的特定协议中的信任假设。在由中心化保管人处理的情况，例如 wBTC，这一点非常关键。在充当其特定第二层的桥接智能合约的卷起合约中，这也相当相关。它们通常由多签或类似机制控制，并且在许多情况下甚至是可升级的。在一些情况下，信任假设较小，而在另一些情况下则相当大。然而，重要的是要注意，在任何桥接/消息协议中，或多或少都存在信任假设，并且这种情况将始终存在。即使是在如 IBC 这样的无智能合约消息协议的情况下。在这些情况下，你信任连接链的验证者集。在其他情况下，若存在受信任的第三方操作桥接协议，则你主要信任该验证者集，例如 Axelar 和 Polkadot。在这种情况下，你还通常依赖于智能合约，至少在 Axelar 的情况下，这些合约作为被转移到 Axelar 的资金的保管人。

总是存在信任假设

有一些方法可以解决这些信任假设，例如依赖 ZKP 验证链上区块头的正确性。然而，仍然存在某种程度上需要信任源链（及其验证者集）的区块头正确，因此说没有涉及信任假设显然是错误的。你还依赖链上验证合约的正确性，因此，应始终优先考虑开源合约，它们也应经过测试和形式验证。这能够避免依赖外部信任假设，涉及到的越少越好。虽然我们永远无法达到完全无信任的状态，但我们可以接近相对的实用无信任状态，这种状态强调信任仅在一个足够的加密经济共识的去中心化网络中。在这里，还值得考虑的是，网络中大多数行动者的利益在于确保网络的长期健康以获得自己的利益。这导致了我们共同体经常提到的正负EV及 Moloch 现象，以及我们作为一个共同体能够在链上和链下共同协调共同抵御非理性行动者的能力。

之前讨论的桥的类型在 SC 和 TA 风险下的分布图

信任的不平衡

虽然一个重要的事实是，信任之间存在不平衡。信任体系因区块链而异。从一个区块链转移数据到另一个具备更高或更低的加密经济安全的区块链可能导致恶意行为。

多签钱包需要来自不同方的多个签名以授权交易，使单一实体更难危害系统安全性。另一方面，去中心化治理允许社区用户进行集体决策，使单一实体难以控制系统。然而，各个多签设置之间将会有所不同，提供的安全性和信任假设的程度各不相同。去中心化治理的情况也是如此。代币持有者的去中心化程度是否足够，他们是否具备 favorecersecurity 的治理实现——例如，乐观批准？许多重要因素需要考虑，通常在不同协议之间会有所不同。

重入与流动性

我们稍早提到的另一个关键点是“重放/重入攻击”。在重放攻击中，攻击者会将先前记录的交易从一个区块链广播到另一个区块链，可能允许他们多次花费相同的资金或资产。避免此类情况的显而易见的方法是使用轻客户端加密证明这些交易已在每个链上完成。但是，并不是在每个链上都可以做到。最近发生的这个类型的攻击的最明显的例子是 Nomad。另一个选项是使用序列号或时间戳来确保每笔交易都有唯一标识符，不可重用——随机性在这方面也很重要。

还要考虑的方面是某特定资产的流动性所在。例如，流动性是在源链的流动性合约中吗？是否像某些美元稳定币一样，流动性实际上是链外的？需要考虑很多信任假设。我们应该尽量减少信任假设，但永远无法完全消除它们。

现在我们已经确立了一些在桥接珍贵资产、查询数据或共享状态时应注意的重要事项——让我们理解为什么桥接资产和状态是至关重要的。

数据移动和状态共享是实现跨链真正组合性的下一步。它使应用程序能够超越区块链的边界，以链无关的方式构建协议。这样，链 A 上的模块、账户或智能合约可以调用或读取链 B 上的智能合约、账户或模块的状态。通过 IBC 的 ICQ 模块，可以看到这个例子的显著作用。确保被桥接的资产在各种链上的安全性至关重要，因为我们和其他许多人都预见到一个许多链希望共同存在的未来。

跨链消息协议的一般分析

本节将作为几乎所有现存跨链桥接和消息协议的指南。它将涵盖它们的各种安全措施及其信任假设。如若我们遗漏了某个特定协议，深表歉意。但这一部分仍应覆盖绝大多数现存的协议，甚至将进入特定桥接合约，如 L2 桥接合约。

我们已经在之前的文章中深入讨论了 IBC 如何工作，例如 这篇，以及 这篇。如果你对阅读它们感兴趣，我推荐你这样做。重要的是要强调，它们内部的主要信任假设来源于已经开启通道的链的验证者集。没有智能合约风险，而是信任验证集及其状态。

正如我们在 Polymer 文章中所述，IBC 有各种派生版本。这里的意思是利用 IBC 的跨链消息协议。第一部分将涵盖这种协议。即 Polymer 和 Composable，我们已经对 Polymer 进行了全面深入的探讨，因此我们将简略说明这一部分，因为你现在应该已经相当熟悉。还应注意，我们是 Polymer 和 Composable 的投资者。

Polymer

• IBC 路由协议，更像是一个通用跨链消息协议而非桥接。

• 轻客户端或作为轻客户端的智能合约，验证区块头（来自验证者的签名）。

• 通过来自验证者集的验证者签名进行加密证明——在非 Cosmos 链上通过递归实现 ZKP（plonky2）和链上验证——它们的 zkIBC 实现。

• 智能合约中的 IBC 逻辑。

• 提供基于连接链的验证集的异步桥接。

• 支持数据共享和查询。不仅仅是资产桥。

• 在源链上进行同步提交（验证者签名），一旦检查到目标链的区块头则完成最终确认。

• 加密经济安全性在于连接的链的验证集和 IBC，针对非 IBC 基础链，信任假设则在于部署的智能合约。

Composable

• XCVM 的运作与 Polymer 类似。通过这句话，表示能够部署原生跨链协议。因此包含了状态共享、查询能力等。

• Centauri 是他们的传输层，促进实际的通信。这是基于 IBC 的，并支持状态共享。它基本上允许通过其与相关重复链相连的再分配链从 IBC 链桥接。

• 与 IBC 一样，采用轻客户端的实施，通过 rust 实现 IBC 支持 Polkadot 生态系统（Substrate）。轻客户端或智能合约/Pallet 作为轻客户端，验证区块头（来自验证者的签名）。

• 在这种情况下，信任假设从两个单一的验证集转移到相关中继链的验证集（Polkadot 或 Kusama），它控制着被桥接的子链的状态，从使用 IBC 的链。其实现方式是一个 IBC 托管（类似于软件合约中的 Polygon 合约中的 IBC 合同）。

• 观察节点用于验证区块有效性，以应对链上的攻击。

• 在支持本地轻客户端的链中，过程与原生的 IBC 类似。

接下来的部分将解释 XCMP 的工作原理，这是 Polkadot 生态系统的本地跨链消息协议。这是对 Composable 的自然延续，因为它们确实起源于该生态系统。

XCM(P)

• 子链在于主中继链的共识下做出单一信任假设，因此所有子链都信任主中继链。这一情况与 Kusama 和其子链相同。

• 因此，XCMP 依赖中继链和子链验证者来验证来自子链发送的消息，处理过程由中继链区块完成。

• 通过 IBC 建立了相应通道。不过每次提交需要发送到中继链，因此需要监控中继链状态以确认消息已达到共识。为此，子链的区块头被放入中继链区块中以确认消息传递。

• 在这种情况下，中继链某种程度上充当受信任的第三方（TTP）——它的安全性与中继链的验证集一样——这是你的信任假设。

• 子链通过共享安全性获得了来自中继链（Polkadot）的安全性。

• 这意味着 Polkadot 网络的总质押是 XCMP 的信任假设和加密经济安全性。

IBC

• 每一条链都需要在对方链上有一个轻客户端，以加密验证两个链之间的共识状态。

• 需要中继者来在两个链上的轻客户端之间转发信息。中继者对于实时性至关重要——确保节点之间能够交换消息，实时达成共识。

• 中继者并不是直接将消息传递给每条链的轻客户端。相反，中继者提交的信息准确目标是该链上的 IBC 模块。轻客户端仅是 IBC 模块的一个小子组件。

• IBC 轻客户端只在初始化步骤时信任特定的区块头（即信任根，当客户端被创建时）。在这一步骤，客户端确实信任提供该区块头的节点是诚实的。在这一步之后，它们不再对特定的完整节点是否诚实持有信任假设。

• 信任假设存在于连接区块链的两个验证者集之间。

• 加密经济安全性是所涉及链的总质押。

为了继续关注 Cosmos 接轨，接下来让我们看看 Gravity 和 Axelar，这两者都通过在非 CosmosSDK/Tendermint 的链上以及它们各自的链上，通过智能合约操作它们的桥接。这些是相对简单的解决方案，但确实能够使互链生态系统与更广泛的区块链网络连接起来。我们来看看它们。

Gravity

• 运行一条 Cosmos 链作为共识网络，负责确保和铸造可在 Cosmos 生态系统中使用的 ICS 资产。

• 验证者需要运行完整的 ETH 节点。

• 通过中继者网络连接（在这种情况下不是像 IBC 一样无信任的），这增加了信任假设，因为他们管理自己的 Cosmos SDK 区域，并按此前所述运行自己的 ETH 节点。

• 桥接到 Gravity 的流动性在 Ethereum 上是智能合约。

• 不可升级合约，仅可进行略微的逻辑升级。

• 信任假设在于 Gravity 桥接验证集、智能合约安全风险和具有冲突利益的中继网络。

Axelar

• 类似于 Gravity，它依赖于 Axelar 链的验证者在接入 Axelar 的链上运行节点/轻客户端。

• 他们还像 Gravity 一样将交易批量处理。

• 还依赖于需要移植到新加入链的目标语言的智能合约。Axelar 目前支持的链比 Gravity 更多，Gravity 仅为以太坊服务。这些智能合约并非流动性智能合约，而是可以调用其他合约的智能合约。理论上，它的作用类似于一个网关或轻节点，其中传递符合由 Axelar 提供的逻辑的消息。类似于 Satellite 的桥接，可以利用这基础设施建立真正的流动性桥接并桥接资产。

• 允许跨链的通用消息传递，同时也规划应用以实现 Axelar 作为 messaging protocol，这与 IBC，以及 Polymer 和 Composable 的目标相似。

• 允许应用利用它们的基础设施。与 LayerZero 的角色不完全相同，Stargate 的桥接系统也是如此。但请记住，Axelar 操作自己的共识网络，即其 Cosmos SDK 链，变动中它的验证者也运行与连接系统的节点。

• 目前的受信任验证集为 60 个验证者（尽管并非所有验证者都在连接的链上运行节点，可能只是其子集或不是）。对智能合约的风险以及是否使用通过其基础设施连接桥接的类型合约也需考虑。

接下来综述 LayerZero，这在跨链消息协议的世界中引起了巨大反响并获得了丰硕的成果。同时重要的是要注意，L0 并不是桥接，而是一种把与之相连或跨链调用智能合约的消息协议。

LayerZero

• 两个实体——预言机和中继者。

  • 预言机将区块头转发到目标链，而中继者将来自源链的交易证明转发给目标链的相关信息，证明交易/消息是有效的。

• 应用程序可以灵活使用 LayerZero 的默认预言机和中继者，或创建和运行属于自己的。它们被用作跨链消息协议，而不是实际的代币桥。但你可以用它构建桥接，如 Stargate 和其他使用它们进行消息传递的桥接。

• 终端，即它们版本的 Axelar 的网关或 Polymer 的 IBC 逻辑智能合约。它们基本上充当在 IBC 中的轻客户端进行验证。

• 这意味着，与 Axelar 一样，你依赖于 LayerZero 的基础设施，以及与 LayerZero 连接的智能合约。

• 如果两个主体之一是不诚实的，则交易将失败。然而，如果两者都不诚实（如果你依赖中心化解决方案或应用的自身，因为这可能会成为问题），则可能会发生利用。因此，在这里使用去中心化的预言机网络至关重要，甚至可以用集中的预言机。

• 不依赖于可信的第三方链，而是依赖于可以具有不同的安全性和信任程度的模块化架构。

• 安全程度与所使用的预言机/中继者解决方案一样好，智能合约的自然风险也同样存在。

• 本身不提供或依赖于任何加密经济安全。但依赖于所使用网络的加密经济安全。因此，所使用的预言机的经济安全性是重点。中继者的安全性是否多签等，也是信任假设的内容之一。

接下来的内容将讨论被称为“乐观桥”的内容，这里我特别指的是 Nomad 及其部分合作伙伴。显然与此相关的内容也有，需记住的是错误是由智能合约漏洞导致的，而非桥接机制本身的使用。

乐观桥

• 提交数据/交易到合约功能类似于前面提到的终端/网关。

• 桥接代理签署并发布数据根的 Merkle 以证明其正确性。然后任何代理都可以将其发布到目标链。这一代理需要进行代币抵押，若发生欺诈则会被削减。

• 在数据发布后，会启动一个欺诈证明窗口，任何（激励奖励获取该代理的抵押金）的观测者都能证实源链的欺诈，因此其抵押金将被削减。然而，目前在链上进行削减并不可行，所以通常需在半手动的链外网络中完成。

• 如果在时间限制内没有欺诈证明，则数据在目标链上被视为最终，且可以调用目标链上的合约。

• 这种技术有着较低的信任假设，但却高度依赖智能合约和监视者的工作。如果存在任何智能合约漏洞，监视者则无法做到什么。

• 他们只需一个诚实的监视者，因为只需单一方可靠地验证更新即可。

• 这意味着应抵消的抵押资金不应过高，因为你实际上依赖的是只有一方诚实的框架。

• 需要去中心化代理，否则单一代理将可能导致系统停止。

• 需要对监视者征税以防范 DoS，但这意味着如果没有发生欺诈，你也不会获得任何收益——需要不同的激励方案，除非你依赖桥的参与者来运行他们，这将导致中心化，因为代理/监视者与协议将共同运作。

• 加密经济安全性取决于所用特定网络。它可能是观察者的加密经济安全或参与者因被允许参与所抵押的代币而受限制的各种形式。对此有多种时限控制方式。

乐观桥的架构

接下来让我们涵盖多个参与方计算（MPC）桥，这些桥在不少案例还依赖于被外部验证的共识网络作为受信任的第三方。例如，Qredo 和 Chainflip。Synapse 也以类似方式运作。

外部验证者的多个参与方计算（MPC）

• MPC 是一种门限签名方案，允许多个节点在单个密钥下创建签名，增加了串通或控制账户的难度。

• 外部验证者意味着协议运行一个拥有验证者节点的网络或链，验证签名并调用控制与当前 MPC 钱包桥接的链上的网关智能合约功能。这种方法也称为中间链方式。

• 许多 MPC 解决方案还运行各种硬件安全机制。

• 如果出现未授权尝试访问账户，将销毁存储在该节点中的密钥；社会工程是唯一可以访问（我们曾见过这种方法成功）。

• 这意味着这些桥通常受限于少数个体，而无法广泛使用。通常，以机构用例为重点。

• 需要信任假设在于，桥接网关合约已正确设置，存在各种智能合约的安全风险。而社会工程在这里同样需要考虑。

• 中间链通常用于记录用户资产的所有权。

• 为最佳的安全假设，网关应由去中心化的多签/节点网络进行控制。

• 在这些情况下，中间链通常是系统的加密经济安全性，因为它允许记录和更改资产的所有权，它因此成为受信任的第三方。

• 请注意，参与签名的数量会增加系统的延迟，正如下图所示：

• 不同解决方案最后的表现如图所示：

之前的两个解决方案也可以被视为应用特定桥接，这是我们之前提到的一种类型的链。另一个符合这一类别的链为人们通常考虑的 Rune，也称为 THORChain。

Rune （THORChain）- THORChain 基本上充当一个外部验证者，实际上在连接链上的无领导金库上运行。这也意味着它是整个网络的加密经济安全，因为它充当桥接链之间的中介。它也是需要做出的一个信任假设。

• 状态链协调资产和交换逻辑，同时委托交易输出

• 这通过每个连接链上的“端点”来处理特定交易

• 每个签名者都需要在连接的链上运行完整节点

• 每个链的客户端相对轻量，仅包含调用特定链上的合约所需的逻辑。主要逻辑在运行于 THORChain 本身的观察者客户端中。让我们来勾画一下，以便你更好地理解：

为了完成我们的分析，让我们看看一种通常不被称为桥接的桥，而是一种 L2 rollup 合约。这些是以太坊上 L2 与之进行通信的合约，资产在这类合约中被锁定，然后在所述 rollup 上“铸造”。在此时，这些合约持有数十亿美元的资产。因此，它们的有效性至关重要。让我们看看它们是如何工作的，以及它们提供什么样的安全性。

Rollup 桥接合约

• 功能类似于桥接，因为资产被锁定在 L1 智能合约中，然后变得可以在 L2 上使用

• Rollup 状态和证明在 L2 合约中被验证，提供了一定程度上从底层派生的密码学安全性。如果需要有效性证明，则会在 L1 上的验证合约中发送和验证。

• 大多数 rollup 在其智能合约中具有可升级性，这显然是需要考虑的风险。

• 大多数 rollup 允许通过 L1 进行交易，或者在排序器失败时强制退出到 L1。

• 本质上是一个降低信任的桥接。然而，存在显著的智能合约风险，以及对谁控制这些的信任假设。

• Arbitrum 和 Optimism “桥接”就是这样工作的。

现在我们已经涵盖了目前用于跨链消息传递协议和桥接的大多数解决方案，让我们看看涉及协议安全性的另一个非常重要的部分。这里我们指的是协议的经济学。特别感兴趣的是协议的加密经济安全，是否有一个允许治理权或让你接管协议核心部分的代币。

桥接经济学

让我们从一个假设开始 - 存在一个具有治理代币的桥接协议，允许对协议的升级进行投票或接管核心协议功能。现在，如果协议中锁定的总价值远远超过通过提案的法定人数，那么攻击该协议显然具有显著价值。这个简单的假设就是桥接经济学和治理功能对桥接至关重要的原因。缓解这一点的一个方法是利用稍微更细致的治理原则，称为乐观批准，正如前面所述。

加密经济安全是区块链桥接和跨链消息传递协议中的一个关键方面，需要精心设计和实施的激励与惩罚系统，以确保系统的安全性和完整性。这就是为什么不必依赖可信第三方的加密经济安全的系统工作效果更好的原因。在依赖桥接的加密经济安全来保护各种链上的资产的系统中，显然不如依赖链本身的加密经济安全来得安全。

然而，目前大多数桥接和跨链消息传递协议依赖于可信第三方的经济学。这在那个 valset 非常安全的情况下可能理想，但在其他情况下也可能会出现问题。还有其它机制可以用来保护参与的网络，例如可验证延迟函数（Verifiable Delay Function），它可以为依赖此类参与者的网络中的 Oracle 添加随机性。

需要考虑的其他经济学方面是，诸如 multisigs、valsets、mpc 或甚至阈值等经常使用加密经济值的网络。这些通常依赖于诚实多数的假设，意味着攻击这些桥接的成本就是腐败/控制网络 51% 的成本。

可信第三方

在区块链桥接中使用可信第三方有利有弊。一方面，这些第三方提供了一个集中的可信协调点，这可以使管理和保护不同网络之间资产和数据的转移变得更容易。在不同的网络有不同的安全性和共识模型，或者需要额外的监督和控制级别的情况下，这尤其有用。

另一方面，使用可信第三方在系统中引入了一个潜在的失败点。如果第三方遭到破坏，可能会导致资产或数据的损失。此外，在可信第三方中集中权力可能削弱系统本身的去中心化和无信任性。

速率限制

另一个在经济上相关的方面，并且可以帮助限制攻击造成的损害的是对桥接实施速率限制。速率限制的概念是限制每小时可以桥接的总 USD 价值量，以便在紧急情况下实施解决方案以保护其余的桥接。

显然，这在用户体验方面会带来问题，尤其是对于非常流行的桥接或大宗桥接用户，同时显然增加了一些安全性。例如，你可以限制每小时可以桥接的总金额为 1000 万美元。绝大多数用户/零售不会注意到，并且可以将攻击的可能损失限制在一个更小的金额内。这在过去的攻击中显然会非常有用。

是否有什么魔法数字规定速率限制应该是多少？不，实际上取决于该桥接的采用情况，也取决于桥接到哪个链。例如，在 Arbitrum<>ETH 桥接上，由于其流行性，你需要一个可以桥接的大额。然而，在特定于游戏的应用链或 rollup 的情况下，玩一款游戏并不需要大量资金，而你会更希望确保用户资金的安全。在这种情况下，实施速率限制是非常有意义的。

缺点显而易见 - 限流并使大玩家失去竞争力。然而，安全是否超越了这些？

一个解决方案可以是在桥接中实施“桥接通道高速公路”。不同的桥接，用于不同的解决方案和人。而这显然带来的一个缺点是流动性和交易量的碎片化。对于一个特定于游戏的 rollup，减少桥接的金额是有意义的，因为你在那里并不需要大数额，并且希望在任何情况下都能确保用户资金的安全。

需要记住的其他事项包括：

1. DoS 攻击，因此需要对大额交易实施相当高的费用。

2. 希望优化增长，但这在增长上有轻微的制约。

正如在整篇文章中所明确的，这一切都是权衡。因此，在速率限制方面也是如此。然而，这是一个我们希望看到更多实验的领域。在大多数情况下，并不存在明确的最佳方案，但总的来说，尝试在这一领域进行新的和大胆的尝试是值得的。没有哪个最终设计是完美的，但安全和保护应该是任何协议的最大关注点。可以说，速率限制允许我们为少数人牺牲用户体验，同时为多数人提供安全。

互操作性和可组合性

互操作性通常用于解释在应用程序和链之间无缝转移资产，而可组合性用于描述这些特定应用程序之间共享基础设施的想法，例如在多个链上部署一个应用程序，工作量最小化。这正是之前描述的跨链消息传递协议所做的工作。

只有当链和应用程序之间的交易成本较低时，可组合性才是可持续的，否则，它会失去可组合性所赋予的基本价值。可组合性为最终用户带来了更多选择和在各种生态系统和应用程序之间无缝执行操作的能力，同时消除了之前诸如从头创建生态系统的障碍。

当应用程序能够与其他应用程序（例如自动流动性头寸、借贷等）进行交互时，它们就变得可组合。

我们尽力保持客观，并提供一个关于当前跨链互操作性现状的清晰概述，希望能为你作为读者提供某种价值。如果有任何你不同意的观点或者觉得被误传的地方，请随时通过推特联系作者 @0xrainandcoffee。

感谢 Runtime Verification 在智能合约部分的输入，以及文章的其他读者们的帮助。

对于桥接中的信任最小化进一步阅读，我强烈推荐阅读 Celestia 的 Mustafa 撰写的 Clusters 文章 - 链接

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