प्रूफ़

इस पेज से आप प्रूविंग मशीन का आकार तय कर सकते हैं, समझ सकते हैं कि एक ट्रांसफ़र में एक मिनट से अधिक समय क्यों लगता है और थ्रूपुट को कंप्यूट नहीं, बल्कि ब्लॉक स्पेस क्यों सीमित करता है, और जान सकते हैं कि प्रूफ़ सिस्टम बदलने पर क्या टूटता है। वैलिडेटर जो कुछ भी स्वीकार करता है, उसके पीछे एक ऐसा प्रूफ़ होता है जिसे उसने स्वयं सत्यापित किया है।

प्रूफ़ क्या कथन करता है

चेन जो भी प्रोग्राम चलाती है, उन सब के लिए एक ही संबंध:

यह RV32IM प्रोग्राम, base_pc से आरंभ होकर, H_IN द्वारा कमिट किए गए निजी इनपुट वेक्टर और H_PUB द्वारा कमिट किए गए सार्वजनिक इनपुट खंड पर चलकर, 2ᵗ − 1 साइकिल के भीतर रुका, अधिकतम GAS_LIMIT गैस ख़र्च की और ये आठ आउटपुट शब्द प्रकाशित किए।

प्रोग्राम की पहचान उसके इन-सर्किट डाइजेस्ट hc से होती है; सत्यापनकर्ता कोई भी निर्देश शब्द कभी नहीं देखता। शील्डेड ट्रांसफ़र यही संबंध है, जो hidden-asset बंडल गेस्ट पर लागू होता है। यह हाथ से असेंबल किया गया 4-इन-4-आउट प्रोग्राम है, जिसका hc जेनेसिस फ़ाइल में hc_bundle के रूप में पिन किया गया है। चेन 20 गेस्ट v3 (guests::bundle_hidden_v3, 60af094a…6e3fce, चेन 17 से) को पिन करती है। चेन 14 और 15 ने v1 (83d3a370…cd0ef8) को और चेन 16 ने ब्रांच-रहित v2 (651043e2…839b) को पिन किया था। चेन 17 से हर बंडल एक दूसरा प्रूफ़ भी ले जाता है, जो auth गेस्ट (guests::auth, जेनेसिस hc_auth, 1e4e347f…5639c1) का होता है। बंडल प्रूफ़ व्यूइंग की लेता है, और auth प्रूफ़ दिखाता है कि प्रेषक के पास उसके पीछे की स्पेंड की है। इसे विभाजित प्राधिकरण कहते हैं, और इसी के कारण केवल व्यूइंग की रखने वाला युग्मित प्रूवर बंडल प्रूफ़ बना पाता है। hidden-asset गेस्ट ने चेन 13 तक के 2-इन-2-आउट bundle गेस्ट का स्थान लिया। वह गेस्ट fullnode में केवल परीक्षणों के लिए बचा है और कोई भी चेन उसे पिन नहीं करती। गोपनीय कॉल वही संबंध है, जो एक डिप्लॉय किए गए प्रोग्राम पर लागू होता है (प्रोग्राम)।

वॉलेट बंडल को कैसे प्रूव करता है

rand send <rand1…> <amount> निजी काम स्थानीय रूप से करता है, और चेन तक केवल प्रूफ़, कमिटमेंट, नलिफ़ायर और सील किए गए लिफ़ाफ़े पहुँचते हैं:

1. स्कैन: व्यूइंग की से ट्री को स्कैन करें और इनपुट चुनें। स्लॉट 2–3 में अधिकतम दो RAND नोट होते हैं, जो राशि और शुल्क दोनों को कवर करते हैं। टोकन ट्रांसफ़र या बर्न में स्लॉट 0–1 में उस टोकन के अधिकतम दो नोट होते हैं, और तब RAND नोट केवल शुल्क को कवर करते हैं। अप्रयुक्त इनपुट स्लॉट एक डमी होता है: राशि 0, स्वामी वॉलेट, उसकी सदस्यता-विफलता सर्किट में मास्क की जाती है, फिर भी नलिफ़ायर प्रकाशित होता है। गेस्ट v2 से गेस्ट ब्रांच-रहित है: डमी का पथ भी वास्तविक नोट की तरह सभी 32 स्तरों तक हैश किया जाता है।
2. फ़ेच: हेड एंकर (rand_getAnchor) और प्रत्येक वास्तविक इनपुट का 32-स्तरीय Merkle विटनेस (rand_getWitness(index)) प्राप्त करें, और लौटाए गए रूट को एंकर से मिलाएँ।
3. बिल्ड: चार आउटपुट बनाएँ। जो समूह मूल्य स्थानांतरित करता है, उसमें प्राप्तकर्ता का नोट और चेंज नोट होते हैं, जो राशि शून्य होने पर भी मौजूद रहते हैं। बाकी जगह शून्य-राशि वाले डमी होते हैं, जिन्हें एक अस्थायी की पर सील किया जाता है।
4. सील: प्रत्येक आउटपुट को एक लिफ़ाफ़े में सील करें (प्राप्तकर्ता के लिए ML-KEM-768, साथ में वॉलेट के ovk के अंतर्गत लपेटी गई ट्रांज़ैक्शन की)। फिर पूरे ट्रांज़ैक्शन को उसके एक्शन सहित असेंबल करें और उसका बाइंडिंग निकालें। यह प्रूफ़ हटाए गए ट्रांज़ैक्शन पर blake3("rand-tx-bind-1" || …) होता है, आठ शब्दों का (ट्रांज़ैक्शन)। चेन 20 पर, जिसकी जेनेसिस binding_domain: 1 सेट करती है, यह blake3("rand-tx-bind-2" || …) होता है, जिसमें पहले जेनेसिस हैश और फिर चेन आईडी आती है। इसलिए एक चेन के लिए बना प्रूफ़ किसी दूसरी चेन पर सत्यापित नहीं होता, चाहे उसकी चेन आईडी समान ही क्यों न हो। v0.6.8 से पुराना वॉलेट पुराना बाइंडिंग लेता है, और चेन 20 उसके प्रूफ़ अस्वीकार कर देती है।
5. प्राधिकृत करें: एक नया 256-बिट सॉल्ट लें और auth गेस्ट को टियर 10 पर प्रूव करें। उसका 16-शब्द का निजी इनपुट स्पेंड की और सॉल्ट है, और सार्वजनिक इनपुट खंड बाइंडिंग है। गेस्ट स्पेंड की से nk व्युत्पन्न करता है और c = H(AUTH, nk ‖ salt) प्रकाशित करता है, जिसे बंडल auth_commit के रूप में ले जाता है।
6. प्रूव करें: बंडल गेस्ट को टियर 14 पर प्रूव करें। उसका 1,212-शब्द का निजी इनपुट है: व्यूइंग की nk, अपने पथों सहित चार इनपुट स्लॉट, एंकर, चार आउटपुट, fee, burn_a, burn_r, निजी एसेट A, time और सॉल्ट। सार्वजनिक इनपुट खंड वही बाइंडिंग है। प्रूफ़ ये बातें दिखाता है: स्वामित्व, सदस्यता, कि प्रत्येक वास्तविक इनपुट अपने स्लॉट का एसेट ले जाता है, चार नलिफ़ायर, वही c, और दो संतुलन in₀ + in₁ = out₀ + out₁ + burn_a तथा in₂ + in₃ = out₂ + out₃ + fee + burn_r। यही वह प्रूफ़ है जिसे युग्मित प्रूवर वॉलेट की जगह बना सकता है; auth प्रूफ़ वॉलेट की अपनी मशीन पर बनता है।
7. जाँचें: प्रूफ़ के प्रकाशित डाइजेस्ट को प्लेनटेक्स्ट से गणना किए गए डाइजेस्ट से मिलाएँ, और Transaction { chain_id, bundle, action: None } सबमिट करें।

चेन 14 से क्रम का महत्व है: लिफ़ाफ़े और एक्शन प्रूफ़ से पहले मौजूद होते हैं, क्योंकि प्रूफ़ उन्हें कमिट करते हैं। कॉल के मामले में कॉल प्रूफ़ पहले बनता है और वह भी बाइंडिंग के भीतर आता है। hardening_v6 चेन पर कॉल प्रूफ़ स्वयं ट्रांज़ैक्शन के एक कॉल बाइंडिंग पर बनता है, जिसमें दोनों प्रूफ़ हटाए गए होते हैं (चेन 16 से 19 पर rand-call-bind-1, चेन 20 पर जेनेसिस हैश सहित rand-call-bind-2)। यह बाइंडिंग शुल्क बंडल के नलिफ़ायर को कवर करता है, इसलिए कॉल प्रूफ़ को किसी दूसरे बंडल के अंतर्गत कॉपी नहीं किया जा सकता।

proving bundle (tier 14; about a minute on a laptop)…
proved in 98.3s: tier 14, 1423170 bytes
submitted transfer 4f2c…  1.5 RAND out, 98.499 RAND change, fee 0.001 RAND, anchored at height 192

यह ट्रांसक्रिप्ट चेन 14 के समय की fullnode गाइड से लिया गया वॉलेट का आउटपुट प्रारूप है; दिखाई गई बाइट संख्या चेन 14 पर कमिट किए गए एक प्रोडक्शन-प्रोफ़ाइल बंडल प्रूफ़ की है। चेन 17 से वॉलेट (चेन 20 पर v0.6.8 सहित) इन पंक्तियों से पहले दो पंक्तियाँ छापता है, proving the spend authorisation on this machine (tier 10; seconds)… और authorisation proved in …: tier 10, … bytes, और बंडल वाली पंक्ति को proving the bundle (tier 14; about a minute and a half on a laptop)… के रूप में लिखता है।

यही तंत्र हर एक्शन का भुगतान करता है, और हमेशा ठीक एक बंडल से। डिप्लॉय, कॉल, टोकन पंजीकरण या टोकन मिंट RAND के शून्य-मूल्य स्व-ट्रांसफ़र पर चलते हैं। बॉन्ड एक ऐसे बंडल पर चलता है जो burn_r के माध्यम से स्टेक को बर्न करता है। टोकन बर्न या ब्रिज बर्न एक बंडल पर चलता है, जो स्लॉट 0–1 से एसेट बर्न करता है (burn_a, burn_asset) और स्लॉट 2–3 से RAND शुल्क चुकाता है। ट्रांसफ़र जिस एसेट को स्थानांतरित करता है, वह एक विटनेस शब्द है और किसी भी सार्वजनिक फ़ील्ड में नहीं होता।

लागत कितनी है

डेवलपमेंट लैपटॉप (Apple Silicon, रिलीज़ बिल्ड) पर मापे गए आँकड़े, जिन्हें fullnode के अपने दस्तावेज़ दर्ज करते हैं:

सत्यापन सर्वसम्मति की लागत है, जिसे हर नोड चुकाता है: वार्म सत्यापनकर्ता की के साथ लगभग 16 ms, और किसी दिए गए आकार के लिए पहली बार की बनाने पर लगभग 230 ms। सत्यापनकर्ता की प्रोग्राम की सामग्री पर निर्भर नहीं करती — वह (tier, program_log_height, input_log_height, keccak_log_height, sha256_log_height, public_log_height) पर आधारित होती है — इसलिए नोड हर आकार के लिए एक की बनाता है और उसे दोबारा उपयोग करता है। डिप्लॉय किए गए प्रोग्राम के लिए की डिप्लॉय के समय पृष्ठभूमि में एक बार गणना की जाती है (लैपटॉप पर लगभग 2 s, 2-vCPU सर्वर पर 7 s)। चेन 13 और उससे पहले का 2-इन-2-आउट बंडल program 12, input 10, keccak 0, sha256 0, public 2, mem 16 आकार घोषित करता था। चेन-14 बंडल प्रूफ़ public 4 घोषित करता है, जो आठ बाइंडिंग शब्दों की ऊँचाई है, और कोई भी हैश टेबल नहीं ले जाता। यदि वह कोई दूसरा टियर, कोई भी टेबल या कोई दूसरी सार्वजनिक ऊँचाई घोषित करता है, तो किसी भी सत्यापनकर्ता की के बनने से पहले ही अस्वीकार कर दिया जाता है। कंस्ट्रेंट सेट 7 से हर घोषित टेबल में कम से कम 2⁷ पंक्तियाँ होती हैं, इसलिए चेन-20 बंडल प्रूफ़ public 7 घोषित करता है।

चेन 20 पर एक ट्रांसफ़र इसलिए लगभग 2.87 MB प्रूफ़ ले जाता है, यानी बंडल प्रूफ़ और ऑथ प्रूफ़, और एक कॉल इनके ऊपर एक तीसरा प्रूफ़। प्रत्येक को जेनेसिस के max_proof_bytes में समाना होता है, जो चेन 20 पर 4,194,304 (4 MiB) है, जैसा कि चेन 17 से 19 पर था, और चेन 13 से 16 के 8 MiB से कम है।

छिपी-एसेट वाला गेस्ट टियर 14 में केवल इसलिए समाता है क्योंकि वह अपने निजी इनपुट एक लूप में पढ़ता है और Merkle जाँच के सिबलिंग रीड को एक साथ जोड़ देता है; पुरानी अनरोल्ड शैली में लिखा जाए तो वही संबंध टियर 16 पर पहुँचता है, लगभग 400 s और 21–22 GB, जिससे 16 GB वाले वॉलेट बाहर हो जाते।

प्रूविंग CPU-बाध्य है, और वॉलेट आज हर प्लेटफ़ॉर्म पर CPU बैकएंड का उपयोग करता है। बड़े टियर वाले रन में प्रूवर सिंगल-थ्रेडेड था: एक 16-vCPU ड्रॉपलेट एक कोर के 99% पर चला, और कोर नहीं, बल्कि मेमोरी ने तय किया कि प्रूफ़ पूरा होगा या नहीं (प्रूविंग मेमोरी)। send, bond, call, deploy, bridge-mint और bridge-burn पर --cuda फ़्लैग एक NVIDIA बैकएंड चुनता है, जिसके लिए --features cuda के साथ बना बिल्ड आवश्यक है। इसके कर्नेल पहली बार वास्तविक हार्डवेयर, एक NVIDIA H100, पर 2026-09-28 को चले और CPU संदर्भ से मेल खाए, लेकिन रिलीज़ जिस सर्किट चेकआउट को वेंडर करती है उसमें कोई PTX कमिट नहीं है, इसलिए जब तक कर्नेल कंपाइल नहीं होते, बिल्ड no PTX for the GPU kernels के साथ विफल होता है। किसी फ़्लीट GPU नोड पर अभी तक कोई प्रोडक्शन प्रूफ़ मापा नहीं गया है। CPU पर जानबूझकर कोई फ़ॉलबैक नहीं है। एक CUDA कॉल इनपुट एन्वेलप को सील भी नहीं कर सकती, क्योंकि सॉल्ट कभी प्रूवर से बाहर नहीं जाता। टियर-14 छिपी-एसेट बंडल प्रूफ़ के लिए अधिकतम मेमोरी लगभग 5.7 GB है (Production FRI, CPU); बड़ी मेमोरी श्रेणियाँ नीचे दिए गए इंटरप्रेटर और रिकर्शन प्रूफ़ से संबंधित हैं (≥ 64 GB और अधिक)।

नोड सत्यापन कैसे करता है

प्रवेश पहले सस्ती जाँचें चलाता है (लेनदेन), फिर:

• प्रकाशित प्लेनटेक्स्ट (एंकर, चार न्यूलिफ़ायर, चार कमिटमेंट, fee, burn_a, burn_r, burn_asset, time, बंडल का auth_commit, और शून्य पर स्थिर एक टेंट शब्द) से बंडल डाइजेस्ट की पुनर्गणना करता है और अपेक्षा करता है कि यह उसके बराबर हो जो प्रूफ़ ने प्रकाशित किया — जिस प्रूफ़ के विटनेस ने संबंध तोड़ा हो, वह एक दूषित डाइजेस्ट प्रकाशित करता है जो किसी भी प्लेनटेक्स्ट से मेल नहीं खाता। इसके बजाय कुछ जाँचें संरचनात्मक हैं (गेस्ट किसी आउटपुट का प्रेषक, एसेट और समय स्वयं देता है, इसलिए प्रूवर उन्हें चुन नहीं सकता), और निजी एसेट डाइजेस्ट में नहीं है;
• प्रूफ़ को डिकोड करता है और उसकी घोषित ऊँचाइयों को टियर के विरुद्ध जाँचता है (check_declared_heights), ताकि प्रूफ़ के आकार पर चेन की सीमा ही सत्यापनकर्ता की सीमा हो। किसी भी सिग्नेचर या प्रूफ़ की जाँच से पहले, हर सबमिट किए गए या गॉसिप किए गए लेनदेन पर (और hardening_v6 के अंतर्गत ब्लॉक सत्यापन में) एक कैनोनिकल-प्रूफ़ स्क्रीन चलती है; fullnode v0.6.8 (audit v6, ZKV-4) से यह स्क्रीन सबसे पहले हर घोषित डिग्री को 25 बिट पर सीमित करती है (MAX_HONEST_DEGREE_BITS, मेमोरी टेबल की अधिकतम सीमा जमा एक), ताकि बहुत बड़ी डिग्री वाला हेडर अब नोड को तब तक रोके नहीं रखता जब तक उसके लिए ईमानदार फ़ोल्डिंग शेड्यूल फिर से निकाला जाता है, और स्क्रीन के भीतर पैनिक होने पर नोड रुकने के बजाय वह लेनदेन अस्वीकार हो जाता है;
• लेनदेन की बाइंडिंग की गणना करता है और Machine::verify_public(hc_bundle, &binding, proof) चलाता है — बैच सत्यापनकर्ता, साथ में यह जाँच कि H_PUB उन आठ शब्दों का डाइजेस्ट है, ताकि किसी अन्य एक्शन, अन्य एन्वेलप या अन्य चेन id वाले लेनदेन पर, या चेन 20 पर किसी अन्य चेन के जेनेसिस पर, कॉपी किया गया प्रूफ़ सत्यापित न हो (चेन 13 तक सेगमेंट खाली था और कुछ भी प्रूफ़ को उसके लेनदेन से नहीं बाँधता था);
• ऑथ प्रूफ़ को hc_auth और उसी बाइंडिंग के विरुद्ध सत्यापित करता है, और अपेक्षा करता है कि वह जो c प्रकाशित करता है वह auth_commit के बराबर हो। ऑथ प्रूफ़ के बिना बंडल अस्वीकार होता है (AuthMissing), और वह भी जिसका c भिन्न हो (AuthMismatch);
• अपेक्षा करता है कि बंडल प्रूफ़ का GAS_LIMIT जेनेसिस के bundle_gas_limit, 20,479, के बराबर हो, और ऑथ प्रूफ़ का 1,279 के बराबर, जो दोनों गेस्ट की हेडर अधिकतम सीमाएँ हैं (BundleGasLimit, AuthGasLimit);
• कॉल के लिए, यही प्रोग्राम के संग्रहीत code_hash के विरुद्ध करता है, जिसमें सेगमेंट के रूप में प्रोग्राम के सार्वजनिक शब्द और उनके बाद कॉल बाइंडिंग होती है (एक RPL-2 Invoke अपना ट्रांज़िशन संदर्भ शब्दों के रूप में जोड़ता है, प्रोग्राम), फिर शुल्क को प्रूफ़ द्वारा घोषित गैस लिमिट और उसके बाइट्स के विरुद्ध जाँचता है (शुल्क)।

RPC या गॉसिप पर सबमिट किया गया लेनदेन 64-गहरी कतार के पीछे चार वर्करों में से किसी एक पर, सहमति लूप से अलग, सत्यापित होता है, और सत्यापित होने के बाद ही आगे गॉसिप किया जाता है; प्रति-पीयर टोकन बकेट (बर्स्ट 16, प्रति सेकंड 4 की पुनःपूर्ति) यह मापता है कि कोई पीयर नोड से कितना सत्यापन करवा सकता है, और 8,192 प्रविष्टियों वाला कैश स्थायी रूप से अस्वीकृत लेनदेन की पुनरावृत्ति का उत्तर मुफ़्त में देता है। प्रस्तावित ब्लॉक के भीतर के प्रूफ़ का सत्यापन अब भी ब्लॉक लागू होते समय सहमति लूप पर ही चलता है। सिंक करने वाला नोड हर ब्लॉक को स्वीकार करने से पहले उसके हर सर्टिफ़िकेट और हर प्रूफ़ को फिर से सत्यापित करता है; किसी भी चीज़ पर केवल इसलिए भरोसा नहीं किया जाता कि किसी कोरम ने उस पर हस्ताक्षर किए।

टियर

fullnode v0.5.6 (2026-09-25) से टियर 14 से ऊपर का कॉल प्रूफ़ सत्यापनकर्ता कुंजी बनने से पहले ही अस्वीकार कर दिया जाता है (CallTierTooHigh), और ऐसा प्रूफ़ ले जाने वाला ब्लॉक अमान्य है; एक कॉल अधिकतम 128 Keccak-f परम्यूटेशन और 128 SHA-256 कम्प्रेशन भी ले जा सकती है। टियर 16 से 20 अब भी प्रूव करते हैं, लेकिन केवल ऑफ़-चेन: ऊपर की उन पंक्तियों में से किसी को भी चेन 20 पर कॉल नहीं किया जा सकता, और चेन 20 ऐसे प्रोग्राम का डिप्लॉय अस्वीकार करती है जो किसी भी टियर-14 कॉल के लिए बहुत बड़ा हो, यानी सार्वजनिक इनपुट के बिना 8,180 शब्दों से अधिक (ProgramUncallable) (बजट)।

प्रूवर वह सबसे छोटा टियर चुनता है जिसका बजट साइकिलों के साथ प्रोग्राम और इनपुट डाइजेस्ट की पंक्तियों को समा ले; जो रन समाता नहीं, वह प्रूविंग से पहले ही विफल हो जाता है। केवल टियर सार्वजनिक है। हर चरण प्रूविंग समय को लगभग चौगुना करता है और प्रूफ़ के आकार में थोड़ी वृद्धि करता है। चेन 20 पर कॉल का शुल्क टियर के बजाय उसके प्रूफ़ द्वारा घोषित गैस लिमिट और बाइट्स में उसके आकार के अनुसार होता है (शुल्क)।

कंस्ट्रेंट सेट और हार्ड फ़ोर्क

कंस्ट्रेंट सेट टेबलों, कॉलमों, बसों, सार्वजनिक मानों और FRI पैरामीटरों का वह सटीक समुच्चय है जिसे सत्यापनकर्ता जाँचता है। एक सेट के अंतर्गत बना प्रूफ़ दूसरे सेट के अंतर्गत सत्यापित नहीं होता, किसी भी दिशा में, और नोड का स्टार्टअप रीप्ले उसकी चेन के हर प्रूफ़ को फिर से सत्यापित करता है — इसलिए किसी भिन्न सेट से बना नोड पहले ही प्रूफ़ पर विफल होकर ट्रंकेट हो जाता है। इसीलिए सेट में हर परिवर्तन एक नई चेन id के रूप में काटा जाता है, जिसमें हर नोड एक ही बिल्ड पर होता है, और इसीलिए rand_status hc_bundle और hc_auth रिपोर्ट करता है, और जिस नोड का बिल्ड जेनेसिस से असहमत हो वह शुरू होने से इनकार कर देता है।

चेन 14 और 15 ने कोई कंस्ट्रेंट नहीं बदला। चेन 15 का नोड Poseidon2 के 86 राउंड कॉन्स्टेंट को सीडेड ड्रॉ के बजाय एक लिटरल टेबल के रूप में रखता है (audit ZKV-2) — मान वही हैं, इसलिए कोई हैश, डाइजेस्ट या प्रूफ़ नहीं बदला। चेन 14: छिपी-एसेट बंडल एक नया गेस्ट है (एक नया hc_bundle) और लेनदेन बाइंडिंग उस सार्वजनिक सेगमेंट का उपयोग करती है जिसे सेट 6 पहले से ही सर्किट में बाँधता है। फिर भी यह एक हार्ड फ़ोर्क है — बंडल का वायर फ़ॉर्मेट, पिन किया गया गेस्ट और हर लेनदेन id बदल गए, बंडल ले जाने वाला चेन-13 लेनदेन नए बिल्ड द्वारा अस्वीकार किया जाता है, और फ़ोर्क से पहले बना वॉलेट खाली-सेगमेंट वाले प्रूफ़ बनाता है जिन्हें चेन अस्वीकार करती है।

उसके बाद आई तीन चेनों में से हर एक ने यह बदला कि प्रमाण क्या होता है। चेन 16 (fullnode v0.6.1, 2026-09-28) कंस्ट्रेंट सेट 7 पर गई, उसने ब्रांच-रहित बंडल गेस्ट v2 को पिन किया और hardening_v6 सेट किया। यह बदलाव 2026-09-27 की समीक्षा के बाद आया, जिसमें पाया गया था कि छोटी तालिकाएँ और अनब्लाइंडेड LogUp टर्मिनल निजी डेटा लीक कर रहे थे (zkVM कैसे काम करता है)। हर सत्यापनकर्ता कुंजी बदल गई। चेन 17 (v0.6.3, 2026-09-29) ने सेट 7 बनाए रखा और विभाजित प्राधिकरण जोड़ा। इसमें बंडल गेस्ट v3, auth गेस्ट, बंडल के वायर फ़ॉर्मेट में दो नए फ़ील्ड और ट्रांज़ैक्शन id डोमेन rand-txid-3 आए। चेन 18 (v0.6.7-rc1, 2026-09-29) गैस मीटर के लिए कंस्ट्रेंट सेट 8 पर गई। प्रमाण के आकार में इसकी मापी गई लागत 1% से कम है। चेन 19 (2026-10-01) उसी v0.6.7 बिल्ड पर चेन 18 का पुनः-जेनेसिस है और इसने प्रमाणों में कुछ नहीं बदला। चेन 20 (fullnode v0.6.8, 2026-10-01) कंस्ट्रेंट सेट 8 और वही गेस्ट तथा सत्यापनकर्ता कुंजियाँ रखती है। यह बदलती है कि प्रमाण किससे बँधा है: ट्रांज़ैक्शन और कॉल बाइंडिंग में अब जेनेसिस हैश (binding_domain: 1) शामिल होता है। यह एक सार्वजनिक इनपुट है जिसकी गणना वॉलेट और लेजर करते हैं, इसलिए कोई सर्किट नहीं बदला। फिर भी यह एक हार्ड फ़ॉर्क है, क्योंकि v0.6.7 वॉलेट के प्रमाण इस पर सत्यापित नहीं होते। हर बिल्ड अपने से पहले की चेनों को जेनेसिस हैश के आधार पर अस्वीकार कर देता है।

कोड में दर्ज दो ऑडिट टिप्पणियाँ जानने योग्य हैं। पहली: TIER सार्वजनिक मान को सत्यापनकर्ता प्रमाण हेडर और बैच के डिग्री बिट्स से मिलाकर जाँचता है, लेकिन सर्किट स्वयं उस पर कोई कंस्ट्रेंट नहीं लगाता (ऑडिट ZL1)। इसे ठीक नहीं किया गया, बल्कि अगले सेट के लिए चिह्नित किया गया है, क्योंकि इसे हटाने से सार्वजनिक मानों का लेआउट खिसक जाता है। दूसरी: H_IN एक गेस्ट-दृश्य प्रतिबद्धता है जिसकी तुलना सत्यापनकर्ता कॉलर द्वारा दिए गए किसी मान से नहीं करता, और ऐसा जानबूझकर किया गया है।

आगामी: ब्लॉक एग्रीगेशन

चेन 14 और 15 पर छिपी-परिसंपत्ति वाला एक बंडल प्रमाण लगभग 1.43 MB का था। इस आकार पर 4 MiB के ब्लॉक (जो डिफ़ॉल्ट है और चेन 12 का आकार था) में दो शील्डेड ट्रांसफ़र आते थे। 2-इनपुट-2-आउटपुट बंडल के ~1.3 MB पर उसमें तीन आते थे। चेन 13, 14 और 15 ने ब्लॉक की सीमा बढ़ाकर 20 MiB (max_block_bytes) कर दी, जिसमें चौदह ट्रांसफ़र आ सकते हैं। चेन 20 भी 20 MiB रखती है, पर वहाँ एक ट्रांसफ़र में लगभग 2.87 MB का प्रमाण होता है, इसलिए एक ब्लॉक में लगभग सात आते हैं। fullnode ने (2026-09-12) प्रूनिंग और बड़े ब्लॉक के बजाय ब्लॉक-स्तरीय एग्रीगेशन का उपाय चुना। इसमें हर सील की गई विंडो के लिए एक रिकर्सिव प्रमाण होता है जो N बंडल प्रमाणों को सत्यापित करता है। इससे इतिहास शुरू से अंत तक प्रमाण-युक्त रहता है और मूल प्रमाण हटाए जा सकते हैं। यह बना और मर्ज हो चुका है, पर सक्रिय नहीं है, और चेन 14 के बाद से इसे सक्रिय करने से पहले फिर से मापना होगा। इसका स्वीकृत बंडल आकार खाली सार्वजनिक खंड (public 2) के साथ मापा गया था, जबकि ट्रांज़ैक्शन-बद्ध बंडल public 4 घोषित करता है, इसलिए चेन 14 पर सिद्ध कोई भी बंडल उससे मेल नहीं खाता। कंस्ट्रेंट सेट 7 और 8 ने आकार को फिर बदला। अब एक बंडल प्रमाण public 7 घोषित करता है और 35 मान प्रकाशित करता है, इसलिए एग्रीगेट का इंटरफ़ेस प्रति प्रमाण 35 वर्ड का है। नोड बिल्ड ऐसे किसी भी जेनेसिस पर शुरू होने से इनकार करता है जिसमें aggregation खंड हो, और चेन 14 से 20 बिना इस खंड के बनाई गईं। गतिशील गैस मूल्यों वाला जेनेसिस, जैसे चेन 20 का, भी aggregation खंड के साथ अस्वीकार किया जाता है। fullnode v0.5.8 से एग्रीगेट प्रमाण अपने एग्रीगेटर को भी बाँधता है (ऑडिट AGG-2: प्रोग्राम aggregate_binding(chain_id, aggregator, nonce) को अवशोषित करता है)। इसलिए स्वीकृत आकार का प्रोग्राम डाइजेस्ट ऐसे बिल्ड पर मापना होगा जिसमें यह बदलाव शामिल हो। सक्रियण दो और बातों की प्रतीक्षा में है। पहली, ठीक किए गए रिकर्शन सत्यापनकर्ता के विरुद्ध जाली एग्रीगेट का एक एंड-टू-एंड अभ्यास, जो अभी तक नहीं चलाया गया है। दूसरी, auth प्रमाण के बारे में एक निर्णय: एग्रीगेट प्रोग्राम केवल बंडल प्रमाण सत्यापित करता है। इसलिए विभाजित प्राधिकरण वाली चेन पर किसी विंडो को सील करने से एक ट्रांसफ़र लगभग 2.87 MB से घटकर लगभग 1.37 MB होगा, शून्य नहीं।

क्या बन चुका है:

• एक दूसरी, Goldilocks-नेटिव मशीन (रिकर्शन VM, randprotocol-rvm), जिसका सत्यापनकर्ता प्रोग्राम एक RV32 प्रमाण को टियर 21 पर लगभग 1.97 मिलियन पंक्तियों में जाँचता है (कंस्ट्रेंट सेट 7 के अंतर्गत 2,044,506)। साथ में बंडल प्रमाणों की एक विंडो पर काम करने वाला एक N-जेनेरिक एग्रीगेट प्रोग्राम;
• दो भूमिकाएँ: वैलिडेटर CPU पर कम लागत वाले रहते हैं और हर सील किए गए ब्लॉक के लिए एक एग्रीगेट सत्यापित करते हैं। एग्रीगेटर GPU-श्रेणी की मशीनों पर एग्रीगेट सिद्ध करते हैं। वे एक अनुमति-रहित, बॉन्डेड रजिस्टर में दर्ज होते हैं जिसमें शील्डेड भुगतान पता होता है। उन्हें कवर किए गए बंडलों का प्रूविंग हिस्सा मिलता है, साथ में हॉल्विंग अनुसूची पर नए RAND में एक ब्लॉक सब्सिडी भी;
• पाँच क्रियाएँ (RegisterAggregator, UnbondAggregator, WithdrawAggregator, SlashAggregator, Aggregate)। SlashAggregator वायर पर बनी रहती है पर अस्वीकार की जाती है, क्योंकि दोबारा भेजा गया एग्रीगेट उसी nonce पर फिर से हस्ताक्षर करता है और यह इक्विवोकेशन नहीं है। इसके अलावा नौ-चरणों वाली स्वीकृति प्रक्रिया; सीलिंग, और कवर किए गए बंडलों की प्रूनिंग, जिससे हर बंडल के लगभग 3 KB सार्वजनिक फ़ील्ड बचते हैं; सील-रूप सिंक, जिसमें नए नोड को प्रति विंडो एक रिकर्शन सत्यापन करना पड़ता है; RPC मेथड rand_getAggregate, rand_getAggregators, rand_getUnsealed, rand_getRawTransaction; और rand-node aggregate --watch डेमन।

परीक्षण FRI प्रोफ़ाइल पर मापे गए आँकड़े: भारी लोड वाले लैपटॉप पर एक N=1 एग्रीगेट लगभग 26 मिनट में सिद्ध हुआ (327,035 बाइट)। एक नए नोड ने सात ब्लॉक का सील किया गया बैच एक रिकर्शन सत्यापन के साथ एक सेकंड से कम में लागू किया। पहले आकलन में मशीन श्रेणियाँ इस प्रकार निकलीं: N=1 के लिए ≥ 64 GB होस्ट मेमोरी चाहिए, N=2 के लिए ≥ 128 GB और N=3 के लिए ≥ 160 GB। उत्पादन में N ≥ 2 का काम CUDA बैकएंड करेगा, जिसके लिए एक GPU नोड चाहिए जो अभी मौजूद नहीं है। कंस्ट्रेंट सेट 7 के अंतर्गत 256 GB की मशीन पर माप (2026-09-28 और 29) में N=2 एग्रीगेट ने 133 GB और N=3 ने 221 GB लिया। उत्पादन एग्ज़िट प्रमाण (एक आंतरिक प्रमाण पर चलने वाला सत्यापनकर्ता प्रोग्राम) 256 GB से अधिक हो गया। इनमें से कुछ भी कंस्ट्रेंट सेट 8 के अंतर्गत दोबारा नहीं मापा गया है। जब तक एग्रीगेशन सक्रिय नहीं होता, चेन 20 पर कोई एग्रीगेट किसी प्रमाण की जगह नहीं लेता। इसके दो आर्काइव नोड हर मूल प्रमाण रखते हैं, और इसके वैलिडेटर 24 घंटे से पुराना इतिहास प्रून कर देते हैं।