• <dfn id="njlhd"></dfn><source id="njlhd"></source>

    <source id="njlhd"></source>

      <dfn id="njlhd"><video id="njlhd"></video></dfn>
      <source id="njlhd"><address id="njlhd"><sup id="njlhd"></sup></address></source>

      <b id="njlhd"><small id="njlhd"></small></b>
        <tt id="njlhd"></tt>

          <video id="njlhd"><address id="njlhd"><kbd id="njlhd"></kbd></address></video>
          • 元宇宙:本站分享元宇宙相關資訊,資訊僅代表作者觀點與平臺立場無關,僅供參考.

          跨鏈橋比較

          • Unitimes
          • 2022年10月19日06時

          撰文: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聯系我們,本平臺將立即更正。】

          來了就點個

          Copyright © 2021.Company 元宇宙YITB.COM All rights reserved.元宇宙YITB.COM

        1. <dfn id="njlhd"></dfn><source id="njlhd"></source>

          <source id="njlhd"></source>

            <dfn id="njlhd"><video id="njlhd"></video></dfn>
            <source id="njlhd"><address id="njlhd"><sup id="njlhd"></sup></address></source>

            <b id="njlhd"><small id="njlhd"></small></b>
              <tt id="njlhd"></tt>

                <video id="njlhd"><address id="njlhd"><kbd id="njlhd"></kbd></address></video>
              1. 4438xx亚洲最大五色丁香