खाते और पते

यह पृष्ठ बताता है कि किस काम के लिए कौन-सी कुंजी बनानी है, किसी address को parse या सत्यापित कैसे करना है, और किसी को कुंजी सौंपने पर क्या प्रकट होता है। इस चेन पर कोई खाते नहीं हैं: बैलेंस किसी कुंजी फ़ाइल से जुड़ा तथ्य है, चेन से जुड़ा कभी नहीं।

दो कुंजियाँ, दो प्रकार के address

ये दोनों कभी आपस में नहीं मिलतीं। वैलिडेटर पहले प्रकार से पहचाने जाते हैं, और Dilithium2 कुंजी का यही स्वरूप किसी टोकन की Key mint authority (rand token create --authority-key-out rand-node keygen के स्वरूप वाली फ़ाइल लिखता है), bridge की pause key और उसकी छह post-quantum guardian कुंजियों के काम आता है। Guardians की attestation कुंजियाँ secp256k1 हैं, जिनके address Ethereum-शैली के 20-बाइट हैं (Bridge)। मूल्य दूसरे प्रकार की कुंजी के अधीन रखा जाता है।

पारदर्शी address

नोड कुंजी एक 32-बाइट seed है, जिससे Dilithium2 कुंजी-युग्म नियतात्मक रूप से व्युत्पन्न होता है: 1,312-बाइट की सार्वजनिक कुंजी और 2,420-बाइट के हस्ताक्षर। Address सार्वजनिक कुंजी का domain-separated BLAKE3 hash है, जिसे base58 में लिखा जाता है:

address = blake3("rand-address" || public_key)      // 32 bytes, shown as base58

हस्ताक्षरित वस्तुएँ (वोट, ब्लॉक, mint, staking क्रियाएँ) पूरी सार्वजनिक कुंजी साथ रखती हैं, इसलिए verifier केवल address पर भरोसा करने के बजाय blake3("rand-address" || public_key) == address की जाँच करता है। इसी seed से नोड की libp2p पहचान भी मिलती है, जो blake3("rand-p2p-identity" || seed) से बनी ed25519 कुंजी है; यही bootstrap multiaddr में /p2p/ के बाद आने वाला peer id है।

rand-node keygen --out node.key.json      # prints the address
rand-node address --key node.key.json     # address, public key (hex), libp2p peer id

उदाहरण: EdrEC2QRQrQF64iRXxF9927jNj6RidiHHByzx5xD6F1e चेन 20 के वैलिडेटरों में से एक है। चेन 15 से 20 तक चेन 14 के लिए बदली गई अठारह कुंजियों का ही पुनः उपयोग होता है, इसलिए उनके address और peer id अपरिवर्तित हैं और चेन 13 का कोई भी वैलिडेटर address या peer id अब उपयोग में नहीं है; चेन 15 पर आठ और वैलिडेटर bond हुए, और चेन 16 से सभी 26 genesis फ़ाइल में हैं।

Shielded address

वॉलेट एक ही गुप्त मान है, 256-बिट की spend key sk, और बाकी सब कुछ उसी से व्युत्पन्न होता है। व्युत्पत्ति Poseidon2 है, जिसमें पहला absorb किया गया शब्द एक domain tag होता है (H(domain, msg)); यह वही फ़ंक्शन है जिसे zkVM circuit में गणना करता है:

spend key   sk                          256 bits, in wallet.key.json
   │
   ├─ viewing key   nk = H(NK, sk)      sees the whole history; cannot spend
   │     ├─ pk = H(PK, nk)              the field a note names its owner by
   │     ├─ nullifier(cm) = H(NF, nk, cm)   what a spend publishes
   │     ├─ ovk                         opens envelopes this wallet sent
   │     └─ ML-KEM-768 decapsulation key    opens envelopes sent to this wallet
   └─ address   rand1 + base58(pk || kem_ek)

Address में pk के 32 बाइट के बाद 1,184-बाइट की ML-KEM-768 encapsulation key आती है, और rand1 उपसर्ग के बाद यह base58 में होता है: 1,665 या 1,666 वर्ण (base58 लंबाई शुरुआती बाइट्स पर निर्भर करती है; लगभग चौदह में से एक address छोटा होता है), लगभग 1.6 KB, और कोई checksum नहीं। नोट envelope को सील करने के लिए प्रेषक को encapsulation key चाहिए, इसीलिए वह address में है। यह जानबूझकर सार्वजनिक है: कोई भी इसे भुगतान कर सकता है, और इसे रखने से यह पता नहीं चलता कि इसमें क्या रखा है।

rand keygen                      # wallet.key.json; refuses to overwrite an existing file
rand address                     # rand1… on stdout, its fingerprint XXXX-XXXX-XXXX-XXXX on stderr

v0.5.10 से rand address stdout पर ठीक address और एक newline प्रिंट करता है, इसलिए $(rand address) स्क्रिप्ट में काम करता है। Fingerprint stderr पर जाता है।

Parsing, ठीक वैसे ही जैसे ShieldedAddress::parse करता है: rand1 हटाएँ, base58-decode करें, और ठीक 32 + 1,184 = 1,216 बाइट अनिवार्य करें; पहले 32 बाइट आठ little-endian u32 शब्दों के रूप में pk हैं, शेष encapsulation key। RPC 2,000 वर्णों से लंबे किसी भी पैरामीटर को parse करने से पहले ही अस्वीकार कर देता है।

कुंजी फ़ाइल के साथ वॉलेट <key>.key.json.notes.json रखता है, जो उन नोटों का cache है जिन्हें इस कुंजी ने खोला है। इसमें नोटों के plaintext होते हैं, इसलिए यह कुंजी की तरह mode 0600 में लिखा जाता है; इसकी हर पंक्ति leaf 0 से दोबारा स्कैन करके पुनः प्राप्त की जा सकती है।

Address साझा करना: fingerprint और randpay: लिंक

Address इतना लंबा है कि उसे ज़ोर से पढ़ा या आँख से मिलाया नहीं जा सकता, और उसमें कोई checksum नहीं होता, इसलिए v0.5.10 से हर वॉलेट उसके साथ एक fingerprint दिखाता है। Fingerprint केवल प्रदर्शन के लिए है: चेन पर या नेटवर्क पर कुछ भी इसे साथ नहीं रखता।

fingerprint = first 80 bits of blake3("rand-address-fingerprint-1" || pk_bytes || kem_ek)
            = 16 Crockford base32 characters, shown as XXXX-XXXX-XXXX-XXXX

Hash उन 1,216 कच्चे बाइट्स पर है जिन्हें address encode करता है। वर्णमाला 0123456789ABCDEFGHJKMNPQRSTVWXYZ है; parsing केस और हाइफ़न को अनदेखा करता है और O को 0 तथा I या L को 1 पढ़ता है।

एक randpay: लिंक एक address और, वैकल्पिक रूप से, उसे क्या भुगतान करना है, यह साथ रखता है:

randpay:<rand1…>[?amount=<decimal>][&asset=<index | 64 hex | rpl1…>][&memo=<percent-encoded UTF-8>]

amount asset की प्रदर्शन इकाइयों में होता है (RAND के लिए नौ दशमलव स्थानों तक दशमलव, किसी टोकन के लिए उसकी registry पंक्ति के अपने decimals) और शून्य नहीं होना चाहिए। memo अधिकतम 510 बाइट का UTF-8 है। Scheme का मिलान केस की परवाह किए बिना होता है; अज्ञात पैरामीटर, दोहराया गया पैरामीटर, या गलत percent-encoding अस्वीकार कर दिया जाता है।

rand address --uri --amount 1.5 --memo "invoice #42" --qr   # a randpay: link, as a terminal QR
rand contacts add alice rand1q9f…                            # shows the fingerprint, asks add? [y/N]
rand send alice 1.5 --memo "coffee"                          # to a contact, with a memo

rand send <TO> एक rand1… address, एक randpay: लिंक या सहेजे गए संपर्क का नाम लेता है, और इसी क्रम में आज़माता है। लिंक का amount, asset और memo वह भर देते हैं जो कमांड लाइन में छूट जाता है, और दोनों तरह से दिया गया कोई मान यदि मेल नहीं खाता तो अस्वीकार कर दिया जाता है। Proving से पहले send to <contact, if any> · fingerprint XXXX-XXXX-XXXX-XXXX · <amount> <asset> प्रिंट करता है और पुष्टि माँगता है; स्क्रिप्ट --yes पास करती है। संपर्क कुंजी के साथ <key>.contacts.json में, mode 0600 में, संग्रहीत होते हैं। Memo नोट envelope के भीतर जाता है (नोट)।

कोई rand balance <address> नहीं है और कोई balance RPC नहीं है: चेन किसी के लिए भी इसका उत्तर नहीं दे सकती। वॉलेट अपनी viewing key से चेन के हर envelope को स्कैन करके अपना बैलेंस निकालता है (नोट)।

वे कुंजियाँ जो आप किसी और को सौंप सकते हैं

प्रकटीकरण कुंजियों का गुण है, और चेन इसमें से कुछ भी बाध्य नहीं कर सकती।

Viewing key खर्च नहीं कर सकती। चेन 17 (विभाजित प्राधिकरण) से bundle proof स्वयं nk से बनता है, और हर bundle एक दूसरा, छोटा auth proof भी साथ रखता है जिसे केवल spend key बना सकती है और जो उसी एक लेनदेन से बंधा होता है (नोट)। इसी के कारण किसी प्रत्यायोजित prover को nk, और इस तरह वॉलेट का पूरा इतिहास, सौंपा जा सकता है, बिना उसे खर्च करने की क्षमता दिए; वॉलेट auth proof हमेशा अपनी ही मशीन पर बनाता है। इस विभाजन से address, कुंजियाँ और मौजूदा नोट अपरिवर्तित रहते हैं। वॉलेट हर बार चलने पर nk व्युत्पन्न करता है और उसे कभी संग्रहीत नहीं करता; हर TxKey प्रत्येक envelope के लिए नए सिरे से बनाई जाती है और सील करने के बाद हटा दी जाती है। किसी नोड को rand_importViewingKey से viewing key सौंपी जा सकती है (मेमोरी में, प्रति नोड अधिकतम 64, restart पर समाप्त) ताकि वह धारक की ओर से स्कैन करे — यही explorer का तरीका है — और rand_checkTransaction(hash, key) एक stateless call में किसी TxKey के विरुद्ध एक भुगतान की जाँच करता है। rand viewing-key nk प्रिंट करता है, और rand tx-key <hash> ऐसे लेनदेन के हर output की कुंजी प्रिंट करता है जिसे यह वॉलेट खोल सकता है।

टोकन id address नहीं हैं

RPL टोकन का एक तीसरे प्रकार का पाठ-पहचानकर्ता होता है, और वह किसी टोकन का नाम देता है, किसी धारक का कभी नहीं। टोकन की 32-बाइट asset id 64 hex वर्णों के रूप में और rpl1… के रूप में दिखाई जाती है: 32 id बाइट्स पर human-readable part rpl के साथ bech32m (BIP-350), 52 डेटा वर्ण और 6 वर्णों का checksum, 62 वर्ण। Parsing सख़्त है: गलत checksum, कोई अन्य human-readable part, ठीक 32 बाइट न होने वाला payload, या मिश्रित केस अस्वीकार कर दिया जाता है, ताकि कोई टाइपो कभी किसी दूसरे टोकन तक न पहुँचे। नोट id साथ नहीं रखता; उसका asset शब्द टोकन का सघन registry index है (RPL टोकन)।

Bridge प्राप्तकर्ता

Bridge के wire format में 32-बाइट का प्राप्तकर्ता स्लॉट है, और shielded address उसमें नहीं समाता। आज यह स्लॉट address का hash रखता है:

recipient_hash = blake3("rand-shielded-recipient" || pk_bytes || kem_ek)

स्रोत-चेन का जमाकर्ता hash का नाम देता है, guardians उस पर हस्ताक्षर करते हैं, और BridgeAttest लेनदेन पूरा address साथ रखता है ताकि लेजर उसके विरुद्ध जाँच कर सके (Bridge)।

छोटा shielded address: चेन 11 पर आज़माया गया, वापस लिया गया

चेन 11 (fullnode टैग v0.2, 2026-09-17) ने लंबे पते के स्थान पर 53 से 55 अक्षरों की प्राप्तकर्ता आईडी, rand1 + base58(blake3(प्राप्तकर्ता हस्ताक्षर कुंजी) ‖ चेकसम), लागू की, और ML-KEM एनकैप्सुलेशन कुंजी को एक हस्ताक्षरित प्राप्तकर्ता रिकॉर्ड में स्थानांतरित कर दिया, जिसे प्रेषक एक्सप्लोरर की रजिस्ट्री से प्राप्त करता था या किसी भुगतान अनुरोध में इनलाइन पाता था। यह एक दिन चला और उसी दिन वापस ले लिया गया (fullnode 17db41d); चेन 12 फिर से लंबे पते पर लौट आई, ठीक वैसे ही जैसा ऊपर वर्णित है, और उसके बाद की प्रत्येक चेन, चेन 20 सहित, उसी को बनाए रखती है।

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

चेन 11 का विनिर्देश और उसका कार्यान्वयन fullnode इतिहास (docs/superpowers/specs/2026-09-17-short-shielded-address.md, टैग v0.2) में उन हिस्सों के लिए बने रहते हैं जिन्हें हाइब्रिड डिज़ाइन पुनः उपयोग करता है: व्युत्पन्न प्राप्तकर्ता हस्ताक्षर कुंजी, हस्ताक्षरित रिकॉर्ड और उसका सत्यापनकर्ता, तथा चेन स्थिति के रूप में रजिस्ट्री।