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)。它会被永久地、不可逆转地添加