深入探究Hyperliquid的技术构造与安全隐患

近期广受关注的Hyperliquid是最有影响力的链上订单簿交易所之一,其总锁仓价值已超20亿美元,被业内评价为"链上版某知名中心化交易所",同时也重新引发了人们对Layer3和应用链的讨论。凭借上线一个月内项目估值达300亿美元的亮眼表现,Hyperliquid获得了广泛关注。目前市场上已有不少关于Hyperliquid的分析报告,但多数集中在产品功能和交易机制方面,缺乏对其技术架构和潜在安全隐患的深入剖析。

本文旨在填补这一空白,纯粹从技术和安全角度对Hyperliquid进行解析,帮助读者更好地理解这一明星项目的内部构造和原理。我们将重点分析Hyperliquid跨链桥合约的设计与风险,以及HyperEVM与HyperL1的双链架构,深入探讨其背后的技术实现方式。

Hyperliquid跨链桥解析

由于Hyperliquid并未开源其核心组件,但开源了相关的桥合约,因此我们对桥合约方面的风险有更多了解。Hyperliquid在某Layer2网络上部署了一个桥合约,用于存储用户存入的USDC资产,我们可以通过Bridge组件观察到Hyperliquid节点的部分行为。

验证者集合

从节点身份划分来看,Hyperliquid有4组验证者,分别是hotValidatorSet、coldValidatorSet以及finalizers和lockers,各自承担不同职责。hotValidatorSet负责响应用户的高频操作如提款等,通常使用热钱包以便及时处理用户请求。

coldValidatorSet主要用于修改系统配置,如更新其他验证者集合的名单,或处理桥合约的锁定状态,且有权直接使某些提款请求失效。

lockers是一组特殊权限的验证者,类似于Layer2常见的"安全委员会",在紧急情况下可投票决定是否暂停跨链桥运作。目前Hyperliquid桥的lockers集合包含5个地址,只需2个locker投票即可暂停桥合约。

finalizers也是一组特殊验证者,主要用于确认跨链桥的状态变更,如用户存取款等操作。Hyperliquid的跨链桥采用"提交-确认"机制,用户发起提款后需等待一段"争议期",期满后由finalizers执行提款交易。

如遇问题,如某笔提款申请超出用户实际余额,Hyperliquid节点可在争议期内通过lockers投票暂停桥合约,或由coldValidatorSet直接使问题提款无效。

目前Hyperliquid仅有4个验证者节点,因此hotValidatorSet和coldValidatorSet各对应4个链上地址。初始化时,Hyperliquid自动将hotValidatorSet内地址注册为lockers和finalizers成员,而coldValidatorSet由官方控制,使用冷钱包存储密钥。

存款

Hyperliquid的桥合约基于EIP-2612的Permit方法处理用户存款,且仅支持USDC一种资产。相比传统Approve-Transfer模式,Permit更为简洁,便于批量操作。

桥合约使用batchedDepositWithPermit函数批量处理多笔存款,流程简单且无资金安全风险,主要是利用Permit方法优化用户体验。

提款

相较存款,提款是高风险操作,因此逻辑更为复杂。用户发起提款请求后,Hyperliquid节点调用桥合约的batchedRequestWithdrawals函数。此时要求每笔提款请求获得hotValidatorSet的2/3签名权重,注意是"2/3签名权重"而非"2/3签名数量"。目前Hyperliquid仅有4个权重相同的节点,故检查签名权重与签名数量暂时一致,但未来可能引入高权重节点。

发起提款请求后,跨链桥不会立即转移USDC,而是有200秒的"争议期"。在此期间可能出现两种情况:

1. lockers认为提款请求存在严重问题,可直接投票冻结合约;

2. 节点认为部分提款有问题,coldValidatorSet成员可调用invalidateWithdrawals函数使该笔提款无效。

若争议期内无异常,期满后finalizers成员可调用batchedFinalizeWithdrawals函数确认最终状态,此时USDC才会转入用户在Layer2的钱包地址。

从安全模型角度看,恶意攻击者若要在Hyperliquid提款流程中作恶,需突破三道防线:

1. 掌握hotValidatorSet的2/3签名权重,即获取足够私钥或串谋。目前仅4个验证者,被控制或串谋可能性不低;

2. 在争议期内避免恶意交易被发现,否则可能触发lockers锁定合约;

3. 获取至少一个finalizers成员私钥,确认提款。目前finalizers与hotValidatorSet成员基本一致,满足条件1即可满足条件3。

桥合约的锁定

Hyperliquid设置了锁定跨链桥合约的功能。具体而言,需lockers成员调用voteEmergencyLock函数投票,目前2名lockers投票即可锁定并暂停桥合约。

值得注意的是,Hyperliquid桥还提供unvoteEmergencyLock函数,允许lockers撤回投票。一旦桥合约被锁定,只能通过emergencyUnlock函数解锁,需收集coldValidatorSet成员2/3以上签名权重。

emergencyUnlock解锁的同时会更新hotValidatorSet和coldValidatorSet验证者地址集合,并立即生效。

验证者集合更新

相比突破提款流程防线,直接使用updateValidatorSet函数更新验证者集合是更有效的攻击手段。这需要所有hotValidatorSet成员签名,且有200秒争议期。

争议期结束后,需finalizers成员调用finalizeValidatorSetUpdate函数完成最终更新。

总结Hyperliquid桥合约存在以下风险:

1. 黑客控制coldValidatorSet后可无视阻拦盗取用户资产。因coldValidatorSet拥有emergencyUnlock权限,可使lockers锁定无效并即时更新节点名单。目前仅4个验证者节点,私钥被盗风险不低;

2. finalizers拒绝确认用户提款交易,展开审查攻击。此时用户资产安全但可能无法提取;

3. lockers恶意锁定跨链桥,阻止所有提款交易执行,只能等coldValidatorSet解锁。

HyperEVM与双链交互架构

为实现订单簿交易的可编程化,如引入隐私交易等需智能合约支持的场景,Hyperliquid推出HyperEVM方案。它较传统EVM有两大优势:可读取Hyperliquid订单簿状态,且内部智能合约可与订单簿系统交互,大幅拓展了应用场景。

例如,用户若需保证挂单隐私性,可在HyperEVM上通过类似Tornado Cash的合约添加隐私层,再通过特定接口在Hyperliquid订单簿系统触发挂单。

Hyperliquid为HyperEVM设计了特殊架构。考虑到定制化订单簿系统性能远超EVM环境,为避免速度下降,Hyperliquid采用"双链方案":每个节点同时运行两条链,本地存储两链数据并分别处理交易。

Hyperliquid为订单簿系统设置专用链(HyperL1,许可制),同时增设EVM兼容链(HyperEVM,无许可)。两链数据通过相同共识协议传播,作为统一状态存在,但在不同环境中运行。HyperL1出块速度快于HyperEVM,但区块仍按序执行。EVM链上合约可读取过往L1区块数据,并向未来L1区块写入数据。

HyperL1和HyperEVM交互主要通过Precompiles和Events实现。

Precompiles

预编译(Precompiles)将复杂操作直接在底层实现,用C/C++等语言处理Solidity不友好的计算。预编译本质是特殊智能合约,其他合约可调用并获取执行结果。目前原生EVM已用预编译实现ecRecover指令(0x01地址)。

HyperEVM也增加了预编译代码,实现对Hyperliquid订单簿系统状态的读取。已知一个预编译地址为0x0000000000000000000000000000000000000800,可读取最近L1区块内用户永续合约仓位。

Events

HyperEVM向HyperL1写入数据依赖Events实现。Events是EVM原生概念,允许合约向外部发送日志信息。如ERC-20转账时会抛出Transfer事件,便于监听。许多跨链场景也用Events传递参数。

HyperLiquid节点监听0x3333333333333333333333333333333333333333地址抛出的Events,根据信息获知用户意图并转化为交易动作,写入未来L1区块。如该地址提供函数,调用时抛出IocOrder事件,L1出块时节点检索到新IocOrder事件就转化为L1内挂单操作。

HyperBFT

共识协议方面,Hyperliquid采用基于HotStuff衍生的HyperBFT协议。初期使用Tendermint算法,但效率低下,每阶段需All-to-All消息交换,复杂度O(n²)。

为达到中心化交易所速度,团队开发HyperBFT并用Rust实现,理论上每秒可处理200万笔订单。HyperBFT中所有消息由Leader汇总广播,免去节点间交换消息,大幅降低复杂度。

简言之,HyperBFT是当前leader出块,全体节点投票并将结果统一发给Leader,再轮换下一leader的共识协议。

开发者注意事项

1. 基于Precompiles的数据读取机制较完善,但需注意msg.sender问题。用户与L1系统合约交互间接触发EVM交易时,EVM内msg.sender为L1系统合约地址而非用户地址。

2. EVM与L1交互存在非原子性问题。如用户通过EVM在L1挂单但资产不足,交易失败但调用函数时无错误提示。开发者需在EVM合约端处理挂单失败情况,并设置资金收回函数。

3. EVM合约地址在L1需有映射账户。部署EVM合约后,需向L1映射地址转少量USDC创建账户。

4. 注意特殊情况如代币余额。L1有特殊地址用于资产跨链,但跨链后EVM可能未及时出块,用户暂时无法读取余额。开发者应处理此类情况避免用户恐慌。