密碼學

使用本頁，可在與鏈互通時揀選合適的函式庫，對照節點實際強制執行的參數，並自行重新計算 id 或承諾。此處每一個數值，均為 chain 21（fullnode v0.8.0，標籤 c0878c3f，自 2026-10-12 起上線）上的程式碼所運行的數值；凡 chain 21 更改了某個數值之處，chain 20 的舊值會並列保留。

密碼學原語及其用途

白皮書的目標參數在若干方面有別於實現實際運行的參數（例如白皮書的 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 鏈上通過驗證，即使守護者密鑰被重用亦然。在 chain 20 及 chain 21 上，M 仍然只綁定 chain id：這是 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）。抗量子簽署者不必與 ECDSA 簽署者相同；兩個法定人數各自獨立計算。該欄位位於交易綁定之內，故不能在副本上被剝除或替換。

抗量子集為創世的 bridge.pq_guardians：chain 21 上為八把 1,312 字節的密鑰，與 chain 15 至 20 相同，與創世 ECDSA 集（守護者集 1）按索引對齊（chain 14 為六把，與集 0 對齊）。ECDSA 守護者集的輪換從不移動它。在 chain 14 上，它在鏈的整個生命週期內固定不變；自 chain 15 起，創世帶有橋的 rules_v2 群組，據此抗量子法定人數可以替換整個抗量子集（RotatePqGuardians）或暫停密鑰（RotatePauseKey），各自須按橋的 rotation_nonce 進行。Chain 20 的創世新增 bridge.rotation，chain 21 沿用：輪換必須為 V2 操作，並帶有每把新密鑰就同一訊息所作的 Dilithium2 簽名（持有證明），且於送達一日後生效，除非當前暫停密鑰將其取消（Bridge）。rand_getBridgeState 提供這些密鑰，而解碼後的 bridge_attest 會列出 pq_signers，即已簽署的索引。同一抗量子法定人數亦授權橋的治理訊息，每則均為固定的大端序佈局，載有 chain id 及一個 nonce。自 chain 20 起（創世 binding_domain: 1），各域的版本數字為 2，而 32 字節的創世雜湊位於域與 chain id 之間；chain 14 至 19 則使用 -1 形式：

生產環境中的 STARK

zkVM 處於約束集 9（chain 21；chain 18 至 20 運行集 8）：九個必備表（program、cpu、memory、alu、range、nibble、poseidon2、input、public），另加 keccak、sha256 及自集 9 起的 modq 表，這三個表僅在其客戶程式調用了對應系統調用時，證明才會攜帶；各表以匯流排連接，並作為一個批量 STARK 一併證明。modq 表即 MODQ 晶片：每次 MODQ 系統調用佔一個 1,024 行的區塊（對 256 係數多項式在 Dilithium 的 q = 8,380,417 之下進行 NTT、逆 NTT、點積或乘減運算），於證明標頭中以 modq_log_height 聲明，僅由多重簽名授權客戶程式攜帶，亦是 chain 21 上每把驗證密鑰及證明編碼均須變動的原因（cpu 表增加了該系統調用的欄位）。自約束集 7 起，每個已聲明的表至少有 2⁷ 行，且每個表的 LogUp 終值均經第十七條匯流排 BLIND 盲化。證明的公開介面為 35 個域元素（pv::NUM）：入口 pc、層級、八個輸出字、程式摘要 hc（8 個字）、加鹽的私有輸入承諾 H_IN（8 個）、未加鹽的公開段摘要 H_PUB（8 個），以及自約束集 8 起的已聲明 gas 上限 GAS_LIMIT。

約束集 6 的實測大小（Apple Silicon，release 構建）：不含 keccak 的正式環境證明在層級 10 為 1,298,729 位元組，在層級 12 為 1,359,978 位元組；含 keccak 的層級 10 證明為 3,198,430 位元組，超出 2 MiB 的預設值，但低於 chains 13 至 15 的 8 MiB。已淘汰的 2-in-2-out 捆綁 guest 的層級 14 證明，在 chain 8 上實測為 1,321,773 位元組，在 chain 13 上為 1,418,406 至 1,420,423 位元組。Chain 14 的 4-in-4-out 隱藏資產捆綁 guest 維持在層級 14，且不使用任何哈希表，其證明在 chain 14 上實測為 1,422,116 及 1,423,170 位元組（2026-09-20）；chain 15 固定使用同一 guest（hc_bundle 不變）；當時捆綁證明聲明 public_log_height 為 4，即八個綁定字的高度，節點在建立 verifier key 之前會拒絕任何其他數值。2026-09-19 在 chain 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 的隱藏資產捆綁證明為 1,498,821（guest v1）及 1,497,156（guest v2）。自此捆綁證明聲明 public_log_height 為 7。約束集 8 增加不足 1%。2026-09-30 在 chain 18 上的實測（Apple Silicon）：認證證明為 1,364,940 至 1,375,371 位元組（層級 10），捆綁證明為 1,494,151 至 1,504,260 位元組（層級 14，guest v3），調用證明則在層級 14 不含哈希表時為 1,498,589 位元組，含 SHA-256 表時為 1,911,152 位元組，在層級 12 含 Keccak 表時為 3,346,865 位元組。全部均在 chains 18 至 20 的 4 MiB 上限之內。

在 verifier key 已預熱的情況下，驗證約需 16 ms；首次建立某個 (tier, heights) 的 key 則約需 230 ms。test FRI 設定檔（16 次查詢）僅供測試套件使用，並不安全；chain 21 的創世區塊固定使用 production，一如 chain 20。Fullnode v0.6.8 並無更改任何約束：chain 20 固定使用與 chains 17 至 19 相同的 hc_bundle 及 hc_auth。Fullnode v0.8.0（chain 21）保留這兩個摘要值 —— hc_bundle 60af094a…6e3fce、hc_auth 1e4e347f…5639c1 —— 並新增第三個摘要值 hc_auth_multisig 9705f8e2f1bc8561848b29cb8efd57c37e3e39788fa58a5f03304d8019668247，即層級 18 的多重簽名認證 guest（在電路內檢查 16 個 Dilithium2 簽名中的至多 3 個；其固定的 verifier key msauth-vk-production.bin，23,754 位元組，SHA-256 68facb06…cd30，由每個 validator 於啟動時載入）；在約束集 9 之下，雖然摘要值不變，每個 verifier key 均為全新。

可重現的哈希構造

附帶域的 BLAKE3：blake3(domain || data)，域字串與資料之間不加分隔符。

綁定域。 Chain 20 的創世區塊設定了 binding_domain: 1（fullnode v0.6.8，審計 v6 BIND-1），chain 21 沿用此設定。在這樣的鏈上，每一個原本只綁定 chain id 的證明綁定與已簽署的操作訊息，現在也會綁定創世哈希：域的版本號加一，而 32 位元組的創世哈希置於原像之首，排在 chain id 之前。如此，為某一條鏈製作的證明或簽名，無法在任何其他鏈上通過驗證，即使該鏈沿用相同的 chain id 與密鑰（如重新切鏈時）亦然。綁定字是證明的公開輸入，因此沒有任何 guest 或 verifier key 更改。該表列出兩種形式；chains 14 至 19 逐位元組使用第一種。先前已綁定創世區塊且不變的有：投票與提案（自 consensus_domain: 1 起）、v2 Registration，以及 AdmitValidator 投票。不更動的有：bridge 的鑄造聯署簽名（見上文）。錢包須使用 v0.6.8 才能在 chain 20 上發送，須使用 v0.8.0 才能在 chain 21 上發送，並按 chain id 而非節點的聲稱來決定採用何種形式；rand_getLimits.binding_domain 會報告此值。

帶域標籤的 Poseidon2:H(domain, msg) = sponge_hash([domain, msg...]),標籤為首個被吸收的字,每個字為一個 Goldilocks 元素,4 元素的摘要拆分為八個 u32 字(每個元素先低半部,後高半部)。域標籤如下:

hc、H_IN 與 H_PUB 並非普通的以消息為前綴的海綿:標頭置於容量之中,使 cpu 表中的摘要行每次置換恰好吸收四個字。請使用 vendored crate(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 為字數,並至少置換一次。它是對相同字的另一種哈希,鏈上沒有任何票據、作廢符、根或摘要使用它。

有兩點須牢記:hc 具綁定性但不具隱藏性(無鹽,因此可以確認被猜測的程式,同一程式的兩次部署亦可被關聯);而 H_IN 既具綁定性亦具隱藏性(每次證明使用全新的 128 位鹽),因此公開 H_IN 在鹽的持有者將其打開之前,不會洩露任何關於輸入的信息。

Key derivations

papers page 上的論文載有安全性論證:後量子密碼學的選擇、FRI 可靠性核算及保留 80 次查詢的原因,以及軌跡長度的上界。