ضرب و سوزاندن

از این صفحه برای اجرای یک faucet روی زنجیره‌ی آزمایشی استفاده کنید، تا بدانید تراکنش Mint روی شبکه چیست، و ببینید یک bond یا یک bridge burn دقیقاً چگونه ارزش را از استخر بیرون می‌برد. هر ورودی و هر خروجی عمومی است؛ هر چه در میان است، یک نوت است.

mint مربوط به faucet

Mint تنها راه ایجاد RAND پس از genesis روی chain 20 است و فقط روی زنجیره‌هایی وجود دارد که genesis آن‌ها "faucet": true دارد. این یک تراکنش بدون bundle و امضاشده توسط validator است:

Action::Mint { cm: Word8, pk: Word8, time: u32, r: Word8, envelope: Envelope, amount: u64,
               minter: PublicKey, signature: Signature }

rand_mint(address[, amount]) روی یک نود validator، نوتی به مقدار amount برای نشانی rand1… داده‌شده می‌سازد، پاکت (envelope) آن را با یک کلید فرستنده‌ی یک‌بارمصرف مهر و موم می‌کند، mint را با کلید Dilithium2 خودِ نود امضا می‌کند و از طریق mempool عادی ارسال می‌کند؛ بنابراین mint از اجماع می‌گذرد و هر نود آن را اعمال می‌کند. سقف آن 100000000000 واحد، یعنی 100 RAND، در هر فراخوانی است و مقدار پیش‌فرض همان سقف است. از chain 14 به بعد، mint شامل گشایش (opening) نوت است — یعنی pk، time و r — و امضا آن را پوشش می‌دهد: در پذیرش، تعهد (commitment) مربوط به (pk, no sender, amount, asset 0, time, r) دوباره محاسبه می‌شود و cm نامنطبق با پیام the mint's commitment does not open to its published note and amount رد می‌شود، و time به پنجره‌ی bundle محدود می‌گردد. پارامترهای rand_mint تغییری نکرده‌اند. پیام امضاشده در chain 14 تا 19 برابر blake3("rand-mint-2" ‖ bincode(chain_id, cm, pk, time, r, envelope, amount)) است؛ در chain 20، که genesis آن binding_domain: 1 را تنظیم می‌کند، برابر rand-mint-3 روی هش genesis و سپس همان فیلدهاست، پس mintِ امضاشده برای یک زنجیره روی هر زنجیره‌ی دیگر، حتی زنجیره‌ای با همان chain id و همان کلیدهای validator، رد می‌شود. یک ناظر (observer) کلید validator ندارد و پاسخ می‌دهد faucet mints are signed by validators; ask a validator node؛ زنجیره‌ای بدون این پرچم پاسخ می‌دهد faucet is disabled on this chain.

faucet در chain 20 روشن است اما بخش staking در genesis آن را محدود می‌کند، با همان مقادیر chain 19:

بنابراین rand faucet در chain 20 فقط برای کیف پولی که در فهرست است کار می‌کند، آن هم با درخواست از نود validatorی که کلیدش یکی از mint‌کننده‌های فهرست‌شده است؛ هر نشانی دیگری را باید کسی که RAND دارد پرداخت کند.

rand faucet                          # 100 RAND to this wallet's address, waits for the commit
rand faucet rand1… --amount 25       # to another address, less than the cap

→ {"method":"rand_mint","params":["rand1…", "100000000000"]}
← "9ab1c0…4f"

آنچه عمومی است: تعهد نوت جدید، پاکت آن، مقدار به‌صورت آشکار، و کلید عمومی validator مینت‌کننده (که به‌صورت نشانی نمایش داده می‌شود) و امضای او. گشایش، کلید مالک نوت یعنی pk را نیز منتشر می‌کند، پس مالک یک نوت faucet عمومی است، همان‌طور که پرداخت یک withdraw عمومی است؛ آنچه پنهان می‌ماند این است که آن نوت بعداً چه زمانی و کجا خرج می‌شود. پیوند یک‌گامی از «100 RAND مینت شد» به «نوتی به ارزش 100 RAND وجود دارد» همان میزان دیده‌شدنی است که یک واریز از شفاف به shielded در هر جای دیگر دارد. پذیرش بررسی می‌کند که faucet فعال باشد، مقدار زیر سقف باشد، بودجه‌ی دوره جا داشته باشد، دریافت‌کننده در فهرست مجاز باشد (جایی که genesis فهرستی دارد)، تعهد به نوت منتشرشده باز شود، mint‌کننده یک validator باشد و در فهرست mint‌کننده‌ها باشد (جایی که genesis فهرستی دارد)، و امضا تأیید شود؛ mint هیچ کارمزدی نمی‌پردازد.

rand_getTransaction آن را به‌صورت { "kind": "mint", "cm": "…", "amount": "100000000000", "minter": "<validator base58>" } با "bundle": null نمایش می‌دهد — مقدار یک رشته‌ی دهدهی است، مانند هر مقدار u64 که RPC از chain 14 به بعد ارائه می‌کند؛ explorer آن‌ها را زیر kind=mint فهرست می‌کند، یکی از معدود انواعی که amount عمومی دارند.

واریزهای genesis

راه دیگر ورود ارزش، فایل genesis است: هر --alloc rand1<address>=<RAND> به rand-node genesis به یک نوت واریز { cm, envelope, amount, opening } با تصادفی‌بودن تازه‌ی تعهد تبدیل می‌شود، که نخستین برگ‌های درخت‌اند. chain 20 نه نوت genesis دارد: هفت نوت RAND، در مجموع 5,184.243719258 RAND (genesis_deposited)، موجودی‌های اپراتور که از یک snapshot از chain 19 منتقل شده‌اند، و دو نوت zUSD به مقدار 10 و 89 zUSD، یعنی 99 zUSD امانت پل که از chain 19 منتقل شده است (Bridge)، که RAND نیستند و در genesis_deposited شمرده نمی‌شوند. RAND موجود در chain 19 در کیف پول‌هایی که اپراتور در اختیار ندارد، حدود 520 RAND، و کارمزدهای برداشت‌نشده‌ی validatorها منتقل نشدند. تاریخچه: chain 19 هشت نوت داشت، هفت نوت RAND به مقدار 5,294.644359629 RAND و یک نوت 10 zUSD؛ chain 18 شش نوت RAND داشت، پنج نوت 1,000 RAND و یک نوت 300 RAND؛ chain 14 و 15 پنج نوت 1,000 RAND داشتند. مقدار عمومی است تا همه بتوانند عرضه‌ی اولیه را جمع بزنند، و از chain 14 به بعد نوت گشایش خود را نیز دارد، پس مالک یک نوت genesis به‌طور عمدی عمومی است. برش دوباره‌ی همان تخصیص‌ها نوت‌های متفاوت و هش genesis متفاوتی می‌دهد، آن هم عمداً.

سوزاندن‌ها (Burns)

هر تراکنش یک bundle چهار‌شکافی از دارایی پنهان دارد و دو کلمه‌ی سوزاندن: burn_r همان RAND است که از استخر به جایی عمومی خارج می‌شود، و burn_a مقداری از توکن نام‌برده در burn_asset است. guest مربوط به bundle هر دو گروه را در یک اثبات متوازن می‌کند، و پذیرش می‌خواهد هر سه صفر باشند، مگر در این اقدام‌ها:

(bundle یک register_aggregator نیز bond genesis خود را از طریق burn_r می‌سوزاند؛ aggregation در chain 20 خاموش است.)

سوزاندن‌ها کارمزد نیستند. سوزاندن یک bond حرکت RAND از استخر به رجیستر است و در burned حسابرسی عرضه شمرده می‌شود (و در register_total دوباره ظاهر می‌شود). سوزاندن پل از chain 14 یک bundle است (پیش‌تر دو تا بود): شکاف‌های 0–1 دارایی پل‌شده را می‌سوزانند و شکاف‌های 2–3 کارمزد را می‌پردازند، پس فقط از طریق همان کارمزد، یعنی BRIDGE_BURN_FEE به مقدار 0.01 RAND، به عرضه‌ی RAND دست می‌زند. باید ارزی را نام ببرد که پشتوانه‌ی دارایی است، تعداد صحیحی از واحدهای آن ارز را آزاد کند، و با آنچه آن پشتوانه قفل کرده سازگار باشد (Bridge). در chain 20، بخش bridge.fees در genesis آن نیز 10 bps از هر mint و سوزاندن پل‌شده را به zUSD می‌گیرد: واریز مقدار ناخالص منهای کارمزد را اعتبار می‌دهد و سوزاندن amount − fee را آزاد می‌کند، و هر کارمزد یک نوت shielded zUSD برای خزانه است. نوت کارمزد همچنان صادرشده و پشتوانه‌دار می‌ماند، پس total_supply == Σ locked برای zUSD همچنان برقرار است؛ حرکت RAND نیست و وارد حسابرسی عرضه‌ی RAND نمی‌شود. یک TokenBurn پایه‌ی bundle به مقدار 0.001 RAND را می‌پردازد؛ توکن پل‌شده در آنجا رد می‌شود و از طریق bridge-burn خارج می‌شود.

یک کارمزد نیز در chain 20 سوزاندن است، مانند هر زنجیره از chain 15 به بعد: genesis آن tokens.burn_registration_fee را تنظیم می‌کند، پس registration_fee به مقدار 1 RAND برای RegisterToken یا RegisterBridgedToken به جای پرداخت به proposer نابود می‌شود، و proposer فقط پایه‌ی bundle را نگه می‌دارد. این مقدار در burned و جداگانه در registration_fees_burned شمرده می‌شود (RPL tokens).

rand bond <validator> 1000 [--registration <hex>]     # burns 1000 RAND out of this wallet's notes
rand bridge-burn <ASSET> <AMOUNT> <TO_CHAIN> <TOKEN> <TO>   # burns AMOUNT of a bridged asset, released as TOKEN on TO_CHAIN
rand token burn <ASSET> <AMOUNT>                      # destroys AMOUNT of an RPL token this wallet holds

کارمزدها خروج دیگرند

fee هر bundle از استخر به rewards پیشنهاددهنده‌ی بلوک، یک فیلد عمومی رجیستر، می‌رود و فقط زمانی به استخر برمی‌گردد که validator آن را به‌صورت نوت برداشت کند (Staking). یک Withdraw پایه‌ی 0.001 RAND را از مقدار برداشت‌شده به proposer بلوکی که آن را اعمال می‌کند می‌پردازد؛ آن پایه هرگز رجیستر را ترک نمی‌کند، پس عبور محسوب نمی‌شود.

عرضه چگونه حرکت می‌کند

in:   genesis_deposited, faucet_minted, withdraw_deposited, program_rand_out
out:  fees_paid, burned
pool_value     = in − out
total_supply   = pool_value + Σ register (stake + pending + rewards) + program_rand_held
               ==  genesis_deposited + genesis_staked + faucet_minted − slashed − registration_fees_burned

program_rand_held و program_rand_out در chain 20 (RPL-2) جدیدند: RANDی که یک Invoke از طریق burn_r به خزانه‌ی یک برنامه می‌سوزاند، در سمت استخر در burned شمرده می‌شود و در خزانه نگه داشته می‌شود، و آنچه خزانه به‌صورت نوت پرداخت می‌کند به استخر برمی‌گردد. rand_getSupply هر دو را همراه با invariant_holds ارائه می‌کند.

فقط mint شیر (faucet) به مقدار آنچه زنجیره صادر کرده می‌افزاید، و روی chain 20 فقط یک کارمزد ثبت‌نامِ سوخته‌شده از آن می‌کاهد: slashed یک وثیقهٔ aggregator که slash شده است را می‌شمارد، یا در بخش staking.slashing در genesis، سهام یک validator که slash شده است را؛ و chain 20 هیچ‌کدام را ندارد (تجمیع خاموش است و slashing برابر null است). یک وثیقه، یک کارمزد، یک برداشت و یک سپردهٔ خزانه (vault) ارزش را میان استخر، دفتر ثبت و خزانه‌ها جابه‌جا می‌کنند و چیزی نمی‌آفرینند. Supply شمارنده‌ها و یک مثال گام‌به‌گام را دارد. یارانهٔ تجمیع بلوک — RAND تازه به ازای هر بلوک مهرشده، بر اساس یک برنامهٔ نیمه‌شدن، که به صورت یک note سپرده به aggregator پرداخت می‌شود — نخستین انتشار زمان‌بندی‌شده خواهد بود و روی chain 20 فعال نیست.