Création et destruction

Utilisez cette page pour exploiter un faucet sur une chaîne de test, pour comprendre ce qu’est une transaction Mint sur le réseau, et pour voir exactement comment une obligation (bond) ou un burn de pont retire de la valeur du pool. Chaque entrée et chaque sortie est publique ; tout ce qui se passe entre les deux est une note.

Le mint du faucet

Un Mint est le seul moyen de créer des RAND après la genèse sur la chain 20, et il n’existe que sur les chaînes dont la genèse indique "faucet": true. C’est une transaction signée par un validateur, sans bundle :

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

rand_mint(address[, amount]) sur un nœud validateur construit une note de amount à destination de l’adresse rand1… indiquée, scelle son enveloppe sous une clé d’expéditeur jetable, signe le mint avec la clé Dilithium2 propre au nœud, et le soumet via le mempool normal : le mint passe donc par le consensus et chaque nœud l’applique. Le plafond est de 100000000000 unités, soit 100 RAND, par appel, et la valeur par défaut est ce plafond. Depuis la chain 14, le mint porte l’ouverture de la note (pk, time et r) et la signature la couvre : l’admission recalcule l’engagement de (pk, no sender, amount, asset 0, time, r) et refuse un cm qui ne correspond pas, avec the mint's commitment does not open to its published note and amount, et elle borne time à la fenêtre du bundle. Les paramètres de rand_mint sont inchangés. Le message signé est blake3("rand-mint-2" ‖ bincode(chain_id, cm, pk, time, r, envelope, amount)) sur les chaînes 14 à 19 ; sur la chain 20, dont la genèse définit binding_domain: 1, il s’agit de rand-mint-3 appliqué au hash de genèse suivi des mêmes champs, de sorte qu’un mint signé pour une chaîne est refusé sur toute autre, même si elle partage le même identifiant de chaîne et les mêmes clés de validateurs. Un observateur n’a pas de clé de validateur et répond faucet mints are signed by validators; ask a validator node ; une chaîne sans ce drapeau répond faucet is disabled on this chain.

Le faucet de la chain 20 est activé mais borné par la section staking de sa genèse, avec les mêmes valeurs que celles de la chain 19 :

Ainsi, rand faucet ne fonctionne sur la chain 20 que pour un portefeuille figurant sur la liste, sollicité auprès d’un nœud validateur dont la clé est un minter listé ; toute autre adresse doit être approvisionnée par quelqu’un qui détient des 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"

Ce qui est public : l’engagement de la nouvelle note, son enveloppe, le montant en clair, ainsi que la clé publique du validateur qui a émis le mint (affichée comme son adresse) et sa signature. L’ouverture publie aussi la clé propriétaire pk de la note ; le propriétaire d’une note de faucet est donc public, comme l’est le versement d’un retrait ; ce qui reste caché, c’est le moment et le lieu où cette note est dépensée par la suite. Le lien direct entre « 100 RAND ont été émis » et « une note de 100 RAND existe » correspond à la même visibilité que celle d’un dépôt du transparent vers le shielded, où que ce soit. L’admission vérifie que le faucet est activé, que le montant est inférieur au plafond, que le budget de l’époque dispose de marge, que le destinataire figure sur la liste d’autorisation lorsque la genèse en prévoit une, que l’engagement s’ouvre sur la note et le montant publiés, que le minter est un validateur (et figure sur la liste des minters lorsque la genèse en prévoit une), et que la signature est valide ; un mint ne paie aucuns frais.

rand_getTransaction en restitue un sous la forme { "kind": "mint", "cm": "…", "amount": "100000000000", "minter": "<validator base58>" } avec "bundle": null : le montant est une chaîne décimale, comme tout montant u64 servi par le RPC depuis la chain 14 ; l’explorateur les répertorie sous kind=mint, l’un des rares types dont le amount est public.

Dépôts de genèse

L’autre voie d’entrée de la valeur est le fichier de genèse : chaque --alloc rand1<address>=<RAND> passé à rand-node genesis devient une note de dépôt { cm, envelope, amount, opening } avec une aléa d’engagement neuf, ce sont les premières feuilles de l’arbre. La chain 20 compte neuf notes de genèse : sept notes RAND, 5,184.243719258 RAND au total (genesis_deposited), soit les soldes des opérateurs reportés depuis un instantané de la chain 19, et deux notes zUSD de 10 et 89 zUSD, les 99 zUSD de la garde du pont reportés depuis la chain 19 (Bridge), qui ne sont pas des RAND et ne sont pas comptés dans genesis_deposited. Les RAND détenus sur la chain 19 par des portefeuilles que l’opérateur ne contrôle pas, environ 520 RAND, ainsi que les frais de validateur non retirés, n’ont pas été reportés. Historique : la chain 19 en comptait huit, sept notes RAND de 5,294.644359629 RAND et une de 10 zUSD ; la chain 18 comptait six notes RAND, cinq de 1,000 RAND et une de 300 RAND ; les chains 14 et 15 en comptaient cinq de 1,000 RAND. Le montant est public afin que chacun puisse additionner l’offre initiale, et depuis la chain 14 la note porte aussi son ouverture, de sorte que le propriétaire d’une note de genèse est public par conception. Recréer les mêmes allocations produit des notes différentes et un hash de genèse différent, volontairement.

Burns

Chaque transaction porte un bundle d’actifs cachés à quatre emplacements, et il comporte deux mots de burn : burn_r correspond aux RAND qui quittent le pool vers un lieu public, et burn_a à un montant du token désigné par burn_asset. Le guest du bundle équilibre les deux groupes dans une seule preuve, et l’admission exige que les trois soient nuls, sauf pour ces actions :

(Le bundle d’un register_aggregator brûle aussi sa bond de genèse via burn_r ; l’agrégation est désactivée sur la chain 20.)

Les burns ne sont pas des frais. Le burn d’une bond est un mouvement de RAND du pool vers le registre ; il est compté dans le burned de l’audit de l’offre (et réapparaît dans register_total). Un burn de pont est un seul bundle depuis la chain 14 (il y en avait deux auparavant) : les emplacements 0–1 brûlent l’actif ponté et les emplacements 2–3 paient les frais, de sorte qu’il ne touche à l’offre de RAND qu’à travers ces frais, BRIDGE_BURN_FEE, 0.01 RAND. Il doit désigner une monnaie qui adosse l’actif, libérer un nombre entier d’unités de cette monnaie, et tenir dans ce que cet adossement a verrouillé (Bridge). Sur la chain 20, son bridge.fees de genèse prélève aussi 10 bps sur chaque mint et chaque burn pontés, en zUSD : un dépôt crédite le brut moins les frais et un burn libère amount − fee, chaque prélèvement étant une note zUSD shielded versée à la trésorerie. La note de frais reste émise et adossée, de sorte que total_supply == Σ locked de zUSD continue de tenir ; ce n’est pas un mouvement de RAND et elle n’entre pas dans l’audit de l’offre de RAND. Un TokenBurn paie la base de bundle de 0.001 RAND ; un token ponté y est refusé et sort par bridge-burn.

Un frais est aussi un burn sur la chain 20, comme sur toutes les chaînes depuis la 15 : sa genèse définit tokens.burn_registration_fee, de sorte que les 1 RAND de registration_fee d’un RegisterToken ou d’un RegisterBridgedToken sont détruits au lieu d’être versés au proposeur, qui ne conserve que la base du bundle. Ils sont comptés dans burned et, séparément, dans 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

Les frais sont l’autre sortie

Les fee de chaque bundle quittent le pool vers les rewards du proposeur du bloc, un champ public du registre, et ne reviennent dans le pool que lorsque le validateur les retire sous forme de note (Staking). Un Withdraw paie la base de 0.001 RAND prélevée sur le montant retiré au proposeur du bloc qui l’applique ; cette base ne quitte jamais le registre, ce n’est donc pas un franchissement.

Comment l’offre évolue

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 et program_rand_out sont nouveaux sur la chain 20 (RPL-2) : les RAND qu’un Invoke brûle dans un coffre de programme via burn_r sont comptés dans burned côté pool et conservés dans le coffre, et ce que le coffre verse sous forme de notes revient dans le pool. rand_getSupply sert les deux, avec invariant_holds.

Seul un mint du faucet augmente ce que la chaîne a émis, et sur la chain 20 seule des frais d’enregistrement brûlés le diminuent : slashed comptabiliserait un bond d’aggregator slashé ou, sous une section genesis staking.slashing, la mise d’un validator slashée, et la chain 20 n’a ni l’un ni l’autre (l’agrégation est désactivée et slashing vaut null). Un bond, des frais, un retrait et un dépôt en vault déplacent de la valeur entre le pool, le registre et les vaults, et ne créent rien. Supply présente les compteurs et un exemple détaillé. La subvention d’agrégation de blocs — de nouveaux RAND par bloc scellé selon un calendrier de halving, versés à un aggregator sous forme de note de dépôt — serait la première émission programmée, et elle n’est pas active sur la chain 20.