Layer 時代下的流動性割裂問題研究

隨着以太坊轉向以 Layer 爲核心的擴展方案，加上 RaaS 等工具的興起，大量公鏈迅速發展。許多實體都希望構建自己的鏈，以代表不同的利益訴求並尋求更高的估值。然而，衆多公鏈的湧現使得生態系統的發展難以跟上公鏈的步伐，導致許多項目在 TGE 時即告破發。

借助 OP Stack，某交易平台推出了自己的 Base Layer，另一交易平台發布了 Ink；借助 ZK 技術，某平台推出了 XLayer；Sony 發布了 Soneium，LINE 推出了 Kaia 等。如今，構建一條鏈的資金和技術門檻已大大降低，運營一條基於 OP Stack 的鏈的成本每月約爲 10,000 美元。

未來必將是多鏈共存的時代。盡管這些 Layer 鏈可能會選擇 EVM 兼容性以實現互通，但由於其背後的 Web2 實體有大量下遊應用，它們很難在同一條鏈上構建應用並達成共識。

當前的多鏈生態帶來了一個新的挑戰：流動性和狀態分散。由於多鏈的存在是必然的，因此互操作性就是一個必須要探索和解決的領域。當前有許多的流動性解決方案，比如鏈抽象、意圖、Clearing Execution、Native CrossChain、ZKSharding，但是其核心本質都是一樣的。

我們使用的業界較爲認可的 Cake 架構來從上至下介紹跨鏈抽象的核心組件構成：

應用層（Application Layer）

這是用戶直接交互的層，也是流動性解決方案中最抽象的一層，因爲它完全屏蔽了流動性轉換的細節。在應用層中，用戶與前端界面互動，未必了解底層的流動性轉換機制。

權限層（Permission Layer）

位於應用層下方，用戶通過連接錢包到 dApp 並請求報價來滿足交易意圖。這裏的「意圖」指的是用戶期望的最終交易結果（即輸出），而非交易的具體執行路徑。

帳戶管理和抽象層（Key Management and Account Abstraction）

由於多鏈環境的存在，需要一個適應不同鏈的帳戶管理和抽象體系來維護各個鏈的獨特帳戶結構。例如，SUI 的對象中心帳戶體系與 EVM 完全不同。One Balance 是該領域的代表項目，它構建了可信的帳戶體系，無需建立鏈間共識，只需現有帳戶體系之間的可信承諾。Near Account 通過爲用戶生成多鏈帳戶錢包來實現抽象化管理，極大地優化了用戶體驗，減少了 UX 的碎片化。然而，流動性方面主要集成了現有的公鏈。

求解層（Solver Layer）

該層負責接收並實現用戶的交易意圖，Solver 角色在這裏競爭以提供更好的用戶體驗，包括更快的交易時間和執行速度。在此基礎上，基於意圖的項目構建了各種意圖驅動的解決方案。此類意圖的衍生品如 Predicate 組件，可在特定規則下實現用戶意圖。

結算層（Settlement Layer）

這是求解層爲實現用戶意圖而使用的中間件層。流動性和狀態分散的解決方案核心組件包括：

• 預言機（Oracle）：用於獲取其他鏈上的狀態信息。
• 跨鏈橋（Bridges）：負責跨鏈的信息和流動性傳遞。
• 提前確認方案（Pre-Confirmation）：縮短跨鏈確認時間。
• 數據可用性（DA）：提供數據的可訪問性。

此外，還需考慮鏈間流動性、最終確認性（Finality）、Layer 證明機制等因素，以保障整個多鏈系統的高效運作。

當前，市面上有多種解決流動性割裂的解決方案，我們縱覽了大量方案後，發現主要是有這幾種方式：

1. 以 RaaS 爲中心：類似於 OP Stack 這種 Rollup 解決方案，通過加入特定的共享排序器和跨鏈橋來協助在 OP Stack 上構建的 Rollup 共享流動性和狀態。這希望能夠以一個更高層次的方向去解決流動性和狀態分散。這裏面有一個較爲細分的就是單獨的設計共享排序器，這個方案更多的是針對 Layer2，不具備普適性。

2. 以帳戶爲中心：構建一個全鏈的帳戶錢包，通過一個稱爲「鏈籤名」的技術支持跨多種區塊鏈協議簽署和執行交易。其中核心組件是 MPC 網路，代替用戶爲多鏈交易籤名。這套方案，雖然能極大的解決 UX 碎片化的問題，但是對於開發者來說，這涉及到復雜的後端實現，並且沒有本質上解決流動性和狀態分散。

3. 以鏈下意圖網路爲中心：也就是我們「引言」蛋糕架構圖中的 Solver Network，核心就是用戶發送意圖給 Solver 網路，Solver 這個角色去競爭報價，給到最優的完成時間和交易價格，這些 Solver 可以是 AI Agent，CEX，Market Maker 乃至集成協議本身。雖然意圖在理論上能夠實現任意難度的復雜跨鏈操作，但是在實現方面確需要有足夠流動性 Solver 來協助，並且當遇到一些鏈下的需求時，Solver 存在欺詐的可能性，如果引入欺詐證明等手段，Solver Network 的實現難度會變得更高，運行 Solver 的門檻也會更高。

4. 以鏈上流動性網路爲中心：這個方向是專門優化跨鏈的流動性問題，但是沒有解決其它鏈上狀態分散的問題。其核心是構建一個流動性層，在該層上搭建應用，以共享全鏈流動性。

5. 以鏈上應用爲中心：這類應用通過集成大 MM、或者第三方應用等來構建高流動性應用。這類項目需要管理復雜的跨鏈流程，對開發者要求極高，因此也極易出現黑客攻擊的事件。

解決流動性問題是一個非常重要的命題，金融世界往往流動性代表一切，如果能夠構建一個整合流動性平台，特別是將零散的全鏈流動性整合在一起，將具備非常大的潛力，而我們也看了許多不同的解決方案。

在上面兩種分類中，我們能夠看到根據蛋糕結構，Settlement Layer 是最原子級別的解決方案，在這些跨鏈、預言機、Pre-Confirmation 方案等原子解決方案之上，構建的更加抽象的一層，就是 Solver Layer、Permission Layer 和 Application Layer。我們在上面列出的各個以不同方向去構建抽象或者流動性解決方案符合這一套的不同層級，可以理解爲上下遊的關係。但是這些方案仍然不是原子級解決方案，整個流動性割裂的問題，帶來了許多龐雜的衍生問題的出現，因此針對互操作性，衍生出了五花八門的解決方案。但是本質上還是要依賴於這些組件。接下來我們將討論幾個典型的鏈抽象概念的項目，來看看各自都是如何從自己的出發點來解決流動性割裂的問題。

INFINIT 構建了一個 DeFi 屆的 RaaS 服務，其能夠爲 DeFi 協議提供直接構建所需要的組件，如 Oracle、Pool Type、IRM、Asset 等，還能夠提供立刻啓用的 Leverage Trading 和 Yield Strategy 等組件。相當於其它應用構建端，但是最終的流動性是放在 Infinit 的流動性層。但是，目前其仍然未披露底層的工作原理。

Khalani 構建了三個核心組件，分別是 Intent 兼容層、Validity 和通用結算層。外部應用或者意圖層可以發布意圖給 Khalani，然後 Khalani 的 Intent 兼容層能夠將外部的意圖轉化爲協議 Solver 能夠識別的格式，使用的規範化的格式就是 Validity 語言。Khalani 節點負責通過跨鏈橋、快速結算技術等提交最終的結果給通用結算層。

Liquorice 是一款去中心化應用程式，可實現基於拍賣的價格發現和單邊流動性池。Liquorice 的主要使命是爲專業交易公司提供高效的庫存管理工具，並在使用意圖結算交易時輕鬆連接到核心 DeFi 協議。與此同時，Liquorice 創建了借貸市場，供其進行借貸交易。這款應用更加專注於交易本身。

Xion 是建立在 Comet BFT 共識協議之上的。其採用的跨鏈通信是基於 Cosmos IBC 的，因此比其它跨鏈橋更加的原生、安全。

=nil; Foundation 提出了 zkSharding 解決方案，該解決方案是使用 ZK 技術來水平拓展以太主網，執行分片並行處理交易並生成 ZKP，而主分片驗證數據、與以太坊通信並在所有驗證者之間同步網路狀態。主分片還管理執行分片中驗證者和帳戶的分布。驗證委員會使用的共識協議也是 Hotstuff，這在最新的並行執行的項目中很常見。=nil; L2 從一開始就將跨分片通信嵌入到協議中。

Ethereum 也正在着手解決這一跨鏈流動性的問題，目前一些主要的交易平台首先公開支持 ERC7683 標準，其使用的也是基於 Intent 的跨鏈方式。其核心目標是爲跨 L2 和側鏈的跨鏈操作建立通用標準，標準化訂單和結算接口，實現無縫跨鏈執行，其主要的核心就是一個 Filler 也可以說是鏈抽象中的 Solver 角色代付。

OP Stack 通過設計一個完整的多 Layer2 解決方案，來一次性解決信息傳遞和 Sequencer 去中心化的問題，當你使用 OP Stack 架構時，便會自動部署跨鏈合約，同時會存在一個 Supervisor 去挑戰避免傳遞虛假跨鏈信息。

解決跨鏈流動性的問題，是一個非常龐雜且解決方案繁多的領域。Layer2 的解決方案分爲從 Ethereum 內嵌跨鏈消息特別是 ERC-7683 來解決，還有 Layer2 如 OP 構建的 OP Stack 來共享 Sequencer 來解決。脫離 Layer2 語境下，所有的 Layer1 也都面臨流動性、狀態、用戶體驗割裂的問題，有專門針對於流動性的應用爲中心的解決方案，也有以 Solver Network 的鏈下解決方案，乃至還有類似 NEAR 這種帳戶爲中心的解決方案，但是也需要基於 Solver 這種鏈下的角色。

跨鏈流動性、狀態、用戶體驗割裂是整個區塊鏈行業的問題，如果從整體上思考，需要以一個更加抽象，類似於鏈抽象的方式去做，這相當於是真正的