理解Hyperliquid的架构：HyperBFT、HyperCore和HyperEVM（第一部分）

引言

如果你作为开发者或交易者使用 Hyperliquid 有一段时间了，你可能在各处都看到过这三个词：HyperBFT、HyperCore 和 HyperEVM。

它们出现在文档中，X 上的技术帖子中，开发者之间的对话中……但要清楚地了解每一个实际上是什么或它们如何组合在一起仍然非常容易。

当然，Hyperliquid 发展迅速。每个人都在谈论它，你不想觉得自己错过了什么重要的东西。

你可能在某个时候打开过官方文档，看过著名的 Hyperliquid 堆栈图，并想过类似这样的话：

“好吧……我想我明白了……但又不是完全明白 🤔”

这通常是困惑开始的地方。不是因为该图是错误的，而是因为它将共识、执行和应用程序概念混合到单个图像中。如果你还没有正确的心理模型，很容易迷失方向。

这就是我写这篇文章的原因。这是分为两部分的系列文章的第一部分，旨在帮助想要真正理解 Hyperliquid 的开发者、技术交易者和创始人。

→ 在第 1 部分中，我们将构建正确的心理图：

• 每一层/组件是什么，
• 为什么存在，
• 以及它有什么责任。

→ 第 2 部分我们将亲自动手：这些层实际如何通信，限制是什么，以及如何在不破坏任何东西的情况下在顶部构建。

话不多说……让我们开始吧 🦾。

1. 从基础开始：HyperBFT

整个堆栈的基础是 HyperBFT，Hyperliquid 的原生共识算法。

它的工作非常简单，但绝对关键：确保所有节点都就哪个区块接下来出现、其中包含什么以及何时该区块最终确定达成一致。

没有这个，构建在堆栈之上的任何东西都不会稳定。

HyperBFT 的灵感来自 HotStuff，这是一种为需要速度的区块链设计的共识算法。HotStuff 背后的关键思想是在没有每个验证者不断与其他每个验证者交谈的情况下达成共识（这会在其他系统中引入大量延迟）。

因此，HotStuff（以及由此扩展出来的 HyperBFT）提供了：

• 低延迟，
• 高吞吐量，
• BFT 安全性，
• 和快速最终性（一旦区块被最终确定，它就不会被回滚，再见重组 👋🏻）。

Hyperliquid 采用了这个模型，对其进行了优化，并构建了 HyperBFT：一个定制版本，旨在以可靠和确定的方式支持非常高的执行吞吐量。

2. Hyperliquid 有两个引擎，而不是一个

在 HyperBFT 之上看到两个不同的区块：HyperCore 和 HyperEVM，这并非巧合。这已经是一个重要的线索，Hyperliquid 不像大多数区块链那样在单个引擎中执行所有操作。

在传统的基于 EVM 的链中，所有内容都在同一个地方运行：智能合约、金融逻辑和状态更新。

这种模型非常适合通用应用程序。但是，一旦你尝试在其中运行一个严肃的交易所，两个问题会立即出现：延迟和 gas 争用。

在一个传统的 EVM 上运行一个具有 Hyperliquid 所需的延迟和一致性要求的链上 CLOB，就像用一辆街车参加一级方程式赛车一样。它可能会启动，但不会获胜 🥵。

Hyperliquid 选择了一条不同的路径，将其系统拆分为两个不同的引擎，每个引擎都有一个非常明确的目的，同时仍然存在于同一个 L1 中：

• HyperCore：纯粹的金融引擎
• HyperEVM：智能合约环境

HyperCore 是实际交易发生的地方。它专门设计用于以确定且节点一致的方式运行高速交易所。

HyperEVM 稍后出现，以解决一个不同的问题：允许构建者使用智能合约创建任意逻辑，而无需触及金融核心。

由于这种职责分离，可以在 Hyperliquid 周围构建，而不会危及订单簿、清算或关键系统状态。

这种设计决策还解释了为什么 Hyperliquid 可以保持低延迟，而不会损害其金融状态的连贯性或安全性。

即使 HyperCore 和 HyperEVM 是分开的，它们也共享相同的共识（HyperBFT）和相同的区块，同时保持完全独立的状态。

区块在 Hyperliquid 中的工作方式

虽然官方文档没有在单个、明确的部分中描述这一点，但以下执行模型可以从 Hyperliquid 构建其 L1 和 HyperEVM 执行的方式中推断出来。

Hyperliquid 具有由 HyperBFT 最终确定的单个 L1 区块序列。所有核心金融状态转换 (HyperCore) 都锚定到此 L1 区块流。

在此 L1 时间线之上，HyperEVM 执行是使用两种类型的 EVM 执行区块进行调度的：

• 小型 EVM 区块，频繁生成（目前每秒一次），用于常规交易和轻量级合约交互。
• 大型 EVM 区块，以较慢的节奏生成（目前每分钟一次），旨在包含更大的交易，例如合约部署或更复杂的逻辑。

并非每个 L1 区块都会生成 EVM 区块。但是，当生成 EVM 区块（小型或大型）时，它是从相同的 L1 区块排序和共识中派生的，并在其下最终确定。

这种设计允许 Hyperliquid 将 HyperEVM 执行的区块速度与区块大小分离，同时保持单一、连贯的 L1 状态和共识。

关键示例：一笔交易

为了使这一点具体化，让我们考虑一些非常具体的事情：一笔交易。

1. 用户提交订单，该订单进入 Hyperliquid 的区块 N。
2. 此时，HyperCore 负责所有金融执行。

3. 这是所有金融活动发生的地方：订单进入订单簿，被匹配，执行，余额和仓位被更新，如果风险状况需要，则会触发清算。
4. 一旦 HyperCore 处理了该区块，与区块 N 相关的金融状态是最终的和确定的。

5. 如果该 L1 区块包含 HyperEVM 执行（小型或大型 EVM 区块），智能合约可以观察到该最终确定的交易并在其之上执行逻辑。

没有并行区块。没有异步执行。没有“合约在交易最终确定之前执行”之类的说法。

一切都按区块移动，以相同的顺序，在相同的共识下。

3. HyperCore：为交易优化的金融引擎

此时，应该清楚 HyperCore 是“实际交易发生的地方”。

但重要的是要理解 HyperCore 不仅仅是另一个模块或一个巨大的智能合约。它是 L1 的金融状态机。

如果它崩溃了，这就是所有人都将有感觉的地方 🥲。

在前面显示的 Hyperliquid 堆栈图中，你将看到 HyperCore 内的五个列：现货、永续合约、预言机、金库和治理。

但要正确理解这些，我们首先需要查看两个关键的内部组件：匹配引擎和清算所。

3.1 匹配引擎和清算所

匹配引擎是一个组件，它决定哪些订单匹配，以什么价格，以什么优先级以及以什么确切的顺序匹配。

每个交易所都有一个，Hyperliquid 也不例外。但是，存在一个关键的区别：它不是为了最大化交易量或偏爱最快的交易者而设计的。

它是为了保护零售用户的体验而设计的。

为了实现这一目标，L1 本身强制执行严格的执行顺序规则。例如，取消和仅挂单订单的优先级高于吃单订单。这避免了一个经典问题：针对不再希望被填充的订单执行。

结果是一个更健康的市场：更少的有害流动、更窄的价差和更公平的执行。

这些类型的规则无法通过简单的智能合约来实现。它们要求匹配引擎位于 L1 的金融引擎内部，执行顺序由共识强制执行。

另一方面，清算所负责在每次交易后更新所有金融状态：仓位、余额、PnL、保证金和风险。

如果保证金不足，则清算直接从 HyperCore 触发。

3.2 你在 Hyperliquid 堆栈中看到的内容……以及它实际的含义

现货

现货列代表一个传统的现货市场，就像你在 CEX 上看到的那样。它包括一个链上订单簿，执行订单的匹配引擎，以及在每次交易后调整余额的清算所。

这是一个完整的现货交易所，但在 L1 内部执行，没有不透明的组件。

永续合约

永续合约列使用与现货相同的引擎，但增加了一个额外的金融逻辑层：仓位、保证金、风险和清算。它也有自己的订单簿，就像现货一样。

预言机

该图以复数形式显示“预言机”是有原因的。Hyperliquid 不依赖于单个外部信息源或 EVM 部署的预言机合约。

价格逻辑直接位于 HyperCore 内部，并且是 L1 状态的一部分。它的作用是为每个资产维护连贯的价格参考。

所有节点都使用这些参考来计算 PnL、评估风险、决定清算并确保每个人都执行完全相同的状态。

基于这些价格参考，系统可以确定仓位是否健康或即将被清算。

金库

Hyperliquid 有两种不同类型的金库。

一方面，有协议金库，其中最重要的是 Hyperliquidity Provider (HLP)。HLP 是一个协议原生金库，它充当系统级别的经济参与者：它通过协议定义的做市策略提供流动性，参与由 HyperCore 管理的清算过程，向 Earn 机制提供 USDC，并累积一部分交易费用。

另一方面，有用户金库，允许交易者创建金库，其他用户可以在其中存入资金并获得对其策略的敞口。即使它们是由用户创建的，它们也不是在 EVM 上部署的合约或 DeFi 产品，它们是原生交易所功能，直接由 HyperCore 管理。

治理

治理也不是合约，也不在 HyperEVM 中。

它是 L1 状态的一部分，因为它控制着直接影响金融引擎的参数：风险规则、市场激活、杠杆限制、内部调整等。

这些是交易所的规则，嵌入在 HyperCore 内部，以确保所有节点应用完全相同的逻辑，避免不一致的状态，并保持执行完全确定。

例如，如果协议激活了一个新市场或更新了一个风险参数，则该更改必须同时应用于所有节点。这就是治理位于 HyperCore 内部而不是智能合约中的原因。

3.3 一句话概括 HyperCore

如果我们要用一句话概括 HyperCore，那就是：

HyperCore 是 Hyperliquid L1 的金融引擎。

这是交易所中真正重要的所有内容所在：订单簿、匹配、仓位、风险、PnL、清算和内部协议规则。

它速度快、确定性强，并且在节点之间保持一致。

它不执行智能合约，它不参与 gas 竞争，并且它不依赖外部机器人来正常运行。

它的状态是完全透明的，任何人都可以检查订单簿、交易、清算或仓位。但它的实施是私有的：你可以验证它做什么，但不能验证它内部如何编写。

简而言之：HyperCore 是使 Hyperliquid 成为真正的交易所的原因……完全在链上。

4. HyperEVM：无需许可的智能合约环境

如果 HyperCore 是金融引擎，那么 HyperEVM 就是创意空间。

它是一个通用的、无需许可的虚拟机，构建者可以在其中部署智能合约来围绕交易所构建逻辑，而无需触及金融核心。

所以如果你懂 Solidity，你会感到宾至如归 😌。

4.1 HyperEVM 列：它们代表什么（以及不代表什么）

在前面显示的 Hyperliquid 堆栈图中，你将在 HyperEVM 内部看到五个列：借贷、拍卖、原生稳定币、桥以及“更多应用程序”。 与 HyperCore 中的列不同，这些列不代表协议组件。相反，它们描述了可以在 HyperEVM 上构建的应用程序类型。

借贷

这不意味着 HyperEVM 包含原生的 DeFi 借贷市场。

默认情况下，HyperEVM 不附带借贷协议、流动性池或利率系统。它只是为构建者提供使用智能合约部署它们的环境。

HyperCore 确实包含专门用于其保证金系统的内部借贷和供应基元（目前在测试网中），但这并非传统的 DeFi 借贷市场。

HyperEVM 层是可部署完整借贷协议的地方：货币市场、借贷池、收益策略，或使用 HyperCore 资产的更复杂的信贷产品。

拍卖

此列表示可以使用智能合约在协议的原生金融引擎之外构建任意拍卖机制。

Hyperliquid 确实在非常特定的情况下使用原生拍卖，例如 HIP-1 和 HIP-3 代币部署，但这些机制是 HyperCore 内部逻辑的一部分，并且不作为通用的、可重用的基元公开。

原生稳定币

此列表示可以在 HyperEVM 上构建无需许可的稳定币。

例如，抵押/超额抵押稳定币，或使用多种资产的混合模型。

关键在于，即使稳定币部署在 HyperEVM 上，它也不会自动成为协议核心的一部分。它不能直接用于保证金、风险计算或清算。

所有这些仍然是 HyperCore 的专有责任。

桥

此列经常被误解。Hyperliquid 已经有一个关键的 L1 桥，将其连接到外部世界。

此列指的是 HyperEVM 还允许构建者创建额外的桥和连接系统。

更多应用

就我个人而言，这一列也可以称为“天空才是极限”。

这是一个明确的意图声明：Hyperliquid 团队无法预测将在其上构建什么，但他们已将协议设计为使其成为可能。

HyperEVM 并非为一组封闭的用例而设计。这是一个可以涌现出甚至不存在的应用程序的环境。

是的，我们将来在 Hyperliquid 上看到构建的许多最有趣的东西可能都位于这一列。

结束语

到目前为止，我们已经构建了 Hyperliquid 堆栈的正确心理图 🧠。

你现在知道 HyperBFT 是什么，为什么 Hyperliquid 分离 HyperCore 和 HyperEVM，以及每一层承担什么责任。同样重要的是，你还知道每一层不是什么。

• HyperCore 是金融中心：严格、确定且痴迷于连贯性。
• HyperEVM 是创意空间：无需许可、灵活，并且旨在让构建者可以进行实验而不会危及交易所。

但是，如果你想在其之上构建，仅了解架构是不够的。

在第 2 部分中，我们将深入探讨：HyperCore 和 HyperEVM 实际上如何通信，智能合约可以做什么和不能做什么，以及为什么 Hyperliquid 做出如此不寻常但有意的设计决策。

如果第 1 部分为你提供了地图，那么第 2 部分将向你展示如何在地形中移动 😏。

参考资料和延伸阅读

Hyperliquid 文档

https://hyperliquid.gitbook.io/hyperliquid-docs

HyperCore 概述

https://hyperliquid.gitbook.io/hyperliquid-docs/hypercore

HyperEVM 概述

https://hyperliquid.gitbook.io/hyperliquid-docs/hyperevm

考虑在 Hyperliquid 上构建或启动 DeFi 项目？

Zealynx 专门从事智能合约审计和区块链安全评估。如果你想确保你的集成是安全的并且能够适应未来发展，请联系我们进行友好的聊天，或在 Twitter 上与我们联系 @sudosuberenu 和 @TheBlockChainer。

常见问题解答

1. Hyperliquid 是 CEX 还是 DEX？

Hyperliquid 是一个完全链上的 DEX（去中心化交易所）。与托管、订单匹配和结算发生在私有服务器上的 CEX 不同，Hyperliquid 在其自己的 L1 区块链上运行所有内容。你保留对资金的托管权，并且每个订单和交易都以透明的方式在链上记录。它将 CEX 的速度和用户体验与 DEX 的透明度和自我托管相结合。

2. Hyperliquid 是 L1 还是 L2？

Hyperliquid 是一个专门构建的 Layer 1 区块链。它运行自己的共识机制（HyperBFT）并且不结算到以太坊或任何其他链。这种设计使 Hyperliquid 能够完全控制区块生产、执行速度和交易排序，从而实现竞争性交易所所需的亚秒级最终性。

3. HyperCore 和 HyperEVM 之间有什么区别？

HyperCore 是原生金融引擎，所有交易都在这里发生 - 订单簿、匹配、仓位、保证金和清算。它不是智能合约；它是直接构建到 L1 中的，以实现速度和确定性。HyperEVM 是一个独立的、无需许可的 EVM 环境，开发者可以在其中部署 Solidity 合约。两者共享相同的共识和区块序列，但维护独立的状态。

4. Hyperliquid 有多快？

Hyperliquid 实现了亚秒级区块时间，具有即时最终性 - 一旦一个区块被最终确定，它就不能被回滚。没有重组或确认等待。HyperBFT 共识实现了这种速度，而双引擎架构确保了 HyperCore 中的交易操作不会与智能合约执行竞争区块空间。

5. 什么是 CLOB，为什么 Hyperliquid 使用它？

CLOB（中央限价订单簿）按价格和时间优先级匹配买卖订单 - 传统证券交易所和 CEX 使用的相同模型。Hyperliquid 使用完全链上的 CLOB 而不是 AMM，因为它为专业的交易者提供更窄的价差、更好的价格发现和熟悉的交易机制（限价单、止损单等）。

6. 我可以在 Hyperliquid 上构建 DeFi 应用程序吗？

是的。HyperEVM 是一个无需许可的 EVM，任何人都可以在其中部署 Solidity 智能合约，而无需获得批准。你可以构建借贷协议、稳定币、金库或任何 DeFi 应用程序。你的合约可以观察 HyperCore 的交易状态（价格、仓位、余额），但不能直接修改金融引擎 - 这种分离保护了交易所的稳定性，同时实现了创新。

词汇表

查看完整词汇表 → (https://www.zealynx.io/glossary)

• 原文链接： zealynx.io/blogs/Underst...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～