本頁記錄 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,而目前未知有任何高效的量子算法可解此問題。768 參數集(NIST 第 3 類)是在安全餘裕與每個地址必須攜帶的 1,184 字節封裝密鑰之間取得的折衷。信封為 ML-KEM-768 結合 ChaCha20-Poly1305:1,348 字節,連同固定的備註欄位則為 1,860 字節。
來源:randprotocol.org(後量子部分);fullnode README;docs/shielded.md §2
2. 為何採用 Poseidon2 承諾而非 Pedersen?
Pedersen 承諾具完美隱藏性,但僅具計算綁定性,而其綁定性歸約至離散對數假設,量子對手可攻破該假設;能夠計算離散對數的對手,可將承諾打開為另一個值。由於今日發布的承諾必須在賬本的整個存續期內保持可靠及隱藏,方案必須建基於相信可抵禦量子對手的假設,實際上即雜湊函數。Poseidon2 是定義於 Goldilocks 域上、面向算術化的雜湊函數,因此在 STARK 內部求值所需的約束較少。票據承諾、深度為 32 的 Merkle 樹及作廢符均由同一雜湊函數實例化。
來源:randprotocol.org(後量子部分);docs/shielded.md §1–2
3. 為何使用兩種雜湊函數:BLAKE3 與 Poseidon2?
兩種函數針對不同的成本模型作了優化。凡雜湊必須在證明內部求值之處,均使用 Poseidon2:票據、承諾樹、作廢符及 zkVM 的內部表,因為其成本以約束數量計。凡不涉及證明、而原生吞吐量佔主導之處,則使用 BLAKE3:區塊雜湊、涵蓋樹、作廢符集合、驗證者登記冊及程序表的狀態根,以及驗證者地址(公鑰的 BLAKE3 摘要)。Poseidon2 在 CPU 上相對較慢;BLAKE3 則相對難以算術化。兩者僅用於其成本模型適用之處。
來源:fullnode README(簽名/雜湊一行);docs/architecture.md
4. 為何以 Dilithium2(ML-DSA)作驗證者簽名?
共識簽名所提供的是可更新的性質(問題 8):日後方案被攻破,雖可偽造未來的消息,但不會使已最終確認的區塊追溯失效,因此原則上可在量子對手出現之前更換方案。儘管如此,仍自創世起採用格基方案,使共識投票、橋接守護者的共同簽名及驗證者登記冊共用單一的後量子密鑰類型。節點實現的是第 3 輪的 Dilithium2 參數集(crystals-dilithium crate),與最終版的 FIPS 204 ML-DSA-44 有所不同;公鑰為 1,312 字節,簽名為 2,420 字節。
來源:docs/superpowers/specs/2026-09-19-pq-cosignature-bridge.md §2;randprotocol.org
5. 為何採用透明的 STARK(Goldilocks 上的 FRI)而非 SNARK?
此選擇源自三項要求。其一,無需可信設置:可靠性僅依賴雜湊函數的抗碰撞性,而非結構化參考字符串或配對友好曲線。其二,具合理的後量子可靠性:該論證不作離散對數或配對假設。其三,與問題 2 的基於雜湊的承諾方案相容。代價是證明大小:一個 bundle 證明約為 1.3 MB,是 Zcash 或 Monero 屏蔽交易的 300 至 600 倍。此代價已獲接受,並由區塊層級的聚合另行處理(問題 31 及 34)。
來源:randprotocol.org;docs/block-space.md §1;docs/zkvm.md
6. 為何採用 80 次查詢的 FRI 配置而非 27 次?
生產配置(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 界限不一致,依該界限,量子對手只需約 2^85 次查詢即可找到 256 位雜湊的碰撞,因此該主張已被撤回,而非加以限定。論文現按原語及角色分別陳述安全性: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. 為何所有密鑰均由單一的 256 位花費密鑰派生?
所有其他密鑰材料均為單一秘密 sk 的確定性函數:查看密鑰 nk = H(NK, sk)、擁有者欄位 pk = H(PK, nk)、作廢符 H(NF, nk, cm)、出向查看密鑰及 ML-KEM 解封裝密鑰,各自使用獨立的域分隔符。因此密鑰文件只儲存 sk,備份僅為單一數值,而從葉 0 起重新掃描整棵樹即可恢復所有票據。由於沒有可供恢復的第二份副本,錢包拒絕覆寫現有的密鑰文件。
來源:docs/shielded.md §1
12. 為何採用固定的 4 入 4 出 bundle 形態?
固定形態使每個 bundle 不論轉移何物,大小與結構均相同。每個 bundle 恰好公佈四個作廢符與四個承諾;未使用的槽位為零值的虛設票據,而找零輸出即使價值為零亦會公佈,因為缺少找零輸出會使該交易變得可區分。原始規格為 2 入 2 出,沿用 Sapling。隨著隱藏資產 bundle 的引入,規格擴闊為 4 入 4 出,令槽位 0–1 承載私有資產,槽位 2–3 承載用於支付費用的 RAND;採用四個而非三個槽位,可使代幣轉移以最多兩張 RAND 票據支付其費用。
來源:docs/shielded.md §2;docs/superpowers/specs/2026-09-19-hidden-asset-bundle-design.md §3
13. 為何一個證明即可轉移任何資產(RAND、zUSD、RPL 代幣)?
此前在 chain 14 之前，一筆代幣轉賬帶有兩個 bundle，一個用於支付 RAND 費用，另一個用於資產本身，因此需要兩個證明，並且會向任何觀察者披露轉移的是哪種代幣。隱藏資產 guest 以資產標識符作為私有輸入，因此 zUSD 轉賬與 RAND 付款無法區分。該 guest 之所以能容納於第 14 級（約 100 s 及 5.7 GB 記憶體），僅因為它以迴圈方式讀取輸入並融合了 Merkle 成員資格檢查；完全展開的實現需要第 16 級（約 400 s 及 21 GB），超出了 16 GB 機器的記憶體容量。
來源：docs/superpowers/specs/2026-09-19-hidden-asset-bundle-design.md §1–3
14. 為何費用是公開的，並支付予提議者？
公開費用與公開的權益登記冊一致，並使准入成本低廉：節點在執行任何驗證之前，即可檢查費用下限。bundle 證明強制執行平衡方程 Σ 輸入 = Σ 輸出 + 費用 + 銷毀，因此費用由隱藏票據支付，而不會披露是哪些票據。所接受的代價是，費用金額可能會顯示交易的類別（轉賬或程式調用）。
來源：docs/superpowers/specs/2026-09-11-shielded-pool-design.md（裁決表）；docs/fees.md §1
15. 為何存款（鑄造、橋接證明）帶有公開金額？
進入屏蔽池的價值必須公開入賬，而橋接證明是來源鏈上發生了相應鎖定的公開證據。由此產生的可見性僅限於進入這一步，類似於 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. 為何證明在本地生成，而委託證明者又為何不會破壞這一點？
證明本身即是花費授權：bundle 不帶簽名，也沒有發送者欄位，因此花費密鑰無須離開錢包。第 14 級的 bundle 證明需要約 5.7 GB 記憶體，超出手機及瀏覽器所能提供的容量，因此設有委託證明者。拆分授權（bundle guest v3，創世參數 hc_auth）將兩個角色分開：證明者僅接收查看密鑰 nk 並生成 bundle 證明，而錢包則使用 sk 生成一個小型的第 10 級授權證明。因此，證明者能夠構造 bundle 證明，卻無法授權花費（問題 36）。
來源：docs/prover.md §1；docs/shielded.md（拆分授權）；docs/superpowers/specs/2026-09-28-delegated-proving-design.md
18. 為何錨點窗口為 256 個區塊？
證明是針對某個特定的承諾樹根（其錨點）構造的，而構造第 14 級的 bundle 證明約需 100 s。因此，賬本必須接受在提交時已有數分鐘之久的錨點。該窗口在原始規格中為 64 個區塊，隨著區塊間隔縮短而擴大至 256 個區塊，使其以實際時間計算的長度保持在證明時間之上。
來源：docs/shielded.md；docs/superpowers/specs/2026-09-11-shielded-pool-design.md
zkVM 與機密計算
19. 為何以 RV32I 作為 guest 指令集架構（而非 RV64）？
32 位元字恰好分解為四個字節肢體，而 Goldilocks 素數 p = 2^64 − 2^32 + 1 足夠大，使兩個 32 位元值的乘積不會溢出該域。RV64 會使 ALU 及記憶體表中的肢體列數目加倍。RISC-V 亦是主流編譯器現有的目標平台，因此 guest 程式是普通的編譯後二進位檔，而非以專門設計的語言編寫的程式。
來源：docs/zkvm.md §2；research/docs/01-isa.md（「為何選 RV32，而非 RV64」）
20. 為何採用 Goldilocks，而非 256 位元域？
Goldilocks 是一個 64 位元素數，其算術可高效映射至原生的 64 位元 CPU 指令，而且其乘法群具有 FRI 所需的大型二的冪子群。配合 32 位元字，它使每一條軌跡行保持狹窄，令生產配置下的證明在筆記型電腦上也切實可行。在小域上運算所損失的可靠性，則透過從擴展域中抽取 FRI 挑戰來彌補。
來源：docs/zkvm.md §2；randprotocol.org（效能章節）
21. 為何採用 gas 級別，而非逐操作碼的 gas 計量？
逐操作碼的 gas 之所以存在於 Ethereum，是因為每個節點都重新執行每一筆交易，而且執行長度無法事先設定上限。在 Rand 中，沒有任何節點執行程式：發送者在鏈下執行一次，節點則驗證單一 STARK，其驗證成本只取決於級別，而與所執行的計算無關。終止性由級別強制保證，因為若一次執行未能在 2^t 個週期內停機，則在第 t 級不存在任何證明。定價為固定下限加上受標頭約束的 gas 估算，區塊容量則是以字節計的預算。gas 僅出現在 EVM 及 sBPF 解釋器 guest 之內，作為私有狀態，用以重現來源鏈的語義。
來源：docs/fees.md §3–4；docs/superpowers/specs/2026-09-28-gas-model-design.md
22. 為何將軌跡拆分為由 LogUp 匯流排連接的九張表？
單一的整體表會把每一行都填充至最寬操作的寬度。將軌跡拆分為九張表，即 CPU、記憶體、ALU、範圍、半字節、Poseidon2、程式、輸入及公開表，各表只填充至自身的高度，從而使軌跡總量保持精簡。LogUp 論證確立各表之間的多重集關係。Keccak 及 SHA-256 表為可選項，僅在 guest 調用相應的系統調用時才會包含。
來源：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 s，最終性時間約為 3.6 s。預期的機構用戶需要結算最終性，以便據以記賬，而具概率性最終性的鏈無法提供這一點。
來源：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），重新驗證每個捆綁（bundle）及調用證明，並在接受該鏈之前比對所得的收據。由於有效性由證明確立，而非僅憑簽名，此程序不會受到影響僅以簽名作保障的區塊鏈的長程攻擊。由於剪除歷史中的證明會削弱此項保證，因此該方案已被否決。
Source: docs/architecture.md; docs/aggregation.md (introduction)
31. 為何在證明超過 1 MB 時仍將區塊上限維持在 4 MiB？
在上限固定的情況下，區塊大小無法增長；當需求超出容量時，改為限制吞吐量（在 80 次查詢的配置下，每個區塊三筆屏蔽轉賬）。吞吐量受限被認為比區塊無限增長更安全的失效模式。所選的補救方法是區塊層級聚合，即每個區塊一個遞歸證明，而非提高上限或降低安全性等級。
Source: docs/block-space.md §1, §6
32. 為何測試網將歷史剪除至一日？
一份載有 18 個 Dilithium2 簽名的法定人數證書約為 44 KB，且每個區塊儲存兩次。在每 1.4 秒產生一個、且大多為空的區塊下，每個節點每日約累積 6.6 GB；節點磁碟已滿，鏈在區塊高度 248,953 失去法定人數。測試網全節點現時保留一日的歷史，一個存檔節點保留全部歷史，而主網節點將保留全部歷史。賬本狀態（樹、nullifier 集、登記冊及程式）則從不剪除。
Source: docs/superpowers/specs/2026-09-24-history-pruning-design.md
33. 為何採用 libp2p？
節點採用 TCP 配合 Noise 及 Yamux，以 gossipsub 傳播交易及投票，以 Kademlia 配合引導清單進行節點發現，在本地網絡使用 mDNS，並以請求－回應機制進行區塊同步。這些均為標準且廣泛部署的組件，因此節點可直接沿用節點評分、重新連接及傳輸層升級，而無須自行維護這些實現。
Source: fullnode README (networking row)
證明市場與聚合
34. 為何採用區塊層級的證明聚合？
若每個捆綁各自附帶約 1.3 MB 的證明，區塊空間會隨捆綁數量線性增長。每個區塊採用單一遞歸 STARK 以驗證全部 N 個捆綁證明，可使鏈上證明成本不隨 N 而變。驗證者（validator）隨後在 CPU 上驗證一個聚合證明（預熱後約 16 ms），因此普通硬件仍可進行驗證，而配備 GPU 的聚合者（aggregator）則在獨立的無許可市場中競爭費用中的證明份額及區塊補貼。
Source: docs/aggregation.md §1
35. 為何設三種角色：驗證者、聚合者與委託證明者？
三種角色的硬件要求不同，且由不同的對象支付報酬。驗證者在 CPU 上對交易排序及驗證，報酬來自費用中的驗證份額。聚合者在 GPU 上生成遞歸區塊證明，報酬來自證明份額及補貼。委託證明者（delegated prover）為設備無法自行生成證明的發送者（如手機或瀏覽器）生成單一捆綁證明，並由該發送者以私密方式支付。角色分立可使驗證成本維持低廉，並使證明具有競爭性。
Source: docs/prover.md §1
36. 為何委託證明者無法盜取資金？
在拆分授權（split authorisation）下，證明者取得查看密鑰 nk，但不取得花費密鑰 sk。捆綁證明承諾於 c = H(AUTH, nk || salt)，而錢包另行提供的授權證明則證明其知悉對應同一 c 的 sk。缺少 sk，證明者可計算捆綁證明，但無法產生有效的授權，且錢包在提交所返回的證明之前會先行驗證。
Source: docs/shielded.md (split authorisation); docs/prover.md §8
橋接與 zUSD
37. 為何在原生鏈上鎖定 USDT/USDC，而不是發行新的穩定幣？
若在 Rand 上原生發行，儲備容量將取決於發行方的部署決定，而這些決定並非項目所能控制。在 Ethereum、BSC、Tron 及 Solana 上鎖定 USDT 及 USDC，可從這些資產已在流通的鏈上獲取儲備，且不引入新的發行方：每一單位 zUSD 均是對存放於公開可讀的託管合約中之 USDT 或 USDC 的債權。
Source: randprotocol.org (reserve section)
38. 為何採用 t-of-n 守護者集合，並且為何要明言此點？
證明（attestation）是 Rand 所能取得的、證明鎖定已在另一條鏈上發生的唯一證據，因此必須由門檻群組簽署；有效的證明須獲得超過三分之二守護者（guardian）的簽名。由此產生的信任假設已明確說明。實際保證取決於儲備償付能力與橋接完整性兩者中較弱的一項；t 個守護者組成的聯盟可在沒有相應鎖定的情況下授權鑄造；而風險敞口則以各鏈所持有的託管資產為限。此假設原本是反對建立橋接的理由，現時並非撤回，而是為換取儲備容量而接受。
Source: randprotocol.org (reserve section, ‘What this costs’)
39. 為何在 ECDSA 證明之外加上 Dilithium2 聯署？
來源鏈並無提供格基簽名驗證器，因此這些鏈上的釋放仍以傳統 ECDSA 作保障，風險敞口以託管資產及上限為界。Rand 賬本接受來自守護者的每一則訊息（存款及守護者集合輪換），均須另附來自同一批守護者的 Dilithium2 簽名法定人數。因此，即使外部端點並非後量子，鑄造路徑仍屬後量子。聯署與證明一併傳送，無須更改已部署的合約。
Source: docs/superpowers/specs/2026-09-19-pq-cosignature-bridge.md §1
40. 為何存款 note 的盲化因子是推導而得，而非自行選取？
過往，存款 note 的承諾在中繼者提交證明之前並未確定，因此兩個中繼者可以就同一份證明提交不同的 note。由證明確定性地推導盲化因子 r，可固定該承諾，使相互競爭的提交收斂於單一承諾，存款因而不會被鑄造兩次。
Source: docs/bridge.md (F1, chain 14)
41. 為何鎖定於 Tron 的 USDT 可以 USDT 形式在 Ethereum 提取？
zUSD 具可互換性：每一單位均是對整體儲備的債權，而非對其進入時所經之鏈的債權。將進入與提取脫鉤，可使流動性流向有需求之處，前提是目的地鏈持有足夠儲備。穩定幣論文證明，不變式 S ≤ Σ_c R_c（總供應量以各鏈儲備之總和為上限）在每一次狀態轉換中均得以保持。
Source: randprotocol.org (reserve section)
42. 為何屏蔽隱藏的是分布，而非數量？
zUSD 的總供應量在代幣登記冊中公開，各鏈的儲備亦為公開餘額，因此任何人均可驗證償付能力；被隱藏的是持有量在各擁有者之間的分布。有一項限制：四條鏈的儲備餘額無法在同一時刻以原子方式觀察，因此就這些鏈而言，此項檢查是事後發現資不抵債，而非預先防止。
Source: randprotocol.org (reserve section)
43. 為何銷毀是唯一指明其資產的交易？
銷毀會在特定鏈上釋放特定資產，因此託管合約必須得知是哪項資產及哪條鏈。其他每一類交易所轉移的資產均不可識別。銷毀亦載有橋接費用，因為它是唯一發送者即受益人的橋接交易。
Source: docs/architecture.md; docs/shielded.md §2
合規與披露
44. 為何採用查看密鑰，而不是「對所有人保密」？
監管機構並不接受披露取決於被調查一方是否合作的隱私系統，Tornado Cash 一案即為例證。因此，Rand 將披露視為協議對象。持有人或受監管的中介機構保留查看密鑰；審計人員可解密合法要求中指明的交易；而設計目標是設立有範圍限定的密鑰，在披露交易對手及金額的同時，不披露交易策略。對於薪酬發放等應用，此種可審計性是一項要求，而非限制。
Source: randprotocol.org/usecases (regulation section; payroll case)
45. 為何傳出查看密鑰與傳入查看密鑰分開？
分開後，發送者可證明其已支付的內容，而無須取得收款人的歷史記錄，反之亦然。傳出查看密鑰 ovk 解密錢包已發出的信封；ML-KEM 解封裝密鑰解密發送予其的信封；而每筆交易專用的密鑰則向第三方準確披露一項輸出。
Source: docs/shielded.md §1–2
已知限制
46. 證明現時洩露甚麼資訊，為何要記錄在案？
2026-09-27 的審查發現，在 v1 guest（鏈 14–15）之下，每個捆綁證明均會揭示哪些輸入欄位持有真實 note，以及每個已花費葉索引的漢明重量（Hamming weight）。原因有兩方面：各表的 LogUp 總和在發布時未經盲化，且 guest 的控制流程會依輸入是否為虛設而分支。補救方法是無分支的 guest（v2），將於下一個創世區塊選用。發布此項發現，是因為該網絡屬測試網，而文件亦同時作為其審計記錄。
Source: docs/shielded.md (‘What the proofs leak today’)
47. 為何狀態增長的定價偏低？
Ethereum 對儲存寫入定價，是因為所儲存的狀態會對每個節點構成永久成本。Rand 目前僅透過每字部署費用及固定的交易包費用，為承諾樹、nullifier 集合及程式儲存的增長定價。這對 testnet 而言已屬足夠，但已記錄為一項待決的定價問題，須在 mainnet-beta 之前解決；其解決方案無須逐操作碼計量。
來源:docs/fees.md §3 (caveats)
48. 為何尚未完成獨立審計?
本協議正於由團隊營運的 testnet 上積極開發,在設計趨於穩定之前,預期仍會有更多約束集及鏈版本切換。本網站在每一頁均有此說明。內部審計輪次(v3–v5)已公佈於 docs/consensus.md 及各項設計規格,以便日後的外部審計有完整紀錄可依。
來源:randprotocol.org (footer);docs/consensus.md