Mint und Burn

Verwenden Sie diese Seite, um einen Faucet gegen eine Test-Chain zu betreiben, um zu verstehen, was eine Mint-Transaktion auf der Leitung ist, und um genau zu sehen, wie eine Bond- oder Bridge-Burn-Transaktion Wert aus dem Pool herausnimmt. Jeder Eintritt und jeder Austritt ist öffentlich; alles dazwischen ist eine Note.

Der Faucet-Mint

Ein Mint ist auf Chain 20 der einzige Weg, nach dem Genesis RAND zu erzeugen, und er existiert nur auf Chains, deren Genesis "faucet": true enthält. Er ist eine vom Validator signierte Transaktion ohne Bundle:

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

rand_mint(address[, amount]) auf einem Validator-Knoten erzeugt eine Note über amount an die angegebene rand1…-Adresse, versiegelt ihren Envelope unter einem Einweg-Absenderschlüssel, signiert den Mint mit dem eigenen Dilithium2-Schlüssel des Knotens und reicht ihn über das normale Mempool ein – der Mint durchläuft also den Konsens, und jeder Knoten wendet ihn an. Die Obergrenze beträgt 100000000000 Einheiten, also 100 RAND, pro Aufruf, und der Standardwert ist die Obergrenze. Seit Chain 14 trägt der Mint die Öffnung der Note – pk, time und r – und die Signatur deckt sie ab: Die Zulassung berechnet die Commitment von (pk, no sender, amount, asset 0, time, r) neu und weist ein cm, das nicht übereinstimmt, mit the mint's commitment does not open to its published note and amount zurück; außerdem bindet sie time an das Bundle-Fenster. Die Parameter von rand_mint sind unverändert. Die signierte Nachricht ist auf den Chains 14 bis 19 blake3("rand-mint-2" ‖ bincode(chain_id, cm, pk, time, r, envelope, amount)); auf Chain 20, deren Genesis binding_domain: 1 setzt, ist es rand-mint-3 über den Genesis-Hash, gefolgt von denselben Feldern. Ein für eine Chain signierter Mint wird daher auf jeder anderen abgelehnt, selbst auf einer, die dieselbe Chain-ID und dieselben Validator-Schlüssel teilt. Ein Beobachter hat keinen Validator-Schlüssel und antwortet mit faucet mints are signed by validators; ask a validator node; eine Chain ohne das Flag antwortet mit faucet is disabled on this chain.

Der Faucet von Chain 20 ist aktiv, aber durch den staking-Abschnitt des Genesis begrenzt, mit denselben Werten wie bei Chain 19:

rand faucet funktioniert auf Chain 20 also nur für eine Wallet auf der Liste, angefragt bei einem Validator-Knoten, dessen Schlüssel ein aufgeführter Minter ist; jede andere Adresse muss von jemandem bezahlt werden, der RAND hält.

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"

Öffentlich sind: die Commitment der neuen Note, ihr Envelope, der Betrag im Klartext sowie der öffentliche Schlüssel des mintenden Validators (als dessen Adresse angezeigt) und seine Signatur. Die Öffnung veröffentlicht außerdem den Eigentümerschlüssel pk der Note, sodass der Eigentümer einer Faucet-Note öffentlich ist, ebenso wie die Auszahlung eines Withdraw; verborgen bleibt, wann und wo diese Note später ausgegeben wird. Die Verbindung in einem Schritt von „100 RAND wurden gemintet“ zu „eine Note über 100 RAND existiert“ ist dieselbe Sichtbarkeit, die eine Einzahlung von transparent nach abgeschirmt überall hat. Die Zulassung prüft, dass der Faucet aktiviert ist, der Betrag unter der Obergrenze liegt, das Budget der Epoche noch Platz hat, der Empfänger auf der Allowlist steht, wo das Genesis eine hat, die Commitment sich zur veröffentlichten Note öffnet, der Minter ein Validator ist und auf der Minter-Liste steht, wo das Genesis eine hat, und die Signatur verifiziert; ein Mint zahlt keine Gebühr.

rand_getTransaction stellt einen Mint als { "kind": "mint", "cm": "…", "amount": "100000000000", "minter": "<validator base58>" } mit "bundle": null dar – der Betrag ist ein Dezimal-String, wie jeder u64-Betrag, den die RPC seit Chain 14 liefert; der Explorer führt sie unter kind=mint auf, einer der wenigen Typen mit einem öffentlichen amount.

Genesis-Einzahlungen

Der andere Weg, auf dem Wert eintritt, ist die Genesis-Datei: Jedes --alloc rand1<address>=<RAND> an rand-node genesis wird zu einer Einzahlungs-Note { cm, envelope, amount, opening } mit frischer Commitment-Zufälligkeit, den ersten Blättern des Baums. Chain 20 hat neun Genesis-Noten: sieben RAND-Noten, insgesamt 5.184,243719258 RAND (genesis_deposited), die Operator-Guthaben, übernommen aus einem Snapshot von Chain 19, und zwei zUSD-Noten über 10 und 89 zUSD, die 99 zUSD der Bridge-Verwahrung aus Chain 19 (Bridge), die kein RAND sind und nicht in genesis_deposited zählen. RAND, das auf Chain 19 von Wallets gehalten wurde, die der Operator nicht hält, etwa 520 RAND, sowie nicht abgehobene Validator-Gebühren wurden nicht übernommen. Verlauf: Chain 19 hatte acht, sieben RAND-Noten über 5.294,644359629 RAND und eine über 10 zUSD; Chain 18 hatte sechs RAND-Noten, fünf zu je 1.000 RAND und eine zu 300 RAND; die Chains 14 und 15 hatten fünf zu je 1.000 RAND. Der Betrag ist öffentlich, damit jeder das Anfangsangebot aufsummieren kann, und seit Chain 14 trägt die Note auch ihre Öffnung, sodass der Eigentümer einer Genesis-Note absichtlich öffentlich ist. Wird dieselbe Zuteilung erneut geschnitten, ergeben sich andere Noten und ein anderer Genesis-Hash – mit Absicht.

Burns

Jede Transaktion trägt ein Bundle mit vier Slots für verborgene Assets, und es hat zwei Burn-Wörter: burn_r ist RAND, das den Pool in einen öffentlichen Ort verlässt, und burn_a ist ein Betrag des durch burn_asset benannten Tokens. Der Bundle-Guest gleicht beide Gruppen in einem Beweis aus, und die Zulassung verlangt, dass alle drei null sind, außer bei diesen Aktionen:

(Das Bundle eines register_aggregator verbrennt über burn_r ebenfalls seine Genesis-Bond; die Aggregation ist auf Chain 20 abgeschaltet.)

Burns sind keine Gebühren. Der Burn eines Bond ist RAND, das vom Pool ins Register wandert, und wird im burned des Angebots-Audits gezählt (und taucht in register_total wieder auf). Ein Bridge-Burn ist seit Chain 14 ein einziges Bundle (zuvor waren es zwei): Die Slots 0–1 verbrennen das gebridgte Asset und die Slots 2–3 zahlen die Gebühr, sodass er das RAND-Angebot nur über diese Gebühr berührt, BRIDGE_BURN_FEE, 0,01 RAND. Er muss eine Münze benennen, die das Asset deckt, eine ganze Zahl von Einheiten dieser Münze freigeben und in das passen, was diese Deckung gesperrt hat (Bridge). Auf Chain 20 erhebt das Genesis-bridge.fees außerdem 10 bps auf jeden gebridgten Mint und Burn in zUSD: Eine Einzahlung schreibt den Bruttobetrag abzüglich der Gebühr gut, und ein Burn gibt amount − fee frei, jede Gebühr als abgeschirmte zUSD-Note an das Treasury. Die Gebühren-Note bleibt ausgegeben und gedeckt, sodass total_supply == Σ locked von zUSD weiterhin gilt; sie ist keine RAND-Bewegung und geht nicht in das Audit des RAND-Angebots ein. Ein TokenBurn zahlt die Bundle-Basis von 0,001 RAND; ein gebridgter Token wird dort abgelehnt und verlässt die Chain über bridge-burn.

Eine Gebühr ist auf Chain 20 ebenfalls ein Burn, wie auf jeder Chain seit 15: Ihr Genesis setzt tokens.burn_registration_fee, sodass die registration_fee von 1 RAND einer RegisterToken oder RegisterBridgedToken zerstört statt an den Proposer gezahlt wird, der nur die Bundle-Basis behält. Sie wird in burned und gesondert in registration_fees_burned gezählt (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

Gebühren sind der andere Ausgang

Die fee jedes Bundles verlässt den Pool in die rewards des Block-Proposers, ein öffentliches Register-Feld, und kehrt nur dann in den Pool zurück, wenn der Validator sie als Note abhebt (Staking). Ein Withdraw zahlt die Basis von 0,001 RAND aus dem abgehobenen Betrag an den Proposer des Blocks, der ihn anwendet; diese Basis verlässt das Register nie, sie ist also keine Überschreitung der Grenze.

Wie sich das Angebot bewegt

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 und program_rand_out sind neu auf Chain 20 (RPL-2): RAND, das ein Invoke über burn_r in einen Programm-Vault verbrennt, wird auf der Pool-Seite in burned gezählt und im Vault gehalten, und was ein Vault als Noten auszahlt, kehrt in den Pool zurück. rand_getSupply liefert beides, mit invariant_holds.

Nur ein Faucet-Mint erhöht die Menge, die die Chain ausgegeben hat, und auf chain 20 verringert sie nur eine verbrannte Registrierungsgebühr: slashed würde eine geslashte Aggregator-Kaution zählen oder, unter einem genesis-Abschnitt staking.slashing, einen geslashten Validator-Stake, und chain 20 hat keines von beidem (Aggregation ist abgeschaltet und slashing ist null). Eine Kaution, eine Gebühr, ein Withdraw und eine Vault-Einzahlung verschieben Wert zwischen dem Pool, dem Register und den Vaults und schaffen nichts. Token-Angebot enthält die Zähler und ein durchgerechnetes Beispiel. Die Block-Aggregations-Subvention – neue RAND pro versiegeltem Block nach einem Halbierungsplan, die als Einzahlungs-Note an einen Aggregator gezahlt werden – wäre die erste planmäßige Ausgabe, und sie ist auf chain 20 nicht aktiv.