Rand Protocol
Weź udział

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ę.

Zbuduj i uruchom lokalnie
bash
# 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
Dołącz do publicznego testnet jako obserwator
chain 21
# 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
Walidatorzy
26
Kworum
18 of 26
Genesis
ca76c2766ed6090ac6ba5dad86b724dd5d2b80c0edfaed287cd8b129e663ca9a
Wykonaj poufne wywołanie
rand
# 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
Łańcuch widzi identyfikator programu, poziom gazu i osiem słów wyjściowych. Nigdy nie widzi ssald, a ponieważ opłatę pokrywa shielded pakiet, nie dowiaduje się też, kto wywołał program; wyjścia są danymi, a każda płatność to pakiet tworzony przez wywołującego. Pomiar na Apple Silicon: proving trwa około 7 s na poziomie 10, dowód ma około 1,2 MB w profilu FRI z 80 zapytaniami, a weryfikacja trwa około 16 ms przy rozgrzanym kluczu weryfikatora, który węzeł oblicza raz na poziom i używa ponownie dla różnych programów.

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.

Źródło
randprotocol/fullnode
GPL-3.0-only · testnet działa na v0.8.0, najnowszym wydaniu
Weryfikuj

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