跨链桥真的不能碰？一文详解跨链桥的分类以及过去、现在与未来|alice|使用者|有效性|翻译|链桥

本文将介绍跨链桥是什么并将跨链桥进行分类与比较，搭配一些著名跨链桥攻击事件进行分析。

什么是跨链桥？

跨链桥是一个在不同链之间负责传递“讯息”的桥，至于是什么样的讯息，接下来会介绍。跨链桥的例子包含Multichain、Celer、XY、Nomad、Rainbow Bridge、Hop等等。

链是不知道彼此的存在的

大家熟悉的跨链桥使用场景绝大多数都是将资产例如ETH、BTC 进行跨链。但实际上“资产”是没办法跨链的，这是因为每一条链都是各自独立的，它们不会知道彼此的存在、彼此的状态。

至于Solana上的ETH或ETH上的BTC 是怎么来的？那些都是跨链桥铸造出来的，只要这些跨链桥是安全的，这些铸造出来的币就是安全的。

注：其他像是USDT或USDC，有些是Tether 和Circle 到不同链上去铸造出来的，剩下则一样是由跨链桥所铸造。

传递什么“讯息”？

表面虽然是资产在跨链，但背后实际上就只是“讯息”在跨链而已。这些讯息像是“我在A 链上把X资产锁住/烧毁了”或“我在B 链上把Y资产解锁/铸造出来了”，讯息的接收方就按照讯息内容来执行相对应的处理。

例如当Alice想透过一个跨链桥把USDT从A 链“转移”到B 链，实际上背后发生的是：

跨链桥在A 链的合约把USDT 从Alice 身上转过来，并送出一个讯息：Alice 在我这锁住了10 USDT。
讯息被带至跨链桥在B 链的合约，合约从自己身上转10 USDT给Alice在B链上的地址

资产跨链实际上背后是单纯的讯息传递，中间省略许多细节

”讯息“的传递是跨链桥的核心，现在最常见的资产跨链只是其中一种用途而已，像Aave的V3版本就是一个运行在多个网络上的抵押借贷平台。

限制与挑战

但跨链桥并没有像上面那个例子这么简单。跨链桥的一个最根本的限制来自于”链不知道彼此存在“这个事实，因此它需要”相信某个人来传递讯息”。所以跨链桥的主要挑战就在于”要怎么验证一个送来的讯息的有效性”。

注：这里的”相信”讯息传递者并非指完全相信，后面的段落中会介绍到有些桥是不需要相信讯息传递者的。传递者可能是好人也可能是坏人，但对传递者们的特质会有一些其他的假设。

安全性

基本上一个跨链桥的安全性取决于：

需要放多少信任在讯息传递者身上？对讯息传递者的行为有没有一些假设？是否假设讯息传递者只能诚实地执行他的工作？
如何验证讯息的有效性？

接下来将介绍不同跨链桥的分类。

跨链桥的分类

跨链桥基本上可以分成四种：

Trusted Relayers
Optimistic Verification
Light client + Trustless relayers
HTLC

（如果对分类有其他想法或意见都欢迎留言或信件讨论。）

1. Trusted Relayers

顾名思义，Trusted Relayers就是信任讯息传递者。基本上相信讯息传递者后，也不需要再验证讯息有效性了，只要是信任的讯息传递者带来的讯息都相信是有效的。而自然地当有了信任及中心化的假设，架构就会简单许多，而且成本会很低、使用体验会很好。

Trusted Relayers的技术没什么特别之处或亮点，就看这些讯息传递者的组成，可以是单个或多个（就像多签）；每一个讯息传递者背后也可以是多签或是MPC。

这里必须要提到的一点是Trusted Relayers 的安全假设是Honest Majority，也就是过半数的讯息传递者必须是诚实的好人。如果超过一半的讯息传递者是坏人或被骇客入侵，则这个跨链桥的就不再安全。

另外要提到的是Layer Zero也是属于Trusted Relayers，即便在他们的定义里讯息传递者的角色被分成”Oracle”及”Relayer”，但还是不改变整个桥的安全性仰赖这两个角色不能都是坏人。不过Layer Zero 相较于其他Trusted Relayers 桥的优点是：每个dApp 能自己客制化自己需要的安全性。如果你很需要安全性，你可以把”Oracle”及”Relayer”的数量设定的很高。另一个优点是：每个dApp 的安全性彼此是独立、不互相影响的。

例子：Multichain、Celer、LayerZero、Wormhole、Ronin Bridge、XY

2. Optimistic Verification

和Optimistic Rollup的Optimistic 一样，都是先乐观地接受传递过来的讯息，但会验证讯息的有效性，如果发现是无效的则发起挑战。优点是绝大多数的时间系统都会是正常运作（因为作恶会被挑战并惩罚），讯息都是有效所以不需发起挑战，所以成本非常低，因为不需要在链上去验证讯息。缺点是必须要有一段挑战期（Optimistic Window），让负责验证的人有足够多时间验证并发起挑战。接下来会以Nomad为例，介绍Optimistic Verification 的运作。

Nomad里有三个角色：Updater、Relayer及Watcher。

Updater抵押担保品，并负责为讯息签名做担保，例如：我以我的担保品发誓Alice 申请要从链A送XXX讯息到链B；
Relayer 单纯负责把讯息及Updater 的签名送到目标链（链B）上；
Watcher 负责监督Updater，并在Updater 作恶时反应

正常情况

Alice触发链A合约，要求送讯息到链 B

Updater 对Alice 的讯息签名

Relayer 负责将讯息及Updater 签名送到链B

等到挑战期（Optimistic Window）结束后，讯息生效，完成讯息跨链。

Updater 作恶

Updater 对一个凭空捏造的讯息签名，并请Relayer 伙伴送到链 B

Watcher 发现后，先到链B 把讯息作废，再把证据（Updater 签名）送到链A，没收Updater 担保品

链A的合约可以很清楚验证Updater所签名的讯息到底存不存在，因为只有使用者亲自送请求到合约，讯息才会真的存在。所以当Updater 对一个不存在的讯息签名，这个签名就会变成作恶的Updater百口莫辩的证据，用来没收Updater的担保品。

证据只在讯息来源链（链A）有效

目标链（链B）永远没办法知道链A 上有谁要送什么讯息过来，所以链B 合约没办法知道Updater担保的讯息到底是不是真的。

那链B 能怎么办？答案是需要引Permissioned Watcher。Permissioned Watcher有权利能作废任何一个讯息，避免伪造的讯息造成任何破坏。但相反地它也可以作废一个正常的讯息，也因此这个角色必须要是Permissioned，他需要是一个被信任的角色。

如果有Permissioned Watcher乱搞，恶意作废正常的讯息，则这时候只能仰赖另一层信任，可能是Governance 或是一个多签Admin 之类的来介入，将恶意的Watcher 剔除。

只需要假设至少有一个Watcher有在做事

和Trusted Relayer的安全假设非常不同，相对于Trusted Relayer 需要假设有过半数诚实参与者，Optimistic Verification只需要假设至少有一个Watcher 是好人即可。这表示要攻破Optimistic Verification，你需要攻破（例如骇入、贿赂、DoS）全部的Watcher。

30分钟挑战期

不同于Optimistic Rollup挑战期多达七天，Optimistic Verification的挑战期只有30分钟。这是因为Optimistic Verification的挑战不需要挑战者与被挑战者之间来回交互，而是直接提交一个一次定生死的证据：Updater 签名的讯息存不存在？（yes/no）。

3. Light client + Trustless relayers

这种跨链桥的方式是让目标链成为来源链的轻节点，可以是链下运行一个轻节点，也可以是用链上合约模拟一个轻节点：合约里记录来源链每个区块并验证每个区块的标头档（Block Header）。除了验证标头档的内容是有效的之外，还需要验证共识，也就是PoW 的验算或PoS 的投票结果。PoW 的验算还算简单，但PoS 的投票结果就复杂许多，尤其是像Ethereum Beacon Chain 多达四十多万的Validator，要维护这些名单在合约或计票的成本都非常高。

另外每条链的区块内容和共识机制都不一样，因此要支援新的一条链并非简单的工作，再加上验证成本会比其他跨链桥高上许多，这些都是这种跨链桥的主要缺点。不过优点是它非常安全，它不需要相信负责带区块资讯来的Relayer，它会自己验证区块和共识。

Light Client 合约验证Relayer 带来的链A 的区块资讯及共识

注：虽然Relayer 只是跑腿的，但还是需要假设有诚实的Relayer 在线，确保正确的区块资讯会被带过来，避免造假的分叉链来破坏安全性。

验证完区块标头档后，剩下就是去验证(1) 交易存在于某个区块，或是(2) 某个event 在某个区块被emit，或是(3) 某个地址的storage 是某个值。举例：

(1) 像是验证BTC 上Alice 转帐给某个地址，或是在OP_RETURN 附上某个讯息

(2) 像是验证ETH 上的Bridge 合约确实emit 了CrossChainMessageRequested event（event 的receipt 会存在receipt tree，tree root 会记录在标头档里）

(3) 像是验证Optimism 上的Bridge 合约的storage 确实存在一笔资料是记录了Alice 申请的讯息跨链的请求

接着Alice 向Light Client 合约利用(1)(2)(3) 的方法证明自己发起过跨链请求

验证成功后就能相信来源链真的存在一笔讯息跨链的请求。

例子：Cosmos IBC、Near Rainbow Bridge

注：Cosmos IBC 是透过运行轻节点，而不是用合约的方式，在不同（也仅限于） Cosmos 链之间传递讯息。Near Rainbow Bridge 只能在Ethereum、Near、Aurora 三条链之间传递。

除了建造复杂与验证成本高之外，这种跨链桥还有一个缺点是：每条链的Finality 时间不一样，例如BTC 来的资料可能要等六个区块（一小时）、ETH 来的资料可能要等12.8 分钟等等，使用体验会差很多。

4. HTLC

HTLC 代表的是Hashed TimeLock Contract（接下来会假设读者知道HTLC 的运作方式）。

注：HTLC 不一定要用Hash 的方式来做commitment，可以用签章来代替

HTLC 优点是非常安全，但缺点是使用体验比其他跨链桥差很多，例如：

需要花更多笔交易才能完成跨链
使用者必须待在线上直到跨链完成
Free Option Problem，发起HTLC 的人是被动方，对手方可以选择配合或不配合（看哪个对他有利）。不过如果对手方是一个有名声要顾的商家（称作Router）就不需要那么担心这个问题
不同Router 的服务品质会有差异，导致使用体验不一致

例子：Connext、Celer V1

以上是四种跨链桥的介绍，接下来会分析每一种跨链桥发生过的攻击事件。