स्टेकिंग

इस पृष्ठ का उपयोग किसी चल रही चेन पर वैलिडेटर सेट में शामिल होने, उससे बाहर निकलने और रजिस्टर को वापस पढ़ने के लिए करें। सहमति (consensus) का भार सार्वजनिक होना आवश्यक है, इसलिए वैलिडेटर रजिस्टर इस चेन की एकमात्र तालिका है जिसमें राशियाँ खुले रूप में दर्ज रहती हैं; फिर भी स्टेक एक शील्डेड नोट से निकलता है और वापस एक शील्डेड नोट में ही जाता है।

रजिस्टर

प्रत्येक उस वैलिडेटर के लिए एक पंक्ति, जिसने कभी बॉन्ड किया हो, जिसकी कुंजी उसका base58 पता है:

ValidatorEntry {
    public_key,                  // Dilithium2: signs blocks, and this validator's staking actions
    stake:    u64,               // bonded: the weight an epoch's set gives it
    pending:  Vec<(u64, u64)>,   // unbonding, as (release_epoch, amount), oldest first
    rewards:  u64,               // fees earned as a block proposer, unpaid
    payout:   ShieldedAddress,   // rand1… — where a withdraw pays
    nonce:    u64,               // replay protection for its signed actions
    activation_epoch: u64,       // under a `staking` section: the first epoch this row may be in a set
}

प्रत्येक फ़ील्ड सार्वजनिक है और रजिस्टर का हैश प्रत्येक ब्लॉक के स्टेट रूट में शामिल होता है। कोई पंक्ति कभी हटाई नहीं जाती: जो वैलिडेटर अपना पूरा स्टेक अनबॉन्ड कर देता है, उसकी पंक्ति stake = 0 के साथ बनी रहती है।

एपॉक

epoch(h) = h / epoch_blocks। एपॉक e ≥ 1 का सेट एपॉक e − 1 के अंतिम ब्लॉक की स्थिति के अनुसार रजिस्टर से निकाला जाता है: stake ≥ MIN_STAKE वाली प्रत्येक पंक्ति, (stake descending, address ascending) के क्रम में शीर्ष MAX_VALIDATORS, पते के अनुसार क्रमबद्ध। किसी व्यू का लीडर, किसी ब्लॉक के मतदाता और किसी सर्टिफ़िकेट का सत्यापन, ये सभी उस एपॉक के सेट का उपयोग करते हैं जिससे वह ब्लॉक संबंधित है। इसके दो परिणाम हैं:

• बॉन्ड किसी बाद की सीमा तक भार नहीं बनता। वह रजिस्टर में तुरंत दर्ज हो जाता है, किंतु सेट केवल किसी सीमा पर बदलता है: staking खंड के बिना वाली चेन पर अगली सीमा पर, chain 20 पर उससे बाद में (नीचे)।
• अनबॉन्ड से भार अगली सीमा पर ही घट जाता है, जबकि राशि निकासी योग्य होने के लिए दो एपॉक प्रतीक्षा करती है। कोई वैलिडेटर निकासी कर पाने से बहुत पहले ही प्रस्ताव देना बंद कर देता है।

यदि निकाला गया सेट खाली हो, तो पिछला सेट आगे बढ़ा दिया जाता है। --validator के साथ शुरू किया गया नोड, जिसकी कुंजी किसी वर्तमान सेट में नहीं है, तब तक केवल प्रेक्षण करता है जब तक कोई एपॉक उसे शामिल न कर ले, इसलिए जेनेसिस के बाद बॉन्ड करके जुड़ने वाले वैलिडेटर को पुनः आरंभ की आवश्यकता नहीं होती; rand_status, is_validator (कुंजी यहाँ है) और active_validator (वह वर्तमान सेट में है) को अलग-अलग बताता है।

स्टेकिंग खंड

किसी जेनेसिस में एक staking खंड हो सकता है (fullnode v0.5.4, audit v4 STAKE-2)। इसके बिना ऊपर दिए नियम ही पूरी व्यवस्था हैं, जैसा chain 14 पर है। chain 15 के बाद की प्रत्येक चेन में यह खंड है। chain 20 में सक्रिय विकल्प:

"staking": {
  "faucet_budget_per_epoch": "10000000000000", "bond_activation_epochs": 2,
  "max_weight_bps": 3333, "max_stake_entry_bps_per_epoch": 2500,
  "admission_by_vote": true, "registration_v2": true,
  "faucet_recipients": ["rand1…", "…16 wallets…"],
  "faucet_minters": ["<validator address>", "…18 validators…"]
}

इस खंड के अंतर्गत फॉसेट काउंटर और बॉन्ड कतार rand-state-5 डोमेन के अंतर्गत स्टेट रूट में जोड़े जाते हैं, और वैलिडेटर लीफ़ rand-validator-leaf-4 होता है। chain 20 में डायनेमिक गैस मूल्य और RPL-2 प्रोग्राम स्टेट भी हैं, जो इनके बाद जोड़े जाते हैं और इसके डोमेन को rand-state-8 पर ले जाते हैं, और मत द्वारा प्रवेश उस रूट को एक बार और H("rand-state-admitted-1", root ‖ admitted_root) के रूप में लपेटता है। chain 15 में कोई faucet_minters सूची नहीं थी: वहाँ प्रत्येक नोड फॉसेट के Mint को पूल में केवल तभी रखता और आगे भेजता था जब उस पर किसी जेनेसिस वैलिडेटर ने हस्ताक्षर किए हों (MinterNotAllowed, नोड नीति के रूप में), ताकि जेनेसिस के बाद बॉन्ड हुआ कोई वैलिडेटर पूल के माध्यम से बजट खाली न कर सके। सूची होने पर यही अस्वीकृति एक वैधता नियम बन जाती है।

इतिहास: chain 15 से 19 तक admission_by_vote नहीं था, इसलिए 1,000 RAND रखने वाली कोई भी कुंजी पंजीकरण कर सकती थी, और उनमें प्रवेश बजट प्रति सीमा 10,000 RAND के निश्चित max_stake_entry_per_epoch के रूप में तय था। निश्चित आँकड़ा किसी एक जेनेसिस के अनुरूप होता है; अंश किसी प्रवेशक को स्टेक चाहे जितना हो, समान हिस्से तक सीमित रखता है। दोनों फ़ील्ड एक साथ सेट नहीं किए जा सकते।

मत द्वारा प्रवेश

fullnode v0.6.8 (audit v6, STAKE-2) में नया, और chain 20 के लिए सक्रिय। 1,000 RAND प्रत्येक वाली 26 कुंजियों के साथ, सेट का अवरोधक एक-तिहाई लगभग 13,000 RAND का खरीदा गया स्टेक है, और कुछ भी स्लैश नहीं होता। इस नियम के अंतर्गत सेट तय करता है कि कौन-सी नई कुंजियाँ पंजीकरण कर भी सकती हैं।

• मत एक एक्शन है, AdmitValidator { candidate, signatures }, बिना बंडल और बिना शुल्क। प्रत्येक हस्ताक्षर blake3("rand-admit-validator-1" ‖ genesis hash ‖ candidate address) पर किसी वैलिडेटर का Dilithium2 हस्ताक्षर है, मतदाताओं के पतों के आरोही क्रम में। मतदाताओं के पास मतदान सेट के भार का दो-तिहाई से निश्चित रूप से अधिक होना चाहिए, जो क्वोरम सर्टिफ़िकेट का ही गणित है: chain 20 पर 26 में से 18 वैलिडेटर। मत एक जेनेसिस से बंधा होता है और उसे किसी nonce की आवश्यकता नहीं: प्रवेश उसी पंजीकरण में उपभोग हो जाता है जिसकी वह अनुमति देता है।
• मतदान सेट वर्तमान एपॉक के लिए रजिस्टर से स्वयं निकाला गया सेट है। कतार में रखा बॉन्ड उसमें भार नहीं होता, और अनबॉन्ड उसे तुरंत छोड़ देता है। कोई उम्मीदवार स्वयं को मत देकर प्रवेश नहीं दिला सकता।
• स्वीकृत सेट सहमति स्टेट है, जिसमें पंजीकरण की प्रतीक्षा कर रही अधिकतम 256 कुंजियाँ होती हैं (इससे अधिक पर AdmissionSetFull)। rand_getAdmitted इसे प्रदान करता है; rand_getLimits.admission_by_vote बताता है कि किसी चेन को मत की आवश्यकता है या नहीं।

# each voting validator, offline
rand-node admit sign --candidate <registration hex or public key> --key node.key.json --genesis-hash <hash>
# whoever collects the lines
rand-node admit submit --candidate <…> --signature <line> --signature <line> … --rpc http://127.0.0.1:8545

इसके बाद बॉन्ड नीचे बताए अनुसार आगे बढ़ता है। rand_getGenesisHash वह हैश लौटाता है जिसकी admit sign को आवश्यकता होती है।

चार कमांड

कौन-सी बाइनरी किस एक्शन की स्वामी है, यह इस बात से तय होता है कि उस पर कौन-सी कुंजी हस्ताक्षर करती है: बॉन्ड नोट खर्च करता है, इसलिए वह वॉलेट कमांड है; अनबॉन्ड और निकासी पर वैलिडेटर की Dilithium2 कुंजी से हस्ताक्षर होते हैं, जो केवल नोड के पास होती है।

पंजीकरण

rand-node register --key node.key.json --payout "$(rand --key payout.key.json address)" --v2 [--rpc http://127.0.0.1:8545]

वैलिडेटर का पता और एक hex Registration प्रिंट करता है: उसकी सार्वजनिक कुंजी, पेआउट पता और एक हस्ताक्षर। --v2 के साथ, जो chain 20 के लिए आवश्यक है, हस्ताक्षर चेन के जेनेसिस हैश, chain id, वैलिडेटर के पते और पेआउट पर rand-register-2 के अंतर्गत होता है; इसके बिना v1 रूप, blake3("rand-register" ‖ bincode(chain_id, payout)), जिसे chain 20 अस्वीकार करता है (chain 20 जैसी binding_domain: 1 चेन पर पंजीकरण संदेश हर स्थिति में v2 वाला ही होता है)। chain id के लिए और --v2 के साथ जेनेसिस हैश के लिए RPC पढ़ा जाता है, इसलिए एक चेन के लिए हस्ताक्षरित पंजीकरण किसी दूसरी चेन पर अस्वीकार हो जाता है। पेआउट पता एक वॉलेट पता है, नोड कुंजी नहीं, और यही वह एकमात्र फ़ील्ड है जिसे बाद का कोई टॉप-अप बदल नहीं सकता। यह hex उसे सौंपें जिसके पास स्टेक है।

बॉन्ड

rand bond <validator base58> <amount in RAND> [--registration <hex>] [--fee <RAND>] [--no-wait] [--cuda]

एक सामान्य परिरक्षित लेनदेन: वॉलेट वह 4-इनपुट 4-आउटपुट छिपी-परिसंपत्ति बंडल प्रमाणित करता है जो chain 14 से हर लेनदेन में रहा है, और स्टेक की गई राशि उसके RAND बर्न, burn_r, में होती है; लेजर बॉन्ड को तभी स्वीकार करता है जब burn_r == amount हो। chain 20 पर बंडल में दो प्रमाण होते हैं, जैसा chain 17 से हर बंडल में रहा है: tier-14 बंडल प्रमाण और स्पेंड कुंजी पर एक tier-10 प्राधिकरण प्रमाण। डिफ़ॉल्ट रूप से दोनों स्थानीय रूप से प्रमाणित किए जाते हैं, Apple Silicon लैपटॉप पर लगभग दो मिनट में (प्रमाणन मेमोरी)। वॉलेट के --prover विकल्प के साथ बंडल प्रमाण इसके बजाय एक युग्मित प्रूवर बनाता है, और प्राधिकरण प्रमाण वॉलेट की मशीन पर ही रहता है। --registration ठीक तभी आवश्यक है जब वैलिडेटर अभी रजिस्टर में न हो, और जब वह रजिस्टर में हो तब अस्वीकार किया जाता है; वॉलेट पहले रजिस्टर से पूछता है। chain 20 पर पंजीकरण वाला बॉन्ड NotAdmitted के साथ अस्वीकार किया जाता है, जब तक कि सेट ने पहले उस कुंजी को वोट देकर शामिल न किया हो (वोट द्वारा प्रवेश); टॉप-अप के लिए किसी वोट की आवश्यकता नहीं है। पंजीकरण वाला बॉन्ड कम से कम 1,000 RAND का होता है; टॉप-अप शून्य से अधिक कोई भी राशि हो सकता है। चेन को केवल यह पता चलता है कि इस वैलिडेटर का स्टेक इतना बढ़ा; किन नोटों से भुगतान हुआ और वे किसके थे, यह ट्रांसफ़र की तरह छिपा रहता है — कोई भी व्यक्ति राशि के अलावा कुछ भी प्रकट किए बिना किसी वैलिडेटर पर स्टेक कर सकता है।

submitted bond 8c3f…e1
  0 RAND out, 1000 RAND burned, 0.999 RAND change, fee 0.001 RAND, anchored at height 412
2nRdFC…: stake 1000 RAND, counting as consensus weight from epoch 69

वॉलेट जो एपॉक प्रिंट करता है, वह अगली सीमा है। इसमें सक्रियण विलंब की गणना नहीं होती: chain 20 पर एपॉक 68 में कमिट हुआ बॉन्ड सबसे पहले एपॉक 71 से भार बनता है, और यदि प्रवेश बजट, यानी प्रति सीमा सक्रिय भार का एक-चौथाई, खर्च हो चुका हो तो और बाद में।

अनबॉन्ड

rand-node unbond <amount in RAND> --key node.key.json [--rpc …] [--no-wait]

amount को stake से pending में release_epoch = epoch + 2 के साथ ले जाता है और नॉन्स बढ़ाता है। यह निःशुल्क और बंडल-रहित है, chain 14 से 19 तक blake3("rand-unbond" ‖ bincode(chain_id, validator, amount, nonce)) पर और chain 20 पर (जेनेसिस binding_domain: 1) blake3("rand-unbond-2" ‖ bincode(genesis_hash, chain_id, validator, amount, nonce)) पर हस्ताक्षरित होता है; यह एक ब्लॉक के समय में कमिट हो जाता है। rand-node v0.6.8 उस चेन के अनुसार रूप चुनता है जिससे वह संवाद करता है। स्टेक से अधिक, या शून्य, अनबॉन्ड करना अस्वीकार किया जाता है; एक एपॉक में किए गए कई अनबॉन्ड एक ही pending पंक्ति में विलय हो जाते हैं।

निकासी

rand-node withdraw <amount in RAND> --key node.key.json [--rpc …] [--no-wait]

मुक्त हुए मूल्य — rewards और वे pending पंक्तियाँ जिनका release_epoch आ चुका है, सबसे पुरानी पहले — का भुगतान रजिस्टर के payout पते पर एक जमा नोट में करता है। यह वैलिडेटर-हस्ताक्षरित है (chain 20 पर rand-withdraw-2 के अंतर्गत, अनबॉन्ड की तरह पहले जेनेसिस हैश पर) और बंडल-रहित है, पर निःशुल्क नहीं: 0.001 RAND का आधार शुल्क राशि में से उस ब्लॉक के प्रस्तावक को जाता है जो इसे लागू करता है, इसलिए 1,000 RAND की निकासी से 999.999 मूल्य का नोट बनता है, और जो राशि आधार शुल्क को पूरा नहीं कर सकती वह अस्वीकार की जाती है। चेन नोट की गणना स्वयं करती है:

cm = H_CM(payout.pk, from = 0, amount − 0.001 RAND, asset 0, time, r)

time कमांड चलने के समय की हेड ऊँचाई है (प्रिंट की जाती है, और हस्ताक्षर से बँधी होती है), जो बंडल विंडो के भीतर कहीं भी स्वीकार्य है (chain 20 पर 1,024 ब्लॉक, जिसका जेनेसिस proof_window_blocks निर्धारित करता है; पहले की चेनों पर 256); r प्रकाशित किया जाता है ताकि चेन कभी नेटवर्क से आई कोई प्रतिबद्धता स्वीकार न करे। इसके बाद पेआउट वॉलेट स्कैन करके नोट ढूँढ़ लेता है, उसे कुछ भी बताए बिना:

rand --key payout.key.json balance      # balance: 999.999 RAND

जुड़ना और छोड़ना

# on the joining validator's machine
rand-node register --key node.key.json --payout "$(rand --key payout.key.json address)" --v2
rand-node run --datadir ./data --key node.key.json --validator --bootstrap /ip4/…/p2p/…
#   it syncs and observes; rand_status says is_validator true, active_validator false

# on chain 20: validators holding more than two thirds of the weight vote the key in
rand-node admit sign --candidate <hex from above> --key <their node.key.json> --genesis-hash <hash>
rand-node admit submit --candidate <hex from above> --signature <line> … --rpc http://127.0.0.1:8545

# on the machine holding the stake
rand bond <validator base58> 1000 --registration <hex>
rand validators                       # the new row, active false until it activates

# from its activation epoch on (on chain 20, three boundaries after the bond at the earliest)
rand-node status                      # active_validator: true

rand-node unbond 1000 --key node.key.json     # out of the set at the next boundary
#   wait two epochs
rand-node withdraw 1000 --key node.key.json    # a note worth 999.999 RAND at the payout address

अनबॉन्ड करने से पहले कोरम का गणित जाँच लें: n के सेट को अपने स्टेक के 2/3 से अधिक का ऑनलाइन होना आवश्यक है। chain 20 पर सभी 26 वैलिडेटर ठीक MIN_STAKE पर हैं, इसलिए कोई भी अनबॉन्ड उस नोड को अगले एपॉक के सेट से बाहर कर देता है, और 26 में से 18 का चालू रहना आवश्यक है। जो वैलिडेटर चालू है पर वोट नहीं देता, वह भी कोरम के विरुद्ध गिना जाता है: chain 14 से कोई वैलिडेटर ऐसे ब्लॉक पर अपना वोट रोक लेता है जो उसकी अपनी घड़ी से 15 s से अधिक आगे हो, इसलिए जिस वैलिडेटर की घड़ी धीमी चलती है वह बिना किसी त्रुटि के वोट देना बंद कर देता है। उस पर NTP चलाएँ (वैलिडेटर चलाना)।

जेनेसिस रजिस्टर को सीधे भरता है — प्रत्येक --validator <key or hex pubkey>,<stake>,<payout> के लिए एक प्रविष्टि — और न्यूनतम से कम स्टेक को अस्वीकार करता है। chain 20 का जेनेसिस 1,000 RAND प्रत्येक की 26 पंक्तियाँ भरता है, वही कुंजियाँ जो chain 19 की थीं।

v0.5.11 से बिल्ड में जेनेसिस वेस्टिंग भी शामिल है: समयबद्ध आवंटनों का एक सार्वजनिक रजिस्टर, जिससे कोई अपरिवर्तनीय प्रविष्टि लॉक किए गए RAND को वैलिडेटर के स्टेक के रूप में बॉन्ड कर सकती है (rand-node vesting bond) और उसे वापस ले सकती है (rand-node vesting unbond)। इसके लिए जेनेसिस में vesting अनुभाग आवश्यक है। किसी भी चेन में यह नहीं है, chain 20 सहित, और इसके बिना वे क्रियाएँ प्रवेश पर ही अस्वीकार की जाती हैं। (v0.6.8 किसी परिवर्तनीय वेस्टिंग प्रविष्टि को केवल हस्ताक्षरकर्ताओं की एक सीमा-संख्या द्वारा, एक निश्चित ट्रेज़री के पक्ष में, निरस्त करने की अनुमति भी देता है, यह भी केवल vesting अनुभाग के अंतर्गत।)

क्या सार्वजनिक है

पुरस्कार उन ब्लॉकों के शुल्क हैं जिन्हें किसी वैलिडेटर ने प्रस्तावित किया। कोई ब्लॉक पुरस्कार नहीं है और कोई मुद्रास्फीति नहीं है, और chain 20 पर वैलिडेटरों की कोई स्लैशिंग नहीं है और कोई जेलिंग नहीं है: दुर्व्यवहार करने वाले वैलिडेटर का स्टेक नहीं कटता, और उपाय ऑपरेटरों के हाथ में है। Fullnode v0.6.8 में लीडर इक्विवोकेशन के लिए एक स्लैशिंग नियम अवश्य है (audit v6, STAKE-1: एक कुंजी द्वारा एक व्यू के लिए दो हस्ताक्षरित ब्लॉक हेडर स्टेक का equivocation_bps नष्ट कर देते हैं और कुंजी को जेल में डाल देते हैं), पर केवल जेनेसिस के staking.slashing अनुभाग के अंतर्गत, और chain 20 में ऐसा कोई अनुभाग नहीं है (rand_getLimits.slashing का मान null है); fullnode इसकी अनुशंसा तभी करता है जब स्टेक एक से अधिक ऑपरेटरों के पास हो। (ब्लॉक-एग्रीगेशन कोड में उन एग्रीगेटरों के लिए एक SlashAggregator क्रिया भी है जो एक ही नॉन्स पर दो भिन्न एग्रीगेट हस्ताक्षरित करते हैं, और यह chain 20 पर सक्रिय नहीं है, जिसमें कोई एग्रीगेशन अनुभाग नहीं है।)

इसे वापस पढ़ना

rand validators        # the whole register
rand status            # is_validator / active_validator for the node asked

→ {"method":"rand_getValidators","params":[]}
← [{ "address": "2nRdFC…", "stake": "1000000000000",
     "pending": [{ "release_epoch": 71, "amount": "1000000000000" }],
     "rewards": "4000000", "payout": "rand1…", "nonce": 3, "active": true, "jailed_until": null }]
→ {"method":"rand_getAdmitted","params":[]}
← { "admission_by_vote": true, "admitted": [], "max": 256 }
→ {"method":"rand_getEpoch","params":[]}
← { "epoch": 69, "epoch_blocks": 1000, "next_set": ["2nRdFC…", "ByDkxs…"] }

राशियाँ इकाइयों की दशमलव स्ट्रिंग होती हैं। active बताता है कि पंक्ति वर्तमान एपॉक चला रहे सेट में है या नहीं; jailed_until स्लैशिंग अनुभाग के अतिरिक्त हमेशा null होता है; admitted उन कुंजियों को सूचीबद्ध करता है जिन्हें वोट देकर शामिल किया गया है पर जिन्होंने अभी पंजीकरण नहीं किया; next_set एक अनुमान है जिसे सीमा से पहले का हर बॉन्ड और अनबॉन्ड बदल देता है। एक्सप्लोरर का GET /validators इसमें share_percent, blocks_proposed और अंतिम प्रस्तावित ऊँचाई जोड़ता है।