Uruchamianie walidatora i agregatora

Użyj tej strony, aby dobrać maszynę, zanim ją uruchomisz. Walidator jest tani. Dowodzenie nie jest: pamięć potrzebna na dowód rośnie gwałtownie wraz z jego poziomem (tier) i to ta jedna liczba rozstrzyga, czy maszyna da sobie radę z zadaniem. Każda podana tu wartość pochodzi z pomiaru na testnet lub z zapisów fullnode’a. Wartości, które nie są ostateczne, są oznaczone.

Co robi każda rola

Walidatory i obserwatorzy nigdy nie dowodzą. Transfer shielded lub wywołanie dowodzi portfel, który je wysyła, albo, w przypadku samego dowodu pakietu, prover, z którym ten portfel jest sparowany (Uruchamianie węzła). Walidatory floty nie dowodzą dziś niczego.

Agregacja bloków jest zbudowana, ale nieaktywna. Wymaga sekcji aggregation w genesis. Łańcuch 20 jej nie ma: agregacja jest wyłączona, tak jak w łańcuchach od 9 do 19, a build odmawia uruchomienia na genesis zawierającym tę sekcję.

Wymiarowanie w skrócie

Prover jest dziś jednowątkowy. Droplet z 16 vCPU pracował na 99% jednego rdzenia. Więcej rdzeni nie przyspiesza pojedynczego dowodu; więcej RAM-u rozstrzyga o tym, czy dowód się zakończy.

Walidatory i obserwatorzy

Pamięć i CPU

Pierwotnych osiemnastu walidatorów działa na dropletach 2 GB. Weryfikacja dowodu jest tania:

Pamięć, jakiej walidator potrzebuje do weryfikacji dowodu wywołania tier 18 lub tier 20, jest teraz częściowo zmierzona, na laptopie z Apple Silicon i 48 GB, niezależnie od dropletu DigitalOcean, który wytworzył każdy dowód: weryfikacja dowodu transfer tier 18 zajęła 50,2 s przy szczytowym RSS 3,66 GB (przetłumaczony) lub 49,6 s (interpreter, RSS nie zapisano osobno); weryfikacja dowodu approve tier 16 zajęła 12,2 s (RSS nie zapisano osobno). Tier 20 nie jest zmierzony — nie istnieje jeszcze żaden dowód tier 20 do zweryfikowania. Od v0.5.6 walidator nigdy nie buduje tak dużego klucza: nagłówek dowodu wywołania jest sprawdzany przed zbudowaniem jakiegokolwiek klucza weryfikacyjnego, a wywołanie powyżej tier 14 (lub z tabelą keccak powyżej 2^12, lub tabelą sha256 powyżej 2^13) jest odrzucane, przy dopuszczeniu i jako reguła ważności bloku. Najgorszy dopuszczalny nagłówek wywołania zmierzono na 4,7 s i 312 MB do weryfikacji.

Droplet z 1 vCPU i 2 GB nie jest w stanie zbudować binariów. Zbuduj je na większej maszynie i skopiuj (zob. konfiguracja).

Dysk

W łańcuchu 20, tak jak w łańcuchu 19, 24 z 26 walidatorów działa z --prune-history 24h i przechowuje około doby bloków; sam ledger (notes, nullifiery, kotwice, rejestr) nigdy nie jest przycinany. Archiwa, obs1 i rand-archive-2 (oba również walidatory), działają bez tej flagi. Węzeł mainnet nigdy jej nie przekazuje. Węzeł odmawia uruchomienia, jeśli w systemie plików jego katalogu danych jest mniej wolnego miejsca niż --min-free-disk-mb (domyślnie 1 024 MB), a rand_getHealth odpowiada disk_low poniżej czterokrotności tej wartości; roll, który czeka na ok, zatrzymuje się na węźle, któremu kończy się miejsce. Zob. Przycinanie historii, aby dowiedzieć się, na co przycięty węzeł nadal odpowiada.

Usuń katalog danych wycofanego łańcucha po przełączeniu. Katalogi danych są nazywane według skrótu genesis (data-<name>-<hash8>: -6210cf07 dla chain 20, -a3defc93 dla chain 19; sześć hostów strażniczych używa /var/lib/randnode/data-20), więc stare katalogi zostają, dopóki ich nie usuniesz. Przy przełączeniu na chain 20 jeden regionalny walidator (syd1) wystartował ze stanem disk_low i 3,9 GB wolnego miejsca, przez co start utknął na 25 z 26, bo na dysku wciąż leżały katalogi łańcuchów 14–17; ich usunięcie zwolniło 22 GB. Zachowaj katalog poprzedniego łańcucha przez dobę jako cel wycofania zmian, a potem go usuń. Przy pełnych blokach każdy surowy dowód pakietu ma od chain 14 około 1,42 MB (około 1,3 MB do chain 13). Od chain 17 każdy pakiet niesie też dowód autoryzacji, więc przelew to około 2,85 MB dowodów: około 1,49 MB dowodu pakietu i 1,36 MB dowodu autoryzacji (profil produkcyjny, zmierzone 2026-09-29). Agregacja, gdy jest aktywna, przycina dowód zamkniętego pakietu do około 3 KB, chyba że węzeł działa z --keep-raw-proofs. Nie obejmuje ona dowodu autoryzacji, który zostaje w pełnym rozmiarze.

Sieć

Otwórz przychodzący TCP 30303 na węźle publicznym. Węzły za NAT łączą się na zewnątrz z użyciem --bootstrap. Przy pełnych blokach 4 MiB łącze walidatora przenosi około 2 MB/s.

Zegar

Walidator potrzebuje NTP. Chain 14 jest pierwszym łańcuchem, w którym czas zegarowy jest częścią konsensusu (wzmocnienie mostu B2):

Walidator, którego zegar spóźnia się o 20 s, po cichu przestaje głosować: widzi każdy uczciwy blok jako wyprzedzający jego zegar i wstrzymuje głos, a nic się nie psuje. Na chain 20 do zatwierdzenia czegokolwiek musi zagłosować osiemnastu z dwudziestu sześciu. Sprawdź każdego walidatora i zainstaluj chrony tam, gdzie zegar nie jest zsynchronizowany:

timedatectl                     # want "System clock synchronized: yes" and "NTP service: active"
chronyc tracking 2>/dev/null || timedatectl show-timesync --all 2>/dev/null
apt-get install -y chrony && systemctl enable --now chrony

Ta sama granica 15 s dotyczy genesis. Ustaw timestamp_ms blisko czasu startu i nigdy przed nim: genesis wyprzedzający czas o więcej niż 15 s nie zatwierdzi bloku 1, dopóki czas zegarowy go nie dogoni, a genesis daleko w przeszłości zostawia czas bloków za zegarem, który nadrabiają one najwyżej po 60 s na blok (docs/deploy.md). Obserwator nie głosuje, więc reguła głosowania go nie wiąże.

Rozmiary DigitalOcean, na których działa testnet

Ta tabela obejmuje pierwotnych osiemnastu walidatorów. Od 2026-09-27 walidator A działa również na dropletcie (sgp1), a nie na laptopie. Na chain 15 (2026-09-27) związano obligacją jeszcze ośmiu walidatorów: dwa archiwa, obs1 i rand-archive-2 (fra1), oraz sześć hostów strażniczych. Rozmiary ich dropletów nie są tu zapisane, podobnie jak to, czy mkc1 i mem1 zmieniono rozmiar. Wszystkie 26 to walidatorzy genesis na chain 20, tak samo jak na chain 19, po 1000 RAND każdy, a na dzień 2026-09-30 wszystkie 26 kluczy należy do jednego operatora.

Pamięć do dowodzenia

Portfel dowodzi każdą wysyłaną transakcję, więc wywołujący program potrzebuje pamięci dla poziomu (tier) tego programu. Oto zmierzone granice. Przebiegi na tier 18 zakończyły się, zostały udowodnione i zweryfikowane na DigitalOcean; tier 20 nie. Od v0.5.6 łańcuch odrzuca dowód wywołania powyżej tier 14 (MAX_CALL_TIER), więc wiersze dla tier 16, 18 i 20 poniżej są pomiarami, a nie wywołaniami, które chain 20 dopuszcza; każde wywołanie zatwierdzone na chain 14 miało tier 10.

Wywołania ERC-20 lądują na tier 16 i 18, a SPL Token na tier 20 (Ethereum, Solana). Żaden dowód na tier 18 ani 20 nie został wykonany na maszynie z 48 GB.

Agregatory

Agregator obserwuje łańcuch, bierze dowody pakietów z okna sfinalizowanych bloków, dowodzi jednego rekurencyjnego agregatu nad nimi i go przesyła. Blok, który go zawiera, jest blokiem pieczętującym. Agregator otrzymuje udział w dowodzeniu objętych pakietów oraz subsydium blokowe w nowych RAND, na swój zarejestrowany adres wypłaty. Agregacja jest bez zezwoleń: może się zarejestrować każdy operator z obligacją.

Istnieje tylko w łańcuchu, którego genesis ma sekcję aggregation. Chain 20 jej nie ma, a jego kompilacja odmawia startu na genesis, który ją zawiera.

Sprzęt

Wartości dla N = 2 i N = 3 zmierzono na dropletcie DigitalOcean z 256 GB w dniach 2026-09-28/29, przy zestawie ograniczeń 7, a produkcyjny dowód wyjścia potrzebował więcej niż 256 GB tej maszyny. Żadnej nie zmierzono ponownie przy zestawie ograniczeń 8, na którym działają chain 18 do 20, więc wiersz N = 1 traktuj jako dolną granicę. Backend CUDA po raz pierwszy uruchomiono na prawdziwym sprzęcie 2026-09-28, na NVIDIA H100: jego jądra kompilują się do PTX dla sm_80 i sm_90 i zgadzają się z referencją CPU. Pomiar produkcyjny na węźle GPU floty wciąż czeka na wykonanie. Każdy węzeł płaci też jednorazowo przy starcie za zbudowanie klucza programu agregatu: 13,0 do 13,4 s w profilu testowym (2¹⁹) i oczekiwane 30 do 70 s w produkcji (2²¹).

Polecenia

# print a signed registration; the bond burns out of a wallet bundle as the register bundle's burn
rand-node aggregator register --key agg.key.json --bond <RAND> --payout rand1… --rpc http://127.0.0.1:8545

# the daemon: poll rand_getUnsealed, fetch the raw bundles, prove, seal the payment note, submit
rand-node aggregate --key agg.key.json --rpc http://127.0.0.1:8545 --watch

# leave, then withdraw the released bond into a note at the payout address
rand-node aggregator unbond --key agg.key.json --rpc http://127.0.0.1:8545
rand-node aggregator withdraw --key agg.key.json --rpc http://127.0.0.1:8545

rand status pokazuje w takim łańcuchu sekcję aggregation: zarejestrowani agregatorzy, nieopieczętowane bloki i indeks harmonogramu dotacji. rand_getUnsealed jest listą zadań.

Konfiguracja

Te kroki odtwarzają skrypty używane przez testnet (deploy/vps-setup.sh, deploy/update-droplet.sh). Dają walidator lub węzeł obserwujący z systemem Linux.

1. Kompilacja na hoście kompilującym

Kompilacja wymaga build-essential clang cmake pkg-config libssl-dev, Rusta 1.98.1 (przypiętego w rust-toolchain.toml) oraz repozytorium circuits obok repozytorium fullnode. Pierwsza kompilacja trwa od 10 do 20 minut.

git clone https://github.com/randprotocol/fullnode
git clone https://github.com/randprotocol/zkp-circuits circuits
cd fullnode
git checkout v0.6.8                       # c9c9bd3c, the build chain 20 runs
git -C ../circuits checkout "$(sed -n 's/^circuits: //p' crates/randprotocol-zkvm/guests-compiled/PROVENANCE.md)"   # aeacf31 for v0.6.8
git show origin/main:deploy/genesis-chain20.json > deploy/genesis-chain20.json   # committed after the tag
cargo build --release -p randprotocol-node -p randprotocol-client
sha256sum target/release/rand-node         # compare on every node you copy it to

Łańcuch 20 wymaga v0.6.8 na każdym węźle przed init. Jego genesis zawiera pola, których nie czyta żadna wcześniejsza kompilacja (testnet, binding_domain, proof_window_blocks, program_state, grupy rotation i fees mostu, limity gazu, przyjmowanie do stakingu w drodze głosowania), a v0.6.8 wprowadza zmiany konsensusu CON-4 i CH-1 z audytu v6. Dowody nadal powstają według zestawu ograniczeń 8, jak w łańcuchach 18 i 19, a obok dowodu każdego pakietu powstaje dowód autoryzacji (hc_auth). Kompilacja v0.6.8 odrzuca genesis łańcuchów od 14 do 17 przy run i verify. Uruchom tę jedną kompilację, której używa flota. Plik genesis znajduje się w gałęzi main repozytorium fullnode (commit 74cfaca0), a nie w tagu v0.6.8, stąd trzecia linia git. Repozytorium circuits musi być na commicie, z którego wydanie zostało zwendorowane, a który druga linia git powyżej odczytuje z drzewa fullnode. Dodaj -p randprotocol-prover, aby zbudować także rand-prover.

2. Instalacja binariów na węźle

scp target/release/rand-node target/release/rand deploy/genesis-chain20.json root@<node>:/root/
ssh root@<node> 'install -m 755 /root/rand-node /root/rand /usr/local/bin/'

3. Klucz, genesis, zapora sieciowa

Na węźle:

install -d -m 700 /root/keys
test -e /root/keys/node.key.json || rand-node keygen --out /root/keys/node.key.json   # prints the address; keep the seed secret
rand-node init --datadir /root/data-6210cf07 --genesis /root/genesis-chain20.json
timedatectl                                        # "System clock synchronized: yes" (see Clock)
ufw allow 22/tcp && ufw allow 30303/tcp && ufw enable

Wygeneruj klucz na węźle, jak powyżej, i trzymaj go poza jakimkolwiek checkoutem. W repozytorium fullnode nie jest już śledzony żaden klucz (audyt v3, OPS-1). Pliki deploy/node-*.key.json zatwierdzone dla łańcuchów od 8 do 13 to opublikowane seedy; klucze walidatorów łańcucha 20 (osiemnaście wygenerowanych dla łańcucha 14 i osiem związanych w łańcuchu 15) wygenerowano poza repozytorium, a flota trzyma klucz każdego dropleta w /root/keys/node-<name>.key.json, poza drzewem źródeł. Lokalizacja ma znaczenie na węźle zaprowadzonym skryptami floty: deploy/rebuild-vps.sh i deploy/push-to-vps.sh synchronizują /root/fullnode przez rsync z opcją --delete, więc klucz leżący wewnątrz tego drzewa zostanie usunięty przez następną przebudowę, a jednostka nie uruchomi się ponownie. Od v0.6.8 keygen odmawia nadpisania istniejącego pliku (v0.6.7 nadpisywał go bez pytania); test -e sprawia, że linię można bezpiecznie uruchamiać ponownie w obu przypadkach. Przed związaniem klucza zrób jego kopię zapasową poza hostem.

init wypisuje hash genesis. Musi on brzmieć 6210cf071a390d7ac61d8cbea5dd9d139d1a493a862b54a45a498f36af2d5135 (łańcuch 20). Plik genesis to genesis-chain20.json w katalogu deploy/ repozytorium fullnode, w gałęzi main. Nazwij katalog danych od pierwszych ośmiu znaków hasha, jak robi to flota (data-<name>-6210cf07), aby nigdy nie kolidował z katalogiem łańcucha 19 (-a3defc93) ani późniejszego łańcucha. Genesis ustala te limity. Limit dowodu wynosił 8 MiB w łańcuchach od 13 do 16, a od łańcucha 17 wynosi 4 MiB, w którym transakcja zaczęła nosić do trzech dowodów:

Genesis łańcucha 20 zawiera także consensus_domain: 1, binding_domain: 1, testnet: true, sekcję staking z przyjmowaniem w drodze głosowania, sekcję gas z pułapami cen, grupy rotation i fees mostu, hardening_v6 oraz dwa przypięte guesty hc_bundle i hc_auth; Uruchamianie węzła wymienia, co ustawiają.

4. Jednostka systemd

To jednostka zapisywana przez deploy/vps-setup.sh, ze ścieżkami podanymi wyżej:

[Unit]
Description=RAND full node
After=network-online.target
[Service]
Environment=RUST_LOG=info,libp2p=warn,libp2p_mdns=off
ExecStart=/usr/local/bin/rand-node run --datadir /root/data-6210cf07 --key /root/keys/node.key.json --validator --listen /ip4/0.0.0.0/tcp/30303 --rpc 127.0.0.1:8545 --no-mdns --prune-history 24h --bootstrap <multiaddr> --bootstrap <multiaddr>
Restart=always
RestartSec=3
[Install]
WantedBy=multi-user.target

Pomiń --validator dla węzła obserwującego. --prune-history 24h to ustawienie walidatorów testnetu, z wyjątkiem archiwów; pomiń je w węźle przechowującym pełną historię i nigdy nie przekazuj go w mainnet. Adresy multiaddr bootstrapu łańcucha 20 to węzły C (fra1), D (ric1) i E (sgp1), bez zmian względem łańcucha 19. Łańcuch 20 działa na kluczach walidatorów wygenerowanych dla łańcucha 14, a tożsamość p2p jest wyprowadzana z klucza walidatora, więc te identyfikatory peerów są tymi, których używał łańcuch 14. Nowy węzeł synchronizujący się od genesis potrzebuje też peera z pełną historią, więc dodaj jedno z dwóch archiwów (obs1, potem rand-archive-2):

/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
/ip4/168.144.46.203/tcp/30303/p2p/12D3KooWS5usdMPvsbaWSaT2xtKndHvDYurwmueoNvaRRarb2wRf
/ip4/206.81.29.236/tcp/30303/p2p/12D3KooWPocyZGcNB9Vp68VSfgVvNXhSzBBoJa4h9R1yMkp71XHh

Utrzymuj RPC na 127.0.0.1, chyba że chroni go zapora. Węzeł, który ma obsługiwać publiczność, otwiera obok niego publiczny listener v0.6.8 (--public-rpc <ADDR>) i stawia przed nim proxy, nigdy przed --rpc (JSON-RPC). Jednostka przeniesiona z v0.6.7 nie może przekazywać --prover-accept-spend-key, które v0.6.8 odrzuca przy starcie.

systemctl daemon-reload && systemctl enable --now rand-node
journalctl -u rand-node -f
rand status                       # height climbing, peer_count rising

5. Dołączenie do zbioru walidatorów

Nowy klucz nie należy do zbioru żadnej epoki. W łańcuchu 20 musi najpierw zostać wybrany w głosowaniu: jego genesis ustawia staking.admission_by_vote, więc walidatorzy posiadający ponad dwie trzecie wagi głosów podpisują go każdy poleceniem rand-node admit sign --candidate <key or registration> --key <validator key> --genesis-hash <chain 20's hash>, a jeden z nich przesyła głosy poleceniem rand-node admit submit; następnie rand_getAdmitted go wyświetla. Potem zwiąż z nim co najmniej 1 000 RAND: wypisz rejestrację poleceniem rand-node register --key /root/keys/node.key.json --payout rand1… --v2 (łańcuch 20 odrzuca rejestrację v1), a następnie zwiąż środki z portfela poleceniem rand bond <address> 1000 --registration <hex>. Związanie czeka na epokę aktywacji, najwcześniej trzy granice po 1 000 bloków od jego zatwierdzenia, a na jednej granicy nowa waga może wynieść najwyżej 2 500 bps wagi aktywnej (łańcuch 19 ograniczał ją do stałych 10 000 RAND). Staking przeprowadza przez ten proces.

6. Aktualizacja

Dotyczy to kompilacji, która obsługuje ten sam łańcuch. Przejście z wcześniejszego łańcucha na łańcuch 20 nie jest aktualizacją: wymaga nowego binarium, nowego genesis i świeżego katalogu danych, a katalog danych starego łańcucha można potem usunąć (deploy/retire-chain-dirs.sh; flota trzyma go przez dobę na wypadek wycofania). Aby wdrożyć nową kompilację bez zmiany łańcucha, zbuduj ją raz, porównaj sha256 zarówno rand-node, jak i rand, zatrzymaj usługę, zainstaluj i uruchom ponownie, po jednym węźle naraz. Niektóre wydania wdraża się metodą „zatrzymaj wszystko, uruchom wszystko” (reguła warstwy wywołań z v0.5.6, zmiana formatu Status w v0.5.7, ostrzejsza weryfikacja dowodów w v0.6); notatki każdego wydania mówią, które. v0.6.7 wdrożono na łańcuch 18 po jednym węźle naraz; v0.6.8 przyszła z łańcuchem 20, metodą „zatrzymaj wszystko, uruchom wszystko”, ponieważ jej zmiany konsensusu CON-4 i CH-1 nie mogą być wdrażane węzeł po węźle. Przed następnym węzłem poczekaj, aż poprzedni dołączy ponownie, aby kworum nigdy nie było mniejsze o więcej niż jeden węzeł. deploy/update-droplet.sh <ip> [build-host] robi dokładnie to przez SSH.

Wydania do v0.6.8 włącznie zbudowano ręcznie na jednym hoście i są niepodpisane. Wydanie v0.6.8 na GitHub zawiera rand-node, rand, rand-prover i SHA256SUMS, zbudowane na węźle E; ta suma kontrolna wykrywa uszkodzone pobranie, ale nie poświadcza hosta kompilującego. v0.6.8 dostarcza workflow wydania, który buduje binaria z tagu, a deploy/update-droplet.sh odmawia instalacji bez podpisanego SHA256SUMS, chyba że ustawiono ALLOW_UNSIGNED=1. deploy/release-signers nie wymienia jeszcze żadnego klucza, więc podpisana ścieżka nie była dotąd używana.

Łańcuchy 15, 16, 17 i 18 ruszyły w ciągu 2,7 doby (od 2026-09-26 do 2026-09-29), każdy jako zatrzymanie całej floty. Łańcuch 19 nastąpił 2026-10-01 o 03:43 UTC, jako ponowny genesis łańcucha 18 na tej samej kompilacji, a łańcuch 20 tego samego dnia o 06:17 UTC, wycięty ze zrzutu łańcucha 19 przy hard forku v0.6.8; każdy węzeł zatrzymał się na wysokości 7 700 łańcucha 19. Pisemna polityka cięcia (2026-09-30) obowiązuje od łańcucha 20; zapis cięcia łańcucha 20 zrezygnował z przebudowy przez drugiego operatora, ponieważ jeden operator posiada wszystkie klucze. Cięcie wymaga powodu, którego nie da się spełnić aktualizacją kroczącą, opublikowanej listy tego, co przenosi i co porzuca, wcześniej wykonanej listy kontrolnej przebudowy klientów, drugiego operatora, który odbudowuje genesis do tego samego hasha, planu wycofania oraz identyfikatora łańcucha, którego nigdy wcześniej nie użyto.