Ta strona pomoże Ci zdecydować, na czym budować i od czego zacząć: model łańcucha w kilku akapitach, parametry działającego testnet, sposób zdobycia testowych RAND oraz mapa pozostałej części dokumentacji.
Czym jest Rand Protocol
Rand to post-kwantowy łańcuch osłonięty. Jego natywna moneta to RAND, a RAND żyje w w pełni osłoniętej puli: w łańcuchu nie ma kont ani sald, są tylko zobowiązania do notatek i nullifiery, a transfer jest dowodem z wiedzą zerową, że cztery notatki zamieniły się w cztery inne (puste notatki wypełniają niewykorzystane sloty), bez ujawniania, który zasób został przesłany. RAND i każdy token zgodny z własnym standardem łańcucha, RPL, dzielą tę jedną pulę. Ta sama moneta opłaca programy poufne: programy RISC-V, które działają poza łańcuchem wewnątrz maszyny wirtualnej z dowodem z wiedzą zerową i są rozliczane w łańcuchu za pomocą dowodu zamiast swoich danych wejściowych.
Każdy prymityw dobrano tak, by wytrzymał przeciwnika kwantowego:
| warstwa | co działa |
|---|---|
| Podpisy | Dilithium2 (oparty na kratach). Podpisują nim bloki i głosy walidatorzy; podpisane są nim także faucet, akcje stakingu i rejestracje mostu. Portfel nigdy nie podpisuje transakcji: pakiet autoryzuje się własnym dowodem. |
| Szyfrowanie notatek | Enkapsulacja klucza ML-KEM-768 oraz ChaCha20-Poly1305. Każdej notatce w łańcuchu towarzyszy koperta, którą może otworzyć tylko jej właściciel (i nadawca). |
| Haszowanie | BLAKE3 z separacją domen dla adresów, identyfikatorów transakcji, korzenia stanu i wszystkiego innego poza systemem dowodowym; Poseidon2 nad ciałem Goldilocks dla notatek, nullifierów, drzewa zobowiązań i wszystkiego wewnątrz dowodu. |
| Dowody | Wsadowy STARK Plonky3 z ukrywającym FRI (80 zapytań, blowup 8, 20 bitów proof-of-work). Przejrzysty: bez zaufanej konfiguracji i bez krzywej z parowaniem, a założeniem jest odporna na kolizje funkcja skrótu. |
| Obliczenia poufne | zkVM Rand, maszyna RV32IM z dowodem w tym STARK. Program identyfikuje skrót obliczany w obwodzie, a weryfikator nie widzi ani jednego słowa instrukcji. |
| Konsensus | Łańcuchowy HotStuff BFT: kworum ważone stawką, większe niż dwie trzecie, liderzy rotujący w kolejności round-robin, reguła zatwierdzenia po trzech kolejnych widokach. |
| Przechowywanie i sieć | Jedna baza RocksDB na węzeł z zatwierdzeniami zapisywanymi przez fsync i kontrolą integralności przy starcie; libp2p (TCP, Noise, Yamux, gossipsub, Kademlia, mDNS w sieciach LAN). |
Implementacją referencyjną jest randprotocol/fullnode, napisana w Rust: binarka rand-node to węzeł, binarka rand to portfel, a metody JSON-RPC mają prefiks rand_. Eksplorator to randscan.org.
Testnet: chain 20
Publiczna flota działa na chain 20, od 2026-10-01 06:17 UTC, na fullnode v0.6.8. Łańcuchy od 15 do 19 zostały wycofane. W cztery dni wycięto cztery łańcuchy, każdy z powodu zmiany, która zmienia każdy dowód lub format transakcji:
- Chain 16 (2026-09-28, fullnode v0.6.1) przeniósł zkVM na zestaw ograniczeń 7, który zaciemnia to, co dowód dotąd ujawniał o małych prywatnych danych wejściowych, i włączył reguły
hardening_v6. - Chain 17 (2026-09-29, v0.6.3) oddzielił autoryzację transferu od jego dowodu: każdy pakiet niesie drugi, mały dowód wykonany kluczem wydawania, dzięki czemu duży dowód może wytworzyć maszyna, która posiada wyłącznie klucz podglądu.
- Chain 18 (2026-09-29, v0.6.7) mierzy wywołania poufne w gazie (zestaw ograniczeń 8) i włącza zaszyfrowane memo w każdej kopercie notatki.
- Chain 20 (2026-10-01, v0.6.8) wiąże każdy dowód i każdą podpisaną wiadomość z hashem genesis, dodaje stan programów (RPL-2), pobiera opłatę od mintów i burnów zUSD przez most oraz włącza reguły audit-v6 wymienione w tabeli poniżej.
Chain 19 (2026-10-01 03:43 UTC, v0.6.7) był ponownym genesis chain 18 na tym samym buildzie i nie zmienił żadnej reguły. Chain 18 zatrzymano na wysokości 143 776, a chain 19 wycięto ze snapshotu na wysokości 141 935. Jego genesis różnił się od genesis chain 18 tylko identyfikatorem łańcucha, znacznikiem czasu, przeniesionymi notatkami i sekcją mostu: nowymi emiterami dla punktów końcowych Ethereum, Binance Smart Chain i Tron oraz przeniesionymi licznikami sekwencji.
Chain 20 jest hard forkiem chain 19: jego genesis wycięto ze snapshotu chain 19 na wysokości 7 258, chain 19 zatrzymano na wysokości 7 700, a wszystkich 26 walidatorów uruchomiono ponownie razem na chain 20, z tymi samymi kluczami, identyfikatorami peerów i węzłami startowymi. Chain 19 i chain 18 są wycofane. Aby wysyłać na chain 20, portfel potrzebuje v0.6.8: dowody i podpisy starszego portfela nie zawierają powiązania z genesis, a łańcuch je odrzuca.
Każdy z nich to nowy łańcuch. Do następnego genesis przeniesiono saldo RAND w portfelach operatora i zUSD w obiegu, a nic poza tym: program wdrożony w jednym łańcuchu nie istnieje w następnym. To oprogramowanie eksperymentalne: niezaudytowane, a RAND w nim nie ma żadnej wartości.
Programy na chain 20 mogą przechowywać stan: komórki programów RPL-2, skarbce programów i akcja Invoke są aktywne.
| identyfikator łańcucha | 20 (rand_chainId) |
| hash genesis | 6210cf071a390d7ac61d8cbea5dd9d139d1a493a862b54a45a498f36af2d5135 |
| plik genesis | deploy/genesis-chain20.json w repozytorium fullnode |
| build | fullnode v0.6.8 (tag c9c9bd3c); węzeł zgłasza własny build w rand_getVersion. Ten build odrzuca łańcuchy od 14 do 17, a portfel starszy niż v0.6.8 nie może wysyłać na łańcuchu 20 |
| powiązanie z genesis | binding_domain 1: powiązanie dowodu każdego pakietu i każdy podpisany komunikat akcji zawierają hash genesis, więc nic, co zostało udowodnione lub podpisane dla jednego łańcucha, nie przejdzie weryfikacji na innym |
| znacznik testnet | testnet true: genesis deklaruje się jako sieć testowa, co pozwala uruchomić kranik obok mostu |
| walidatorzy | 26, każdy ze stawką 1 000 RAND, czyli minimum stakingu |
| kworum | 18 z 26: ściśle więcej niż dwie trzecie stawki |
| interwał bloków | domyślne --block-interval-ms 1000; około jednego bloku na sekundę |
| czas bloku | znacznik czasu późniejszy o ponad 60 s od znacznika bloku nadrzędnego jest nieprawidłowy, a walidator nie głosuje na blok wyprzedzający jego własny zegar o ponad 15 s, więc walidatory korzystają z NTP |
| okno dowodu | proof_window_blocks 1 024: kotwica pakietu musi być jednym z ostatnich 1 024 korzeni końca bloku, a jego time nie może być starszy (256 bloków na łańcuchach 18 i 19) |
| epoki | 1 000 bloków; nowe wiązanie czeka dwie dodatkowe epoki, zanim zacznie się liczyć (bond_activation_epochs 2, aktywacja w epoce e + 3), a stawka po wypowiedzeniu wiązania jest zwalniana po dwóch kolejnych epokach |
| staking | rejestracje są w wersji v2 (rand-node register --v2), a nowy klucz rejestruje się dopiero wtedy, gdy walidatorzy posiadający ponad dwie trzecie wagi zagłosują za jego przyjęciem (admission_by_vote); waga jednego walidatora jest ograniczona do 33,33 %; nowa stawka wchodząca na granicy epoki jest ograniczona do 25 % wagi aktywnej (max_stake_entry_bps_per_epoch 2 500); brak slashingu |
| zkVM | zestaw ograniczeń 8, produkcyjny profil FRI (80 zapytań) |
| guest pakietu | hc_bundle 60af094acfe65d85fdb18fb3d06cf9085dcf28c96e59e87f1ee527226e6e3fce: pakiet ukrytych aktywów 4 wejścia–4 wyjścia, wersja 3, poziom 14 |
| guest autoryzacji | hc_auth 1e4e347f44cf86750b30a9a4bdf9ec9256efe353d4ff8017451eca7d195639c1: autoryzacja wydatku, którą niesie każdy pakiet, poziom 10 |
| gas | wywołanie deklaruje limit gazu egzekwowany przez układ i płaci za niego gas_price: 100 jednostek za gaz i 800 jednostek za KiB przy dolnej granicy, obie wartości zmieniają się w każdym bloku w kierunku celu 262 144 gazu i 10 485 760 bajtów i nigdy nie przekraczają pułapów 10 000 za gaz i 80 000 za KiB. Do obciążenia bajtowego liczą się tylko bajty, od których pobierana jest cena bajtu (dowód wywołania i jego koperta wejściowa) (byte_load: "paying"), więc blok transferów go nie podnosi. Każdy pakiet deklaruje przypięty limit 20 479 i płaci stałe 0,001 RAND |
| stan programu | RPL-2 włączony: komórki programu, skarbce programu i Invoke (Action 33); utworzona komórka kosztuje 0,01 RAND (cell_fee 10 000 000 jednostek); wywołanie odczytuje najwyżej 8 komórek, zapisuje najwyżej 8 i wykonuje najwyżej 4 wypłaty (rand_getLimits.program_state) |
| koperta noty | envelope_bytes 1860: koperta każdej noty ma 1 860 bajtów i niesie zaszyfrowane memo |
| limit programu | max_program_words 65 535, ale przy hardening_v6 wdrożenie, którego nie pomieściłoby żadne wywołanie poziomu 14, jest odrzucane (ProgramUncallable): 8 180 słów dla programu bez segmentu publicznego |
| limit dowodu | max_proof_bytes 4 194 304 (4 MiB); na łańcuchach od 13 do 16 było to 8 MiB |
| limit bloku | max_block_bytes 20 971 520 (20 MiB) |
| limit koperty wywołania | max_call_envelope_bytes 65 536 |
| dane publiczne na program | max_program_public_words 32 768, ustalane przy wdrożeniu |
| kranik | włączony, ale tylko dla 16 portfeli z listy dozwolonych w genesis (staking.faucet_recipients) i tylko od 18 walidatorów wskazanych w genesis jako emitenci (staking.faucet_minters): do 100 RAND na wywołanie, łącznie 10 000 RAND na epokę |
| obliczenia poufne | włączone; dowód wywołania jest ograniczony do poziomu 14. Programy nie przechodzą przez zmianę łańcucha; przykładowe programy podają, na którym łańcuchu każdy z nich jest wdrożony |
| tokeny | rejestr RPL włączony: opłata rejestracyjna 1 RAND, spalana; co najwyżej 4 096 tokenów; wartość każdej noty poniżej 2⁶³. zUSD jest wpisany w genesis pod indeksem 1 |
| most | włączony: zestaw strażników 1 z ośmioma strażnikami, ośmioma strażnikami PQ Dilithium2, kluczem wstrzymania, emiterami dla czterech łańcuchów źródłowych, dziennym limitem emisji 100 000 zUSD na zabezpieczenie i globalnym limitem 4 000 zUSD na kroczące 24 godziny dla wszystkich zabezpieczeń. zUSD ma siedem zabezpieczeń; jego podaż to tyle, ile jest zablokowane, odczytywane na żywo z rand_getTokenSupply. Od łańcucha 20 od każdej emisji i każdego spalenia pobierana jest opłata 10 bps, w zUSD, jako nota na adres skarbca (bridge.fees): wpłata uznaje kwotę brutto pomniejszoną o opłatę, a spalenie zwalnia amount − fee w łańcuchu źródłowym. Rotacja strażników PQ lub klucza wstrzymania niesie własny podpis każdego nowego klucza i wchodzi w życie 86 400 s po przyjęciu (bridge.rotation) |
| historia | 24 walidatory przechowują 24 godziny bloków (--prune-history 24h) i odpowiadają -32010 dla starszych; dwa węzły archiwalne przechowują każdy blok, a publiczny RPC https://rpc.randprotocol.org przekazuje zapytania do węzła archiwalnego |
| agregacja bloków | wyłączona (brak sekcji aggregation w genesis; build odmawia uruchomienia na genesis, który ją zawiera) |
| wartość genesis | 26 000 RAND w stakingu w rejestrze walidatorów oraz siedem not wpłat o łącznej wartości 5 184,243719258 RAND, przeniesionych z portfeli operatora na łańcuchu 19: 31 184,243719258 RAND, przed emisjami z kranika (rand_getSupply zwraca genesis_staked i genesis_deposited); plus dwie noty genesis o łącznej wartości 99 zUSD, odpowiadające 99 zUSD zablokowanym na ich zabezpieczeniach |
Węzły startowe (deploy/nodes.env):
/ip4/164.90.239.200/tcp/30303/p2p/12D3KooWEQEbUwZRgqhDPXhW7vNBmcRcnhUDGUADe81VFdv3ALYe
/ip4/165.245.173.74/tcp/30303/p2p/12D3KooWJyc5oDHggAr89e9QrRFBy9Tg8TxXh18yzrb1SM6KKLYw
/ip4/188.166.235.187/tcp/30303/p2p/12D3KooWSyX84P1DAbWByLHpRBMLRWD53r3Jj4aqVt6tHoF8B2ZQŁańcuch 20 działa na kluczach walidatorów, których używały łańcuchy od 14 do 19, więc te identyfikatory peerów nie zmieniły się od rotacji kluczy w łańcuchu 14.
Eksplorator randscan.org indeksuje łańcuch 20 i udostępnia API REST pod adresem https://randscan.org/api/v1 (API eksploratora). JSON-RPC pełnego węzła domyślnie nasłuchuje na 127.0.0.1:8545; uruchom węzeł (Uruchamianie węzła), użyj takiego, któremu ufasz, albo skorzystaj z publicznego punktu końcowego https://rpc.randprotocol.org (rand --rpc https://rpc.randprotocol.org …). Publiczny punkt końcowy obsługuje wszystko, czego potrzebuje portfel, w tym pierwszą synchronizację i wysyłanie transakcji, w ramach limitu 1 200 odczytów i 6 wysłań na minutę na adres. Nie obsługuje kranika.
Pobieranie RAND z kranika
Kranik jest typem transakcji: walidator emituje jedną notę o jawnej kwocie na osłonięty adres, a nota może zostać otwarta tylko przez posiadacza adresu. Na łańcuchu 20 wypłaca on tylko na 16 adresów z listy dozwolonych w genesis: emisja na jakikolwiek inny adres jest odrzucana z komunikatem the faucet may not mint to this recipient (not in staking.faucet_recipients), więc portfel spoza listy otrzymuje testowe RAND, gdy ktoś mu je wyśle. Każda z trzech poniższych ścieżek prosi o emisję węzeł walidatora; obserwatorzy odpowiadają faucet mints are signed by validators; ask a validator node, a publiczny punkt końcowy RPC w ogóle nie przekazuje rand_mint.
Za pomocą portfela rand, skierowanego na RPC walidatora:
rand keygen # writes wallet.key.json; refuses to overwrite
rand address # the rand1… address on stdout (about 1,665 characters), its fingerprint on stderr
rand faucet # an allowlisted wallet: 100 RAND into a note only it can open
rand balance # scans the tree with this key; prints 100 RANDrand faucet [ADDRESS] --amount <RAND> emituje na inny adres lub mniejszą kwotę; 100 RAND to zarówno wartość domyślna, jak i limit na wywołanie. Przez JSON-RPC to samo żądanie to rand_mint:
curl -s http://127.0.0.1:8545 -H 'content-type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"rand_mint","params":["rand1…", "100000000000"]}'Wynikiem jest hash transakcji emisji; odpytuj rand_getTransaction, aż zwróci blok. Kwoty są ciągami jednostek, a 1 RAND to 10⁹ jednostek. Aplikacje portfela mają ten sam kranik jako jedno dotknięcie; wysyłaj z nich za pomocą Rand Wallet v0.6.8 lub nowszego, pierwszego wydania dla łańcucha 20. Strona kranika w tej witrynie przyjmuje zgłoszenia na listę oczekujących na granty w sieci deweloperskiej.
Kwota emisji jest jawna w łańcuchu: to widoczność jednego przeskoku, jaką ma każda wpłata z jawnej do osłoniętej puli. To, ile nota jest warta i dla kogo, pozostaje później ukryte, tak jak w przypadku każdej innej noty.
Co dalej
- Konta i adresy: dwa rodzaje kluczy, czym jest adres
rand1…i dlaczego 54-znakowy adres z chain 11 został wycofany. - Noty i drzewo zobowiązań, Transakcje i akcje, Opłaty, Konsensus i finalność, Podaż: model.
- Kryptografia i Dowody: prymitywy, parametry STARK, sposób, w jaki pakiet jest dowodzony i weryfikowany.
- Tokeny i Wdrożenie tokena RPL: standard RPL, token jako wpis w rejestrze z identyfikatorem
rpl1…oraz tworzenie go z poziomu portfela. - Programy: wdrażanie i wywoływanie poufnego programu oraz to, co nie jest jeszcze możliwe.
- Bridge, Mint i burn, Staking, Uruchomienie węzła.
- Napisz program w Rust lub C: kompletny przewodnik, od zaprojektowania wejść i wyjść programu po aukcję z zapieczętowanymi ofertami napisaną w obu językach, budżet dowodzenia, wdrożenie i sprawdzenie wywołania.
- Cztery przykładowe programy: kompletne aplikacje, każda uruchomiona w testnet: anonimowe głosowanie na liście dozwolonych opartej na Keccak, dowód zobowiązań na drzewie sum SHA-256, rejestr off-chain, którego stan jest przenoszony między wywołaniami, oraz decyzja kredytowa z zachowaniem prywatności na podstawie opublikowanego modelu.
- Architektura zbioru instrukcji RISC-V, Wdrożenie programu w Rust, Wdrożenie programu RISC-V: budowanie i wdrażanie własnych programów za pomocą zestawu narzędzi
rand-guest. - Transpiler Solana i Transpiler Ethereum: SPL Token i ERC-20, przetłumaczone na RISC-V i zgodne słowo w słowo z interpreterami.
- Uruchomienie walidatora i agregatora: RAM, CPU i dysk dla każdej roli oraz zmierzone granice pamięci dowodzenia.
- Dla deweloperów: repozytoria, stos technologiczny, kamienie milowe zkVM, co jest określone, ale jeszcze nie wydane, oraz jak budować, testować i wnosić wkład.
- JSON-RPC, Wiersz poleceń, API eksploratora: materiały referencyjne.
Katalog docs/ repozytorium fullnode jest źródłem, względem którego te strony są sprawdzane, a artykuły zawierają tło kryptograficzne.