यह पृष्ठ Rand के प्रत्येक प्रमुख डिज़ाइन निर्णय का आधार दर्ज करता है: घटक को कौन-सा गुण प्रदान करना है, किस धारणा के अंतर्गत वह उसे प्रदान करता है, और उसके बदले में कौन-सी लागत स्वीकार की गई है। इसे 29 September 2026 को इस साइट, श्वेतपत्र (whitepaper) के सारांश और संदर्भ फ़ुल नोड (github.com/randprotocol/fullnode: इसकी README, docs/ और docs/superpowers/specs/) से संकलित किया गया था। प्रत्येक उत्तर उस दस्तावेज़ का हवाला देता है जिसमें आधार वर्णित है; जब तक पथ randprotocol.org से आरंभ न हो, वे fullnode रिपॉज़िटरी को संदर्भित करते हैं।
स्थिति। Rand संस्थापक टीम द्वारा संचालित एक testnet पर चलता है, और प्रोटोकॉल का स्वतंत्र ऑडिट नहीं हुआ है। नीचे दिए गए कई निर्णय चेन कटों (chain cuts) में चरणबद्ध रूप से लागू किए जा रहे हैं। सभी आँकड़े संकलन के समय चल रहे नोड के मापन हैं; उनमें परिवर्तन अपेक्षित है और उद्धृत करने से पहले उन्हें पुनः मापा जाना चाहिए।
क्रिप्टोग्राफ़िक आदिम (Cryptographic primitives)
1. नोट एन्क्रिप्शन के लिए ML-KEM-768 (Kyber) क्यों?
किसी नोट का प्लेनटेक्स्ट उसके प्राप्तकर्ता के लिए एक एन्वेलप में एन्क्रिप्ट किया जाता है, जो सार्वजनिक लेजर पर अनिश्चित काल तक बना रहता है। अतः उसकी गोपनीयता एक अप्रतिसंहरणीय (irrevocable) गुण है (प्रश्न 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 (post-quantum अनुभाग); fullnode README; docs/shielded.md §2
2. Pedersen के बजाय Poseidon2 कमिटमेंट क्यों?
Pedersen कमिटमेंट पूर्णतः छिपाने वाले (perfectly hiding) हैं, किंतु केवल संगणनात्मक रूप से बाध्यकारी (computationally binding) हैं, और उनकी बाध्यता डिस्क्रीट-लघुगणक धारणा पर आधारित है, जिसे क्वांटम प्रतिद्वंद्वी तोड़ देता है; डिस्क्रीट लघुगणक की गणना कर सकने वाला प्रतिद्वंद्वी किसी कमिटमेंट को भिन्न मान के लिए खोल सकता है। चूँकि आज प्रकाशित कमिटमेंट को लेजर के पूरे जीवनकाल में सुदृढ़ (sound) और छिपाने वाला बना रहना चाहिए, इसलिए योजना ऐसी धारणाओं पर टिकी होनी चाहिए जिनके क्वांटम प्रतिद्वंद्वियों के विरुद्ध भी टिके रहने का विश्वास है, जिसका व्यवहार में अर्थ हैश फ़ंक्शन है। Poseidon2 Goldilocks फ़ील्ड पर परिभाषित एक अंकगणितीकरण-उन्मुख (arithmetisation-oriented) हैश है, इसलिए STARK के भीतर इसका मूल्यांकन कम बाधाओं (constraints) में हो जाता है। वही हैश नोट कमिटमेंट, depth-32 Merkle ट्री और nullifier को इंस्टैंशिएट करता है।
स्रोत: randprotocol.org (post-quantum अनुभाग); docs/shielded.md §1–2
3. दो हैश फ़ंक्शन — BLAKE3 और Poseidon2 — क्यों?
दोनों फ़ंक्शन भिन्न लागत-मॉडलों के लिए अनुकूलित हैं। Poseidon2 का उपयोग वहाँ होता है जहाँ हैश का मूल्यांकन प्रूफ़ के भीतर करना हो — नोट, कमिटमेंट ट्री, nullifier और zkVM की आंतरिक तालिकाएँ — क्योंकि इसकी लागत बाधाओं में मापी जाती है। BLAKE3 का उपयोग वहाँ होता है जहाँ कोई प्रूफ़ शामिल नहीं है और नेटिव थ्रूपुट प्रमुख है: ब्लॉक हैश, ट्री, nullifier सेट, वैलिडेटर रजिस्टर और प्रोग्राम तालिका पर स्टेट रूट, तथा वैलिडेटर पते (सार्वजनिक कुंजी का BLAKE3 डाइजेस्ट)। CPU पर Poseidon2 अपेक्षाकृत धीमा है; BLAKE3 का अंकगणितीकरण अपेक्षाकृत महँगा है। प्रत्येक का उपयोग केवल वहीं किया जाता है जहाँ उसका लागत-मॉडल लागू होता है।
स्रोत: fullnode README (signatures / hashes पंक्ति); docs/architecture.md
4. वैलिडेटर हस्ताक्षरों के लिए Dilithium2 (ML-DSA) क्यों?
सहमति (consensus) के हस्ताक्षर एक नवीकरणीय (renewable) गुण प्रदान करते हैं (प्रश्न 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) क्यों?
यह चयन तीन आवश्यकताओं से निकलता है। पहली, कोई विश्वसनीय सेटअप (trusted setup) नहीं: सुदृढ़ता केवल हैश फ़ंक्शन की टकराव-प्रतिरोधकता पर टिकी है, किसी संरचित संदर्भ स्ट्रिंग या पेयरिंग-अनुकूल कर्व पर नहीं। दूसरी, संभाव्य पोस्ट-क्वांटम सुदृढ़ता: यह तर्क डिस्क्रीट-लघुगणक या पेयरिंग संबंधी कोई धारणा नहीं बनाता। तीसरी, प्रश्न 2 की हैश-आधारित कमिटमेंट योजना के साथ संगतता। इसकी लागत प्रूफ़ का आकार है: एक बंडल प्रूफ़ लगभग 1.3 MB का होता है, जो Zcash या Monero के शील्डेड लेनदेन के आकार का 300–600 गुना है। यह लागत स्वीकार की गई और इसे ब्लॉक-स्तरीय एग्रीगेशन द्वारा अलग से संबोधित किया गया है (प्रश्न 31 और 34)।
स्रोत: randprotocol.org; docs/block-space.md §1; docs/zkvm.md
6. 27 के बजाय 80-क्वेरी FRI प्रोफ़ाइल क्यों?
उत्पादन प्रोफ़ाइल (80 क्वेरी, ब्लोअप फ़ैक्टर 8, 20 बिट प्रूफ़-ऑफ़-वर्क ग्राइंडिंग) लगभग 86 बिट की सिद्ध (provable) सुदृढ़ता प्रदान करती है, जबकि 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 (post-quantum अनुभाग)
8. ‘अप्रतिसंहरणीय बनाम नवीकरणीय’ वर्गीकरण क्या है और यह चुनावों को क्यों निर्धारित करता है?
कोई सुरक्षा गुण अप्रतिसंहरणीय (irrevocable) होता है यदि भविष्य में किसी भी समय नई क्षमता प्राप्त करने वाला प्रतिद्वंद्वी पहले से प्रकाशित डेटा के लिए उसका पूर्वप्रभावी उल्लंघन कर सकता है; नोट की गोपनीयता और कमिटमेंट का छिपाव इसी प्रकार के हैं, इसलिए उन्हें प्रकाशन के समय ही क्वांटम-प्रतिरोधी होना चाहिए। कोई गुण नवीकरणीय (renewable) होता है यदि वह प्रत्येक उपयोग पर पुनः स्थापित होता है, ताकि खतरे के साकार होने से पहले योजना को बदला जा सके; हस्ताक्षर और प्रूफ़ की सुदृढ़ता इसी प्रकार के हैं। इस अनुभाग में प्रत्येक आदिम का चयन इस बात से निकलता है कि वह जिस गुण की रक्षा करता है उसे किस श्रेणी में रखा गया।
स्रोत: randprotocol.org (post-quantum अनुभाग)
शील्डेड पूल (The shielded pool)
9. खातों या शेष राशियों के बिना नोट/UTXO मॉडल क्यों?
खाता-आधारित लेजर अपनी संरचना से ही शेष राशियाँ प्रकाशित करता है; उन्हें छिपाने के लिए स्टेट को एन्क्रिप्ट करना और सिफ़रटेक्स्ट पर कथनों को सिद्ध करना पड़ता है, जो काफ़ी अधिक महँगा है। नोट पूल केवल कमिटमेंट और nullifier संग्रहीत करता है, जिनमें से कोई भी स्वामी या राशि प्रकट नहीं करता, इसलिए सार्वजनिक स्टेट में शेष राशि की कोई जानकारी नहीं होती। एकमात्र अपवाद वैलिडेटर रजिस्टर है, जिसके स्टेक भार सार्वजनिक होने चाहिए ताकि प्रतिकृतियाँ (replicas) कोरम की सदस्यता पर सहमत हो सकें (प्रश्न 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), nullifier H(NF, nk, cm), आउटगोइंग व्यूइंग कुंजी और ML-KEM डिकैप्सुलेशन कुंजी, प्रत्येक अपने डोमेन सेपरेटर के अंतर्गत। इसलिए कुंजी फ़ाइल केवल sk संग्रहीत करती है, बैकअप एक ही मान है, और ट्री को लीफ़ 0 से पुनः स्कैन करने पर प्रत्येक नोट पुनः प्राप्त हो जाता है। चूँकि पुनर्प्राप्ति के लिए कोई दूसरी प्रति नहीं है, वॉलेट मौजूदा कुंजी फ़ाइल को अधिलेखित करने से इनकार करता है।
स्रोत: docs/shielded.md §1
12. निश्चित 4-इन-4-आउट बंडल आकार क्यों?
निश्चित आकार प्रत्येक बंडल को, इस बात से स्वतंत्र कि वह क्या स्थानांतरित करता है, समान आकार और संरचना का बना देता है। प्रत्येक बंडल ठीक चार nullifier और चार कमिटमेंट प्रकाशित करता है; अप्रयुक्त स्लॉट शून्य-मान वाले डमी नोट होते हैं, और चेंज आउटपुट तब भी प्रकाशित किया जाता है जब उसका मान शून्य हो, क्योंकि चेंज आउटपुट की अनुपस्थिति लेनदेन को अलग पहचानने योग्य बना देगी। मूल विनिर्देश Sapling का अनुसरण करते हुए 2-इन-2-आउट था। हिडन-एसेट बंडल के साथ इसे 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 से पहले, एक टोकन ट्रांसफ़र में दो बंडल होते थे, एक RAND शुल्क के लिए और एक परिसंपत्ति के लिए। इसके लिए दो प्रमाण चाहिए थे, और किसी भी पर्यवेक्षक को यह भी दिख जाता था कि कौन-सा टोकन स्थानांतरित हुआ। छिपी-परिसंपत्ति वाला गेस्ट परिसंपत्ति पहचानकर्ता को निजी इनपुट के रूप में लेता है, इसलिए zUSD का ट्रांसफ़र RAND के भुगतान से अलग पहचाना नहीं जा सकता। यह गेस्ट टियर 14 में (लगभग 100 s और 5.7 GB मेमोरी में) केवल इसलिए समा पाता है कि वह अपने इनपुट एक लूप में पढ़ता है और Merkle सदस्यता जाँच को उसी में समाहित (fuse) कर लेता है। पूरी तरह अनरोल्ड कार्यान्वयन के लिए टियर 16 (लगभग 400 s और 21 GB) चाहिए, जो 16 GB वाली मशीन की मेमोरी से अधिक है।
स्रोत: docs/superpowers/specs/2026-09-19-hidden-asset-bundle-design.md §1–3
14. शुल्क सार्वजनिक क्यों है और प्रस्तावक (proposer) को क्यों दिया जाता है?
सार्वजनिक शुल्क सार्वजनिक स्टेक रजिस्टर के अनुरूप है और प्रवेश को सस्ता बनाता है: कोई नोड कोई भी सत्यापन करने से पहले शुल्क की न्यूनतम सीमा जाँच सकता है। बंडल प्रमाण संतुलन समीकरण Σ इनपुट = Σ आउटपुट + शुल्क + बर्न लागू करता है, इसलिए शुल्क छिपे हुए नोट से चुकाया जाता है और यह उजागर नहीं होता कि कौन-से नोट। स्वीकार की गई लागत यह है कि शुल्क की राशि से लेन-देन का वर्ग (ट्रांसफ़र या प्रोग्राम कॉल) प्रकट हो सकता है।
स्रोत: docs/superpowers/specs/2026-09-11-shielded-pool-design.md (निर्णय तालिका); docs/fees.md §1
15. जमा (mint, bridge attest) की राशि सार्वजनिक क्यों है?
पूल में प्रवेश करने वाले मूल्य का लेखा सार्वजनिक रूप से होना चाहिए, और ब्रिज अटेस्टेशन इस बात का सार्वजनिक प्रमाण है कि स्रोत चेन पर संगत लॉक हुआ था। इससे उत्पन्न दृश्यता केवल प्रवेश चरण तक सीमित है, जो 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. प्रूफ़िंग स्थानीय क्यों है, और डेलिगेटेड प्रोवर (prover) इसे कैसे भंग नहीं करता?
प्रमाण स्वयं खर्च का प्राधिकरण है: बंडल में कोई हस्ताक्षर और कोई प्रेषक फ़ील्ड नहीं होता, इसलिए खर्च की कुंजी को वॉलेट से बाहर जाने की आवश्यकता नहीं पड़ती। टियर 14 के बंडल प्रमाण के लिए लगभग 5.7 GB मेमोरी चाहिए, जो फ़ोन और ब्राउज़र उपलब्ध नहीं करा सकते, इसलिए डेलिगेटेड प्रोवर है। विभाजित प्राधिकरण (बंडल गेस्ट v3, जेनेसिस पैरामीटर hc_auth) दोनों भूमिकाओं को अलग करता है: प्रोवर को केवल व्यूइंग की nk मिलती है और वह बंडल प्रमाण बनाता है, जबकि वॉलेट sk से एक छोटा टियर 10 प्राधिकरण प्रमाण बनाता है। इस प्रकार प्रोवर बंडल प्रमाण तो बना सकता है, किंतु खर्च को प्राधिकृत नहीं कर सकता (प्रश्न 36)।
स्रोत: docs/prover.md §1; docs/shielded.md (विभाजित प्राधिकरण); docs/superpowers/specs/2026-09-28-delegated-proving-design.md
18. एंकर विंडो 256 ब्लॉक की क्यों है?
प्रमाण किसी विशेष कमिटमेंट-ट्री रूट (उसके एंकर) के विरुद्ध बनाया जाता है, और टियर 14 का बंडल प्रमाण बनाने में लगभग 100 s लगते हैं। इसलिए लेजर को ऐसे एंकर स्वीकार करने होते हैं जो जमा करने के समय कई मिनट पुराने हों। मूल विनिर्देश में विंडो 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 (‘Why RV32, not RV64’)
20. 256-बिट फ़ील्ड के बजाय Goldilocks क्यों?
Goldilocks 64-बिट अभाज्य है जिसकी अंकगणितीय संक्रियाएँ CPU के मूल 64-बिट निर्देशों पर कुशलता से प्रतिचित्रित होती हैं, और जिसके गुणनात्मक समूह में दो की घात वाला बड़ा उपसमूह है, जैसा FRI के लिए आवश्यक है। 32-बिट शब्दों के साथ मिलकर यह ट्रेस की हर पंक्ति को संकरा रखता है, जिससे लैपटॉप पर प्रोडक्शन-प्रोफ़ाइल की प्रूफ़िंग व्यावहारिक हो जाती है। छोटे फ़ील्ड पर काम करने से जो साउंडनेस घटती है, उसकी भरपाई FRI चैलेंज को एक्सटेंशन फ़ील्ड से चुनकर की जाती है।
स्रोत: docs/zkvm.md §2; randprotocol.org (performance section)
21. प्रति-ऑपकोड गैस मीटरिंग के बजाय गैस टियर क्यों?
प्रति-ऑपकोड गैस Ethereum में इसलिए है कि हर नोड हर लेन-देन को पुनः निष्पादित करता है और निष्पादन की लंबाई पहले से सीमित नहीं होती। Rand में कोई नोड प्रोग्राम निष्पादित नहीं करता: प्रेषक उसे ऑफ़ चेन एक बार निष्पादित करता है, और नोड एक ही STARK का सत्यापन करते हैं, जिसकी सत्यापन लागत केवल टियर पर निर्भर करती है, किए गए संगणन पर नहीं। समाप्ति (termination) टियर द्वारा लागू होती है, क्योंकि जो निष्पादन 2^t चक्रों के भीतर रुकता नहीं, उसका टियर 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 (platform note); docs/confidential.md
24. कॉल-इनपुट एन्वेलप क्यों है?
जो कॉलर निजी इनपुट अपने पास रखता है, वह बाद में दिखा सकता है कि कॉल किस पर संगणित की गई थी। कॉल-इनपुट एन्वेलप इसे टिकाऊ बनाता है: इनपुट एन्क्रिप्टेड रूप में कॉल के साथ संग्रहीत होते हैं, जहाँ नामित ऑडिटर उन्हें कुंजी से डिक्रिप्ट कर सकता है। यह चयनात्मक प्रकटीकरण को, अर्थात बाज़ार के लिए गोपनीय और नामित नियामक के लिए खुला, भुगतानों से प्रोग्राम निष्पादन तक विस्तारित करता है।
स्रोत: docs/confidential.md (‘Call input envelopes’)
25. कंस्ट्रेंट-सेट में परिवर्तन हार्ड फ़ॉर्क क्यों है?
हर नोड सिंक्रनाइज़ेशन के दौरान हर प्रमाण का पुनः सत्यापन करता है, और प्रमाण केवल उसी कंस्ट्रेंट-सेट (AIR) के सापेक्ष वैध होता है जिसके अंतर्गत वह बनाया गया था। इसलिए AIR में परिवर्तन वैध चेनों के समुच्चय को बदल देता है, और उसे नोड-दर-नोड अपनाया नहीं जाता, बल्कि जेनेसिस कट पर लागू किया जाता है।
स्रोत: docs/architecture.md (‘Why a constraint-set change is a hard fork’)
26. AIR के बजाय एमुलेटर संदर्भ क्यों है?
एमुलेटर मशीन का पठनीय विनिर्देश है और AIR उस विनिर्देश का बहुपद कंस्ट्रेंट के रूप में एन्कोडिंग है। जहाँ दोनों में असहमति हो, वहाँ परिभाषा के अनुसार AIR त्रुटिपूर्ण है। इससे मानक परिभाषा उस कलाकृति में रहती है जिसकी मनुष्यों द्वारा लेखापरीक्षा सबसे व्यावहारिक है।
स्रोत: docs/zkvm.md §5
सहमति और नोड
27. चेन्ड HotStuff BFT क्यों?
चेन्ड HotStuff नियतात्मक अंतिमता (finality) प्रदान करता है: दो-तिहाई से अधिक स्टेक-भारित कोरम के साथ, ब्लॉक के ऊपर लगातार तीन कोरम प्रमाणपत्र बन जाने पर वह अंतिम हो जाता है, और अंतिम ब्लॉक का पुनर्गठन कभी नहीं होता। मापा गया ब्लॉक अंतराल 1.2 s है और अंतिमता का समय लगभग 3.6 s। अभिप्रेत संस्थागत उपयोगकर्ताओं को ऐसी निपटान अंतिमता चाहिए जिसके विरुद्ध वे प्रविष्टियाँ दर्ज कर सकें, जो संभाव्य अंतिमता वाली चेन प्रदान नहीं करती।
स्रोत: fullnode README; randprotocol.org (performance section); docs/architecture.md §6
28. प्रमाण सत्यापन सहमति लूप से बाहर क्यों है?
नोड हर STARK का सत्यापन तब करता है जब वह लेन-देन को स्वीकार करता है (गर्म अवस्था में लगभग 32 ms), उसे आगे प्रेषित करने से पहले, इसलिए सत्यापन ब्लॉक प्रस्ताव के क्रिटिकल पथ पर कभी नहीं आता। अतः ब्लॉक अंतराल प्रमाण के आकार से नहीं, बल्कि सहमति की विलंबता से निर्धारित होता है। जाँचें लागत के क्रम में रखी जाती हैं और STARK का सत्यापन अंत में होता है, ताकि विकृत लेन-देन सबसे महँगे चरण से पहले ही अस्वीकृत हो जाए।
स्रोत: randprotocol.org; docs/architecture.md (‘How it works’)
29. जब बाकी सब शील्डेड है, तो वैलिडेटर रजिस्टर सार्वजनिक क्यों है?
सभी रेप्लिका को इस पर सहमत होना होता है कि कौन-से वैलिडेटर प्रस्ताव कर सकते हैं और कौन-से वोट कोरम बनाते हैं, जिसके लिए स्टेक भार का सार्वजनिक होना आवश्यक है। इसलिए रजिस्टर में स्टेक राशियाँ स्पष्ट रूप में रहती हैं। स्वामित्व से संबंध छिपा रहता है: बॉन्ड शील्डेड नोट से वित्तपोषित होता है और निकासी का भुगतान उसी प्रकार के नोट में होता है, और कोई भी संक्रिया यह प्रकट नहीं करती कि वह नोट किसका है।
स्रोत: docs/staking.md §1
30. सिंक हो रहा नोड प्रमाणपत्रों पर भरोसा करने के बजाय हर ब्लॉक को पुनः निष्पादित क्यों करता है?
देर से जुड़ने वाला नोड चेन को स्वीकार करने से पहले प्रत्येक कोरम प्रमाणपत्र का सत्यापन करता है, प्रत्येक बंडल और कॉल प्रूफ़ का पुनः सत्यापन करता है, और परिणामी रसीदों की तुलना करता है। चूँकि वैधता केवल हस्ताक्षरों से नहीं, बल्कि प्रूफ़ों से स्थापित होती है, इसलिए यह प्रक्रिया उन लॉन्ग-रेंज अटैकों के प्रति असुरक्षित नहीं है जो केवल हस्ताक्षरों पर आधारित चेनों को प्रभावित करते हैं। इतिहास से प्रूफ़ हटाने (प्रूनिंग) का विकल्प अस्वीकार कर दिया गया, क्योंकि इससे यह गारंटी समाप्त हो जाती।
स्रोत: docs/architecture.md; docs/aggregation.md (परिचय)
31. जब एक प्रूफ़ 1 MB से बड़ा है, तब ब्लॉक सीमा 4 MiB पर क्यों रखी गई है?
निश्चित सीमा होने पर ब्लॉक का आकार बढ़ नहीं सकता; जब माँग क्षमता से अधिक हो जाती है, तो उसके बजाय थ्रूपुट सीमित होता है (80-क्वेरी प्रोफ़ाइल के अंतर्गत प्रति ब्लॉक तीन शील्डेड ट्रांसफ़र तक)। असीमित ब्लॉक वृद्धि की तुलना में थ्रूपुट की सीमा को विफलता का अधिक सुरक्षित रूप माना गया। चुना गया समाधान ब्लॉक-स्तरीय एग्रीगेशन है, यानी प्रति ब्लॉक एक रिकर्सिव प्रूफ़; सीमा बढ़ाना या साउंडनेस स्तर घटाना नहीं।
स्रोत: docs/block-space.md §1, §6
32. टेस्टनेट इतिहास को एक दिन तक ही क्यों प्रून करता है?
18 Dilithium2 हस्ताक्षरों वाला एक कोरम प्रमाणपत्र लगभग 44 KB का होता है और प्रति ब्लॉक दो बार संग्रहीत किया जाता है। प्रत्येक 1.4 s पर अधिकांशतः खाली ब्लॉकों के साथ, यह प्रति नोड प्रतिदिन लगभग 6.6 GB बैठता था; नोडों की डिस्क भर गईं, और चेन ने ऊँचाई 248,953 पर कोरम खो दिया। टेस्टनेट फ़ुल नोड अब एक दिन का इतिहास रखते हैं, एक अकेला आर्काइव नोड पूरा इतिहास रखता है, और मेननेट नोड पूरा इतिहास रखेंगे। लेजर स्टेट — ट्री, नलिफ़ायर सेट, रजिस्टर और प्रोग्राम — कभी प्रून नहीं किया जाता।
स्रोत: docs/superpowers/specs/2026-09-24-history-pruning-design.md
33. libp2p ही क्यों?
नोड Noise और Yamux के साथ TCP, लेन-देन और वोट के लिए gossipsub, पीयर खोज के लिए बूटस्ट्रैप सूची के साथ Kademlia, स्थानीय नेटवर्क पर mDNS, और ब्लॉक सिंक्रनाइज़ेशन के लिए request-response का उपयोग करता है। ये मानक और व्यापक रूप से तैनात घटक हैं, इसलिए नोड को अपने स्वयं के कार्यान्वयन बनाए रखने के बजाय पीयर स्कोरिंग, पुनः कनेक्शन और ट्रांसपोर्ट अपग्रेड विरासत में मिलते हैं।
स्रोत: fullnode README (networking row)
प्रूविंग बाज़ार और एग्रीगेशन
34. ब्लॉक-स्तरीय प्रूफ़ एग्रीगेशन क्यों?
यदि प्रत्येक बंडल अपना लगभग 1.3 MB का प्रूफ़ साथ लाए, तो ब्लॉक स्पेस बंडलों की संख्या के साथ रैखिक रूप से बढ़ता है। प्रति ब्लॉक एक रिकर्सिव STARK, जो सभी N बंडल प्रूफ़ों का सत्यापन करता है, ऑन-चेन प्रूफ़ लागत को N से स्वतंत्र रखता है। तब वैलिडेटर CPU पर एक एग्रीगेट प्रूफ़ का सत्यापन करते हैं (वार्म अवस्था में लगभग 16 ms), जिससे सामान्य हार्डवेयर भी वैलिडेशन कर सकता है, जबकि GPU वाले एग्रीगेटर शुल्क के प्रूविंग हिस्से और ब्लॉक सब्सिडी के लिए एक अलग, परमिशनलेस बाज़ार में प्रतिस्पर्धा करते हैं।
स्रोत: docs/aggregation.md §1
35. तीन भूमिकाएँ क्यों — वैलिडेटर, एग्रीगेटर, डेलिगेटेड प्रूवर?
तीनों भूमिकाओं की हार्डवेयर आवश्यकताएँ भिन्न हैं और उनका भुगतान अलग-अलग पक्ष करते हैं। वैलिडेटर CPU पर लेन-देन को क्रमबद्ध करता है और सत्यापित करता है, और उसे शुल्क के सत्यापन हिस्से से भुगतान मिलता है। एग्रीगेटर GPU पर रिकर्सिव ब्लॉक प्रूफ़ तैयार करता है, और उसे प्रूविंग हिस्से तथा सब्सिडी से भुगतान मिलता है। डेलिगेटेड प्रूवर ऐसे प्रेषक के लिए एकल बंडल प्रूफ़ तैयार करता है जिसका डिवाइस ऐसा नहीं कर सकता (फ़ोन या ब्राउज़र), और उसे वह प्रेषक निजी रूप से भुगतान करता है। भूमिकाओं को अलग रखने से वैलिडेशन सस्ता रहता है और प्रूविंग प्रतिस्पर्धी बनती है।
स्रोत: docs/prover.md §1
36. डेलिगेटेड प्रूवर धन की चोरी क्यों नहीं कर सकता?
विभाजित प्राधिकरण (split authorisation) के अंतर्गत प्रूवर को व्यू कुंजी nk मिलती है, लेकिन स्पेंड कुंजी sk नहीं। बंडल प्रूफ़ c = H(AUTH, nk || salt) के प्रति प्रतिबद्ध होता है, और वॉलेट का अलग प्राधिकरण प्रूफ़ उसी c के लिए sk का ज्ञान प्रदर्शित करता है। sk के बिना प्रूवर बंडल प्रूफ़ तो गणना कर सकता है, पर वैध प्राधिकरण नहीं बना सकता, और वॉलेट लौटाए गए प्रूफ़ को जमा करने से पहले उसका सत्यापन करता है।
स्रोत: docs/shielded.md (split authorisation); docs/prover.md §8
ब्रिज और zUSD
37. नया स्टेबलकॉइन जारी करने के बजाय USDT/USDC को उनकी मूल चेनों पर लॉक क्यों किया जाता है?
Rand पर नेटिव जारीकरण से रिज़र्व क्षमता जारीकर्ताओं के तैनाती-संबंधी निर्णयों पर निर्भर हो जाती, जो परियोजना के नियंत्रण से बाहर हैं। Ethereum, BSC, Tron और Solana पर USDT और USDC को लॉक करने से रिज़र्व उन्हीं चेनों से आते हैं जिन पर ये संपत्तियाँ पहले से प्रचलित हैं, और कोई नया जारीकर्ता नहीं जुड़ता: प्रत्येक zUSD इकाई सार्वजनिक रूप से पढ़े जा सकने वाले कस्टडी कॉन्ट्रैक्ट में रखे USDT या USDC पर एक दावा है।
स्रोत: randprotocol.org (reserve section)
38. t-of-n गार्डियन सेट क्यों, और इसे स्पष्ट रूप से क्यों कहा जाता है?
अटेस्टेशन ही वह एकमात्र प्रमाण है जो Rand के पास यह दिखाने के लिए उपलब्ध है कि किसी अन्य चेन पर लॉक हुआ, इसलिए उस पर थ्रेशोल्ड समूह के हस्ताक्षर होने चाहिए; वैध अटेस्टेशन के लिए दो तिहाई से अधिक गार्डियनों के हस्ताक्षर आवश्यक हैं। परिणामी विश्वास-धारणा स्पष्ट रूप से कही गई है। प्रभावी गारंटी रिज़र्व सॉल्वेंसी और ब्रिज की अखंडता में से कमज़ोर वाली है; t गार्डियनों का गठबंधन संगत लॉक के बिना मिंटिंग को अधिकृत कर सकता है; और जोखिम प्रत्येक चेन पर रखी कस्टडी तक सीमित है। यह धारणा मूल रूप से ब्रिज न बनाने के पक्ष में तर्क थी। इसे वापस नहीं लिया गया है, बल्कि रिज़र्व क्षमता के बदले स्वीकार किया गया है।
स्रोत: randprotocol.org (reserve section, ‘What this costs’)
39. ECDSA अटेस्टेशन के साथ Dilithium2 सह-हस्ताक्षर क्यों?
स्रोत चेनों में कोई लैटिस-हस्ताक्षर वेरिफ़ायर उपलब्ध नहीं है, इसलिए उन चेनों पर रिलीज़ पारंपरिक ECDSA से सुरक्षित रहती हैं, और जोखिम कस्टडी तथा सीमाओं से बँधा रहता है। Rand लेजर गार्डियनों से जो भी संदेश स्वीकार करता है — डिपॉज़िट और गार्डियन-सेट रोटेशन — उन सभी में उन्हीं गार्डियनों के Dilithium2 हस्ताक्षरों का कोरम अतिरिक्त रूप से होना चाहिए। इसलिए बाहरी एंडपॉइंट पोस्ट-क्वांटम न होने पर भी मिंट पथ पोस्ट-क्वांटम है। सह-हस्ताक्षर अटेस्टेशन के साथ प्रेषित किए जाते हैं और तैनात कॉन्ट्रैक्टों में किसी परिवर्तन की आवश्यकता नहीं होती।
स्रोत: docs/superpowers/specs/2026-09-19-pq-cosignature-bridge.md §1
40. डिपॉज़िट नोट का ब्लाइंडिंग चुना जाने के बजाय व्युत्पन्न क्यों किया जाता है?
पहले डिपॉज़िट नोट का कमिटमेंट तब तक निर्धारित नहीं होता था जब तक कोई रिले करने वाला अटेस्टेशन जमा न कर दे, इसलिए दो रिले करने वाले एक ही अटेस्टेशन को अलग-अलग नोटों के साथ जमा कर सकते थे। ब्लाइंडिंग फ़ैक्टर r को अटेस्टेशन से नियतात्मक रूप से व्युत्पन्न करने पर कमिटमेंट तय हो जाता है, जिससे प्रतिस्पर्धी सबमिशन एक ही कमिटमेंट पर टकराते हैं और डिपॉज़िट दो बार मिंट नहीं किया जा सकता।
स्रोत: docs/bridge.md (F1, chain 14)
41. Tron पर लॉक किया गया USDT, Ethereum पर USDT के रूप में कैसे निकल सकता है?
zUSD फ़ंजिबल है: प्रत्येक इकाई समग्र रिज़र्व पर एक दावा है, उस चेन पर नहीं जिसके माध्यम से वह प्रविष्ट हुई। प्रवेश को निकास से अलग करने पर तरलता वहाँ जा सकती है जहाँ उसकी माँग है, बशर्ते गंतव्य चेन के पास पर्याप्त रिज़र्व हों। स्टेबलकॉइन पेपर सिद्ध करता है कि अपरिवर्तनीय शर्त S ≤ Σ_c R_c, अर्थात कुल आपूर्ति प्रति-चेन रिज़र्वों के योग से अधिक नहीं, प्रत्येक स्टेट ट्रांज़िशन द्वारा सुरक्षित रहती है।
स्रोत: randprotocol.org (reserve section)
42. शील्डिंग वितरण को क्यों छिपाती है, मात्रा को क्यों नहीं?
कुल zUSD आपूर्ति टोकन रजिस्ट्री में सार्वजनिक है और प्रत्येक चेन का रिज़र्व एक सार्वजनिक बैलेंस है, इसलिए सॉल्वेंसी का सत्यापन कोई भी कर सकता है; जो छिपा है वह स्वामियों के बीच होल्डिंग का वितरण है। एक सीमा लागू होती है: चारों रिज़र्व बैलेंस को किसी एक क्षण पर परमाणु रूप से नहीं देखा जा सकता, इसलिए उन चेनों के लिए यह जाँच इन्सॉल्वेंसी को रोकने के बजाय घटना के बाद पकड़ती है।
स्रोत: randprotocol.org (reserve section)
43. बर्न ही वह एकमात्र लेन-देन क्यों है जो अपनी संपत्ति का नाम बताता है?
बर्न किसी विशिष्ट चेन पर एक विशिष्ट संपत्ति जारी करता है, इसलिए कस्टडी कॉन्ट्रैक्ट को पता होना चाहिए कि कौन-सी संपत्ति और कौन-सी चेन। अन्य प्रत्येक लेन-देन एक अपरिचित संपत्ति स्थानांतरित करता है। बर्न ब्रिज शुल्क भी वहन करता है, क्योंकि यही एकमात्र ब्रिज लेन-देन है जिसका प्रेषक ही लाभार्थी है।
स्रोत: docs/architecture.md; docs/shielded.md §2
अनुपालन और प्रकटीकरण
44. ‘सभी से निजी’ के बजाय व्यू कुंजियाँ क्यों?
नियामकों ने उन गोपनीयता प्रणालियों को स्वीकार नहीं किया है जिनमें प्रकटीकरण जाँच के अधीन पक्ष के सहयोग पर निर्भर करता है, जैसा कि Tornado Cash का मामला दर्शाता है। इसलिए Rand प्रकटीकरण को एक प्रोटोकॉल ऑब्जेक्ट मानता है। धारक, या कोई विनियमित मध्यस्थ, व्यू कुंजी रखता है; ऑडिटर वैध अनुरोध में नामित लेन-देन को डिक्रिप्ट कर सकता है; और डिज़ाइन का लक्ष्य ऐसी स्कोप्ड कुंजियाँ हैं जो ट्रेडिंग रणनीति उजागर किए बिना प्रतिपक्ष और राशि प्रकट करती हैं। पेरोल जैसे अनुप्रयोगों के लिए यह ऑडिट-योग्यता सीमा नहीं, बल्कि एक आवश्यकता है।
स्रोत: randprotocol.org/usecases (regulation section; payroll case)
45. आउटगोइंग व्यू कुंजी इनकमिंग कुंजी से अलग क्यों है?
यह पृथक्करण प्रेषक को प्राप्तकर्ता के इतिहास तक पहुँच पाए बिना यह सिद्ध करने देता है कि उसने क्या भुगतान किया, और इसका उलटा भी। आउटगोइंग व्यू कुंजी ovk उन एनवलप को डिक्रिप्ट करती है जो वॉलेट ने भेजे हैं; ML-KEM डीकैप्सुलेशन कुंजी उन एनवलप को डिक्रिप्ट करती है जो उसे भेजे गए हैं; और प्रति-लेन-देन कुंजी किसी तीसरे पक्ष के सामने ठीक एक आउटपुट प्रकट करती है।
स्रोत: docs/shielded.md §1–2
ज्ञात सीमाएँ
46. आज प्रूफ़ क्या लीक करते हैं, और इसे दस्तावेज़ में क्यों दर्ज किया गया है?
2026-09-27 की समीक्षा में पाया गया कि v1 गेस्ट (chains 14–15) के अंतर्गत प्रत्येक बंडल प्रूफ़ यह प्रकट करता है कि किन इनपुट स्लॉट में वास्तविक नोट हैं और प्रत्येक खर्च किए गए लीफ़ इंडेक्स का हैमिंग भार क्या है। इसका कारण दोहरा है: प्रति-तालिका LogUp योग बिना ब्लाइंडिंग के प्रकाशित होते हैं, और गेस्ट का कंट्रोल फ़्लो इस पर शाखा लेता है कि इनपुट डमी है या नहीं। समाधान एक शाखा-रहित गेस्ट (v2) है, जिसे अगले जेनेसिस पर चुना जाएगा। यह निष्कर्ष इसलिए प्रकाशित किया गया है कि नेटवर्क एक टेस्टनेट है और दस्तावेज़ उसके ऑडिट रिकॉर्ड का काम करते हैं।
स्रोत: docs/shielded.md (‘What the proofs leak today’)
47. स्टेट वृद्धि का मूल्य कम क्यों आँका गया है?
Ethereum स्टोरेज राइट्स का मूल्य निर्धारित करता है, क्योंकि संग्रहीत स्टेट प्रत्येक नोड पर स्थायी लागत डालती है। Rand वर्तमान में कमिटमेंट ट्री, nullifier सेट और प्रोग्राम स्टोरेज की वृद्धि का मूल्य केवल प्रति-शब्द परिनियोजन शुल्क और एकसमान बंडल शुल्क के माध्यम से निर्धारित करता है। यह testnet के लिए पर्याप्त है, परंतु इसे mainnet से पहले हल किए जाने वाले एक खुले मूल्य-निर्धारण प्रश्न के रूप में दर्ज किया गया है; इसके समाधान के लिए प्रति-opcode मीटरिंग आवश्यक नहीं है।
स्रोत: docs/fees.md §3 (caveats)
48. अब तक कोई स्वतंत्र ऑडिट पूरा क्यों नहीं हुआ है?
प्रोटोकॉल टीम द्वारा संचालित testnet पर सक्रिय विकास के अधीन है, और डिज़ाइन के स्थिर होने से पहले और constraint सेट तथा chain कट अपेक्षित हैं। वेबसाइट यह बात प्रत्येक पृष्ठ पर बताती है। आंतरिक ऑडिट चक्र (v3–v5) docs/consensus.md और डिज़ाइन विनिर्देशों में प्रकाशित हैं, ताकि अंतिम बाह्य ऑडिट के पास कार्य करने के लिए एक संपूर्ण अभिलेख उपलब्ध रहे।
स्रोत: randprotocol.org (footer); docs/consensus.md