Uruchom węzeł Rand
Referencyjny pełny węzeł i jego portfel są napisane w Rust i budują się ze źródeł. Powstają dwa pliki binarne: rand-node, czyli węzeł i narzędzia operatora, oraz rand, portfel, który przechowuje shielded klucz wydatkowania, komunikuje się z dowolnym węzłem przez JSON-RPC i lokalnie uruchamia prover zkVM dla każdego transferu i każdego poufnego wywołania. Eksperymentalny testnet, chain 21, działa na 26 walidatorach na dropletach DigitalOcean. Nie został poddany audytowi i nie ma realnej wartości. Pliki binarne obu programów dla Linux x86_64 są dołączone do wydania v0.8.0, czyli kompilacji, na którą przeniesiono flotę.
# 1. Rust (rustup pobiera przypiętą wersję 1.98.1) oraz zależności budowania RocksDB
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
sudo apt install build-essential clang cmake pkg-config libssl-dev # Linux
# 2. Sklonuj i zbuduj (za pierwszym razem 10–20 min)
git clone https://github.com/randprotocol/fullnode.git
cd fullnode
cargo build --release # target/release/rand-node, target/release/rand
# 3. Łańcuch dwóch walidatorów na tej maszynie (RPC na 8545 i 8546)
scripts/local-testnet.sh
target/release/rand --rpc http://127.0.0.1:8545 status
# 4. Testy; w trybie release, ponieważ proving STARK jest wolny w trybie debug (678 testów, około 43 minut według pomiaru z 2026-09-14)
cargo test --workspace --release
# Wydanie v0.8.0 (c0878c3f) uruchamia chain 21, a żadne wcześniejsze wydanie tego nie robi: chain 21 działa na zestawie ograniczeń 9, którego kluczy weryfikatora i kodowania dowodów nie zawiera nic starszego. Zbuduj je z tagu albo na Linux x86_64
# pobierz pliki binarne wydania i sprawdź je z SHA256SUMS opublikowanym razem z nim
git checkout v0.8.0 && cargo build --release
curl -LO https://github.com/randprotocol/fullnode/releases/download/v0.8.0/rand-node -LO https://github.com/randprotocol/fullnode/releases/download/v0.8.0/rand \
-LO https://github.com/randprotocol/fullnode/releases/download/v0.8.0/msauth-vk-production.bin# przypięty klucz weryfikatora multisig: rand-node wczytuje go sprzed swojego pliku binarnego i odmawia uruchomienia bez niego
sha256sum rand-node rand msauth-vk-production.bin # musi wypisać wartości wydania (SHA256SUMS, podpisane jako SHA256SUMS.sig):
# 324a4ab1029d39e67fc2de36b036341b0f88f13089997d7fe24c596363a58278 rand-node
# e3a38e74ee28743a960fc1c3eb1ac6c538e18dc259411e10afff7f54e268bbf4 rand
# 68facb06c7f321aaf1d4d541acf6b5c0e9d7f17788ed1c9add6c5a8a8f7acd30 msauth-vk-production.bin
# Tożsamość Twojego węzła: klucz walidatora Dilithium2 i identyfikator peera p2p w jednym pliku. Wygeneruj własny
# i przechowuj go poza checkoutem; repozytorium nie śledzi już żadnego klucza
rand-node keygen --out node.key.json
# Genesis jest dostarczany w repozytorium; każdy węzeł musi posiadać identyczny plik.
# init wypisuje jego hash, który musi zgadzać się z poniższym
rand-node init --datadir ./data --genesis deploy/genesis-chain21.json
# Połącz się z publicznymi walidatorami (chain 21 zachował klucze chain 14, więc także jego identyfikatory peerów i adresy IP).
# Pomiń --validator: Twojego klucza nie ma w zbiorze walidatorów. Walidator potrzebuje też NTP
rand-node run --datadir ./data --key node.key.json \
--listen /ip4/0.0.0.0/tcp/30303 --rpc 127.0.0.1:8545 --no-mdns \
--bootstrap /ip4/164.90.239.200/tcp/30303/p2p/12D3KooWEQEbUwZRgqhDPXhW7vNBmcRcnhUDGUADe81VFdv3ALYe \
--bootstrap /ip4/165.245.173.74/tcp/30303/p2p/12D3KooWJyc5oDHggAr89e9QrRFBy9Tg8TxXh18yzrb1SM6KKLYw \
--bootstrap /ip4/188.166.235.187/tcp/30303/p2p/12D3KooWSyX84P1DAbWByLHpRBMLRWD53r3Jj4aqVt6tHoF8B2ZQ
# Portfel to osobny, shielded klucz. Jego adres rand1… to około 1,6 KB tekstu
rand keygen && rand address
# Mint z faucetu jest podpisywany przez walidatora, więc wymaga RPC walidatora: działa na
# lokalnym łańcuchu dwóch walidatorów bez zmian; obserwator odpowiada "ask a validator node". Na chain 21
# faucet mintuje tylko do 16 portfeli z listy dozwolonych w jego genesis i tylko z walidatorów, które wskazuje
rand faucet # 100 RAND do notatki, którą możesz otworzyć tylko Ty
rand balance # skanuje drzewo Twoim kluczem; nikt inny tego nie zrobi
rand send <rand1 address> 1.5 # prosi o potwierdzenie, generuje dowód (~2 min), czeka na zatwierdzenie
# Złóż wbudowanego gościa: zapłać nadwyżkę ponad 1000, jeśli cztery prywatne salda ją pokrywają
rand program build --guest private_payment --arg 1000 --out pp.json
rand program deploy pp.json # wypisuje identyfikator programu (jego hash zawartości)
# Dowód generowany lokalnie; w łańcuchu lądują tylko dowód, osiem słów wyjściowych i zapieczętowany zapis wejść
rand call <program id> --input 400 --input 250 --input 300 --input 75
rand receipt <tx> # wyjścia [1, 0, 25, 0, ...]: nadwyżka, opublikowana jako dane
# Później otwórz zapis i porównaj go z H_IN opublikowanym przez dowód
rand open-call <tx> # wejścia: [400, 250, 300, 75] — werdykt: faithful
Wymagania
- System
- Linux x86_64 lub macOS arm64
- Rust
- 1.98.1, przypięty przez rust-toolchain.toml; rustup go instaluje
- Zależności budowania
- Kompilator C++, cmake, pkg-config, nagłówki OpenSSL (RocksDB)
- Pierwsza kompilacja
- 10 do 20 minut: RocksDB i Plonky3 ze źródeł
- Porty
- TCP 30303 przychodzący na węzłach publicznych; RPC na 127.0.0.1:8545
- Serwer
- Instancja chmurowa z 1 do 2 vCPU obsługuje walidatora testnet
- Zegar
- NTP (chrony) na walidatorze: wstrzymuje głos na blok wyprzedzający jego własny zegar o więcej niż 15 s, więc spóźniony zegar po cichu przestaje głosować
- Proving
- Dziś tylko CPU: shielded transfer trwa na laptopie około dwóch minut (dowód autoryzacji 7 s i dowód pakietu około 110 s) i zajmuje około 6 GB pamięci; małe wywołanie dodaje około 30 s
Wybierz rolę
- Obserwator otwarta dla każdego
Ten sam plik binarny bez --validator. Synchronizuje łańcuch, weryfikuje każdy certyfikat oraz każdy dowód pakietu i wywołania, ponownie wykonuje każdy blok, porównuje potwierdzenia i udostępnia JSON-RPC. Tak działa nowy klucz w publicznym testnet.
- Walidator z depozytem
Głosuje i proponuje bloki w ramach łańcuchowego HotStuff. Na chain 21, podobnie jak na chain 20, nowy walidator jest najpierw dopuszczany głosowaniem: walidatorzy posiadający ponad dwie trzecie stawki podpisują akcję AdmitValidator dla jego klucza. Następnie rejestruje klucz węzła (rand-node register --v2), wiąże co najmniej 1 000 RAND z portfela i wchodzi do zbioru na trzeciej granicy epoki liczącej 1 000 bloków po związaniu (dwuepokowe opóźnienie wiązania z chain 18). Chain 18 wystartował z 26 walidatorami po 1 000 RAND każdy; aby zatwierdzać bloki, ponad dwie trzecie stawki, czyli 18 z 26, musi być online i głosować. Wygeneruj własny klucz: żaden klucz walidatora nie jest już przechowywany w repozytorium, a pliki kluczy zatwierdzone dla wcześniejszych łańcuchów to opublikowane ziarna.
- Portfel i prover lokalnie
Klient rand przechowuje 256-bitowy klucz wydatkowania i niczego nie podpisuje: autoryzacją są dwa dowody, mały, tworzony kluczem wydatkowania, oraz dowód pakietu 4-in-4-out. Skanuje drzewo w poszukiwaniu własnych notatek, generuje oba dowody na Twojej maszynie, w tym samym kształcie dla RAND i dla każdego tokena RPL, a przy poufnym wywołaniu dowodzi także program. Do łańcucha trafiają tylko dowody, zobowiązania, nullifiery i zapieczętowane koperty.
Nie uruchamiasz węzła? Ten sam portfel jest dostępny jako aplikacja na iOS, Android, Chrome i Firefox: Portfele.
Każdy węzeł sprawdza wszystko
Węzeł, który się synchronizuje, ponownie weryfikuje każdy certyfikat, ponownie wykonuje każdy blok łącznie z jego dowodami i porównuje potwierdzenia przed jego przyjęciem. Przy starcie sprawdza własną bazę danych, obcina wszystko, co niespójne, zachowując stan bezpieczeństwa głosowania, i pobiera brakujący fragment od peerów.
# Węzeł zatrzymany: hashe, QC, podpisy, dowody, odtworzenie
rand-node verify --datadir ./data --mode full
rand-node verify --datadir ./data --repair
Testy awarii na działającym testnet
- ›Zatrzymaj jednego z czterech walidatorów: łańcuch nadal zatwierdza bloki, a węzeł po powrocie nadrabia zaległości w kilka sekund.
- ›Zatrzymaj dwóch z czterech: łańcuch zatrzymuje się bez kworum i wznawia pracę bez forka, gdy wrócą.
- ›Uszkodź bazę danych węzła: wykrycie przy starcie, obcięcie, ponowna synchronizacja od peerów, a potem identyczność bajt po bajcie.
- ›Transfery przez różne węzły: wszystkie zatwierdzone, salda wszędzie identyczne, podaż bez zmian.
- ›Zerwane połączenie z peerem zostaje nawiązane ponownie przez logikę ponownego wybierania w ciągu około 30 sekund.
Jeszcze niezaimplementowane
Wymienione po to, by różnica między artykułem a węzłem była czytelna, a nie domyślna.
- ›Trwały stan poszczególnych programów i wywołania między programami
- ›Kompilator w samym portfelu: program to wbudowany, zasemblowany guest albo obraz zbudowany osobnym toolchainem rand-guest
- ›Slashing i jailing, nagrody za bloki, rynki opłat, beacon lidera oparty na hash-sortition
- ›Akumulator nullifierów, przycinanie dowodów po finalności, grupowanie dowodów w partie
- ›Dowód tier-20 dla transferu SPL Token oraz rynek prowerów GPU opisany w artykule