यह पृष्ठ बताता है कि इस चेन पर टोकन क्या होता है। किसी टोकन को बनाने, सूचीबद्ध करने या इंडेक्स करने से पहले इसे पढ़ें। RPL, Rand का टोकन मानक है, जो चेन 14 में नया आया। टोकन एक शील्डेड नेटिव एसेट है: लेजर रजिस्ट्री में एक प्रविष्टि। इसके बैलेंस साधारण नोटों के रूप में उसी कमिटमेंट ट्री में रहते हैं जिसका उपयोग RAND करता है। यह कोई कॉन्ट्रैक्ट नहीं है। टोकन बनाने की चरण-दर-चरण विधि के लिए RPL टोकन डिप्लॉय करें देखें।
इसका कारण संरचनात्मक है। एक Call केवल एक रसीद लिखता है, इसलिए ERC-20 जैसे कॉन्ट्रैक्ट के पास बैलेंस रखने की कोई जगह नहीं थी। सार्वजनिक बैलेंस तालिका रखने पर टोकन एक शील्डेड चेन की इकलौती पारदर्शी एसेट बन जाते। इसलिए RPL टोकन को लेजर का प्रथम-श्रेणी ऑब्जेक्ट बनाता है। चेन 20 में RPL-2 (v0.6.8) जुड़ता है: कोई प्रोग्राम सार्वजनिक स्टेट सेल और एक सार्वजनिक वॉल्ट रख सकता है, और अपने टोकन की मिंट अथॉरिटी बन सकता है (नीचे)। लोगों के पास रहने वाले बैलेंस अब भी नोट ही हैं।
टोकन एक रजिस्ट्री प्रविष्टि है
TokenRegistry (crates/randprotocol-core/src/ledger/tokens.rs) एक ही तालिका है, जिसे हर टोकन साझा करता है, चाहे वह नेटिव हो या ब्रिज्ड। ब्रिज भी किसी एसेट का इंडेक्स इसी रजिस्ट्री से निकालता है। हर प्रविष्टि में ये फ़ील्ड होते हैं:
| फ़ील्ड | नियम |
|---|---|
id | एसेट id, 32 बाइट, कंटेंट-एड्रेस्ड |
index | u32, वह मान जो नोट का asset शब्द रखता है। ये मान लगातार होते हैं और पंजीकरण के क्रम में 1 से दिए जाते हैं। इंडेक्स 0 RAND है और कभी पंजीकृत नहीं होता |
name | UTF-8 के 1 से 32 बाइट, रिक्त स्थान की अनुमति है, अपरिवर्तनीय |
symbol | 1 से 12 ASCII ग्राफ़िक बाइट (0x21..=0x7e, कोई व्हाइटस्पेस नहीं), अपरिवर्तनीय |
decimals | 0 से 9, अपरिवर्तनीय |
authority | मिंट अथॉरिटी, नीचे देखें |
mint_nonce | Key अथॉरिटी का रीप्ले काउंटर |
total_supply | u64, जाँचा हुआ अंकगणित। ओवरफ़्लो होने पर मिंट अस्वीकार हो जाता है। चेन 15 से इसे 2^63 से नीचे रखा जाता है (नीचे) |
registered_at | पंजीकरण की ऊँचाई |
डेसिमल 9 पर रुकते हैं, क्योंकि राशियाँ u64 हैं। 18 डेसिमल पर एक u64 में केवल 18.4 पूर्ण टोकन समाते हैं, और 9 RAND की अपनी परिशुद्धता है। ब्रिज्ड टोकन हमेशा 8 डेसिमल पर पंजीकृत होता है, उसके स्रोत कॉइन चाहे जितने डेसिमल उपयोग करें।
रजिस्ट्री जेनेसिस फ़ाइल के tokens सेक्शन से चालू होती है, ठीक वैसे ही जैसे bridge और aggregation अपने-अपने सेक्शन से। इस सेक्शन के बिना हर टोकन क्रिया किसी अन्य जाँच से पहले ही अस्वीकार हो जाती है (TokenError::Disabled)। चेन 20 की जेनेसिस में यह सेक्शन है और उसमें एक टोकन सूचीबद्ध है: zUSD, अपने सात बैकिंग के साथ। यह टोकन चेन 14 से हर कट में आगे लाया गया है। चेन पर बाकी हर टोकन ट्रांज़ैक्शन से आता है। (चेन 14 की जेनेसिस में कोई टोकन सूचीबद्ध नहीं था।) गेट चालू होने पर tokens_root स्टेट रूट में जुड़ता है। यह इंडेक्स-क्रम में blake3("rand-token-leaf-1", bincode(TokenInfo)) लीफ़ों का merkle रूट है। जिस चेन पर आगे कुछ और चालू नहीं है, वहाँ रूट का डोमेन rand-state-4 होता है। चेन 20 का रूट फ़ॉसेट और बॉन्ड-क्यू स्टेट, लाइव गैस मूल्य और प्रोग्राम-स्टेट रूट भी रखता है। यह rand-state-8 के अंतर्गत हैश होता है और फिर स्वीकृत वैलिडेटर सेट से एक बार और लपेटा जाता है (सहमति)।
tokens सेक्शन वाली चेन यह भी माँगती है कि हर जेनेसिस alloc नोट अपना ओपनिंग (pk, time, r) साथ रखे। नोड कमिटमेंट की पुनर्गणना करता है और मेल न खाने वाली फ़ाइल अस्वीकार कर देता है। कमिटमेंट एसेट 0 पर होता है, जब तक ओपनिंग उसी जेनेसिस में सूचीबद्ध किसी टोकन का इंडेक्स न बताए। चेन 20 पर ऐसे दो नोट हैं: इंडेक्स 1 पर 10 और 89 zUSD। हर सूचीबद्ध टोकन के लिए जेनेसिस नोटों का योग उस locked के बराबर होना चाहिए जिससे उसकी बैकिंग शुरू होती हैं। जब नोट का asset शब्द किसी टोकन का नाम ले सकता है, तब बिना ओपनिंग वाला जेनेसिस कमिटमेंट ही वह इकलौता रास्ता होता जिससे किसी भी एसेट का बिना बैकिंग वाला नोट बिना जाँच के पूल में डाला जा सके।
एसेट id, इंडेक्स और rpl1…
हर टोकन के दो नाम होते हैं, और RPC दोनों देता है।
- एसेट id 32 बाइट का होता है और प्रोग्राम id की तरह कंटेंट-एड्रेस्ड होता है। नेटिव टोकन का id
blake3("rand-rpl-asset", bincode(name, symbol, decimals, authority, initial, salt))है। इसमेंsaltनिर्माता द्वारा चुने गए 32 बाइट हैं औरinitialपूरा प्रारंभिक मिंट है, यदि कोई हो। ब्रिज्ड टोकन का idblake3("rand-rpl-asset", bincode(name, symbol, 8, salt))है। पहले से मौजूद id को पंजीकृत करने का प्रयास अस्वीकार होता है (TokenError::AlreadyRegistered)। - इंडेक्स वह है जो नोट वास्तव में रखता है, क्योंकि 32 बाइट का id एक शब्द में नहीं समाता। यह एक संक्षिप्त रूप है, जिसका अर्थ केवल इसी चेन पर होता है।
- पाठ रूप
rpl1…32 id बाइट पर bech32m (BIP-350) है, जिसका मानव-पठनीय भागrplहै। इसमें 52 डेटा वर्ण और 6 वर्णों का चेकसम होता है, कुल 62 वर्ण। जहाँ भी किसी टोकन का नाम आता है, यह 64-hex id के साथ दिखाया जाता है, और जहाँ भी टोकन खोजा जाता है, वहाँ स्वीकार किया जाता है। hex भी स्वीकार्य रहता है। पार्सिंग सख़्त है: ग़लत चेकसम, ग़लत प्रीफ़िक्स, ठीक 32 बाइट से अलग पेलोड, या मिश्रित केस अस्वीकार होते हैं। इसलिए टाइपिंग की कोई भूल किसी दूसरे टोकन तक नहीं पहुँच सकती।
सिंबल अद्वितीय नहीं होते। ERC-20 और SPL की तरह, टोकन की पहचान उसका एसेट id है, उसका नाम या टिकर कभी नहीं।
rand_bridgeAssetId हर (chain, token) के लिए एक पुराना मान निकालता है, जिसे rand_getAssets हर बैकिंग पंक्ति में छापता है। यह ब्रिज के वायर फ़ॉर्मेट का एक संकरा पहचानकर्ता है, टोकन का अपना id नहीं।
मिंट अथॉरिटी
| अथॉरिटी | कौन इकाइयाँ जारी कर सकता है | टिप्पणियाँ |
|---|---|---|
None | पंजीकरण के बाद कोई नहीं | स्थिर आपूर्ति: प्रारंभिक मिंट अनिवार्य है और कुल आपूर्ति हमेशा उतनी ही रहेगी |
Key(PublicKey) | एक Dilithium2 कुंजी का धारक | बाद में हस्ताक्षर से फिर मिंट कर सकता है। अथॉरिटी किसी दूसरी कुंजी को सौंप सकता है या उसका त्याग कर सकता है |
Bridge { backings } | केवल ब्रिज का लॉक और रिलीज़ | कभी सीधा मिंट नहीं होता। केवल ब्रिज की गवर्नेंस क्रियाओं से अस्तित्व में आता है |
Program(ProgramId) | केवल उस प्रोग्राम के Invoke (RPL-2) | program_state सेक्शन वाली चेन पर (चेन 20): बिना प्रारंभिक मिंट के पंजीकृत होता है, इसलिए इसकी आपूर्ति शून्य से शुरू होती है। मिंट या बर्न केवल उन ट्रांज़िशनों से होता है जिनकी पुष्टि प्रोग्राम का प्रूफ़ करता है (rand token create --program <id>)। जिस चेन पर यह सेक्शन नहीं है, वहाँ पंजीकरण के समय अस्वीकार होता है |
Bridge का नाम लेने वाला RegisterToken अस्वीकार होता है (TokenError::AuthorityNotAllowed)। Program का नाम लेने वाला RegisterToken भी अस्वीकार होता है, यदि उसमें प्रारंभिक मिंट हो या चेन पर program_state न हो। Key अथॉरिटी ठीक एक Dilithium2 सार्वजनिक कुंजी होती है। किसी अन्य बाइट लंबाई की कुंजी अस्वीकार होती है (TokenError::BadAuthorityKey), और मिंट में प्राप्तकर्ता की ML-KEM कुंजी पर भी उसकी लंबाई का यही नियम लागू होता है। दोनों या तो सहमति स्टेट हैं या स्थिर शुल्क पर खरीदा गया ब्लॉक स्पेस, इसलिए कोई भी मनमाने ढंग से बड़ा नहीं हो सकता।
टोकन बनाना
टोकन बनाने के लिए किसी अनुमति की आवश्यकता नहीं है। Action::RegisterToken { name, symbol, decimals, authority, initial, salt, index } एक साधारण RAND शुल्क बंडल के साथ जाता है और BUNDLE_BASE के साथ रजिस्ट्री का registration_fee भी चुकाता है। पंजीकरण शुल्क एक जेनेसिस पैरामीटर है, जो 1 RAND और 10,000 RAND के बीच सीमित है, इसलिए स्पैम टोकन की भी हमेशा कुछ लागत होती है। चेन 20 पर यह 1 RAND है, इसलिए एक पंजीकरण की लागत 1.001 RAND है। चेन 15 से हर चेन की तरह चेन 20 भी इसे बर्न करती है: प्रस्तावक को केवल बंडल बेस मिलता है (नीचे)।
index उस रजिस्ट्री इंडेक्स को बताता है जिसके लिए निर्माता ने प्रारंभिक नोट सील किया था। यदि वह इंडेक्स पहले ही किसी दूसरे पंजीकरण ने ले लिया हो, तो नोट को अटकाने के बजाय ट्रांज़ैक्शन अस्वीकार कर दिया जाता है (TokenError::IndexMismatch)। निर्माता अगले इंडेक्स के लिए फिर से प्रूफ़ बनाता है।
मिंट किया गया नोट चेन गणना करती है, सबमिट करने वाला उसे नहीं चुनता: note_commitment(recipient.pk, MINT_FROM, amount, index, time, r)। राशि और प्राप्तकर्ता का pk वायर पर सार्वजनिक होते हैं। इसलिए सील किया गया एनवेलप बेकार निकले तब भी प्राप्तकर्ता ट्रांज़ैक्शन के अपने फ़ील्ड से नोट दोबारा बना सकता है। ब्रिज डिपॉज़िट में भी यही सुरक्षा है।
id पूरे प्रारंभिक मिंट से क्यों बँधा है
RegisterToken पर हस्ताक्षर नहीं होता। ट्रांज़ैक्शन बाइंडिंग किसी प्रूफ़ की हुई प्रति को बदलने से रोकती है, पर यह नहीं बताती कि कोई नई प्रति किसका नाम ले सकती है। यदि id केवल प्रारंभिक राशि को कवर करता, तो लंबित पंजीकरण देखने वाला कोई भी व्यक्ति दूसरे प्राप्तकर्ता वाली प्रति सबमिट कर सकता था। वह उसे उसी id के अंतर्गत पंजीकृत करके और पहले कमिट करके स्थिर-आपूर्ति वाले टोकन की पूरी आपूर्ति ले सकता था। चूँकि id पूरे प्रारंभिक मिंट (राशि, प्राप्तकर्ता, r, time और एनवेलप) को कवर करता है, इसलिए मोड़ी गई प्रति एक भिन्न एसेट id पर हैश होती है। वह उसी सिंबल वाला एक अलग टोकन बन जाती है, जिसकी अनुमति गैर-अद्वितीय सिंबल पहले से देते हैं। मूल पंजीकरण फिर भी एक री-प्रूफ़ की लागत पर अगले इंडेक्स पर दर्ज हो जाता है।
ट्रांसफ़र वही बंडल हैं जो RAND के हैं
चेन 14 से हर मूल्य-हस्तांतरण ट्रांज़ैक्शन ठीक एक बंडल रखता है: स्थिर 4-इनपुट-4-आउटपुट वाला छिपी-एसेट आकार (ट्रांज़ैक्शन और क्रियाएँ)। स्लॉट 0–1 एक निजी एसेट रखते हैं, जो RAND या कोई भी RPL टोकन हो सकता है, और सर्किट को कभी पता नहीं चलता कि वह कौन-सी है। स्लॉट 2–3 हमेशा RAND रखते हैं। किसी भी एसेट का ट्रांसफ़र Action::None है, यानी वही क्रिया जो एक साधारण RAND भुगतान उपयोग करता है। टोकन-ट्रांसफ़र की कोई अलग क्रिया नहीं है, और न ही कोई सार्वजनिक फ़ील्ड जो टोकन का नाम बताए।
किसी टोकन ट्रांसफ़र का पर्यवेक्षक ठीक वही देखता है जो एक RAND भुगतान प्रकाशित करता है: एक एंकर, चार नलिफ़ायर, चार कमिटमेंट, RAND fee, burn_a = burn_r = burn_asset = 0, एक time, चार एनवेलप सिफरटेक्स्ट और बंडल प्रमाण। चेन 17 (विभाजित प्राधिकरण) से हर बंडल एक auth_commit और एक दूसरा, छोटा प्राधिकरण प्रमाण भी ले जाता है, जो फिर से हर एसेट के लिए एक जैसा है। चेन 20 पर प्रत्येक एनवेलप ठीक 1,860 बाइट का है और उसमें एक एन्क्रिप्टेड मेमो (rand send --memo) के लिए जगह रहती है, चाहे मेमो भेजा जाए या नहीं। पर्यवेक्षक प्रेषक, प्राप्तकर्ता, राशि, कौन-सा एसेट स्थानांतरित हुआ, कौन-से स्लॉट डमी थे, या चेंज राशि नहीं देखता।
वॉलेट स्लॉट 0–1 में टोकन के अधिकतम दो नोट और शुल्क के लिए स्लॉट 2–3 में अधिकतम दो RAND नोट ख़र्च करता है। शुल्क हमेशा RAND में होता है, इसलिए जिस धारक के पास टोकन है पर RAND नहीं, उसे प्रमाण बनाने से पहले ही अस्वीकार कर दिया जाता है। लागत वही है जो एक RAND भुगतान की होती है (शुल्क)। चेन 20 पर इसका अर्थ है प्रेषक की मशीन पर बने दो STARK प्रमाण: व्यय प्राधिकरण (टियर 10, लगभग 7 s, लगभग 1.37 MB) और बंडल (टियर 14, लगभग 100 s, लगभग 1.5 MB), जो मिलाकर नेटवर्क पर लगभग 2.85 MB होते हैं। प्रत्येक प्रमाण एक प्रमाण पर चेन की 4 MiB सीमा से कम है। चेन 17 से पहले ट्रांसफ़र केवल बंडल प्रमाण ले जाता था, जो उस समय मापने पर लगभग 1.42 MB था।
मिंटिंग और प्राधिकार
TokenMint { asset, amount, recipient, r, time, envelope, nonce, signature } किसी Key-प्राधिकृत टोकन की और मात्रा मिंट करता है। SetAuthority { asset, new, nonce, signature } प्राधिकार किसी दूसरी कुंजी को सौंपता है, या new अनुपस्थित होने पर उसका परित्याग करता है; परित्याग के बाद कोई भी कुंजी उस टोकन को फिर कभी मिंट नहीं कर सकती। जिस टोकन का प्राधिकार Key नहीं है, उस पर इनमें से कोई भी क्रिया अस्वीकार कर दी जाती है (TokenError::NotKeyAuthority)।
प्राधिकार blake3("rand-rpl-mint-1" | "rand-rpl-authority-1", chain_id ‖ asset_id ‖ nonce ‖ body) पर हस्ताक्षर करता है। nonce का टोकन के mint_nonce के बराबर होना आवश्यक है, जो इसके बाद एक बढ़ जाता है, इसलिए हस्ताक्षरित मिंट को न इस चेन पर दोहराया जा सकता है और न किसी दूसरी चेन पर ले जाया जा सकता है। मिंट के body में एनवेलप का डाइजेस्ट शामिल होता है: केवल कमिटमेंट उसे कवर नहीं करता, और डाइजेस्ट के बिना कोई तीसरा पक्ष गॉसिप किए गए मिंट को निरर्थक एनवेलप के साथ फिर से लपेटकर नॉन्स ख़र्च कर सकता था।
दोनों क्रियाएँ BUNDLE_BASE का भुगतान करने वाले एक RAND शुल्क बंडल के साथ जाती हैं। शुल्क चुकाने वाला वॉलेट और मिंट को प्राधिकृत करने वाली कुंजी अलग-अलग हैं और अलग-अलग लोगों की हो सकती हैं।
बर्निंग
Action::TokenBurn { asset, amount } उसी एकल बंडल के साथ जाता है: बंडल का burn_asset asset के बराबर, burn_a amount के बराबर, और burn_r 0 होना चाहिए। टोकन एसेट स्लॉट के माध्यम से और RAND शुल्क उसी प्रमाण के स्लॉट 2–3 के माध्यम से पूल से बाहर जाते हैं। total_supply ठीक amount से घटता है। Bridge-प्राधिकार वाला टोकन यहाँ अस्वीकार कर दिया जाता है (TokenError::BridgedToken); वह ब्रिज बर्न के माध्यम से बाहर जाता है।
शुल्क
हर RPL क्रिया RAND में भुगतान करती है।
| क्रिया | न्यूनतम शुल्क | चेन 20 पर |
|---|---|---|
किसी भी एसेट का ट्रांसफ़र (Action::None) | BUNDLE_BASE | 0.001 RAND |
RegisterToken | BUNDLE_BASE + registration_fee | 1.001 RAND, जिसमें से 1 RAND बर्न होता है |
TokenMint | BUNDLE_BASE | 0.001 RAND |
SetAuthority | BUNDLE_BASE | 0.001 RAND |
TokenBurn | BUNDLE_BASE | 0.001 RAND |
चेन 20 की जेनेसिस में एक gas खंड है, और वह केवल प्रोग्राम कॉल और इनवोक का मूल्य तय करता है। ये न्यूनतम शुल्क स्थिर हैं: कोई भी RPL क्रिया गैस या बाइट के आधार पर भुगतान नहीं करती।
क्या सार्वजनिक है और क्या छिपा है
| सार्वजनिक | छिपा | |
|---|---|---|
| पंजीकरण | नाम, प्रतीक, दशमलव, प्राधिकार, एसेट id, प्रारंभिक मिंट की राशि और प्राप्तकर्ता | कुछ नहीं; इसी से किसी टोकन की आपूर्ति उसके पहले ब्लॉक से ऑडिट योग्य रहती है |
| आगे का मिंट | राशि, प्राप्तकर्ता का परिरक्षित पता, नए नोट के फ़ील्ड | RAND शुल्क किसने चुकाया |
| ट्रांसफ़र | ऐसा कुछ भी नहीं जिससे पता चले कि कोई टोकन स्थानांतरित हुआ भी है | प्रेषक, प्राप्तकर्ता, राशि, कौन-सा एसेट |
| बर्न | एसेट और राशि | बर्न किए गए नोट किसके पास थे |
| प्राधिकार परिवर्तन | नई कुंजी, या यह कि प्राधिकार का परित्याग किया गया | — |
इसलिए total_supply हमेशा ऑडिट योग्य रहता है: यह पंजीकरण और हर मिंट द्वारा जोड़ी गई मात्रा में से हर बर्न को घटाकर बनता है। धारकों के बीच ट्रांसफ़र कुछ भी प्रकट नहीं करता, यह भी नहीं कि RAND के बजाय कोई टोकन हस्तांतरित हुआ।
प्रकटीकरण उसी तरह काम करता है जैसे RAND के लिए। नोट के प्लेनटेक्स्ट में एसेट होता है, इसलिए प्रति-लेनदेन कुंजी (rand tx-key <hash>) या व्यूइंग कुंजी किसी टोकन नोट को ठीक वैसे ही खोलती है जैसे RAND नोट को, और rand_checkTransaction तथा rand_getViewingNotes अपने द्वारा प्रकट किए गए नोट में asset लौटाते हैं। ऐसी कुंजी मिलने पर randscan रजिस्ट्री से इंडेक्स का मिलान करता है और ट्रांसफ़र को नामित टोकन के रूप में दिखाता है; उसी लेनदेन का सार्वजनिक पृष्ठ इनमें से कुछ भी नहीं दिखाता।
ब्रिज किए गए टोकन
Bridge-प्राधिकार वाला टोकन भी RPL टोकन ही है: वही रजिस्ट्री प्रविष्टि, वही छिपा ट्रांसफ़र, वही बर्न प्रक्रिया। इसकी आपूर्ति केवल किसी स्रोत चेन पर लॉक (BridgeAttest) या रिलीज़ (BridgeBurn) के माध्यम से बदलती है। एक ब्रिज किए गए टोकन के कई बैकिंग हो सकते हैं, प्रत्येक एक (chain, token) युग्म, जिसके अपने स्रोत दशमलव, लॉक की गई राशि और मिंट सीमा होती है, और total_supply हमेशा उसके बैकिंग द्वारा लॉक की गई राशियों के योग के बराबर होता है। ब्रिज किया गया टोकन पंजीकृत करना, और बैकिंग जोड़ना, केवल ब्रिज के पोस्ट-क्वांटम संरक्षकों के कोरम के अंतर्गत होता है।
चेन 20 पर रजिस्ट्री का पहला टोकन zUSD (“Shielded USD”) है, इंडेक्स 1, 8 दशमलव, जो जेनेसिस फ़ाइल में सात बैकिंग के साथ सूचीबद्ध है (Ethereum, Binance Smart Chain और Solana पर USDT और USDC, तथा Tron पर USDT)। यह वही एसेट id रखता है जो चेन 14 पर था, जहाँ इसे ऊँचाई 256 पर लेनदेन द्वारा पंजीकृत किया गया था: चेन 15 से 20 तक प्रत्येक इसे उसी नाम, प्रतीक और सॉल्ट के साथ जेनेसिस में सूचीबद्ध करती है। चेन 20 की शुरुआत में इसके पास दो जेनेसिस नोटों (10 और 89) में 99 zUSD थे, जिनके पीछे Ethereum पर लॉक 22 USDT, Binance Smart Chain पर 22, Tron पर 30 और Solana पर 25 थे, जो चेन 19 की ब्रिज स्थिति से लाए गए। चेन 19 की शुरुआत 10 zUSD से हुई थी, जिनके पीछे Solana पर 10 USDT थे; चेन 18 की शुरुआत Tron पर लॉक 9 USDT और Solana पर 1 से। इसकी कुल आपूर्ति उसके बैकिंग में लॉक राशि के बराबर है और हर जमा और रिडेम्प्शन के साथ बदलती है। इसका id rpl1xtj6k2x8strx8c2d5fjs50ltztck5ykms4ve7nmzmstf6fhn0v0spelqtx है। ब्रिज बैकिंग, रिलीज़ इकाइयों, मिंट सीमाओं, विराम और सह-हस्ताक्षर का विवरण देता है।
zUSD एक बास्केट है, सात अलग-अलग दावे नहीं। इसके बैकिंग अंकित मूल्य पर एक पूल में रखे जाते हैं, इसलिए धारक हर सूचीबद्ध बैकिंग का जोखिम उठाता है, केवल उस कॉइन का नहीं जो उसने जमा किया: जिस बैकिंग का पेग टूट गया हो उसे सममूल्य पर जमा करके zUSD को किसी सुदृढ़ बैकिंग की ओर बर्न किया जा सकता है, जब तक सुदृढ़ बैकिंग ख़ाली न हो जाएँ। हानि को सीमित करने वाली चीज़ें हैं रोलिंग मिंट विंडो (चेन 20 पर, सभी बैकिंग में मिलाकर प्रति 24 घंटे 4,000 zUSD, साथ में प्रति बैकिंग 100,000) और वास्तव में लॉक की गई अभिरक्षा। विंडो दर को सीमित करती है और मिंट रोकने का समय देती है। यह कुल राशि की सीमा तय नहीं करती। कोई बैकिंग केवल पोस्ट-क्वांटम संरक्षक कोरम के अंतर्गत सूचीबद्ध होता है, और मिंट रुके रहने के दौरान नहीं।
ब्रिज के शुल्क, zUSD में (चेन 20)। चेन 20 की जेनेसिस bridge.fees निर्धारित करती है: जमा पर 10 bps और बर्न पर 10 bps, प्रत्येक बैकिंग की एक पूर्ण रिलीज़ इकाई तक नीचे की ओर पूर्णांकित (6-दशमलव USDT के लिए 100 आधार इकाइयाँ), जो जेनेसिस में नामित ट्रेज़री पते को zUSD नोट के रूप में चुकाया जाता है (v0.6.8, fullnode docs/bridge.md §25)। g की जमा दो नोट जोड़ती है: जमाकर्ता का g − fee और ट्रेज़री का fee; 1 USDT जमा करने पर जमाकर्ता को 0.999 zUSD मिलते हैं। amount का बर्न fee को ट्रेज़री नोट के रूप में रखता है और स्रोत चेन पर amount − fee रिलीज़ करता है; संरक्षक उसी रिलीज़ राशि पर हस्ताक्षर करते हैं, और rand_getBridgeBurn amount, release_amount और fee लौटाता है। शुल्क नोट जारी और समर्थित होता है, इसलिए total_supply अब भी बैकिंग के locked के योग के बराबर रहता है: जमा दोनों को g से बढ़ाती है, बर्न दोनों को amount − fee से घटाता है। शुल्क नोट कोई एनवेलप नहीं ले जाता। इसका हर अंश सार्वजनिक है (लेनदेन और जेनेसिस दर से राशि, एसेट और time, अटेस्टेशन डाइजेस्ट या बर्न के लेनदेन id से व्युत्पन्न ब्लाइंडिंग, जेनेसिस से स्वामी), इसलिए ट्रेज़री का वॉलेट इसे सार्वजनिक फ़ील्ड से पुनर्निर्मित करता है (नोट)। BRIDGE_BURN_FEE, यानी बर्न द्वारा प्रस्तावक को चुकाया जाने वाला 0.01 RAND, अपरिवर्तित है। चेन 14 से 19 तक Rand पर कोई ब्रिज शुल्क नहीं था।
चेन 15 से रजिस्ट्री
चेन 15 से जेनेसिस रजिस्ट्री के तीन ऐसे नियम लागू करती है जो चेन 14 में नहीं थे, और चेन 20 की जेनेसिस वही तीन मान निर्धारित करती है। प्रत्येक जेनेसिस हैश और टोकन रूट के प्रति प्रतिबद्ध है।
| जेनेसिस फ़ील्ड | चेन 20 | प्रभाव |
|---|---|---|
tokens.max_tokens | 4096 | रजिस्ट्री में इससे अधिक टोकन कभी नहीं रहते; सीमा पर पहुँचने पर RegisterToken और RegisterBridgedToken को RegistryFull के साथ अस्वीकार कर दिया जाता है। ListBacking कोई टोकन नहीं जोड़ता और इससे अप्रभावित रहता है |
tokens.burn_registration_fee | true | किसी पंजीकरण का registration_fee प्रस्तावक को चुकाया जाने के बजाय नष्ट कर दिया जाता है; प्रस्तावक fee − registration_fee रखता है। rand_getSupply इसे burned में और registration_fees_burned में गिनता है (आपूर्ति) |
tokens.bound_note_value | true | 2^63 या उससे अधिक का TokenMint, प्रारंभिक मिंट या ब्रिज जमा AmountTooLarge के साथ अस्वीकार किया जाता है, और जो किसी टोकन के total_supply को 2^63 तक या उससे आगे ले जाए, वह SupplyTooLarge के साथ |
नोट-मूल्य की यह सीमा इसलिए है क्योंकि बंडल सर्किट हर राशि की 63 बिट तक रेंज-जाँच करता है: 2^63 या उससे अधिक मूल्य का नोट कमिट तो किया जा सकता है, पर कभी खर्च नहीं किया जा सकता, जबकि वह टोकन की आपूर्ति में गिना जाता रहता है। इसके अलावा हर नोड हर चेन पर ऐसी राशि को प्रवेश के समय ही अस्वीकार कर देता है, उसका जेनेसिस चाहे जो कहे।
RPC और CLI
| मेथड | पैरामीटर | परिणाम |
|---|---|---|
rand_getTokens | [from_index, limit], वैकल्पिक, डिफ़ॉल्ट 0 और 1000, अधिकतम 1000 तक सीमित | { enabled, registration_fee, next_index, max_tokens, burn_registration_fee, bound_note_value, tokens }, इंडेक्स के आरोही क्रम में, from_index से रेंज के अनुसार पढ़ा गया |
rand_getToken | [token]: एक इंडेक्स, 64-hex id या rpl1… | एक टोकन की पंक्ति, या null; त्रुटिपूर्ण id पर -32602 |
rand_getTokenSupply | [token], वही रूप | { total_supply, backings }; नेटिव टोकन के लिए backings खाली होता है |
इन परिणामों में हर राशि (total_supply, registration_fee, किसी बैकिंग का locked, mint_cap_per_day और minted_today) एक दशमलव स्ट्रिंग है, क्योंकि JSON संख्या 2⁵³ के बाद सटीक नहीं रहती। index, next_index, mint_day और max_tokens साधारण पूर्णांक हैं (जिस चेन पर कोई सीमा नहीं है, वहाँ max_tokens null होता है); burn_registration_fee और bound_note_value बूलियन हैं। किसी पंक्ति का authority {"kind":"none"}, {"kind":"key","key","address"}, {"kind":"bridge","backings":[…]} या {"kind":"program","program"} होता है। पूरा विवरण JSON-RPC में है।
गोपनीयता। कॉलर के मन में कोई भी टोकन हो, rand_getTokens की लागत वही रहती है। rand_getToken और rand_getTokenSupply नोड को बता देते हैं कि कॉलर किस टोकन में रुचि रखता है: एक्सप्लोरर के लिए यह ठीक है, पर भेजने जा रहे वॉलेट के लिए गलत। इसलिए वॉलेट हर --asset को पूरी सूची से हल करता है, और कोई संख्यात्मक इंडेक्स नोड तक पहुँचता ही नहीं।
| कमांड | यह क्या करता है |
|---|---|
rand token create | रजिस्ट्री के अगले इंडेक्स पर एक टोकन पंजीकृत करता है, स्थिर-आपूर्ति वाला या Key-अधिकृत |
rand token mint | Key-अधिकृत टोकन की और इकाइयाँ मिंट करता है, उसकी अधिकार कुंजी से हस्ताक्षरित |
rand token set-authority | अधिकार किसी दूसरी कुंजी को सौंपता है (--new-key) या उसे छोड़ देता है (--renounce) |
rand token burn <ASSET> <AMOUNT> | इस वॉलेट में रखी इकाइयाँ नष्ट करता है |
rand token info <ASSET> | एक टोकन की पूरी पंक्ति |
rand token list | रजिस्ट्री का एक पृष्ठ |
rand send <TO> <AMOUNT> --asset <INDEX|rpl1…|hex> | एक बंडल में टोकन भेजता है; --asset के बिना यह RAND भेजता है। प्रूफ़ बनाने से पहले यह प्राप्तकर्ता का फ़िंगरप्रिंट और राशि प्रिंट करता है और send? [y/N] पूछता है (--yes यह प्रश्न छोड़ देता है) |
rand asset-balance [INDEX] | इस वॉलेट में किसी एक एसेट की कितनी मात्रा है, या हर एसेट की एक पंक्ति |
rand token register-bridged, rand token list-backing | ब्रिज की दो सूचीकरण क्रियाएँ; हर एक के लिए PQ गार्जियन कोरम फ़ाइल चाहिए |
v0.5.10 से rand send --asset, rand token mint और rand token burn की राशियाँ टोकन की प्रदर्शन इकाइयों में होती हैं, जो उसकी रजिस्ट्री पंक्ति के अपने decimals के अनुसार पढ़ी जाती हैं: 6-दशमलव वाले टोकन का 1.5 उसकी सबसे छोटी इकाई के 1,500,000 के बराबर है, और टोकन से अधिक दशमलव अंक देने पर राशि अस्वीकार कर दी जाती है। send की पुष्टि दोनों प्रिंट करती है (1.500000 USDX (1500000 units))। rand token create के --fixed-supply और --initial अब भी पूरी सबसे छोटी इकाइयाँ लेते हैं, rand bridge-burn भी, और rand asset-balance सबसे छोटी इकाइयाँ प्रिंट करता है। ऑन-चेन राशि हमेशा सबसे छोटी इकाई वाला पूर्णांक होती है। फ़्लैग और डिफ़ॉल्ट कमांड लाइन में हैं।
ERC-20 और SPL से अंतर
| ERC-20 / SPL | RPL | |
|---|---|---|
| बैलेंस | एक सार्वजनिक मैपिंग या खाता | शील्डेड नोट; केवल कुंजीधारक ही उसे देख सकता है |
| ट्रांसफ़र इवेंट | सार्वजनिक, प्रेषक, प्राप्तकर्ता और राशि सहित | कोई नहीं; ट्रांसफ़र ऐसा कुछ प्रकाशित नहीं करता जिससे उसे अलग पहचाना जा सके |
| प्रति-टोकन कोड | संभव: टैक्स, रीबेस, हुक, फ़्रीज़ | कोई नहीं; हर टोकन वही निश्चित नियम मानता है |
| प्रोग्राम द्वारा धारण | हाँ | चेन 20 (RPL-2) पर: प्रोग्राम का सार्वजनिक वॉल्ट, जो invoke के बर्न फ़ील्ड से भरता है और चेन द्वारा गणना किए गए नोटों के रूप में भुगतान करता है |
| राशियाँ | 256-बिट तक (ERC-20), 64-बिट (SPL) | u64, अधिकतम 9 दशमलव |
| प्राप्ति | ERC-20 के लिए कोई सेटअप नहीं; SPL के लिए associated token account चाहिए | कोई सेटअप नहीं; शील्डेड पता कुछ भी प्राप्त कर लेता है |
| ट्रांसफ़र की लागत | साधारण EVM या SVM निष्पादन | प्रेषक द्वारा सिद्ध: साझा hidden-asset बंडल, और चेन 17 से उसके साथ एक छोटा प्राधिकरण प्रूफ़ |
| अनुमोदन | approve / transferFrom | अभी नहीं |
| मेटाडेटा | कुछ इम्प्लीमेंटेशन में परिवर्तनीय | ऑन-चेन और अपरिवर्तनीय |
| फ़्रीज़, ब्लैकलिस्ट | कुछ टोकनों पर संभव | डिज़ाइन के अनुसार दायरे से बाहर |
ज्ञात सीमाएँ
- कोई अलाउंस नहीं। RPL स्पेसिफ़िकेशन में
approveऔरtransferFromको निर्धारित अलाउंस खातों के रूप में डिज़ाइन किया गया है, पर वे अभी बने नहीं हैं। - प्रोग्राम की होल्डिंग सार्वजनिक होती है। चेन 20 पर प्रोग्राम अपने वॉल्ट में टोकन रख सकता है और अपना टोकन मिंट कर सकता है (RPL-2), पर वॉल्ट का बैलेंस टोकन की आपूर्ति की तरह सार्वजनिक होता है; केवल नोट निजी होते हैं। चेन 20 से पहले की चेनों पर कोई प्रोग्राम स्टेट था ही नहीं।
- शुल्क केवल RAND में। कोई टोकन अपना शुल्क स्वयं नहीं चुका सकता; केवल टोकन रखने वाला वॉलेट कुछ भी स्थानांतरित नहीं कर सकता।
u64राशियाँ और अधिकतम 9 दशमलव। 18-दशमलव वाला स्रोत कॉइन कम परिशुद्धता पर दर्शाया जाता है; ब्रिज इसे 8 दशमलव और प्रति बैकिंग एक रिलीज़ इकाई से सुलझाता है।- हर ट्रांसफ़र सिद्ध किया जाता है। प्रेषक की मशीन पर लगभग 100 s और कई GB मेमोरी; टोकन के लिए RAND से सस्ता कोई रास्ता नहीं है।
- नेटिव टोकन पर कोई फ़्रीज़, ब्लैकलिस्ट या पॉज़ नहीं, यह सोचा-समझा निर्णय है। ब्रिज का मिंट पॉज़ केवल ब्रिज किए गए मिंट पर लागू होता है।
- प्रति-टोकन लुकअप रुचि उजागर करते हैं।
rand_getToken,rand_getTokenSupplyऔर एक्सप्लोरर का/tokens/:idसर्वर को बता देते हैं कि किस टोकन के बारे में पूछा गया।