このページでは、Rand における主要な設計判断ごとに、その根拠を記録しています。記録する内容は、コンポーネントが備えるべき性質、その性質が成り立つための前提、そして引き換えに受け入れたコストです。本ページは 2026年9月29日 に、このサイト、ホワイトペーパーの要約、およびリファレンス実装のフルノード(github.com/randprotocol/fullnode:その README、docs/、docs/superpowers/specs/)から編纂しました。各回答には、根拠が述べられている文書を示しています。パスは、randprotocol.org で始まるものを除き、fullnode リポジトリ内のパスです。
状況。 Rand は創業チームが運営する testnet 上で稼働しており、プロトコルは独立した監査を受けていません。以下の判断のいくつかは、チェーンのカットを通じて段階的に実装されています。掲載した数値はすべて、編纂時点で稼働していたノードの測定値です。今後変更される見込みであり、引用する前に再測定する必要があります。
暗号プリミティブ
1. ノートの暗号化に ML-KEM-768(Kyber)を使うのはなぜですか。
ノートの平文は、受信者宛てに暗号化されたエンベロープに収められ、そのエンベロープは公開台帳に無期限に残ります。したがって、その機密性は取り消し不能な性質です(質問8)。楕円曲線 KEM で封をした過去のエンベロープは、暗号学的に意味のある量子コンピュータを後の時点で入手した攻撃者に、すべて復号される可能性があります。Shor のアルゴリズムが離散対数問題を多項式時間で解くためです。ML-KEM は NIST FIPS 203 で標準化されており、その安全性は Module-LWE に帰着します。Module-LWE を効率的に解く量子アルゴリズムは知られていません。パラメータセットの 768(NIST カテゴリ3)は、安全マージンと、すべてのアドレスが持つ必要のある 1,184 バイトのカプセル化鍵とのトレードオフとして選びました。エンベロープは ML-KEM-768 と ChaCha20-Poly1305 を組み合わせたもので、1,348 バイト、固定長のメモフィールドを含めると 1,860 バイトです。
出典:randprotocol.org(耐量子セクション)、fullnode README、docs/shielded.md §2
2. Pedersen ではなく Poseidon2 コミットメントを使うのはなぜですか。
Pedersen コミットメントは完全に隠蔽的ですが、束縛性は計算量的なものにとどまり、その束縛性は離散対数の仮定に帰着します。量子の攻撃者はこの仮定を破ります。離散対数を計算できる攻撃者は、コミットメントを別の値に対して開示できてしまいます。今日公開したコミットメントは台帳の存続期間を通じて健全性と隠蔽性を保たなければならないため、方式は量子の攻撃者に対しても成り立つと信じられている仮定の上に置く必要があります。実際には、これはハッシュ関数を意味します。Poseidon2 は Goldilocks 体上で定義された算術化向きのハッシュであり、STARK の内部で評価しても制約数が少なくて済みます。ノートのコミットメント、深さ32の Merkle ツリー、ナリファイアは、同じハッシュで実現しています。
出典:randprotocol.org(耐量子セクション)、docs/shielded.md §1–2
3. BLAKE3 と Poseidon2 という2つのハッシュ関数を使うのはなぜですか。
2つの関数は、異なるコストモデルに対して最適化されています。Poseidon2 は、ハッシュを証明の内部で評価しなければならない箇所、すなわちノート、コミットメントツリー、ナリファイア、zkVM の内部テーブルで使います。そのコストが制約数で測られるためです。BLAKE3 は、証明を伴わず、ネイティブのスループットが支配的な箇所で使います。具体的には、ブロックハッシュ、ツリー・ナリファイア集合・バリデータ登録簿・プログラムテーブルにわたるステートルート、そしてバリデータのアドレス(公開鍵の BLAKE3 ダイジェスト)です。Poseidon2 は CPU 上では比較的低速であり、BLAKE3 は算術化のコストが比較的高くなります。それぞれを、そのコストモデルが当てはまる箇所にのみ使っています。
出典:fullnode README(署名/ハッシュの行)、docs/architecture.md
4. バリデータの署名に Dilithium2(ML-DSA)を使うのはなぜですか。
コンセンサスの署名が提供するのは更新可能な性質です(質問8)。方式が後に破られても、将来のメッセージを偽造できるようになるだけで、すでにファイナライズされたブロックが遡って無効になることはありません。そのため原理上は、量子の攻撃者が現れる前に方式を置き換えられます。それでも、コンセンサスの投票、ブリッジのガーディアンの共同署名、バリデータ登録簿が単一の耐量子鍵タイプを共有できるよう、ジェネシスから格子ベースの方式を採用しました。ノードが実装しているのは第3ラウンドの Dilithium2 パラメータセット(crystals-dilithium クレート)で、最終版の FIPS 204 ML-DSA-44 とは異なります。公開鍵は 1,312 バイト、署名は 2,420 バイトです。
出典:docs/superpowers/specs/2026-09-19-pq-cosignature-bridge.md §2、randprotocol.org
5. SNARK ではなく透明な STARK(Goldilocks 上の FRI)を使うのはなぜですか。
この選択は3つの要件から導かれます。第一に、トラステッドセットアップが不要であること。健全性は、構造化参照文字列やペアリングフレンドリーな曲線ではなく、ハッシュ関数の衝突耐性のみに依拠します。第二に、耐量子の健全性が妥当であること。この論証は離散対数やペアリングの仮定を置きません。第三に、質問2のハッシュベースのコミットメント方式と整合することです。コストは証明のサイズです。バンドル証明は約 1.3 MB で、Zcash や Monero のシールドトランザクションの 300〜600 倍にあたります。このコストは受け入れたうえで、ブロック単位のアグリゲーションで別途対処しています(質問31および34)。
出典:randprotocol.org、docs/block-space.md §1、docs/zkvm.md
6. FRI のクエリ数を 27 ではなく 80 のプロファイルにしたのはなぜですか。
本番プロファイル(80 クエリ、ブローアップ係数 8、20 ビットのプルーフ・オブ・ワーク・グラインディング)は、約 86 ビットの証明可能な健全性を提供します。27 クエリのプロファイルは約 42 ビットで、本番プロファイルの証明サイズは 2.75 倍になります。検証時間はほとんど変わりません。コールドで 809 ms から 838 ms に増える程度で、ウォームでは約 16 ms です。証明可能な健全性を証明サイズより優先し、サイズのコストはブロックスペースとアグリゲーションの設計に転嫁しました。
出典:docs/block-space.md §1、§3
7. 耐量子性の主張を「プロトコル全体で128ビット」ではなく、プリミティブごとに述べているのはなぜですか。
以前の草稿では、プロトコル全体で 128 ビットの耐量子安全性を主張していました。この主張は Brassard–Høyer–Tapp の下界と整合しません。この下界のもとでは、量子の攻撃者は 256 ビットのハッシュの衝突を約 2^85 回のクエリで見つけます。そのため、この主張は限定を付けて残すのではなく、撤回しました。論文は現在、安全性をプリミティブごと、役割ごとに述べています。対象は、384 ビットのトランスクリプトハッシュ、原像耐性のみが必要な箇所で使う 256 ビットのハッシュ、Dilithium2、ML-KEM-768、拡大体上の FRI で、Module-LWE と Module-SIS の仮定のもと、ハッシュ関数は量子ランダムオラクルとしてモデル化しています。ノードのトランスクリプトハッシュは現時点では Poseidon2 であり、ドキュメントはこれを未解決の設定上のギャップとして挙げています。
出典:randprotocol.org(耐量子セクション)
8. 「取り消し不能と更新可能」の分類とは何で、なぜ選択を左右するのですか。
セキュリティ上の性質が取り消し不能であるとは、将来のいずれかの時点で新たな能力を得た攻撃者が、すでに公開されたデータについて、その性質を遡って破れることをいいます。ノートの機密性とコミットメントの隠蔽性はこの種類に属するため、公開の時点で量子耐性を備えている必要があります。性質が更新可能であるとは、使用のたびに性質が再確立されるため、脅威が現実になる前に方式を置き換えられることをいいます。署名と証明の健全性はこの種類に属します。このセクションにおける各プリミティブの選択は、それが守る性質をこのように分類することから導かれています。
出典:randprotocol.org(耐量子セクション)
シールドプール
9. アカウントも残高もない、ノート/UTXO モデルを採用するのはなぜですか。
アカウントベースの台帳は、構造上、残高を公開します。残高を隠すには、状態を暗号化し、その暗号文に対する命題を証明する必要があり、コストは大幅に高くなります。ノートプールが保存するのはコミットメントとナリファイアだけで、どちらも所有者や金額を明かしません。そのため、公開状態には残高に関する情報が含まれません。唯一の例外はバリデータ登録簿で、レプリカがクォーラムの構成について合意できるよう、そのステーク重みは公開されていなければなりません(質問29)。
出典:docs/shielded.md §1–2、docs/staking.md §1
10. アドレスが約 1.6 KB あるのはなぜですか。
シールドアドレスは、32 バイトの所有者フィールド pk と、送信者がエンベロープに封をするために必要な 1,184 バイトの ML-KEM-768 カプセル化鍵からなります。base58 でエンコードすると、約 1,667 文字になります。この長さは、耐量子 KEM の直接の帰結です。承認済みの設計(短いシールドアドレス、2026-09-17)は、アドレスを約 256 ビットの受信者識別子に置き換えます。この識別子は、更新可能なレコードに解決されます。レコードは花消費鍵で署名され、エクスプローラが配信します。これにより、カプセル化鍵は書き写すのではなく取得するものになります。
出典:docs/shielded.md §1、docs/superpowers/specs/2026-09-17-short-shielded-address.md
11. すべての鍵を1つの 256 ビットのスペンディングキーから導出するのはなぜですか。
その他の鍵素材はすべて、単一の秘密 sk の決定的な関数です。ビューイングキー nk = H(NK, sk)、所有者フィールド pk = H(PK, nk)、ナリファイア H(NF, nk, cm)、アウトゴーイングビューイングキー、ML-KEM の復号鍵が、それぞれ独自のドメイン分離子のもとで導出されます。そのため、鍵ファイルが保存するのは sk だけで、バックアップは1つの値で済み、ツリーをリーフ 0 からスキャンし直せばすべてのノートを復元できます。復元の元となる2つ目のコピーが存在しないため、ウォレットは既存の鍵ファイルの上書きを拒否します。
出典:docs/shielded.md §1
12. バンドルの形を 4入力4出力に固定するのはなぜですか。
形を固定すると、移動する内容にかかわらず、すべてのバンドルが同じサイズと構造になります。各バンドルは、ちょうど4つのナリファイアと4つのコミットメントを公開します。使わないスロットは額面ゼロのダミーノートで埋め、おつりの出力は、値がゼロであっても公開します。おつりの出力が欠けていると、そのトランザクションを他と区別できてしまうためです。当初の仕様は、Sapling にならった 2入力2出力でした。これを、隠しアセットのバンドルとともに 4入力4出力に広げました。スロット 0〜1 がプライベートなアセットを、スロット 2〜3 が手数料用の RAND を運びます。3スロットではなく4スロットにしたのは、トークン転送が最大2つの RAND ノートから手数料を賄えるようにするためです。
出典:docs/shielded.md §2、docs/superpowers/specs/2026-09-19-hidden-asset-bundle-design.md §3
13. 1つの証明であらゆるアセット(RAND、zUSD、RPL トークン)を移動できるのはなぜですか。
Chain 14 より前は、トークン転送に二つのバンドルが含まれていました。一つは RAND の手数料用、もう一つは資産用です。そのため証明が二つ必要になり、どのトークンが移動したかが観察者に明らかになっていました。hidden-asset ゲストは資産識別子を非公開入力として受け取るので、zUSD の転送は RAND の支払いと区別できません。このゲストが tier 14(約 100 秒、メモリ約 5.7 GB)に収まるのは、入力をループで読み込み、Merkle メンバーシップ検査を融合しているためです。完全にアンロールした実装では tier 16(約 400 秒、21 GB)が必要になり、16 GB のマシンのメモリを超えます。
ソース: docs/superpowers/specs/2026-09-19-hidden-asset-bundle-design.md §1–3
14. なぜ手数料は公開で、プロポーザーに支払われるのか
手数料を公開にすることは公開のステーク登録簿と整合的であり、受け付けのコストも低く抑えられます。ノードは検証を一切行う前に、手数料の下限を確認できるからです。バンドル証明は残高の等式 Σ inputs = Σ outputs + fee + burn を強制します。そのため手数料は、どのノートかを明かすことなく、非公開のノートから支払われます。許容されているコストは、手数料の額から取引の種類(転送かプログラム呼び出しか)が分かりうる点です。
ソース: docs/superpowers/specs/2026-09-11-shielded-pool-design.md(裁定表)、docs/fees.md §1
15. なぜデポジット(mint、bridge attest)の金額は公開なのか
プールに入る価値は公開で会計処理されなければなりません。また、bridge attestation は、移転元チェーンで対応するロックが行われたことの公開された証拠です。これによる可視性は入口の段階に限られます。Zcash における透明からシールドへの(t-to-z)取引に相当します。預け入れられたノートのその後の支出は秘匿されます。
ソース: docs/superpowers/specs/2026-09-11-shielded-pool-design.md、docs/shielded.md(公開される情報の表)
16. なぜメモは 512 バイト固定のフィールドなのか
固定長のフィールドにより、メモの有無や長さが台帳から分からなくなります。メモに対応したチェーンでは、ダミーやおつりを含め、ノートを作成するすべてのエンベロープがちょうど 1,860 バイトになります。メモは暗号化されたエンベロープの内部でのみ運ばれ、ノート、コミットメント、証明には含まれません。メモを読めるのは、すでにそのノートを復号できる当事者に限られます。不正な形式のメモは空のメモとして復号されるため、ノート自体が回復不能になることはありません。
ソース: docs/shielded.md §2、docs/superpowers/specs/2026-09-26-address-sharing-and-memo-design.md
17. なぜ証明はローカルで行われるのか、また委任プルーバーはそれをどう損なわないのか
証明そのものが支出の承認です。バンドルには署名も送信者フィールドもないため、支出鍵がウォレットの外に出る必要はありません。tier 14 のバンドル証明には約 5.7 GB のメモリが必要で、スマートフォンやブラウザが提供できる量を超えます。委任プルーバーはそのために存在します。分割承認(バンドルゲスト v3、ジェネシスパラメータ hc_auth)は二つの役割を分離します。プルーバーが受け取るのはビューイングキー nk だけで、バンドル証明を生成します。ウォレットは sk を用いて、小さな tier 10 の承認証明を生成します。したがって、プルーバーはバンドル証明を構築できても、支出を承認することはできません(質問 36)。
ソース: docs/prover.md §1、docs/shielded.md(分割承認)、docs/superpowers/specs/2026-09-28-delegated-proving-design.md
18. なぜアンカーウィンドウは 256 ブロックなのか
証明は特定のコミットメントツリーのルート(そのアンカー)に対して構築され、tier 14 のバンドル証明の構築には約 100 秒かかります。そのため台帳は、提出時点で数分前のアンカーを受け入れなければなりません。当初の仕様ではウィンドウは 64 ブロックでしたが、ブロック間隔が短くなったため 256 ブロックに拡大されました。これにより、実時間でのウィンドウの長さが証明時間を上回る状態が保たれています。
ソース: docs/shielded.md、docs/superpowers/specs/2026-09-11-shielded-pool-design.md
zkVM と機密計算
19. なぜゲスト ISA に RV32I なのか(RV64 ではなく)
32 ビットのワードはちょうど四つのバイトリムに分解されます。また Goldilocks 素数 p = 2^64 − 2^32 + 1 は十分に大きく、二つの 32 ビット値の積が体からあふれることはありません。RV64 では、ALU テーブルとメモリテーブルのリム列の数が倍になります。さらに RISC-V は主要なコンパイラがすでにサポートするターゲットであり、ゲストプログラムは専用言語のプログラムではなく、通常のコンパイル済みバイナリになります。
ソース: docs/zkvm.md §2、research/docs/01-isa.md(「なぜ RV64 ではなく RV32 か」)
20. なぜ 256 ビット体ではなく Goldilocks なのか
Goldilocks は 64 ビットの素数で、その演算はネイティブな 64 ビット CPU 命令に効率よく対応します。また、その乗法群は FRI が要求する大きな 2 の冪の部分群を持ちます。32 ビットワードと組み合わせることで、トレースのすべての行が細く保たれ、ラップトップ上で本番プロファイルの証明が実現可能になります。小さな体で計算することで失われる健全性は、FRI のチャレンジを拡大体から選ぶことで補われます。
ソース: docs/zkvm.md §2、randprotocol.org(パフォーマンスのセクション)
21. なぜオペコードごとのガス計量ではなくガス tier なのか
オペコードごとのガスが Ethereum に存在するのは、すべてのノードがすべてのトランザクションを再実行し、実行の長さが事前に有界でないからです。Rand ではどのノードもプログラムを実行しません。送信者がオフチェーンで一度だけ実行し、ノードは単一の STARK を検証します。その検証コストは、実行された計算ではなく tier のみに依存します。終了性は tier によって強制されます。2^t サイクル以内に停止しない実行は、tier t では証明を持ちえないからです。価格設定は固定の下限に、ヘッダーで上限が定められたガス見積もりを加えたものであり、ブロック容量はバイト予算です。ガスが現れるのは EVM と sBPF インタープリタのゲストの内部だけで、非公開の状態として、移転元チェーンのセマンティクスを再現するために必要な場合に限られます。
ソース: docs/fees.md §3–4、docs/superpowers/specs/2026-09-28-gas-model-design.md
22. なぜトレースは LogUp バスで結ばれた九つのテーブルに分割されるのか
単一の巨大なテーブルでは、すべての行が最も幅の広い演算の幅に合わせてパディングされます。トレースを九つのテーブル(CPU、メモリ、ALU、レンジ、ニブル、Poseidon2、プログラム、入力、公開)に分け、それぞれを自身の高さまでだけパディングすることで、トレース全体は小さく保たれます。テーブル間の多重集合の関係は LogUp 引数によって確立されます。Keccak と SHA-256 のテーブルは任意であり、ゲストが対応するシステムコールを呼び出す場合にのみ含まれます。
ソース: docs/zkvm.md §5
23. なぜプログラム呼び出しは出力ワードを八つしか公開しないのか
プログラム呼び出しとは、公開されたコードが非公開の入力に対して正しく実行されたことの証明であり、台帳が記録するのはレシートだけです。32 ビットワード八つあれば、結果、コミットメント、判断を束縛するのに十分です。また出力サイズが固定であるため、レシートの形からプログラムについて何も分かりません。現時点では出力はデータのみで、プログラム自身が価値を転送することはできません。
ソース: randprotocol.org/usecases(プラットフォームに関する注記)、docs/confidential.md
24. なぜ呼び出し入力エンベロープがあるのか
非公開の入力を保持している呼び出し元は、後から、その呼び出しが何に対して計算されたかを示すことができます。呼び出し入力エンベロープは、入力を暗号化して呼び出しとともに保存することでこれを永続的にし、指定された監査人が鍵で復号できるようにします。これにより選択的開示(市場に対しては機密、指定された規制当局に対しては開示)が、支払いからプログラムの実行へと拡張されます。
ソース: docs/confidential.md(「呼び出し入力エンベロープ」)
25. なぜ制約セットの変更はハードフォークなのか
すべてのノードは同期中にすべての証明を再検証し、証明は、それが生成された制約セット(AIR)に対してのみ有効です。したがって AIR を変更すると有効なチェーンの集合が変わるため、ノードごとに採用されるのではなく、ジェネシスの切り替え時に導入されます。
ソース: docs/architecture.md(「なぜ制約セットの変更はハードフォークなのか」)
26. なぜ AIR ではなくエミュレータが基準なのか
エミュレータはマシンの可読な仕様であり、AIR はその仕様を多項式制約として符号化したものです。両者が食い違う場合、AIR が誤っていると定義されます。これにより、規範的な定義は、人間が監査するのに最も現実的な成果物に置かれます。
ソース: docs/zkvm.md §5
コンセンサスとノード
27. なぜチェーン型 HotStuff BFT なのか
チェーン型 HotStuff は決定的ファイナリティを提供します。ステーク加重で三分の二を超えるクォーラムの下では、あるブロックの上に連続する三つのクォーラム証明書が形成された時点でそのブロックはファイナルとなり、ファイナルなブロックが再編成されることはありません。測定されたブロック間隔は 1.2 秒、ファイナリティまでの時間は約 3.6 秒です。想定している機関ユーザーは、仕訳を記録できる決済ファイナリティを必要としますが、確率的ファイナリティのチェーンはこれを提供しません。
ソース: fullnode README、randprotocol.org(パフォーマンスのセクション)、docs/architecture.md §6
28. なぜ証明の検証はコンセンサスのループの外にあるのか
ノードは、トランザクションを受け付ける時点で(ウォーム時に約 32 ms)、リレーする前に各 STARK を検証します。したがって検証がブロック提案のクリティカルパスに入ることはありません。ブロック間隔は、証明のサイズではなくコンセンサスのレイテンシによって決まります。検査はコストの順に並べられ、STARK の検証は最後に行われます。これにより、不正な形式のトランザクションは、最も高価なステップの前に拒否されます。
ソース: randprotocol.org、docs/architecture.md(「仕組み」)
29. なぜほかのすべてがシールドされているのに、バリデータ登録簿は公開なのか
すべてのレプリカは、どのバリデータが提案でき、どの投票がクォーラムを構成するかについて合意しなければならず、そのためにはステークの重みが公開されている必要があります。したがって登録簿はステーク額を平文で保持します。所有者との結び付きは秘匿されたままです。ボンドはシールドされたノートから拠出され、引き出しはシールドされたノートに支払われます。いずれの操作も、それが誰のノートであるかを明かしません。
ソース: docs/staking.md §1
30. なぜ同期中のノードは、証明書を信頼せずにすべてのブロックを再実行するのですか?
遅れて参加したノードは、チェーンを受け入れる前に、すべての quorum certificate(クォーラム証明書)を検証し、すべてのバンドル証明とコール証明を再検証し、得られたレシートを突き合わせます。有効性は署名だけでなく証明によって確立されるため、この手順は、署名のみで保護されるチェーンが受けるロングレンジ攻撃の影響を受けません。履歴から証明を削除する案は、この保証が失われるため採用されませんでした。
出典: docs/architecture.md、docs/aggregation.md(冒頭)
31. 証明が 1 MB を超えるのに、なぜブロック上限を 4 MiB に保つのですか?
上限を固定すると、ブロックサイズは増大しません。需要が容量を超えた場合には、代わりにスループットが制限されます(80 クエリのプロファイルでは 1 ブロックあたり 3 件のシールド転送)。スループットの制限は、ブロックの無制限な肥大化よりも安全な障害モードであると判断されました。採用された対策は、上限の引き上げやソundness レベルの引き下げではなく、ブロック単位のアグリゲーション、すなわちブロックごとに 1 つの再帰証明を生成する方式です。
出典: docs/block-space.md §1、§6
32. なぜ testnet は履歴を 1 日分に剪定するのですか?
18 個の Dilithium2 署名を含む quorum certificate は約 44 KB で、1 ブロックにつき 2 回保存されます。1.4 秒ごとにほとんど空のブロックが生成される状況では、ノード 1 台あたり 1 日で約 6.6 GB に達しました。ノードのディスクが満杯になり、チェーンは高さ 248,953 でクォーラムを失いました。現在、testnet のフルノードは 1 日分の履歴を保持し、アーカイブノード 1 台がすべてを保持します。mainnet のノードはすべてを保持する予定です。台帳の状態(ツリー、ナリファイア集合、レジスタ、プログラム)が剪定されることはありません。
出典: docs/superpowers/specs/2026-09-24-history-pruning-design.md
33. なぜ libp2p なのですか?
ノードは、Noise と Yamux を用いた TCP、トランザクションと投票のための gossipsub、ブートストラップリストを用いたピア探索のための Kademlia、ローカルネットワーク向けの mDNS、ブロック同期のためのリクエスト・レスポンスを使用します。これらは標準的で広く展開されているコンポーネントであるため、ノードは独自の実装を保守することなく、ピアのスコアリング、再接続、トランスポートのアップグレードを引き継げます。
出典: fullnode README(ネットワーキングの行)
証明市場とアグリゲーション
34. なぜブロック単位の証明アグリゲーションなのですか?
各バンドルが約 1.3 MB の独自の証明を持つ場合、ブロック領域はバンドル数に比例して増加します。N 個すべてのバンドル証明を検証する再帰的な STARK をブロックごとに 1 つ用いれば、オンチェーンの証明コストは N に依存せず一定に保たれます。バリデータは CPU 上で 1 つのアグリゲート証明(ウォーム時で約 16 ms)を検証するだけで済むため、汎用ハードウェアでも検証を続けられます。一方、GPU を持つアグリゲータは、手数料の証明分とブロック補助金を得るために、別個のパーミッションレス市場で競争します。
出典: docs/aggregation.md §1
35. なぜバリデータ、アグリゲータ、委任プルーバーの 3 つの役割なのですか?
3 つの役割は、必要なハードウェアが異なり、報酬を支払う主体も異なります。バリデータは CPU 上でトランザクションの順序付けと検証を行い、手数料の検証分から報酬を受け取ります。アグリゲータは GPU 上で再帰的なブロック証明を生成し、証明分と補助金から報酬を受け取ります。委任プルーバーは、自身の端末では証明を生成できない送信者(スマートフォンやブラウザ)のために単一のバンドル証明を生成し、その送信者から非公開で報酬を受け取ります。役割を分離することで、検証のコストが低く抑えられ、証明生成には競争が生まれます。
出典: docs/prover.md §1
36. なぜ委任プルーバーは資金を盗めないのですか?
分割承認(split authorisation)では、プルーバーはビューイングキー nk を受け取りますが、支出鍵 sk は受け取りません。バンドル証明は c = H(AUTH, nk || salt) にコミットし、ウォレットが別に生成する承認証明は、同じ c に対する sk の知識を示します。sk がなければ、プルーバーはバンドル証明を計算できても有効な承認を作成できません。また、ウォレットは返された証明を送信前に検証します。
出典: docs/shielded.md(分割承認)、docs/prover.md §8
ブリッジと zUSD
37. なぜ新しいステーブルコインを発行せず、USDT/USDC を元のチェーン上でロックするのですか?
Rand 上でのネイティブ発行では、準備金の容量が発行体の展開判断に左右されることになり、それはプロジェクトの管理外です。USDT と USDC を Ethereum、BSC、Tron、Solana 上でロックすれば、これらの資産がすでに流通しているチェーンから準備金を調達でき、新たな発行体も生じません。zUSD の各単位は、誰でも読み取れるカストディコントラクトに保管された USDT または USDC に対する請求権です。
出典: randprotocol.org(準備金の節)
38. なぜ t-of-n のガーディアン集合なのか、そしてなぜそれを率直に述べるのですか?
アテステーションは、別のチェーンでロックが行われたことを Rand が知るための唯一の証拠であるため、閾値を満たすグループによる署名が必要です。有効なアテステーションには、ガーディアンの 3 分の 2 を超える署名が求められます。その結果生じる信頼の前提は、明示されています。実効的な保証は、準備金の支払能力とブリッジの完全性のうち弱いほうに等しくなります。t 人のガーディアンの連合は、対応するロックがなくてもミントを承認できます。そのエクスポージャーは、各チェーンに保管されたカストディの額で上限が決まります。この前提は、もともとブリッジを構築しないことの論拠でした。それは撤回されたのではなく、準備金の容量と引き換えに受け入れられたものです。
出典: randprotocol.org(準備金の節、「これが負担するコスト」)
39. なぜ ECDSA アテステーションに加えて Dilithium2 の共同署名を付けるのですか?
ソースチェーンには格子署名の検証器がないため、それらのチェーン上でのリリースは従来型の ECDSA による保護にとどまり、エクスポージャーはカストディの額と上限で制限されます。Rand の台帳がガーディアンから受け入れるすべてのメッセージ(デポジットとガーディアン集合のローテーション)には、同じガーディアンによる Dilithium2 署名のクォーラムを追加で付ける必要があります。したがって、外部のエンドポイントがそうでなくても、ミントの経路は耐量子です。共同署名はアテステーションと並行して送信され、展開済みのコントラクトの変更を必要としません。
出典: docs/superpowers/specs/2026-09-19-pq-cosignature-bridge.md §1
40. なぜデポジットノートのブラインディングは選択ではなく導出されるのですか?
以前は、デポジットノートのコミットメントは、リレイヤーがアテステーションを送信するまで確定しなかったため、2 つのリレイヤーが同じアテステーションを異なるノートで送信できました。ブラインディング係数 r をアテステーションから決定的に導出することでコミットメントが固定され、競合する送信は 1 つのコミットメントに集約されるので、デポジットが二重にミントされることはありません。
出典: docs/bridge.md(F1、chain 14)
41. なぜ Tron 上でロックされた USDT を Ethereum 上の USDT として引き出せるのですか?
zUSD は代替可能です。各単位は、それが入ってきたチェーンではなく、準備金全体に対する請求権です。入口と出口を切り離すことで、宛先チェーンが十分な準備金を保有している限り、流動性は需要のある場所へ移動できます。ステーブルコインの論文は、不変条件 S ≤ Σ_c R_c、すなわち総供給量がチェーンごとの準備金の合計で上限づけられることが、あらゆる状態遷移で保たれることを証明しています。
出典: randprotocol.org(準備金の節)
42. なぜシールドは分布を隠すのに数量は隠さないのですか?
zUSD の総供給量はトークンレジストリで公開されており、各チェーンの準備金は公開残高であるため、誰でも支払能力を検証できます。隠されるのは、保有者間での保有の分布です。ただし 1 つ制約があります。4 つの準備金残高を、ある一時点で原子的に観測することはできないため、これらのチェーンでは、このチェックは支払不能を未然に防ぐのではなく、事後に検出します。
出典: randprotocol.org(準備金の節)
43. なぜバーンは資産を指定する唯一のトランザクションなのですか?
バーンは特定のチェーン上の特定の資産を解放するため、カストディコントラクトはどの資産とどのチェーンかを知る必要があります。ほかのすべてのトランザクションは、識別されない資産を転送します。また、バーンはブリッジ手数料も負担します。バーンは、送信者が受益者でもある唯一のブリッジトランザクションだからです。
出典: docs/architecture.md、docs/shielded.md §2
コンプライアンスと開示
44. なぜ「全員に対して秘匿」ではなく、ビューイングキーなのですか?
規制当局は、Tornado Cash の事例が示すように、開示が調査対象の当事者の協力に依存するプライバシーシステムを認めていません。そのため Rand は、開示をプロトコルのオブジェクトとして扱います。保有者または規制対象の仲介者がビューイングキーを保持し、監査人は適法な要請で指定されたトランザクションを復号でき、設計上の目標は、取引戦略を明かさずに取引相手と金額を開示するスコープ付きの鍵です。給与支払いのような用途では、この監査可能性は制約ではなく要件です。
出典: randprotocol.org/usecases(規制の節、給与支払いの事例)
45. なぜ送信用のビューイングキーは受信用と分かれているのですか?
分離することで、送信者は受取人の履歴にアクセスせずに自分が支払った内容を証明でき、その逆も可能になります。送信用ビューイングキー ovk はウォレットが送信したエンベロープを復号し、ML-KEM のデカプセル化鍵は自分宛てに送られたエンベロープを復号します。トランザクションごとの鍵は、ちょうど 1 つの出力を第三者に開示します。
出典: docs/shielded.md §1–2
既知の制約
46. 現在、証明は何を漏らしており、なぜそれが文書化されているのですか?
2026-09-27 のレビューにより、v1 ゲスト(chain 14–15)では、各バンドル証明が、どの入力スロットが実際のノートを保持しているか、および各支出済みリーフのインデックスのハミング重みを明らかにすることが判明しました。原因は 2 つあります。テーブルごとの LogUp の合計がブラインディングなしで公開されること、そしてゲストの制御フローが入力がダミーかどうかで分岐することです。対策は、次のジェネシスで選択される、分岐のないゲスト(v2)です。この発見が公開されているのは、ネットワークが testnet であり、文書がその監査記録の役割を果たしているためです。
出典: docs/shielded.md(「現在、証明は何を漏らしているか」)
47. なぜ状態の増大は過小に価格付けされているのですか?
Ethereum は、保存された状態がすべてのノードに恒久的なコストを課すため、ストレージへの書き込みに価格を付けています。現在の Rand では、コミットメントツリー、ナリファイア集合、プログラムストレージの増加に対する価格付けは、ワードごとのデプロイ手数料と定額のバンドル手数料のみです。これはテストネットには十分ですが、mainnet 前に解決すべき未解決の価格設定の課題として記録されています。その解決にオペコードごとの計量は必要ありません。
出典: docs/fees.md §3 (caveats)
48. 独立した監査がまだ完了していないのはなぜですか?
このプロトコルは、チームが運用する testnet 上で活発に開発されており、設計が安定するまでに、さらなる制約セットとチェーンのカットが見込まれます。ウェブサイトはすべてのページでこのことを明記しています。内部監査ラウンド(v3〜v5)は docs/consensus.md と設計仕様書で公開されており、将来の外部監査が参照できる完全な記録を残しています。
出典: randprotocol.org (footer); docs/consensus.md