撰文:NIC Lin

  

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

什么是跨链桥

 
跨链桥是一个在不同链之间负责传递「讯息」的桥,至于是什么样的讯息,接下来会介绍。跨链桥的例子包含MultichainCelerLayerZeroNomadHop等等。
 

链是不知道彼此的存在的

 
大家熟悉的跨链桥使用场景绝大多数都是将资产例如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 版本就是一个运行在多个网路之上的抵押借贷平台。
 

限制与挑战

 
但跨链桥并没有像上面那个例子这么简单。跨链桥的一个最根本的限制来自于「链不知道彼此存在」这个事实,因此它需要「相信某个人来传递讯息」。所以跨链桥的主要挑战就在于「要怎么验证一个送来的讯息的有效性」。
 
注:这里的「相信」讯息传递者并非指完全相信,后面的段落中会介绍到有些桥是不需要相信讯息传递者的。传递者可能是好人也可能是坏人,但对传递者(们)的特质会有一些其他的假设。
 

安全性

 
基本上一个跨链桥的安全性取决于:
 
  • 需要放多少信任在讯息传递者身上?对讯息传递者的行为有没有一些假设?是否假设讯息传递者只能诚实地执行他的工作?
  • 如何验证讯息的有效性?
 
接下来将介绍不同跨链桥的分类。
 

跨链桥的分类

 
跨链桥基本上可以分成四种:
 
  1. Trusted Relayers
  2. Optimistic Verification
  3. Light client + Trustless relayers
  4. 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 的安全性彼此是独立、不互相影响的。
 
例子:MultichainCelerLayerZeroWormholeRonin BridgeXY
 

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 了CrossChainMessageRequestedevent(event 的receipt 会存在receipt tree,tree root 会记录在标头档里)
 
(3) 像是验证Optimism 上的Bridge 合约的storage 确实存在一笔资料是记录了Alice 申请的讯息跨链的请求
 

接着Alice 向Light Client 合约利用(1)(2)(3) 的方法证明自己发起过跨链请求
 
验证成功后就能相信来源链真的存在一笔讯息跨链的请求。
 
例子:Cosmos IBCNear 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
 
以上是四种跨链桥的介绍,接下来会分析每一种跨链桥发生过的攻击事件。
 

攻击事件分析

1. Trusted Relayers 跨链桥的攻击事件


1) Multichain, 2021.07, ~8M loss


在他们的MPC 套件库中重用了该是随机产生的随机值,导致私钥可以被还原。相关链接:
  • https://medium.com/multichainorg/anyswap-multichain-router-v3-exploit-statement-6833f1b7e6fb
 

2) PolyNetwork, 2021.08, ~600M loss

智能合约漏洞导致攻击者能获得存取协议资产的权限。相关链接:
  • https://en.wikipedia.org/wiki/Poly_Network_exploit
  • https://certik.medium.com/polynetwork-hack-analysis-a86513f2a730
 

3) Multichain, 2022.01, ~3M loss


智能合约漏洞导致攻击者可以任意转走受害者的wrapped token(例如WETH、WBNB 等)。相关链接:
  • https://medium.com/multichainorg/action-required-critical-vulnerability-for-six-tokens-6b3cbd22bfc0
  • https://halborn.com/explained-the-multichain-hack-january-2022/
 

4) Qubit, 2022.01, ~80M loss

智能合约漏洞以及合约升级过程的疏忽,导致攻击者可以直接把协议里的资产全部提走。相关链接:
  • https://certik.medium.com/qubit-bridge-collapse-exploited-to-the-tune-of-80-million-a7ab9068e1a0
 

5) Wormhole, 2022.02, ~300M loss

智能合约漏洞让攻击者可以跳过权限检查,无限铸造出新的代币。相关链接:
  • https://wormholecrypto.medium.com/wormhole-incident-report-02-02-22-ad9b8f21eec6
 

6) Ronin Bridge, 2022.03, ~600M loss

多签成员(九个里的五个)的节点被攻陷。相关链接:
  • https://www.theverge.com/2022/7/6/23196713/axie-infinity-ronin-blockchain-hack-phishing-linkedin-job-offer
 

7) Horizon Bridge, 2022.06, ~100M loss

多签成员(五个里的两个)的私钥被盗。相关链接:
  • https://halborn.com/explained-the-harmony-horizon-bridge-hack/
 

2. Optimistic Verification 跨链桥的攻击事件

Nomad, 2022.08, ~190M loss

智能合约漏洞及合约升级过程的疏忽,导致任何人都可以伪造跨链讯息来转走资产。相关链接:
  • https://www.coinbase.com/blog/nomad-bridge-incident-analysis
 

3. Light Client + Trustless Relayers 跨链桥的攻击事件

Near Rainbow Bridge, 2022.05 & 2022.08, no fund lost

两次尝试伪造跨链讯息的攻击都被watchdog 服务挡下来。相关链接:
  • https://decrypt.co/108015/nears-rainbow-bridge-blocks-another-attack-costing-hackers-5-ethereum
 

4. HTLC 则没有过攻击事件

 
其实可以看出来攻击事件都是发生在Trusted Relayers 节点安全管理问题及合约出现问题,没有针对Optimistic Verification、Light Client 或HTLC 跨链桥本身协议成功的攻击事件。
 

跨链桥的比较

 
接着是不同种跨链桥技术在「成本(Cost)」、「使用者体验(UX) 」及「安全性(Security)」三个方面的比较。以下会直接以图片呈现
 

 

1. 成本(Cost)

 

 
  • Trusted Relayers:成本最低,因为不需什么复杂的验证,Relayer 带来的资讯都直接相信
  • Optimistic Verification:只需要验证Merkle Proof
  • Light Client:要验证最多东西,包含共识、区块标头档及交易或状态的证明
  • HTLC:验证的东西很简单,但会需要多笔交易(Lock/Unlock)才能完成
 

2. 使用者体验(UX)

 

 

  • Trusted Relayers:体验最好,Relayer 动作多快跨链就有多快,使用者也不需要做什么事
  • Optimistic Verification:需要等待挑战期(Optimistic Window),以及有可能遇到Updater 下线或Watcher 恶搞
  • Light Client:需要等待Finality、不同链会有不一样的体验,且支援的链少
  • HTLC:需要多笔交易(Lock/Unlock)才能完成、使用者需要保持在线、Router 们的服务品质不一致
 

3. 安全性(Security)

 

 
  • Trusted Relayers:安全性最低、需要大多数多签成员是诚实的假设,或是少部分成员被DoS 打下线也会造成服务停摆
  • Optimistic Verification:只需要假设至少有一个Watcher 是诚实的,但Updater 被DoS 打下线还是会造成服务停摆
  • Light Client:非常安全,必须要能攻击那些链的共识才有可能造成伤害
  • HTLC:最安全,必须要攻破hash function 才有可能造成伤害
 

Rollup Bridge 和跨链桥的不同

 
Rollup Bridge 指的是Rollup 和其L1 之间的原生桥,因为L1 和Rollup 之间可以直接传递讯息,且讯息的有效性是被零知识证明或诈欺证明所保障的,所以比L1 与L1 之间的跨链桥还要安全许多。
 
不过Rollup 原生桥会有一些延迟:ZK Rollup 要等待零知识证明产生并上链、Optimistic Rollup 要等待挑战期结束。
 
注:延迟主要是发生在Rollup -> L1 的讯息,L1 -> Rollup 的讯息都非常快速。
 
如果不想等待则可以使用第三方提供的服务:你用原生桥的方式转钱给第三方,第三方在L1 先把钱垫付给你,他再慢慢等钱从原生桥过来。更多关于Rollup Bridge 的介绍可以参考imToken 的系列文《Rollup Bridge 介绍(一):Maker DAI Bridge》:

https://medium.com/imtoken/rollup-bridge-%E4%BB%8B%E7%B4%B9-%E4%B8%80-maker-dai-bridge-678c62228eb5

 

使用跨链与提供流动性的安全性需求是不同的

 
如果你只是单纯使用跨链服务,例如把钱从链A 转到链B,则你不需要担心太多,即便桥被骇,只要桥还有残存流动性或后来有新注入的流动性,你的跨链请求就一定会被完成。
 
但如果你是想要提供流动性给跨链桥来赚跨链手续费的话,就要谨慎选择跨链桥了。如果被盗的金额太大,项目方赔不出来,那你就一定会赔钱。可以选择有额外安全机制的跨链桥,例如Celer 和XY 都有对跨链转帐订一个上限(例如单次或一段时间内最高累积只能转100M)。
 
其实就和使用AMM 一样,提供流动性一定会承受比单纯swap 更大的风险。
 

最近的新技术或发展

1) ZK Light Client Bridge

前面有提到Light Client 跨链桥虽然安全,但成本很高,好消息是零知识证明可以有效降低这个成本。但要注意的是零知识证明只能提高效率,并不能提高安全性。而且零知识证明更为复杂,要等到ZK Light Client 支援足够多的链还要很长一段时间。
 
有两个新项目在实作ZK Light Client:

  • Succinct Labs
    https://blog.succinct.xyz/post/2022/09/20/proof-of-consensus
  • zkBridge
    https://twitter.com/dawnsongtweets/status/1574775694139314176
 

2) 跨链的世界还是个尚未开发的MEV 宝地

 
  • 跨链交易比单链转帐创造出更多的MEV 机会
  • 如果跨链交易再搭配去DEX 做swap 的话那MEV 机会又更多
 
想了解更多资讯可以参考 Nomad 创办人在 ETHAmsterdam 的MEV Day 的演讲投影片。他推断跨链DEX 做不起来,因为价格会因为更多的MEV 机会影响而导致没有竞争力,要用跨链DEX 还不如单纯先把资产跨链再自己去 DEX swap。
 
原文链接:
https://medium.com/taipei-ethereum-meetup/%E8%B7%A8%E9%8F%88%E6%A9%8B%E6%AF%94%E8%BC%83-4327192f7200
 


**本文仅代表原作者观点,不构成任何投资意见或建议。
 

-END-

【发布文章仅为传播更有价值的信息,文章版权归原作者所有,其内容与观点不代表Unitimes立场。本微信平台出现的图片均在互联网收集而来,版权归版权所有人所有,若版权者认为其作品不宜供大家浏览或不应无偿使用,请添加微信unitimes2018联系我们,本平台将立即更正。】

来了就点个