マルチチェーンおよびレイヤー2ソリューションは、「高速な順序決定と弱い確定性」と「強い確定性と長い待機時間」というジレンマに常に直面してきました。中央集権型シーケンサーは数秒でソフトな確定を提供しますが、運用者の信用に依存します。一方、L1のファイナリティは堅牢であるものの、確定までに長い待ち時間を要する場合が多いです。HotShotは、確定の責任を分散型のステーキング済みバリデーターセットに移し、数秒以内の合成的なファイナリティを実現します。
HotShotを理解するには、3つのコア原則を把握することが重要です。すなわち、コンセンサスは順序と確定のみを管理すること、実行とデータ可用性(DA)は分離されていること、そして楽観的レスポンシブ性によってレイテンシが低減されることです。また、クロスチェーンや金融ユースケースにおける「秒単位ファイナリティ」の意味も理解する必要があります。
HotShotは、Espresso Network(ESP)のBFTコンセンサスプロトコルであり、HotStuffおよびHotStuff-2から設計を継承しています。リーダーがブロックを提案し、バリデーターが複数ラウンドの投票でクオーラム証明書を形成し、誠実多数の仮定のもとブロック順序に最終合意します。
Espressoのアーキテクチャでは、HotShotが決済と確定を担い、統合環境から提出されたトランザクション出力の統一かつ検証可能な最終記録を生成します。各アプリやチェーンは独自の実行環境・順序戦略・コンプライアンスルールを持ちます。Espressoは全ての状態を1つの共有マシンに統合するのではなく、複数の当事者が共通のファイナリティ基盤を共有します。
| HotShotコンポーネント | Espressoでの役割 |
|---|---|
| BFTコンセンサスコア | ブロック順序の分散型最終確定を提供 |
| バリデーターセット | ESPをステーキングし、投票・ブロック生成を行う |
| クオーラム証明書 | ステーキング済みバリデーターの過半数承認を証明 |
| 実行レイヤー(外部) | 各アプリ/チェーンが独自に状態遷移を管理 |
| DAレイヤー(分離可能) | デフォルトはEspressoDA。他ソリューションも選択可能 |
この表は、HotShotと周辺モジュールの役割分担を示しています。コンセンサスは「順序が確定した」証明を提供し、実行とデータ可用性はモジュール化・合成可能です。セキュリティはステーキング重みに依存し、結果を侵害するには通常ステーキング済みESPの3分の2以上の支配が必要です。ESPステーキングとプロトコル手数料では、バリデーターのステーキング、閾値、ペナルティがこのモデルをどのように支えるかが解説されています。
HotShotの通常運用プロセスは、順序決定モジュールがブロックまたはトランザクションストリームを提出→リーダーがパッケージ化してブロードキャスト→バリデーターが投票し証明書を作成→クオーラム到達でブロック確定、という流れです。固定ブロック間隔型プロトコルとは異なり、HotShotは楽観的レスポンシブ性を重視しています。ネットワーク状態が良好でメッセージ伝播が迅速な場合、最悪ケースを想定した保守的タイムアウトなしで、実際の伝播速度でプロトコルが進行します。
楽観的レスポンシブ性は、好条件下でレイテンシがネットワーク往復数回分まで短縮でき、最大遅延まで意図的に延長されないことを意味します。HotStuff-2ではビュー変更や証明書パスに必要なラウンド数がさらに減り、「3回のネットワーク往復でファイナリティ達成」が現実的になりました。状況が悪化した場合は、プロトコルがタイムアウトベースの経路に切り替わり、安全性と生存性を確保します。
| 属性 | 楽観的レスポンシブ(HotShot) | 非レスポンシブ固定間隔(例) |
|---|---|---|
| 進行速度 | 条件良好時はネットワーク速度で進行 | 固定スロット/ブロック時間 |
| 良好なネットワークレイテンシ | 秒単位以下まで短縮可能 | 固定間隔に制限される |
| 最悪ケース | タイムアウト・ビュー変更に依存 | 常に保守的パラメータで運用 |
| CDN統合 | 証明書・データ配信を加速可能 | 通常は未対応 |
この表は2つの進行方式の違いを示しています。HotShotは「平均的に高速」な設計となっており、CDN等のネットワーク加速器と連携することも多いです。共有シーケンシングレイヤー比較では、「高速な確定」にはバリデーターセットが不可欠である理由が説明されています。
図1. HotShotコンセンサスの流れ:ブロック提案→バリデーター投票→クオーラム証明書→秒単位ファイナリティ。楽観的レスポンシブ性により好条件下でネットワーク速度で進行します。
HotShotは意図的にトランザクションを実行しません。バリデーターはコンセンサス中にスマートコントラクトやアプリケーション状態マシンを再実行しません。確定されるのは「ステーキング済みバリデーターの過半数がシーケンスを承認した」ことであり、「このレイヤーで状態ルートが計算された」ことではありません。実行環境は確定シーケンスを受け取り、各自のルールで状態を導出します。プライバシーアプリケーションは、認可された当事者が鍵を保持した後でのみ復号・実行できます。
この確定と実行の分離には2つの主な効果があります。第一に、Espressoのスループットは単一のグローバル実行者によるボトルネックから解放され、専門化された環境が並列で実行しつつ、HotShotがその出力ストリームを確定します。第二に、クロス環境連携では検証可能なメッセージ(ゼロ知識証明など)に依存できるため、ターゲットチェーンはEspresso上で全てのビジネスロジックを複製せずとも、ソース状態の正当性を検証できます。
データ可用性(DA)もコンセンサスから分離されています。統合者はEspressoDA(検証可能な情報分散、DA委員会、CDN加速を含む)や他のDAソリューションを利用可能です。HotShotは順序決定と証明書に集中し、DAはデータ取得を保証します。秒単位確定フローは、提案・証明書・下流データ取得を完全な確定経路として接続しています。
図2. 確定と実行の分離:HotShotは順序とクオーラム証明書を出力し、EspressoDA(または他DA)がデータ取得を保証、アプリケーションが独自に状態を導出します。
秒単位ファイナリティとは、トランザクションシーケンスが分散型バリデーターセットによって数秒以内に不可逆であると確定されることです。「シーケンサーのソフト確定」とは異なり、HotShotのファイナリティはステーキング済みバリデーターの過半数によって支えられます。また、一部L1のように長いファイナリティを待つ必要がなく、統合者は強い確定のために1エポック全体を待つ必要がありません。メインネットのドキュメントでは通常数秒以内(例:Mainnet 1では3秒未満)と記載されていますが、実際の時間はネットワーク負荷やバージョンにより異なるため、常に公開ネットワーク状況や開示情報を参照してください。
クロスチェーンユースケースでは、統一ファイナリティによって「一方がトランザクションを確定と見なす一方、他方はまだ再編成可能」というウィンドウが短縮され、担保監視、メッセージパッシング、流動性ルーティングの同期が容易になります。ステーブルコイン発行、決済ネットワーク、トークン化資産、証拠金管理では、秒単位確定によりエクスポージャーや照合遅延が短縮され、リアルタイムのリスク管理やクロスシステム担保化が可能となります(実行・コンプライアンス・鍵管理は各アプリの管理下にあることが前提です)。
HotShotの主なメリットは、分散型ファイナリティが単一シーケンサーモデルよりも監査性が高いこと、楽観的レスポンシブ性によりネットワーク状態が良好な場合の確定レイテンシが短縮されること、確定・実行・DAの分離により高スループットとカスタマイズ性が実現できることです。統合者は独自のVM、手数料、コンプライアンス設定を維持しつつ、同じ決済レイヤーを共有できます。
制限も明確です。HotShotはアプリケーション層の正当性を代替しません。不適切なロジック、誤った鍵、誤ったオラクル入力は誤った状態を引き起こします。生存性はネットワークやバリデーター参加に依存し、極端な状況下ではタイムアウト経路にフォールバックする場合があります。セキュリティはステーキング分布やペナルティメカニズムに依存し、バリデーター集中やクライアント多様性も長期的な要因です。DA選択の失敗やデータ取得障害は、コンセンサス証明書が有効でも下流の実行やクロスチェーン検証に影響を与える可能性があります。
リスク面では、プロトコルリスク(コンセンサス仮定の失敗や実装バグ)、統合リスク(順序決定、ブリッジ、証明システム)、運用リスク(鍵、権限、コンプライアンス)を区別してください。上記はメカニズムの強みと限界の概要です。
HotShotはEspresso NetworkのBFTコンセンサスプロトコルとして、バリデーターのステーキングによる検証可能な最終トランザクション順序を提供し、楽観的レスポンシブ性による秒単位ファイナリティを実現します。本プロトコルはトランザクションを実行せず、DAはモジュール化され、実行は各アプリケーションの環境内にとどまります。クロスチェーンや金融シナリオでは、より短く一貫した確定ウィンドウの恩恵を受けますが、アプリケーションの正当性、ステーキング分布、ネットワーク状態、DA選択が依然として重要な制約条件となります。
HotShotはEspresso Networkで採用されているByzantine Fault Tolerant(BFT)コンセンサスプロトコルであり、HotStuffおよびHotStuff-2に基づいています。バリデーターはブロック順序に投票し、クオーラム証明書を形成して、誠実多数の仮定のもとで最終確定を提供します。HotShot自体はトランザクション状態遷移を実行しません。
EspressoはHotShotの楽観的レスポンシブ性と複数ラウンド投票を活用し、好条件下でネットワーク速度でコンセンサスを進行させます。そのため、メインネットの確定は通常数秒以内に行われます。ファイナリティは分散型のステーキング済みバリデーターセットによって支えられており、単一シーケンサーのソフト確定だけではありません。
Espresso Networkは、複数のチェーンやアプリケーションで共有される決済・確定インフラストラクチャです。各環境は独自の実行とルールを維持し、トランザクション出力はHotShotによって分散型ファイナリティを達成します。データ可用性やクロスチェーンメッセージングも統合可能で、信頼できる仲介者への依存を最小限に抑えます。
ESPはEspresso Networkのネイティブユーティリティトークンであり、主にHotShotのセキュリティ確保のためのバリデーターステーキングやプロトコル手数料への参加に使用されます。ステーキング重みによって投票影響度が決まり、確定を侵害するには通常ステーキング済みESPの大部分の支配が必要です。
主なリスクには、アプリケーションロジックや鍵のエラーがコンセンサスによって自動的に修正されないこと、極端なネットワークやバリデーターの挙動で確定が遅延すること、ステーキング集中やクライアント脆弱性がセキュリティに影響すること、DAやブリッジ/証明コンポーネントの欠陥が下流の可用性に影響することが挙げられます。リスク評価では、プロトコルレベルと統合レベルのリスクを区別してください。





