perpを触っていると、Hyperliquidはまるで中央集権の取引所のようにサクサク動きます。
それでいて「完全オンチェーン」だと聞いて、なぜそんなことが成り立つのか引っかかった方も多いはずです。
その速さの正体としてよく出てくるのが、Hyperliquid L1という専用のブロックチェーンと、HyperBFTという独自の合意形成システムです。
この記事では、Hyperliquid L1・HyperBFTとは何か、CEX並みに速い4つの理由、そのリスクと制約までを、専門用語をかみ砕いて順に整理しています。
Hyperliquid L1は、それ自体が独立して動く一本のブロックチェーンです。
EthereumやSolanaの上に載ったアプリではなく、取引のために土台から自前で用意したチェーンだという点が、すべての出発点になります。
Hyperliquid L1は、買い注文と売り注文を価格ごとに並べる板取引（オーダーブック）を、完全にオンチェーンで、しかも中央集権の取引所に近い速さで動かすために用意された独自チェーンです。
速い板取引をオンチェーンのまま成立させるための専用の土台だと押さえておくと、この先の話がつながりやすくなります。
板取引では、注文と取り消しが秒間に大量に飛び交います。プロのトレーダーやマーケットメイカーは、1秒間に何度も注文を出し直すことも珍しくありません。
この大量の処理を、送金もNFTもゲームもさばく汎用チェーンの上で全部記録しようとすると、すぐに詰まってガス代も跳ね上がります。
Ethereum上のDEXの多くが板取引ではなく数式で価格を決めるAMM方式を採るのも、この制約を避けるための工夫でした。
CEX並みの板取引をオンチェーンで成立させるには、取引に資源を全振りした専用チェーンが必要だったのです。
Hyperliquid L1は、大きく「合意を担う（コンセンサス）レイヤー」と「その上で処理を動かす実行（エグゼキューション）レイヤー」に分かれています。
合意を担うのが、次の章で詳しく見るHyperBFTです。
実行層はさらに二層に分かれ、板取引エンジンであるHyperCoreと、スマートコントラクトを動かすHyperEVMが、同じ土台の上に乗っています。
速さが命の板取引はHyperCoreが、自由なアプリ開発はHyperEVMが受け持つという役割分担です。
この二層がどう連携するのかは、HyperCoreとHyperEVMの違いで掘り下げています。
HyperBFTは、HotStuffという合意方式をもとにしたHyperliquid独自の仕組みです。
たくさんのバリデータが「この取引はもう確定だ」と足並みをそろえるための、土台の仕組みにあたります。
一部のバリデータが故障したり不正をはたらいたりしても全体が止まらない、ビザンチン障害耐性という性質を持つのが特徴です。
コンセンサスレイヤー（合意層）とは、チェーンの中で「どの取引が、どの順番で成立したか」を、ひとつの結論に固める部分です。
中央集権の取引所なら、運営の1台のサーバーが「これが正解」と決めれば済みます。
しかし管理者のいないチェーンでは、分散したたくさんの参加者が合意して順序を決めなければなりません。
この合意づくりを担うのがコンセンサスレイヤーで、HyperliquidではHyperBFTがその役を担います。
合意の投票役を担うのは、HYPEを預け入れたバリデータたちです。
誰でも投票できるわけではなく、一定量のHYPEをステーキングした者だけが参加できます。（最低 10,000 HYPE）
バリデータが投票し合い、3分の2を超える賛成が集まった内容が、覆らない正史として確定していきます。合意を支えているのは、HYPEを預けたバリデータの存在だという点が要になります。
この担い手の構成やステーキングの中身は、Hyperliquidのステーキングとバリデータで扱います。
分散した参加者が合意するうえで、古くから知られる難問が「ビザンチン将軍問題」です。
複数の将軍が連携して城を攻めるとき、一部の将軍が嘘の伝令を流しても、残りが正しく足並みをそろえて勝てるか、というたとえで語られます。
今の文脈で言うと「裏切り者や嘘の情報が混じっても、全体としては正しい結論にたどり着けるか」という、分散合意の核心を突いた問題です。
このビザンチン将軍問題に答えるのが、BFT（ビザンチン障害耐性）です。
BFTを満たす仕組みは、参加者の一部（目安として全体の3分の1未満）が故障したり不正をはたらいたりしても、全体としては正しく動き続けることを保証します。
HyperBFTもこの性質を受け継いでおり、一部のバリデータが落ちても、取引の確定そのものは止まりません。
名前の「BFT」は、このビザンチン障害耐性から来ています。
HyperBFTがCEX並みの速さを実現できる理由を、大きく4つに分けて見ていきます。
いずれも「ブロックの確定を待つ時間」や「合意にかかる手間」を削るための工夫です。
1つ目は、合意のための連絡を、できるかぎり軽くする工夫です。
古い合意方式では、参加者全員がお互いに連絡を取り合う必要があり、人数が増えるほど通信量が爆発的に膨らみました。
HyperBFTが土台にするHotStuffの系譜は、この連絡をリーダー役に集約してすっきりさせます。
担い手が増えても合意のコストが膨らみにくいことが、高速さを支える前提になっています。
2つ目は、ブロックが作られた瞬間に近いタイミングで覆らなくなる、ワンブロックファイナリティです。
多くのチェーンでは、取引が「確定した」と言い切れるまでに、後続のブロックがいくつも積み上がるのを待つ必要があります。
HyperBFTは、合意がブロック1つぶんで確定に達する設計のため、何ブロックも待つ必要がありません。
約定がすぐに覆らない確定へ至るので、取引の体感が中央集権の取引所に近づくのです。
3つ目は、ネットワークが実際に速いときに、その速さをそのまま活かせる設計です。
合意の仕組みの多くは、「通信が大きく遅れるかもしれない」という最悪のケースに備えて、各段階に固定の待ち時間を設けています。
そのため、実際の通信が速くても、決められた時間を待ってからでないと次に進めません。
一方、HyperBFTは、必要な賛成票が実際に届いた瞬間に次へ進みます。
だから、ネットワークの状態が良いときは、その良さがそのまま確定の速さに反映されます。
「最悪に備えて一律に待つ」のではなく「その時々の実際の速さで動く」ため、平常時のスピードが大きく変わってくるのです。
ただしこれらの数値は計測条件や接続環境、設計の更新で大きく変わりうるため、最新の数値の確認が必要です。
4つ目は、複数のブロックを少しずつ重ねて同時に処理する、パイプライン構造です。
1つの取引が完全に確定するのを待ってから次に取りかかるのではなく、ある取引が後半の工程に進んでいる間に、次の取引の前半の工程を始めてしまいます。
工場のベルトコンベアのように、工程をずらして流れを止めずに進めるイメージです。
この流れ作業が、毎秒20万件規模とされる高い処理量を支えています。
取引の速さは本物です。
ただし、それで何もかもが安全になるわけではありません。
専用チェーンならではのリスクと制約も、あわせて理解しておく必要があります。
1つ目は、チェーンとしての歴史の浅さです。
EthereumやBitcoinが10年以上にわたって攻撃や混乱にさらされ、そのたびに生き延びてきたのに対し、Hyperliquid L1は登場からの期間がまだ短いチェーンです。
長期間・大規模な攻撃に耐え抜いた実績の蓄積はこれからで、まだ表面化していない弱点が残っている可能性は否定できません。
2つ目は、合意を担うバリデータの少なさと集中です。
合意に参加するバリデータは2026年時点でおおむね24〜25にとどまり、100万を超えるEthereumや約1,400のSolana（いずれも2026年時点）と比べると、担い手はかなり少数です。
さらに、ノードを動かすソフトウェアが完全なソースコードではなく署名済みのバイナリとして配布されているため、中身を検証しづらいクローズドソースだという指摘もあります。
このリスクが顕在化したのが、2025年3月のJELLY事件です。
JELLYというミームコインで意図的な価格操作が起きた際、バリデータは投票でオラクル価格を上書きし、対象のコインを上場廃止にしました。
緊急時に少数のバリデータの判断で取引が巻き戻された事実は、「人為的な介入の余地がある」という論点を残しました。
運営はバリデータの拡大やソフトウェアの公開意向を示していますが、守られたという評価と中央集権的だという批判の両方が、いまも併存しています。
3つ目は、コンセンサスの外側に残るリスクです。
HyperBFTが担当するのは、「どの取引がどの順番で成立したか」というチェーン内部の整合性までです。
外部から価格を取り込むオラクルが操作されれば、合意自体は正しくても誤った価格で清算が起きえます。
HyperEVM上で動く個々のアプリ（スマートコントラクト）の不具合や、他チェーンと資産をやり取りするブリッジも、コンセンサスとは別の弱点です。
「チェーンが速くて堅牢」であることと、「その上のすべてが安全」であることは別問題だと切り分ける必要があります。
ここまでで、Hyperliquid L1とHyperBFTの全体像を整理してきました。要点を振り返ります。
技術を理解したことは、そのままHYPEを見る目を養うことにつながります。
速くて透明だから信頼するのか、介入の余地があるから距離を置くのか、どちらにせよ根拠を持って判断する材料となるでしょう。
アーキテクチャ全体を理解するために、取引エンジンとEVMという二層の中身をさらに分解したいならHyperCoreとHyperEVMの違いを読んでみてください。
合意を担うバリデータとステーキングの中身を知りたいならHyperliquidのステーキングとバリデータへ進むのがおすすめです。
