Airbender Prime、最も遅いブロックを見る

分析 | 2026年10月17日

ZKsyncの10月13日の評価では、GPU一基で7,200ブロックすべてを各12秒未満で証明したと報告している。

工学的に重要な問いは、高速な証明器が生む時間の余裕をどう使うかだ。Open Market Notes は、待ち時間の短縮、処理要求の集中への備え、追加の実装による一致の要求という三つの選択肢を検討する。以下の計算は独自の仮想例であり、Airbender Prime の実測値でも、発表された試験の独立した再現でもない。

時計を止める地点を決める

Ethereumのロードマップは12秒のブロック生成間隔を説明し、証明生成と検証を区別している。

提案するサービス試験では、必要な情報がそろったジョブが利用可能になった時点から、必要な結果が受理された時点までを測る。待ち行列、証明、伝送、検証の時間を別々に記録する。証明段階を短縮すれば他の段階に使える時間は増えるが、それらの実際の所要時間が分かるわけではない。また、ブロック間隔だけではサービスの受理期限は決まらない。その条件を明記する必要がある。

遅いジョブは次のジョブも遅らせる

独立した五つのジョブが、0、12、24、36、48秒の時点で到着するとする。一つのワーカーが到着順に処理し、途中で中断して別のジョブに切り替えることはない。処理時間は順に8、8、20、8、8秒で、各期限は到着から12秒後とする。伝送、検証、起動などの費用はすべて時間計算から除く。期限ちょうどの完了は間に合ったものと扱う。

完了時刻は8、20、44、52、60秒で、期限は12、24、36、48、60秒になる。平均処理時間は10.4秒にすぎないが、三番目と四番目は遅れる。四番目の処理自体は八秒でも、三番目が生んだ待ち時間を引き継ぐ。五番目は期限ちょうどに完了し、省略した費用を吸収する余裕がない。

この例は実際のシステムの期限超過率を推定するものではない。ジョブの処理に費やす時間と、到着後に経過した時間の違いを切り分けている。順序を変える、中断を認める、ワーカーを増やすといった変更は別の実験になる。その選択を平均値の中に隠してはならない。

予備能力と必須の一致は異なる

Ethereum Foundationの研究は、zkVMと、それが実行する状態遷移の実装の両方に多様性を求めている。

ここで、二つの仮想的な受理ルールを考える。一つは二つのワーカーから最初に届く有効な結果を受理する。もう一つは、指定した二つの独立実装から有効で一致する結果が両方届くことを要求する。同じ候補ブロックについて、結果が八秒と十三秒で利用可能になり、他の時間費用はないとする。前者は八秒で受理できるが、後者は十三秒より前には受理できない。これはサービス方針の例示であり、現在のEthereumの合意形成を説明するものではない。

したがって、追加ワーカーの役割は二つの設計で異なる。一方では遅れた結果を補えるが、他方ではその結果自体が必須条件になる。機械の台数だけでは、何が一致しなければならないかは分からない。速度比較では、必須の結果が欠けた場合にジョブが未完了のままとなるかも含め、受理ルールを示す必要がある。

集中到着を試し、未完了の仕事も示す

固定したブロック列を、集中到着を含む明示的な到着予定で再生する試験を提案する。ブロックごとにワーカーを初期状態に戻さず、待ち行列の履歴を保つ。利用できるハードウェア、スケジューリング規則、期限、受理条件を明記する。想定する冗長化や実装多様性の要件を有効にした状態で、同じ列を実行する。

期限内に受理した結果、遅れた結果、未完了のジョブを分けて報告し、集中到着の後に待ち行列が回復するまでの時間を示す。完了時刻がないというだけで未完了の仕事を除外してはいけない。除外すると、苦戦しているサービスが速く見える可能性がある。この運用結果は安全性の評価と分けて扱う。

設計上の選択は、節約した時間の使い道にある。待ち時間の短縮、処理しにくい並びへの備え、追加で必須となる結果は、同じ余裕の異なる用途だ。次の有用な実証では、その配分を明らかにし、設計によって生じる待ち行列の下でも、選んだ期限を守れるかを示すべきだ。