暗号技術

このページは、チェーンと連携する際にライブラリを選ぶとき、パラメータをノードが強制する内容と照合するとき、そして id やコミットメントを自分で再計算するときに使ってください。ここに挙げた値はすべて、chain 20(fullnode v0.6.8)上でコードが実際に使っているものです。

プリミティブと用途

ホワイトペーパーの目標パラメータは、実装が実際に使う値と異なる箇所があります(たとえば、論文の 384 ビットのトランスクリプトハッシュに対し、zkVM は Poseidon2 のトランスクリプトを使います)。これらのページが記述するのはコードの内容です。

ブリッジにおけるポスト量子共同署名

ブリッジのガーディアン証明は secp256k1 ECDSA であり、量子コンピュータを持つ攻撃者は偽造できる可能性があります。chain 14 以降、すべての BridgeAttest(入金もガーディアンセットのローテーションも同様)は、同じガーディアンによる同じダイジェストへの Dilithium2 署名のクォーラムも持たなければなりません。

M = "rand-bridge-pq-cosign-1" || rand_chain_id (u64 BE) || mu        // 63 bytes, deterministic signing

ここで mu = keccak256(keccak256(body)) は ECDSA クォーラムが署名する値です。M に含まれる Rand の chain id により、ガーディアン鍵が再利用されたとしても、testnet の共同署名が別の Rand チェーンで検証を通ることはありません。M がバインドするのは chain id のみで、これは chain 20 でも同じです。binding_domain がジェネシスハッシュの背後へ移さなかった唯一の署名対象メッセージであり、それに署名するガーディアンのデーモンが別のリポジトリにあるためです。同じ chain id と同じガーディアンセットを持つチェーンのコピーは、その入金の共同署名を受け入れてしまいます。ガーディアンセットのインデックスは M に含まれないため、共同署名は ECDSA セットのローテーションをまたいで有効です。アクションの pq_signatures フィールドは PqSignature { index: u8, signature } のリストで、安価な検査を先に、高価な検査を後にして検証されます。quorum(n) ≤ len ≤ n(PqNoQuorum)、インデックスが厳密に増加していること(PqIndexOrder)、すべてのインデックスが n 未満であること(PqIndexOutOfRange)、すべての署名がちょうど 2,420 バイトであること(PqBadSignatureLength)、最後に、すべての署名が pq_guardians[index] の下で検証を通ること(PqBadSignature)です。PQ の署名者が ECDSA の署名者と同じである必要はなく、それぞれのクォーラムは別々に数えられます。このフィールドはトランザクションバインディングの内側にあるため、コピーから取り除いたり差し替えたりすることはできません。

PQ セットはジェネシスの bridge.pq_guardians です。chain 20 では chain 15 から 19 と同じく 1,312 バイトの鍵 8 個で、ジェネシスの ECDSA セット(ガーディアンセット 1)とインデックスが対応しています(chain 14 は 6 個で、セット 0 に対応していました)。ECDSA のガーディアンセットのローテーションがこれを動かすことはありません。chain 14 ではチェーンの存続期間中固定でしたが、chain 15 以降はジェネシスにブリッジの rules_v2 グループが含まれ、その下では PQ クォーラムが PQ セット全体(RotatePqGuardians)または停止鍵(RotatePauseKey)を置き換えられます。いずれもブリッジの rotation_nonce の下で行われます。chain 20 のジェネシスは bridge.rotation を追加します。ローテーションは V2 アクションでなければならず、各新しい鍵自身が同じメッセージに対して行う Dilithium2 署名(所有証明)を伴います。また、現在の停止鍵がキャンセルしない限り、確定から 1 日後に有効になります(Bridge)。rand_getBridgeState は鍵を返し、デコードされた bridge_attest は署名したインデックスである pq_signers を列挙します。同じ PQ クォーラムが、ブリッジのガバナンスメッセージも承認します。各メッセージは、chain id とナンスを含む固定のビッグエンディアンのレイアウトです。chain 20(ジェネシスの binding_domain: 1)では、各ドメインのバージョン桁が 2 になり、32 バイトのジェネシスハッシュがドメインと chain id の間に入ります。chain 14 から 19 は -1 の形式を使います。

本番環境の STARK

zkVM は制約セット 8 にあります。9 個の必須テーブル(program、cpu、memory、alu、range、nibble、poseidon2、input、public)に加え、ゲストが対応するシステムコールを呼び出した場合にのみ証明が持つ keccak テーブルと sha256 テーブルがあり、17 本のバスで接続され、1 つのバッチ STARK として証明されます。制約セット 7 以降、宣言されたすべてのテーブルは少なくとも 2⁷ 行を持ち、すべてのテーブルの LogUp 終端は 17 番目のバス BLIND を通じてブラインドされます。証明のパブリックインターフェースは 35 個のフィールド要素(pv::NUM)です。エントリ pc、ティア、8 個の出力ワード、プログラムダイジェスト hc(8 ワード)、ソルト付きのプライベート入力コミットメント H_IN(8)、ソルトなしのパブリックセグメントダイジェスト H_PUB(8)、そして制約セット 8 以降は宣言されたガス上限 GAS_LIMIT です。

コンストレイントセット6での実測サイズ(Apple Silicon、リリースビルド)は次のとおりです。keccak を含まないプロダクション証明は、ティア10で 1,298,729 バイト、ティア12で 1,359,978 バイトでした。keccak を含むティア10の証明は 3,198,430 バイトで、既定の 2 MiB を超え、チェーン13〜15の 8 MiB を下回ります。廃止された 2-in-2-out のバンドルゲストのティア14の証明は、チェーン8で 1,321,773 バイト、チェーン13で 1,418,406〜1,420,423 バイトでした。チェーン14の 4-in-4-out の hidden-asset バンドルゲストは、ハッシュテーブルをどちらも持たないままティア14にとどまり、その証明はチェーン14(2026-09-20)で 1,422,116 バイトと 1,423,170 バイトでした。チェーン15も同じゲストを固定しています(hc_bundle は変更なし)。そこではバンドル証明が public_log_height を 4(8個のバインディングワードの高さ)と宣言し、ノードは検証鍵を構築する前に、それ以外の値をすべて拒否しました。2026-09-19 にチェーン13で作成した、keccak を含む ERC-20 approve 呼び出しの証明(ティア16)は 3,412,405 バイトです。fullnode v0.5.6 以降のすべてのチェーンは、この呼び出しをティア16で拒否します。

コンストレイントセット7のブラインディング列とテーブルのフロアにより、ハッシュを含まない証明は約5%大きくなります。fullnode による 2026-09-28 の実測では、fib はティア10で 1,367,688 バイト、ティア12で 1,424,299 バイト、keccak を含むティア10の証明は 3,283,898 バイト、ティア14の hidden-asset バンドル証明は 1,498,821 バイト(ゲスト v1)と 1,497,156 バイト(ゲスト v2)でした。それ以降、バンドル証明は public_log_height を 7 と宣言します。コンストレイントセット8の増加は 1% 未満です。2026-09-30 にチェーン18で実測した値(Apple Silicon)は次のとおりです。認可証明は 1,364,940〜1,375,371 バイト(ティア10)、バンドル証明は 1,494,151〜1,504,260 バイト(ティア14、ゲスト v3)、呼び出し証明は、ハッシュテーブルなしのティア14で 1,498,589 バイト、SHA-256 テーブルありのティア14で 1,911,152 バイト、Keccak テーブルありのティア12で 3,346,865 バイトです。いずれも、チェーン18〜20の 4 MiB の上限に収まります。

検証にかかる時間は、検証鍵がウォームな状態で約 16 ms、(tier, heights) の鍵を初めて構築するときで約 230 ms です。test FRI プロファイル(16クエリ)はテストスイート用で、安全ではありません。チェーン20のジェネシスは production を固定しています。fullnode v0.6.8 はコンストレイントを一切変更しません。チェーン20は、チェーン17〜19と同じ hc_bundle と hc_auth を固定しています。

再現できるハッシュ構成

ドメイン付きの BLAKE3: blake3(domain || data)。ドメイン文字列は区切りなしで連結します。

バインディングドメイン。 チェーン20のジェネシスは binding_domain: 1 を設定しています(fullnode v0.6.8、audit v6 BIND-1)。このようなチェーンでは、チェーン ID だけをバインドしていたすべての証明バインディングと署名済みアクションメッセージが、ジェネシスハッシュもバインドするようになります。ドメインのバージョン番号が1つ上がり、32バイトのジェネシスハッシュがプリイメージの先頭、チェーン ID の前に置かれます。これにより、あるチェーン向けに作った証明や署名は、チェーン ID と鍵を再利用した別のチェーン(再カットの場合など)でも、他のどのチェーンでも検証を通りません。バインディングワードは証明の公開入力なので、ゲストも検証鍵も変わっていません。表には両方の形式を載せています。チェーン14〜19は前者をバイト単位でそのまま使います。以前からジェネシスにバインドされていて変更がないものは、投票と提案(consensus_domain: 1 以降)、v2 の Registration、AdmitValidator の投票です。移していないものは、ブリッジのミント共同署名(前述)です。チェーン20で送信するにはウォレットが v0.6.8 である必要があり、形式はノードの申告ではなくチェーン ID で決めます。rand_getLimits.binding_domain がそれを報告します。

ドメインタグ付きの Poseidon2: H(domain, msg) = sponge_hash([domain, msg...])。タグが最初に吸収されるワードで、各ワードは Goldilocks の要素です。4要素のダイジェストは8個の u32 ワードに分割されます(各要素の下位半分、次に上位半分)。ドメインタグ:

hc、H_IN、H_PUB は、単純なメッセージプレフィックス付きのスポンジではありません。ヘッダーはキャパシティに入るため、cpu テーブルのダイジェスト行は1回の置換でちょうど4ワードを吸収します。手作業ではなく、ベンダリングされたクレート(randprotocol_zkvm::hash::{input_digest, public_digest}、isa::Program::digest)で再現してください。

単純なスポンジはパディングを行わないため、最初のブロック内では [a] と [a, 0] は同じハッシュになります。上記のすべての構成は、固定長のメッセージをそれぞれ固有のタグでハッシュします。長さが変わりうるデータのために、制約セット7で長さ束縛付きスポンジ(hash::sponge_hash_len、POSEIDON2_LEN syscall)が加わりました。このスポンジは状態 [0, 0, 0, 0, n, 0, 0, 0](n はワード数)から始まり、少なくとも1回は置換を行います。同じワード列に対する別のハッシュであり、チェーン上のノート、ヌリファイア、ルート、ダイジェストのいずれもこれを使っていません。

覚えておくべき性質が2つあります。hc は束縛性はあるものの秘匿性はなく(ソルトがないため、推測したプログラムを確認でき、同一プログラムの2つのデプロイを関連付けられます)、H_IN は束縛性に加えて秘匿性もあります(証明ごとに新しい128ビットのソルトを用います)。そのため H_IN を公開しても、ソルトの保持者がそれを開示するまで、入力については何も明らかになりません。

鍵の導出

論文ページの論文には、セキュリティ上の議論が載っています。ポスト量子の選択、FRI の健全性の見積もりと80クエリを維持する理由、そしてトレース長の上限です。