Hyperliquid 架构详解：安全与去中心化

为什么 Hyperliquid 在 2025-2026 年很重要

链上衍生品已从一个细分 DeFi 产品发展成为加密市场的核心基础。仅在 2025 年，永续合约 DEX 的生命周期交易量增长就急剧加速，这反映了一种更广泛的转变：交易者越来越希望获得类似中心化交易所的执行，同时又不放弃链上透明度和自我托管。总结 DefiLlama 永续合约 DEX 交易量趋势的报告，突显了这个细分市场的快速扩张。(cointelegraph.com)

Hyperliquid 处于这场变革的中心，因为它“不仅仅是一个永续合约应用”。它是一个专门构建的第一层（Layer 1），旨在以极高的吞吐量运行链上订单簿，并通过 HyperEVM 将这一基础扩展为一个通用的智能合约环境。根据 DefiLlama 的 Hyperliquid仪表板，Hyperliquid 的累计永续合约交易量已达数万亿美元，这凸显了其作为链上杠杆交易重要场所的地位。(defillama.com)

本文将剖析 Hyperliquid 的架构，并围绕以下两个问题展开：

• 它如何在保持链上的同时实现高速运行？
• 安全性和去中心化方面的权衡体现在哪些方面？

Hyperliquid 一图概览（心智模型）

Hyperliquid 是一个区块链，由运行一种名为 HyperBFT 的 BFT 类型 PoS 共识的验证者集合来保证安全。执行被分为两个域：

• HyperCore： 专门构建的金融原语（现货 + 永续合约订单簿、保证金、清算）
• HyperEVM： 构建在同一 L1“内部”的 EVM 执行环境，继承相同的共识安全

Hyperliquid 自己的文档在其 技术概述 中明确描述了这种划分。(hyperliquid.gitbook.io)

共识：HyperBFT 和“BFT 类型最终性”的含义

HyperBFT 是 HotStuff 启发的 PoS 共识

Hyperliquid 表示，它由HyperBFT 提供安全保证，“一种 HotStuff 共识的变体”，区块生产与质押成正比。请参阅 HyperCore 概述。(hyperliquid.gitbook.io)

如果您想了解“HotStuff 系列”共识在部分同步下的优化目标（响应速度和效率），可以查阅原始论文 HotStuff: BFT Consensus in the Lens of Blockchain。(arxiv.org)

实际启示： BFT 类型 PoS（相对于概率性最终性）对订单簿 DEX 具有吸引力，因为交易者在波动期间关心确定性排序和快速最终性。

多数投票、围栏和验证者轮次

Hyperliquid 的质押文档强调了经典的 BFT 多数投票假设：多数票（Quorum）是 > 2/3 的质押量，安全性和活性假设多数票的质押量是诚实的。它们还描述了：

• 共识在“轮次”中进行
• 验证者集合的变化发生在轮次（Epoch）中（而非持续进行）
• 因表现不佳而围栏（Jailing）（不同于罚没 slashing）

请参阅 质押（技术细节）。(hyperliquid.gitbook.io)

这对去中心化的重要性： “谁持有质押、谁运行验证者以及集合如何随时间变化”不仅仅是治理问题，它构成链核心安全模型的一部分。

执行层：为什么 HyperCore 与典型的 DEX 设计不同

完全链上订单簿（非链下撮合引擎）

一种常见的 DEX 模式是：链下订单簿 + 链上结算（或链上 AMM）。Hyperliquid 的定位不同：HyperCore 的设计宗旨是订单、撤销、交易和清算都发生在链上，通过共识产生单一的、一致的排序。

他们的文档强调，HyperCore「不依赖链下订单簿这一权宜之计」，并且它将保证金和撮合引擎的状态都包含了在链上。详情请参阅 HyperCore 概述。(hyperliquid.gitbook.io)

延迟和吞吐量目标

Hyperliquid 报告称，对于共置的客户端，端到端延迟极低，主网吞吐量约为 ~20 万订单/秒，同样在 HyperCore 概述 中。(hyperliquid.gitbook.io)

这是其核心架构的重点：Hyperliquid 没有先构建一个通用链，而是围绕金融消息吞吐量（订单、撤销、清算）优化了基础链。

HyperEVM：无需成为“独立链”即可实现可编程性

HyperEVM 继承 HyperBFT 安全性

Hyperliquid 非常明确地指出 HyperEVM 不是一个独立的网络：「EVM 块 [被] 构建为 Hyperliquid 执行的一部分，继承了 HyperBFT 共识的所有安全性。」详情请参阅 HyperEVM（开发者文档）。(hyperliquid.gitbook.io)

来自同一文档的关键操作细节：

• 主网 Chain ID: 999
• 启用了 EIP-1559（Cancun 硬分叉，不含 blobs）
• HYPE 是原生 gas 代币
• 优先费用也会被燃烧（一个值得注意的设计选择）

详情请参阅 HyperEVM（开发者文档）。(hyperliquid.gitbook.io)

双区块架构：小区块供用户，大区块供构建者

HyperEVM 采用双区块架构，以避免在快速确认和大型区块大小之间进行单一的強制权衡。Hyperliquid 文档指出：

• 小区块的确认时间约为 ~1 秒，Gas 上限为 200 万
• 大区块的确认时间约为 ~1 分钟，Gas 上限为 3000 万

详情请参阅 双区块架构。(hyperliquid.gitbook.io)

重要性： 这是 Hyperliquid 将 L1 设计定制化以满足实际交易和应用程序需求的一个最清晰的例子：交易者希望快速确认；DeFi 构建者则需要为更重的合约部署留有空间。

HyperCore 和 HyperEVM 之间的资产如何移动

Hyperliquid 描述了跨域转移（Core → EVM 排队等待下一个 EVM 区块；EVM → Core 在 EVM 区块之后立即处理）的具体时间规则。详情请参阅 交互时间。(hyperliquid.gitbook.io)

并且 Hyperliquid 提供了一个将 HYPE 转移到 HyperEVM 的标准机制（发送到特定地址）。详情请参阅 HyperEVM（开发者文档）。(hyperliquid.gitbook.io)

示例（如文档所示）：

要将 HYPE 从 HyperCore 转移到 HyperEVM：
将 HYPE 发送到 0x2222222222222222222222222222222222222222

安全模型：什么受共识保护，什么属于“应用风险”

理解 Hyperliquid 安全的一个有用方法是区分以下几个方面：

• 共识安全（HyperBFT 正确性、法定人数假设、验证者行为）
• 执行正确性（HyperCore 匹配/保证金逻辑、HyperEVM EVM 语义）
• 桥接和资产托管路径（资金如何进出、依赖哪些合约）
• 预言机和风险控制（标记价格、未平仓量上限、清算行为）

风险披露：L1 风险、预言机操纵和桥接风险

Hyperliquid 风险页面本身就指出了：

• L1 停机风险（较新的链，经受的考验较少）
• 预言机操纵风险（由验证者维护的预言机）
• 智能合约/桥接风险（文档特别提到了对桥接合约的依赖）

该页面还提到了缓解措施，例如未平仓量上限以及对远离预言机价格的、针对流动性较低资产的订单的限制。（hyperliquid.gitbook.io)

Bug Bounty 作为安全反馈回路

Hyperliquid 运行一个官方 Bug Bounty 计划，涵盖主网节点/API 问题以及（在测试网上）HyperEVM 交互界面。(hyperliquid.gitbook.io)

安全启示：在快速发展的 DeFi 基础设施领域，持续激励负责任的披露并非可选项——而是协议运行的一部分。

协议层内置多签（HyperCore）

一个值得注意的设计选择是：HyperCore 将原生多签操作作为内置原语支持，而不是要求采用智能合约钱包模式。请参阅多签（HyperCore）。（hyperliquid.gitbook.io)

**用户启示：**如果您是运营商、LP 或高价值交易者，多签可以降低单密钥风险，而单密钥风险仍然是加密领域最常见的故障模式之一。

去中心化：Hyperliquid 的优势所在以及仍存争议之处

去中心化并非单一指标。对于 Hyperliquid 而言，它通常归结为：

• 验证者独立性和质押分布
• 代码透明度（开源 vs 闭源组件）
• 治理和紧急权力（验证者在实践中能做什么？）

“闭源节点”和质押集中化争论（2025 年）

2025 年初，Hyperliquid 因去中心化问题面临公众审查——涉及验证者公平性、质押集中化以及当时节点代码并未完全开源的事实。CoinDesk 报道了 Hyperliquid 的回应，包括加强去中心化的计划以及对委托计划的提及。请参阅CoinDesk 报道。（coindesk.com)

为何在架构上很重要： HotStuff 风格的 PoS 链在技术上可以非常健壮，但去中心化的认知在很大程度上取决于验证者是否能够独立运作（包括以最小的“把关”审查和运行节点软件）。

验证者干预作为实况压力测试

在一次备受瞩目的市场事件后，出现了另一场关于去中心化的讨论：验证者下架了一个永续合约市场并强制平仓，这引发了关于在极端条件下“不可阻挡”的市场极限的疑问。Blockworks 描述了这一事件，并将其定性为揭示了去中心化的约束。请参阅Blockworks 分析。（blockworks.co)

这凸显了链上衍生品的一个核心张力：

• 交易员在操纵企图期间要求强大的风险管理
• DeFi 用户期望可信的中立性和可预测的规则

健康的去中心化问题值得思考： 紧急措施是基于规则的、透明的，并且具有明确的合法性治理——还是应急性的？答案会影响用户是将系统视为不可变的基础设施，还是视为受管理的交易场所。

「安全 + 用户体验」是链上永续合约的新战场

2025 年，链上永续合约的交易量达到了创纪录的水平，交易场所之间的竞争也日益激烈。市场结构正朝着以下方向转变：

• 更低的执行延迟
• 更深的流动性
• 更清晰的风险控制
• 更强的托管和访问保障

这就是为什么 Hyperliquid 的架构很重要：它试图将高性能交易作为一级（L1）功能的首要要素，而不是“硬塞”上去的。

用户（交易员、LP 和构建者）的实用清单

1) 将关键安全视为交易优势的一部分

如果你无法保护你的密钥，那么任何性能优势都无关紧要。Hyperliquid 自己的支持文档强调了防范钓鱼攻击和验证官方 URL。请参阅支持指南。(hyperliquid.gitbook.io)

2) 使用多签（或至少划分角色）

对于团队而言，请考虑区分：

• 交易操作员密钥
• 财务托管密钥
• 合约的部署/管理员密钥（如果你在 HyperEVM 上构建）

HyperCore 内置的多签对此非常有用。请参阅多签（HyperCore）。(hyperliquid.gitbook.io)

3) 使用杠杆前了解预言机和流动性风险

阅读协议自身的风险页面，并将其视为强制性的交易前尽职调查，而不是法律套话。(hyperliquid.gitbook.io)

OneKey 的定位（与链上速度相匹配的自托管）

Hyperliquid 的演变（尤其是 HyperEVM）强化了一个简单的趋势：更多严肃的交易和 DeFi 活动正在向链上迁移，这使得安全交易签名和操作安全变得更加重要——而非次要。

像 OneKey 这样的硬件钱包可以在安全堆栈中发挥实用作用：

• 将私钥与日常设备隔离
• 在高频 DeFi 活动中减小钓鱼和恶意软件的攻击范围
• 与多账户操作设置（区分交易与财务）良好配合

目标不是减慢用户速度，而是让“快速链上金融”在真实的威胁模型下能够生存。

最终想法：Hyperliquid 的架构是通向统一链上金融的押注

Hyperliquid 的设计是连贯的：一个受 HotStuff 启发的 BFT PoS 共识，针对延迟进行了优化；一个专门的金融执行引擎（HyperCore）；以及一个紧密集成的 EVM 环境（HyperEVM），旨在带来可组合性，同时不牺牲基础链的性能特征。文档中将 HyperCore + HyperEVM 描述为一个统一的系统是理解整个堆栈的关键。请参阅关于 Hyperliquid。(hyperliquid.gitbook.io)

同时，2026 年关于 Hyperliquid 最重要的讨论很可能仍然是那些定义了广泛 DeFi 基础设施的相同讨论：

• 随着使用量的扩展，去中心化如何发展
• 验证者权力如何变得透明和受规则约束
• 安全流程（赏金、审计、事件响应）如何跟上增长的步伐