# Layer 0 War

By [MatrixDAO](https://paragraph.com/@matrixdao) · 2022-09-07

---

作者：CE, MatrixDAO Research Analyst

TL;DR
-----

*   在多鏈已成定局情況下，不同 layer 1 / 2 割裂了流動性與可組合性，使用 cross chain infra 在各鏈傳遞訊息可以整合流動性、提高可組合性，並且提高使用者體驗，過去跨鏈需要數次的操作現在只需一個交易、一次費用、一個介面。
    
*   要完成跨鏈訊息的傳遞必須完成讀、寫、驗證的動作，基本上不同的解決方案就是在以上三點作出差異化，以下表格羅列出不同解決方案在這三個動作上的差異。
    

![](https://storage.googleapis.com/papyrus_images/03d38bed952afb6a83281c442fa88a189ab1b61d126001bdc196ff32f1ae787e.png)

*   對於開發者來說，Security (安全性)、Liveness (穩定度)、Developer Friendly (開發者友好)、Composabiltiy (可組合性)為主要考量因素，不同應用開發者在意的點不同，優先順序也會不一樣。
    

![](https://storage.googleapis.com/papyrus_images/9926aecf849b2053f6e69d1cc373d084adcde8baecc38055d153cab2ff09b9c5.png)

*   這個市場仍在早期階段沒有明顯的贏家，每個 solution 都有各自的 trade off，短期內我們認為 LayerZero 有機 會獲得許多開發者採用，原因是(1) LayerZero 剛好在熊市來臨之前募了相當多的資金，可以給開發者提供更多幫助 (2) 知名度相當高，demo 產品 stargate 上市後吸引數十億美金的資金 (3)自由選擇 oracle 與 relayer 的彈性 可讓開發者自己權衡成本與安全性的 trade off。
    
*   長期來說我們更看好 IBC 有機會成為 Web3 的 HTTP，因(1) 安全性最好且最大短版composiblity 有機會被解決， 許多一鍵發鏈或是跨鏈之鏈的 solution 皆採用 IBC，當越來越多鏈連接 IBC 之後可以帶來更多開發者 (2) IBC是真 正具有 network effect 的協議，其他 solution 更像是跨鏈的 SaaS 服務商。
    
*   IBC 最大的問題是必須要在各個連接鏈上都執行 light client，對於某些鏈如 Ethereum來說成本太高而不可行， 但如果未來零知識證明技術成熟後將執行 light client 的成本大幅下降，或許能讓 IBC 適用大多公鏈。
    
*   期待未來出現開發者工具藉由上述跨鏈訊息的工具將不同 Layer 1 / 2 的概念模糊化，使開發者專心開發產品， 不須擔心不同鏈的用戶與流動性。
    

為何跨鏈訊息重要？Cross Chain Application 帶來甚麼新的 想像空間？
---------------------------------------------

Web2 的 HTTP 通訊協定連結了各式網站並加入安全的溝通管道，造就網際網路的快速發展，Web3 在各 Layer 1 , 2 興起之後發展了許多不同的生態系，但各個生態系各自為政，使得資產、流動性、資料分散在不同的區塊鏈上。

目前用戶可以透過跨鏈橋將資產轉移到不同的 layer1 去做應用，如將 ETH 從 Ethereum 轉成 Avalanche 的 wETH 去 AAVE 上當抵押品，但有了 cross chain infra 之後，用戶不需自行轉移資產，可以直接在 Ethererum 抵押 ETH，並在 Avalanche 借出 AVAX 使用，大大提高 composability，也可以整合不同鏈的流動性，不只是借貸平台，Dex、Yield Aggregator 都可以擁有更好的流動性與收益率，就像是在 Layer 1 底下再建一層 Layer 0 讓彼此互相溝通。

除了 DeFi，cross chain NFT 也能擁有更多用途，有了 general message passing，可以確認是原本的 NFT，並開啟新的可能，如用 Ethereum 的 NFT 在其他鏈當抵押品、或是創造一個 dAPP 可以利用各個鏈的NFT而不用擔心 license 或是 loyalty fee 的問題。

除了整合 DeFi 與 NFT 的流動性，提升使用者體驗對於 on-boarding 新用戶非常重要，錢包或是其他的 web3 portal ( 如一個超級出圈的應用如 StepN ) 專注在提高用戶體驗提高用戶留存，背後的交易可以在低成本的鏈上執行，一 旦需要到較為貴的鏈上執行時可以透過跨鏈訊息去呼叫其他鏈的智能合約完成交易，用戶不需要切換不同的鏈。 用戶只在意買到甚麼幣、甚麼NFT、甚麼遊戲角色、流程是否順暢、過程是否安全，其實並不在意在哪個鏈上執 行。2021年經歷了 Layer 1 rotation，人們爭論哪個 Layer 1 是最後贏家，但有了 Layer 0 infra，開發者不必擔心在 某個鏈開發會不會沒有 users、沒有流動性，可以專注在產品以及用戶獲取，對於 blockchain 的注意力可以回到產 品身上。

總結來說，使用cross chain infra在各鏈之間傳遞訊息有以下幾個好處：

*   **成本**：相比資產跨鏈，只傳遞訊息會占用更少的gas，整體用戶成本可以下降
    
*   **整合流動性**：用戶或是應用在不同鏈上的流動性可以被聚合，交易的深度提高，滑點降低，資本使用效率也可以提升
    
*   **提高用戶使用體驗**：過去數次的操作現在只需一個交易、一次費用、一個介面
    

HTTP 是 Web2 的網路公共財，具有極強的網絡效果，但 Web3 的 HTTP 還沒有出現贏家。因此這篇文章想要探討各種不同 Web3 中跨鏈訊息的解決方案，並嘗試以開發者角度思考哪種方案最有機會成為 Web3 的 HTTP。

跨鏈訊息是怎麼傳遞的?
-----------

假設今天用戶在 chain A 儲存 ETH 到某借貸協議，接著要在 chain B 借出 AVAX，其中要傳遞的資訊包括 (1)用戶的確在 chain A 完成儲蓄動作 (2) 向 chain B 的借貸協議借出 AVAX，這兩件事我們可以稱作讀跟寫，可注意的是其中並沒 有涉及資產的跨鏈轉移 ，只有訊息的傳送，我們會稱 chain A 為 source chain，chain B 為 destination chain。

因此要完成跨鏈的訊息傳遞必須要做到以下幾點，基本上不同的解決方案就是在以下三點作出差異化：

*   **讀** — 讓 destination chain 知道 source chain 現在的狀態，是否已經完成交易
    
*   **寫** — 用戶在 source chain 發出的訊息能夠在 destination chain 完成
    
*   **驗證** — 驗證在 source chain 的狀態已經完成且訊息無誤
    

讀的方式包括：

*   **Light client** — 在每個destination chain的節點都跑source chain的light client，讓destination chain可以直接讀取source chain的資料 (block header)
    
*   **Oracle** — 利用oracle來讀取sourced chain最新的資料 (latest block header)
    
*   **Optimistic State** — 樂觀相信某個protocol所寫的sourced chain資料
    
*   **Intermediate chain** — 透過一個中間層的共識來讀取資料
    

寫的方式包括：

*   **Smart Contract (Endpoint / Gateway)** — 部屬在destination chain的一個多簽合約並被source chain的節點 所控制
    
*   **Optimistic Write** — 等待一段時間後若沒有人反對source chain的訊息後就透過destination chain的smart contract寫入區塊鏈
    
*   **Intermediate chain** — 透過一個中間層的共識來執行訊息內容
    

驗證的方式包括：

*   **Natively Verified** — 直接透過source與destination chain的節點驗證
    
*   **Optimistic Verified** — 一定之內若沒有watcher提出fraud proof的話便視為驗證完成
    
*   **Externally Verified** — 第三方共識層所提出的proof
    

各類訊息跨鏈方案比較
----------

### IBC

![](https://storage.googleapis.com/papyrus_images/15ebfc63166cb073334a02a5351fb68515ac3b3ce6130366b5f348a5627262df.png)

讀：在每個鏈上的節點都跑各個鏈的light client，讓所有連結的鏈都知道彼此的最新狀態，若有n個連結的鏈，總共必 須要有n^2的light client，因此工程浩大，且不是所有的鏈都可以跑，像是在Ethereum上跑別的鏈的light client就不符 合經濟效益，Bitcoin因為不支援smart contract也無法，在Cosmos上因為都用同一種共識體系，且將IBC module整 合至其SDK中，因此所有利用Cosmos SDK開發的鏈都可以透過IBC來傳遞訊息。

寫：handshake之後destination chain的validator就會將狀態寫入blockchain。

驗證：雙方IBC module確認各自的finality之後達成handshake，便可以傳送訊息。

### LayerZero

讀：Layerzeo在每個連接的鏈上都會執行一個ultra light client，與light client相比最大的差別是不須下載source chain所有的資料，而是透過oracle傳送source chain最新的block header來讀取狀態，因此在成本上較為節省， 但每次讀取都必須呼叫一次oracle合約，因此若是高頻的訊息傳遞，成本不一定比較便宜。

寫：Endpoint上的validator驗證完之後，會將訊息封包(packet)傳送至communicator，在傳遞至user application 完成訊息所要完成的交易。

驗證：Endpoint上的validator會驗證從relayer收到的transaction proof與oracle傳來的block header是否相符，用 戶可以自行選擇relayer與oracle，會產生安全性的問題的唯一方式是relayer與oracle同時作惡，其實也可以把它想 成2 of 2的multisig，只不過這兩個multisig可以是個人，多人，甚至是PoS。

### Axelar

![](https://storage.googleapis.com/papyrus_images/f7c4f4b4c2be100058bafa386b35bb5d139c0586cfc84841dfd4c58af7e7133f.png)

讀：Axelar是使用cosmos SDK建立的一條鏈，因此內建light client可以讀取Cosmos生態系的資料，但同時也在非IBC 體系的鏈上部屬節點讀取資料，因此可讀取Cosmos, ETH甚至是Polkadot生態系的資料。

寫：在每條鏈上部屬Smart contract (Axelar稱為gateway contract)同時被Axelar Network的validator所控制，若 Network達成共識產生proof，destination chain的smart contract便可以傳達訊息給application。

驗證：Axelar本身就是一個PoS的公鏈，因此當2/3的validator同意即達成共識完成驗證。

### Intermediate chain — Celer IM (Celer Network), AnyCall (Multichain), Chainlink

![](https://storage.googleapis.com/papyrus_images/2c5f5640265ea35ecda34f87da5bf585deebdbb4708fcb64e2d583df30456ce9.png)

讀：因source chain與destination chain之間並沒有訊息溝通管道，需要一個第三方的共識層在每個鏈上部屬smart contract，按造需要讀取不同鏈的資訊，有n條鏈就部屬n個智能合約，相較light client拓展的速度較快，也沒有因為不 同鏈的共識機制不同而無法讀取的問題。

寫：在每條鏈上部屬smartcontract同時被Intermediatechain的validator所控制，若達成共識產生proof，destination chain的smart contract便可以傳達訊息給application。

驗證：以上三種solution都有各自的PoS network，按造各自的要求達到共識進行驗證。

### Nomad

![](https://storage.googleapis.com/papyrus_images/c9fc29eab7354130f25b42944fd45e74381ffb09fe6a254adcafbd4c4bec1cbf.png)

讀：在所有的鏈都部屬home與replica兩種合約，所有destination chain的replica合約會樂觀接受到source chain所update 的訊息。一旦有新訊息，Updater會透過nomad的資料結構將新的訊息更新到所有destination chain的replica合約之中。 但會暫時保留在合約之中並不會向destination chain的validator傳送，稱為「pending update」。

寫：認證成功之後processor會將訊息送至destination chain的validator進行寫入的動作。

驗證：Watchers會觀察updater與home contract互動，一旦有update事件發生便會進行檢查，只要有一位watcher提出作惡證明，在replica的pending update便會取消並逞罰updater，30分鐘後若沒有watcher提出便視為認證成功。

### 比較表

![](https://storage.googleapis.com/papyrus_images/18d0eb2af84ecf1bc08d42754d63059cca13b0f495ba45d9274267af15ac0106.png)

其他類似solution包括Polkadot的XCM、Bybit孵化的Teleport、Synapse的Synapse Chain等，XCM就只侷限在 Polkadot生態系之中所以不討論(這邊要強調IBC與Cosmos是獨立分開的)，Teleport與Synapse Chain雖然也都 主打整合跨鏈的流動性或是訊息，但都必須要求開發者把application移轉到它們的生態系之中，這幾個solution 更像是Layer 1討論，我也認為對於開發者來說，**要在新的一條沒有用戶沒有流動性的鏈重新部屬自己的合約不如 直接用上述的solution就好**，因此本篇暫不討論這幾個solution。

開發者在意甚麼?
--------

以下我們會試著透過 (1) Security (2) Liveness (3) Developer Friendly (4) Composability來嘗試分析各個 solution 的差異，不同application的開發者會在意的點會不同，優先順序也會不一樣。

### Security

安全性絕對是最優先必須考慮的，但不容易衡量，因安全性除了consensus risk 以外還有 smart contract risk，然而 smart contract risk 取決於開發者的能力，與solution的設計關係不大，我們檢查了各個 solution 基本上都經過相當 有名的審計公司如 Certik、Slowmist、PeckShield、Quantstamp 審核，因此**這裡提到的 security 指的是 consensus risk，白話一點是因為驗證出現問題使得 destination chain 讀了錯誤的 source chain 訊息**，如source chain的借貸協 議根本沒有抵押品卻可以讓destination chain的協議借出貸款。

透過 light client 互相驗證 source 與 destination chain block header 的 IBC 是最安全的的通訊方式，因為中間沒有一層 第三方的共識，各個鏈都儲存著各個鏈的歷史狀態，驗證可以由雙方的 validator 來進行，因此驗證錯誤的訊息基本 上不可能，除非soured chain本身consensus已經被攻擊，那就不在本篇文章想討論的範圍，因為不是傳遞錯誤的訊 息，而是訊息本身就是錯誤或是惡意的，當然light client最大問題是因為共識體系不同或是成本過高使在某些鏈上無 法使用，也因此composability較差，後面會詳細討論。

LayerZero的方法則是考慮到light client成本過高的問題，它們稱其為”ultra light client"，既然無法儲存所有連接鏈 上的block header，那就透過oracle傳來最新的block header進行驗證，也因此LayerZero的ultra light client可以用 較低的成本進行驗證，但問題又回到，我們還是得相信oracle傳來正確的block header，所以基本上中間還是有另一 個共識層，並不是真正的trustless，另外LayerZero也讓用戶可以自由選擇oracle與relayer，也就是說LayerZero的 安全性會受到用戶選擇甚麼oracle與relayer來影響。還有一點值得討論的是當用戶可以自由選擇oracle與relayer的 時候，較不會出現系統性的風險，只有選擇某出事oracle的應用才會受到影響，但這點對於開發者來說沒有差別， 因為開發者只會在意自己的application受到攻擊的可能，而不是所有application受到攻擊的可能。

Axelar、Celer IM、Chainlink CCIP、Multichain的anyCall都是透過中間的共識層來維持安全性。Axelar、Celer採用 Tendermint DPoS的共識體系，任何人都可以成為、退出節點，去中心化程度較高，利用token抵押來維持安全性， 因此token市值、抵押的比例都會影響安全性，要特別提到一點是因為Axelar建立在Cosmos體系之上，可以利用 interchain security來提高Axelar的安全性，Chainlink近期推出staking program來進一步增加其DON (Decentralized Oracle Network)的安全性，而$LINK的市值可與layer 1比擬，Multichain的network採用TSS的多簽形成共識，較為中心 化，安全性取決於私鑰的保存，相比PoS network更容易受到consensus的攻擊。另外一點要考慮的是Celer, Multichain, Chainlink都是透過同一套共識體系來做其他業務，Celer、Multichain是資產跨鏈，Chainlink是Oracle，因此同個共識 不同業務所擔保資產的都必須納入考慮，作為駭客攻擊的經濟誘因，如下表呈現，整體來說Chainlink仍是最安全選擇，Multichain最為危險。

![](https://storage.googleapis.com/papyrus_images/fa9cbfcf49895586663c870f7b145fdff471bcb9e6793b423551c73544e6f69f.png)

Nomad的作法基本上也不會有共識的風險，就如同optimistic rollup的安全性等同Ethereum一樣，只有可能訊息本 身是惡意或是錯誤的，也就是說source chain本身安全性出現問題，不太可能會有驗證錯誤的可能性 (訊息跨鏈橋 的安全性出現問題)，但與optimistic rollup最大的不同是驗證時間從7天下降至30分鐘，一旦source chain的down time超過30分鐘，watcher很有可能來不及提出fraud proof而使有問題的訊息發出，但這也能透過使用區塊高度 而非區塊時間來解決，總而言之，在共識風險上問題不大，但如同optimistic rollup一樣，data finality才是最大問 題，訊息必須等30分鐘才能完成確認，為了解決用戶等待太久的問題，Nomad目前與Connext合作來提供立即的 資產流動性。

檢視過去的資產跨鏈的攻擊事件來看，大多數是smart contract的漏洞導致，真正因為consensus risk有所損失的 就只有Ronin Bridge，被駭原因是超過一半的私鑰被駭客掌握，但這個事件導致$625m的資產被盜走，為DeFi史上 最大的損失金額，Security的問題不可不慎。

### Liveness

除了安全性，cross-chain application的開發者當然也會注重**訊息的傳遞會不會突然中斷、要花多久時間等等**，我們 稱之為Liveness，通常是透過relayer來傳遞，也是大部分solution收費的方式。

透過IBC傳送訊息基本上都能立即到達，因為所有連接的鏈都擁有instant finality的特性，liveness的表現優秀，也不 會有額外的費用，除非某個連接鏈的1/3節點停止運行，整條鏈便會停止出塊，訊息傳遞當然也會停止。

LayerZero的liveness就取決於使用哪個relayer傳送訊息，可以由LayerZero提供，也可以由Application自己當 relayer，可能只有一個節點使得liveness表現較為不穩定，也可以由一個去中心化的oracle擔任，因此彈性很高， 若自己擔任relayer可以省去訊息傳遞的費用，甚至提供服務給其他application來收費。

基本上使用第三方共識進行驗證的solution如Axelar, Celer, Multichain, Chainlink大多也都直接使節點成為relayer傳 送訊息，因此liveness取決於network是否持續正常運作，基本上liveness的表現也很穩定。

Nomad方式最容易遇到Liveness的問題，除了時效性較差之外，只要有一個watcher持續地發出fraud proof，理論上 就能阻擋所有訊息的傳送，只不過從經濟角度誘因並不高，因為攻擊者不能得到甚麼好處，他只能癱瘓系統，不能 從系統拿走資金，唯一有誘因的是競爭對手進行攻擊使用戶離開Nomad，不過Nomand未來也會有watcher tax，增 加攻擊的成本。

整體來說liveness還是IBC方法表現最好，接著是依靠第三方共識的solution，最差的是Nomad。要特別提到的是訊 息最終傳遞大多還是靠destination chain上的合約來執行，有時候並不是傳輸協議出現問題而是合約有問題或是合 約用的RPC有延遲，概念像是web2網路沒問題，但終端網站掛了還是沒有辦法傳遞訊息。所以除了solution的設計 之外，最終在destination chain的執行狀況上也會影響Liveness，這個跟solution開發者的功力息息相關，較難從設 計上看出端倪。

### Developer Friendly

對於開發者來說，要部屬相關功能並不是太費工，都是在source chain呼叫各solution的smart contract function傳 送訊息，接著在destination chain呼叫接受訊息的功能便可以完成了，因此各個solution單純以整合自己合約的code 來說難度差異不大，都是呼叫send / receive的function，像是替自己的application接上跨鏈讀/寫的能力。

![Celer IM 的 code，其他 solution 大多類似 ](https://storage.googleapis.com/papyrus_images/11e6c4fb74a4a40af2d6da7683f278d5f4881e995e2a61752c02b03ff3577cc2.png)

Celer IM 的 code，其他 solution 大多類似

LayerZero因為讓開發者自由選擇oracle與relayer，同時也給了開發者更多彈性，如果你是一個尚未規模化的 application，使用chainlink當oracle需要的費用可能較貴，就可以使用其他較不出名的oracle，當然安全性會較 差，但成本也較低，一旦協議TVL變大，交易的金額也越來越大，隨時可以轉換使用的oracle，這樣的彈性對於開 發者來說吸引力或許更大。

基本上各solution的差別不是很大，LayerZero因為自由選擇oracle與relayer可能多了一點彈性，但對於開發者來 說，是否有ecosystem fund、grant program、知名度更為重要，目前得知LayerZero會投資使用它們solution做 cross chain application的團隊、Axelar有$2.3m的grant program，從資金與投資者角度來看，LayerZero佔有 更多一點優勢，當然Chainlink本身的資金與對開發者的影響力是不可忽視的，但Chainlink仍有非常多其他的業務 要發展，CCIP不一定是主力。

![](https://storage.googleapis.com/papyrus_images/96124ceed8369a1771701c4a4afa92e0032ae105887059a6c3c06c45912c6424.png)

就我與開發者接觸的一個體會是，很多開發者對於solution design也不是很清楚，很難判斷誰比較安全、穩定，有時候 只是因為誰的知名度高、跟solution是否有關係等等，因此BD/Marketing的能力也非常重要。Celer是目前唯一官方宣 布與9個project合作，雖然真正上線的只有一個擴鏈橋項目Chainhop，就跟LayerZero的Stargate、Axelar的satellite一 樣，都是Demo的概念，資產跨鏈是最容易想像的應用場景，但可以看到Stargate造成的迴響與其他兩個產品是完全不 同的。目前聽到其他project有想採用類似的solution都是以Celer與LayerZero居多，因此這兩間公司在BD/Marketing能 力上有一定的優勢。

### Composability

IBC只適用具有instant finality的鏈且要在ETH架設其他鏈的light client成本太高，因此composability最差，目 前只適用於cosmos生態系之中，但看到一些solution正在透過IBC來拓展至其他的鏈，Axelar的角色就很有趣， 身兼使用IBC與第三方共識的solution，某個程度來說也替IBC增加composabiliy的可能性，因為Axelar把EVM或 是Substrate與Cosmos體系的流動性接起來之後，Cosmos的體系有望受惠而成長，對於開發者來說直接使用 Cosmos SDK開發的吸引力也會越來越高，其內建的IBC module也會越來越受到歡迎。另外polymer與Celestia合 作將IBC帶到optimistic rollups，使cross chain與modulation的概念融合再一起，希望未來在celestia上的rollup 可以透過IBC聯合起來，也是另外一個IBC拓展composabiltiy的例子，最後也有不少人討論ETH 2.0 sharding之間 也能透過IBC連結在一起的可能性，因此IBC是有所限制但不是只適用Cosmos。

第三方共識的solution要跨到新的鏈只需要在鏈上部屬合約就行，且相較於light client，不論是部屬的數量 (N vs N^2) 或是成本都具有優勢，因此理論上composability最好。但實際上，Celer IM目前支援的鏈最多有14條，Axelar 次之支援7條，LayerZero照理說取決於oracle但現在支援EVM Layer共7條，Multichain目前只有BNB與ETH且都還是 testnet，而Chainlink則是沒有推出，根據官方說法至少會等到年底..。Nomad的方式也是在鏈上部屬智能合約，不 受consensus體系限制，目前實際上支援了5條EVM的鏈。

![](https://storage.googleapis.com/papyrus_images/b89283f925ea2b41665c37db1dde7ca97ea8d899b73a11f95338d5c66b7c040a.png)

結語
--

目前這個市場還在非常早期，沒有明顯的贏家，每個solution都有各自的trade off，不同application也會有不同出發點， 未來隨著更多Layer 2出現或是Ethereum開始進行分片，跨鏈之間的溝通會越來越重要但也會更加複雜。如果目的是提供 用戶更好的體驗與整合流動性，有沒有對接到用戶最多的EVM chain是最重要的，所以composability為第一考量， 因此IBC即使安全性最好、穩定性最高，也不會考慮使用。有些application最在意的是liveness，訊息的傳遞延遲不能太 久，如衍生品的金融交易，就會考慮使用IBC，或是期待Chainlink的solution。有些更看重的是marketing，cross-chain 的function大多做為宣傳一途，那就會考慮知名度最高且對開發者更加友善的LayerZero。

短期內我認為LayerZero有機會獲得許多開發者採用，原因是：

1.  LayerZero剛好在熊市來臨之前募了相當多的資金，有更多的資源提供給開發者如舉辦黑客松、grant program、雇用更多BD等等，目前開發者仍在探索cross chain application的可能性，測試的階段會更偏向有這些資源的solution。 2. LayerZero知名度相當高，尤其在Stargate推出之後馬上引起許多開發者注意，且lead investor a16z在marketing上 也能提供許多幫助，不論是cross chain vision或是項目本身，很多時候開發者只是基由知名度來選擇solution。
    
2.  自由選擇oracle與relayer的彈性也讓開發者可以隨著application的規模而做出改變，從成本與安全性/穩定度自由做出選擇。
    

長期我更看好IBC：

1.  目前最大的短版composability有機會被解決，IBC最大問題是不支持Ethereum，沒有user也沒有流動性，但 Ethereum轉成PoS之後，或許有機會可以採用IBC solution，而分片之後，不同的分片也可以使用IBC互相溝通， 甚至與非Ethereum體系的鏈直接溝通。
    
2.  Modulation + IBC可能會創造出新的narrative，Celestia以consensus + data availability模組化的概念引起市 場不少的討論，若得到許多開發者認同，其內建的IBC module也會得到更多採用。
    
3.  IBC真正具有network effect，以web2的HTTP協議來看，網絡效果非常強，其他的跨鏈訊息傳遞對我來說更像是 SaaS的服務商，因為他只是服務某個特定的Dapp，但IBC是只要有越多zone接上，croos chain的interoperabiltiy效 用越高，就像是網際網路的IP address一樣，一個IBC module只要更改chain ID就能夠與不同也裝上IBC的鏈直 接溝通。
    

未來此賽道的發展可能：

1.  ZK的技術可以降低Light client的成本，使得IBC可以通用至所有的鏈上:其實ZK roll up的技術想要解決的問 題與cross chain infra很像—「如何知道並立即確認其他鏈已經與正在發生的事情?」，很期待未來ZK的技術是 否可以進一步簡化light client所需要驗證的資源與資料，並降低成本，如full node只需提供最新的block header zk proof，light client就不必知道該鏈上過去所有的資料就能進行驗證，進行大幅降低light client的成本。
    
2.  整合出一種開發工具將不同Layer 1的概念模糊化:這些solution都只是面對開發者的工具，真正我們關心的是 layer 0 infra可以帶來甚麼好處，也就是cross chain application可以帶來甚麼更好的應用場景，如果有一種開發工 具可以將layer 1的概念模糊化，使開發者專心開發產品，不須擔心不同鏈的用戶與流動性，很像是Stripe將金融服 務給抽象化，讓商家接上其API就能享有banking as a service如支付、借款、發卡等等，其實Intermediate Chain的 solution都有機會往這個路線發展，讓application建在Intermediate chain上但可擁有所有連接鏈的composabiltiy與 流動性。
    

本文 PDF 版本[下載連結](https://drive.google.com/file/d/1FjBVNyzYK7hjOUJJOWReMjeB8Lb7ZQjW/view?usp=sharing)

---

*Originally published on [MatrixDAO](https://paragraph.com/@matrixdao/layer-0-war)*