--- title: "Hyperliquid 为什么这么快：和比特币比，它留下了什么、改掉了什么" description: "比特币两个块之间的 7 分 25 秒里，Hyperliquid 出了 6,181 个块。顺着这个差距往下追：两条链共用的是哪副骨架；比特币的 10 分钟花在哪；HyperBFT 怎么用 2/3 质押的签名一步定终局，HotStuff 怎么把投票做成流水线；订单簿为什么直接写进状态机、块里为什么撤单排在吃单前面；70 毫秒出块为什么下单仍要 0.2 到 0.9 秒；以及快的代价落在了谁身上。" pubDate: 2026-10-22 tags: ["Hyperliquid", "比特币", "共识算法", "区块链"] hero: "./hero.svg" refs: - id: hl-explorer title: "Hyperliquid Explorer" url: "https://app.hyperliquid.xyz/explorer" site: "Hyperliquid" note: "本文的区块数据来自它背后的 `https://rpc.hyperliquid.xyz/explorer`（`blockDetails`），2026-10-22 14:20 UTC 前后抓取 #1,193,223,606 起连续 400 块，以及比特币 #972,622 和 #972,623 两个时间戳对应的高度。脚本和数据在作者的调研目录里。" - id: hl-info title: "Info endpoint" url: "https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/info-endpoint" site: "Hyperliquid Docs" note: "`validatorSummaries` 取验证者质押（2026-10-22），`l2Book` 取 BTC 盘口。" - id: mempool title: "mempool.space REST API" url: "https://mempool.space/docs/api/rest" site: "mempool.space" note: "取比特币 #972,474–#972,623 共 150 块的时间戳和交易数，以及近一周各矿池出块数（2026-10-22）。" - id: nakamoto title: "Bitcoin: A Peer-to-Peer Electronic Cash System" url: "https://bitcoin.org/bitcoin.pdf" author: "Satoshi Nakamoto" date: "2008-10-31" note: "第 4 节工作量证明，第 11 节计算攻击者追上诚实链的概率随确认数指数下降。" - id: hl-overview title: "HyperCore Overview" url: "https://hyperliquid.gitbook.io/hyperliquid-docs/hypercore/overview" site: "Hyperliquid Docs" note: "HyperBFT 是 HotStuff 的变体；同地客户端端到端延迟中位 0.2 秒、P99 0.9 秒；主网约 20 万单/秒，瓶颈在执行。" - id: hl-staking title: "Staking" url: "https://hyperliquid.gitbook.io/hyperliquid-docs/hypercore/staking" site: "Hyperliquid Docs" note: "quorum 是超过 2/3 质押的验证者集合；一个 epoch 是 10 万轮，约 90 分钟；可投票 jail 慢的验证者；目前没有自动 slashing。" - id: hotstuff title: "HotStuff: BFT Consensus with Linearity and Responsiveness" url: "https://arxiv.org/abs/1803.05069" author: "Maofan Yin, Dahlia Malkhi, Michael K. Reiter, Guy Golan Gueta, Ittai Abraham" site: "PODC 2019" date: "2019" note: "投票只发给领导者、聚合成证书（QC），每轮提议携带上一块的 QC，三链规则提交。" - id: hl-orderbook title: "Order book" url: "https://hyperliquid.gitbook.io/hyperliquid-docs/hypercore/order-book" site: "Hyperliquid Docs" note: "价格-时间优先；块内先执行不发 GTC/IOC 的动作，再执行撤单，最后是发 GTC/IOC 的动作，同类内保持出块者的顺序。" - id: glassnode-fill title: "Hyperlatency：Fill Latency" url: "https://latency.glassnode.com/fill-latency" site: "Glassnode" note: "2026 年 3 月在 AWS 东京（ap-northeast-1）发 120 次市价单，下单到成交回报中位 884 ms，范围 695–1,634 ms，其中网络约 5 ms。" - id: glassnode-about title: "Hyperlatency：About" url: "https://latency.glassnode.com/about" site: "Glassnode" note: "验证者集中在东京。" - id: rekt-jelly title: "Hyperliquidate II" url: "https://rekt.news/hyperliquidate2" site: "rekt.news" note: "2025-03-26 JELLY 事件：HLP 被动接下大额空单，验证者投票下架 JELLY 永续并按 0.0095 结算。" - id: defiant-jelly title: "Hyperliquid token tanks as another vault attack sparks controversy" url: "https://thedefiant.io/news/defi/hyperliquid-token-tanks-as-another-vault-attack-sparks-controversy" site: "The Defiant" further: true --- 2026 年 10 月 22 日下午，我从两个公开接口各拉了一段区块。比特币第 972,622 块由 F2Pool 挖出，下一块 972,623 在 7 分 25 秒之后才出现[^mempool]。同样这 445 秒里，Hyperliquid 的链从第 1,193,225,778 块走到第 1,193,231,959 块，一共出了 6,181 个块，每块平均装着三千多笔交易[^hl-explorer]。 点开其中一块看，里面几乎全是同一类东西：某个地址在某个币上挂了一张限价单，某个地址撤掉了一张单。整条链像是一台交易所的流水账，每 70 毫秒记一页。 两边都叫“区块链”，都是一块接一块、用哈希串起来的账本。同一类东西，为什么出块速度差了将近四个数量级？Hyperliquid 是把比特币的哪一部分换掉了，又留下了哪一部分？快了这么多，总得有人付出点什么。 我们就从这两段区块开始往下拆。 ## 一、两条链的共同骨架 ### 账本怎么做到“大家一致” 先把两条链摆在一起看（图 1）。比特币和 Hyperliquid 解决的是同一个问题：很多台互不信任的机器，各自保存一份账本，怎么保证每一份都一样？ 两者给出的骨架是相同的。账本本身不直接同步，大家同步的是**交易的顺序**。每台机器从同一个初始状态出发，按同一个顺序执行同一串交易，执行规则是确定的，结果就必然相同。计算机科学里管这个叫“复制状态机”。交易按批打包成**区块**，每一块都记着上一块的哈希，改动历史上任何一块，后面所有的哈希都对不上，所以历史没法悄悄篡改。
两条链的三个相邻区块 上面是比特币 972,621、972,622、972,623 三块，哈希都以一长串 0 开头，分别由 MARA Pool、F2Pool、Braiins Pool 挖出，交易 3,619、3,030、2,113 笔，相邻两块间隔 34 秒和 445 秒。下面是 Hyperliquid 1,193,223,610 到 612 三块，出块者各不相同，交易 3,433、3,270、6,220 笔，间隔 67 毫秒和 66 毫秒。 比特币 · 2026-10-22 14:21–14:29 UTC Hyperliquid · 2026-10-22 14:19:47 UTC +34 s +445 s +67 ms +66 ms 区块#972,621 哈希0000…0037fa7a 矿池MARA Pool 交易3,619 笔 区块#972,622 哈希0000…0057cb86 矿池F2Pool 交易3,030 笔 区块#972,623 哈希0000…01ebbd3b 矿池Braiins Pool 交易2,113 笔 区块#1,193,223,610 哈希0xfee0…0fd1 出块0x0d89…1b1a 交易3,433 笔 区块#1,193,223,611 哈希0x334c…26ef 出块0xe02d…ada5 交易3,270 笔 区块#1,193,223,612 哈希0x770d…a82c 出块0x5795…2d44 交易6,220 笔 同一副骨架：一串互相引用的区块，每块装几千笔签过名的交易。差别在相邻两块之间隔了多久，以及是谁写下了下一块。
图 1 · 两条链的形状一样，节奏差了将近四个数量级
### 相同的还有哪些 **授权方式相同。** 比特币的交易用 secp256k1 曲线上的私钥签名，Hyperliquid 也是同一条曲线，只是签名格式沿用了以太坊的 EIP-712，所以以太坊钱包的地址可以直接用。谁有私钥谁就能动这笔钱，交易所本身不保管密钥。 **可验证性相同。** 任何人都能把区块下载下来自己重放。本文的数据就是这么来的：Hyperliquid 每一块里的每一张挂单、每一次撤单，都可以从公共接口逐条取回来。 **状态机都是专用的。** 比特币的状态是“哪些币还没花”，交易能做的事基本只有转账。Hyperliquid 的核心部分 HyperCore 也不是通用的合约虚拟机，它的状态是余额、仓位、保证金和每个币的订单簿，交易能做的事就是下单、撤单、改单、转账这些交易所动作。这一点后面会变得很重要。 骨架既然一样，速度的差别就只能出在两件事上：**谁来决定下一块里装什么、按什么顺序**，以及**执行这些交易要花多少力气**。先看第一件。比特币为什么要等 10 分钟才排好一次顺序？ ## 二、比特币的排序：工作量证明 ### 难点：陌生人之间怎么定顺序 比特币的网络是开放的，任何人都能随时加入、随时离开，没有一份“成员名单”。在这种环境下，投票是不可能的：一个人开一千个节点，就有一千票。 中本聪的办法是**按算力投票**：谁先算出一个足够小的区块哈希，谁就有权写下一块。哈希算不出捷径，只能一次次试，这就是“工作量证明”（PoW）。图 1 里比特币的哈希都以一长串 0 开头，就是这个“足够小”的痕迹。难度每 2,016 块调整一次，让全网平均 10 分钟才有人抽中一次[^nakamoto]。 ### 为什么偏偏是 10 分钟 抽中的人之间没有任何协调。如果两个矿池在几秒内先后挖出了同一高度的块，网络里就暂时出现两条链，节点各自跟着先收到的那条走。等下一块接在其中一条后面，那条更长，另一条上的块就作废了（图 2 左）。 一个新块传遍全网要几秒。出块间隔必须远大于传播时间，分叉才会少；间隔一短，分叉变多，算力白白浪费，攻击者也更容易用自己的私链追上来。所以 10 分钟不是“机器跑不快”，而是这套抽签机制的安全参数。
比特币的分叉、确认和实测出块间隔 左边是示意：#621 之后两个矿池几乎同时挖出 #622 A 和 #622 B，下一块接在 A 后面，B 作废；交易在 A 里之后每多一块算一次确认，6 次确认约 1 小时。右边是 2026-10-22 实测的 149 个出块间隔：时间戳倒退 5 次，0–5 分钟 59 次，5–10 分钟 32 次，10–15 分钟 14 次，15–20 分钟 11 次，20–30 分钟 19 次，30 分钟以上 9 次。 分叉与确认（示意） 实测：149 个出块间隔 #621 #622 A #622 B #623 … 没人接着挖 B， 它里面的交易回到待打包 交易在 #622 A 里，之后每多一块算一次“确认” 1 2 3 4 5 6 ≈ 1 小时 每多一次确认，被另一条链追上的概率指数下降， 但永远不是零：这叫概率终局。 倒退5 0–5 分59 5–10 分32 10–15 分14 15–20 分11 20–30 分19 ≥ 30 分9 平均 639 秒，中位 377 秒，长短全凭运气。
图 2 · 抽签式出块：间隔随机，交易要靠后续区块一层层“埋深”才算稳
### 结果：间隔随机，终局是概率的 图 2 右边是 2026-10-22 往前数的 149 个出块间隔。平均 639 秒，接近 10 分钟，但中位数只有 377 秒；28 次超过 20 分钟，最长的一次等了 63 分钟，也有 14 次不到 1 分钟。抽签没有记忆，下一次什么时候中，跟上一次隔了多久无关，间隔就呈现这种长尾分布。甚至有 5 次后一块的时间戳比前一块还早，因为协议只要求时间戳大于前 11 块的中位数，矿工填的时间本来就不精确。 更要紧的是**终局性**，也就是“这笔交易确认以后，还会不会被撤销”。在比特币里，一个块永远可能被一条更长的分叉替换掉，只是概率随着后面堆的块数指数下降。习惯上等 6 次确认，大约 1 小时，才把一笔大额转账当成板上钉钉。 吞吐也一样受限。这 150 块平均每块 4,553 笔交易，折合每秒 7.2 笔。拿来转账够用，拿来做交易所是不可能的：一个做市商每秒改几次报价，就能把整条链占满。 **如果放弃“谁都能随时加入”这个前提，排序能不能快得多？** ## 三、Hyperliquid 的排序：HyperBFT ### 换一个前提：一组已知的验证者 Hyperliquid 不让任何人都来抽签写块。写块和投票的资格属于**验证者**：质押了 HYPE 代币、在链上登记过的节点，投票权按质押量算。2026-10-22 这一刻，活跃的验证者有 27 个[^hl-info]。防“一人开一千个节点”的办法从比特币的算力变成了质押：开再多节点，票数也只跟押上的钱成正比。 成员名单一旦确定，就可以用分布式系统里研究了几十年的**拜占庭容错（BFT）共识**：只要作恶或失联的验证者质押加起来不到 1/3，系统就保证不出错。 ### 为什么 2/3 的签名就能一锤定音 规则只有一条：一个块要拿到**超过 2/3 质押**的签名，才算通过，这些签名打包在一起叫“法定人数证书”（quorum certificate，简称 QC）[^hl-staking]。 为什么这样就不会出现两个互相冲突的块都通过？图 3 右边画了这个论证：签块 X 的超过 2/3，签冲突块 Y 的也超过 2/3，两群人必然有超过 1/3 的质押是重叠的。作恶的不到 1/3，所以重叠部分里一定有诚实的验证者，而诚实的验证者不会在同一高度签两个不同的块。于是两个冲突块不可能都拿到证书。 这就是 BFT 和比特币最根本的不同：**一块一旦按规则提交，就是确定的终局**，不存在被更长的链替换掉的可能，也就不需要“再等 6 块”。 ### HotStuff：把投票做成流水线 光有 2/3 规则还不够快。经典的 BFT 算法（如 1999 年的 PBFT）每一步都要所有验证者两两互发消息，节点一多，消息量按平方增长；而且一个块要经过几个阶段的投票才算提交，下一块得等上一块走完。 HyperBFT 是 HotStuff 的一个变体[^hl-overview]。HotStuff 是 2019 年的论文，后来被 Facebook 的 Libra（Diem）区块链采用[^hotstuff]。它做了两件事： - **投票只发给领导者。** 验证者把签名发给下一轮的出块者，由它聚合成一张 QC，消息量随验证者数线性增长。 - **每一轮的提议都带着上一块的 QC。** 一轮投票同时完成两件事：给新块签名，也把更早的块往“提交”推进一步。块和块像流水线一样首尾相接，每一轮都出一个块，不用等前一块的全部阶段走完。 出块者每轮轮换。我们抓的 399 个连续块里出现了 27 个不同的出块者，正好是全部活跃验证者，相邻两块几乎总是换人（图 3 左）。
HyperBFT 的连续四轮与 2/3 法定人数 左边是实测的 #611 到 #614 四个块，分别由 0xe02d、0x5795、0xdf35、0xa82f 提出，时间为 +0、+66、+129、+195 毫秒；每一块都带着上一块的证书 QC，验证者把投票发给下一个出块者。右边是一条代表全部质押的横条：签块 X 的超过 2/3，签冲突块 Y 的超过 2/3，两者重叠超过 1/3，其中必有诚实验证者。 连续四轮（实测块 #611–#614） 为什么超过 2/3 就够 投票 投票 投票 #611+0 ms 0xe02d… 带 QC#610 #612+66 0x5795… 带 QC#611 #613+129 0xdf35… 带 QC#612 #614+195 0xa82f… 带 QC#613 每轮的投票既给本块出证书，也把更早的块往提交推一步。 按 HotStuff 论文的三链规则，#611 要再连上两层证书才提交， 此后永不回滚。HyperBFT 的具体提交规则没有公开。 签块 X：> 2/3 签冲突块 Y：> 2/3 重叠 > 1/3 作恶的质押不到 1/3，重叠里 必有诚实者，它不会两边都签。 反过来：超过 1/3 不投票， 凑不齐证书，链就停下。
图 3 · 已知成员 + 2/3 签名 = 确定终局；证书一轮轮串起来，每轮都出块
实测下来，这 399 个块的间隔中位数 68 毫秒，平均 72 毫秒，P99 也只有 141 毫秒。从 2025 年 11 月的第 8 亿块算到今天，长期平均每秒 13.4 块。 ### 代价：宁可停下，也不分叉 BFT 换来了确定的终局，也改变了网络出问题时的表现。比特币在网络分裂时两边都会继续出块，事后再按“最长链”合并，丢掉一边；HyperBFT 一旦有超过 1/3 的质押不在线，就凑不齐证书，**整条链停下来等**。它选择的是一致性，而不是一直可用。为了减少这种情况，Hyperliquid 允许验证者投票把响应太慢的同伴“关禁闭”（jail），被关的节点不再参加共识[^hl-staking]，我们查询时就有 6 个验证者处于这个状态。 **排序的问题解决了。可是一个 70 毫秒的块里塞得下三千多笔订单，靠的不只是共识。为什么不像以太坊上的交易所那样，把订单簿写成一个智能合约？** ## 四、把订单簿放进状态机 ### 现象：链上几乎全是挂单和撤单 先说明几个交易所的术语。**订单簿**是每个币的一张买卖报价表，买方按价格从高到低排，卖方从低到高排，新来的订单按“价格优先、同价先到先得”去撮合。往订单簿里放一张等别人来成交的限价单叫**挂单**（maker），拿一张单直接去吃掉对面已有的报价叫**吃单**（taker）。Hyperliquid 的订单有几种时效：**GTC** 挂到撤为止，能成交的部分立即成交；**IOC** 能成交多少成交多少，剩下的立刻作废，就是典型的吃单；**ALO**（只挂单）如果会立刻成交就直接拒绝，保证自己一定是挂单方。 把 399 个块里的 124 万笔动作按类型数一遍，结果是这样的：
399 个连续区块里的动作（2026-10-22，约 28.6 秒）
动作含义笔数占比
做市商在维护报价
cancelByCloid按自己编的订单号撤单552,83144.5%
order · Alo只挂单516,69341.6%
cancel按交易所订单号撤单123,5139.9%
batchModify / modify改价改量23,6291.9%
可能立即成交的订单
order · Ioc能吃多少吃多少，剩下作废15,0121.2%
order · Gtc / 市价 / 触发单挂到撤为止、网页市价单、止盈止损2,3450.2%
其他
其余空操作、定时撤单、调杠杆、预言机报价、EVM 交易等9,5180.8%

撤单和只挂单加起来占 96%。按单笔订单计；出错被拒的动作也会上链，约占 0.06%。

表 1 · 链上流量的主角是做市商不停地撤旧报价、挂新报价，真正去吃单的不到 2%
这个比例并不奇怪。价格每跳一下，做市商就要撤掉旧报价、挂上新报价，一笔成交背后是几十次报价更新。一个想做交易所的链，首先得扛住的是这股撤单挂单的洪流。 ### 第一次尝试：订单簿写成智能合约 在以太坊上，最直接的做法是写一个订单簿合约。每次挂单、撤单都是一次合约调用，要付 gas 费；以太坊 12 秒一块，一块的 gas 总量又有限。做市商每秒改几次报价，光撤单的手续费就能把利润吃光，报价还总是慢 12 秒。 所以以太坊上的交易所走了两条别的路：一条是自动做市商（AMM），干脆不要订单簿，用一个公式按池子里的存量报价；另一条是把订单簿和撮合放到链下的服务器上，只把成交结果拿到链上结算。后者快了，可撮合顺序由运营方说了算，用户得信任它没有插队。 ### 解决：撮合引擎就是状态机本身 Hyperliquid 的做法是第三条路：**不在通用虚拟机里跑订单簿，而是把订单簿、保证金、清算直接写成链的状态机**[^hl-overview]。这就是第一节说的“专用状态机”。一个挂单动作不需要被解释成一串虚拟机指令、逐条计算 gas，节点直接用原生代码改内存里的订单簿；挂单撤单也不收 gas，手续费只在成交时收。 这和比特币其实是同一个思路：比特币也只做一件事（转账），所以规则可以写死、执行可以很轻。Hyperliquid 把“一件事”换成了“交易所”。官方说当前的瓶颈恰恰在执行，约每秒 20 万单，共识和网络还有余量。我们实测的那 28.6 秒里，平均每秒约 4.4 万笔。 ### 块内顺序：撤单排在吃单前面 状态机是自己写的，块内的执行顺序也就可以按交易所的需要来定。Hyperliquid 规定，一个块里的动作分三类执行：先执行不发 GTC/IOC 的动作（包括 ALO 挂单），再执行全部撤单，最后才执行发 GTC 或 IOC 的动作；同一类里保持出块者排的顺序[^hl-orderbook]。 我们在 #1,193,223,611 这一块里核对了一下，3,270 笔动作的执行顺序和文档完全一致（图 4 上）。
一个块里的执行顺序 上面是块 #1,193,223,611 的 3,270 笔动作按执行顺序排成一条横条：先是 1,469 笔不吃单的动作，主要是 ALO 挂单；然后是 1,781 笔撤单；最后 20 笔是可能吃单的动作，其中 15 笔是 GTC 或 IOC 下单。下面是示意：做市商撤掉 81,811 的卖单，吃单者用 IOC 去买 81,811，两者落在同一块里时撤单先执行，IOC 吃不到旧报价。 块 #1,193,223,611 的 3,270 笔动作，按执行顺序 ① 1,469 笔不吃单（ALO 挂单等） ② 1,781 笔撤单 ③ 最后 20 笔 同一块里撤单和吃单撞上（示意） 做市商撤单：卖 81,811 吃单者IOC 买：81,811 块内先执行撤单，再执行 IOC IOC 碰不到已经撤掉的旧报价， 只能按新的盘口成交，或者落空
图 4 · 块内的执行顺序是协议规定的：挂单和撤单先于吃单
为什么要这样排？设想价格突然往上一跳，做市商赶紧撤掉 81,811 的旧卖单，另一个反应快的交易者也看到了，发了一张 IOC 想抢着买下这张过时的便宜单。如果按到达先后执行，谁的网络快谁赢，做市商就会被“摘单”；Hyperliquid 规定撤单先执行，只要两张单落在同一块里，做市商就安全（图 4 下）。被摘单的风险小了，做市商才敢把买卖价挂得更近。这是我根据规则推出来的设计动机，文档本身只写了规则。 对照一下比特币：块里装哪些交易、按什么顺序，由矿工按手续费率挑，出价高的先上；以太坊上更是演变出了专门抢排序的 MEV 生意。Hyperliquid 把排序的大部分规则写死在了协议里，出块者只剩下同一类动作内部怎么排的权力。 **块 70 毫秒一个，撮合在状态机里直接完成。那我在网页上下一张市价单，是不是 70 毫秒就能看到成交？** ## 五、出块时间不等于下单延迟 不是。一张订单从发出到拿到成交回报，要走完一整条路：客户端把签好名的订单发给 API 服务器，服务器转给验证者，等下一位出块者把它放进提议，验证者投票、证书串起来、块被提交，节点执行撮合，回报再原路返回。出块间隔只是其中的一段。
几种“快”的口径
口径数字来源
Hyperliquid 出块间隔中位 68 ms本文实测 399 块，P99 141 ms
下单到确认（同地客户端）中位 0.2 s官方文档，P99 0.9 s
市价单下单到成交回报（东京）中位 884 msGlassnode 2026 年 3 月实测 120 次，其中网络约 5 ms
对照
比特币出块间隔平均 639 s本文实测 149 个间隔，中位 377 s
比特币 6 次确认约 1 小时惯例，概率终局

Hyperliquid 的块一旦提交就是终局，所以表里前三行就是“成交且不可撤销”所需的时间。

表 2 · 出块是 70 毫秒级，一张单的完整往返是 0.2 到 0.9 秒级，比特币是分钟到小时级
官方文档给的数字是：地理上和验证者在一起的客户端，端到端中位 0.2 秒，P99 0.9 秒[^hl-overview]。Glassnode 在 2026 年 3 月从 AWS 东京机房发了 120 次真实市价单，中位数是 884 毫秒，其中网络传输只占约 5 毫秒，其余都在服务端[^glassnode-fill]。两者差了几倍，Glassnode 认为是网络规模和订单量比写文档时大了很多；具体时间花在哪一段，外部测不出来。 还有一个容易忽略的因素：**物理距离**。Hyperliquid 的验证者集中在东京[^glassnode-about]，在东京机房里网络只要几毫秒，从欧洲或美国发单，就要再加上一两百毫秒的跨洋往返。这也是“快”的一部分代价：快是对离验证者近的人而言的。 即便如此，和比特币放在一起，差距仍然是几个数量级：一边是不到 1 秒就成交并且不可撤销，一边是平均 10 分钟进第一个块、1 小时才算稳。 **速度的来源都清楚了。最后算一笔账：和比特币相比，Hyperliquid 到底放弃了什么？** ## 六、快的代价 ### 逐项对照 把前面几节的内容放回一张表里：
比特币与 Hyperliquid（HyperCore）
比特币Hyperliquid
相同的骨架
账本模型复制状态机：按同一顺序执行同一串交易，区块用哈希串联
授权secp256k1 私钥签名，自己保管密钥
可验证任何人都能下载全部区块自己重放
状态机专用：只做转账专用：只做交易所（另有 HyperEVM 旁路）
改掉的部分
谁能写块任何人，按算力抽签27 个活跃验证者，按质押轮流
终局概率终局，惯例等 6 块提交即终局
出块间隔（实测）中位 377 s中位 68 ms
吞吐（实测）约 7 笔/秒约 4.4 万笔/秒
块内顺序矿工按手续费率挑协议规定：挂单、撤单先于吃单
手续费每笔交易按字节付只对成交收费
付出的代价
网络出问题时继续出块，事后按最长链合并超过 1/3 质押失联就停下
谁能加入无需许可要质押，活跃集合有名额
节点分布全球集中在东京
节点软件开源，多种实现官方发布的二进制，源码未公开
表 3 · 骨架没变，变的是“谁来排序”和“执行什么”，代价落在开放性和抗审查上
### 权力集中在哪里 去中心化程度最直观的指标，是写块的权力分在多少人手里。图 5 把两边放在一起：上面是 Hyperliquid 27 个活跃验证者的质押，下面是比特币近一周 1,035 个块由哪些矿池挖出。
写块权力的分布 上面是 Hyperliquid 27 个活跃验证者的质押占比，Hyper Foundation 名下 5 个验证者合计 47.1%，越过 1/3 线但没到 2/3 线，其余 22 个合计 52.9%。下面是比特币近一周 1,035 个块的矿池分布：Foundry USA 26.4%，AntPool 20.5%，F2Pool 15.7%，前两家合计未过半，前三家 62.6%，其余 12 个矿池 37.4%。 Hyperliquid · 27 个活跃验证者的质押（2026-10-22） 比特币 · 近一周 1,035 个块由谁挖出 1/3：能让链停下 2/3：能单独出块 Hyper Foundation 1–5：47.1% 其余 22 个：52.9% Foundry 26.4% AntPool 20.5% F2Pool 15.7% 1/2 ViaBTC、SpiderPool、MARA 等 12 个：37.4% 两边都不平均。区别在于集中的一方能做什么：矿池改不了规则，2/3 质押签了什么，链就认什么。
图 5 · Hyperliquid 的基金会一家就越过了 1/3；比特币前三大矿池合计 62.6%
两边都谈不上平均。Hyperliquid 这边，Hyper Foundation 名下的 5 个验证者合计 47.1%，单独就越过了 1/3 的线：它不需要任何人配合就能让链停下，但还到不了 2/3，不能单独出块。按质押从大到小，前 3 个（都是基金会的）就超过 1/3，前 8 个超过 2/3。比特币这边，前三大矿池近一周挖了 62.6% 的块。 但集中带来的权力并不一样。比特币的矿池最多能决定装哪些交易、拒绝哪些交易，或者在掌握过半算力时重写最近几块；它改不了规则，因为每个全节点都会独立检查每一块，违规的块直接被丢掉，而且矿工随时可以换矿池。Hyperliquid 的验证者除了排序，还承担着交易所的运营职能：喂预言机价格、决定上下架。超过 2/3 的质押签了什么，链就执行什么。 2025 年 3 月 26 日的 JELLY 事件就是一个例子。有人在 JELLY 这个小币上开了大额空单，再撤走保证金，让平台的做市金库 HLP 被动接下这个仓位，随后币价被拉高了几倍。验证者在几分钟内投票下架了 JELLY 永续合约，并按 0.0095 美元而不是当时的市场价结算所有仓位[^rekt-jelly]。这次干预让金库免于大额亏损，也让很多人第一次意识到：这条链上的“规则”，在极端情况下是可以由一小群验证者当场改写的。这种事在比特币上不会发生。 另外两处代价前面已经出现过：验证者集中在东京，离得远的人天然慢一截；节点软件只发布二进制，外界没法逐行审计它的执行逻辑。 ## 小结 1. **Hyperliquid 和比特币是同一类东西吗？** 骨架相同：复制状态机、哈希串联的区块、secp256k1 签名、任何人可以重放验证，而且两者的状态机都是专用的。 2. **比特币为什么慢？** 开放网络里只能按算力抽签排序；为了让分叉少，出块间隔必须远大于传播时间，于是是 10 分钟，终局只能靠堆确认数，惯例 1 小时。 3. **Hyperliquid 怎么排序？** 换成一组已知的、按质押投票的验证者，用 HotStuff 系的 BFT 共识：超过 2/3 质押签名即出证书，两个冲突块不可能同时拿到证书，提交即终局；投票流水线化，实测中位 68 毫秒一块。 4. **为什么订单簿能放上链？** 订单簿、保证金、清算直接写成状态机，挂单撤单不跑虚拟机、不收 gas；链上 96% 的流量是做市商的撤单和挂单，块内按协议规则先挂单、再撤单、最后吃单。 5. **70 毫秒出块，下单要多久？** 完整往返在 0.2 到 0.9 秒，并且取决于你离东京的验证者有多远。 6. **代价是什么？** 网络出问题时会停而不是分叉，验证者少且集中，基金会一家超过 1/3 质押，验证者可以干预市场（JELLY 事件）。比特币用慢换来了谁都改不了规则，Hyperliquid 用这一点换来了速度。 ## 参考资料