跨鏈協議安全性的重要性及LayerZero的不足

跨鏈協議的安全性問題近年來備受關注。從過去兩年各區塊鏈上發生的安全事件造成的損失金額來看，跨鏈協議相關的安全事件損失位居榜首。解決跨鏈協議安全問題的重要性和緊迫性甚至超過了以太坊擴容方案。跨鏈協議之間的互操作性是Web3生態系統連接成網的內在要求。這類協議通常獲得巨額融資，其總鎖倉價值(TVL)和交易筆數也在剛性需求驅動下日益增長。然而，由於大衆對這些協議的辨識度不高，難以準確評估它們的安全等級。

讓我們先來看一個典型的跨鏈產品設計架構。在Chain A和Chain B之間的通信過程中，由Relayer執行具體操作，Oracle則對Relayer進行監督。這種架構的優點是避免了傳統方式中需要第三條鏈（通常不部署dApp）來完成共識算法以及多個節點驗證的復雜過程，因此能爲終端用戶帶來"快速跨鏈"的體驗。由於架構輕便，代碼量少，且可以直接使用現成的Chainlink作爲Oracle，這種類型的項目容易快速上線，但同時也容易被模仿，技術門檻幾乎爲零。

然而，這種架構至少存在兩個問題：

1. 將數十個節點的驗證過程簡化爲單一Oracle驗證，大幅降低了安全系數。

2. 在簡化爲單一驗證後，必須假設Relayer和Oracle是相互獨立的。這種信任假設難以永久成立，不符合加密貨幣原生理念，無法從根本上保證二者不會合謀作惡。

某些跨鏈協議採用了這種基本模式。作爲獨立安全類型的"超輕量級"跨鏈方案，它們僅負責傳遞消息，並不對應用的安全性負責，也沒有能力承擔這種責任。

即便允許多方運行中繼器，也無法徹底解決上述問題。首先，去中心化並不僅僅意味着運行者數量增加或人人都可以接入。需求端一直都是無需許可的，讓供給端也變成無需許可並不是劃時代的變革，這只是市場端的變化，與產品本身的安全性關係不大。某些協議的Relayer本質上只是負責轉發信息的中介，與Oracle一樣，都屬於受信任的第三方。試圖通過將受信主體從1個增加到30個來提高跨鏈安全性是徒勞的，不僅沒有改變產品特性，還可能引發新的問題。

如果一個跨鏈代幣項目允許修改配置的節點，那麼就有可能被攻擊者替換爲其自己的節點，進而僞造任意消息。從結果來看，使用這種協議的項目仍然可能面臨巨大的安全隱患，且這種問題在更復雜的場景下會更加嚴重。在龐大的系統中，只要有一個環節被替換就可能引發連鎖反應。某些跨鏈協議本身並不具備解決這個問題的能力，如果真的出現安全事故，它們很可能會將責任推給外部應用。

如果某個協議不能像Layer1、Layer2那樣共享安全性，那它就不能被稱爲基礎設施。基礎設施之所以"基礎"，是因爲它能共享安全性。如果某個項目自稱是基礎設施，那就應該像其他基礎設施一樣爲其所有生態項目提供一致的安全性，即所有生態項目共享該基礎設施的安全性。因此，準確地說，某些跨鏈協議並不是基礎設施，而是中間件。接入這種中間件SDK/API的應用開發者確實可以自由定義他們的安全策略。

一些研究團隊曾指出，假設應用所有者（或擁有私鑰的人）不會作惡是不正確的。如果惡意行爲者獲得了跨鏈協議配置的訪問權限，他們可能會將預言機和中繼器從默認組件更改爲由他們控制的組件，從而操縱使用該機制的智能合約，導致用戶資產被盜。

此外，有研究表明，某些跨鏈協議的中繼器存在關鍵漏洞。雖然目前處於多重籤名狀態，這些漏洞只能由內部人員或已知身分的團隊成員利用，但仍然存在潛在風險。這些漏洞可能允許從多重籤名發送欺詐性消息，或在預言機和多重籤名簽署消息或交易後修改消息，都可能導致所有用戶資金被盜。

回溯比特幣的本源，我們可以看到中本聰在白皮書中提出的核心理念：一種完全的點對點電子貨幣系統，允許在線支付直接從一方發送到另一方，無需通過金融機構。這一理念強調了去中心化和無需信任的特性，這也成爲後來所有基礎設施開發者共同追求的目標。

然而，某些跨鏈協議在實際運作中要求Relayer、Oracle這兩個角色不會合謀作惡，同時要求用戶將使用該協議構建應用的開發者視爲可信賴的第三方。參與"多籤"的受信主體都是被事先安排好的特權角色。更重要的是，在整個跨鏈過程中沒有產生任何欺詐證明或有效性證明，更不用說將這些證明上鏈並進行鏈上驗證。因此，這些協議實際上並不滿足"中本聰共識"，不能被稱爲真正的去中心化和無需信任的系統。

在面對安全問題時，一些跨鏈協議的回應態度往往是"否認"再"否認"。然而，歷史告訴我們，比特幣之前就有很多電子貨幣嘗試，但都失敗了，因爲它們都沒有達成去中心化、抗攻擊和自帶內在價值的目標。跨鏈協議也是如此，無論融資規模多大、用戶流量多高、"血統"多麼純正，只要產品無法實現真正的去中心化安全，大概率會因爲抗攻擊能力不足而最終失敗。

構建真正去中心化的跨鏈協議是一個復雜的挑戰。一些新興的解決方案，如使用零知識證明技術來升級跨鏈協議，可能會爲這一領域帶來新的突破。然而，關鍵在於協議開發者是否認識到自身存在的問題，並願意採取必要的措施來改進。