वैलिडेटर और एग्रीगेटर चलाना

इस पृष्ठ का उपयोग किसी मशीन को चलाने से पहले उसका आकार तय करने के लिए करें। वैलिडेटर सस्ता है। प्रूविंग सस्ती नहीं है: किसी प्रूफ़ की मेमोरी उसके टियर के साथ तेज़ी से बढ़ती है, और यही वह एक संख्या है जो तय करती है कि कोई मशीन यह काम कर सकती है या नहीं। यहाँ दिया गया हर आँकड़ा testnet या fullnode के रिकॉर्ड से लिया गया माप है। जो आँकड़े अंतिम नहीं हैं, उन्हें चिह्नित किया गया है।

हर भूमिका क्या करती है

वैलिडेटर और ऑब्ज़र्वर कभी प्रूफ़ नहीं बनाते। शील्डेड ट्रांसफ़र या कॉल का प्रूफ़ वही वॉलेट बनाता है जो उसे भेजता है, या केवल बंडल प्रूफ़ के मामले में, वह प्रूवर जिसके साथ वह वॉलेट युग्मित है (नोड चलाना)। फ़्लीट के वैलिडेटर आज किसी चीज़ का प्रूफ़ नहीं बनाते।

ब्लॉक एग्रीगेशन बन चुका है, पर सक्रिय नहीं है। इसके लिए जेनेसिस में aggregation खंड होना आवश्यक है। चेन 20 में ऐसा कोई खंड नहीं है: चेन 9 से 19 की तरह एग्रीगेशन बंद है, और जिस जेनेसिस में यह खंड हो, उस पर यह बिल्ड शुरू होने से इनकार करता है।

एक नज़र में आकार

प्रूवर आज सिंगल-थ्रेडेड है। 16-vCPU वाला ड्रॉपलेट एक कोर के 99% पर चला। अधिक कोर किसी एक प्रूफ़ को तेज़ नहीं बनाते; अधिक RAM तय करती है कि वह पूरा होगा या नहीं।

वैलिडेटर और ऑब्ज़र्वर

मेमोरी और CPU

मूल अठारह वैलिडेटर 2 GB ड्रॉपलेट पर चलते हैं। किसी प्रूफ़ का सत्यापन सस्ता है:

टियर-18 या टियर-20 कॉल प्रूफ़ के सत्यापन के लिए वैलिडेटर को जितनी मेमोरी चाहिए, वह अब आंशिक रूप से मापी जा चुकी है। माप 48 GB वाले Apple-silicon लैपटॉप पर लिया गया, जो हर प्रूफ़ बनाने वाले DigitalOcean ड्रॉपलेट से अलग मशीन है: टियर-18 transfer प्रूफ़ के सत्यापन में 3.66 GB शिखर RSS पर 50.2 s लगे (ट्रांसलेटेड) या 49.6 s (इंटरप्रेटर, RSS अलग से दर्ज नहीं); टियर-16 approve प्रूफ़ के सत्यापन में 12.2 s लगे (RSS अलग से दर्ज नहीं)। टियर 20 मापा नहीं गया है, क्योंकि सत्यापन के लिए अभी कोई टियर-20 प्रूफ़ मौजूद नहीं है। v0.5.6 से कोई वैलिडेटर इतनी बड़ी कुंजी कभी नहीं बनाता: कोई भी वेरिफ़ायर कुंजी बनाने से पहले कॉल प्रूफ़ का हेडर जाँचा जाता है। टियर 14 से ऊपर की कॉल, या 2^12 से बड़ी keccak टेबल या 2^13 से बड़ी sha256 टेबल वाली कॉल, प्रवेश के समय भी अस्वीकार की जाती है और ब्लॉक-वैधता नियम के रूप में भी। सबसे भारी स्वीकार्य कॉल हेडर के सत्यापन में 4.7 s और 312 MB मापे गए।

1-vCPU, 2 GB वाला ड्रॉपलेट बाइनरी बिल्ड नहीं कर सकता। किसी बड़ी मशीन पर बिल्ड करें और बाइनरी कॉपी करें (देखें सेटअप)।

डिस्क

चेन 20 पर, चेन 19 की तरह, 26 में से 24 वैलिडेटर --prune-history 24h के साथ चलते हैं और लगभग एक दिन के ब्लॉक रखते हैं; लेजर स्वयं (नोट, नलिफ़ायर, एंकर, रजिस्टर) कभी प्रून नहीं होता। आर्काइव obs1 और rand-archive-2 (दोनों वैलिडेटर भी हैं) इस फ़्लैग के बिना चलते हैं। mainnet नोड यह फ़्लैग कभी नहीं लगाता। अगर डेटा डायरेक्टरी वाले फ़ाइल सिस्टम पर --min-free-disk-mb (डिफ़ॉल्ट रूप से 1,024 MB) से कम खाली जगह हो, तो नोड शुरू होने से इनकार करता है। खाली जगह इसके चार गुने से कम होने पर rand_getHealth का उत्तर disk_low होता है। इसलिए ok की प्रतीक्षा करने वाला रोल उस नोड पर रुक जाता है जिसकी डिस्क भर रही है। प्रून किया गया नोड अब भी किन अनुरोधों का उत्तर देता है, यह जानने के लिए देखें हिस्ट्री प्रूनिंग।

रिटायर हो चुकी चेन की डेटा डायरेक्टरी को कट-ओवर के बाद हटा दें। डेटा डायरेक्टरियाँ जेनेसिस हैश के आधार पर नामित होती हैं (data-<name>-<hash8>: चेन 20 के लिए -6210cf07, चेन 19 के लिए -a3defc93; छह गार्डियन होस्ट /var/lib/randnode/data-20 का उपयोग करते हैं), इसलिए पुरानी डायरेक्टरियाँ तब तक बनी रहती हैं जब तक आप उन्हें हटाते नहीं। चेन-20 के कट पर एक क्षेत्रीय वैलिडेटर (syd1) केवल 3.9 GB खाली स्थान के साथ disk_low स्थिति में चालू हुआ और उसने स्टार्ट को 26 में से 25 पर रोके रखा, क्योंकि चेन 14 से 17 तक की डायरेक्टरियाँ अब भी उस पर मौजूद थीं; उन्हें हटाने से 22 GB खाली हुआ। पिछली चेन की डायरेक्टरी को रोलबैक लक्ष्य के रूप में एक दिन तक रखें, फिर उसे हटा दें। पूर्ण ब्लॉकों पर प्रत्येक रॉ बंडल प्रूफ चेन 14 से लगभग 1.42 MB का है (चेन 13 तक लगभग 1.3 MB)। चेन 17 से प्रत्येक बंडल में एक ऑथराइज़ेशन प्रूफ भी होता है, इसलिए एक ट्रांसफ़र में लगभग 2.85 MB के प्रूफ होते हैं: बंडल प्रूफ के लिए लगभग 1.49 MB और ऑथराइज़ेशन प्रूफ के लिए 1.36 MB (प्रोडक्शन प्रोफ़ाइल, 2026-09-29 को मापा गया)। एग्रीगेशन सक्रिय होने पर किसी सील किए गए बंडल के प्रूफ को लगभग 3 KB तक छाँट देता है, बशर्ते नोड --keep-raw-proofs के साथ न चल रहा हो। यह ऑथराइज़ेशन प्रूफ पर लागू नहीं होता, जो पूरे आकार में बना रहता है।

नेटवर्क

सार्वजनिक नोड पर इनबाउंड TCP 30303 खोलें। NAT के पीछे के नोड --bootstrap के साथ बाहर की ओर कनेक्ट करते हैं। पूर्ण 4 MiB ब्लॉकों पर एक वैलिडेटर लिंक लगभग 2 MB/s डेटा वहन करता है।

घड़ी

वैलिडेटर के लिए NTP आवश्यक है। चेन 14 पहली चेन है जिस पर वॉल-क्लॉक समय सहमति (consensus) का हिस्सा है (ब्रिज हार्डनिंग B2):

जिस वैलिडेटर की घड़ी 20 s पीछे है, वह बिना किसी संकेत के वोट देना बंद कर देता है: उसे हर ईमानदार ब्लॉक अपनी घड़ी से आगे दिखता है, वह अपना वोट रोक लेता है, और कुछ भी विफल नहीं होता। चेन 20 पर कुछ भी कमिट करने के लिए छब्बीस में से अठारह का वोट आवश्यक है। हर वैलिडेटर की जाँच करें, और जहाँ घड़ी सिंक्रनाइज़ नहीं है वहाँ chrony इंस्टॉल करें:

timedatectl                     # want "System clock synchronized: yes" and "NTP service: active"
chronyc tracking 2>/dev/null || timedatectl show-timesync --all 2>/dev/null
apt-get install -y chrony && systemctl enable --now chrony

यही 15 s की सीमा जेनेसिस पर भी लागू होती है। timestamp_ms को लॉन्च समय के निकट रखें और कभी उससे आगे नहीं: 15 s से अधिक भविष्य का जेनेसिस तब तक ब्लॉक 1 कमिट नहीं करता जब तक वॉल टाइम उस तक न पहुँच जाए, और बहुत अतीत का जेनेसिस ब्लॉक समय को वॉल क्लॉक से पीछे छोड़ देता है, जो प्रति ब्लॉक अधिकतम 60 s की दर से ही बराबरी कर पाता है (docs/deploy.md)। ऑब्ज़र्वर वोट नहीं देता, इसलिए वोट नियम उस पर लागू नहीं होता।

वे DigitalOcean आकार जिन पर testnet चलता है

यह तालिका मूल अठारह वैलिडेटरों को दर्शाती है। 2026-09-27 से वैलिडेटर A भी लैपटॉप के बजाय एक ड्रॉपलेट (sgp1) पर चलता है। चेन 15 पर (2026-09-27) आठ और वैलिडेटर बॉन्ड किए गए: दो आर्काइव, obs1 और rand-archive-2 (fra1), तथा छह गार्डियन होस्ट। उनके ड्रॉपलेट आकार यहाँ दर्ज नहीं हैं, और न ही यह कि mkc1 और mem1 का आकार बढ़ाया गया या नहीं। चेन 19 की तरह चेन 20 पर भी सभी 26 जेनेसिस वैलिडेटर हैं, प्रत्येक 1,000 RAND के साथ, और 2026-09-30 तक सभी 26 कुंजियाँ एक ही ऑपरेटर के पास हैं।

प्रूविंग मेमोरी

वॉलेट अपने द्वारा भेजे गए हर ट्रांज़ैक्शन का प्रूफ स्वयं बनाता है, इसलिए किसी प्रोग्राम को कॉल करने वाले को उस प्रोग्राम के टियर के लिए आवश्यक मेमोरी चाहिए। ये मापी गई सीमाएँ हैं। टियर-18 रन DigitalOcean पर पूरे हो चुके हैं, प्रूव और सत्यापित हो चुके हैं; टियर-20 नहीं। v0.5.6 से चेन टियर 14 से ऊपर का कॉल प्रूफ अस्वीकार करती है (MAX_CALL_TIER), इसलिए नीचे की टियर-16, 18 और 20 की पंक्तियाँ माप हैं, ऐसे कॉल नहीं जिन्हें चेन 20 स्वीकार करती है; चेन 14 पर कमिट किया गया हर कॉल टियर 10 का था।

ERC-20 कॉल टियर 16 और 18 पर तथा SPL Token टियर 20 पर आते हैं (Ethereum, Solana)। 48 GB मशीन पर टियर 18 या 20 का कोई प्रूफ नहीं बनाया गया है।

एग्रीगेटर

एग्रीगेटर चेन पर नज़र रखता है, फ़ाइनलाइज़ हो चुके ब्लॉकों की एक विंडो के बंडल प्रूफ लेता है, उन पर एक रिकर्सिव एग्रीगेट प्रूव करता है, और उसे सबमिट करता है। जिस ब्लॉक में वह शामिल होता है, वह सीलिंग ब्लॉक कहलाता है। एग्रीगेटर को कवर किए गए बंडलों का प्रूविंग हिस्सा और नए RAND में एक ब्लॉक सब्सिडी, उसके पंजीकृत पेआउट पते पर दी जाती है। एग्रीगेशन अनुमति-रहित है: बॉन्ड वाला कोई भी ऑपरेटर पंजीकरण कर सकता है।

यह केवल उसी चेन पर मौजूद होता है जिसके जेनेसिस में aggregation अनुभाग हो। चेन 20 में ऐसा कोई अनुभाग नहीं है, और उसका बिल्ड ऐसे जेनेसिस पर शुरू होने से इनकार करता है जिसमें यह अनुभाग हो।

हार्डवेयर

N = 2 और N = 3 के आँकड़े 2026-09-28/29 को 256 GB के DigitalOcean ड्रॉपलेट पर, कंस्ट्रेंट सेट 7 के अंतर्गत मापे गए थे, और प्रोडक्शन एग्ज़िट प्रूफ को उस मशीन के 256 GB से अधिक की आवश्यकता पड़ी। कंस्ट्रेंट सेट 8, जिस पर चेन 18 से 20 चलती हैं, के अंतर्गत इनमें से किसी को पुनः नहीं मापा गया है, इसलिए N = 1 पंक्ति को निचली सीमा मानें। CUDA बैकएंड पहली बार 2026-09-28 को वास्तविक हार्डवेयर, एक NVIDIA H100, पर चला: इसके कर्नेल sm_80 और sm_90 के लिए PTX में बिल्ड होते हैं और CPU संदर्भ से मेल खाते हैं। फ़्लीट GPU नोड पर प्रोडक्शन माप अभी बाकी है। हर नोड एग्रीगेट प्रोग्राम के लिए एक बार का स्टार्टअप की-बिल्ड भी करता है: टेस्ट प्रोफ़ाइल (2¹⁹) पर 13.0 से 13.4 s, और प्रोडक्शन (2²¹) पर अपेक्षित 30 से 70 s।

कमांड

# print a signed registration; the bond burns out of a wallet bundle as the register bundle's burn
rand-node aggregator register --key agg.key.json --bond <RAND> --payout rand1… --rpc http://127.0.0.1:8545

# the daemon: poll rand_getUnsealed, fetch the raw bundles, prove, seal the payment note, submit
rand-node aggregate --key agg.key.json --rpc http://127.0.0.1:8545 --watch

# leave, then withdraw the released bond into a note at the payout address
rand-node aggregator unbond --key agg.key.json --rpc http://127.0.0.1:8545
rand-node aggregator withdraw --key agg.key.json --rpc http://127.0.0.1:8545

ऐसी चेन पर rand status एक aggregation खंड दिखाता है: पंजीकृत एग्रीगेटर, अनसील्ड ब्लॉक और सब्सिडी अनुसूची का सूचकांक। rand_getUnsealed कार्य-सूची है।

सेटअप

ये चरण उन स्क्रिप्टों का अनुसरण करते हैं जिनका उपयोग testnet करता है (deploy/vps-setup.sh, deploy/update-droplet.sh)। इनसे एक Linux वैलिडेटर या ऑब्ज़र्वर तैयार होता है।

1. बिल्ड होस्ट पर बिल्ड करें

बिल्ड के लिए build-essential clang cmake pkg-config libssl-dev, Rust 1.98.1 (rust-toolchain.toml द्वारा पिन किया गया), और fullnode चेकआउट के बगल में एक circuits चेकआउट आवश्यक है। पहले बिल्ड में 10 से 20 मिनट लगते हैं।

git clone https://github.com/randprotocol/fullnode
git clone https://github.com/randprotocol/zkp-circuits circuits
cd fullnode
git checkout v0.6.8                       # c9c9bd3c, the build chain 20 runs
git -C ../circuits checkout "$(sed -n 's/^circuits: //p' crates/randprotocol-zkvm/guests-compiled/PROVENANCE.md)"   # aeacf31 for v0.6.8
git show origin/main:deploy/genesis-chain20.json > deploy/genesis-chain20.json   # committed after the tag
cargo build --release -p randprotocol-node -p randprotocol-client
sha256sum target/release/rand-node         # compare on every node you copy it to

Chain 20 को init से पहले हर नोड पर v0.6.8 चाहिए। इसके genesis में ऐसे फ़ील्ड हैं जिन्हें कोई पिछला बिल्ड नहीं पढ़ता (testnet, binding_domain, proof_window_blocks, program_state, ब्रिज के rotation और fees समूह, गैस की ऊपरी सीमाएँ, वोट द्वारा स्टेकिंग प्रवेश), और v0.6.8 में ऑडिट v6 के CON-4 और CH-1 सहमति (consensus) परिवर्तन शामिल हैं। प्रूफ़ अब भी constraint set 8 के अंतर्गत बनाए जाते हैं, जैसे chain 18 और 19 पर, और हर बंडल प्रूफ़ के साथ एक प्राधिकरण प्रूफ़ (hc_auth) होता है। v0.6.8 बिल्ड chain 14 से 17 के genesis को run और verify पर अस्वीकार कर देता है। वही एक बिल्ड चलाएँ जो फ़्लीट चलाता है। genesis फ़ाइल fullnode के main (commit 74cfaca0) पर है, v0.6.8 टैग में नहीं, इसीलिए तीसरी git पंक्ति है। circuits चेकआउट उसी commit पर होना चाहिए जिससे रिलीज़ को vendor किया गया था, जिसे ऊपर की दूसरी git पंक्ति fullnode ट्री से पढ़ती है। rand-prover को भी बिल्ड करने के लिए -p randprotocol-prover जोड़ें।

2. नोड पर बाइनरी इंस्टॉल करें

scp target/release/rand-node target/release/rand deploy/genesis-chain20.json root@<node>:/root/
ssh root@<node> 'install -m 755 /root/rand-node /root/rand /usr/local/bin/'

3. कुंजी, genesis, फ़ायरवॉल

नोड पर:

install -d -m 700 /root/keys
test -e /root/keys/node.key.json || rand-node keygen --out /root/keys/node.key.json   # prints the address; keep the seed secret
rand-node init --datadir /root/data-6210cf07 --genesis /root/genesis-chain20.json
timedatectl                                        # "System clock synchronized: yes" (see Clock)
ufw allow 22/tcp && ufw allow 30303/tcp && ufw enable

कुंजी नोड पर ही बनाएँ, जैसा ऊपर दिखाया गया है, और उसे किसी भी चेकआउट से बाहर रखें। fullnode रिपॉज़िटरी में अब कोई कुंजी ट्रैक नहीं की जाती (ऑडिट v3, OPS-1)। chain 8 से 13 के लिए कमिट की गई deploy/node-*.key.json फ़ाइलें प्रकाशित seeds हैं; chain 20 की वैलिडेटर कुंजियाँ (chain 14 के लिए बनाई गई अठारह और chain 15 पर बॉन्ड की गई आठ) रिपॉज़िटरी से बाहर बनाई गई थीं, और फ़्लीट हर droplet की कुंजी स्रोत ट्री के बाहर /root/keys/node-<name>.key.json में रखता है। फ़्लीट की स्क्रिप्टों से प्रोविज़न किए गए नोड पर यह स्थान मायने रखता है: deploy/rebuild-vps.sh और deploy/push-to-vps.sh /root/fullnode को --delete के साथ rsync करते हैं, इसलिए उस ट्री के भीतर रखी कुंजी अगले रीबिल्ड में हट जाती है और फिर यूनिट पुनः आरंभ होने में विफल रहती है। v0.6.8 से keygen किसी मौजूदा फ़ाइल को अधिलेखित करने से मना करता है (v0.6.7 बिना पूछे उसे अधिलेखित कर देता था); test -e किसी भी स्थिति में पंक्ति को दोबारा चलाना सुरक्षित रखता है। कुंजी को बॉन्ड करने से पहले उसका बैकअप होस्ट से बाहर रखें।

init genesis हैश प्रिंट करता है। यह 6210cf071a390d7ac61d8cbea5dd9d139d1a493a862b54a45a498f36af2d5135 (chain 20) होना चाहिए। genesis फ़ाइल main पर fullnode रिपॉज़िटरी की deploy/ में genesis-chain20.json है। डेटा निर्देशिका का नाम हैश के पहले आठ अक्षरों के आधार पर रखें, जैसा फ़्लीट करता है (data-<name>-6210cf07), ताकि वह chain 19 की (-a3defc93) या किसी बाद की चेन की निर्देशिका से कभी न टकराए। genesis ये सीमाएँ निर्धारित करता है। प्रूफ़ की सीमा chain 13 से 16 पर 8 MiB थी और chain 17 से 4 MiB है, जहाँ से एक लेन-देन में अधिकतम तीन प्रूफ़ होने लगे:

chain 20 के genesis में consensus_domain: 1, binding_domain: 1, testnet: true, वोट द्वारा प्रवेश वाला एक staking खंड, मूल्य की ऊपरी सीमाओं वाला एक gas खंड, ब्रिज के rotation और fees समूह, hardening_v6 और दो guest पिन hc_bundle और hc_auth भी हैं; ये क्या निर्धारित करते हैं, इसकी सूची नोड चलाना में है।

4. एक systemd यूनिट

यह वह यूनिट है जो deploy/vps-setup.sh लिखता है, ऊपर दिए गए पथों के साथ:

[Unit]
Description=RAND full node
After=network-online.target
[Service]
Environment=RUST_LOG=info,libp2p=warn,libp2p_mdns=off
ExecStart=/usr/local/bin/rand-node run --datadir /root/data-6210cf07 --key /root/keys/node.key.json --validator --listen /ip4/0.0.0.0/tcp/30303 --rpc 127.0.0.1:8545 --no-mdns --prune-history 24h --bootstrap <multiaddr> --bootstrap <multiaddr>
Restart=always
RestartSec=3
[Install]
WantedBy=multi-user.target

ऑब्ज़र्वर के लिए --validator हटा दें। testnet के वैलिडेटर, आर्काइव को छोड़कर, --prune-history 24h चलाते हैं; पूरा इतिहास रखने वाले नोड के लिए इसे हटा दें, और mainnet पर इसे कभी न दें। chain 20 के बूटस्ट्रैप multiaddr नोड C (fra1), D (ric1) और E (sgp1) हैं, जो chain 19 से अपरिवर्तित हैं। chain 20 उन वैलिडेटर कुंजियों पर चलती है जो chain 14 के लिए बनाई गई थीं, और p2p पहचान वैलिडेटर कुंजी से व्युत्पन्न होती है, इसलिए ये peer id वही हैं जो chain 14 ने उपयोग किए थे। genesis से सिंक करने वाले नए नोड को एक पूर्ण-इतिहास peer भी चाहिए, इसलिए दो आर्काइव में से एक जोड़ें (obs1, फिर rand-archive-2):

/ip4/164.90.239.200/tcp/30303/p2p/12D3KooWEQEbUwZRgqhDPXhW7vNBmcRcnhUDGUADe81VFdv3ALYe
/ip4/165.245.173.74/tcp/30303/p2p/12D3KooWJyc5oDHggAr89e9QrRFBy9Tg8TxXh18yzrb1SM6KKLYw
/ip4/188.166.235.187/tcp/30303/p2p/12D3KooWSyX84P1DAbWByLHpRBMLRWD53r3Jj4aqVt6tHoF8B2ZQ
/ip4/168.144.46.203/tcp/30303/p2p/12D3KooWS5usdMPvsbaWSaT2xtKndHvDYurwmueoNvaRRarb2wRf
/ip4/206.81.29.236/tcp/30303/p2p/12D3KooWPocyZGcNB9Vp68VSfgVvNXhSzBBoJa4h9R1yMkp71XHh

RPC को 127.0.0.1 पर ही रखें, जब तक कि कोई फ़ायरवॉल उसकी रक्षा न करे। जिस नोड को सार्वजनिक सेवा देनी हो, वह इसके बगल में v0.6.8 का सार्वजनिक listener खोलता है (--public-rpc <ADDR>) और उसके आगे एक प्रॉक्सी लगाता है, --rpc के आगे कभी नहीं (JSON-RPC)। v0.6.7 से लाई गई यूनिट को --prover-accept-spend-key नहीं देना चाहिए, जिसे v0.6.8 स्टार्टअप पर अस्वीकार कर देता है।

systemctl daemon-reload && systemctl enable --now rand-node
journalctl -u rand-node -f
rand status                       # height climbing, peer_count rising

5. वैलिडेटर सेट में शामिल हों

नई कुंजी किसी भी epoch के सेट में नहीं होती। chain 20 पर पहले उसे वोट द्वारा शामिल किया जाना आवश्यक है: इसका genesis staking.admission_by_vote निर्धारित करता है, इसलिए दो-तिहाई से अधिक वोटिंग भार रखने वाले वैलिडेटर प्रत्येक rand-node admit sign --candidate <key or registration> --key <validator key> --genesis-hash <chain 20's hash> से उस पर हस्ताक्षर करते हैं, और कोई एक rand-node admit submit से वोट सबमिट करता है; इसके बाद rand_getAdmitted उसे सूचीबद्ध करता है। फिर उस पर कम से कम 1,000 RAND बॉन्ड करें: rand-node register --key /root/keys/node.key.json --payout rand1… --v2 से एक पंजीकरण प्रिंट करें (chain 20 v1 पंजीकरण अस्वीकार करती है), फिर किसी वॉलेट से rand bond <address> 1000 --registration <hex> से बॉन्ड करें। बॉन्ड अपने सक्रियण epoch की प्रतीक्षा करता है, जो कमिट होने के बाद कम से कम तीन 1,000-ब्लॉक सीमाओं के बाद आता है, और प्रति सीमा सक्रिय भार का अधिकतम 2,500 bps नया भार बनता है (chain 19 ने इसे 10,000 RAND की निश्चित सीमा पर रखा था)। स्टेकिंग इसकी पूरी प्रक्रिया बताता है।

6. अपडेट करना

यह उस बिल्ड पर लागू होता है जो उसी चेन को चलाता है। किसी पिछली चेन से chain 20 पर जाना अपडेट नहीं है: इसके लिए नई बाइनरी, नया genesis और एक नई डेटा निर्देशिका चाहिए, और पुरानी चेन की डेटा निर्देशिका बाद में हटाई जा सकती है (deploy/retire-chain-dirs.sh; फ़्लीट रोलबैक के लिए उसे एक दिन रखता है)। chain cut के बिना नया बिल्ड लागू करने के लिए, एक बार बिल्ड करें, rand-node और rand दोनों का sha256 मिलाएँ, सेवा रोकें, इंस्टॉल करें और पुनः आरंभ करें, एक समय में एक नोड। कुछ रिलीज़ इसके बजाय सभी-रोकें, सभी-शुरू करें विधि से लागू की जाती हैं (v0.5.6 का call-tier नियम, v0.5.7 का Status wire परिवर्तन, v0.6 का अधिक सख़्त प्रूफ़ सत्यापन); हर रिलीज़ के नोट्स बताते हैं कि कौन-सी विधि। v0.6.7 chain 18 पर एक-एक नोड करके लागू हुआ; v0.6.8 chain 20 के साथ आया, सभी-रोकें, सभी-शुरू करें विधि से, क्योंकि इसके CON-4 और CH-1 सहमति परिवर्तन कभी भी नोड-दर-नोड लागू नहीं किए जाने चाहिए। अगले नोड से पहले हर नोड के फिर से जुड़ने की प्रतीक्षा करें, ताकि कोरम में कभी एक से अधिक की कमी न हो। deploy/update-droplet.sh <ip> [build-host] SSH पर ठीक यही करता है।

v0.6.8 तक की रिलीज़ एक ही होस्ट पर हाथ से बिल्ड की गई थीं और हस्ताक्षरित नहीं हैं। v0.6.8 की GitHub रिलीज़ में rand-node, rand, rand-prover और SHA256SUMS हैं, जो नोड E पर बिल्ड किए गए; वह checksum दूषित डाउनलोड को पकड़ता है, पर बिल्ड होस्ट की प्रामाणिकता की पुष्टि नहीं करता। v0.6.8 एक रिलीज़ वर्कफ़्लो के साथ आता है जो टैग से बाइनरी बिल्ड करता है, और deploy/update-droplet.sh हस्ताक्षरित SHA256SUMS के बिना इंस्टॉल अस्वीकार कर देता है, जब तक कि ALLOW_UNSIGNED=1 सेट न हो। deploy/release-signers में अभी कोई कुंजी सूचीबद्ध नहीं है, इसलिए हस्ताक्षरित मार्ग का उपयोग अभी तक नहीं हुआ है।

chain 15, 16, 17 और 18 2.7 दिनों के भीतर (2026-09-26 से 2026-09-29) लाइव हुईं, हर बार पूरे फ़्लीट को रोककर। chain 19 2026-10-01 को 03:43 UTC पर आई, जो उसी बिल्ड पर chain 18 का पुनः-genesis थी, और chain 20 उसी दिन 06:17 UTC पर, जिसे v0.6.8 हार्ड फ़ोर्क पर chain 19 के स्नैपशॉट से काटा गया; हर नोड chain-19 की ऊँचाई 7,700 पर रुका। एक लिखित cut नीति (2026-09-30) chain 20 से आगे लागू होती है; chain 20 के cut रिकॉर्ड ने दूसरे ऑपरेटर के रीबिल्ड की शर्त माफ़ कर दी, क्योंकि सभी कुंजियाँ एक ही ऑपरेटर के पास हैं। cut के लिए ऐसा कारण चाहिए जिसे रोलिंग अपडेट पूरा न कर सके, इसमें क्या शामिल है और क्या हटाया जा रहा है इसकी एक प्रकाशित सूची, पहले से पूरी की गई क्लाइंट रीबिल्ड चेकलिस्ट, एक दूसरा ऑपरेटर जो genesis को उसी हैश पर दोबारा बिल्ड करे, एक रोलबैक योजना, और एक ऐसा chain id जो पहले कभी उपयोग न हुआ हो।