撰文：NIC Lin

  

本文將介紹跨鏈橋是什麼並將跨鏈橋進行分類與比較，搭配一些著名跨鏈橋攻擊事件進行分析。 

什麼是跨鏈橋

 
跨鏈橋是一個在不同鏈之間負責傳遞「訊息」的橋，至於是什麼樣的訊息，接下來會介紹。跨鏈橋的例子包含Multichain 、 Celer 、 LayerZero 、 Nomad 、 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 版本就是一個運行在多個網路之上的抵押借貸平台。
 

限制與挑戰

 
但跨鏈橋並沒有像上面那個例子這麼簡單。跨鏈橋的一個最根本的限制來自於「鏈不知道彼此存在」這個事實，因此它需要「相信某個人來傳遞訊息」。所以跨鏈橋的主要挑戰就在於「要怎麼驗證一個送來的訊息的有效性」。
 
注：這裡的「相信」訊息傳遞者並非指完全相信，後面的段落中會介紹到有些橋是不需要相信訊息傳遞者的。傳遞者可能是好人也可能是壞人，但對傳遞者（們）的特質會有一些其他的假設。
 

安全性

 
基本上一個跨鏈橋的安全性取決於：
 
  • 需要放多少信任在訊息傳遞者身上？對訊息傳遞者的行為有沒有一些假設？是否假設訊息傳遞者只能誠實地執行他的工作？
  • 如何驗證訊息的有效性？
 
接下來將介紹不同跨鏈橋的分類。
 

跨鏈橋的分類

 
跨鏈橋基本上可以分成四種：
 
  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 的安全性彼此是獨立、不互相影響的。
 
例子： 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 了CrossChainMessageRequestedevent（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  以上是四種跨鏈橋的介紹，接下來會分析每一種跨鏈橋發生過的攻擊事件。 

攻擊事件分析

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聯繫我們，本平台將立即更正。 】

來了就點個“贊”唄