Hyperliquid のアーキテクチャ · Hyperliquid の L1 · 2/8

HyperBFT コンセンサス

売買のためのコンセンサスの難しさ

売買の場では、コンセンサスに求めるものが汎用のチェーンとは違います。必要なのは次の3つです。

• 遅延が小さいこと — 売買する人には1秒未満の確認が要ります。12秒ごとのブロックでは足りません
• 処理量が多いこと — トークンの送金だけでなく、毎秒何千件もの注文の操作をさばく必要があります
• 順番が決定的であること — すべてのバリデーターが、注文と取消を同じ順番で見る必要があります。そうでないと、同じ板の状態になりません

HyperBFT の仕組み

HyperBFT は Hyperliquid 独自のコンセンサスです。BFT プロトコルの HotStuff 系の一種です。主な性質は次のとおりです。

リーダーが進めるラウンド

コンセンサスは ラウンド ごとに進みます。各ラウンドで、リーダーが取引のまとまりを提案し、バリデーターがそれに投票します。クォーラムの署名が集まると、そのラウンドを確定できます。クォーラムとは、全ステークの2/3を超えるバリデーターのことです。誠実なノードはすべて、確定したラウンドの同じ並びに合意します。確定した各ラウンドは実行に回されます。取引を1件以上含むラウンドから、新しいブロックが1つできます。

Leader proposes round → Validators vote
→ Quorum (>2/3 of stake) reached → Round committed → Executed as a block

パイプライン化

HotStuff 系のプロトコルは、投票の段階をパイプライン化します。つまり、次の提案の作業を、前の提案の投票と重ねて進めます。この重ね合わせが、こうしたプロトコルが1秒未満の確認を実現できる大きな理由です。(Hyperliquid は、HyperBFT の内部の段階について詳しい仕様を公開していません。)

板を意識した順番づけ

mempool とコンセンサスの仕組みは、板の取引を区別して扱います。各ブロックの中では、注文以外の操作が先に実行されます。次に取消、最後に GTC や IOC の注文を送る操作です。新しい taker より先に取消を実行するので、maker は古い気配を引っ込める機会を得られます。

バリデーターの顔ぶれ

稼働中のバリデーターは、ステークの多い順の上位です(資料によると上位27)。バリデーターのノードは、許可なく誰でも動かせます。バリデーターには次のことが求められます。

• 自分自身に 10,000 HYPE 以上を委任すること(1年間ロックされます)
• 高性能なハードウェアを動かすこと(遅延の小さいネットワークが特に大事です)
• コンセンサスのメッセージにすばやく応えること — 遅れるバリデーターは、クォーラムの投票で jail(一時停止)されることがあります。直すまで報酬は得られません

jail はスラッシング(没収)とは違います。スラッシングは、二重署名のように悪意がはっきり証明できる行為のためのものです。2026年10月時点で、自動のスラッシングは実装されていないと資料に書かれています(ステークの資料)。

ほかとの比べ方

HyperBFT は、板の処理のために作られました。コンセンサスとネットワークは、突き合わせのエンジンと一緒に作られています。ほかの多くの取引の場は、汎用のコンセンサスを売買向けに手直ししています。あるいは、板をコンセンサスの外に置き、約定だけをチェーンに記録しています。