Tokeny RPL

Ta strona wyjaśnia, czym jest token w tym łańcuchu, zanim go utworzysz, wystawisz lub zindeksujesz. RPL to standard tokenów Rand, nowy w chain 14. Token jest osłoniętym aktywem natywnym: jednym wpisem w rejestrze księgi, a salda są przechowywane jako zwykłe notatki w tym samym drzewie zobowiązań, którego używa RAND. Nie jest kontraktem. Aby utworzyć token krok po kroku, zobacz Deploy an RPL token.

Powód jest strukturalny. Call zapisuje wyłącznie potwierdzenie, więc kontrakt w stylu ERC-20 nie miał gdzie przechowywać salda, a publiczna tabela sald uczyniłaby tokeny jedynym przejrzystym aktywem w łańcuchu osłoniętym. RPL czyni natomiast token pełnoprawnym obiektem księgi. Chain 20 dodaje RPL-2 (v0.6.8): program może utrzymywać publiczne komórki stanu i publiczny skarbiec oraz może być organem emisji własnego tokena (niżej); salda należące do osób nadal są notatkami.

Token jest wpisem w rejestrze

TokenRegistry (crates/randprotocol-core/src/ledger/tokens.rs) to jedna tabela współdzielona przez każdy token, natywny lub pomostowany. Jest to ten sam rejestr, przez który most rozwiązuje indeks aktywa. Każdy wpis:

Liczba miejsc dziesiętnych kończy się na 9, ponieważ kwoty są typu u64: przy 18 miejscach u64 mieści zaledwie 18,4 całego tokena, a 9 to własna precyzja RAND. Token pomostowany zawsze rejestruje się z 8 miejscami dziesiętnymi, niezależnie od tego, jakich użyto w monetach źródłowych.

Rejestr włącza sekcja tokens w pliku genesis, tak jak bridge i aggregation włączają swoje sekcje. Bez niej każda akcja tokenowa jest odrzucana przed jakąkolwiek inną kontrolą (TokenError::Disabled). Genesis chain 20 zawiera tę sekcję i wymienia jeden token, zUSD, z jego siedmioma zabezpieczeniami, przenoszony z chain 14 przez każde kolejne cięcie; każdy inny token w łańcuchu pojawia się przez transakcję. (Genesis chain 14 nie wymieniał żadnego.) Przy włączonej bramce tokens_root (korzeń merkle’a liści blake3("rand-token-leaf-1", bincode(TokenInfo)) w kolejności indeksów) wchodzi do korzenia stanu. Domeną tego korzenia jest rand-state-4 w łańcuchu, w którym nic późniejszego nie jest włączone; korzeń chain 20 obejmuje także stan faucetu i kolejki obligacji, aktualne ceny gazu oraz korzeń stanu programów, jest haszowany w domenie rand-state-8 i zostaje opakowany jeszcze raz przez zbiór dopuszczonych walidatorów (Consensus).

Łańcuch z sekcją tokens wymaga również, aby każda notatka alloc w genesis zawierała swoje otwarcie (pk, time, r), a węzeł przelicza zobowiązanie i odrzuca plik, który się nie zgadza. Zobowiązanie dotyczy aktywa 0, chyba że otwarcie wskazuje indeks tokena wymienionego w tym samym genesis (chain 20 ma dwie takie notatki, 10 i 89 zUSD przy indeksie 1), a dla każdego wymienionego tokena suma notatek genesis musi równać się temu, od czego zaczynają jego zabezpieczenia w stanie locked. Gdy słowo asset notatki może już wskazywać token, nieotwarte zobowiązanie genesis byłoby jedynym sposobem wprowadzenia do puli niezabezpieczonej notatki dowolnego aktywa bez kontroli.

Identyfikator aktywa, indeks i rpl1…

Token ma dwie nazwy, a RPC podaje obie.

• Identyfikator aktywa ma 32 bajty i jest adresowany zawartością, tak jak identyfikator programu. Identyfikator tokena natywnego to blake3("rand-rpl-asset", bincode(name, symbol, decimals, authority, initial, salt)), gdzie salt to 32 bajty wybrane przez twórcę, a initial to cała emisja początkowa, jeśli istnieje. Identyfikator tokena pomostowanego to blake3("rand-rpl-asset", bincode(name, symbol, 8, salt)). Rejestracja identyfikatora, który już istnieje, jest odrzucana (TokenError::AlreadyRegistered).
• Indeks to to, co notatka faktycznie niesie, ponieważ 32-bajtowy identyfikator nie mieści się w jednym słowie. Jest skrótem, który ma znaczenie wyłącznie w tym łańcuchu.
• Forma tekstowa rpl1… to bech32m (BIP-350) z częścią czytelną dla człowieka rpl nad 32 bajtami identyfikatora: 52 znaki danych i 6-znakowa suma kontrolna, razem 62 znaki. Jest pokazywana obok 64-znakowego identyfikatora szesnastkowego wszędzie, gdzie występuje nazwa tokena, i akceptowana wszędzie, gdzie token jest wyszukiwany; zapis szesnastkowy nadal jest akceptowany. Parsowanie jest ścisłe: błędna suma kontrolna, zły prefiks, ładunek o długości innej niż dokładnie 32 bajty lub mieszana wielkość liter są odrzucane, więc literówka nie może wskazać innego tokena.

Symbole nie są unikalne. Podobnie jak w ERC-20 i SPL, tożsamością tokena jest jego identyfikator aktywa, nigdy nazwa ani ticker.

Dawna wartość dla pary (chain, token), którą oblicza rand_bridgeAssetId i którą rand_getAssets wypisuje dla każdego wiersza zabezpieczenia, jest węższym identyfikatorem formatu przesyłania mostu, a nie własnym identyfikatorem tokena.

Organy emisji

RegisterToken wskazujący Bridge jest odrzucany (TokenError::AuthorityNotAllowed), podobnie jak wskazujący Program z emisją początkową lub w łańcuchu bez program_state. Organ Key to dokładnie jeden klucz publiczny Dilithium2: klucz o jakiejkolwiek innej długości w bajtach jest odrzucany (TokenError::BadAuthorityKey), a klucz ML-KEM odbiorcy w emisji jest w ten sam sposób ograniczony długością. Oba są stanem konsensusu lub miejscem w bloku kupowanym za stałą opłatę, więc żaden nie może być dowolnie duży.

Tworzenie tokena

Tworzenie jest bezuprawnieniowe. Action::RegisterToken { name, symbol, decimals, authority, initial, salt, index } jedzie na zwykłym pakiecie opłat w RAND i płaci BUNDLE_BASE plus registration_fee rejestru. Opłata rejestracyjna jest parametrem genesis ograniczonym między 1 RAND a 10 000 RAND, więc token-spam zawsze coś kosztuje. W chain 20 wynosi ona 1 RAND, zatem rejestracja kosztuje 1,001 RAND, a chain 20 ją spala, tak jak każdy łańcuch od 15: proposer zatrzymuje tylko bazę pakietu (niżej).

index wskazuje indeks rejestru, dla którego twórca zapieczętował notatkę początkową. Jeśli inna rejestracja zajęła ten indeks wcześniej, transakcja jest odrzucana (TokenError::IndexMismatch), zamiast porzucić notatkę; twórca generuje dowód ponownie dla następnego indeksu.

Wyemitowana notatka jest obliczana przez łańcuch, a nie wybierana przez nadawcę: note_commitment(recipient.pk, MINT_FROM, amount, index, time, r). Kwota i pk odbiorcy są jawne w transmisji, więc odbiorca może odbudować notatkę z pól samej transakcji, nawet jeśli zapieczętowana koperta jest uszkodzona. Depozyt mostu ma tę samą ochronę.

Dlaczego identyfikator wiąże całą emisję początkową

RegisterToken jest niepodpisany. Wiązanie transakcji zapobiega zmianie udowodnionej kopii, ale nie mówi nic o tym, co może wskazywać nowa kopia. Gdyby identyfikator obejmował tylko kwotę początkową, obserwator oczekującej rejestracji mógłby wysłać kopię z innym odbiorcą, zarejestrować ją pod tym samym identyfikatorem i przejąć całą podaż tokena o stałej podaży, zatwierdzając ją jako pierwszy. Ponieważ identyfikator obejmuje całą emisję początkową (kwotę, odbiorcę, r, time i kopertę), przekierowana kopia daje skrót w postaci innego identyfikatora aktywa: innego tokena z tym samym symbolem, na co niejednoznaczny symbol już pozwala. Oryginał nadal trafia pod następny indeks kosztem jednego ponownego dowodu.

Transfery to ten sam pakiet co RAND

Od chain 14 każda transakcja przenosząca wartość niesie dokładnie jeden pakiet, o stałym kształcie 4 wejścia–4 wyjścia z ukrytym aktywem (Transactions and actions). Sloty 0–1 niosą aktywo prywatne, RAND lub dowolny token RPL, a obwód nigdy nie dowiaduje się którego. Sloty 2–3 zawsze niosą RAND. Transfer dowolnego aktywa to Action::None, akcja, której używa zwykła płatność w RAND. Nie ma akcji transferu tokena ani publicznego pola wskazującego token.

Obserwator transferu tokena widzi dokładnie to, co publikuje płatność w RAND: kotwicę, cztery nullifiery, cztery zobowiązania, opłatę RAND fee, burn_a = burn_r = burn_asset = 0, time, cztery szyfrogramy kopert i dowód pakietu. Od łańcucha 17 (podzielona autoryzacja) każdy pakiet niesie też auth_commit oraz drugi, mniejszy dowód autoryzacji, znów taki sam dla każdego aktywa. W łańcuchu 20 każda koperta ma dokładnie 1 860 bajtów i mieści zaszyfrowane memo (rand send --memo), niezależnie od tego, czy je wysłano. Obserwator nie widzi nadawcy, odbiorcy, kwoty, tego, które aktywo zmieniło właściciela, które sloty były atrapami ani reszty.

Portfel wydaje do dwóch notatek tokena w slotach 0–1 i do dwóch notatek RAND w slotach 2–3 na opłatę. Opłata jest zawsze w RAND, więc posiadacz tokena bez RAND zostaje odrzucony przed wygenerowaniem dowodu. Koszt jest taki sam jak płatności w RAND (Opłaty). W łańcuchu 20 są to dwa dowody STARK tworzone na maszynie nadawcy: autoryzacja wydatku (poziom 10, ok. 7 s, ok. 1,37 MB) i pakiet (poziom 14, ok. 100 s, ok. 1,5 MB), razem ok. 2,85 MB w transmisji. Każdy mieści się w limicie łańcucha 4 MiB na jeden dowód. Przed łańcuchem 17 transfer niósł sam dowód pakietu, ok. 1,42 MB według ówczesnego pomiaru.

Emisja i organ uprawniony

TokenMint { asset, amount, recipient, r, time, envelope, nonce, signature } emituje kolejne jednostki tokena z autoryzacją Key. SetAuthority { asset, new, nonce, signature } przekazuje uprawnienie innemu kluczowi albo się go zrzeka, gdy brak new; po zrzeczeniu się żaden klucz nigdy już nie wyemituje tego tokena. Każda z tych akcji na tokenie, którego organem uprawnionym nie jest Key, zostaje odrzucona (TokenError::NotKeyAuthority).

Organ uprawniony podpisuje blake3("rand-rpl-mint-1" | "rand-rpl-authority-1", chain_id ‖ asset_id ‖ nonce ‖ body). nonce musi być równy mint_nonce tokena, który następnie rośnie o jeden, więc podpisanej emisji nie można odtworzyć w tym łańcuchu ani przenieść do innego. body emisji zawiera skrót koperty: samo zobowiązanie jej nie obejmuje, a bez tego skrótu osoba trzecia mogłaby opakować rozgłoszoną emisję w śmieciową kopertę i zużyć nonce.

Obie akcje jadą w pakiecie z opłatą w RAND, płacącym BUNDLE_BASE. Portfel płacący opłatę i klucz autoryzujący emisję są rozdzielne i mogą należeć do różnych osób.

Spalanie

Action::TokenBurn { asset, amount } jedzie w tym samym pojedynczym pakiecie: burn_asset pakietu musi być równe asset, burn_a musi być równe amount, a burn_r wynosi 0. Token opuszcza pulę przez sloty aktywa, a opłata w RAND przez sloty 2–3 tego samego dowodu. total_supply spada dokładnie o amount. Token z organem Bridge jest tu odrzucany (TokenError::BridgedToken); opuszcza łańcuch przez spalenie w moście.

Opłaty

Każda akcja RPL jest opłacana w RAND.

Genesis łańcucha 20 ma sekcję gas, która wycenia wyłącznie wywołania programów i invoke. Te progi są stałe: żadna akcja RPL nie płaci za gaz ani za bajty.

Co jest jawne, a co ukryte

total_supply zawsze więc podlega audytowi: to suma tego, co dodała rejestracja i każda emisja, pomniejszona o każde spalenie. Transfer między posiadaczami niczego nie ujawnia, także tego, że właściciela zmienił token, a nie RAND.

Ujawnianie działa tak jak dla RAND. Tekst jawny notatki zawiera aktywo, więc klucz dla pojedynczej transakcji (rand tx-key <hash>) lub klucz podglądu otwiera notatkę tokena dokładnie tak, jak notatkę RAND, a rand_checkTransaction i rand_getViewingNotes zwracają asset w ujawnianej notatce. Mając taki klucz, randscan rozwiązuje indeks względem rejestru i pokazuje transfer jako token o danej nazwie; publiczna strona tej samej transakcji nie pokazuje z tego nic.

Tokeny mostowane

Token z organem Bridge nadal jest tokenem RPL: ten sam wpis w rejestrze, ten sam ukryty transfer, ta sama mechanika spalania. Jego podaż zmienia się wyłącznie przez blokadę w łańcuchu źródłowym (BridgeAttest) lub wypłatę (BridgeBurn). Jeden token mostowany może mieć wiele pokryć, każde jako para (chain, token) z własną liczbą miejsc dziesiętnych w źródle, zablokowaną kwotą i limitem emisji, a total_supply zawsze równa się sumie tego, co zablokowały jego pokrycia. Token mostowany jest rejestrowany, a pokrycie dodawane, wyłącznie za zgodą kworum postkwantowych strażników mostu.

W łańcuchu 20 pierwszym tokenem rejestru jest zUSD („Shielded USD”), indeks 1, 8 miejsc dziesiętnych, wpisany w pliku genesis z siedmioma pokryciami (USDT i USDC na Ethereum, Binance Smart Chain i Solana oraz USDT na Tron). Zachowuje identyfikator aktywa, który miał w łańcuchu 14, gdzie został zarejestrowany transakcją na wysokości 256: łańcuchy od 15 do 20 wpisują go w genesis pod tą samą nazwą, symbolem i solą. Łańcuch 20 wystartował z 99 zUSD w dwóch notatkach genesis (10 i 89), pokrytych 22 USDT zablokowanymi na Ethereum, 22 na Binance Smart Chain, 30 na Tron i 25 na Solana, przeniesionymi ze stanu mostu łańcucha 19. Łańcuch 19 wystartował z 10 zUSD, pokrytymi 10 USDT na Solana; łańcuch 18 z 9 USDT zablokowanymi na Tron i 1 na Solana. Jego całkowita podaż równa się temu, co zablokowały jego pokrycia, i zmienia się przy każdym depozycie i wykupie. Jego identyfikator to rpl1xtj6k2x8strx8c2d5fjs50ltztck5ykms4ve7nmzmstf6fhn0v0spelqtx. Most opisuje pokrycia, jednostki wypłaty, limity emisji, pauzę i współpodpis.

zUSD to koszyk, a nie siedem osobnych roszczeń. Jego pokrycia są łączone po wartości nominalnej, więc posiadacz ponosi ryzyko każdego wymienionego pokrycia, a nie monety, którą wpłacił: pokrycie, które utraciło powiązanie z kursem, można wpłacić po parytecie i spalić zUSD na rzecz pokrycia zdrowego, aż zdrowe się wyczerpią. Stratę ogranicza kroczące okno emisji (w łańcuchu 20 4 000 zUSD łącznie na wszystkie pokrycia na 24 godziny, obok 100 000 na pokrycie) oraz faktycznie zablokowana custodia. Okno ogranicza tempo i daje czas na wstrzymanie emisji. Nie ogranicza sumy. Pokrycie jest wpisywane wyłącznie za zgodą kworum postkwantowych strażników i nie wtedy, gdy emisje są wstrzymane.

Opłaty mostu w zUSD (łańcuch 20). Genesis łańcucha 20 ustawia bridge.fees: 10 bps od depozytu i 10 bps od spalenia, każde zaokrąglone w dół do pełnej jednostki wypłaty pokrycia (100 jednostek bazowych dla USDT z 6 miejscami dziesiętnymi), płatne jako notatka zUSD na adres skarbca wskazany w genesis (v0.6.8, fullnode docs/bridge.md §25). Depozyt g dopisuje dwie notatki: g − fee deponenta i fee skarbca; 1 USDT wpłacony to 0,999 zUSD dla deponenta. Spalenie amount zostawia fee jako notatkę skarbca i wypłaca amount − fee w łańcuchu źródłowym; strażnicy podpisują tę kwotę wypłaty, a rand_getBridgeBurn zwraca amount, release_amount i fee. Notatka opłaty jest wyemitowana i pokryta, więc total_supply nadal równa się sumie locked pokryć: depozyt zmienia obie wartości o g, spalenie obniża obie o amount − fee. Notatka opłaty nie niesie koperty. Każde jej słowo jest jawne (kwota z transakcji i stawki z genesis, aktywo i time, czynnik zaślepiający wyprowadzony ze skrótu poświadczenia albo z identyfikatora transakcji spalenia, właściciel z genesis), więc portfel skarbca odtwarza ją z pól jawnych (Notatki). BRIDGE_BURN_FEE, czyli 0,01 RAND, które spalenie płaci proposerowi, pozostaje bez zmian. Łańcuchy od 14 do 19 nie miały na Rand opłaty mostu.

Rejestr od łańcucha 15

Od łańcucha 15 genesis włącza trzy reguły rejestru, których nie miał łańcuch 14, a genesis łańcucha 20 ustawia te same trzy wartości. Każda jest zapisana w skrócie genesis i w korzeniu tokenów.

Ograniczenie wartości notatki istnieje, ponieważ obwód pakietu (bundle) sprawdza zakres każdej kwoty do 63 bitów: notatkę wartą 2^63 lub więcej dałoby się zatwierdzić, ale nigdy wydać, a mimo to liczyłaby się do podaży tokenu. Każdy węzeł odrzuca też taką kwotę już przy przyjęciu, w każdym łańcuchu, niezależnie od tego, co mówi jego genesis.

RPC i CLI

Każda kwota w tych wynikach (total_supply, registration_fee, locked, mint_cap_per_day i minted_today zabezpieczenia) jest ciągiem dziesiętnym, ponieważ liczba JSON nie jest dokładna powyżej 2⁵³. index, next_index, mint_day i max_tokens są zwykłymi liczbami całkowitymi (max_tokens to null w łańcuchu bez limitu); burn_registration_fee i bound_note_value są wartościami logicznymi. Pole authority wiersza ma postać {"kind":"none"}, {"kind":"key","key","address"}, {"kind":"bridge","backings":[…]} lub {"kind":"program","program"}. Pełny opis znajduje się w JSON-RPC.

Prywatność. rand_getTokens kosztuje tyle samo, niezależnie od tego, o jaki token pyta wywołujący. rand_getToken i rand_getTokenSupply zdradzają węzłowi, który token interesuje wywołującego: w eksploratorze to bez znaczenia, w portfelu tuż przed wysłaniem — niedopuszczalne. Dlatego portfel rozwiązuje każde --asset na podstawie całej listy, a numeryczny indeks w ogóle nie trafia do węzła.

Od v0.5.10 kwoty w rand send --asset, rand token mint i rand token burn podaje się w jednostkach wyświetlanych tokenu, odczytywanych według decimals jego własnego wiersza w rejestrze: 1.5 tokenu o 6 miejscach dziesiętnych to 1 500 000 jego najmniejszej jednostki, a więcej cyfr ułamkowych, niż ma token, jest odrzucane. Potwierdzenie send wypisuje obie wartości (1.500000 USDX (1500000 units)). --fixed-supply i --initial w rand token create nadal przyjmują całe najmniejsze jednostki, tak samo jak rand bridge-burn, a rand asset-balance wypisuje najmniejsze jednostki. W łańcuchu kwotą jest zawsze liczba całkowita w najmniejszych jednostkach. Flagi i wartości domyślne opisano w Wiersz poleceń.

Różnice względem ERC-20 i SPL

Znane ograniczenia

• Brak allowances. approve i transferFrom są zaprojektowane w specyfikacji RPL jako zarezerwowane konta zgód i nie zostały zbudowane.
• Zasoby programu są publiczne. W łańcuchu 20 program może przechowywać tokeny w swoim skarbcu i emitować własny token (RPL-2), ale saldo skarbca jest publiczne, podobnie jak podaż tokenu; prywatne są tylko notatki. Łańcuchy przed 20 nie miały żadnego stanu programu.
• Opłaty tylko w RAND. Token nie może zapłacić własnej opłaty; portfel zawierający wyłącznie tokeny nie może wykonać transferu.
• Kwoty u64 i co najwyżej 9 miejsc dziesiętnych. Moneta źródłowa z 18 miejscami dziesiętnymi jest reprezentowana z niższą precyzją; most rozlicza to z 8 miejscami dziesiętnymi i jednostką wypłaty na zabezpieczenie.
• Każdy transfer jest dowodzony. Około 100 s i kilka GB pamięci na maszynie nadawcy; dla tokenu nie ma tańszej ścieżki niż dla RAND.
• Brak zamrożenia, czarnej listy i pauzy w tokenie natywnym, z decyzji projektowej. Pauza emisji mostu dotyczy wyłącznie emisji tokenów z mostu.
• Wyszukiwania per token zdradzają zainteresowanie. rand_getToken, rand_getTokenSupply i /tokens/:id w eksploratorze zdradzają serwerowi, o który token pytano.