Solana追趕Hyperliquid:一場雄心勃勃的模仿秀

最近，Solana生態圈發生了一件有趣的事。Solana基金會、Anza、Jito Labs等重量級玩家聯合發布了一份名爲"互聯網資本市場(Internet Capital Markets, ICM)"的技術路線圖。這份路線圖的核心是"應用可控的交易執行(Application Controlled Execution, ACE)"概念,目標是讓鏈上應用能夠毫秒級控制交易排序,打造去中心化的"鏈上華爾街"。

雖然路線圖中沒有直接提到Hyperliquid,但細讀後不難發現,其中的設計幾乎處處都在針對Hyperliquid的強項。這就像Solana在說:"你Hyperliquid有的,我們也要有,而且要做得更好!"

要知道,Hyperliquid在鏈上永續合約市場佔據了主導地位,交易量曾一度佔到整個去中心化永續市場的65%左右。面對這樣強勁的競爭對手,Solana顯然不甘心被超越,因此推出了這份ICM路線圖。

那麼,這場"模仿秀"到底是怎麼回事?Solana能否真的追上甚至超越Hyperliquid呢?讓我們深入分析一下。

ICM背景與內容

誰在主導這場變革?

參與制定路線圖的都是Solana生態的重量級玩家:

• Solana Foundation/Labs:Solana的"親爸爸",負責整體協調和核心協議開發。

• Anza:由Solana Labs前成員創立的開發公司,類似以太坊的ConsenSys。負責許多核心技術攻關,如新的共識協議Alpenglow。

• Jito Labs:Solana上的MEV基礎設施提供商,影響力巨大。主導提供Block Assembly Marketplace (BAM)等交易排序方案。

• Multicoin Capital:著名加密投資機構,Solana早期支持者。持有大量SOL和生態項目權益,在技術方向上有相當話語權。

• DoubleZero:專注於加速網路通信的團隊,提供專用光纖網路方案,用於提升Solana驗證節點間的通信速度。

• Drift:Solana上領先的永續合約DEX項目。此前採用鏈下撮合模式,面對完全鏈上的Hyperliquid時略顯喫力,希望借助底層升級來翻身。

要解決的核心問題

路線圖聚焦於改進市場微觀結構,主要是解決當前鏈上交易機制對做市商不夠友好的問題。目前Taker(主動發起交易的一方)往往佔優勢,而Maker(掛單等待成交的一方)處於劣勢。這是因爲Taker通常掌握最新信息,並可以通過提高手續費來確保交易優先執行,而Maker往往來不及撤單,被迫在不利價格成交。

一些高頻套利者會利用這種不對稱,發起"有毒流量"攻擊。例如,當鏈上價格還未更新但鏈下價格已變化時,套利者可以用舊價格喫掉做市商的單子,讓做市商承擔損失。爲了自保,做市商要麼拉大買賣價差,要麼減少掛單量,導致整個市場流動性變差。

ICM路線圖就是要平衡這種格局,吸引高質量的流動性回到鏈上。

ICM的三步走

Solana將這個宏大計劃分爲三個階段:

短期(1-3個月):主要優化現有鏈上交易體驗,讓訂單簿類應用更好用,減少惡性MEV幹擾。包括:

• Jito Labs的Block Assembly Marketplace(BAM)模塊上線主網。這是在終極ACE上線前的臨時外掛系統,讓Solana智能合約擁有自主交易排序權。

• Anza團隊優化"交易進入同一Slot"的成功率,減少滑點與MEV損失。

這些改進預計在2025年7-9月陸續落地。

中期(3-9個月):引入專用高速網路和新版共識,大幅減少延遲、提高吞吐量:

• 部署DoubleZero專用光纖網路,爲驗證者提供近乎零抖動、延遲降低最多100ms的高速通信。

• 推出Alpenglow共識協議,將最終確認時間從約12.8秒壓縮到約0.15秒。

• 研發異步程序執行(Asynchronous Program Execution,APE),減少交易執行對共識的阻塞。

長期(9-30個月):對Solana核心架構進行革命性升級,目標在2027年前後實現:

• 多重並行出塊人(Multiple Concurrent Leaders, MCL):讓多個驗證者同時在各自pipeline內提議交易,然後按優先費將這些並行區塊合並排序。這可弱化單一打包者的壟斷,增強抗審查性。

• 原生的應用可控執行(Application Controlled Execution,ACE)功能:真正賦予鏈上智能合約控制交易執行順序的權力。

分析至此,這份ICM路線圖背後的故事可能是這樣的:Solana上的老牌DEX Drift被後來者Hyperliquid以"鏈上Binance"的優秀體驗後來居上。Drift自身難以抗衡,只好求助於Solana Labs、Anza、Jito等"大佬"。這些"大佬"提出ICM這份技術改造方案,宣稱要將Hyperliquid的看家本領都復制給Drift,助其重新競爭DEX市場。但"大佬"們也表示,這次技術改造難度極大,因此將技術方案劃分爲三步走戰略,近期能給Drift的只有Jito的BAM,讓Drift先湊合着用,和Hyperliquid較量一下。

明白了這個背景,接下來我們詳細分析ICM到底模仿、復制了Hyperliquid的哪些核心優勢。

模仿一:交易排序機制

問題所在:如前所述,現在的鏈偏向taker,maker承擔"有毒流量"之苦。主動吃單的用戶可以根據鏈下最新價格,瞬間對鏈上掛單發起交易,並通過提高手續費而優先成交,而做市商往往來不及更新或撤單。結果是,做市商要麼拉大點差,要麼幹脆撤掉流動性,讓市場深度變差。

ICM的終極方案:應用可控執行(ACE)

ICM路線圖提出了ACE(Application Controlled Execution)概念,即將交易排序權下放到各個鏈上應用,由應用自行決定本應用相關交易如何排序執行。舉例來說,在未來實現ACE的Solana上,DeFi合約可以實現如下自定義的交易排序規則:

• Oracle價格更新插入:DeFi應用可以在大額交易撮合前,先插入一筆交易從預言機獲取最新價格,確保訂單按最新合理價格撮合,防止做市商的報價基於過時價格而被套利。

• 撤單優先執行:應用可以設定"撤單請求"優先於新的"吃單交易"執行,讓maker有機會在行情不利時及時撤回掛單。

• 隊尾競拍:例如出現一筆巨額買單推高價格後,DeFi應用將"緊隨其後"的機會拿出來拍賣,誰願意將最多利益返還給協議(或用戶),DeFi協議就讓誰的交易貼着大單後執行。DeFi應用可以將拍賣收益返還給用戶,從而把有毒MEV流量轉化爲良性收入。

JITO的BAM:過渡方案

在ACE正式上線前,Jito Labs推出了名爲Block Assembly Marketplace (BAM)的過渡方案。BAM的工作流程是:

1. 用戶將交易發送給一個運行BAM軟件的節點(而非直接給當前Leader)。

2. BAM節點收集本地交易並運行各類插件(plugin)對交易包(Bundle)進行隱私保護下的重新排序(插件運行在安全的TEE環境中,在執行前對外隱藏交易內容)。通過插件,應用開發者可以爲自己的合約定制各種排序規則,例如撤單優先、撮合前更新預言機價格,甚至運行復雜的應用內競價等。

3. 排序後的交易Bundle再發送給Solana Leader打包上鏈。

BAM可以看作ACE上鏈前的試驗田,功能上非常接近終極ACE,只是它運行在鏈下的獨立網路中,而非Solana主鏈協議內置。

值得注意的是,Jito此前一直提供面向MEV提取的基礎設施(如Jito Block Engine),其商業模式是通過優化交易排序爲套利者創造機會並分享收益。這在某種程度上是站在普通用戶和被套利者對立面的"矛"。然而Jito在2024年初關閉了面向套利機器人的公共內存池(mempool)功能,以減少三明治攻擊等負外部性。這一舉措表明Solana社區傾向於抑制有害MEV,維護用戶公平。

BAM的推出更是順應這一思路:它本質上是將原本用於MEV套利的排序機制,變成一面"盾",以保護做市商等流動性提供者,比如強制撤單優先避免做市商受損、引入競價返利減少搶跑獲利等。原先的MEV搜索者如果想賺錢,就必須轉換角色,編寫BAM插件爲DeFi協議服務,靠插件手續費盈利。

向HYPERLIQUID取經

上述ACE/BAM思路,其實可以看作對Hyperliquid鏈上撮合機制的一種追趕。Hyperliquid是一個專用鏈(Appchain),天生就是爲DEX服務的。而且Hyperliquid官方運營的HLP Vault實際上就是該平台最大的做市商之一,所以不難理解Hyperliquid的鏈規則更偏向於流動性提供者,已經在鏈層實現了許多保護做市商的設計,比如:

• 掛單方優先保護:撤單和只做maker的掛單被優先處理,避免做市商在不知情情況下被不利成交。Solana ACE提到的"撤單優先執行"Hyperliquid早已實踐多年。

• 最新價格保障:Hyperliquid的清算和撮合過程都強調使用最新喂價與保證金狀態進行"雙重檢查"。例如,當有掛單撮合成交時,系統會再次拉取最新預言機價格評估雙方保證金,確保不會因爲價格滯後造成風險。這類似ACE在交易執行前插入預言機更新交易。

• 自成交防護:若同一地址買賣相遇,Hyperliquid自動取消而非撮合,以防止刷量或不必要費用。

Solana ICM的ACE/BAM,無疑是向Hyperliquid"取經"。Hyperliquid作爲鏈上CLOB龍頭,用一條專屬鏈實現了對做市商友好的種種機制。Solana現在希望用通用鏈加模塊化插件,來復制這種效果------即讓每個應用都擁有類似Hyperliquid那樣的對交易排序的控制力。

模仿二:即時最終性

現有共識對比

Solana當前採用的是Tower BFT,確認和最終性是概率性漸進的:一個區塊得到2/3投票即記爲"確認(Confirmed)",但需鏈上累積約32個後續區塊(通常約13秒)才能被錨定爲"最終確定(Finalized)"。對於某些應用(比如高頻交易),十幾秒的最終確認時間還是太長了。

HyperBFT是Hyperliquid自研的共識算法,受HotStuff共識啓發,採用兩輪投票確認區塊,實現"即時最終性"。

• 第一輪:預投票(Prevote):驗證者收到Proposer廣播出來的候選區塊後,會進行快速驗證。如果驗證通過,每個驗證者就會對這個區塊投出一張"預投票"(Prevote)票,並將其廣播給全網。這張票代表:"我初步看過了,這個區塊沒問題。"

• 第二輪:預提交(Precommit):一旦某個驗證者收集到了來自超過三分之二驗證者對同一個候選區塊的Prevote,它就獲得了足夠的信心,相信網路的大多數成員都認可這個區塊。於是,該驗證者會投出一張更具分量的"預提交"(Precommit)票,並廣播出去。這張票代表:"我看到了網路的大多數都同意了,我準備好將這個區塊正式寫入帳本了。"

• 當一個驗證者收集到了來自超過三分之二驗證者對同一個候選區塊的Precommit時,共識便達成了!該區塊被認爲是最終確定的(Finalized)。它會被永久地、不可逆轉地添加