Bible Network Crypto DeFi Onchain RWA AI Agent Stablecoin CryptoTax DeFAI Chain SAFU AGI Claude Me Claude Skill Claude Design Claude Cowork
獨立知識媒體
與任何項目無關聯
DeFi 協議底層運作全解析:AMM、借貸、收益與風險
defi-bible.com
最新
一筆 6540 萬美元的閃電貸,換來 600 萬美元的利潤:Summer.fi Lazy Summer 金庫被駭事件完整回顧  ·  協議說自己有九成流動性都是自己的,這句話該怎麼查證,不能只聽官方說法  ·  積分歸零那一天,你會後悔嗎?決定要不要衝一個積分計畫前,先問自己這個問題  ·  你手上的 WBTC,背後其實是一把三分之二的鑰匙:拆解包裝比特幣的完整信任結構  ·  跟你完全無關的協議被駭,你的存款為什麼還是縮水了:Kelp 到 Aave 的壞帳連鎖拆解  ·  買進之前,先花五分鐘查一件事:這枚代幣是不是快要撞上解鎖懸崖
名詞解析 · defi-fundamentals

Cross-Chain Messaging Protocol

跨鏈訊息協議
defi-fundamentals intermediate

30 秒版 · 給沒耐心的人
一套讓不同區塊鏈之間能夠傳遞資訊、觸發彼此智能合約動作的底層基礎設施,跟前面文章介紹過的橋接功能經常搭配使用,但本質上處理的是「訊息的可信傳遞」這個更基礎的問題,橋接資產的轉移只是這套機制眾多應用場景裡的其中一種。
完整解說 +
01 · 這是什麼?

跨鏈訊息協議是什麼,跟前面介紹過的橋接功能有什麼不同?

前面文章介紹過的橋接,聚焦在「怎麼把一項資產,從一條鏈搬到另一條鏈」這個具體問題;跨鏈訊息協議處理的範圍更廣——它提供的是一套通用的底層機制,讓任何一條鏈上的智能合約,能夠把任意一段訊息或指令,可信地傳遞給另一條鏈上的智能合約,並觸發對方執行對應的動作。資產橋接,某種程度上只是這套通用機制,應用在「傳遞一則『請在目標鏈上釋放等值資產』的指令」這個特定場景下的具體案例。

跟橋接功能最大的不同在於「處理的抽象層級」:橋接通常聚焦在單一功能(資產轉移),而跨鏈訊息協議是一套更底層、更通用的基礎設施,除了資產橋接,還能支援跨鏈治理投票、跨鏈讀取另一條鏈上的資料狀態、或者讓一個智能合約串連起發生在好幾條不同鏈上的一連串操作。可以把跨鏈訊息協議理解成一條更基礎的公路系統,橋接則是這條公路系統上,眾多不同用途的車輛之一,不是公路系統本身。

02 · 為什麼存在?

跨鏈訊息協議為什麼會出現,想解決什麼結構性問題?

區塊鏈生態系經過多年發展,已經演變成一個由眾多獨立鏈組成的多鏈環境,不同鏈各有自己的優勢與用戶社群,但這些鏈原生的設計,彼此之間預設是完全隔離的——一條鏈上的智能合約,原生沒有任何方式,能直接得知或影響另一條鏈上發生的事情。這種隔離性,某種程度上限制了整個生態系的發展潛力——用戶跟資產被切割在各自的鏈上,無法自由流動,開發者如果想打造一個能同時服務多條鏈用戶的應用,也缺乏統一的技術管道去實現。

跨鏈訊息協議想解決的正是這個結構性隔離問題:透過一套標準化、通用化的訊息傳遞機制,讓開發者不需要為每一對想要互通的鏈,各自客製化開發一套專屬的溝通管道,而是能透過同一套協議,統一處理跟任意其他鏈之間的訊息傳遞需求。這某種程度上是把「讓多條鏈變得像一條鏈一樣好用」這個目標,透過標準化的基礎設施去實現,而不是讓每個應用開發者,各自重新發明一套跨鏈溝通的輪子。

03 · 如何影響你的決策?

跨鏈訊息協議具體怎麼運作,訊息從一條鏈傳遞到另一條鏈的完整流程是什麼樣子?

以目前市場上具代表性的跨鏈訊息協議架構為例,典型流程包含幾個環節:

  1. 訊息發送:來源鏈上的智能合約,把要傳遞的訊息內容(可能是「釋放某筆資產」、「更新某個狀態」等任意指令),打包成一個標準化的封包,送進協議的端點合約
  2. 獨立驗證:這個封包不會被單一個實體直接信任並轉發,而是需要經過一組獨立的驗證節點(不同協議對這組節點有不同稱呼,常見的一種設計稱為「去中心化驗證網路」,DVN),各自獨立確認這則訊息的雜湊值與來源真實無誤,只有達到協議預先設定的驗證門檻(例如需要至少幾個獨立驗證節點都確認無誤),這則訊息才會被標記為「已驗證」
  3. 執行傳遞:訊息通過驗證後,目標鏈上負責執行的角色(不同協議的稱呼也不同,可能稱為「執行者」),會把這則訊息實際送達目標鏈上的智能合約,並觸發合約執行對應的邏輯,例如真的把資產釋放給接收方
  4. 安全參數可自訂:值得留意的是,多數現代跨鏈訊息協議,並不是用一套「放諸四海皆準」的統一安全標準去驗證所有訊息,而是允許每個使用這套協議的應用程式,自行決定「需要幾個驗證節點、達到什麼樣的驗證門檻,才算通過驗證」——一個承載價值極高的跨鏈通道,理論上可以選擇設定更嚴格的驗證門檻,一個承載價值較低的通道,則可以選擇較寬鬆的門檻以換取更快的傳遞速度跟更低的成本

這套「安全參數可依應用需求自訂」的設計哲學,某種程度上反映了跨鏈訊息協議想解決的核心問題——不是提供一套統一僵化的安全標準,而是提供一套彈性、可組合的基礎設施,讓不同應用能依照自己實際承載的價值規模,做出對應的安全性取捨。

04 · 你該怎麼辦?

跨鏈訊息協議對一般用戶有什麼實際影響,該怎麼評估依賴這類協議的產品風險?

對一般用戶而言,跨鏈訊息協議通常是隱藏在幕後的基礎設施——你在使用一個跨鏈橋、或者一個支援多鏈操作的 DeFi 應用時,實際上很可能就是在間接依賴某個跨鏈訊息協議提供的底層服務,但介面層面通常不會特別強調這件事。理解這套機制的存在,能幫助你在評估任何一個跨鏈相關產品時,多問一個更深入的問題——不只是「這個橋接功能安不安全」,還包括「這個橋接功能底層依賴的跨鏈訊息協議,安全設計是什麼、驗證門檻設定得夠不夠嚴謹」。

評估這類風險時,前面文章介紹過的一起真實事件值得參考——2026 年 4 月的 Kelp DAO 跨鏈橋攻擊事件,攻擊者利用的正是底層跨鏈訊息協議安全參數設定上的疏失,而不是 Kelp DAO 自己合約邏輯本身的錯誤。這起事件具體示範了,即使一個應用自己的智能合約完全沒有問題,如果它依賴的跨鏈訊息協議安全配置不夠嚴謹,依然可能因此暴露在真實的攻擊風險裡。具體查證方向包括:這個應用選擇的驗證門檻設定,相對於這個通道承載的資產價值規模,是不是足夠嚴謹(承載價值越高,理論上越需要更嚴格的驗證門檻);以及這個應用是否公開揭露自己選擇的具體安全參數設定,讓外部研究者能獨立評估這個配置是否合理,而不是只籠統宣稱「我們使用了業界領先的跨鏈技術」。

實際例子 +

2026 年 4 月 19 日的 Kelp DAO 跨鏈橋攻擊事件(前面文章介紹過完整案例拆解),攻擊者利用的正是底層跨鏈訊息協議 LayerZero 的預設安全設定,取得約 2.92 億美元等值的 rsETH。LayerZero 這套協議本身,採用一套稱為「X of Y of N」的可配置驗證模型——應用程式能自行決定,從 Y 個可選的獨立驗證節點裡,選出哪幾個節點組成自己的驗證組合,並設定至少需要幾個節點(X)達成一致,這則跨鏈訊息才算通過驗證。這起事件具體示範了,即使協議本身提供了可自訂、可調整嚴謹度的安全機制,如果應用方在實際配置時沒有選擇足夠嚴謹的驗證門檻,這套彈性設計依然可能被利用,造成真實的資產損失。

常見誤解 +
✕ 誤解1
× 誤解:跨鏈訊息協議就是橋接,兩者是同一件事的不同說法,實際是:橋接是跨鏈訊息協議眾多應用場景裡的其中一種,跨鏈訊息協議本身處理的是更基礎的「訊息可信傳遞」問題,還能支援跨鏈治理、跨鏈讀取資料等橋接以外的功能
✕ 誤解2
× 誤解:只要一個應用使用了知名的跨鏈訊息協議,就代表這個應用的跨鏈功能絕對安全,實際是:多數現代跨鏈訊息協議的安全參數是可自訂的,具體安全性取決於應用方實際選擇的驗證門檻設定,2026 年 Kelp DAO 事件正是應用方配置不夠嚴謹、而非協議本身有漏洞的具體案例
這件事跟你有什麼關係 +
直接影響

優點是透過標準化的通用機制,讓開發者不需要為每一對想互通的鏈各自客製化開發,也讓不同應用能依照自己承載的價值規模,自訂對應的安全參數設定,兼顧靈活性與成本效率;缺點是這套「安全參數可自訂」的彈性設計,把選擇正確安全等級的責任,轉移到了個別應用開發者身上,如果應用方本身沒有足夠的安全意識、選擇了不夠嚴謹的驗證門檻,即使底層協議設計再完善,依然可能因為配置疏失而暴露在真實攻擊風險裡。

提問
請至少輸入 10 個字
更多相關主題