万字综述区块链桥接中的安全和信任假设

我们将提供一个关于大多数信息传递协议 、桥接和互操作性项目的完整概述 。

原文：Horatius At The Bridge（The Weekly Depths）

作者：rain&coffee

编译：Yangz，DeFi 之道

封面：由 Maze AI 生成

早期罗马的一个著名传说描述了 Horatius Cocles 几乎单枪匹马地保卫了一座桥，以对抗伊特鲁里亚的侵略者。

在过去的几个月里，我们看到代币桥成为越来越复杂的攻击的目标。于是，一些人开始谈论桥接的实际安全问题。因此，我们想对区块链桥接的安全和信任假设做一个全面概述。我们将提供一个关于大多数信息传递协议、桥接和互操作性项目的完整概述。此外，我们还将看看跨链消息协议和桥接的经济性，因为如果协议的代币能让你对其进行控制，这也是极为关键的。

首先，让我们确定一下，在桥接相关协议上发生的漏洞方面，问题到底有多严重。

通过上面两张图片，我们可以清楚地看到，随着存在的链的数量增加，桥接的漏洞已经成为了一个巨大问题。除非我们优先考虑安全问题，否则这只会成为一个更加系统化的风险，而我们作为用户需要站在协议责任的最前沿——归根结底，这是我们的资金。所以，这也是我们撰写本文的原因——关注互操作性领域中的信任假设和安全性。

同样，由于行业变得越来越多链、应用链和模块化，我们也看到大量新的区块链和层的涌入。为了适应用户和流动性，需要有互操作性。因此，随着越来越多的区块链开始建立自己的生态系统，桥接，特别是代币桥的重要性和受欢迎程度变得越来越高。将流动性从一个链转移到另一个链是有需求的。因此，也就有了代币桥的流行，虽然这不是桥接的唯一用途。这里我们特指一般的信息传递协议，例如 IBC，它通过其信息传递系统和标准实现了无数的用例。

下图是一些关于许多资产在不同的链上被桥接的优秀概述（来源 CryptoFlows.info - 其创造者也是其他伟大的网站的创建者，如 L2 Fees, CryptoFees）。

这清楚地表明了对桥接的需求，并强调了为什么当涉及到跨链消息协议和桥接时，我们推动安全是如此的重要——因为它们处理着巨大的价值，无论是在数量上还是在许多情况下由多签智能合约控制的托管。

在大多数桥接应用和跨链信息传输协议中，有一系列有助于其功效的行动。这些可以从以下几点中看到。虽然，它们取决于有关的特定桥接/信息传递协议。

• 欺诈观察者/监测：状态监测器，如轻型客户端、验证器或预言机。
• 中继器：负责信息传递/中继，如中继器（通常只是一个信使，而不是共识参与者），将信息从源头带到目标链上，该链在链外运行。
• 共识：监视链的行动者之间的协议，这可以是可信的第三方 valset 的形式，如 Axelar 或共识节点的链外网络，甚至是一个多签。
• 签名：桥接者对信息进行加密签名，这可以是验证者签署加密签名，如 IBC，或通过 ZKP（如 Plonky2）与 Polymer，证明源链上的验证者签名。

你可以把这些协议分为四大类型：

托管桥（通常是特定资产，但你甚至可以说交易所是托管桥）：提供以托管（通过第三方）或非托管（智能合约）方式进行抵押的封装资产。这类协议的一个例子是 wBTC，有一个像 BitGo 这样的中心化商家，然后铸造一个同等的 ERC-20 代币（以太坊上的 wBTC）。我们将在后面讨论这种类型的解决方案的信任假设和风险，但仅凭这个解释，其中一些应该很清楚了。

专用多签链：这些通常是两个链之间的双向桥接，如 Harmony Bridge、Avalanche Bridge 和 Rainbow Bridge，都是通过以太坊上的智能合约将各自的链连接到以太坊。用户通常向协议发送一项资产，在那里作为抵押品，并在目标链上发行一个桥接封装代币，由源链合约中锁定的抵押品支持。这些通常由一组验证人或甚至只是一个多签来保护。而我们也已经看到了这些解决方案是如何被证明容易产生风险的 -- 即 Ronin 桥和 Harmony 桥黑客事件。

特定应用：一个应用程序提供对几个链的访问，但只用于该特定的应用程序，例如，Thorchain，它也运行自己的链，有单独的验证器组。这些协议的信任假设往往在于一个单一的验证器组，它控制和处理整个网络的所有消息和交易，连接到不同链上的不同智能合约/地址。

通用跨链信息传递：跨链消息传递协议，允许在有设定指令的链上进行通用的消息传递，如 IBC。这些通常依赖于验证器集。这里的信任在于被连接的两个链的验证器集。有了 XCM，信任就在于中继链（Polkadot）。此外，像 Polymer 和 LayerZero 这类信息传递协议也适用，它们是不可知的。

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

接下来的部分将有助于涵盖跨链协议的两个重要部分，即涉及的智能合约风险和需要考虑的额外信任假设。

智能合约风险

首先要涵盖的最明显的安全风险之一是智能合约的风险。智能合约被用于大多数跨链桥，这些桥接没有原生的通用信息传输协议，因此，它们的安全是至关重要的。以下，让我们来探讨一下这里需要解决的一些风险。总的来说，避免这些风险的最有效方法是完全省略智能合约的使用，而是依靠相关链的安全性。

1.  调用合约的正确语句

• 哪些函数在执行之前依赖于预定义的条件
• 断言条件，以检查所有函数执行中需要保持真实的东西，如桥接流动性合约的余额
• 如果所需条件没有得到满足，可以触发还原语句，比如之前讨论的那些。

2.  形式化验证和严格的测试

• 合约的形式化验证对于确保上述智能合约在设定条件下的正确性非常重要。数学运算是否正常？它是否按照我需要它遵守的规范工作？
• 对于所做的每一次更新或改变，测试合约的所有函数。
• 测试随机性，以确保如果违反了安全属性，这些函数是成立的。
• 有各种测试方法可以使用，如 -- 单元测试、静态和动态分析等等。如果你想讨论你能做什么，请与像 Runtime Verification 这样的人取得联系。像往常一样，记得审计你的合约，但要注意，审计并不代表不会出错，它只是另一种将信任降到最低的方式。赏金也是另一个可以利用的好东西，且有各种方法来实现这些 -- 比如 Sherlock 和 ImmuneFi。

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

• 你的合约应该是不可改变的和不可升级的吗？这显然可以确保 “恶意行为者 “不能造成问题。然而，它降低了创新的能力。一个新的合约和向其迁移的过程是需要的，而这需要经过我们之前讨论过的许多检查点。此外，不可升级的另一个缺点是，如果合约有缺陷，那么其无法解决，只是活到被人利用为止。虽然不可升级的好处是，在合约坚定不移的情况下，它限制了漏洞，但如果对可升级的合约进行更新而没有适当的安全措施，就会导致故障 -- 如之前所见。
• 然而，如果你选择了可升级性，那么在大多数情况下会是正确的选择，因为有各种方法可以确保你坚持最小化信任和最大化安全：

为失败做准备 -- 如果发生漏洞，需要进行哪些升级，我可以制定紧急措施吗？

利用代理模式 -- 将状态（信息）和逻辑（执行）分割在不同的合约之间。这意味着你可以升级智能合约的逻辑（用一个新的智能合约），而不搞乱状态本身。

4.  紧急停止

• 设置可以访问紧急停止功能的实体，它可以关闭对智能合约内函数的可访问性。这应该只在非常重要的情况下使用，比如需要它来阻止一个漏洞。然而，这确实把权力放在了少数人的手中，但它有时可以帮助保护合约中的函数，以防止漏洞发生。这是一个很好的方法和想法，可以和下一点一起实施。

5.  监控（观察者）

• 主动监测智能合约的功能和执行是极其重要的，以确保有效性和正确跟踪。你也可以利用各种监控工具来获得某些触发器或函数的警报，这对合约的有效性和安全性非常重要。

一个补充的方法是设置观察者激励（如 Optimistic Rollups），有激励的观察者会抓住欺诈活动并报告它。然而，这需要以一种能够产生实际效果的方式来实施，毕竟还有比设置观察者更紧迫的事情。

6.  治理

• 如果你的智能合约的控制权是去中心化的，并交给你的协议代币持有者，那么治理系统的安全性就需要有确定性。
• 需要考虑的是，大型代币持有者能够升级合约并改变对他们有利的功能，这可能会导致恶意的利用，造成失败和资金损失 -- 这在以前已经出现过。

1. 一个可以考虑的好方法是 Optimistic Approval，这是一个增加时间锁和否决程序的方法，允许调整激励机制，限制某些行为者的权力，并有助于避免恶意的提议。
2. 这也与使用时间锁来防止智能合约执行对系统不可或缺的功能有关，直到一定的时间过去，这可以让紧急功能在需要时介入。
3. TWAP 投票也可以用来减少快速治理投票的接管。

• 一个去中心化的治理系统可以非常有用，让社区成员对协议的未来有发言权。然而，它确实增加了风险和信任假设。

7.  访问控制

• 合约的具体函数需要解决谁可以调用它们的问题。是否应该允许所有 EoA 调用函数？函数应该是公共的还是私人的？是否应该只在智能合约内调用函数？有些函数应该只由某些行为者访问，例如可升级性，或铸造代币。
• 谁是所有者，他们能够执行什么函数 -- 是只属于一个所有者，还是一个多身份的人？通常，不同的角色可以访问部分函数，以限制中心化。无论如何，你应该专注于消除单点故障，并尽量减少信任 -- 专注于最小化，因为你永远无法消除信任。

8.  重入

• 序列号、时间戳或加密证明，以确保对合约调用的有效识别，以避免重复调用。

9.  预言机操纵（合并预言机）

• 对于依赖价格反馈或来自预言机的类似信息的智能合约来说，另一件重要的事情是要有安全的方法来识别操纵，并从外部角度限制可能出现的情况。关于这一点，有一篇很好的研究论文可供阅读，即 《综合价格馈送》，它阐述了在使用预言机时确保安全和最小化信任的方法。

从上面的内容可以看出，当涉及到智能合约的风险时，有很多的权衡因素。我们希望通过上面的清单，显示出所涉及的大部分风险，以供用户和开发者评估。

还应注意的是，即使一些跨链信息传递协议不依赖于 “智能合约” 本身，它们仍然依赖于代码和协议设计，需要广泛的审计和测试。这应该是不言而喻的，但还是需要注意。此外，它们也应该按照讨论的许多相同的想法来更新。最近的一个非智能合约错误导致的漏洞的例子是 BNB 漏洞，这是一个旧的 IBC 规范中过时的代码因没有保持更新造成的。

信任假设

另一个要涵盖的重要部分是正在使用的特定协议中的信任假设。这对于像 wBTC 这样由中心化托管者处理的情况来说，是非常重要的。即使是在为其特定的 L2 充当桥接智能合约的 rollup 合约的情况下，这也是相关的。通常情况下，它们是由多签或类似的控制，在许多情况下甚至可以升级。在某些情况下，信任假设很小，但在另一些情况下，它们相当大。然而，需要注意的是，在任何桥接/信息传递协议中，在某种程度上都有信任假设，而且总是会存在的，即使是像 IBC 这样的无智能合约的信息传递协议。在这些情况下，你要信任连接链的验证器集，或者在其他情况下，如果有一个受信任的第三方来操作桥接协议，你就会主要信任该验证器集，比如 Axelar 和 Polkadot。在这些情况下，你也会经常依赖于智能合约，至少在 Axelar 的情况下是如此的，它们会托管被桥接到 Axelar 的资金。

信任假设永远存在

有一些方法可以解决这些信任假设，例如依靠 ZKPs 来验证链上区块头的正确性。然而，仍然会有信任假设的存在，即区块头来自源链（和它的 valset）是正确的。因此，说不涉及信任假设是完全错误的。此外，你还要依赖于链上验证器合约是正确的，因此，开源合约应该始终是首选，并接受测试和正式验证。这样做的目的是为了防止依赖外部信任假设，毕竟这些假设越少越好。虽然我们永远不会达到无信任，但我们可以相对接近并达到实际的无信任，也就是信任只存在于一个有足够加密经济协议的去中心化网络中。所谓一致，是指攻击的成本将远远超过收益。在这里，同样重要的是要考虑到，为了自己的利益，确保网络的长期健康符合大多数网络参与者的利益。这让我们想到了 “-” 和 “+”EV 的说法，以及 Moloch 的作用，和我们作为一个社区，在链上和链下共同协调，对抗非理性行为者的能力。

信任的差异

信任上的差异是至关重要的。各个区块链的信任系统各不相同，将数据从一个区块链转移到另一个具有更大或更小的加密经济安全性的区块链上，可能会导致恶意行为的发生。

多签钱包需要来自不同方面的多个签名才能授权交易，这使得单个实体更难破坏系统的安全性。另一方面，去中心化的治理允许用户社区的集体决策，使单一实体更难获得对系统的控制。然而，每个多签的设置都会与下一个不同，提供不同数量的安全和信任假设。去中心化治理的情况也是如此。代币持有者是否有足够的去中心化，他们是否有一个有利于安全的治理实施 -- 例如，Optimistic Approval？有几个因素是需要考虑的，而且往往因协议而异。

重入和流动性

我们稍早涉及的另一个关键是 “重放/重入攻击”。在重放攻击中，攻击者将一个区块链上先前记录的交易广播到另一个区块链上，有可能会让他们多次花费相同的资金或资产。避免这种情况的明显方法显然是使用轻客户端来加密证明上述交易已经在每个链上完成。然而，这在每个链上都是不可能的。最近发生的这种类型的漏洞攻击的最明显的例子是 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 一样用轻型客户端操作，以及 IBC 的锈蚀实现，以支持 Polkadot 生态系统（Substrate）。轻客户端或智能合约/Pallets 作为轻客户端验证区块头（验证者的签名）。
• 在这种情况下，信任假设从两个单一的 valsets 转移到有关中继链（Polkadot 或 Kusama）的 valset，该链操作被桥接的并行链的状态。这是通过一个 IBC pallet（类似于以太坊上 Solidity 的 Polymer IBC 合约）来实现其并行链上所需的 IBC 框架。
• 观察者节点在链被攻击的情况下验证区块的有效性。
• 对于有原生轻客户端支持的链，其过程与 IBC 的原生工作方式非常相似。

下一节将解释 XCMP 是如何运作的，它是 Polkadot 生态系统的本地跨链信息传输协议。这也是对 Composable 的自然跟进，因为它们确实源自该生态系统。

XCM (P)

• 并行链做了一个单一的信任假设，因为它们都依赖于 Polkadot 的共识，所以它们信任主中继链。Kusama 和它的并行链也一样。
• 因此 XCMP 依靠中继链和并行链验证器来验证从并行链发出的消息，这个过程由中继链上的一个区块来最终完成。
• 建立如与 IBC 的渠道。然而每次提交都需要到中继链上，因此需要监控中继链上的状态，以确认消息已经达成共识。因此，并行链区块头需要进入中继链区块以确认消息的传递。

• 在这种情况下，中继链有点像受信任的第三方（TTP）一样运作 -- 所以它和中继链的 valset 一样安全，即你的信任假设。
• 并行链通过中继链（Polkadot）通过共享安全获得其安全性。
• 这意味着 Polkadot 网络的总赌注是 XCMP 的信任假设和加密经济安全。

IBC

• 需要对方链上的轻客户端对两个链之间的共识状态进行加密验证
• 需要中继器在两条链上的轻客户端之间中继信息。中继器是有效性的需要 -- 能够在节点之间交换信息，使节点成功达成共识。
• 中继器不向每个链上的轻客户转发信息。相反，中继器提交给每个链的消息的确切接收者是该链上的 IBC 模块。轻客户端是 IBC 模块的一个小的子组件。
• IBC 轻客户端只在初始化步骤（信任根，当客户端被创建时）信任一个特定的区块头。在该步骤中，客户端确实信任提供该区块头的节点是诚实的。在这一步之后，他们不再有诚实的基于特定完整节点的信任假设。
• 信任假设在于连接的区块链的两个验证器组内
• 加密经济安全是有关链的关键所在

为了观察 Cosmos 路线，让我们看看 Gravity 和 Axelar，它们都通过智能合约在非 CosmosSDK/Tendermint 链上运行自己的桥接，并进入自己的链上，作为可信的第三方和共识网络发挥作用。这些都是相对简单的解决方案，但它们确实使 Interchain 生态系统能够连接到更广泛的区块链生态系统。

Gravity

• 运行一个 Cosmos 链作为共识网络，以确保在 Cosmos 生态系统中可使用的 ICS 资产的安全并进行加密。
• 验证者需要运行一个完整的 ETH 节点
• 通过中继网络连接（在这种情况下，它不像 IBC 那样是无信任的），这增加了一个信任假设，因为他们控制着他们的 Cosmos SDK 区，因此如前所述，他们需要运行自己的 Eth 节点。
• 与 Gravity 连接的流动性是在 Ethereum 的智能合约中。
• 不可升级合约，只有轻微的逻辑升级是可能的。
• 信任假设在于 Gravity 桥的 valset，智能合约的安全风险和有利益冲突的中继器网络。

Axelar

• 与 Gravity 类似，它依赖于 Axelar 链的验证者，在 Axelar 上的链上运行节点/轻客户端。
• 与 Gravity 同样类似的是，它对交易也进行批处理。
• 也依赖于智能合约，需要移植到新上链的目标语言上。Axelar 目前比 Gravity 支持更多的链，而 Gravity 只支持 Ethereum。这些智能合约并不是流动性的智能合约，而是一个可以调用其他合约的智能合约。这意味着他们在理论上的操作就像一个网关或一个轻型节点，其中传递的消息符合 Axelar 提供的逻辑。桥接，如 Satellite，可以使用基础设施来建立一个实际的流动性桥接并桥接资产。
• 允许一般的消息跨链传递，并以应用为目标，将 Axelar 作为消息传递协议，就像 IBC 以及 Polymer 和 Composable 所针对的那样。
• 允许应用程序使用他们的基础设施。类似于 LayerZero 不是桥接，但 Stargate 是。这是一个可靠的比较，然而，请记住，Axelar 经营着自己的共识网络，即它的 Cosmos SDK 链，它的验证者也为连接的系统运行节点。
• 目前，受信任的验证者有 60 个（尽管对于其中的一个子集或有时全部的子集，不是所有的验证者都在连接的链上运行节点）。所以显然也要考虑到智能合约的风险，同时，如果你使用通过他们的基础设施连接的桥，他们也是智能合约。

接下来，我们将看一下 LayerZero，它确实在一般的跨链消息协议世界中掀起了风暴，并看到了巨大的吸引力。需要再次指出的是，L0 不是桥接，而是一个消息传输协议，你可以用它来建立桥接，或者用来调用跨链智能合约。

LayerZero‌

• 两个实体 -- 预言机和中继器。
• 预言机将区块头转发给目标链，而中继器将源链的交易证明与预言机转发的信息进行对比，证明交易/消息是有效的。
• 应用程序可以灵活地使用 LayerZero 默认的预言机和中继器，或者创建和运行自己的。它们被用作跨链的信息传递协议，而不是一个实际的代币桥。但是你可以用它建立桥接，比如 Stargate 和其他的桥，用它们来传递消息。
• Endpoint，是他们的 Axelar 的 Gateways 版本，或者 Polymer 的 IBC 逻辑智能合约。他们基本上像 IBC 中的轻客户端一样处理验证。
• 这确实意味着你和 Axelar 一样，依赖于 LayerZero 的基础设施，然后是连接到 LayerZero 的智能合约。
• 如果这两个人中有一个不诚实，交易就会失败。然而，如果两个人都不诚实（如果你依赖中心化的解决方案或应用程序自己的解决方案，这可能是一个问题），就有可能被利用。因此，这里使用的去中心化预言机网络是至关重要的，也有多种选择，并可能使用综合预言机 -- 如果需要的话，可参考相关部分。
• 不依赖于可信的第三方链，而是依赖于一个模块化的架构，可以有不同程度的安全和信任。

• 与正在使用的预言机/中继器解决方案以及自然智能合约风险一样安全。
• 不提供或依赖任何加密经济安全的说法。然而，它确实依赖于所用网络的加密经济安全，包括预言机使用的的经济安全。中继器的安全，如是否是多签等等。此外，它也有对所使用的智能合约的信任假设。

接下来，让我们看看 “Optimistic Bridges”，这里我特别指的是 Nomad 和他们的一些合作伙伴。这显然有一些内涵，但请记住，这个漏洞并不是桥接机制的结果，而是网络的安全性未能覆盖的一个智能合约的漏洞。

Optimistic Bridges

• 交易/数据发布到一个合约函数，就像之前提到的 Endpoints/Gateways。
• 桥接代理签署 Merkle 根的数据是正确的，并发布它。然后任何中继器都可以将其发布到想要的目标链上。这个代理必须绑定代币，如果发生欺诈，代币会被罚没。
• 在数据发布后，一个防欺诈的窗口就会开启，任何链上的观察者（因为他们得到了代理的债券而受到激励）可以证明源链上的欺诈，债券便会被罚没。然而，目前，这类链上罚没是不可能的，所以它必须发生在链下网络，且通常是半手动的。
• 如果在时间范围内没有发送欺诈证明，那么数据在目标链上被认为是最终的，可以在目标链上调用合约。
• 这种技术有一个低信任假设，然而，它在很大程度上依赖于智能合约和观察者的工作。如果有任何智能合约被利用，观察者就无法做任何事情。
• 他们只需要一个诚实的观察者，因为只有单方需要正确验证更新。
• 这确实意味着绑定的可罚没质押需要不是非常高，因为你依靠的是只有一方是诚实的这一事实。
• 需要去中心化的代理，否则，一个人就可以停止系统的运行。
• 需要对观察者征税以防止 DoS，然而，这意味着如果从来没有任何欺诈行为，你也不会得到任何东西，这需要不同的激励方案，除非你只是依靠桥接的活动者来运行它们，但这也导致了中心化，因为观察者/活动者和协议都会运行一切。
• 加密经济安全取决于所使用的具体网络。它可能是观察者或代理人的加密经济安全，这些观察者或代理人有绑定的代币才被允许参与。对于限制他们的影响有各种方法，如之前讨论的那样。

接下来让我们来介绍一下多方计算（MPC）的桥梁，其中一些也依赖于自己的可信第三方外部验证的共识网络，如区块链。这种解决方案的两个例子是 Qredo 和 Chainflip。Synapse 也与他们的无领导 MPC valset 的工作有些类似。

有着外部验证者的多方计算（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 的” 桥接 “是这样运作的：

现在我们已经涵盖了目前用于跨链信息传输协议和桥接的绝大部分解决方案的类型。接下来，让我们来看看有关协议安全的另一个非常重要的部分，即协议的经济性。该部分特别有趣的是协议的加密经济安全，即如果它有一个代币，可以赋予治理权力或允许你接管协议本身的一个重要部分。

桥接经济学

让我们从一个假设开始 -- 假设有一个带有治理代币的桥接协议，允许对协议的升级进行投票，或者允许控制协议的核心函数。现在，如果锁定在协议中的总价值远远超过了通过提案的法定人数，那么攻击协议的价值就很明显。这个简单的假设就是为什么桥接经济和治理功能对桥接极其重要的原因。在治理方面，缓解这种情况的一个方法是利用一个稍有细微差别的治理原则，称为 Optimistic Approval，如前面所述。

加密经济安全是区块链桥和跨链消息协议的一个重要方面，需要一个精心设计和实施的激励和抑制系统来确保系统的安全性和完整性。这就是为什么那些不一定依赖可信第三方的加密经济安全的系统效果最好的原因。在系统中，依靠桥接的加密经济安全来确保各个链上的资产，显然不如依靠链上的加密经济安全本身更安全。

然而，目前，大多数桥接和跨链信息传输协议都依赖于可信第三方的经济。显然，这在该 valset 非常安全的情况下可能是相当理想的，但在其他情况下也可能会出现问题。此外，还有其他机制的用法，可以用来保证参与网络的安全，比如可验证延迟函数，它可以在依靠这种行为者的网络中为参与的预言机增加随机性。

其他需要考虑的经济方面是经常使用加密经济价值的网络，如在 multisigs、valsets、mpc 甚至阈值中。这些往往依赖于诚实的多数假设，这意味着攻击这些桥接的成本是占领 51% 的网络的成本。

受信任的第三方

在区块链桥接中使用受信任的第三方既有优势也有劣势。一方面，这些第三方提供了一个集中的、受信任的协调点，这可以使不同网络之间的资产和数据的转移更容易管理和安全。在不同的网络有不同的安全和共识模式，或者需要额外的监测和控制水平的情况下，这可能特别有用。

另一方面，使用受信任的第三方在系统中引入了一个潜在的故障点。如果第三方被破坏，有可能导致资产或数据的损失。此外，将权力集中在受信任的第三方，有可能破坏系统本身的去中心化和去信任。

速率限制

另一个与经济相关的方面，也可以帮助限制攻击造成的损害，那就是对桥接使用速率限制。速率限制的意思是限制每小时可桥接的美元总价值的概念，这样就可以把紧急解决方案落实到位，以挽救桥接的其余部分。

显然，这在用户体验方面造成了问题，特别是对于非常受欢迎的桥接或大型桥接用户来说，同时这也显然增加了一些安全性。例如，你可以限制每小时可桥接的总金额为 1000 万美元。那么，绝大多数用户/零售商不会注意到这一点，而且这将把漏洞中可能造成的损失限制在一个更小的数额。这在过去的漏洞中显然是相当有用的。

那么，速率限制应该是多少，有什么神奇的数字吗？这取决于所述桥的采用，也取决于被桥接的链。例如，在 Arbitrum<>ETH 桥上，需要被桥接的量可能很大，因为它很流行。而在游戏专用的应用链或 rollup 的情况下，并不需要大量的价值传递，所以你宁愿确保用户的资金安全。在这种情况下，速率限制会有很大的意义。

当然，负面影响也是显而易见的，即降低流量，将大玩家排除在外。然而，安全问题是表示比这些更重要？

一个解决方案可能是实施 “桥接车道的高速公路”。为不同的解决方案和人建立不同的桥接。这样做的一个明显的缺点是，这将带来流动性和交易量的分散。对于一个游戏专用的 rollup，限制较低的金额是有意义的，因为你不需要大资金交易，且你想在任何情况下确保用户的资金安全。

其他一些需要记住的事情是：

• DoS 攻击，所以你需要对大交易量进行一定的收费。
• 你想为增长进行优化，但这给增长带来了一点阻碍。

正如本文所表明的那样，一路走来都是权衡利弊。因此，当涉及到速率限制时，情况也是如此。然而，这是一个我们希望看到更多实验的领域。在大多数情况下，没有明确的最佳方案，但总的来说，在这个领域尝试新的和大胆的东西是值得的。没有任何最终设计是理想的，但安全和保障应该是任何协议的最大关切。可以这么说，速率限制允许我们为少数人牺牲用户体验，并为多数人提供安全。

互操作性和可组合性

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

只有当链和应用之间的交易成本很低时，可组合性才真正可以持续，否则，它就失去了可组合性赋予你的主要价值。可组合性为终端用户带来了更多的选择，并且能够在各种生态系统和应用程序之间无缝地进行操作，同时消除了先前的障碍，如从头开始构建生态系统。

当应用程序能够与其他应用程序交互时，它们就是可组合的，如自动流动性头寸、借贷等。

我们已经尽量客观地提供了关于跨链互操作性的当前状况的清晰概述，并希望它为作为读者的你提供某种价值。如果你有任何不同意的地方，或者觉得被误导了，那么请在 Twitter 上联系作者 @0xrainandcoffee。

最后，感谢 Runtime Verification 对智能合约部分的投入，也感谢文章的其他读者提供的帮助。

关于桥接中信任最小化的进一步阅读，我强烈推荐阅读来自 Celestia 的 Mustafa 的 Clusters。

免责声明：作为区块链信息平台，本站所发布文章仅代表作者及嘉宾个人观点，与 Web3Caff 立场无关。文章内的信息仅供参考，均不构成任何投资建议及要约，并请您遵守所在国家或地区的相关法律法规。