Dla deweloperów

Rand jest oprogramowaniem open source. Pełny węzeł, eksplorator, most, badania nad dowodzeniem i klienty portfela mają każdy własne repozytorium na GitHub. Czytaj kod, uruchamiaj testy, wysyłaj poprawki. Ta strona to mapa: gdzie mieszka każdy komponent, w czym jest zbudowany, jak daleko zaszedł system dowodzenia i gdzie dziś się kończy.

Repozytoria

Stos

Rust od początku do końca. Rand to własny łańcuch: węzeł HotStuff BFT z warstwą plotkowania libp2p, w pełni osłonięta pula notatek jako księga, podpisy i szyfrowanie notatek odporne na ataki kwantowe oraz zkVM Rand do poufnych obliczeń, wszystko w repozytorium fullnode. Sam system dowodzenia jest częścią objętą aktywnymi badaniami, opisaną niżej.

Jedna relacja dla każdego programu

Uniwersalna relacja wykonania R_exec z whitepaperu istnieje jako kod: rand_zkvm, maszyna RV32IM dowodzona pod jednym wsadowym STARK na Plonky3 nad ciałem Goldilocks. Dowodzi, że jakiś ślad wykonał program hc do tych publicznych wyjść na wejściach zobowiązanych przez solone H_IN, a nic o programie nigdy nie jest parametrem weryfikatora. Opublikowanie poufnego programu oznacza zarejestrowanie skrótu, nigdy generowanie dedykowanego układu.

System dowodzenia jest przejrzysty, bez zaufanej konfiguracji i bez krzywej z iloczynem dwuliniowym, a jego założeniem jest odporna na kolizje funkcja skrótu. Oczekuje się, że każdy inny komponent dotykający dowodów będzie zmierzał do tego crate’a, zamiast rozwijać własny. Crate mieści się w zkp-circuits/research i jest wendorowany do fullnode przy zestawie ograniczeń 8 (circuits aeacf31, fullnode v0.6.7 i v0.6.8). Poniższe tabele i pomiary opisują zestaw ograniczeń 5 (kamień milowy M4.2), chyba że wiersz wskazuje późniejszy zestaw; pochodzą z docs/zkvm.md, docs/zkvm-milestones.md i docs/confidential.md fullnode według stanu na 2026-09-13, a pomiary podano tak, jak je zmierzono na laptopie z Apple Silicon, nie jako cele.

Osiem tabel na nazwanych szynach, dziewiąta na żądanie

Jedno zobowiązanie, jedno otwarcie FRI. Tabele nigdy nie wywołują się nawzajem; wymieniają fakty przez nazwane szyny LogUp (PROGRAM, PROGRAM_WORD, MEMORY, ALU, POSEIDON2, INPUT_DIGEST, INPUT_READ, KECCAK oraz wyszukiwania zakresów i półbajtów), a weryfikator sprawdza, czy każda szyna bilansuje się globalnie. Maksymalny stopień ograniczeń każdej tabeli jest przypięty testem pod limitem 8, na jaki pozwala rozszerzenie FRI (blowup).

Od tego czasu pojawiły się trzy zestawy ograniczeń. Zestaw 6 dodał obowiązkową tabelę public dla publicznego wejścia programu podawanego przy wdrożeniu, związaną z niesolonym skrótem H_PUB, oraz opcjonalną tabelę sha256 obok keccak. Zestaw 7 (łańcuch 16) zaślepia każdy terminal LogUp na nowej szynie BLIND, ustala dla każdej zadeklarowanej tabeli dolną granicę 2⁷ wierszy i dodaje syscall POSEIDON2_LEN związany długością. Zestaw 8 (łańcuch 18) dodaje kolumnę GAS do tabeli cpu i jedną wartość publiczną, zadeklarowany GAS_LIMIT.

Co ujawnia dowód

Publiczne: skrót kodu hc (osiem słów skrótu w układzie), solone zobowiązanie wejścia H_IN (osiem słów), poziom gazu i osiem słów wyjścia. Od zestawu ograniczeń 6 także H_PUB, skrót publicznego wejścia, a od zestawu ograniczeń 8 zadeklarowany limit gazu. Nagłówek dowodu deklaruje wysokości tabel Keccak i SHA-256, więc pokazuje, czy wywołanie używało skrótów i, powyżej dolnej granicy 2⁷, mniej więcej w jakim stopniu.

Ukryte: prywatne wejścia (H_IN jest solone, więc jest zarówno ukrywające, jak i wiążące); każde słowo instrukcji, ponieważ weryfikator sprawdza hc, a nigdy program; każda wartość rejestru i pamięci; każda wykonana gałąź; dokładna liczba cykli i dokładnie zużyty gaz; oraz to, które syscalle zostały uruchomione, poza tym, co pokazują wysokości dwóch tabel skrótów.

Poziom jest publiczny w każdym dowodzie, ponieważ rozmiar STARK już ujawnia wysokość jego śladu; ukrycie indeksu nic by nie dało. hc jest wiążący, nie ukrywający: zobacz gdzie to dziś się kończy.

Zmierzone, przy zestawie ograniczeń 5

Laptop z Apple Silicon, build release. To podział tabeli bajtowej w M2.3 przesunął czas dowodzenia; profil 80 zapytań z powrotem podniósł rozmiar dowodu. Klucz weryfikatora nie zależy od zawartości programu, jest indeksowany poziomem oraz zadeklarowanymi w dowodzie wysokościami programu, wejścia i keccaka, więc węzeł rozgrzewa jeden klucz i używa go ponownie.

Późniejsze zestawy zmieniły rozmiary. W zestawie ograniczeń 7 dowód tier 10 ma 1 367 688 bajtów w profilu produkcyjnym, a dowód tier 10 zawierający Keccak 3 283 898 (pomiar z 2026-09-28). Od chain 17 transfer niesie dwa dowody: dowód pakietu tier 14, około 1,49 MB, oraz dowód autoryzacji tier 10, około 1,37 MB, którego wygenerowanie trwa około 7 s. Genesis chain 20 ustala blok o rozmiarze 20 MiB i limit dowodu 4 MiB, a wywołanie nie może przekroczyć tier 14.

Trzy cele, jeden obwód

Natywnie wykonuje się tylko RISC-V. Programy Solidity i Solana działają albo na gościu-interpreterze wewnątrz tej samej relacji, z ich bajtkodem jako wejściem, albo są tłumaczone poza łańcuchem na programy RISC-V, których wyjścia są identyczne z wyjściami interpretera słowo w słowo. Kosztowne kody operacji wymagają dedykowanych tabel koprocesorów zamiast symulacji bit po bicie.

Kamienie milowe

Kamień milowy 1 udowodnił maszynę ogólnego przeznaczenia. Kamień milowy 3 zamienił ją w pulę chronioną (shielded pool): transfer z przynależnością dowodzoną w obwodzie jest dowodzony w R_exec, a weryfikator sprawdza hc, nie widząc ani jednego słowa programu. Kamień milowy 4 to zgodność: jego loader, zobowiązanie do wejścia i tabela Keccak zostały dostarczone jako zestawy ograniczeń 4 i 5, a tabela SHA-256 wraz z zestawem 6. Gości-interpreterów EVM i sBPF, zestaw narzędzi rand-guest oraz oba translatory zbudowano. Transfer ERC-20 został udowodniony na maszynie ze 128 GB; dowód SPL Token, na tier 20, jeszcze nie. Kamień milowy 5 to maszyna wirtualna rekurencji stojąca za agregacją bloków, która jest zbudowana i wyłączona w każdym łańcuchu. Zestawy ograniczeń 7 i 8 powstały po przeglądach z września i modelu gazu.

Fazy puli chronionej

Księga fullnode została wdrożona w trzech fazach, z których każda była hard forkiem (docs/shielded.md §7). S1 zastąpiła księgę kont pulą notatek; S3 przywróciła most jako notatki i weszła jako pierwsza; S2 dołożyła na wierzchu staking. Wszystkie trzy są na main i na bieżącym łańcuchu.

Od wiersza S2 w dół znajduje się praca nad v0.5. Każdy wiersz to twardy fork. Wszystkie razem weszły do jednego nowego łańcucha, chain 14, wydzielonego 2026-09-20 z kompilacji b3c594c i otagowanego jako v0.5 tego samego dnia, po przejściu na żywo pełnego cyklu zUSD przez wdrożone punkty końcowe źródeł. Chain 15, działający od 2026-09-26 na v0.5.8 i nowszych, zawierał całość, z włączonymi poprawkami audytów v4 i v5 zależnymi od genesis: faucet z listą dozwolonych i budżetem na epokę, opóźniona aktywacja bondu, limit wagi stawki, rejestracje powiązane z genesis, consensus_domain 1, reguły mostu v2 oraz limit rejestru tokenów, spalana opłata rejestracyjna i granica 2⁶³ dla not. Chain 20, działający od 2026-10-01 06:17 UTC na v0.6.8 (c9c9bd3c), będący twardym forkiem chain 19, zachowuje to wszystko i dodaje prace z wydań v0.6, wymienione poniżej.

Wydania od v0.5

Każde wydanie to tag git z wpisem w CHANGELOG.md fullnode’a. Wydanie, które zmienia konsensus, format przesyłu lub klucz weryfikatora, wychodzi z nowym łańcuchem; pozostałe wchodzą na działający łańcuch po jednym węźle naraz.

Gdzie to się dziś kończy

Odstępstwa od whitepapera, opisane wprost, bez wygładzania. Każde jest śledzone w dokumentacji własnej danego crate’a, wraz z kamieniem milowym, który je zamyka.

• hc jest wiążące, ale nie ukrywa: nie zawiera soli, więc zgadnięty program można potwierdzić, a dwa wdrożenia tego samego programu są powiązywalne. M3.4 usunęło to, że weryfikator trzyma cały program jawnie.
• Portfel zbudowany przed 2026-09-21 prosi swój węzeł o świadków, a żądanie świadka wskazuje liść, który ma zostać wydany. Obecny rand trzyma własną kopię drzewa i nigdy o nic nie pyta; węzeł nadal obsługuje rand_getWitness dla starszych portfeli.
• Wpłaty są jawne na granicy: mint z faucetu, nota genesis i wpłata przez most niosą swoją kwotę jawnie (od łańcucha 14 mint i nota genesis niosą też swoje otwarcie, więc klucz właściciela również jest publiczny), czyli ta sama widoczność o jeden skok, jaką ma wpłata z puli przejrzystej do osłoniętej w każdym innym systemie.
• Zero knowledge jest statystyczne, nie doskonałe. Taką właściwość faktycznie zapewnia ukrywające FRI w Plonky3 0.7, i crate to mówi.
• Hash transkryptu to Poseidon2 z deweloperskimi stałymi rund, a nie SHA3-384 / BLAKE3-384 z papierów. To zmiana konfiguracji, nie przepisywanie.
• Przy 80 zapytaniach FRI dowód pakietu miał około 1,42 MB w łańcuchach 14 i 15 (około 1,3 MB do łańcucha 13). Od łańcucha 17 transfer niesie około 2,85 MB dowodu: dowód pakietu, około 1,49 MB, i dowód autoryzacji, około 1,37 MB. W łańcuchu domyślnym, z blokami 4 MiB i limitem dowodu 2 MiB, dowód zawierający Keccak wprost przekracza limit dowodu; genesis łańcucha 20 ustawia bloki 20 MiB i limit dowodu 4 MiB (łańcuchy 13 do 16 ustawiają 8 MiB).
• Nagłówek dowodu wywołania nie jest ukryty. Deklaruje poziom oraz wysokości tablic Keccak i SHA-256, więc pokazuje, czy wywołanie haszowało. Wywołania zatwierdzone w łańcuchu 15 przed dolną granicą provera v0.6 ujawniały więcej: prywatną tablicę poniżej 2⁷ wierszy dało się odczytać z dowodu. Dolna granica provera v0.6 zamknęła to dla nowych wywołań, a zbiór ograniczeń 7 z hardening_v6 uczynił to regułą łańcucha od łańcucha 16.
• Wywołanie jest ograniczone do poziomu 14, z co najwyżej 2¹² wierszy Keccak (128 permutacji) i 2¹³ wierszy SHA-256 (128 kompresji), a przy hardening_v6 nie można wdrożyć programu dłuższego niż 8 180 słów. Goście interpretera EVM i sBPF oraz przetłumaczone obrazy ERC-20 i SPL Token są wszystkie powyżej tego progu.
• Kto trzyma świadka, widzi wszystko. ZK chroni widok weryfikatora, nie provera. Od łańcucha 17 portfel może przekazać dowód pakietu sparowanemu rand-prover bez przekazywania klucza wydatkowania, ale ten prover nadal trzyma klucz podglądu i widzi noty. Backend CUDA po raz pierwszy uruchomiono na sprzęcie 2026-09-28 i nie ma jeszcze pomiaru produkcyjnego.

Układ repozytorium

Workspace Cargo fullnode’a, tak jak opisują go jego README i katalog crates/.

Określone, jeszcze niewdrożone

Te komponenty są opisane w papierach lub w dokumentacji fullnode’a, ale nie działają: albo nie ma ich w repozytoriach, albo są zbudowane i włączone w żadnym łańcuchu. Wymieniono je, aby przerwa między specyfikacją a kodem była czytelna, a nie domyślna.

Budowanie i testy

Standardowy przepływ pracy Rust w każdym repozytorium. Fullnode to jeden workspace Cargo z przypiętą wersją toolchainu oraz zestawem testów klastrowych, który uruchamia prawdziwe węzły przez TCP. Jego kompilacja wymaga repozytorium circuits sklonowanego obok, w katalogu o nazwie circuits, na commicie, z którego zsynchronizowano dołączone (vendored) crate’y (aeacf31 dla v0.6.7 i v0.6.8). zkVM to samodzielny crate w zkp-circuits z własnym przypięciem toolchainu oraz demonstracją, która opisuje, co poufne wywołanie ujawnia, a czego nie.

Fullnode:

git clone https://github.com/randprotocol/fullnode.git
git clone https://github.com/randprotocol/zkp-circuits.git circuits   # the sibling directory must be named circuits
git -C circuits checkout "$(sed -n 's/^circuits: //p' fullnode/crates/randprotocol-zkvm/guests-compiled/PROVENANCE.md)"
cd fullnode

# Rust 1.98.1 is pinned by rust-toolchain.toml; first build pulls RocksDB and Plonky3, 10 to 20 minutes
cargo build --release        # target/release/rand-node, target/release/rand, target/release/rand-prover

# All crates; release because STARK proving is slow in debug. One to two hours, mostly proving
cargo test --release

# One machine, two validators
scripts/local-testnet.sh
target/release/rand --rpc http://127.0.0.1:8545 status

Badawcza zkVM, w zkp-circuits/research:

# Toolchain is pinned by rust-toolchain.toml; the first build pulls Plonky3
cargo build --release

# Narrated demo: thirteen proofs, one at production FRI parameters (~6-7 min)
cargo run --release

# Emulator, per-table constraints, cheating provers, ZK, end-to-end, viewing keys, compiled guests (395 tests, ~17 min)
cargo test

Zestaw testów fullnode zmierzony w v0.6.1 na maszynie z 16 vCPU: core 521 testów, node 373, client 117, zestaw cheating-prover 116, oszustwa z ukrytymi pakietami (hidden-bundle) 21 (75 min), przepływ portfela 6 (53 min), klaster 26 (44 min) oraz bramka end-to-end zUSD 2 (51 min). Produkcyjne dowody maszyny wirtualnej rekurencji nie wchodzą w jego zakres i wymagają pamięci wymienionej powyżej.

Running a node opisuje dołączenie do publicznego testnet na podstawie tej kompilacji; genesis testnet, węzły początkowe (bootstrap peers) i skrypty uruchomieniowe znajdują się w katalogu deploy/ fullnode, a strona pobierania zawiera wersję skróconą.

Współtworzenie

Fullnode jest udostępniany na licencji GNU General Public License v3.0 (GPL-3.0-only); wcześniej był na licencji Apache-2.0. Zgłaszaj błędy i propozycje projektowe jako zgłoszenia (issues) w repozytorium, którego dotyczy zmiana. Pull requesty są mile widziane: przed wysłaniem uruchom cargo fmt && cargo clippy i ograniczaj zakres zmian. Miejscem na początek są zgłoszenia fullnode.

Architektura, obwód prywatności, dowód tokena opłat oraz kompromis postkwantowy są opisane w whitepaperze na stronie artykułów. Katalog docs/ w repozytorium fullnode jest źródłem, względem którego sprawdzana jest każda strona tej dokumentacji.