इस पृष्ठ का उपयोग चेन के साथ इंटरऑपरेट करते समय सही लाइब्रेरी चुनने, किसी पैरामीटर को नोड द्वारा लागू किए जाने वाले मान से मिलाने, और किसी आईडी या कमिटमेंट की स्वयं पुनर्गणना करने के लिए करें। यहाँ दिया गया प्रत्येक मान वही है जिस पर चेन 20 (fullnode v0.6.8) पर कोड चलता है।
प्रिमिटिव और उनका उपयोग कहाँ होता है
| प्रिमिटिव | पैरामीटर | उपयोग |
|---|---|---|
| Dilithium2 | 1,312-बाइट सार्वजनिक कुंजी, 2,420-बाइट हस्ताक्षर; कुंजी-युग्म 32-बाइट सीड से व्युत्पन्न | वैलिडेटर वोट और ब्लॉक प्रस्ताव; फ़ॉसेट मिंट; Unbond, Withdraw और किसी वैलिडेटर का Registration; किसी AdmitValidator के वोट (चेन 20); एग्रीगेटर क्रियाएँ; किसी RPL टोकन का Key मिंट प्राधिकार (TokenMint, SetAuthority); ब्रिज के पोस्ट-क्वांटम गार्डियन सह-हस्ताक्षर, उसकी पॉज़ कुंजी और, चेन 20 पर, रोटेशन में नई कुंजियों के स्वामित्व-प्रमाण (नीचे) |
| ML-KEM-768 | 1,184-बाइट एनकैप्सुलेशन कुंजी, 1,088-बाइट सिफ़रटेक्स्ट | किसी नोट एनवेलप की प्रति-लेनदेन कुंजी को प्राप्तकर्ता के पते के लिए सील करना; किसी कॉल-इनपुट एनवेलप को किसी ऑडिटर के लिए सील करना; किसी प्रूविंग जॉब को युग्मित प्रूवर के लिए सील करना |
| ChaCha20-Poly1305 | 32-बाइट कुंजी, आगे जोड़ा गया यादृच्छिक 12-बाइट नॉन्स, 16-बाइट टैग | प्रत्येक एनवेलप भाग: नोट बॉडी, रैप की गई लेनदेन कुंजियाँ, कॉल-इनपुट ट्रांसक्रिप्ट; किसी युग्मित प्रूवर के जॉब और उत्तर |
| BLAKE3 | 32-बाइट आउटपुट, सदैव आगे एक डोमेन स्ट्रिंग जोड़कर | पते, लेनदेन आईडी, लेनदेन बाइंडिंग और कॉल बाइंडिंग, प्रोग्राम आईडी, टोकन एसेट आईडी, स्टेट रूट और उसके Merkle ट्री, p2p पहचान, हस्ताक्षर संदेश, ब्रिज एसेट आईडी, किसी ब्रिज डिपॉज़िट की ब्लाइंडिंग और ब्रिज शुल्क नोटों की ब्लाइंडिंग |
| Goldilocks पर Poseidon2 | चौड़ाई 8, रेट 4, क्षमता 4, पैडिंग-रहित ओवरराइट स्पंज; संदेश तत्व 32-बिट वर्ड हैं; चेन-15 कट से 86 राउंड स्थिरांक नोड स्रोत में एक शाब्दिक तालिका (poseidon2_constants.rs) हैं, वही मान जो पहले सीडेड ड्रॉ से उत्पन्न होते थे | प्रूफ़ के भीतर सब कुछ: कुंजियाँ, नोट कमिटमेंट, नलिफ़ायर, कमिटमेंट ट्री, प्रोग्राम डाइजेस्ट hc, इनपुट कमिटमेंट H_IN और H_PUB, बंडल डाइजेस्ट, ऑथराइज़ेशन कमिटमेंट |
| secp256k1 ECDSA + keccak256 | low-s हस्ताक्षर, Ethereum-शैली के 20-बाइट गार्डियन पते, mu = keccak256(keccak256(body)) | ब्रिज गार्डियन अटेस्टेशन, ताकि वही कुंजी EVM कॉन्ट्रैक्ट, Solana प्रोग्राम और Rand पर काम करे; Rand पर प्रत्येक अटेस्टेशन को नीचे वर्णित Dilithium2 कोरम की भी आवश्यकता होती है |
| bech32m (BIP-350) | मानव-पठनीय भाग rpl, 32-बाइट पेलोड, 52 डेटा वर्ण + 6 चेकसम वर्ण = 62 | किसी RPL टोकन के एसेट आईडी का पाठ रूप rpl1… |
| Plonky3 बैच STARK | Goldilocks p = 2⁶⁴ − 2³² + 1, हाइडिंग FRI, ब्लोअप 8, फ़ोल्डिंग एरिटी 8, 80 क्वेरी, 20 प्रूफ़-ऑफ़-वर्क बिट | प्रत्येक बंडल प्रूफ़, ऑथ प्रूफ़ और कॉल प्रूफ़; एक बंडल प्रूफ़ और उसका ऑथ प्रूफ़ अपने लेनदेन के आठ बाइंडिंग वर्ड को अपने सार्वजनिक इनपुट खंड के रूप में रखते हैं |
श्वेतपत्र के लक्ष्य पैरामीटर कुछ स्थानों पर कार्यान्वयन में चलने वाले मानों से भिन्न हैं (उदाहरण के लिए, पेपर का 384-बिट ट्रांसक्रिप्ट हैश बनाम zkVM का Poseidon2 ट्रांसक्रिप्ट)। ये पृष्ठ कोड का वर्णन करते हैं।
ब्रिज पर पोस्ट-क्वांटम सह-हस्ताक्षर
ब्रिज के गार्डियन अटेस्टेशन secp256k1 ECDSA हैं, जिन्हें एक क्वांटम प्रतिद्वंद्वी जाली बना सकता है। चेन 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 चेन आईडी किसी testnet सह-हस्ताक्षर को किसी अन्य Rand चेन पर सत्यापित होने से रोकती है, भले ही गार्डियन कुंजियाँ पुनः उपयोग की गई हों। M केवल चेन आईडी को बाँधता है, चेन 20 पर भी: यह वह एकमात्र हस्ताक्षरित संदेश है जिसे binding_domain ने जेनेसिस हैश के पीछे नहीं किया, क्योंकि इस पर हस्ताक्षर करने वाले गार्डियन डेमन एक अन्य रिपॉज़िटरी में हैं। उसी चेन आईडी और उसी गार्डियन सेट वाली किसी चेन की प्रति उसके डिपॉज़िटों के सह-हस्ताक्षर स्वीकार कर लेगी; गार्डियन-सेट इंडेक्स 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 है: चेन 20 पर आठ 1,312-बाइट कुंजियाँ, जैसे चेन 15 से 19 पर, जो जेनेसिस ECDSA सेट, यानी गार्डियन सेट 1, के साथ इंडेक्स-संरेखित हैं (चेन 14 पर छह थीं, सेट 0 के साथ संरेखित)। ECDSA गार्डियन-सेट रोटेशन इसे कभी नहीं बदलता। चेन 14 पर यह चेन के पूरे जीवनकाल के लिए स्थिर था; चेन 15 से जेनेसिस में ब्रिज का rules_v2 समूह होता है, जिसके अंतर्गत एक PQ कोरम पूरे PQ सेट (RotatePqGuardians) या पॉज़ कुंजी (RotatePauseKey) को बदल सकता है, प्रत्येक ब्रिज के rotation_nonce के अंतर्गत। चेन 20 का जेनेसिस bridge.rotation जोड़ता है: रोटेशन V2 क्रिया होनी चाहिए, जिसमें प्रत्येक नई कुंजी का उसी संदेश पर अपना Dilithium2 हस्ताक्षर हो (स्वामित्व का प्रमाण), और यह दर्ज होने के एक दिन बाद प्रभावी होता है, जब तक कि वर्तमान पॉज़ कुंजी इसे रद्द न कर दे (ब्रिज)। rand_getBridgeState कुंजियाँ प्रदान करता है और डिकोड किया गया bridge_attest pq_signers सूचीबद्ध करता है, यानी वे इंडेक्स जिन्होंने हस्ताक्षर किए। वही PQ कोरम ब्रिज के गवर्नेंस संदेशों को अधिकृत करता है, जिनमें से प्रत्येक एक निश्चित बिग-एंडियन लेआउट है जिसमें चेन आईडी और एक नॉन्स होता है। चेन 20 पर (जेनेसिस binding_domain: 1) प्रत्येक डोमेन का संस्करण अंक 2 है और 32-बाइट जेनेसिस हैश डोमेन और चेन आईडी के बीच स्थित है; चेन 14 से 19 -1 रूपों का उपयोग करती हैं:
| संदेश | डोमेन (चेन 14–19 / चेन 20) | हस्ताक्षरकर्ता |
|---|---|---|
M_pause | rand-bridge-pause-1 / -2 | एकमात्र जेनेसिस पॉज़ कुंजी (Dilithium2), जो ब्रिज को रोक सकती है पर कभी पुनः आरंभ नहीं कर सकती |
M_unpause | rand-bridge-pq-unpause-1 / -2 | एक PQ गार्डियन कोरम |
M_list | rand-bridge-pq-list-1 / -2 | एक PQ गार्डियन कोरम (ListBacking) |
M_register | rand-bridge-pq-register-1 / -2 | एक PQ गार्डियन कोरम (RegisterBridgedToken) |
M_rotate_pq | rand-bridge-pq-rotate-pq-1 / -2 | वर्तमान PQ सेट का कोरम (RotatePqGuardians, rules_v2 वाली चेन); चेन 20 पर प्रत्येक नई कुंजी भी, अपने स्वामित्व-प्रमाण के रूप में |
M_rotate_pause | rand-bridge-pq-rotate-pause-1 / -2 | वर्तमान PQ सेट का कोरम (RotatePauseKey, rules_v2 वाली चेन); चेन 20 पर नई कुंजी भी |
M_cancel | rand-bridge-cancel-rotation-1 / -2, अंत में एक kind बाइट के साथ | वर्तमान पॉज़ कुंजी (CancelRotation, bridge.rotation वाली चेन: चेन 20) |
उत्पादन में STARK
zkVM कंस्ट्रेंट सेट 8 पर है: नौ अनिवार्य तालिकाएँ (program, cpu, memory, alu, range, nibble, poseidon2, input, public) तथा एक keccak और एक sha256 तालिका, जिन्हें कोई प्रूफ़ केवल तभी रखता है जब उसके गेस्ट ने संबंधित सिस्कॉल को कॉल किया हो; ये सत्रह बसों से जुड़ी हैं और एक बैच STARK के रूप में सिद्ध की जाती हैं। कंस्ट्रेंट सेट 7 से प्रत्येक घोषित तालिका में कम से कम 2⁷ पंक्तियाँ होती हैं और प्रत्येक तालिका का LogUp टर्मिनल सत्रहवीं बस, BLIND, के माध्यम से ब्लाइंड किया जाता है। किसी प्रूफ़ का सार्वजनिक इंटरफ़ेस 35 फ़ील्ड तत्व (pv::NUM) है: प्रवेश pc, टियर, आठ आउटपुट वर्ड, प्रोग्राम डाइजेस्ट hc (8 वर्ड), सॉल्टेड निजी-इनपुट कमिटमेंट H_IN (8), बिना सॉल्ट का सार्वजनिक-खंड डाइजेस्ट H_PUB (8) और, कंस्ट्रेंट सेट 8 से, घोषित गैस सीमा GAS_LIMIT।
| पैरामीटर | उत्पादन | टिप्पणी |
|---|---|---|
| FRI क्वेरी | 80 | कंस्ट्रेंट सेट 3 और 4 की 27-क्वेरी पुनः-ट्यूनिंग 2026-09-12 के ऑडिट के बाद वापस ली गई: उससे केवल ~42 सिद्ध बिट बचते थे |
| ब्लोअप | 8 (log_blowup = 3) | प्रत्येक तालिका की अधिकतम कंस्ट्रेंट डिग्री 8 की सीमा के भीतर नियत है |
| फ़ोल्डिंग एरिटी | 8 | |
| प्रूफ़-ऑफ़-वर्क बिट | 20 | |
| साउंडनेस | 3·80 + 20 = 260 बिट अनुमानित (ethSTARK); प्रॉक्सिमिटी गैप के अंतर्गत लगभग 86 बिट सिद्ध | |
| शून्य ज्ञान | सांख्यिकीय: LDE और FRI बैच बहुपद यादृच्छिकीकृत हैं, इसलिए एक ही रन के दो प्रूफ़ भिन्न होते हैं | कंस्ट्रेंट सेट 7 से प्रत्येक घोषित तालिका कम से कम 2⁷ पंक्तियों की है, जो किसी प्रूफ़ द्वारा खोले जाने वाले 82 बिंदुओं से अधिक है, और LogUp टर्मिनल ब्लाइंड किए गए हैं |
| टियर | 10, 12, 14, 16, 18, 20 | प्रूफ़ टियर प्रकट करता है, साइकिल संख्या कभी नहीं; fullnode v0.5.6 से टियर 14 से ऊपर का कॉल प्रूफ़ अस्वीकार किया जाता है (CallTierTooHigh), बंडल प्रूफ़ टियर 14 पर और ऑथ प्रूफ़ टियर 10 पर नियत है |
| प्रूफ़ सीमा | जेनेसिस का max_proof_bytes: चेन 17 से 20 पर 4 MiB (4,194,304); चेन 13 से 16 पर 8 MiB; इसके बिना वाले जेनेसिस पर, जैसे चेन 12, 2 MiB (MAX_PROOF_BYTES) | 2 MiB तैनात गेस्ट द्वारा बनाए जा सकने वाले हर हैश-तालिका-रहित प्रूफ़ से ऊपर और keccak-युक्त प्रूफ़ से नीचे है; 4 MiB दोनों को स्वीकार करता है |
| गैस | प्रति cpu पंक्ति 1; प्रति Poseidon2 एब्ज़ॉर्ब पंक्ति 3; प्रति SHA256 पंक्ति 64; प्रति KECCAK पंक्ति 192 | cpu तालिका के GAS कॉलम में संचित और अधिकतम GAS_LIMIT होना सिद्ध; वेरिफ़ायर gas_max(t, k, s) = (2ᵗ − 1) + 2ᵗ⁻² + 191·(2ᵏ/32) + 63·(2ˢ/64) से ऊपर की सीमा अस्वीकार करता है, जो हैश-रहित टियर-10 हेडर के लिए 1,279 और टियर-14 हेडर के लिए 20,479 है |
1,298,729 बाइट था और टियर 12 पर 1,359,978; keccak-युक्त टियर-10 प्रूफ़ 3,198,430 बाइट का था, जो 2 MiB की डिफ़ॉल्ट सीमा से अधिक और चेन 13 से 15 की 8 MiB सीमा से कम है। सेवानिवृत्त 2-इन-2-आउट बंडल गेस्ट का टियर-14 प्रूफ़ चेन 8 पर 1,321,773 बाइट और चेन 13 पर 1,418,406 से 1,420,423 बाइट मापा गया। चेन 14 का 4-इन-4-आउट छिपी-परिसंपत्ति बंडल गेस्ट किसी भी हैश तालिका के बिना टियर 14 पर ही रहता है, और उसके प्रूफ़ चेन 14 पर (2026-09-20) 1,422,116 और 1,423,170 बाइट मापे गए। चेन 15 ने वही गेस्ट पिन किया (hc_bundle अपरिवर्तित)। वहाँ बंडल प्रूफ़ ने public_log_height 4 घोषित किया, जो आठ बाइंडिंग शब्दों की ऊँचाई है, और नोड वेरिफ़ायर कुंजी बनाने से पहले ही कोई भी अन्य मान अस्वीकार कर देता था। चेन 13 पर 2026-09-19 को बना keccak-युक्त ERC-20 approve कॉल प्रूफ़ (टियर 16) 3,412,405 बाइट का है। fullnode v0.5.6 के बाद की हर चेन टियर 16 पर वह कॉल अस्वीकार करती है।
बाधा समुच्चय 7 के ब्लाइंडिंग कॉलम और तालिका-न्यूनतम हैश-रहित प्रूफ़ में लगभग 5% जोड़ते हैं। 2026-09-28 को fullnode द्वारा मापे गए आँकड़े: fib टियर 10 पर 1,367,688 बाइट और टियर 12 पर 1,424,299 बाइट, keccak-युक्त टियर-10 प्रूफ़ 3,283,898 बाइट, और टियर-14 छिपी-परिसंपत्ति बंडल प्रूफ़ 1,498,821 बाइट (गेस्ट v1) और 1,497,156 बाइट (गेस्ट v2)। तब से बंडल प्रूफ़ public_log_height 7 घोषित करता है। बाधा समुच्चय 8 इसमें 1% से कम जोड़ता है। चेन 18 पर 2026-09-30 को (Apple Silicon) मापे गए आँकड़े: auth प्रूफ़ 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 वही hc_bundle और hc_auth पिन करती है जो चेन 17 से 19 करती थीं।
हैश संरचनाएँ जिन्हें आप स्वयं पुनरुत्पादित कर सकते हैं
डोमेन सहित BLAKE3: blake3(domain || data), जिसमें डोमेन स्ट्रिंग के बाद कोई विभाजक नहीं होता।
बाइंडिंग डोमेन। चेन 20 का जेनेसिस binding_domain: 1 सेट करता है (fullnode v0.6.8, audit v6 BIND-1)। ऐसी चेन पर पहले केवल चेन id को बाँधने वाली हर प्रूफ़ बाइंडिंग और हर हस्ताक्षरित क्रिया-संदेश अब जेनेसिस हैश को भी बाँधता है। डोमेन की संस्करण संख्या एक बढ़ जाती है, और प्रीइमेज में चेन id से पहले 32-बाइट का जेनेसिस हैश आता है। इस कारण एक चेन के लिए बना प्रूफ़ या हस्ताक्षर किसी अन्य चेन पर सत्यापित नहीं होता। यह उस चेन पर भी लागू है जो वही चेन id और वही कुंजियाँ दोबारा उपयोग करती है, जैसा री-कट में होता है। बाइंडिंग शब्द प्रूफ़ का सार्वजनिक इनपुट हैं, इसलिए कोई गेस्ट या वेरिफ़ायर कुंजी नहीं बदली। तालिका दोनों रूप देती है; चेन 14 से 19 पहला रूप बाइट-दर-बाइट उपयोग करती हैं। ये पहले से जेनेसिस से बँधे थे और अपरिवर्तित हैं: वोट और प्रस्ताव (consensus_domain: 1 से), v2 Registration, और AdmitValidator वोट। ब्रिज का मिंट सह-हस्ताक्षर (ऊपर देखें) नहीं बदला गया। चेन 20 पर भेजने के लिए वॉलेट को v0.6.8 चाहिए। वॉलेट रूप का चयन चेन id से करता है, इस आधार पर नहीं कि नोड क्या दावा करता है; rand_getLimits.binding_domain इसे बताता है।
| मान | संरचना |
|---|---|
| पारदर्शी पता | blake3("rand-address" || dilithium2_public_key), base58 |
| लेन-देन id | blake3("rand-txid-3" || bincode(view)), जहाँ view वह लेन-देन है जिसमें बंडल के प्रूफ़ बाइट blake3(proof) से और उसका auth प्रूफ़ blake3(auth_proof) से प्रतिस्थापित हैं; auth_commit जस का तस शामिल होता है। चेन 16 तक डोमेन rand-txid-2 था, जिसमें auth फ़ील्ड नहीं थे |
| लेन-देन बाइंडिंग | चेन 14 से 19 पर blake3("rand-tx-bind-1" || bincode(chain_id, bundle', action')); चेन 20 पर blake3("rand-tx-bind-2" || bincode(genesis_hash, chain_id, bundle', action'))। आठ लिटिल-एंडियन u32 शब्द, जहाँ ' का अर्थ है कि bundle.proof, bundle.auth_proof और किसी Aggregate का proof रिक्त सदिश से प्रतिस्थापित हैं; bincode निश्चित-चौड़ाई वाले लिटिल-एंडियन पूर्णांकों के साथ। हर बंडल प्रूफ़ और auth प्रूफ़ इन्हीं शब्दों पर बनाया और इन्हीं के विरुद्ध सत्यापित किया जाता है |
| कॉल बाइंडिंग | blake3("rand-call-bind-1" || …), या चेन 20 पर जेनेसिस हैश को पहले रखकर rand-call-bind-2। यह लेन-देन बाइंडिंग की ही संरचना है, जिसमें Call (या Invoke) का अपना proof भी रिक्त किया जाता है। hardening_v6 जेनेसिस पर, जैसे चेन 20, कॉल प्रूफ़ का सार्वजनिक खंड प्रोग्राम के डिप्लॉय-समय के सार्वजनिक शब्दों और उनके बाद इन आठ शब्दों से बनता है। Invoke का खंड इनके बाद अपना संक्रमण संदर्भ-शब्दों के रूप में जोड़ता है |
| प्रोग्राम id | blake3("rand-program" || base_pc as 4 LE bytes || words as 4 LE bytes each) |
| p2p पहचान | blake3("rand-p2p-identity" || seed) से ed25519 कुंजी |
| ब्रिज परिसंपत्ति id (प्रति बैकिंग) | blake3("rand-bridge-asset" || token_chain as 2 BE bytes || token_address (32 bytes))। इसे rand_bridgeAssetId गणना करता है और rand_getAssets हर बैकिंग पंक्ति के लिए दिखाता है। यह वायर पर स्रोत कॉइन की पहचान करता है, टोकन की नहीं |
| RPL टोकन परिसंपत्ति id, देशी | blake3("rand-rpl-asset" || bincode(name, symbol, decimals, authority, initial: Option<InitialMint>, salt)), जहाँ salt निर्माता द्वारा चुने गए 32 बाइट हैं; हेक्स में और rpl1… के रूप में दिखाया जाता है |
| RPL टोकन परिसंपत्ति id, ब्रिज्ड | blake3("rand-rpl-asset" || bincode(name, symbol, BRIDGE_DECIMALS, salt))। यह किसी (chain, token) युग्म पर नहीं बनता, क्योंकि एक ब्रिज्ड टोकन कई बैकिंग में फैला होता है |
| ब्रिज जमा ब्लाइंडिंग | r = blake3("rand-deposit-r-1" || mu)। BridgeAttest के लिए प्रवेश केवल इसी r को स्वीकार करता है; अन्यथा WrongDepositBlinding |
| ब्रिज शुल्क नोट ब्लाइंडिंग (चेन 20) | जमा का शुल्क नोट: r = blake3("rand-bridge-fee-r-1" || mu); बर्न का: r = blake3("rand-bridge-burn-fee-r-1" || txid)। दोनों आठ लिटिल-एंडियन शब्दों के रूप में पढ़े जाते हैं। इन नोटों का कोई एनवेलप नहीं होता: हर फ़ील्ड सार्वजनिक है, और स्वामी जेनेसिस का bridge.fees.recipient है |
| ब्रिज प्राप्तकर्ता | पूर्ण शील्डेड पते पर blake3("rand-shielded-recipient" || pk_bytes || kem_ek) |
फ़ॉसेट Mint संदेश | blake3("rand-mint-2" || bincode(chain_id, cm, pk, time, r, envelope, amount)); चेन 20 पर blake3("rand-mint-3" || bincode(genesis_hash, chain_id, cm, pk, time, r, envelope, amount)) |
TokenMint, SetAuthority संदेश | blake3("rand-rpl-mint-1" or "rand-rpl-authority-1", chain_id || asset_id || nonce || body); मिंट के body में blake3(bincode(envelope)) शामिल होता है। चेन 20 पर rand-rpl-mint-2 और rand-rpl-authority-2, जिनमें जेनेसिस हैश पहले आता है |
Registration संदेश | staking.registration_v2 या binding_domain: 1 वाले जेनेसिस पर, जैसे चेन 20, blake3("rand-register-2" || bincode(genesis_hash, chain_id, validator, payout)) (वहाँ v1 पंजीकरण अस्वीकार किया जाता है); अन्यत्र blake3("rand-register" || bincode(chain_id, payout)) |
AdmitValidator वोट (चेन 20) | blake3("rand-admit-validator-1" || genesis_hash || candidate_address), जिस पर हर मतदान करने वाला वैलिडेटर हस्ताक्षर करता है |
Unbond संदेश | blake3("rand-unbond" || bincode(chain_id, validator, amount, nonce)); चेन 20 पर blake3("rand-unbond-2" || bincode(genesis_hash, chain_id, validator, amount, nonce)) |
Withdraw संदेश | blake3("rand-withdraw" || bincode(chain_id, validator, amount, nonce, time, r, envelope)); चेन 20 पर rand-withdraw-2, जिसमें जेनेसिस हैश पहले आता है |
| Merkle नोड (स्टेट ट्री) | blake3("rand-merkle-node" || left || right) |
| टोकन रजिस्ट्री लीफ़ | blake3("rand-token-leaf-1" || bincode(TokenInfo)), अनुक्रमणिका क्रम में, tokens_root के अंतर्गत |
| स्टेट रूट | चेन 20 पर blake3("rand-state-admitted-1" || inner || admitted_root), जो inner = blake3("rand-state-8" || tree_root || nullifier_root || validators_root || programs_root || bridge_root || tokens_root || faucet_epoch || faucet_minted_in_epoch || bond_queue_root || gas_price || byte_price || program_state_root) को लपेटता है। यहाँ program_state_root = blake3("rand-program-state-1" || cells_root || vaults_root) (RPL-2) है। दोनों फ़ॉसेट काउंटर और दोनों वर्तमान मूल्य 8-8 बिग-एंडियन बाइट के हैं, और यह आवरण स्वीकृत समुच्चय (staking.admission_by_vote) को प्रतिबद्ध करता है। चेन 19 का रूप byte_price तक के इन्हीं फ़ील्ड पर blake3("rand-state-7" || …) था। जेनेसिस का staking खंड rand-state-5 के अंतर्गत tokens_root के बाद तीन फ़ील्ड जोड़ता है, जैसा चेन 15 से 17 पर था। जेनेसिस का gas.dynamic खंड दोनों मूल्य जोड़ता है और डोमेन को rand-state-7 पर ले जाता है। चेन 14 पर पहले छह फ़ील्ड पर rand-state-4 था। जिस चेन में bridge, tokens या aggregation खंड नहीं है, उस पर पहले चार फ़ील्ड पर rand-state-2 है (सहमति) |
डोमेन टैग सहित Poseidon2: H(domain, msg) = sponge_hash([domain, msg...])। टैग पहला अवशोषित शब्द होता है, और हर शब्द एक Goldilocks तत्व है। 4-तत्वों वाला डाइजेस्ट आठ u32 शब्दों में बाँटा जाता है (हर तत्व का पहले निचला आधा, फिर ऊपरी आधा)। डोमेन टैग:
| टैग | मान | संरचना |
|---|---|---|
NK | 1 | व्यूइंग कुंजी nk = H(1, sk) |
PK | 2 | नोट का सार्वजनिक मान pk = H(2, nk) |
NF | 3 | नलिफ़ायर H(3, nk || cm) |
CM | 4 | नोट प्रतिबद्धता H(4, pk(8) || from(8) || amount_lo || amount_hi || asset || time || r(8)) — 28 शब्द |
OVK, KEM_SEED | 5, 6 | आउटगोइंग व्यूइंग कुंजी और ML-KEM सीड, काउंटर-मोड वाइड हैश [domain, nk, counter] के माध्यम से |
NODE | 7 | ट्री नोड H(7, left || right); रिक्त लीफ़ के सभी शब्द शून्य होते हैं |
HC | 8 | प्रोग्राम डाइजेस्ट; टैग, base_pc और len पहले क्रमचय की कैपेसिटी लेनों में रहते हैं, फिर शब्द प्रति ब्लॉक चार की दर से अवशोषित किए जाते हैं |
OUT | 9 | ट्रांसफ़र गेस्ट का आउटपुट डाइजेस्ट |
IN | 10 | H_IN: कैपेसिटी हेडर [10, n_in, 0], फिर 4 शब्दों का साल्ट, फिर इनपुट |
BUNDLE | 11 | सेवानिवृत्त 2-इन-2-आउट बंडल का डाइजेस्ट, 47 सार्वजनिक शब्दों पर; अब कोई भी चेन उस गेस्ट को पिन नहीं करती |
| हिडन बंडल | 64 | चेन 14 से 16 पर हिडन-एसेट बंडल का डाइजेस्ट, 81 शब्दों पर: एंकर, चार नलिफ़ायर, चार प्रतिबद्धताएँ, fee, burn_a, burn_r (प्रत्येक दो शब्द), burn_asset, time, और अंत में टेंट शब्द। चेन 17 से 20 पर (बंडल गेस्ट v3) यह 89 शब्दों का है: प्राधिकरण प्रतिबद्धता c के आठ शब्द टेंट शब्द से ठीक पहले रहते हैं। निजी एसेट A इसमें शामिल नहीं है। यह टैग नोड-स्थानीय है और vendored टैग 1 से 15 से अलग रहता है |
AUTH | 65 | प्राधिकरण प्रतिबद्धता c = H(65, nk || salt), 16 शब्द, प्रत्येक बंडल के लिए नए 256-बिट साल्ट के साथ; बंडल प्रूफ़ इसे अपने डाइजेस्ट के भीतर और auth प्रूफ़ इसे अपने आठ आउटपुट शब्दों के रूप में प्रकाशित करता है, और बंडल इसे auth_commit के रूप में वहन करता है (चेन 17 से 20)। 64 की तरह नोड-स्थानीय |
PUB | 15 | H_PUB: हेडर [15, n_pub, 0], कोई साल्ट नहीं; किसी प्रोग्राम के लिए, चेन 20 पर शब्द डिप्लॉय के समय निश्चित किए जाते हैं (अधिकतम 32,768), प्रत्येक कॉल का खंड वही शब्द होते हैं जिनके बाद कॉल बाइंडिंग के आठ शब्द आते हैं, और कॉल की जाँच उस खंड के डाइजेस्ट के विरुद्ध की जाती है; बंडल प्रूफ़ और auth प्रूफ़ के लिए खंड ट्रांज़ैक्शन के आठ बाइंडिंग शब्द होते हैं; max_program_public_words के बिना जेनेसिस केवल रिक्त खंड स्वीकार करता है |
hc, H_IN और H_PUB साधारण संदेश-उपसर्गित स्पंज नहीं हैं: हेडर कैपेसिटी में जाता है ताकि cpu तालिका की डाइजेस्ट पंक्तियाँ प्रति क्रमचय ठीक चार शब्द अवशोषित करें। इन्हें हाथ से बनाने के बजाय vendored क्रेट (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 को प्रकाशित करने से इनपुट के बारे में तब तक कुछ प्रकट नहीं होता जब तक साल्ट धारक इसे खोल नहीं देता।
कुंजी व्युत्पत्तियाँ
| कुंजी | स्रोत |
|---|---|
| Dilithium2 कुंजी युग्म (नोड) | 32-बाइट सीड से नियतात्मक रूप से |
| libp2p ed25519 (नोड) | blake3("rand-p2p-identity" || seed) |
व्यूइंग कुंजी, pk, ovk, ML-KEM कुंजी युग्म (वॉलेट) | ऊपर की तालिका के अनुसार व्यय कुंजी की Poseidon2 व्युत्पत्तियाँ; ML-KEM युग्म MlKem768::from_seed(kem_seed) है |
शोधपत्र पृष्ठ पर दिए गए शोधपत्रों में सुरक्षा संबंधी तर्क दिए गए हैं: पोस्ट-क्वांटम विकल्प, FRI सुदृढ़ता का लेखा-जोखा और 80 क्वेरी क्यों रखी जाती हैं, तथा ट्रेस-लंबाई सीमा।