از این صفحه برای درک اینکه توکن در این زنجیره چیست استفاده کنید، پیش از آنکه توکنی ایجاد، فهرست یا نمایهسازی کنید. RPL استاندارد توکن Rand است و از زنجیره 14 اضافه شده است. توکن یک دارایی بومی محافظتشده است: یک ورودی در رجیستری دفتر کل که موجودیهای آن بهصورت نوتهای معمولی در همان درخت تعهدی نگهداری میشود که RAND استفاده میکند. توکن یک قرارداد نیست. برای ایجاد گامبهگام آن، استقرار یک توکن RPL را ببینید.
دلیل این طراحی ساختاری است. یک Call فقط یک رسید مینویسد، پس قراردادی به سبک ERC-20 جایی برای نگهداری موجودی نداشت، و یک جدول موجودی عمومی توکنها را به تنها دارایی شفاف در یک زنجیره محافظتشده تبدیل میکرد. RPL بهجای آن، توکن را به یک شیء درجهیک دفتر کل تبدیل میکند. زنجیره 20 نسخه RPL-2 را اضافه میکند (v0.6.8): یک برنامه میتواند سلولهای حالت عمومی و یک خزانه عمومی نگه دارد و میتواند مرجع مجاز ضرب (mint authority) توکنی از آنِ خودش باشد (در ادامه); موجودیهایی که اشخاص نگه میدارند همچنان نوت هستند.
توکن یک ورودی رجیستری است
TokenRegistry (crates/randprotocol-core/src/ledger/tokens.rs) یک جدول واحد است که همه توکنها، چه بومی و چه پلی، در آن مشترکاند. همان رجیستریای است که پل شاخص یک دارایی را از طریق آن تعیین میکند. هر ورودی:
| فیلد | قاعده |
|---|---|
id | شناسه دارایی، ۳۲ بایت، مبتنی بر محتوا |
index | u32، مقداری که کلمه asset یک نوت حمل میکند؛ فشرده، به ترتیب ثبت از 1 تخصیص مییابد. شاخص 0 همان RAND است و هرگز ثبت نمیشود |
name | ۱ تا ۳۲ بایت UTF-8، فاصله مجاز است، تغییرناپذیر |
symbol | ۱ تا ۱۲ بایت ASCII گرافیکی (0x21..=0x7e، بدون فاصله)، تغییرناپذیر |
decimals | ۰ تا ۹، تغییرناپذیر |
authority | مرجع مجاز ضرب، در ادامه |
mint_nonce | شمارنده ضدبازپخش یک مرجع از نوع Key |
total_supply | u64، با محاسبات بررسیشده؛ سرریز، ضرب را رد میکند. از زنجیره 15 زیر 2^63 نگه داشته میشود (در ادامه) |
registered_at | ارتفاع ثبت |
ارقام اعشار در عدد 9 متوقف میشوند چون مقادیر u64 هستند: با 18 رقم اعشار، یک u64 فقط 18.4 توکن کامل را در خود جا میدهد، و 9 دقت خود RAND است. یک توکن پلی همیشه با 8 رقم اعشار ثبت میشود، فارغ از اینکه سکههای مبدأ آن چه دقتی دارند.
رجیستری با بخش tokens در فایل genesis روشن میشود، همانطور که bridge و aggregation با بخشهای خودشان روشن میشوند. بدون آن، هر اقدام توکنی پیش از هر بررسی دیگر رد میشود (TokenError::Disabled). genesis زنجیره 20 این بخش را دارد و یک توکن را فهرست میکند، یعنی zUSD با هفت پشتوانهاش، که از زنجیره 14 در هر برش منتقل شده است؛ هر توکن دیگر روی زنجیره با تراکنش وارد میشود. (genesis زنجیره 14 هیچ توکنی فهرست نمیکرد.) با روشن بودن این دروازه، یک tokens_root (ریشه merkle برگهای blake3("rand-token-leaf-1", bincode(TokenInfo)) به ترتیب شاخص) در ریشه حالت ادغام میشود. دامنه این ریشه rand-state-4 است در زنجیرهای که چیز دیگری پس از آن روشن نشده باشد؛ ریشه زنجیره 20 حالت faucet و صف bond، قیمتهای جاری gas و ریشه حالت برنامه را نیز حمل میکند، هشهایی تحت rand-state-8، و یک بار دیگر با مجموعه validatorهای پذیرفتهشده پوشانده میشود (اجماع).
زنجیرهای که بخش tokens دارد همچنین ایجاب میکند که هر نوت alloc در genesis بازگشایی خود (pk، time، r) را حمل کند، و گره تعهد را دوباره محاسبه میکند و فایلی را که مطابقت نداشته باشد رد میکند. تعهد روی دارایی 0 است، مگر آنکه بازگشایی شاخص توکنی را نام ببرد که همان genesis فهرست کرده است — زنجیره 20 دو نوت چنین دارد، 10 و 89 zUSD در شاخص 1 — و به ازای هر توکن فهرستشده، نوتهای genesis باید جمعی برابر با مقداری داشته باشند که پشتوانههای آن با locked شروع میکنند. وقتی یک نوت کلمه asset ای دارد که میتواند یک توکن را نام ببرد، یک تعهد genesis بازنشده تنها راهی میبود که نوتی بدون پشتوانه از هر دارایی را بدون بررسی وارد استخر کند.
شناسه دارایی، شاخص و rpl1…
یک توکن دو نام دارد و RPC هر دو را میدهد.
- شناسه دارایی ۳۲ بایت است و مانند شناسه برنامه مبتنی بر محتواست. شناسه یک توکن بومی
blake3("rand-rpl-asset", bincode(name, symbol, decimals, authority, initial, salt))است، که در آنsalt۳۲ بایتی است که سازنده انتخاب میکند وinitialکل ضرب اولیه است، در صورت وجود. شناسه یک توکن پلیblake3("rand-rpl-asset", bincode(name, symbol, 8, salt))است. ثبت شناسهای که از قبل وجود دارد رد میشود (TokenError::AlreadyRegistered). - شاخص چیزی است که یک نوت در واقع حمل میکند، چون شناسه ۳۲ بایتی در یک کلمه جا نمیشود. این یک میانبر است که فقط در همین زنجیره معنا دارد.
- شکل متنی
rpl1…از نوع bech32m (BIP-350) است با بخش خوانا برای انسانrplروی ۳۲ بایت شناسه: ۵۲ نویسه داده و یک جمعکنترل ۶ نویسهای، در مجموع ۶۲ نویسه. این شکل در هر جا که توکنی نام برده شود کنار شناسه ۶۴ رقمی هگزادسیمال نشان داده میشود و در هر جا که توکنی جستوجو شود پذیرفته میشود؛ هگزادسیمال همچنان پذیرفته است. تجزیه سختگیرانه است: جمعکنترل نادرست، پیشوند اشتباه، بار دادهای که دقیقاً ۳۲ بایت نباشد، یا حروف ترکیبی (بزرگ و کوچک) رد میشود، بنابراین یک غلط تایپی نمیتواند به توکن دیگری تعیین شود.
نمادها یکتا نیستند. مانند ERC-20 و SPL، هویت یک توکن شناسه دارایی آن است، نه نام یا نماد آن.
مقدار قدیمی به ازای هر (chain, token) که rand_bridgeAssetId محاسبه میکند و rand_getAssets برای هر ردیف پشتوانه چاپ میکند، شناسهای محدودتر برای قالب سیمی پل است، نه شناسه خود توکن.
مراجع مجاز ضرب
| authority | چه کسی میتواند واحد صادر کند | یادداشتها |
|---|---|---|
None | هیچکس، پس از ثبت | عرضه ثابت: ضرب اولیه الزامی است و تمام آن چیزی است که همیشه وجود خواهد داشت |
Key(PublicKey) | دارنده یک کلید Dilithium2 | بعداً با امضا دوباره ضرب میکند؛ میتواند مرجع را به کلید دیگری واگذار یا از آن صرفنظر کند |
Bridge { backings } | فقط قفل و آزادسازی پل | هرگز ضرب مستقیم نیست؛ فقط از طریق اقدامات حاکمیتی پل وجود دارد |
Program(ProgramId) | فقط Invokeهای آن برنامه (RPL-2) | در زنجیرهای با بخش program_state (زنجیره 20): بدون ضرب اولیه ثبت میشود، پس عرضه آن از صفر شروع میشود، و فقط با گذارهایی ضرب یا سوزانده میشود که اثبات برنامه تأییدشان کند (rand token create --program <id>). در زنجیرهای بدون این بخش، هنگام ثبت رد میشود |
یک RegisterToken که Bridge را نام ببرد رد میشود (TokenError::AuthorityNotAllowed)، همچنین است اگر Program را با ضرب اولیه یا در زنجیرهای بدون program_state نام ببرد. یک مرجع Key دقیقاً یک کلید عمومی Dilithium2 است: کلیدی با هر طول بایت دیگر رد میشود (TokenError::BadAuthorityKey)، و کلید ML-KEM گیرنده در یک ضرب نیز به همین ترتیب به طول خود مقید است. هر دو یا حالت اجماعاند یا فضای بلوکی که با کارمزد ثابت خریداری میشود، پس هیچکدام نباید بهطور دلخواه بزرگ باشند.
ایجاد یک توکن
ایجاد بدون نیاز به مجوز است. Action::RegisterToken { name, symbol, decimals, authority, initial, salt, index } روی یک بسته کارمزد معمولی RAND سوار میشود و BUNDLE_BASE بهعلاوه registration_fee رجیستری را میپردازد. کارمزد ثبت یک پارامتر genesis است که بین 1 RAND و 10,000 RAND محدود شده است، تا یک توکن هرزنامه همیشه هزینهای داشته باشد. در زنجیره 20 این مقدار 1 RAND است، پس یک ثبت 1.001 RAND هزینه دارد، و زنجیره 20 آن را میسوزاند، همانطور که هر زنجیره از 15 به بعد چنین کرده است: پیشنهاددهنده فقط پایه بسته را نگه میدارد (در ادامه).
index شاخص رجیستریای را نام میبرد که سازنده نوت اولیه را برای آن مهروموم کرده است. اگر ثبت دیگری ابتدا آن شاخص را بگیرد، تراکنش رد میشود (TokenError::IndexMismatch) تا نوت بیصاحب نماند؛ سازنده در شاخص بعدی دوباره اثبات میکند.
نوت ضربشده را زنجیره محاسبه میکند، نه ارسالکننده انتخاب: note_commitment(recipient.pk, MINT_FROM, amount, index, time, r). مقدار و pk گیرنده روی سیم عمومی هستند، پس گیرنده میتواند نوت را از خود فیلدهای تراکنش بازسازی کند، حتی اگر پاکت مهرومومشده بیمعنا باشد. واریز پل نیز همین دفاع را دارد.
چرا شناسه کل ضرب اولیه را مقید میکند
یک RegisterToken امضا نمیشود. مقیدسازی تراکنش جلوی تغییر یک نسخه اثباتشده را میگیرد، اما درباره آنچه یک نسخه تازه میتواند نام ببرد چیزی نمیگوید. اگر شناسه فقط مقدار اولیه را پوشش میداد، ناظری که ثبتی در انتظار را میدید میتوانست نسخهای با گیرندهای دیگر ارسال کند، آن را با همان شناسه ثبت کند، و با تعهد زودتر، کل عرضه یک توکن با عرضه ثابت را بگیرد. از آنجا که شناسه کل ضرب اولیه را پوشش میدهد (مقدار، گیرنده، r، time و پاکت)، یک نسخه تغییر مسیر دادهشده به یک شناسه دارایی متفاوت هش میشود: توکنی دیگر با همان نماد، که نمادِ غیریکتا از پیش اجازهاش را میدهد. نسخه اصلی همچنان با هزینه یک اثبات دوباره در شاخص بعدی مینشیند.
انتقالها همان بسته RAND هستند
از زنجیره 14 هر تراکنشی که ارزش جابهجا میکند دقیقاً یک بسته حمل میکند، همان شکل ثابت ۴ ورودی و ۴ خروجی با دارایی پنهان (تراکنشها و اقدامات). اسلاتهای 0–1 یک دارایی خصوصی را حمل میکنند، RAND یا هر توکن RPL، و مدار هرگز نمیفهمد کدام. اسلاتهای 2–3 همیشه RAND حمل میکنند. انتقال هر دارایی Action::None است، همان اقدامی که یک پرداخت ساده RAND استفاده میکند. هیچ اقدام انتقال توکن و هیچ فیلد عمومیای که توکن را نام ببرد وجود ندارد.
آنچه ناظر در انتقال یک توکن میبیند دقیقاً همان است که یک پرداخت RAND منتشر میکند: یک لنگر، چهار نالیفایر، چهار تعهد، کارمزد fee به RAND، burn_a = burn_r = burn_asset = 0، یک time، چهار متن رمزشدهٔ پاکت و اثبات بسته. از زنجیرهٔ ۱۷ به بعد (احراز مجوز تفکیکشده)، هر بسته یک auth_commit و یک اثبات احراز مجوز دوم و کوچکتر هم دارد که باز برای همهٔ داراییها یکسان است. در زنجیرهٔ ۲۰ هر پاکت دقیقاً 1,860 بایت است و جا برای یک یادداشت رمزشده (rand send --memo) دارد، چه فرستاده شود و چه نه. ناظر فرستنده، گیرنده، مقدار، دارایی منتقلشده، اسلاتهای ساختگی و باقیمانده را نمیبیند.
کیف پول حداکثر دو نوت از توکن را در اسلاتهای ۰ و ۱ و حداکثر دو نوت RAND را برای کارمزد در اسلاتهای ۲ و ۳ خرج میکند. کارمزد همیشه به RAND است، بنابراین دارندهٔ توکنی که RAND ندارد پیش از اثباتسازی رد میشود. هزینه با هزینهٔ یک پرداخت RAND یکسان است (کارمزدها). در زنجیرهٔ ۲۰ این یعنی دو اثبات STARK که روی دستگاه فرستنده ساخته میشوند: احراز مجوز خرج (سطح ۱۰، حدود 7 ثانیه، حدود 1.37 MB) و بسته (سطح ۱۴، حدود 100 ثانیه، حدود 1.5 MB)، که روی هم حدود 2.85 MB روی شبکه میشود. هر کدام زیر سقف 4 MiB زنجیره برای یک اثبات است. پیش از زنجیرهٔ ۱۷ یک انتقال فقط اثبات بسته را داشت، حدود 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 در ضرب شامل چکیدهٔ پاکت است: تعهد بهتنهایی آن را پوشش نمیدهد، و بدون چکیده، شخص ثالث میتوانست یک ضرب منتشرشده را با پاکتی بیمعنی دوباره بستهبندی کند و nonce را مصرف کند.
هر دو عمل سوار بر یک بستهٔ کارمزد RAND میشوند که BUNDLE_BASE میپردازد. کیف پولی که کارمزد را میپردازد و کلیدی که ضرب را مجاز میکند جدا هستند و میتوانند متعلق به افراد مختلف باشند.
سوزاندن
Action::TokenBurn { asset, amount } سوار بر همان بستهٔ واحد میشود: burn_asset بسته باید برابر asset باشد، burn_a باید برابر amount باشد و burn_r برابر 0 است. توکن از طریق اسلاتهای دارایی از استخر خارج میشود و کارمزد RAND از طریق اسلاتهای ۲ و ۳ همان اثبات. total_supply دقیقاً به اندازهٔ amount کم میشود. توکنی با مرجع Bridge اینجا رد میشود (TokenError::BridgedToken)؛ چنین توکنی از طریق سوزاندن پل خارج میشود.
کارمزدها
هر عمل RPL به RAND پرداخت میشود.
| عمل | کف کارمزد | در زنجیرهٔ ۲۰ |
|---|---|---|
انتقال هر دارایی (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 |
جنسیس زنجیرهٔ ۲۰ بخشی به نام gas دارد و آن فقط قیمت فراخوانی و اجرای برنامهها را تعیین میکند. این کفها ثابتاند: هیچ عمل RPL بر اساس گس یا بایت پرداخت نمیکند.
چه چیزی عمومی است و چه چیزی پنهان
| عمومی | پنهان | |
|---|---|---|
| ثبت | نام، نماد، تعداد ارقام اعشار، مرجع مجاز، شناسهٔ دارایی، مقدار و گیرندهٔ ضرب اولیه | هیچ؛ به همین دلیل عرضهٔ توکن از همان بلوک نخست قابل حسابرسی است |
| ضرب بعدی | مقدار، آدرس محافظتشدهٔ گیرنده، فیلدهای نوت جدید | اینکه چه کسی کارمزد RAND را پرداخته است |
| انتقال | هیچ چیزی که نشان دهد توکنی جابهجا شده است | فرستنده، گیرنده، مقدار، دارایی |
| سوزاندن | دارایی و مقدار | اینکه چه کسی نوتهای سوزاندهشده را در اختیار داشته است |
| تغییر مرجع مجاز | کلید جدید، یا اینکه مرجع رها شده است | — |
بنابراین total_supply همیشه قابل حسابرسی است: آنچه ثبت و هر ضرب افزودهاند منهای هر سوزاندن. انتقال میان دارندگان هیچ چیز را فاش نمیکند، از جمله اینکه بهجای RAND یک توکن دستبهدست شده است.
افشا مانند RAND کار میکند. متن آشکار نوت دارایی را در خود دارد، پس یک کلید هر تراکنش (rand tx-key <hash>) یا یک کلید مشاهده، نوت توکن را دقیقاً همانطور که نوت RAND را باز میکند باز میکند، و rand_checkTransaction و rand_getViewingNotes در نوتی که افشا میکنند asset را برمیگردانند. با داشتن چنین کلیدی، randscan شاخص را در برابر رجیستری حل میکند و انتقال را بهصورت توکن نامدار نشان میدهد؛ صفحهٔ عمومی همان تراکنش هیچیک از اینها را نشان نمیدهد.
توکنهای پلشده
توکنی با مرجع Bridge همچنان یک توکن RPL است: همان ورودی رجیستری، همان انتقال پنهان، همان سازوکار سوزاندن. عرضهٔ آن فقط از طریق قفل روی یک زنجیرهٔ مبدأ (BridgeAttest) یا یک آزادسازی (BridgeBurn) جابهجا میشود. یک توکن پلشده میتواند چندین پشتوانه داشته باشد، هر کدام یک جفت (chain, token) با ارقام اعشار مبدأ، مقدار قفلشده و سقف ضرب خودش، و total_supply همیشه برابر مجموع آن چیزی است که پشتوانههایش قفل کردهاند. ثبت یک توکن پلشده و افزودن یک پشتوانه فقط تحت حدنصاب نگهبانان پساکوانتومی پل ممکن است.
در زنجیرهٔ ۲۰ نخستین توکن رجیستری zUSD («Shielded USD») است، با شاخص 1 و 8 رقم اعشار، که در فایل جنسیس با هفت پشتوانه فهرست شده است (USDT و USDC روی Ethereum، Binance Smart Chain و Solana، و USDT روی Tron). این توکن همان شناسهٔ داراییای را نگه داشته که در زنجیرهٔ ۱۴ داشت، جایی که با تراکنش در ارتفاع 256 ثبت شد: زنجیرههای ۱۵ تا ۲۰ هر کدام آن را در جنسیس با همان نام، نماد و salt فهرست کردهاند. زنجیرهٔ ۲۰ را با 99 zUSD در دو نوت جنسیس (10 و 89) آغاز کرد، با پشتوانهٔ 22 USDT قفلشده روی Ethereum، 22 روی Binance Smart Chain، 30 روی Tron و 25 روی Solana، که از وضعیت پل زنجیرهٔ ۱۹ منتقل شده بود. زنجیرهٔ ۱۹ با 10 zUSD آغاز شد که پشتوانهٔ آن 10 USDT روی Solana بود؛ زنجیرهٔ ۱۸ با 9 USDT قفلشده روی Tron و 1 روی Solana. عرضهٔ کل آن برابر چیزی است که پشتوانههایش قفلشده نگه میدارند و با هر واریز و بازخرید جابهجا میشود. شناسهٔ آن rpl1xtj6k2x8strx8c2d5fjs50ltztck5ykms4ve7nmzmstf6fhn0v0spelqtx است. پل پشتوانهها، واحدهای آزادسازی، سقفهای ضرب، توقف و همامضایی را توضیح میدهد.
zUSD یک سبد است، نه هفت ادعای جداگانه. پشتوانههای آن به ارزش اسمی در هم ادغام شدهاند، پس دارنده ریسک همهٔ پشتوانههای فهرستشده را میپذیرد، نه فقط ریسک سکهای که واریز کرده است: پشتوانهای که پیوند ارزی خود را از دست داده میتواند به ارزش اسمی واریز شود و zUSD به سمت یک پشتوانهٔ سالم سوزانده شود، تا وقتی که پشتوانههای سالم تخلیه شوند. آنچه زیان را محدود میکند پنجرهٔ ضرب غلتان است (در زنجیرهٔ ۲۰، 4,000 zUSD در مجموع همهٔ پشتوانهها در هر 24 ساعت، در کنار 100,000 برای هر پشتوانه) و نگهداری واقعاً قفلشده. پنجره نرخ را محدود میکند و زمان توقف ضربها را فراهم میآورد. مجموع را سقف نمیگذارد. یک پشتوانه فقط تحت حدنصاب نگهبانان پساکوانتومی فهرست میشود، و نه در زمانی که ضربها متوقف است.
کارمزدهای پل، به zUSD (زنجیرهٔ ۲۰). جنسیس زنجیرهٔ ۲۰ مقدار bridge.fees را تعیین میکند: 10 bps برای واریز و 10 bps برای سوزاندن، هر کدام به سمت پایین تا یک واحد آزادسازی کامل پشتوانه گرد میشود (100 واحد پایه برای USDT با 6 رقم اعشار)، که بهصورت یک نوت 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، یک عامل پوشاننده که از چکیدهٔ گواهی یا شناسهٔ تراکنش سوزاندن مشتق میشود، و مالک از جنسیس)، پس کیف پول خزانه آن را از فیلدهای عمومی بازسازی میکند (نوتها). BRIDGE_BURN_FEE، یعنی 0.01 RAND که یک سوزاندن به پیشنهاددهنده میپردازد، بدون تغییر است. زنجیرههای ۱۴ تا ۱۹ روی Rand کارمزد پل نداشتند.
رجیستری از زنجیرهٔ ۱۵ به بعد
از زنجیرهٔ ۱۵ جنسیس سه قاعدهٔ رجیستری را روشن میکند که زنجیرهٔ ۱۴ نداشت، و جنسیس زنجیرهٔ ۲۰ همان سه مقدار را تعیین میکند. هر کدام در هش جنسیس و ریشهٔ توکن ثبت میشود.
| فیلد genesis | chain 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 میشمارد (Supply) |
tokens.bound_note_value | true | یک TokenMint، یک مینت اولیه یا یک واریز پل به مقدار 2^63 یا بیشتر با AmountTooLarge رد میشود، و مقداری که total_supply یک توکن را به 2^63 یا فراتر از آن برساند با SupplyTooLarge رد میشود |
کران مقدار note وجود دارد چون مدار bundle هر مقدار را تا 63 بیت بررسی بازه میکند: یک note با ارزش 2^63 یا بیشتر قابل commit شدن است اما هرگز خرج نمیشود، در حالی که همچنان در عرضهی توکن شمرده میشود. هر node همچنین چنین مقداری را هنگام پذیرش در هر chain رد میکند، فارغ از آنچه genesis آن میگوید.
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 رقمی هگز یا rpl1… | ردیف یک توکن، یا null؛ شناسهی بدشکل -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 در chain بدون سقف 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 به node میگویند فراخواننده به کدام توکن اهمیت میدهد: برای یک explorer مناسب است، اما برای کیف پولی که در آستانهی ارسال است نادرست. بنابراین کیف پول هر --asset را از فهرست کامل resolve میکند و یک اندیس عددی هرگز به node نمیرسد.
| دستور | کاری که میکند |
|---|---|
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> | ارسال یک توکن در یک bundle؛ بدون --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 خودِ ردیف رجیستری آن خوانده میشوند: 1.5 از یک توکن با 6 رقم اعشار برابر 1,500,000 از کوچکترین واحد آن است، و ارقام اعشاری بیشتر از آنچه توکن دارد رد میشود. تأییدیهی send هر دو را چاپ میکند (1.500000 USDX (1500000 units)). --fixed-supply و --initial در rand token create همچنان کوچکترین واحدهای کامل را میگیرند، همانطور که rand bridge-burn میگیرد، و rand asset-balance کوچکترین واحدها را چاپ میکند. روی chain، مقدار همیشه عدد صحیح کوچکترین واحد است. پرچمها و پیشفرضها در Command line آمده است.
تفاوتها با ERC-20 و SPL
| ERC-20 / SPL | RPL | |
|---|---|---|
| موجودیها | یک نگاشت یا حساب عمومی | noteهای shielded؛ فقط دارندهی کلید میتواند آنها را ببیند |
| رویدادهای انتقال | عمومی، با فرستنده، گیرنده و مقدار | ندارد؛ یک انتقال هیچ چیز متمایزکنندهای منتشر نمیکند |
| کد بهازای هر توکن | ممکن: مالیات، rebase، hook، فریز | ندارد؛ هر توکن از همان قواعد ثابت پیروی میکند |
| نگهداری توسط یک برنامه | بله | روی chain 20 (RPL-2): خزانهی عمومی یک برنامه، که با فیلدهای burn در یک invoke پر میشود و بهصورت noteهای محاسبهشده توسط chain پرداخت میشود |
| مقدارها | تا 256 بیت (ERC-20)، 64 بیت (SPL) | u64، حداکثر 9 رقم اعشار |
| دریافت | ERC-20 به هیچ راهاندازی نیاز ندارد؛ SPL به یک associated token account نیاز دارد | بدون راهاندازی؛ یک آدرس shielded هر چیزی را دریافت میکند |
| هزینهی یک انتقال | اجرای سادهی EVM یا SVM | اثبات توسط فرستنده: bundle مشترک دارایی پنهان، و از chain 17 یک اثبات مجوز کوچک در کنار آن |
| تأییدیهها (approvals) | approve / transferFrom | هنوز نه |
| فراداده | در برخی پیادهسازیها قابل تغییر | روی chain و تغییرناپذیر |
| فریز، فهرست سیاه | روی برخی توکنها ممکن | عمداً خارج از دامنه |
محدودیتهای شناختهشده
- بدون allowance.
approveوtransferFromدر مشخصات RPL بهصورت حسابهای allowance اختصاصیافته طراحی شدهاند و ساخته نشدهاند. - داراییهای یک برنامه عمومی است. روی chain 20 یک برنامه میتواند توکنها را در خزانهی خود نگه دارد و توکن خودش را مینت کند (RPL-2)، اما موجودی خزانه عمومی است، مانند عرضهی یک توکن؛ فقط noteها خصوصیاند. chainهای پیش از 20 هیچ وضعیت برنامهای نداشتند.
- کارمزدها فقط RAND است. یک توکن نمیتواند کارمزد خودش را بپردازد؛ کیف پولی که فقط توکن دارد نمیتواند جابهجایی کند.
- مقدارهای
u64و حداکثر 9 رقم اعشار. یک کوین مبدأ با 18 رقم اعشار با دقت پایینتر نمایش داده میشود؛ پل این را با 8 رقم اعشار و یک واحد آزادسازی بهازای هر پشتوانه حل میکند. - هر انتقال اثبات میشود. حدود 100 s و چندین GB حافظه روی دستگاه فرستنده؛ برای یک توکن مسیر ارزانتری از RAND وجود ندارد.
- بدون فریز، فهرست سیاه یا توقف روی یک توکن بومی، بهموجب تصمیم طراحی. توقف مینت پل فقط برای مینتهای پلشده اعمال میشود.
- جستوجوهای مختص هر توکن، علاقه را فاش میکنند.
rand_getToken،rand_getTokenSupplyو/tokens/:idدر explorer به سرور میگویند دربارهی کدام توکن پرسیده شده است.