万字长文最全综述区块链桥安全和信任假设

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

前几个月里，我们看到代币桥成为黑客攻击的目标，而攻击手段越来越复杂。一些人开始讨论桥接到底有多安全。因此，我们想对区块链桥接的安全性和信任假设进行全面概述，包含大多数消息传输协议、桥接和互操作性项目。此外，我们还将浅析跨链消息传输协议和桥接经济学，因为如果协议代币能让你对其进行管理控制，那么这方面也是极其重要的。

首先，让我们明确下桥相关协议上的漏洞攻击问题到底有多严重。

可以清楚地看到，随着现有链数量的增加，桥接漏洞攻击已成为巨大问题。除非我们优先考虑安全问题，否则这必会发展为一个更加系统化的风险，而作为用户的我们需要肩负协议责任站在最前沿——归根结底，毕竟那都是我们的资金。这也是我们撰写本文的初衷——关注互操作性领域中的信任假设和安全性问题。

同样，由于行业变得越来越注重多链、应用链和模块化，我们也见证了大量新兴区块链和层的涌入。为了适应用户和流动性需求，互操作性是必要的。因此，随着越来越多的区块链开始建设自己的生态系统，桥接变得越来越重要，越来越受欢迎，尤其是代币桥。人们需要将流动性从一个链转移到另一个链。于是，代币桥很受欢迎。尽管这不并是桥接的唯一用例。这里我们需要特别提到通用消息传输协议，例如IBC，它通过自身的消息传输系统和标准支持了大量用例。

下面，你可以很好地概览有多少资产被桥接在各链上：

这明确地显示了桥接需求，突出了为什么在涉及跨链消息传输协议和桥接时，我们推动安全性建设是如此至关重要——因为它们处理的是巨额价值，传输量巨大，在很多情况下常由多签智能合约进行托管。

在大多数桥接应用程序和跨链消息传输协议中，有一系列操作有助于提高效能。你将在下文看到。但是，它们依赖于特定的桥接/消息传输协议：

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

中继器（Relayer）：负责消息传递/中继（中继器通常只是传递消息的信使，而非共识参与者），将信息从源链传递到链下操作的目标链。

共识（Consensus）：监控链的主体间达成的协议，形式可以是可信的第三方valset，例如Axelar或共识节点的链下网络，甚至是多签。

签名（Signature）：桥接主体对消息进行加密签名，可能是验证者对加密签名进行签名，例如引入IBC，或例如Polymer使用ZKP（如Plonky2）对来自源链的验证者签名进行验证。

（桥接主体与通用架构）

这些协议可主要分为以下四类：

托管桥接（通常是特定资产的桥接，但你甚至可以称交易所为托管桥接）：以托管（通过第三方）或非托管（智能合约）方式提供包装资产。此类协议的一个例子是wBTC，它有一个中心化商家BitGo，BitGo铸造等效的ERC-20代币（即以太坊上的wBTC）。稍后我们将讨论这种解决方案的信任假设和风险问题，但仅通过此处解释，便可见一斑了。

特定多签链：这些通常是两条链之间的双向桥接，如Harmony Bridge、Avalanche Bridge和Rainbow Bridge，全部通过以太坊上的智能合约将各自的链连接到以太坊。用户通常将资产发送到协议，在那里资产被作为抵押品持有，并在目标链上发行一个桥包装代币，由源链上锁定在合约里的抵押品支持。这些通常由一组验证器保护，甚至只由一个多签保护。我们已然知晓这些解决方案是容易出现风险的——例如Ronin Bridge及近期的Harmony Bridge桥攻击事件。

特定应用程序：提供对多链访问，但仅用于该特定应用程序，例如Thorchain，它还使用单独的验证器集运营自己的链。这些信任假设通常存在于一个验证器集中，该验证器集控制并处理网络上连接到各链上不同智能合约/地址的所有消息和交易。

通用跨链消息：跨链消息传输协议，允许跨带指令设置的链进行通用消息传输，例如IBC。这些通常依赖于验证器集。在这里，信任位于两个链相连的验证器集中。就XCM来说，信任取决于中继链（Polkadot）。你还可以添加诸如Polymer和LayerZero之类的消息传输协议，它们都是不可知的。

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

（上述桥接类型的简化操作架构）

下文内容将介绍跨链协议的两个重要部分，即所涉智能合约风险和需要考虑的额外信任假设。

智能合约风险

首先要关注的最明显的安全风险之一就是智能合约风险。智能合约用于大多数没有原生通用消息传输协议的跨链桥接，所以，它们的安全性至关重要。那么，让我们来讨论一下这里需要强调的一些风险。避免这些风险最有效的方法就是完全不使用智能合约，而是依赖相关链的安全性。

（1）调用合约的正确语句

a. 哪些函数可能在执行前依赖预定义条件。

b. 断言条件以检查全部函数执行所需均为true的事项，例如桥流动性合约余额。

c. 如不满足所需条件（如上述条件），则恢复可触发语句。

（2）正式验证和严格测试

a. 合约的正式验证对于确保所述智能合约在特定条件下的正确性非常重要。可以运行吗？是否按照我要它遵守的规格运行？