ミニブロック: Ethereum PBSのためのSSV支援サブスロットオークション

原文

Mini-Blocks: SSV-Backed Sub-Slot Auctions for Ethereum PBS — MatheusFranco99 (2026-05-18)

この作業はGal Rogozinskiとの共同で行われた。

動機

Ethereumのブロック価値は、ブロックの先頭に大きく集中している。最初の数トランザクション（アービトラージの足、清算、オラクルに敏感なトレード）は、スロットで抽出される価値の不均衡なシェアを占め、ブロックの残りの部分は比較的静かで価値の低い領域に落ち着く。これは、スロットの周期そのものに起因する部分がある。ビルダーは12秒ごとに単一の順序付けられたペイロードを構成し、競争力のあるサーチャーは実行リスクが最も低いポジションに努力を集中させる。

ミニブロックは、単一のスロットを部分的なペイロードの順序付きシーケンスに分解することで、この問題に対処する。各ミニブロックは、スロット内の独自のオークションラウンドの結果であり、プロポーザーによって署名され、以前に受け入れられたミニブロックによって蓄積されたステートを拡張する。正規のEthereumブロックは、依然として標準のPBS（プロポーザー・ビルダー分離）パイプラインを通じてスロットの最後に生成される。ミニブロックは、その上に構築されるサブスロットレイヤーであり、単一のオークションではなく、スロットごとに複数のブロック先頭のようなオークションを実行することで、現在最初の数ポジションに閉じ込められている価値をブロックの残りの部分でも実現できるようにする。

経済的ロジックは、ブロックの先頭に価値が集中する理由から導かれる。CEX-DEXアービトラージや関連戦略を実行するサーチャーは、決定からインクルージョンまでの時間とともに増大する実行リスクと、同じ期間で広がるオプショナリティ（選択肢の幅）に直面する。nuconstructの分析[1]が示すように、オークション間の間隔を短縮すると、オプショナリティが縮小するよりも速くサーチャーの実行リスクが減少するため、スロット内で複数の短いラウンドを実行することで、サーチャー（ひいてはブロック構築者とプロポーザー）が各ラウンドに支払う意欲のある期待値が高まる。これは、単に同じトランザクションセットをより多くのスロットに再パッケージ化するだけではない。

いくつかの具体的な利点が続く。プロポーザーは、スロットあたりより多くの価格設定されたオークションを実行するため、スロットあたりより多くの価値を獲得する。ユーザーはラウンドの周期の副次的な効果として、より速い承認を得られる。これは、ブロック構築パイプラインを変更することなく、明示的な事前承認への自然な拡張パスを確立する。ビルダーは、スロットあたり1つではなく、明確に定義された複数のブロック先頭のような機会を得られるため、収益性の高い競争が可能な戦略の種類が多様化する。

この設計は、ビルダーとリレーの参加戦略の柔軟性も向上させる。ビルダーは、小規模または大規模なバンドルであっても、収益性の高いミニブロックを見つけたらいつでも入札できる。バリデータは、収益性の高い入札を選択するための自由市場を持つ。

決定的に重要なのは、これらの利益が新たなインフラを必要としないことだ。主要な設計原則は、既存のPBS（プロポーザー・ビルダー分離）インフラ（リレーとビルダー）を再利用し、個別のブロック構築パスを導入するのではなく、スロットあたり複数のオークションラウンドを実行することにある。PBS（プロポーザー・ビルダー分離）の設計とその信頼仮定を完全に継承することで、既存のインフラが依存する統合されたパイプラインを維持し、リレーとビルダーの運用および信頼プロファイルを実質的に変更しない。

主要な技術的イネーブラーは、SSVの分散型バリデータ技術（DVT）である。DVTクラスターは、独立したオペレーターのしきい値が合意した場合にのみ有効なBLS署名を生成するため、ミニブロックヘッダーに対するクラスターの署名は信頼できるコミットメントとなる。約束を破るには、単一のキーホルダーではなく、複数の独立した当事者のしきい値を不正に操作する必要がある。

このドキュメントでは、以下のトピックを扱う。

SSVオペレーターとリレー間の通信レイヤー。
プロトコルの概要：ラウンド構造、入札選択、およびリレーとビルダーへのステートアドバタイズメント。
ブロックのパッキングとEthereumネットワークへの提出。
ユーザーへのステートアドバタイズメントとそれに基づくトランザクションシミュレーション。
セキュリティ。
結論。

アクター

SSVオペレーター（DVTクラスター）: SSVバリデータを共同で実行するBFT（ビザンチンフォールトトレラント）なオペレーターのセット。このドキュメントの目的上、クラスターはスロット中にミニブロックの入札を選択し、後に最終ブロックに署名するプロポーザー側のエンティティとして扱われる。
リレー: DVTクラスターからミニブロック関連のメッセージを受信し、ビルダーまたはローカルのオーダーフローから候補セグメントを調達し、ダウンストリームのコンシューマーに部分的なステートインターフェースを公開するエンティティ。
ビルダー: ミニブロックウィンドウのために収益性の高いトランザクションシーケンスを提供するために競合するエンティティ。最終ブロックには、異なるビルダーやリレーから調達されたミニブロックが含まれる場合がある。
ユーザー、サーチャー、およびアプリケーション: 進捗中のブロックを観察したり、それに基づいてトランザクションをシミュレートしたり、後続のミニブロックウィンドウをターゲットとする新しいオーダーフローを送信したりする可能性のある、部分的なステートの外部コンシューマー。

1. SSVオペレーターとリレー間の通信レイヤー

クライアント-サーバー型インターフェース

通信モデルは、SSVオペレーターとリレーセット間のクライアント-サーバー型インターフェースに従い、標準PBS（プロポーザー・ビルダー分離）における通常のリレーとプロポーザーの関係を反映している。

登録

このインターフェースの最初のステップは、特定のバリデータがミニブロックプロセスにオプトインしたことを示す長期的なアドバタイズメントである。このアドバタイズメントは、提案義務ごとのイベントではなく、一度限りの登録である。これにより、リレーは、このバリデータからの提案がミニブロックフローに従うことを事前に知り、バリデータがプロポーザーの義務を得たときにミニブロックの入札を提出する準備ができる。

これは、Builder-API[6]のSignedValidatorRegistrationV1コンテナをミニブロックフィールドで拡張することで実現できる。リレーはすでにvalidator_registrationをバリデータからの正規のオプトインシグナルとして消費しており、それはバリデータのBLSキーで明確に定義されたドメイン上で署名されるため、これを拡張することで並行する登録パスを導入することを避ける。具体的には、ビルダー仕様[7]の登録メッセージにminiblocks_enabledフィールドを追加する。

class ValidatorRegistrationV1(Container):
    fee_recipient: ExecutionAddress
    gas_limit: uint64
    timestamp: uint64
    pubkey: BLSPubkey
    miniblocks_enabled: boolean  # new

バリデータは、miniblocks_enabled = trueに設定された標準のSignedValidatorRegistrationV1を提出することでオプトインする。残りの呼び出しは今日とまったく同じように動作する。

スロット通信

登録は長期的なものであるが、スロットごとのセットアップ交換は不要である。リレーは、登録を通じて、このバリデータがミニブロックフローを実行することを知っている。オペレーターがプロポーザーの義務を得ると、そのスロットのために登録されたリレーからの入札を受け入れ始める。これは、バリデータが今日リレーとどのように相互作用するかを反映している。決定の認証は、バリデータのBLSキーを使用する既存の慣例に従う。

リレーはクラスター内のすべてのオペレーターと対称的に通信する。実際には、リレーはすべてのオペレーターにセグメントを提案し、合意が形成された後、少なくとも1つのオペレーターからの有効な証明済み出力を待つことを意味する。

2. プロトコル概要

スロットは、ミニブロックウィンドウ（またはラウンド）の順序付きシーケンスに分解され、その後に最終ブロックが組み立てられ提出されるフルブロックフェーズが続く。メッセージとプロトコルステップを説明する前に、いくつのラウンドが可能で、それぞれがどのくらいの期間続くかを制限するタイミング制約を確立する。

2.1 タイミング

ミニブロックプロトコルに利用可能な合計時間は、2つの境界条件から導かれる。

開始: プロトコルは、提案スロット開始の-8秒前に始まる。SSVオペレーターは、次のスロットのRANDAOバリデータ署名を構築するために前のウィンドウ（-12から-8）を使用するため、-8までには事前合意フェーズが完了し、ミニブロックオークションを開始できる。
終了: ミニブロックオークションはT=0（提案スロットの開始）で終了する。この時点からプロトコルはフルブロックフェーズに移行する。リレーは直ちにFinalBlockBidを転送し、クラスターは最良の入札を選択して署名する。これは、例えば、入札価値を最大化するためにスロット開始後1.5秒まで待つなど、バリデータが今日の標準PBS（プロポーザー・ビルダー分離）でタイミングゲームをプレイするのとまったく同じである。

これにより、ミニブロックオークションに8秒が与えられ、その後T=0でフルブロックフェーズが始まり、標準PBS（プロポーザー・ビルダー分離）と同じタイミングダイナミクスに従う。デフォルトのM = 4ミニブロックの場合、各オークションウィンドウは8 / 4 = 2秒続く。

マルチラウンドMEV（最大抽出可能価値）-Boostの論文[2]では、各PBS（プロポーザー・ビルダー分離）ラウンドが約4秒かかるとモデル化されており、その内訳はブロック構築者の構築と入札選択に約2秒、他のビルダーへのステート伝播に2秒となっている。我々の設計は、伝播がラウンドから分離されているため、これを改善する。MiniBlockHeaderはすでにstate_diffを保持しており、トランザクションリストの伝播がまだ進行中でも、ビルダーは次の入札の構築を開始できる。これは、伝播が構築後に順次実行されるのではなく、構築と並行して実行されることを意味する。したがって、構築には同じ2秒を維持するが、伝播には追加の時間を費やさないため、実質的なラウンドコストが半分になり、2秒のウィンドウが可能になる。

追加の要因として、DVT合意形成のレイテンシがある。各ウィンドウ内で、クラスターは、構築予算の一部を消費して、SignedBlindedMiniBlockを返す前に、勝者の入札についてしきい値合意に達する必要がある。したがって、ビルダーの構築に利用可能な時間は、ウィンドウの最初のwindow_duration − consensus_latency秒となる。例えば、consensus_latencyが0.5秒の場合、オペレーターはウィンドウが終了するまで約0.5秒の時点で最良の入札を選択することが期待され、リレーはそれに合わせて最適化できる。具体的には、バリデータは登録時に予想される合意形成レイテンシを任意でアドバタイズでき、リレーはそれに応じて入札提出期限を調整できる。さらに、これがウィンドウの相当な部分を占める可能性があるが、将来的には、DVTクラスターはこの特定の問題に最適化された、より良いタイミング保証を持つ合意形成アルゴリズムを選択できるようになるだろう。

ハイパーパラメータ

パラメータ	デフォルト	説明
STARTING_TIME	-8s	提案スロットに対するミニブロックオークションの開始時間
NUM_MINIBLOCKS	4	ミニブロックウィンドウの数。それぞれ8秒 / NUM_MINIBLOCKS続く

2秒の分割は、最初のプロトコルフェーズのベースラインである。将来の改良では、リレーが自然に生成する可能性のある連続的な入札ストリームをよりよく追跡するために、厳格なラウンド周期を緩和できる可能性がある。その件に関する将来の作業については、連続リレー入札の付録を参照のこと。

2.2 メッセージ

// Relay -> DVT Cluster: bid for a mini-block window
message BlindedMiniBlock {
    uint64 slot                   = 1;
    uint64 mini_block_index       = 2;
    bytes  parent_mini_block_root = 3; // hash(SignedBlindedMiniBlock[i-1]), or parent block root for i=0
    uint64 bid_value              = 4; // payment to the proposer
    bytes  tx_root                = 5; // BinaryMerkleRoot([keccak256(t_1),...,keccak256(t_k)])
    bytes  state_root             = 6; // post-execution EVM state root
    bytes  state_diff             = 7; // account/storage delta produced by this tx sequence
    uint64 gas_used               = 8; // total gas consumed by this tx sequence; cumulative gas across all accepted mini-blocks must not exceed MAX_BLOCK_GAS
    uint64 tx_count               = 9; // number of transactions k_i; must equal len(T_i) and is consistent with tx_root
    bytes  builder_signature      = 10; // builder's BLS signature over this bid
}

// DVT Cluster -> Relay: signed acceptance of a winning bid
message SignedBlindedMiniBlock {
    BlindedMiniBlock bid               = 1;
    bytes        cluster_signature = 2; // threshold BLS signature from the DVT cluster
}

// Relay -> Builders/Users: broadcast after each round
message MiniBlockHeader {
    uint64 slot             = 1;
    uint64 mini_block_index = 2;
    bytes  mini_block_root  = 3; // hash(SignedBlindedMiniBlock[i])
    bytes  state_root       = 4;
    bytes  state_diff       = 5;
    uint64 gas_used         = 6; // gas consumed by this accepted mini-block
}

// Builder -> Relay: bid for the final full-block auction.
// The relay verifies the mini-blocks consistency by their placements and the full execution_payload list.
// The relay does not forward execution_payload or mini-block placements to the cluster.
message FinalBlockBid {
    uint64 slot                          = 1;
    uint64 bid_value                     = 2;
    bytes  execution_payload             = 3; // full ExecutionPayload; relay later creates blinded header for cluster
    repeated MiniBlockPlacement placements = 4; // one per accepted mini-block, in chain order
    bytes  builder_signature             = 5; // builder's signature over fields 1–4
}

// Declares where mini-block i's transactions are placed in the final block.
// The relay verifies this against execution_payload and the stored SignedBlindedMiniBlock headers.
// Not forwarded to the cluster.
message MiniBlockPlacement {
    bytes  mini_block_root = 1; // hash(SignedBlindedMiniBlock[i]) — links placement to the signed header
    uint64 start_index     = 2; // s_i: declared starting position; relay cross-checks against stored k_j values
}

BlindedMiniBlockは、リレーからクラスターに転送されるブラインド化された入札である。PBS（プロポーザー・ビルダー分離）の慣例に従い、ビルダーはこのメッセージとともに完全なトランザクションリストをリレーに送信する。リレーはそれをプライベートに保持し、クラスターはこの段階ではブラインド化されたヘッダーのみを見る。これは今日のPBS（プロポーザー・ビルダー分離）の動作を反映している。
BlindedMiniBlock.tx_root = BinaryMerkleRoot([keccak256(t_1), ..., keccak256(t_k)])は、順序付けられたトランザクションシーケンスへのコミットメントである。トランザクションリストを持つ誰もがこのルートに対してそれを検証できる。リレーはこれを使用してルールB1（セクション5）を強制する。
BlindedMiniBlock.gas_usedはラウンドごとのガスを保持しない。リレーは、スロット内で受け入れられたミニブロック全体の累積gas_usedを追跡し、実行中の合計がEthereumのMAX_BLOCK_GASを超える入札を拒否する。ファイナリゼーション時には、残りの余裕がT_extraに利用可能となる。
BlindedMiniBlock.tx_countは、このミニブロックのシーケンスにおけるトランザクション数k_iである。以前に受け入れられたミニブロックのtx_count値とともに、基礎となるトランザクションリストを必要とせずに、任意の当事者が開始オフセットs_i = sum_{j < i} k_jを導出できるようにする。これにより、s_iは署名されたヘッダーのみから再構築可能となり、ルールB2（セクション5）におけるオンチェーン証拠に必要となる。
BlindedMiniBlock.builder_signatureは、メッセージ内の他のすべてのフィールドの署名ルートに対するビルダーのBLS署名である。リレーは入札検証の一部としてこれを検証する。事後的に、任意のウォッチャーは、公開されたSignedBlindedMiniBlockに埋め込まれたbuilder_signatureが入札自身のフィールドに対して検証されるかどうかを確認できる。無効な署名は、リレーがクラスターに転送する前に入札を改ざんした証拠となる。
MiniBlockHeaderは、各ラウンド後にリレーがブロードキャストするもので、ステート差分（state_diff）を保持するため、ビルダーは次のウィンドウの入札を直ちに構築開始できる。
FinalBlockBidは、標準PBS（プロポーザー・ビルダー分離）のフルブロック入札を拡張し、各ミニブロックのトランザクションが最終ブロックのどこに配置されるかを宣言するMiniBlockPlacementエントリを含む。リレーは、ExecutionPayloadと保存されたヘッダーに対してこれらの配置を検証する（セクション3.3を参照）。これらはクラスターには転送されない。
FinalBlockBid.builder_signatureは、フィールド1〜4に対するビルダーのBLS署名であり、ビルダーを特定のペイロードと配置セットにコミットさせる。コミットされたtx_root_i値と配置が矛盾するFinalBlockBidは、ルールB2（セクション5）の下でのビルダーの不正行為の証拠となる。

2.3 プロトコル

ミニブロックオークションラウンド

以下のステップが各ミニブロックウィンドウiに対して繰り返される。

ビルダーは、以前に受け入れられたすべてのミニブロックによって生成された実行ステート（i > 0の場合）に対して、候補となる部分ペイロードを構築する。各ビルダーは、完全なトランザクションリストを1つ以上のリレーに送信し、tx_rootとstate_rootを介してそのリストにコミットするBlindedMiniBlockも送信する。トランザクションはリレーによってプライベートに保持される。クラスターはこの段階ではそれらを見ることはない。これは今日のPBS（プロポーザー・ビルダー分離）の動作を反映している。
リレーは、受信した入札を検証する。提出されたトランザクションに対してtx_rootとstate_rootを検証し、parent_mini_block_rootが最後に受け入れられたミニブロックと一致することを確認し、gas_usedが公開されたトランザクションの実行コストと一致しない入札や、gas_usedがスロットの累積受け入れガスをMAX_BLOCK_GAS以上に押し上げる入札を拒否する。そして、最も価値の高い有効なブラインド化されたBlindedMiniBlockをすべてのDVTクラスターオペレーターに転送する。
DVTクラスターオペレーターは、受信した入札について合意形成を実行する。入札選択ルールはPBS（プロポーザー・ビルダー分離）を反映している。既知のプレフィックスに対する有効性を条件として、最も価値の高いものが勝利する。しきい値合意に達すると、クラスターはSignedBlindedMiniBlockをリレーに返す。
リレーは、MiniBlockHeader（state_diffとstate_rootを含む）をすべてのビルダーにブロードキャストする。この時点から、ビルダーはウィンドウi+1の入札の構築を開始できる。並行して、勝者のリレーは、そのラウンドの完全なトランザクションリストをkeccak256(T_i || mini_block_root)で署名してブロードキャストする。これにより、受信者は、公開が署名済みヘッダー内のコミットされたtx_root_iに対して認証されることを検証できる。
ステップ1からウィンドウi+1に対して繰り返す。

フルブロックフェーズ

すべてのMミニブロックウィンドウがT=0で完了すると、プロトコルはフルブロックフェーズに移行する。これは標準PBS（プロポーザー・ビルダー分離）の提案と同一である。リレーは直ちにFinalBlockBidの転送を開始し、クラスターは最良の入札を選択して署名する。タイミングゲームの動作は完全に維持され、今日のバリデータと同様にクラスターの裁量に委ねられる。

ビルダーは、受け入れられたすべてのミニブロックからのトランザクションシーケンスを順序通りにプレフィックスとして配置し、オプションで残りのブロック容量を埋める追加のトランザクションを続けて、完全なExecutionPayloadを組み立てる。参加するには、ミニブロックラウンドからのすべてのトランザクションリストの開示を受信し、検証している必要がある。ビルダーは、完全なペイロードと、受け入れられたミニブロックごとに1つのMiniBlockPlacementを提出する。それぞれが最終トランザクションリストにおけるミニブロックの開始インデックスs_iを宣言する（セクション3.3を参照）。
リレーは、配置を検証する。コミットされた各tx_root_iがB内の宣言された位置範囲のトランザクションと一致することを確認し、すべてのチェックがパスした場合にのみ、ブラインド化されたExecutionPayloadHeaderをクラスターに転送する。配置は転送されない。
DVTクラスターは、ブラインド化されたヘッダーを受信する。標準PBS（プロポーザー・ビルダー分離）を反映して、クラスターは配置を独立して検証しない。標準PBS（プロポーザー・ビルダー分離）のプロポーザーがリレーを信頼するのと同じように、クラスターはリレーがこのチェックを実行したと信頼する。クラスターはBlindedBeaconBlockに署名する。
リレーは、署名されたBeaconBlockを組み立て、Ethereumネットワークに伝播する。

2.4 シーケンス図

sequenceDiagram
    autonumber
    participant B as ビルダー
    participant R as リレー
    participant C as DVTクラスター

    note over B,C: ミニブロックウィンドウ i (M回繰り返される)

    B->>R: トランザクション + BlindedMiniBlock (tx_root, state_root, bid_value)
    R->>C: BlindedMiniBlock (ブラインド化済み — 最良の入札)
    C->>C: 入札に関する合意形成
    C->>R: SignedBlindedMiniBlock
    R->>B: MiniBlockHeader (state_diff, state_root) + トランザクションリストの開示
    note over B: 並行してウィンドウ i+1 の構築を開始

    note over B,C: ファイナリゼーションウィンドウ

    B->>R: FinalBlockBid (ExecutionPayload + MiniBlockPlacements)
    R->>R: tx_rootsとBに対して配置を検証
    R->>C: BlindedBeaconBlockヘッダー (配置は検証済み、転送されない)
    C->>R: 署名済みBlindedBeaconBlock

3. ブロックのパッキングとEthereumネットワークへの提出

ミニブロックオークションはコミット＆リビールパターンに従う。各ラウンド中、勝者の入札はtx_rootを介してトランザクションシーケンスにコミットする。tx_rootはBinaryMerkleRoot([keccak256(t_1), ..., keccak256(t_k)])と定義され、[t_1, ..., t_k]は順序付けられたトランザクションリストであり、トランザクション自体は開示されない。これにより、ラウンド中のオーダーフローはプライベートに保たれる。クラスター、他のリレー、他のビルダーは、state_diffを介してミニブロックがステートに与える影響を見るが、それを生成した正確な内容は見ない。ビルダーは、コミットされたトランザクションリストに暗号学的に固定される。

3.1 コミットメントチェーン

各SignedBlindedMiniBlockヘッダーには、そのラウンドのトランザクションにコミットするtx_rootと、前の署名済みヘッダーにリンクするparent_mini_block_rootが含まれる。M個のミニブロックが受け入れられたスロット全体で、これはハッシュチェーンを形成する。

genesis (スロット親ブロックルート)
  └─ SignedBlindedMiniBlock[0]: tx_root_0, parent = genesis
       └─ SignedBlindedMiniBlock[1]: tx_root_1, parent = hash(SignedBlindedMiniBlock[0])
            └─ ...
                 └─ SignedBlindedMiniBlock[M-1]: tx_root_{M-1}, parent = hash(SignedBlindedMiniBlock[M-2])

各ヘッダーに対するクラスターのしきい値署名は、そのラウンドのトランザクションシーケンスと、以前のミニブロックの全履歴の両方に対する拘束力のあるコミットメントである。チェーンを破る行為（例：トランザクションの挿入、並べ替え、省略）は、署名済みヘッダーを持つ誰でも検出可能である。

3.2 トランザクションの開示

クラスターがSignedBlindedMiniBlockに署名することで勝者の入札にコミットすると、勝者のリレーは直ちにそのラウンドのトランザクションリストをブロードキャストする。これは、ビルダーの元の提出物からすでに保持しているものである。この時点でリレーは異なるトランザクションセットを置き換えることはできない。なぜなら、署名済みヘッダー内のtx_rootがコミットされたリストを暗号学的に固定しているため、いかなる逸脱もルールB1（セクション5）の下で検出可能であり、スラッシュ可能である。

3.3 フルブロックの構築と整合性チェック

T_i = [t_{i,1}, ..., t_{i,k_i}]をSignedBlindedMiniBlock[i]にコミットされたトランザクションシーケンスとし、k_i個のトランザクションを持つとする。s_i = sum_{j < i} k_jを最終ブロックにおけるミニブロックiの開始インデックスと定義する（したがってs_1 = 0）。最終ブロックの順序付けられたトランザクションリストは次のようになる。

B = T_1 || T_2 || ... || T_M || T_extra

R = transactions_rootは、Bに対するEthereum MPTルートである。キーはRLP(j)、値はRLP(b_j)であり、0 <= j < nである。

ビルダーが計算し、リレーに送信するもの。

ファイナリゼーションビルダーは、開示されたすべてのT_iと自身のT_extraを保持し、以下の処理を行う。

B = T_1 || ... || T_M || T_extraを組み立て、R = MPT_root(B)を計算する。
完全なExecutionPayload（Rと完全なトランザクションリストBを含む）と、受け入れられたミニブロックごとに1つのMiniBlockPlacement（それぞれmini_block_rootとstart_index = s_iを宣言）をリレーに提出する。

リレーが検証するもの。

リレーは、受け入れられたSignedBlindedMiniBlock[i]ヘッダーと、ExecutionPayloadからの完全なトランザクションリストBを保持する。各ヘッダーは、署名済みフィールドとしてbid.tx_count = k_iを保持するため、k_iはヘッダーのみから導出可能なコミットされた値である。リレーは、これらの署名済みk_j値からs_i = sum_{j < i} k_jを独立して計算する。クラスターに転送する前に、リレーは以下のチェックを実行する。

Bを以前のステートに対して実行し、ExecutionPayload内のstate_rootを検証する。Bによって使用される総ガスがMAX_BLOCK_GASを超えないことを検証する。
各ミニブロックiについて：mini_block_root == hash(SignedBlindedMiniBlock[i])を検証する。これは、配置が正しい署名済みヘッダーを参照していることを確認する。
各ミニブロックiについて：BinaryMerkleRoot([keccak256(B[s_i + j]) for j in 0..k_i]) == tx_root_iを検証する。これは、B内の位置s_iにあるトランザクションが、クラスターが署名したコミットメントと正確に一致することを確認する。

チェック3は、エンドツーエンドの整合性を確立するのに十分である。これは、トランザクションの内容とそのB内の位置を同時に検証する。すべてのチェックがパスした場合にのみ、リレーは続行する。その後、リレーはブラインド化されたExecutionPayloadHeader（Rを含む）のみをクラスターに転送する。ミニブロックの配置やトランザクションリストは転送されない。

クラスターが受信し、署名するもの。

クラスターは、リレーからExecutionPayloadHeaderを受信する。クラスターは配置を独立して検証しない。標準PBS（プロポーザー・ビルダー分離）を反映して、クラスターは、リレーがブラインド化されたヘッダーを転送する前にこれらのチェックを完了したと信頼する。これは、バリデータがトランザクションの内容を見ることなくブラインド化されたブロックに署名する今日の標準PBS（プロポーザー・ビルダー分離）を支配するのと同じ信頼関係である。クラスターはBlindedBeaconBlockに署名する。

ここで確立される整合性プロパティは、最終ブロックのトランザクションリストは、受け入れられたすべてのミニブロックヘッダーにコミットされた正確なトランザクションシーケンスを順序付けられたプレフィックスとして含まなければならないということである。形式的には、すべてのiと0 <= j < k_iに対してb_{s_i + j} = t_{i,j}である。クラスターは、tx_root_1, ..., tx_root_M（SignedBlindedMiniBlockチェーンから）とR（BlindedBeaconBlockから）の両方に対する署名済みコミットメントを保持する。この整合性保証に対するリレーの責任は、セクション5で議論される。

3.4 不達

標準PBS（プロポーザー・ビルダー分離）と同様に、ミニブロックウィンドウで勝利したリレーがそのトランザクションリストT_iの開示に失敗する可能性がある。開示が遅れてもファイナリゼーションが始まる前であれば、まだ使用可能であり、プロトコルは遅延を吸収し、害はない。ファイナリゼーションが始まる時点で開示がまだ行われていない場合、スロットは失われる。このようなタイミングイベントに対するスラッシングはないことに注意されたい。強制は、今日の既存のリレーを支配するのと同じ評判モデルに従い、一貫した不達はオーダーフローの喪失につながる。

両方のバリアントは、セクション5のケースIIIで詳細に議論されている。

4. ユーザーとサーチャーへのステートアドバタイズメント

ユーザーとサーチャーは、進行中のブロックの現在の部分的なステートを照会し、スロットのファイナリゼーション前にそれに基づいてトランザクションをシミュレートできるべきである。ミニブロックプロトコルに参加するリレーは、この目的のために2つの補完的なインターフェースを公開する。

リレー支援シミュレーション。 EthGasのリアルタイムAPIに従い、リレーは使い慣れたRPCメソッドを拡張して、スロット内の部分的な実行ビューを提供する。これは、ローカル実行を必要としないほとんどのユーザーにとってアクセスしやすいパスである。

ステート差分クエリ。 補完的なインターフェースとして、リレーは現在のスロットで受け入れられたすべてのミニブロックの累積state_diffをクエリ可能なエンドポイントとして公開できる。ローカルでシミュレートすることを好むサーチャーやユーザーは、累積state_diffを自身のステートに適用し、独立してシミュレーションを実行できる。

5. セキュリティ

ミニブロックレイヤーは、PBS（プロポーザー・ビルダー分離）設計とその信頼仮定に基づいて構築されており、新しい信頼できる当事者を導入したり、Ethereumコンセンサスへの変更を必要としない。リレーはビルダーとプロポーザー側のクラスター間のブローカーであり続け、バリデータはEthereumネットワークに到達するすべてのものに対して責任を負う署名者であり、ビルダーとリレーは、スロット全体でラウンドごとに拡張された、今日のPBS（プロポーザー・ビルダー分離）で見られるのと同じ全体的な信頼プロファイルを見る。

しかし、サブスロットのコミット＆リビール構造は、標準PBS（プロポーザー・ビルダー分離）ではカバーされない不正行為のベクトルと障害モードを生み出す。以下の表にそれらを列挙する。それぞれについて、このセクションの残りの部分で議論する。

#	不正なシナリオ
I	ミニブロックウィンドウで有効な入札を提出するビルダーがいない。
II	クラスターがウィンドウ内でSignedBlindedMiniBlock[i]を生成できない（合意形成レイテンシが超過するか、オペレーターがパーティションされる）。
III	勝者のリレーがコミットされたトランザクションリストの開示に失敗するか、遅れて開示する。
IV	クラスターが(slot, mini_block_index)で二重署名する — 同じウィンドウに対して2つの異なる入札に署名する。
V	クラスターがSignedBlindedMiniBlock[i]に、SignedBlindedMiniBlock[i-1]にリンクしないparent_mini_block_rootで署名する。
VI	ビルダーが、マークルルートがコミットされたtx_rootと一致しないトランザクションリストを開示する。
VII	ビルダーのコミットされたstate_rootまたはgas_usedが、開示されたトランザクションを以前のステートに対して実行した結果と一致しない。
VIII	ファイナリゼーション時にFinalBlockBidを生成するビルダーがいない。
IX	勝者のファイナリゼーションリレーが沈黙する（標準PBSのミススロットと同じ障害モード）。
X	ビルダーが、配置がコミットされたtx_root_i値と一致しない、または総ガスがMAX_BLOCK_GASを超えるFinalBlockBidを提出する。
XI	クラスターが、スロットの累積受け入れガスをMAX_BLOCK_GAS以上に押し上げるSignedBlindedMiniBlockに署名する。
XII	勝者のファイナリゼーションリレーが、勝者のファイナリゼーションビルダーによって署名されたFinalBlockBidと一致しない実行ペイロードを持つブロックをEthereumに公開する。

このセクションの残りの部分では、各ケースと、該当する場合、それを強制するスラッシングルールについて議論する。スラッシングルールは、それらが対象とするアクターによってグループ化される。C1、C2、C3はDVTクラスターに関するものであり、B1とB2はビルダーに関するものである（参加の前提条件として担保を預託していると仮定する）。B1はミニブロックラウンドフェーズをカバーし、B2はファイナリゼーションフェーズをカバーする。ファイナリゼーションステップにおけるリレーの障害は、今日の標準PBS（プロポーザー・ビルダー分離）を支配するのと同じ評判による強制モデルに従い、オンチェーンでスラッシュ可能ではない。

I — 有効な入札がない

ウィンドウiの期限までに有効なBlindedMiniBlockがどのリレーからも届かない場合、クラスターは正規の空の入札について合意に達し、それに対して通常のSignedBlindedMiniBlock[i]を生成する。空の入札は次のように定義される。

tx_root = BinaryMerkleRoot([]) = 0x0...0
state_diff = ∅
state_root = SignedBlindedMiniBlock[i-1]のstate_root（つまり、事前ステートは変更されない）
bid_value = 0
parent_mini_block_root = hash(SignedBlindedMiniBlock[i-1])（またはi = 0の場合はスロット親ブロックルート）
builder_signature = 0x0...0

クラスターは、非空の入札とまったく同じように、そのしきい値BLS署名でこのヘッダーに署名し、リレーにブロードキャストする。リレーは対応するMiniBlockHeader（空のstate_diffを含む）をブロードキャストし、ビルダーはウィンドウがクリーンに終了したことを知り、待つことなくウィンドウi+1の入札の構築を開始できる。

II — クラスターがウィンドウ内でSignedBlindedMiniBlock[i]を生成できない

クラスターがウィンドウiの期限内に入札についてしきい値合意に達しない場合、プロトコルのルールはシンプルである。リレーとビルダーは、クラスターが決定を出力するまで待つ。クラスターは合意形成を継続し、有効なSignedBlindedMiniBlock[i]を生成すると、リレーは対応するMiniBlockHeaderをブロードキャストし、プロトコルはそこから再開する。

これは今日の標準PBS（プロポーザー・ビルダー分離）の動作を反映している。通常のEthereumでは、DVTクラスターが時間内にブロックの合意形成を完了できない場合、バリデータはスロットを逃す。決定を強制する魔法のフォールバックはない。ミニブロックレイヤーは、サブスロットの粒度でまったく同じ仮定を継承する。クラスターの決定が遅すぎる場合、ミニブロックは遅延し、決して決定されない場合、何も署名されない。

唯一目に見える効果は、後続のウィンドウの実行時間が短くなることである。SignedBlindedMiniBlock[i]がそのウィンドウの期限からδ秒後に署名された場合、ウィンドウi+1の予算はwindow_durationからwindow_duration − δに縮小する。しかし、後のウィンドウは完全な予算を回復する。遅延は一度吸収され、伝播しない。例えば、window_duration = 2sでミニブロックiの署名が500ms遅れた場合、ウィンドウi+1は実質的に1.5秒となり、ウィンドウi+2は2秒に戻る。

クロスラウンドケース: δ > window_duration。 クラスターがミニブロックiで非常に遅れ、その遅延がウィンドウi+1のウォールクロックスロット全体を消費する場合、ウィンドウi+1は通常のオークションとして実行する時間がない。その場合、クラスターがiからブロック解除されるとすぐに、期限切れのウィンドウを検出し、直ちに空の入札（ケースIで定義）でi+1の合意形成を開始し、逃したウィンドウに追いつき、次のウィンドウから通常のオークションを再開する。チェーンはその後、SignedBlindedMiniBlock[i]（非空、遅延）に続いて1つ以上の空のSignedBlindedMiniBlock[i+1], ...を示し、パイプラインが現在のウォールクロック位置に追いつくまで続く。

ビルダー側の最適化。 プロトコル自体は投機的な動作を必要としないが、ビルダーは候補となるBlindedMiniBlock[i]を提出するとすぐに、MiniBlockHeader[i]を待つことなく、ウィンドウi+1のバンドルの収集を楽観的に開始できる。SignedBlindedMiniBlock[i]が実際に到着すると調整する。勝者の入札が彼らが構築していたものと一致する場合、彼らの作業は引き継がれる。異なる場合、発表されたstate_diffに基づいて調整する。これはプロトコルに影響を与えないローカルなビルダーの選択であり、クラスターがわずかに遅い場合にクリティカルパスから遅延の一部を隠すだけである。

III — 勝者のリレーがコミットされたトランザクションリストの開示に失敗するか、遅れて開示する

クラスターはSignedBlindedMiniBlock[i]に署名した（tx_root_i、state_root_i、state_diff_iにコミット）。勝者のリレーは、ファイナリゼーションビルダーが完全なブロックを組み立てられるように、基礎となるトランザクションリストT_iをブロードキャストすることが期待される。

バリアントIII-a — 開示が遅れてもファイナリゼーション前である場合。

T_iがウィンドウiの期限後にブロードキャストされたが、フルブロックフェーズが始まる前であれば、まだ使用可能である。後続のウィンドウはケースIIと同じ方法で遅延を吸収するが、ビルダーは次のミニブロックの作業を楽観的に開始できる。プロトコルアクションは不要である。T_iは通常通り組み込まれ、最終ブロックは完全なMミニブロックプレフィックスで組み立てられる。

ここで生じる疑問は、ウィンドウi+1のビルダーがT_iに含まれていたトランザクションを誤って重複させる可能性があるかどうかである。そこでステート差分が役立つ。彼らは重複させることはできない。ビルダーは、MiniBlockHeader[i].state_diffで発表されたポストT_iステートに対してウィンドウi+1のペイロードを構築し、state_diffはすでにT_iに現れたすべての送信者のnonceをインクリメントしている。T_iからのトランザクション、またはすでに消費された(sender, nonce)ペアのいずれかを使用する他のトランザクションを再インクルードしようとする試みは、リレーでのEVM検証によって拒否される（§3.3、ステップ1）。

バリアントIII-b — 開示が全く行われないか、ファイナリゼーション開始後に行われる場合。

ファイナリゼーションを開始しなければならない時点でT_iが利用できない場合、スロットは失われる。これはPBS（プロポーザー・ビルダー分離）に並行する障害である。今日の標準PBS（プロポーザー・ビルダー分離）では、バリデータがBlindedBeaconBlockに署名した後、勝者のリレーが沈黙した場合、バリデータはそのスロットのブロックを生成せず、プロトコル上の救済策はない。ミニブロックは、サブスロットの粒度でこの動作を継承する。いずれかの勝者のリレーが時間内に開示に失敗した場合、同じ方法で、同じ理由でスロットは失われる。

今日のPBS（プロポーザー・ビルダー分離）におけるミススロットと同様に、強制は評判によるものである。一貫して開示に失敗するリレーはオーダーフローを失う。スラッシングルールは導入されない。二重署名がない限り、純粋なデータ秘匿はオンチェーンで証明するのが難しく、今日の既存のリレーを支配するのと同じ二者間/評判モデルによって管理される。

このルールに対する価値を維持する代替案として、部分的なアセンブリがある。これは、開示されたプレフィックスのみを使用してスロットがブロックを生成するというもので、付録で検討されたが、プロトコルをシンプルに保ち、PBS（プロポーザー・ビルダー分離）と整合する障害モデルにするため、主要プロトコルには採用されなかった設計である。

IV — クラスターが(slot, mini_block_index)で二重署名する

スラッシングルールC1（下記）によって強制される。

V — クラスターがSignedBlindedMiniBlock[i]に、SignedBlindedMiniBlock[i-1]にリンクしないparent_mini_block_rootで署名する

スラッシングルールC2（下記）によって強制される。

VI — ビルダーが、マークルルートがコミットされたtx_rootと一致しないトランザクションリストを開示する

スラッシングルールB1（下記）によって強制される。

VII — ビルダーのコミットされたstate_rootまたはgas_usedが、開示されたトランザクションの実行結果と一致しない

オンチェーンでスラッシュ可能ではない。リレーは、トランザクションリストを実行し、state_rootとgas_usedの両方を検証してから、入札をクラスターに転送する（§2.3ステップ2）。したがって、不一致のstate_rootまたはガス値を持つ入札は、その時点で拒否され、SignedBlindedMiniBlockになることはない。そのような入札がクラスターに到達した場合、責任はリレーにある。下記のリレーの整合性責任を参照のこと。

VIII — ファイナリゼーション時にFinalBlockBidを生成するビルダーがいない

ファイナリゼーション期限までにどのビルダーもFinalBlockBidを提出しない場合、クラスターはBlindedBeaconBlockとして署名するものがなく、スロットは失われる。これはPBS（プロポーザー・ビルダー分離）に並行する障害である。標準PBS（プロポーザー・ビルダー分離）では、どのビルダーも時間内にブロックを配信しない場合、バリデータはスロットを逃すか、ローカル実行にフォールバックする。後者がここでは範囲外であるため、ミニブロックは前者を継承する。

実際には、このシナリオは限定的である。フルブロックフェーズまでに、すべてのT_iの開示は到着しているか（ケースIII-bは発生しない）、または到着していない場合、スロットはすでにIII-bの下で失われている。したがって、VIIIは、すべての開示が成功したが、どのビルダーもアセンブリを提出しない場合にのみ意味のある形でトリガーされる。その状況にあるビルダーは、Bを組み立てるために必要なすべてを持っており、提出する経済的インセンティブが自然にある（ゼロ入札のアセンブリでさえT_extraとプロポーザーチップを実現する）。これが、この状況が実際には稀である理由である。

IX — 署名済みBlindedBeaconBlockを受信した後、勝者のファイナリゼーションリレーが沈黙する

クラスターがBlindedBeaconBlockに署名すると、勝者のリレーは完全なブロックをEthereumに公開することが期待される（§2.3、ファイナリゼーションステップ4）。もし沈黙した場合、スロットは単に失われる。これは標準PBS（プロポーザー・ビルダー分離）のミススロット障害モードである。公開の欠如はケースIII-bと同じ証明問題を抱えており、評判による強制に委ねられる。そのスロットのSignedBlindedMiniBlock[0..M-1]ヘッダーは孤立し、部分的なアセンブリに類似する（付録）。

X — リレーが、配置がコミットされたtx_root_i値と一致しない、または総ガスがMAX_BLOCK_GASを超える最終ブロックを転送する

スラッシングルールB2（下記）によって強制される。

XI — クラスターが、スロットの累積受け入れガスをMAX_BLOCK_GAS以上に押し上げるSignedBlindedMiniBlockに署名する

スラッシングルールC3（下記）によって強制される。

XII — 勝者のファイナリゼーションリレーが、勝者のファイナリゼーションビルダーによって署名されたFinalBlockBidと一致しない実行ペイロードを持つブロックを公開する

このケースは実行可能な攻撃ではない。クラスターはBlindedBeaconBlockに署名する。これにはExecutionPayloadHeaderが含まれ、block_hashとtransactions_rootを含み、これらは実行ペイロードの正確なトランザクション内容に暗号学的にコミットする。リレーが異なる実行ペイロードを公開した場合、Ethereumノードはブロック署名を無効として拒否するだろう。したがって、リレーは、クラスターに提示したブラインド化されたヘッダーを構築するために使用された実行ペイロードとまったく同じものを公開する義務がある。

クラスターのスラッシングルール

C1 — ミニブロックの二重署名

クラスターが、同じ(slot, mini_block_index)に対して、異なる入札を持つ2つのSignedBlindedMiniBlockメッセージに署名する。

証拠: 2つのSignedBlindedMiniBlockメッセージMとM'で、以下の条件を満たすもの。

M.bid.slot == M'.bid.slot
M.bid.mini_block_index == M'.bid.mini_block_index
M.bid != M'.bid
M.cluster_signatureとM'.cluster_signatureの両方が、クラスターの公開鍵の下で有効なしきい値BLS署名である

これは、Ethereumのプロポーザー二重署名スラッシング条件に直接類似している。証拠はオンチェーンで検証可能な2つのBLS署名オブジェクトであるため、このルールは追加の実行コンテキストなしにSSVスラッシングコントラクトによって強制できる。

C2 — チェーンの破損

クラスターが、parent_mini_block_rootがhash(SignedBlindedMiniBlock[i-1])と等しくないSignedBlindedMiniBlock[i]に署名する。これは、スロットの途中でミニブロック履歴を実質的にフォークする行為である。

証拠: 有効なクラスター署名を持つ2つの連続するSignedBlindedMiniBlockメッセージSignedBlindedMiniBlock[i-1]とSignedBlindedMiniBlock[i]で、SignedBlindedMiniBlock[i].bid.parent_mini_block_root != hash(SignedBlindedMiniBlock[i-1])であるもの。

これは二重署名のより弱い形式である。同じインデックスに対して2つの矛盾するヘッダーに署名するのではなく、クラスターは連続するインデックス間のハッシュリンクを破る。

C3 — 累積ガス違反

クラスターが、スロットの累積受け入れガスをMAX_BLOCK_GAS以上に押し上げるSignedBlindedMiniBlockに署名する。クラスターは、スロット内のすべての先行ミニブロックの署名済みヘッダーを保持しており、署名する前に実行中の合計を計算できる。これは、すでにコミットしたSignedBlindedMiniBlockヘッダーのチェーン全体にわたるbid.gas_usedフィールドの単純な合計である。

証拠: 有効なクラスター署名を持つSignedBlindedMiniBlock[0..i]ヘッダーの完全なチェーンで、sum(SignedBlindedMiniBlock[j].bid.gas_used for j in 0..i) > MAX_BLOCK_GASであるもの。

C1およびC2と同じ計算クラスである。実行コンテキストなし、開示依存性なし、署名済みヘッダーのみからオンチェーンで強制可能。

ビルダーのスラッシングルール

B1 — tx_rootの不一致

ビルダーがリレーに提供したトランザクションリストのマークルルートが、付随するBlindedMiniBlockにコミットされたtx_rootと一致しない。リレーは、入札を受信すると直ちにこれを検出し（クラスターに何も転送する前に）、ビルダーの担保を二者間でスラッシュできる。

証拠: ビルダーのBlindedMiniBlock（bid.tx_rootとbuilder_signatureを含む）と、それに付随して提出されたトランザクションリストで、BinaryMerkleRoot([keccak256(t_1), ..., keccak256(t_k)]) != bid.tx_rootであるもの。このチェックは実行を必要としない。純粋なマークルルート計算である。クラスターの関与は不要であり、強制はビルダーの担保に対するリレー側で行われる。

リレーが過失により不正な入札をクラスターに転送した場合でも、不一致は事後に証明可能である。リレーがそのラウンドのトランザクションリストをブロードキャストすると（§3.2）、リストとBlindedMiniBlock（またはクラスターが署名した場合はSignedBlindedMiniBlock）を持つ任意の当事者は、不一致を検証し、証拠を提出してビルダーをスラッシュできる。bid.tx_rootとbuilder_signatureは署名済みオブジェクトと未署名オブジェクトの両方に存在するため、証拠が有効であるためにクラスターの関与は必要ない。

B2 — 最終ブロックの配置の不整合

ビルダーが、配置宣言が対応するSignedBlindedMiniBlock[i]ヘッダーにコミットされたtx_root_i値と一致しない、または総ガスがMAX_BLOCK_GASを超えるFinalBlockBidを提出する。ビルダーは提出時にSignedBlindedMiniBlockチェーン（tx_root_iとtx_count値を含む）を完全に知っていたため、不整合なFinalBlockBidは、ビルダーがリレーに預託した担保に対して強制可能な、証明可能なビルダーのコミットメント違反である。これはB1と同じモデルである。

証拠（配置の不一致）: 有効なクラスター署名を持つSignedBlindedMiniBlock[0..i]ヘッダーの完全なチェーン（それぞれbid.tx_count = k_jを保持するため、s_i = sum_{j < i} k_jは署名済みデータのみから導出可能）、単一のトランザクションtと、t ∈ tx_root_iを示すマークルインクルージョン証明、そのスロットの正規のEthereumブロックで、tがB内の期待される位置s_i..s_i + k_i − 1に現れないことを示すもの、および不整合な配置をカバーするビルダー署名済みFinalBlockBid。このようなトランザクションは1つだけ提示すればよいことに注意されたい。

証拠（総ガス違反）: スロットの正規のEthereumブロックとビルダー署名済みFinalBlockBid。ブロックのgasUsedは公開されている。もしMAX_BLOCK_GASを超過していれば、その違反はビルダーの署名済み入札から自明である。

両方のバリアントは純粋な暗号学的/算術的チェックであり、B1と同じ計算クラスである。

リレーの責任

リレーはプロトコル内のいくつかの信頼ポイントに位置する。彼らは、受信したBlindedMiniBlockをクラスターに転送する前に検証し（§2.3）、各受け入れられたミニブロック後にコミットされたトランザクションリストを保持しブロードキャストし（§3.2）、最終ブロックを組み立てる際に配置の整合性を検証する（§3.3）。プロトコルは、標準PBS（プロポーザー・ビルダー分離）と同じリレーの信頼モデルを継承する。リレーの障害は、オンチェーンスラッシングではなく、評判による強制によって管理される。このセクションでは、どの障害がスラッシング対象外であり、その理由をまとめる。

障害ケースNo.X — ビルダーはスラッシュ可能だが、リレーの過失はそうではない。 リレーがビルダーのFinalBlockBidを、エラーを検出せずに不整合な配置で転送した場合、不正な配置に対するビルダーのbuilder_signatureはオンチェーン証拠となる。ルールB2はビルダーを対象とする。リレーの検証失敗は評判に関する問題であり、オンチェーンでスラッシュ可能なものではない。

オンチェーンで証明不可能。 2つのリレー障害はスラッシング対象外のままである。

入札側のstate_root検証ミス（ケースVII）：リレーがトランザクションリストを実行してstate_rootを検証せずにBlindedMiniBlockをクラスターに転送した。これを証明するには、既知の事前ステートに対してトランザクションを再実行する必要がある。これは、オンチェーンEVM再実行では法外に高価であり、インタラクティブな不正証明ゲームでは多ラウンドプロトコル機構を導入し、ZK有効性証明では重いプロバーインフラを追加する。
T_iの非開示（ケースIII-b）：リレーが期限までにメッセージをブロードキャストしなかったことを証明することは、暗号学的オブジェクトではない。これは、「リレーRから時間Tまでに開示を観察しなかった」と署名する証人またはアテステーションを必要とし、スラッシングコントラクトが自然に扱わない社会的/プロトコルレイヤーを開く。強制は評判によるものであり、標準PBS（プロポーザー・ビルダー分離）と同じである。

将来のプロトコル上のパス。 入札側の検証ミスは、トラステッド実行環境（TEE）を介してオンチェーン強制下に置くことができる。TEEでは、リレーが証明された環境内で実行され、クラスターまたはスラッシングコントラクトがハードウェアアテステーションを検証する。これにより、PBS（プロポーザー・ビルダー分離）のプライバシー境界を維持しつつ、整合性保証を強化できる。あるいは、正しい実行の有効性証明が、TEEハードウェア依存性なしに同じ保証を達成できる。非開示はより困難なケースである。信頼できるオラクルなしにメッセージの不在を証明することは未解決の問題である。

6. 結論

ミニブロックは、既存のPBS（プロポーザー・ビルダー分離）パイプラインをサブスロットオークションレイヤーで拡張し、Ethereumエコシステムがスロットの価値をより多く実現できるようにする。リレーとビルダーには、スロットあたり1つではなく、複数のブロック先頭のような機会を与え、ユーザーとアプリケーションには、進行中のブロックのより速く、より豊かなビューを提供する。これらすべてを、新しい信頼できる当事者を導入したり、個別のブロック構築パスを導入したり、Ethereumコンセンサスに変更を加えたりすることなく実現する。この設計は、リレーとビルダーがすでに運用しているインフラに自然に適合し、それが生み出す余剰によって追加の運用負荷を補償し、プロトコルが成熟するにつれて段階的な強化（例：二重署名スラッシング）の余地を残す。また、さらなる拡張のための自然な基盤でもある。特に、[2]で導入された事前承認対応トランザクションタイプを採用することで、リレーインターフェースを再設計することなく、同じパイプラインをロールアップの事前承認、ベース事前承認、および同期的なL1↔L2コンポーザビリティに対応するように拡張できる。

参考文献

[1] nuconstruct, “Second Thoughts: How 1-second subslots transform CEX-DEX Arbitrage on Ethereum”. ArXiv, 2026. [2601.00738] Second Thoughts: How 1-second subslots transform CEX-DEX Arbitrage on Ethereum
[2] L. Oshitani, “Based Preconfirmations with Multi-round MEV-Boost.” Ethereum Research, 2024. Based Preconfirmations with Multi-round MEV-Boost
[3] J. Drake, “Based rollups — superpowers from L1 sequencing.” Ethereum Research, 2023.
[4] J. Drake, “Based preconfirmations.” Ethereum Research, 2023.
[5] EthGas Realtime API Documentation. Realtime Ethereum | ETHGas.
[6] Flashbots Relay Specs — Builder-API registerValidator. Relay-API
[7] Ethereum Builder API Specification - GitHub. GitHub - ethereum/builder-specs: Specification for the external block builders. · GitHub

付録

プロトコルの代替案

P2P通信

完全なP2P通信レイヤーも検討されたが、追加のゴシップ遅延、ネットワークの複雑さ、ピア管理のオーバーヘッドを導入する。リレーにとって関連する要件は、プロポーザー側のクラスターとのタイムリーな認証済みメッセージ交換であり、クライアント-サーバーモデルがこれを直接満たす。

義務ごとの登録

長期的な登録の代わりに、定期的または義務ごとのアドバタイズメントも検討されたが、すべてのスロットで冗長な調整オーバーヘッドを追加する。

中央集権型SSV側コーディネーター

中央集権型コーディネーターアプローチも検討された。これは外部インターフェースを簡素化できるが、設計の分散化目標に反し、SSVのビザンチン分散化の利点を損なう中央集権型信頼コンポーネントを追加することになる。それでも、対称的なアプローチは、基礎となるプロトコルに応じて最適化できる。例えば、リーダーベースの合意形成プロトコルの場合、リレーは、デフォルトのインターフェースを変更することなく、プロトコルレベルの最適化として、最初に現在のリーダーに通信を集中させることもできる。

シーケンシャル（ウォールクロックに固定されない）ミニブロックウィンドウ

ケースII（クラスターがウィンドウ内でSignedBlindedMiniBlock[i]を生成できない）を処理する際、セクション5で説明されているウォールクロックに固定されたキャッチアップルールに対する代替案として、ミニブロックウィンドウを固定されたウォールクロック間隔ではなくシーケンシャルとして扱う方法がある。この代替案では、ウィンドウi+1は事前に決定されたウォールクロック時間には開始せず、MiniBlockHeader[i]がブロードキャストされるとすぐに開始する。各ウィンドウは、前のウィンドウがどれだけ遅れて署名されたかに関わらず、完全なwindow_durationの間実行される。

その結果、スロットあたり実際に署名されるミニブロックの数が変動するようになる。プロトコルは、M個が署名されるか、remaining_slot_time < window_durationになるまでウィンドウを順次実行する。このモデルでは、Mは不変量ではなく、上限（「スロットあたり最大M個のミニブロック」）となる。最終ブロックはB = T_1 || ... || T_k || T_extraの形式をとり、k ≤ Mとなる。

この設計は、線形であり、署名されたすべてのミニブロックが非空であるため魅力的である。遅延が発生した場合、スロットは単に少ないミニブロックをホストするだけで、チェーンに空のヘッダーが蓄積されることはない。セクション5で選択された設計は、代わりにMをシンプルさのために厳密な不変量として維持しており、合意形成が非常に遅れた場合に空のSignedBlindedMiniBlockヘッダーの連続を許容するコストを伴う。両方のアプローチは、障害発生時にプロポーザーに提供する価値において本質的に同等であり（どちらも優雅に劣化する）、どちらを選択するかは、パイプラインの残りの部分やプロトコルの初期段階での正確性の証明にとってどちらの不変量がより便利かという問題である。

開示が欠落した場合の部分的なアセンブリ（ケースIII-b）

ケースIII-b（勝者のリレーがファイナリゼーションまでにT_iの開示に失敗する）を処理する際、スロットを失うことに対する代替案として部分的なアセンブリがある。これは、開示が時間内に観察されたミニブロックのみを使用して最終ブロックが構築されるというものである。具体的には、T_iが欠落している場合、最終ブロックはB = T_1 || ... || T_{i-1} || T_extraとして組み立てられる。ここでT_extraはT_{i-1}後のステートに対して計算され、j ≥ iのMiniBlockPlacementは発行されない。j ≥ iのSignedBlindedMiniBlock[j]ヘッダーは記録上存在するが、孤立する。それらは最終的なEthereumブロックには現れない。

このバリアントにおける重要な連鎖は、位置iでの開示の欠落が、ミニブロックi自体だけでなく、ダウンストリームの接尾辞i..M-1全体を孤立させることである。これは、SignedBlindedMiniBlock[i+1]がT_iによって生成されたステートの上に構築されたためである。ウィンドウi+1のペイロードを構築するビルダーは、MiniBlockHeader[i].state_diffを見て、T_iが適用されると仮定した。T_i以前のステートに対してT_{i+1}, ..., T_Mを実行すると、nonceと残高に関するEVM検証に失敗するだろう。したがって、部分的なアセンブリは、最後に完全に開示されたミニブロックで自然に切り詰められる。

この設計はスラッシングルールと整合している。C1、C2、B1、B2のいずれも、署名されたすべてのミニブロックヘッダーが最終的なEthereumブロックに含まれることを要求しない。プロトコルレベルの不変量は、代わりに、最終ブロックがそれが含めると主張する署名されたプレフィックスと整合していることである。孤立したヘッダーは、未包含のアテステーションに構造的に類似している。これらは存在するがオンチェーンには着地しない署名されたアーティファクトである。後で開示の欠落によって切り詰められるプレフィックスに署名するバリデータは正しく動作している。最終的に署名するBlindedBeaconBlockは、含まれるプレフィックスのみを参照し、それはSignedBlindedMiniBlock[0..i-1]ヘッダーと内部的に整合している。

セクション5で選択された設計は、よりシンプルな「スロットミス」ルールを選択している。これは、障害モデルを標準PBS（プロポーザー・ビルダー分離）と整合させ（サイレントリレー＝ミススロット、評判による強制によって管理される）、ミニブロックが含まれるかどうかに対するリレー主導の責任表面を導入することを避けるためである。部分的なアセンブリは厳密に価値をより保持するものであり、リレーの担保と部分的なインクルージョン会計が指定されれば、自然な実装パスとなる。

ブロック整合性の代替案

プロトコルは、各コミットされたtx_root_iの下のトランザクションが、最終ブロックのtransactions_root R内の期待される位置に忠実に現れることを確立する必要がある。構造的な緊張は次のとおりである。tx_root_iはトランザクションハッシュ上のバイナリマークルツリー（BinaryMerkleRoot([keccak256(t_{i,1}), ..., keccak256(t_{i,k_i})])）である一方、Rは完全なトランザクションバイト上のEthereum MPT（MPT_root({RLP(j) -> RLP(b_j)})）である。トランザクションを開示することなく、これら2つのコミットメントが同じトランザクション内容をエンコードしていることを証明するには、2つの構造間のクロスコミットメント証明か、信頼できる仲介者が必要となる。以下の代替案はそれぞれこの要件を満たそうとする。それぞれに重大な欠点があるため、セクション3.3の設計では、直接リスト比較が可能なリレーに検証を委ねている。

クラスター側検証（トランザクション開示が必要）

tx_root_i = BinaryMerkleRoot([keccak256(t_{i,1}), ..., keccak256(t_{i,k_i})])と定義する（メインプロトコルと同様）。リレーは、ブラインド化されたヘッダーとともにT_iとs_iをクラスターに転送し、各トランザクションのMPTインクルージョン証明π_{i,j} = MPT_proof(R, s_i + j, t_{i,j})も転送する。

クラスターはR（ルートハッシュ）のみを保持し、完全なトランザクションリストBは保持しないため、ここではMPT証明が必要である。リレーとは異なり（リレーはBを持ち、直接比較で検証できる）、クラスターはT_iがRの下で正しい位置にあることをチェックするために証明を必要とする。クラスターは以下を検証する。

BinaryMerkleRoot([keccak256(t_{i,1}), ..., keccak256(t_{i,k_i})]) == tx_root_i — 開示されたリストがコミットメントと一致することを確認する。
すべてのi、jに対してMPT_verify(R, s_i + j, t_{i,j}, π_{i,j}) = true — 各トランザクションがR内の期待される位置にあることを確認する。

このスキームは健全であり、新しいインフラは不要である。根本的な問題はステップ1である。クラスターはマークルルートを再計算するために完全なトランザクションリストT_iを受信する必要があり、PBS（プロポーザー・ビルダー分離）のプライバシー境界を侵害する。M = 4ミニブロックで各k = 20トランザクションのスロットでは、クラスターはファイナリゼーション時にすべての80トランザクションを受信する。

ミニブロックあたりの証明サイズ：k_i * O(log_16(n)) MPTノード、n = 300の場合、約k_i * 3 * 500バイト。k_i = 20の場合：ミニブロックあたり約30KB、合計約120KB。不正証明の場合、反例となる位置は1つだけで十分である：O(log k_i + log_16(n))ノード、約2KB。

トランザクションプライベートなクラスター検証

以下の両方のバリアントは、クラスターがトランザクション内容を見ることなく検証できるハッシュベースの補助コミットメントを定義する。しかし、それらは同じ根本的な制限を共有している。クラスターは、補助コミットメントがRと整合していることを独立して確認できない。このギャップを埋めるには、リレーを信頼するか（これはセクション3.3のモデルに収束する）、または新しいEthereumフィールド（EIP（Ethereum 改善提案）が必要）が必要となる。2つのバリアントは構造的に異なるが、同じ結論に至る。

バリアントA — ミニブロックコミットメントの補助ルート。 以下を定義する。

aux_root = BinaryMerkleRoot([tx_root_1, tx_root_2, ..., tx_root_M])

ビルダーはaux_rootをFinalBlockBidに含める。クラスターは、すでに保持しているtx_root_i値からaux_rootを再計算する（トランザクション内容は不要）し、各iに対してBinaryMerkleVerify(aux_root, i, tx_root_i, path_i) = trueを検証する。これは安価である。O(M log M)ハッシュ。ギャップは、aux_rootがM個のミニブロックルートのみをエンコードし、Rではないことである。クラスターはaux_rootとRが同じトランザクションを反映していることを検証できない。

バリアントB — ハッシュキー付きMPT。 リーフが完全なトランザクションバイトではなくトランザクションハッシュを保持する代替のトランザクションルートを定義する。

R_hash = MPT_root({RLP(j) -> keccak256(RLP(b_j)) : 0 <= j < n})

ビルダーは、各ミニブロックiとオフセットjに対して、tx_root_i内のバイナリマークルパスρ_{i,j}と、R_hash内のMPT証明π_{i,j}を、両方ともハッシュのみで提供する。クラスターは、完全なトランザクションバイトを見ることなく両方を検証する。証明サイズはクラスター側検証と一致するが、プライバシー境界は維持される。ギャップは、R_hashが標準のExecutionPayloadには存在しない新しいオブジェクトであることである。クラスターは、それがRと整合していることを検証する方法がない。

共通の解決策。 両方のバリアントは、それぞれのギャップを埋めるために同じ2つのオプションに直面する。

リレーのアテステーション。 リレーは、補助コミットメントとR間のバインディングに署名する（例：BLS_sign(keccak256(aux_root || R || slot))）。クラスターは署名を検証し、リンクについてはリレーを信頼する。これはセクション3.3の設計と機能的に同等であり（リレーが信頼のアンカーである）、基礎となる信頼仮定を変更することなく構造化されたコミットメントオブジェクトを追加する。
実行クライアント統合（EIP（Ethereum 改善提案））。 補助コミットメント（miniblocks_rootまたはtx_hashes_root）をExecutionPayloadヘッダーのファーストクラスフィールドとして追加し、transactions_rootとともに実行クライアントによって計算されるようにする。両方が同じクライアント内の同じトランザクションリストから派生するため、整合性は自明に保証される。EIP（Ethereum 改善提案）と実行クライアントの調整が必要となる。

連続リレー入札

§2.1のラウンド構造は、固定されたwindow_duration間隔（デフォルト2秒）にコミットしている。実際には、リレーはオーダーフローが到着するにつれて継続的に入札を発行する可能性があり、より忠実なプロトコルは、入札をウィンドウにバッチ処理するのではなく、到着したときに取り込むだろう。選択された設計は、コンセンサスレイヤーをシンプルに保ち、スロットのタイミングを予測可能にする厳格なスケジュールと引き換えに、その忠実性の一部を犠牲にしている。以下の方向性は、将来のプロトコルバージョンでウィンドウの厳格性をどのように緩和できるかを示している。このセクションは、コンセンサス遅延下でのウォールクロックのずれに対処するシーケンシャルウィンドウの代替案を補完するが、ここでは連続的な入札のより密接な追跡が目標である。

より短いウィンドウ。 最もシンプルな改良は、現在のプロトコルを維持し、window_durationを短縮するだけである。例えば、0.5秒に短縮し、それに合わせてNUM_MINIBLOCKSを増やすことで、ラウンドの周期がより細かく入札ストリームをサンプリングする。この粒度では、オペレーターは魅力的な入札がない場合にコミットしないことを決定し、固定された間隔ごとにコミットを強制するのではなく、スロットを先に進めることも期待される。この方向性の限界はDVTコンセンサスレイテンシである。各ウィンドウは1つのコンセンサスインスタンスに対応する必要があり、そのためには最適化されたコンセンサスアルゴリズムが必要となる。

入力トリガー型コンセンサス。 より深い方向性は、固定された周期をなくし、プロトコル自体がコンセンサスラウンドを実行する時期を決定できるようにすることである。これは、事前に決定されたクロックティックではなく、十分に価値のある入札の到着によってトリガーされる。固定された瞬間にオークションウィンドウを開閉するのではなく、クラスターは入札ストリームが価値またはタイミング条件を超えたときに決定を開始するだろう。これはコンセンサスレイヤーを大幅に再構築するものであり（ほとんどの既存のコンセンサスプロトコルは予測可能なラウンド開始時間を前提としている）、未解決の研究領域に属する。

リーダーが選択する提案タイミング。 より限定的なパスは、既知のラウンド開始時間を持つ標準的なリーダーベースのコンセンサスプロトコルを維持しつつ、リーダーがラウンド内で提案メッセージを発行する時期を選択できるようにすることである。リーダーは、ラウンド内の最新の安全な時点までより良い入札を待ち、全体的なスケジュールは外部からは決定論的なままである。これはほとんどの既存のリーダーベースのプロトコルと互換性があり、入力トリガー型コンセンサスよりも厳密に少ない機構を導入する。

これらの方向性はそれぞれ、プロトコルのシンプルさの一部を犠牲にして、リレー入札の連続的な性質により密接に適合させるものである。いずれも選択された設計（初期バージョンのシンプルさのため）には採用されていないが、コンセンサスとネットワークが改善されるにつれて、2秒ウィンドウを緩和する自然な道筋である。

1投稿 - 1参加者

トピック全文を読む

Ethereum フォーラム日本語アーカイブ

エクスプローラー

トピックで絞り込む

ミニブロック: Ethereum PBSのためのSSV支援サブスロットオークション

動機

アクター

1. SSVオペレーターとリレー間の通信レイヤー

2. プロトコル概要

2.1 タイミング

2.2 メッセージ

2.3 プロトコル

2.4 シーケンス図

3. ブロックのパッキングとEthereumネットワークへの提出

3.1 コミットメントチェーン

3.2 トランザクションの開示

3.3 フルブロックの構築と整合性チェック

3.4 不達

4. ユーザーとサーチャーへのステートアドバタイズメント

5. セキュリティ

クラスターのスラッシングルール

ビルダーのスラッシングルール

6. 結論

参考文献

付録

プロトコルの代替案

P2P通信

義務ごとの登録

中央集権型SSV側コーディネーター

シーケンシャル（ウォールクロックに固定されない）ミニブロックウィンドウ

開示が欠落した場合の部分的なアセンブリ（ケースIII-b）

ブロック整合性の代替案

クラスター側検証（トランザクション開示が必要）

トランザクションプライベートなクラスター検証

連続リレー入札

グラフビュー

目次

Ethereum フォーラム 日本語アーカイブ

エクスプローラー

トピックで絞り込む

ミニブロック: Ethereum PBSのためのSSV支援サブスロットオークション

動機

アクター

1. SSVオペレーターとリレー間の通信レイヤー

2. プロトコル概要

2.1 タイミング

2.2 メッセージ

2.3 プロトコル

2.4 シーケンス図

3. ブロックのパッキングとEthereumネットワークへの提出

3.1 コミットメントチェーン

3.2 トランザクションの開示

3.3 フルブロックの構築と整合性チェック

3.4 不達

4. ユーザーとサーチャーへのステートアドバタイズメント

5. セキュリティ

クラスターのスラッシングルール

ビルダーのスラッシングルール

6. 結論

参考文献

付録

プロトコルの代替案

P2P通信

義務ごとの登録

中央集権型SSV側コーディネーター

シーケンシャル（ウォールクロックに固定されない）ミニブロックウィンドウ

開示が欠落した場合の部分的なアセンブリ（ケースIII-b）

ブロック整合性の代替案

クラスター側検証（トランザクション開示が必要）

トランザクションプライベートなクラスター検証

連続リレー入札

グラフビュー

目次

Ethereum フォーラム日本語アーカイブ