RPL-Token

Auf dieser Seite erfahren Sie, was ein Token auf dieser Chain ist, bevor Sie eines erstellen, listen oder indizieren. RPL ist der Token-Standard von Rand, neu in Chain 14. Ein Token ist ein abgeschirmtes natives Asset: ein Eintrag in einer Ledger-Registry, dessen Guthaben als gewöhnliche Notes im selben Commitment-Baum liegen, den auch RAND verwendet. Es ist kein Contract. Eine Schritt-für-Schritt-Anleitung zum Erstellen finden Sie unter Deploy an RPL token.

Der Grund ist strukturell. Ein Call schreibt nur eine Quittung, ein Contract im Stil von ERC-20 hätte also keinen Ort gehabt, an dem er ein Guthaben hätte führen können. Eine öffentliche Guthabentabelle hätte Tokens zum einzigen transparenten Asset einer abgeschirmten Chain gemacht. RPL macht einen Token stattdessen zu einem erstklassigen Ledger-Objekt. Chain 20 ergänzt RPL-2 (v0.6.8): Ein Programm kann öffentliche State-Zellen und einen öffentlichen Vault führen und die Mint-Autorität eines eigenen Tokens sein (unten); Guthaben, die Personen halten, sind weiterhin Notes.

Ein Token ist ein Registry-Eintrag

TokenRegistry (crates/randprotocol-core/src/ledger/tokens.rs) ist eine Tabelle, die sich alle Tokens teilen, native wie gebridgte. Es ist dieselbe Registry, über die die Bridge den Index eines Assets auflöst. Jeder Eintrag:

Die Nachkommastellen enden bei 9, weil Beträge u64 sind: Bei 18 Nachkommastellen fasst ein u64 nur 18,4 ganze Tokens, und 9 ist die eigene Präzision von RAND. Ein gebridgter Token wird immer mit 8 Nachkommastellen registriert, gleich welche Stellen seine Quell-Coins verwenden.

Die Registry wird durch einen tokens-Abschnitt in der Genesis-Datei eingeschaltet, so wie bridge und aggregation durch ihre. Ohne ihn wird jede Token-Aktion vor jeder anderen Prüfung abgelehnt (TokenError::Disabled). Das Genesis von Chain 20 enthält den Abschnitt und listet einen Token, zUSD, mit seinen sieben Backings, die seit Chain 14 durch jeden Cut weitergetragen wurden; jeder andere Token auf der Chain entsteht per Transaktion. (Das Genesis von Chain 14 listete keinen.) Ist das Gate eingeschaltet, fließt ein tokens_root (die Merkle-Wurzel der Blätter blake3("rand-token-leaf-1", bincode(TokenInfo)) in Indexreihenfolge) in die State-Root ein. Die Domäne dieser Wurzel ist rand-state-4 auf einer Chain, auf der nichts Späteres eingeschaltet ist; die Wurzel von Chain 20 umfasst zusätzlich den Zustand von Faucet und Bond-Queue, die geltenden Gaspreise und die Wurzel des Programmzustands, gehasht unter rand-state-8, und wird ein weiteres Mal von der Menge der zugelassenen Validatoren umhüllt (Consensus).

Eine Chain mit einem tokens-Abschnitt verlangt außerdem, dass jede Genesis-alloc-Note ihre Öffnung (pk, time, r) trägt; der Node berechnet das Commitment neu und lehnt eine Datei ab, die nicht übereinstimmt. Das Commitment liegt auf Asset 0, es sei denn, die Öffnung nennt den Index eines Tokens, den dasselbe Genesis listet. Chain 20 hat zwei solche Notes, 10 und 89 zUSD auf Index 1. Und je gelistetem Token müssen die Genesis-Notes sich zu dem Betrag summieren, mit dem seine Backings als locked beginnen. Sobald eine Note ein asset-Wort hat, das einen Token benennen kann, wäre ein ungeöffnetes Genesis-Commitment der einzige Weg, eine ungedeckte Note beliebigen Assets ungeprüft in den Pool zu bringen.

Asset-ID, Index und rpl1…

Ein Token hat zwei Namen, und die RPC liefert beide.

• Die Asset-ID umfasst 32 Bytes und ist wie eine Programm-ID inhaltsadressiert. Die ID eines nativen Tokens ist blake3("rand-rpl-asset", bincode(name, symbol, decimals, authority, initial, salt)), wobei salt 32 Bytes sind, die der Ersteller wählt, und initial das gesamte anfängliche Minting, falls vorhanden. Die ID eines gebridgten Tokens ist blake3("rand-rpl-asset", bincode(name, symbol, 8, salt)). Das Registrieren einer bereits vorhandenen ID wird abgelehnt (TokenError::AlreadyRegistered).
• Der Index ist das, was eine Note tatsächlich trägt, weil eine 32-Byte-ID nicht in ein Wort passt. Er ist ein Kürzel, das nur auf dieser Chain etwas bedeutet.
• Die Textform rpl1… ist bech32m (BIP-350) mit dem Human-readable Part rpl über die 32 ID-Bytes: 52 Datenzeichen und eine Prüfsumme aus 6 Zeichen, insgesamt 62 Zeichen. Sie wird neben der ID mit 64 Hex-Zeichen angezeigt, wo immer ein Token genannt wird, und überall akzeptiert, wo einer nachgeschlagen wird; Hex bleibt weiterhin zulässig. Das Parsen ist streng: Eine falsche Prüfsumme, ein falsches Präfix, eine Nutzlast, die nicht genau 32 Bytes umfasst, oder gemischte Groß- und Kleinschreibung werden abgelehnt, sodass ein Tippfehler nicht zu einem anderen Token aufgelöst werden kann.

Symbole sind nicht eindeutig. Wie bei ERC-20 und SPL ist die Identität eines Tokens seine Asset-ID, nie sein Name oder Ticker.

Der alte Wert je (chain, token), den rand_bridgeAssetId berechnet und rand_getAssets pro Backing-Zeile ausgibt, ist ein engerer Bezeichner für das Wire-Format der Bridge, nicht die eigene ID des Tokens.

Mint-Autoritäten

Ein RegisterToken, das Bridge nennt, wird abgelehnt (TokenError::AuthorityNotAllowed), ebenso eines, das Program mit einem anfänglichen Minting oder auf einer Chain ohne program_state nennt. Eine Key-Autorität ist genau ein öffentlicher Dilithium2-Schlüssel: Ein Schlüssel jeder anderen Bytelänge wird abgelehnt (TokenError::BadAuthorityKey), und der ML-KEM-Schlüssel des Empfängers in einem Minting wird auf dieselbe Weise an seine Länge gebunden. Beides ist Consensus-Zustand oder zu einer Pauschalgebühr gekaufter Blockplatz, daher darf keines von beiden beliebig groß sein.

Einen Token erstellen

Die Erstellung ist erlaubnisfrei. Action::RegisterToken { name, symbol, decimals, authority, initial, salt, index } läuft in einem gewöhnlichen RAND-Fee-Bundle mit und zahlt BUNDLE_BASE plus die registration_fee der Registry. Die Registrierungsgebühr ist ein Genesis-Parameter zwischen 1 RAND und 10,000 RAND, sodass ein Spam-Token immer etwas kostet. Auf Chain 20 beträgt sie 1 RAND, eine Registrierung kostet also 1,001 RAND, und Chain 20 verbrennt sie, wie es jede Chain seit 15 tut: Der Proposer behält nur die Bundle-Basis (unten).

index nennt den Registry-Index, für den der Ersteller die anfängliche Note versiegelt hat. Hat eine andere Registrierung diesen Index zuerst belegt, wird die Transaktion abgelehnt (TokenError::IndexMismatch), statt die Note zu stranden; der Ersteller beweist erneut für den nächsten Index.

Die geminte Note wird von der Chain berechnet, nicht vom Einreicher gewählt: note_commitment(recipient.pk, MINT_FROM, amount, index, time, r). Der Betrag und der pk des Empfängers sind auf dem Wire öffentlich, sodass der Empfänger die Note aus den eigenen Feldern der Transaktion rekonstruieren kann, selbst wenn der versiegelte Umschlag Müll ist. Eine Bridge-Einzahlung hat denselben Schutz.

Warum die ID das gesamte anfängliche Minting bindet

Ein RegisterToken ist unsigniert. Das Transaction Binding verhindert, dass eine bewiesene Kopie verändert wird, sagt aber nichts darüber, was eine frische Kopie nennen darf. Hätte die ID nur den anfänglichen Betrag abgedeckt, könnte ein Beobachter einer ausstehenden Registrierung eine Kopie mit anderem Empfänger einreichen, sie unter derselben ID registrieren und durch frühere Aufnahme die gesamte Menge eines Tokens mit fester Menge an sich bringen. Weil die ID das gesamte anfängliche Minting abdeckt (Betrag, Empfänger, r, time und Umschlag), hasht eine umgeleitete Kopie zu einer anderen Asset-ID: ein anderer Token mit demselben Symbol, was ein nicht eindeutiges Symbol ohnehin zulässt. Das Original landet weiterhin beim nächsten Index, für die Kosten eines erneuten Beweises.

Transfers sind dasselbe Bundle wie bei RAND

Seit Chain 14 trägt jede wertbewegende Transaktion genau ein Bundle, die feste 4-in-4-out-Form mit verborgenem Asset (Transactions and actions). Die Slots 0–1 tragen ein privates Asset, RAND oder einen beliebigen RPL-Token, und die Schaltung erfährt nie, welches. Die Slots 2–3 tragen immer RAND. Ein Transfer jedes Assets ist Action::None, die Aktion, die auch eine einfache RAND-Zahlung verwendet. Es gibt keine Token-Transfer-Aktion und kein öffentliches Feld, das den Token nennt.

Was ein Beobachter einer Token-Überweisung sieht, entspricht genau dem, was eine RAND-Zahlung veröffentlicht: einen Anchor, vier Nullifier, vier Commitments, die RAND-fee, burn_a = burn_r = burn_asset = 0, eine time, vier Envelope-Chiffretexte und den Bundle-Beweis. Seit Chain 17 (geteilte Autorisierung) trägt jedes Bundle außerdem ein auth_commit und einen zweiten, kleineren Auth-Beweis, ebenfalls für jedes Asset identisch. Auf Chain 20 ist jeder Envelope genau 1.860 Bytes groß und bietet Platz für ein verschlüsseltes Memo (rand send --memo), unabhängig davon, ob eines gesendet wird. Nicht zu sehen sind Sender, Empfänger, Betrag, welches Asset bewegt wurde, welche Slots Dummies waren und das Wechselgeld.

Das Wallet gibt bis zu zwei Notes des Tokens in den Slots 0–1 und bis zu zwei RAND-Notes in den Slots 2–3 für die Gebühr aus. Die Gebühr wird immer in RAND entrichtet; wer einen Token, aber kein RAND hält, wird vor dem Beweisen abgewiesen. Die Kosten entsprechen denen einer RAND-Zahlung (Gebühren). Auf Chain 20 sind das zwei STARK-Beweise, die auf dem Rechner des Senders erzeugt werden: die Ausgabeautorisierung (Tier 10, etwa 7 s, etwa 1,37 MB) und das Bundle (Tier 14, etwa 100 s, etwa 1,5 MB), zusammen etwa 2,85 MB auf der Leitung. Jeder liegt unter der Obergrenze der Chain von 4 MiB pro Beweis. Vor Chain 17 trug eine Überweisung allein den Bundle-Beweis, damals gemessen etwa 1,42 MB.

Minting und die Autorität

TokenMint { asset, amount, recipient, r, time, envelope, nonce, signature } mintet weitere Einheiten eines Key-autorisierten Tokens. SetAuthority { asset, new, nonce, signature } überträgt die Autorität auf einen anderen Schlüssel oder gibt sie auf, wenn new fehlt; nach einem Verzicht kann kein Schlüssel den Token jemals wieder minten. Beide Aktionen werden bei einem Token, dessen Autorität nicht Key ist, abgewiesen (TokenError::NotKeyAuthority).

Die Autorität signiert blake3("rand-rpl-mint-1" | "rand-rpl-authority-1", chain_id ‖ asset_id ‖ nonce ‖ body). nonce muss dem mint_nonce des Tokens entsprechen, der danach erhöht wird; so lässt sich ein signierter Mint weder auf dieser Chain wiedereinspielen noch auf eine andere übertragen. Der body eines Mints enthält den Digest des Envelopes: Das Commitment allein deckt ihn nicht ab, und ohne den Digest könnte ein Dritter einen verbreiteten Mint mit einem Müll-Envelope neu verpacken und den Nonce verbrauchen.

Beide Aktionen laufen in einem RAND-Gebühren-Bundle mit, das BUNDLE_BASE zahlt. Das Wallet, das die Gebühr zahlt, und der Schlüssel, der den Mint autorisiert, sind getrennt und können verschiedenen Personen gehören.

Burning

Action::TokenBurn { asset, amount } läuft im selben einzelnen Bundle mit: Das burn_asset des Bundles muss asset entsprechen, burn_a muss amount entsprechen, und burn_r ist 0. Der Token verlässt den Pool über die Asset-Slots und die RAND-Gebühr über die Slots 2–3 desselben Beweises. total_supply sinkt um genau amount. Ein Token mit Bridge-Autorität wird hier abgewiesen (TokenError::BridgedToken); er verlässt das System über einen Bridge-Burn.

Gebühren

Jede RPL-Aktion zahlt in RAND.

Das Genesis von Chain 20 enthält einen gas-Abschnitt, der ausschließlich Programmaufrufe und Invokes bepreist. Diese Untergrenzen sind pauschal: Keine RPL-Aktion zahlt nach Gas oder nach Byte.

Was öffentlich ist und was verborgen bleibt

total_supply ist daher stets prüfbar: Es ist das, was die Registrierung und jeder Mint hinzugefügt haben, abzüglich jedes Burns. Eine Überweisung zwischen Haltern offenbart nichts, auch nicht, dass statt RAND ein Token den Besitzer gewechselt hat.

Die Offenlegung funktioniert wie bei RAND. Der Note-Klartext enthält das Asset, daher öffnet ein Schlüssel pro Transaktion (rand tx-key <hash>) oder ein Viewing Key eine Token-Note genauso wie eine RAND-Note, und rand_checkTransaction sowie rand_getViewingNotes geben asset in der Note zurück, die sie offenlegen. Mit einem solchen Schlüssel löst randscan den Index gegen das Register auf und zeigt die Überweisung als den benannten Token; die öffentliche Seite derselben Transaktion zeigt davon nichts.

Gebridgte Tokens

Ein Token mit Bridge-Autorität ist weiterhin ein RPL-Token: derselbe Registereintrag, dieselbe verborgene Überweisung, dieselbe Burn-Mechanik. Sein Angebot ändert sich nur durch eine Sperre auf einer Quell-Chain (BridgeAttest) oder eine Freigabe (BridgeBurn). Ein gebridgter Token kann viele Deckungen haben, jeweils ein Paar (chain, token) mit eigenen Quell-Dezimalstellen, eigenem gesperrtem Betrag und eigenem Mint-Limit; total_supply entspricht stets der Summe dessen, was seine Deckungen gesperrt halten. Ein gebridgter Token wird nur unter einem Quorum der Post-Quanten-Wächter der Bridge registriert, und eine Deckung wird nur unter einem solchen Quorum hinzugefügt.

Auf Chain 20 ist der erste Token des Registers zUSD („Shielded USD”), Index 1, 8 Dezimalstellen, im Genesis-File mit sieben Deckungen aufgeführt (USDT und USDC auf Ethereum, Binance Smart Chain und Solana sowie USDT auf Tron). Er behält die Asset-ID, die er auf Chain 14 hatte, wo er per Transaktion bei Höhe 256 registriert wurde: Die Chains 15 bis 20 führen ihn im Genesis jeweils unter demselben Namen, Symbol und Salt auf. Chain 20 startete mit 99 zUSD in zwei Genesis-Notes (10 und 89), gedeckt durch 22 USDT, gesperrt auf Ethereum, 22 auf Binance Smart Chain, 30 auf Tron und 25 auf Solana, übernommen aus dem Bridge-Zustand von Chain 19. Chain 19 startete mit 10 zUSD, gedeckt durch 10 USDT auf Solana; Chain 18 mit 9 auf Tron gesperrten USDT und 1 auf Solana. Sein Gesamtangebot entspricht dem, was seine Deckungen gesperrt halten, und ändert sich mit jeder Einzahlung und Einlösung. Seine ID lautet rpl1xtj6k2x8strx8c2d5fjs50ltztck5ykms4ve7nmzmstf6fhn0v0spelqtx. Bridge behandelt Deckungen, Freigabeeinheiten, Mint-Limits, die Pause und die Mitsignatur.

zUSD ist ein Korb, nicht sieben getrennte Forderungen. Seine Deckungen werden zum Nennwert gepoolt, sodass ein Halter das Risiko aller aufgeführten Deckungen trägt, nicht das der Münze, die er eingezahlt hat: Eine Deckung, die ihren Peg verloren hat, kann zu pari eingezahlt und zUSD gegen eine solide Deckung verbrannt werden, bis die soliden erschöpft sind. Den Verlust begrenzen das rollierende Mint-Fenster (auf Chain 20 4.000 zUSD über alle Deckungen pro 24 Stunden, neben 100.000 pro Deckung) und die tatsächlich gesperrte Verwahrung. Das Fenster begrenzt die Rate und verschafft Zeit, Mints zu pausieren. Es deckelt nicht die Gesamtsumme. Eine Deckung wird nur unter dem Post-Quanten-Wächter-Quorum aufgeführt und nicht, solange Mints pausiert sind.

Die Gebühren der Bridge in zUSD (Chain 20). Das Genesis von Chain 20 setzt bridge.fees: 10 bps auf eine Einzahlung und 10 bps auf einen Burn, jeweils abgerundet auf eine ganze Freigabeeinheit der Deckung (100 Basiseinheiten bei einem USDT mit 6 Dezimalstellen), gezahlt als zUSD-Note an eine Treasury-Adresse, die das Genesis benennt (v0.6.8, Fullnode docs/bridge.md §25). Eine Einzahlung von g hängt zwei Notes an: die des Einzahlers über g − fee und die der Treasury über fee; 1 USDT Einzahlung ergibt 0,999 zUSD für den Einzahler. Ein Burn von amount behält fee als Treasury-Note und gibt amount − fee auf der Quell-Chain frei; die Wächter signieren diesen Freigabebetrag, und rand_getBridgeBurn liefert amount, release_amount und fee. Eine Gebühren-Note ist ausgegeben und gedeckt, sodass total_supply weiterhin der Summe der locked-Werte der Deckungen entspricht: Eine Einzahlung verändert beide um g, ein Burn senkt beide um amount − fee. Eine Gebühren-Note trägt keinen Envelope. Jedes ihrer Felder ist öffentlich (der Betrag aus der Transaktion und dem Genesis-Satz, das Asset und time, ein Blinding, abgeleitet aus dem Attestierungs-Digest oder der Transaktions-ID des Burns, der Eigentümer aus dem Genesis), sodass das Wallet der Treasury sie aus öffentlichen Feldern rekonstruiert (Notes). BRIDGE_BURN_FEE, die 0,01 RAND, die ein Burn an den Proposer zahlt, bleibt unverändert. Die Chains 14 bis 19 hatten keine Bridge-Gebühr auf Rand.

Das Register seit Chain 15

Seit Chain 15 schaltet das Genesis drei Registerregeln ein, die Chain 14 nicht hatte, und das Genesis von Chain 20 setzt dieselben drei Werte. Jede ist im Genesis-Hash und in der Token-Root festgeschrieben.

Die Obergrenze für den Note-Wert besteht, weil der Bundle-Circuit jeden Betrag auf 63 Bit prüft: Eine Note im Wert von 2^63 oder mehr könnte zwar committet, aber nie ausgegeben werden und würde dennoch zum Supply des Tokens zählen. Jeder Node lehnt einen solchen Betrag außerdem bei der Zulassung auf jeder Chain ab, unabhängig vom Genesis.

RPC und CLI

Jeder Betrag in diesen Ergebnissen (total_supply, registration_fee, locked einer Deckung, mint_cap_per_day und minted_today) ist ein Dezimalstring, da eine JSON-Zahl jenseits von 2⁵³ nicht exakt ist. index, next_index, mint_day und max_tokens sind einfache Ganzzahlen (max_tokens ist auf einer Chain ohne Obergrenze null); burn_registration_fee und bound_note_value sind Booleans. Die authority einer Zeile lautet {"kind":"none"}, {"kind":"key","key","address"}, {"kind":"bridge","backings":[…]} oder {"kind":"program","program"}. Alle Details finden sich unter JSON-RPC.

Datenschutz. rand_getTokens kostet gleich viel, unabhängig davon, welches Token der Aufrufer im Sinn hat. rand_getToken und rand_getTokenSupply teilen dem Node mit, für welches Token sich der Aufrufer interessiert: für einen Explorer unbedenklich, für ein Wallet, das gleich sendet, falsch. Das Wallet löst daher jedes --asset aus der gesamten Liste auf, und ein numerischer Index erreicht den Node gar nicht erst.

Seit v0.5.10 werden die Beträge von rand send --asset, rand token mint und rand token burn in den Anzeigeeinheiten des Tokens angegeben, gelesen mit den decimals der eigenen Registerzeile: 1.5 eines Tokens mit 6 Dezimalstellen sind 1.500.000 seiner kleinsten Einheit, und mehr Nachkommastellen, als das Token hat, werden abgelehnt. Die Bestätigung von send gibt beides aus (1.500000 USDX (1500000 units)). --fixed-supply und --initial von rand token create verlangen weiterhin ganze kleinste Einheiten, ebenso rand bridge-burn, und rand asset-balance gibt kleinste Einheiten aus. On-chain ist der Betrag immer die Ganzzahl in der kleinsten Einheit. Flags und Standardwerte stehen unter Command line.

Unterschiede zu ERC-20 und SPL

Bekannte Grenzen

• Keine Allowances. approve und transferFrom sind in der RPL-Spezifikation als zweckgebundene Allowance-Konten entworfen und nicht umgesetzt.
• Die Bestände eines Programms sind öffentlich. Auf Chain 20 kann ein Programm Tokens in seinem Vault halten und sein eigenes Token ausgeben (RPL-2), doch ein Vault-Guthaben ist öffentlich, wie der Supply eines Tokens; nur Notes sind privat. Chains vor 20 hatten überhaupt keinen Programmzustand.
• Gebühren nur in RAND. Ein Token kann seine eigene Gebühr nicht bezahlen; ein Wallet, das nur Tokens hält, kann nichts bewegen.
• u64-Beträge und höchstens 9 Dezimalstellen. Eine Quellmünze mit 18 Dezimalstellen wird mit geringerer Genauigkeit dargestellt; die Bridge löst dies mit 8 Dezimalstellen und einer Auszahlungseinheit pro Deckung.
• Jeder Transfer wird bewiesen. Etwa 100 s und mehrere GB Arbeitsspeicher auf dem Rechner des Senders; für ein Token gibt es keinen günstigeren Weg als für RAND.
• Kein Freeze, keine Blacklist und keine Pause bei einem nativen Token, per Entscheidung. Die Mint-Pause der Bridge gilt nur für gebridgte Mints.
• Abfragen pro Token verraten Interesse. rand_getToken, rand_getTokenSupply und /tokens/:id des Explorers teilen dem Server mit, nach welchem Token gefragt wurde.