Ta strona zapisuje uzasadnienie każdej większej decyzji projektowej w Rand: właściwość, którą komponent musi zapewniać, założenie, przy którym ją zapewnia, oraz koszt zaakceptowany w zamian. Opracowano ją 29 września 2026 r. na podstawie tej witryny, streszczenia whitepapera i referencyjnego pełnego węzła (github.com/randprotocol/fullnode: jego README, docs/ i docs/superpowers/specs/). Każda odpowiedź wskazuje dokument, w którym uzasadnienie jest podane; ścieżki odnoszą się do repozytorium fullnode, chyba że zaczynają się od randprotocol.org.
Status. Rand działa w sieci testnet prowadzonej przez zespół założycielski, a protokół nie został niezależnie zaudytowany. Kilka z poniższych decyzji jest wdrażanych etapami w kolejnych wydaniach łańcucha. Wszystkie wartości liczbowe są pomiarami działającego węzła z chwili opracowania; należy oczekiwać, że się zmienią, i przed ich zacytowaniem trzeba je zmierzyć ponownie.
Prymitywy kryptograficzne
1. Dlaczego ML-KEM-768 (Kyber) do szyfrowania not?
Tekst jawny noty jest szyfrowany dla odbiorcy w kopercie, która pozostaje w publicznej księdze bezterminowo. Jej poufność jest zatem właściwością nieodwołalną (pytanie 8): przeciwnik, który w dowolnym późniejszym momencie zdobędzie kryptograficznie istotny komputer kwantowy, mógłby odszyfrować każdą historyczną kopertę zapieczętowaną KEM opartym na krzywych eliptycznych, ponieważ algorytm Shora rozwiązuje problem logarytmu dyskretnego w czasie wielomianowym. ML-KEM jest znormalizowany w NIST FIPS 203, a jego bezpieczeństwo redukuje się do Module-LWE, dla którego nie jest znany żaden efektywny algorytm kwantowy. Zestaw parametrów 768 (kategoria 3 wg NIST) wybrano jako kompromis między zapasem bezpieczeństwa a 1 184-bajtowym kluczem enkapsulacji, który musi zawierać każdy adres. Koperta to ML-KEM-768 połączony z ChaCha20-Poly1305: 1 348 bajtów, a ze stałym polem memo 1 860 bajtów.
Źródło: randprotocol.org (sekcja o kryptografii postkwantowej); README fullnode; docs/shielded.md §2
2. Dlaczego zobowiązania Poseidon2, a nie Pedersena?
Zobowiązania Pedersena są doskonale ukrywające, ale tylko obliczeniowo wiążące, a ich właściwość wiązania redukuje się do założenia o logarytmie dyskretnym, które przeciwnik kwantowy łamie; przeciwnik zdolny obliczać logarytmy dyskretne może otworzyć zobowiązanie na inną wartość. Ponieważ zobowiązanie opublikowane dziś musi pozostać poprawne i ukrywające przez cały okres istnienia księgi, schemat musi opierać się na założeniach uważanych za odporne na przeciwników kwantowych, co w praktyce oznacza funkcję skrótu. Poseidon2 to funkcja skrótu zorientowana na arytmetyzację, zdefiniowana nad ciałem Goldilocks, więc jej obliczenie wewnątrz STARK kosztuje niewiele ograniczeń. Ta sama funkcja skrótu realizuje zobowiązanie do noty, drzewo Merkle’a o głębokości 32 i nullifier.
Źródło: randprotocol.org (sekcja o kryptografii postkwantowej); docs/shielded.md §1–2
3. Dlaczego dwie funkcje skrótu — BLAKE3 i Poseidon2?
Te dwie funkcje są zoptymalizowane pod różne modele kosztu. Poseidon2 jest używany wszędzie tam, gdzie skrót trzeba obliczyć wewnątrz dowodu — w notach, drzewie zobowiązań, nullifierach i wewnętrznych tabelach zkVM — ponieważ jego koszt mierzy się w ograniczeniach. BLAKE3 jest używany wszędzie tam, gdzie dowód nie występuje, a decyduje natywna przepustowość: w skrótach bloków, w korzeniu stanu obejmującym drzewo, zbiór nullifierów, rejestr walidatorów i tablicę programów oraz w adresach walidatorów (skrót BLAKE3 klucza publicznego). Poseidon2 jest stosunkowo wolny na CPU; BLAKE3 jest stosunkowo kosztowny do arytmetyzacji. Każdy z nich jest używany tylko tam, gdzie obowiązuje jego model kosztu.
Źródło: README fullnode (wiersz podpisy / skróty); docs/architecture.md
4. Dlaczego Dilithium2 (ML-DSA) do podpisów walidatorów?
Podpisy konsensusu zapewniają właściwość odnawialną (pytanie 8): późniejsze złamanie schematu pozwala fałszować przyszłe wiadomości, ale nie unieważnia wstecz bloków już sfinalizowanych, więc schemat można by w zasadzie wymienić, zanim pojawi się przeciwnik kwantowy. Mimo to od bloku genesis przyjęto schemat oparty na kratach, aby głosy konsensusu, współpodpisy strażników mostu i rejestr walidatorów korzystały z jednego postkwantowego typu klucza. Węzeł implementuje zestaw parametrów Dilithium2 z trzeciej rundy (crate crystals-dilithium), który różni się od końcowego ML-DSA-44 z FIPS 204; klucze publiczne mają 1 312 bajtów, a podpisy 2 420 bajtów.
Źródło: docs/superpowers/specs/2026-09-19-pq-cosignature-bridge.md §2; randprotocol.org
5. Dlaczego przejrzysty STARK (FRI nad Goldilocks), a nie SNARK?
Wybór wynika z trzech wymagań. Po pierwsze, brak zaufanej konfiguracji: poprawność opiera się wyłącznie na odporności funkcji skrótu na kolizje, a nie na strukturalnym ciągu referencyjnym ani krzywej przyjaznej parowaniom. Po drugie, wiarygodna postkwantowa poprawność: argument nie przyjmuje żadnego założenia o logarytmie dyskretnym ani o parowaniach. Po trzecie, zgodność ze schematem zobowiązań opartym na funkcji skrótu z pytania 2. Kosztem jest rozmiar dowodu: dowód paczki ma około 1,3 MB, czyli 300–600 razy więcej niż osłonięta transakcja Zcash lub Monero. Koszt ten zaakceptowano i adresuje go osobno agregacja na poziomie bloku (pytania 31 i 34).
Źródło: randprotocol.org; docs/block-space.md §1; docs/zkvm.md
6. Dlaczego profil FRI z 80 zapytaniami zamiast 27?
Profil produkcyjny (80 zapytań, współczynnik blowup 8, 20 bitów grindingu proof-of-work) zapewnia około 86 bitów dowodliwej poprawności, wobec około 42 bitów dla profilu z 27 zapytaniami, przy 2,75-krotnie większym rozmiarze dowodu. Czas weryfikacji prawie się nie zmienia: z 809 ms do 838 ms na zimno i około 16 ms na ciepło. Dowodliwą poprawności przedłożono nad rozmiar dowodu, a koszt rozmiaru przeniesiono na projekt przestrzeni blokowej i agregacji.
Źródło: docs/block-space.md §1, §3
7. Dlaczego twierdzenie postkwantowe podaje się dla każdego prymitywu, a nie jako „128-bitowe w całym protokole”?
Wcześniejsze wersje robocze głosiły 128-bitowe bezpieczeństwo postkwantowe dla protokołu jako całości. Twierdzenie to jest niezgodne z ograniczeniem Brassarda–Høyera–Tappa, zgodnie z którym przeciwnik kwantowy znajduje kolizje w 256-bitowej funkcji skrótu w około 2^85 zapytaniach, więc je wycofano, zamiast je kwalifikować. Artykuł podaje teraz bezpieczeństwo osobno dla każdego prymitywu i każdej roli — 384-bitowy skrót transkryptu, 256-bitowe skróty używane tylko tam, gdzie wymagana jest odporność na przeciwobraz, Dilithium2, ML-KEM-768 oraz FRI nad ciałem rozszerzonym — przy założeniach Module-LWE i Module-SIS oraz przy modelowaniu funkcji skrótu jako kwantowych wyroczni losowych. Skrótem transkryptu w węźle jest obecnie Poseidon2; dokumentacja wymienia to jako otwartą lukę konfiguracyjną.
Źródło: randprotocol.org (sekcja o kryptografii postkwantowej)
8. Czym jest klasyfikacja „nieodwołalne vs odnawialne” i dlaczego determinuje wybory?
Właściwość bezpieczeństwa jest nieodwołalna, jeśli przeciwnik, który w dowolnym przyszłym momencie zyska nową zdolność, może ją naruszyć wstecz dla danych już opublikowanych; poufność not i ukrywanie zobowiązań są tego rodzaju, więc muszą być odporne kwantowo już w chwili publikacji. Właściwość jest odnawialna, jeśli jest ustanawiana na nowo przy każdym użyciu, tak że schemat można wymienić, zanim zagrożenie się zmaterializuje; podpisy i poprawność dowodów są tego rodzaju. Każdy wybór prymitywu w tej sekcji wynika z sklasyfikowania właściwości, którą ten prymityw chroni.
Źródło: randprotocol.org (sekcja o kryptografii postkwantowej)
Pula osłonięta
9. Dlaczego model not/UTXO, bez kont i sald?
Księga oparta na kontach publikuje salda z samej konstrukcji; ich ukrycie wymaga zaszyfrowania stanu i dowodzenia twierdzeń o szyfrogramach, co jest znacznie droższe. Pula not przechowuje wyłącznie zobowiązania i nullifiery, z których żaden nie ujawnia właściciela ani kwoty, więc stan publiczny nie zawiera żadnej informacji o saldach. Jedynym wyjątkiem jest rejestr walidatorów, którego wagi stawek muszą być publiczne, aby repliki zgadzały się co do składu kworum (pytanie 29).
Źródło: docs/shielded.md §1–2; docs/staking.md §1
10. Dlaczego adres ma ~1,6 KB?
Adres osłonięty składa się z 32-bajtowego pola właściciela pk oraz 1 184-bajtowego klucza enkapsulacji ML-KEM-768, którego nadawca potrzebuje do zapieczętowania koperty; zakodowany w base58 ma około 1 667 znaków. Długość jest bezpośrednią konsekwencją postkwantowego KEM. Zatwierdzony projekt (krótkie adresy osłonięte, 2026-09-17) zastępuje adres identyfikatorem odbiorcy o długości około 256 bitów, który wskazuje aktualizowalny rekord, podpisany kluczem wydatkowania i udostępniany przez eksplorator, tak aby klucz enkapsulacji był pobierany, a nie przepisywany.
Źródło: docs/shielded.md §1; docs/superpowers/specs/2026-09-17-short-shielded-address.md
11. Dlaczego każdy klucz jest wyprowadzany z jednego 256-bitowego klucza wydatkowania?
Cały pozostały materiał kluczowy jest deterministyczną funkcją jednego sekretu sk: klucz podglądu nk = H(NK, sk), pole właściciela pk = H(PK, nk), nullifier H(NF, nk, cm), wychodzący klucz podglądu i klucz dekapsulacji ML-KEM, każdy z własnym separatorem domeny. Plik klucza przechowuje więc tylko sk, kopia zapasowa to pojedyncza wartość, a ponowne przeskanowanie drzewa od liścia 0 odzyskuje każdą notę. Ponieważ nie ma drugiej kopii, z której można by odzyskać klucz, portfel odmawia nadpisania istniejącego pliku klucza.
Źródło: docs/shielded.md §1
12. Dlaczego stały kształt paczki 4 wejścia–4 wyjścia?
Stały kształt sprawia, że każda paczka ma ten sam rozmiar i strukturę, niezależnie od tego, co przenosi. Każda paczka publikuje dokładnie cztery nullifiery i cztery zobowiązania; nieużywane sloty to noty fikcyjne o zerowej wartości, a wyjście reszty jest publikowane nawet wtedy, gdy jego wartość wynosi zero, ponieważ brak wyjścia reszty wyróżniałby transakcję. Pierwotna specyfikacja zakładała 2 wejścia–2 wyjścia, na wzór Sapling. Poszerzono ją do 4 wejść–4 wyjść wraz z paczką ukrytego aktywa, tak aby sloty 0–1 przenosiły aktywo prywatne, a sloty 2–3 RAND na opłatę; cztery sloty zamiast trzech pozwalają, by transfer tokena pokrył swoją opłatę z maksymalnie dwóch not RAND.
Źródło: docs/shielded.md §2; docs/superpowers/specs/2026-09-19-hidden-asset-bundle-design.md §3
13. Dlaczego jeden dowód przenosi dowolne aktywo (RAND, zUSD, tokeny RPL)?
Przed łańcuchem 14 transfer tokena zawierał dwa pakiety, jeden dla opłaty w RAND i jeden dla aktywa, co wymagało dwóch dowodów i ujawniało każdemu obserwatorowi, który token został przesłany. Guest z ukrytym aktywem przyjmuje identyfikator aktywa jako wejście prywatne, dlatego transfer zUSD jest nieodróżnialny od płatności w RAND. Guest mieści się w tierze 14 (około 100 s i 5,7 GB pamięci) tylko dlatego, że odczytuje swoje wejścia w pętli i łączy sprawdzenie przynależności do drzewa Merkle’a w jedną operację; w pełni rozwinięta implementacja wymaga tieru 16 (około 400 s i 21 GB), co przekracza pamięć maszyny z 16 GB.
Źródło: docs/superpowers/specs/2026-09-19-hidden-asset-bundle-design.md §1–3
14. Dlaczego opłata jest jawna i trafia do proposera?
Jawna opłata jest spójna z jawnym rejestrem stawek i sprawia, że przyjęcie transakcji jest tanie: węzeł może sprawdzić dolny próg opłaty, zanim wykona jakąkolwiek weryfikację. Dowód pakietu wymusza równanie bilansu Σ wejść = Σ wyjść + opłata + spalenie, więc opłata jest pokrywana z ukrytych not bez ujawniania, których. Zaakceptowanym kosztem jest to, że kwota opłaty może ujawniać klasę transakcji (transfer lub wywołanie programu).
Źródło: docs/superpowers/specs/2026-09-11-shielded-pool-design.md (tabela rozstrzygnięć); docs/fees.md §1
15. Dlaczego depozyty (mint, bridge attest) mają jawną kwotę?
Wartość wchodząca do puli musi być jawnie rozliczona, a poświadczenie mostu jest publicznym dowodem, że w łańcuchu źródłowym nastąpiła odpowiadająca mu blokada. Wynikająca z tego widoczność ogranicza się do kroku wejścia, analogicznie do transakcji z adresu jawnego do osłoniętego (t-to-z) w Zcash; kolejne wydatki zdeponowanej noty są ukryte.
Źródło: docs/superpowers/specs/2026-09-11-shielded-pool-design.md; docs/shielded.md (tabela tego, co jest jawne)
16. Dlaczego memo to pole o stałej długości 512 bajtów?
Pole o stałej długości sprawia, że księga nie ujawnia, czy memo jest obecne ani jak jest długie: w łańcuchu z włączonym memo każda koperta tworząca notę, w tym atrapy i reszta, ma dokładnie 1860 bajtów. Memo jest przenoszone wyłącznie wewnątrz zaszyfrowanej koperty, nigdy w nocie, zobowiązaniu ani dowodzie, i mogą je odczytać dokładnie te strony, które już teraz potrafią odszyfrować notę. Memo o nieprawidłowym formacie jest dekodowane jako puste, aby nie mogło uczynić samej noty nieodzyskiwalną.
Źródło: docs/shielded.md §2; docs/superpowers/specs/2026-09-26-address-sharing-and-memo-design.md
17. Dlaczego dowodzenie jest lokalne i jak delegowany prover tego nie psuje?
Sam dowód jest autoryzacją wydatku: pakiet nie zawiera podpisu ani pola nadawcy, więc klucz wydatkowania nigdy nie musi opuszczać portfela. Dowód pakietu w tierze 14 wymaga około 5,7 GB pamięci, co przekracza możliwości telefonów i przeglądarek, stąd delegowany prover. Podzielona autoryzacja (guest pakietu v3, parametr genezy hc_auth) rozdziela te dwie role: prover otrzymuje wyłącznie klucz podglądu nk i wytwarza dowód pakietu, natomiast portfel wytwarza niewielki dowód autoryzacji w tierze 10 przy użyciu sk. Prover może więc skonstruować dowód pakietu, ale nie może autoryzować wydatku (pytanie 36).
Źródło: docs/prover.md §1; docs/shielded.md (podzielona autoryzacja); docs/superpowers/specs/2026-09-28-delegated-proving-design.md
18. Dlaczego okno kotwicy wynosi 256 bloków?
Dowód jest konstruowany względem określonego korzenia drzewa zobowiązań (jego kotwicy), a skonstruowanie dowodu pakietu w tierze 14 trwa około 100 s. Księga musi zatem akceptować kotwice, które w chwili przesłania mają kilka minut. W pierwotnej specyfikacji okno wynosiło 64 bloki i zostało poszerzone do 256 bloków wraz ze skracaniem interwału między blokami, tak aby jego czas trwania w czasie rzeczywistym pozostawał dłuższy niż czas dowodzenia.
Źródło: docs/shielded.md; docs/superpowers/specs/2026-09-11-shielded-pool-design.md
zkVM i obliczenia poufne
19. Dlaczego RV32I jako ISA gościa (a nie RV64)?
Słowo 32-bitowe rozkłada się dokładnie na cztery bajtowe człony, a liczba pierwsza Goldilocks p = 2^64 − 2^32 + 1 jest na tyle duża, że iloczyn dwóch wartości 32-bitowych nigdy nie przepełnia ciała. RV64 podwoiłby liczbę kolumn członów w tabelach ALU i pamięci. RISC-V jest ponadto istniejącym celem powszechnie używanych kompilatorów, więc programy guest są zwykłymi skompilowanymi plikami binarnymi, a nie programami w języku zaprojektowanym specjalnie na ten cel.
Źródło: docs/zkvm.md §2; research/docs/01-isa.md (‘Why RV32, not RV64’)
20. Dlaczego Goldilocks, a nie ciało 256-bitowe?
Goldilocks to liczba pierwsza 64-bitowa, której arytmetyka dobrze odwzorowuje się na natywne 64-bitowe instrukcje procesora i której grupa multiplikatywna ma dużą podgrupę rzędu będącego potęgą dwójki, jak tego wymaga FRI. Razem ze słowami 32-bitowymi sprawia to, że każdy wiersz śladu jest wąski, co czyni dowodzenie w profilu produkcyjnym wykonalnym na laptopie. Bezpieczeństwo (soundness) utracone przez pracę w małym ciele jest odzyskiwane przez losowanie wyzwań FRI z ciała rozszerzonego.
Źródło: docs/zkvm.md §2; randprotocol.org (sekcja o wydajności)
21. Dlaczego tiery gazu zamiast pomiaru gazu dla każdego opkodu?
Gaz dla każdego opkodu istnieje w Ethereum, ponieważ każdy węzeł ponownie wykonuje każdą transakcję, a długość wykonania nie jest z góry ograniczona. W Rand żaden węzeł nie wykonuje programu: nadawca wykonuje go jednorazowo, poza łańcuchem, a węzły weryfikują pojedynczy STARK, którego koszt weryfikacji zależy wyłącznie od tieru, a nie od wykonanych obliczeń. Zakończenie jest wymuszane przez tier, ponieważ wykonanie, które nie zatrzymuje się w ciągu 2^t cykli, nie dopuszcza dowodu w tierze t. Wycena składa się ze stałego progu oraz oszacowania gazu ograniczonego przez nagłówek, a pojemność bloku jest budżetem w bajtach. Gaz pojawia się wyłącznie wewnątrz guestów interpretera EVM i sBPF, jako stan prywatny, gdzie jest potrzebny do odtworzenia semantyki łańcucha źródłowego.
Źródło: docs/fees.md §3–4; docs/superpowers/specs/2026-09-28-gas-model-design.md
22. Dlaczego ślad jest podzielony na dziewięć tabel połączonych szynami LogUp?
Pojedyncza monolityczna tabela dopełniałaby każdy wiersz do szerokości najszerszej operacji. Rozdzielenie śladu na dziewięć tabel — CPU, pamięć, ALU, zakresów, półbajtów (nibble), Poseidon2, programu, wejścia i publiczną — z których każda jest dopełniana tylko do własnej wysokości, utrzymuje mały łączny rozmiar śladu. Argumenty LogUp ustanawiają relacje multizbiorów między tabelami. Tabele Keccak i SHA-256 są opcjonalne i są dołączane tylko wtedy, gdy guest wywołuje odpowiednie wywołanie systemowe.
Źródło: docs/zkvm.md §5
23. Dlaczego wywołanie programu publikuje tylko osiem słów wyjścia?
Wywołanie programu jest dowodem, że publiczny kod został poprawnie wykonany na prywatnych wejściach; księga zapisuje wyłącznie pokwitowanie. Osiem 32-bitowych słów wystarcza do związania wyniku, zobowiązania lub decyzji, a stały rozmiar wyjścia sprawia, że kształt pokwitowania nie ujawnia nic o programie. Wyjścia są obecnie wyłącznie danymi: program nie może sam przenosić wartości.
Źródło: randprotocol.org/usecases (uwaga o platformie); docs/confidential.md
24. Dlaczego istnieje koperta wejść wywołania?
Wywołujący, który zachowuje prywatne wejścia, może później wykazać, na czym wywołanie zostało obliczone. Koperta wejść wywołania czyni to trwałym, przechowując wejścia w postaci zaszyfrowanej obok wywołania, gdzie wyznaczony audytor może je odszyfrować kluczem. Rozszerza to selektywne ujawnianie — poufne dla rynku, jawne dla wyznaczonego regulatora — z płatności na wykonywanie programów.
Źródło: docs/confidential.md (‘Call input envelopes’)
25. Dlaczego zmiana zbioru ograniczeń jest hard forkiem?
Każdy węzeł ponownie weryfikuje każdy dowód podczas synchronizacji, a dowód jest ważny wyłącznie względem zbioru ograniczeń (AIR), przy którym został wytworzony. Zmiana AIR zmienia więc zbiór ważnych łańcuchów i jest wprowadzana przy cięciu genezy, a nie przyjmowana węzeł po węźle.
Źródło: docs/architecture.md (‘Why a constraint-set change is a hard fork’)
26. Dlaczego wzorcem jest emulator, a nie AIR?
Emulator jest czytelną specyfikacją maszyny, a AIR jest kodowaniem tej specyfikacji w postaci ograniczeń wielomianowych. Tam, gdzie oba się rozchodzą, błąd z definicji leży po stronie AIR. Umieszcza to definicję normatywną w artefakcie, który jest dla człowieka najpraktyczniejszy do audytu.
Źródło: docs/zkvm.md §5
Konsensus i węzeł
27. Dlaczego łańcuchowy HotStuff BFT?
Łańcuchowy HotStuff zapewnia deterministyczną finalność: przy kworach ważonych stawką, obejmujących ponad dwie trzecie, blok jest finalny, gdy nad nim powstały trzy kolejne certyfikaty kworum, a blok finalny nigdy nie jest reorganizowany. Zmierzony interwał między blokami wynosi 1,2 s, a czas do finalności około 3,6 s. Docelowi użytkownicy instytucjonalni wymagają finalności rozliczenia, względem której mogą księgować zapisy, a łańcuch z finalnością probabilistyczną jej nie zapewnia.
Źródło: README fullnode; randprotocol.org (sekcja o wydajności); docs/architecture.md §6
28. Dlaczego weryfikacja dowodów odbywa się poza pętlą konsensusu?
Węzeł weryfikuje każdy STARK w chwili przyjmowania transakcji (około 32 ms przy rozgrzanej pamięci podręcznej), przed jej przekazaniem dalej, dzięki czemu weryfikacja nigdy nie leży na ścieżce krytycznej proponowania bloku. Interwał między blokami wyznacza zatem opóźnienie konsensusu, a nie rozmiar dowodu. Kontrole są uporządkowane według kosztu, a STARK jest weryfikowany jako ostatni, tak aby nieprawidłowo sformułowana transakcja została odrzucona przed najkosztowniejszym krokiem.
Źródło: randprotocol.org; docs/architecture.md (‘How it works’)
29. Dlaczego rejestr walidatorów jest jawny, skoro wszystko inne jest osłonięte?
Wszystkie repliki muszą zgadzać się co do tego, którzy walidatorzy mogą proponować bloki i które głosy stanowią kworum, co wymaga, aby wagi stawek były jawne. Rejestr przechowuje zatem kwoty stawek jawnie. Powiązanie z własnością pozostaje ukryte: depozyt stawki jest finansowany z osłoniętej noty, a wypłata trafia do takiej noty, i żadna z tych operacji nie ujawnia, czyja to nota.
Źródło: docs/staking.md §1
30. Dlaczego synchronizujący się węzeł ponownie wykonuje każdy blok zamiast ufać certyfikatom?
Węzeł, który dołącza do sieci z opóźnieniem, weryfikuje każdy quorum certificate, ponownie weryfikuje każdy bundle oraz każdy dowód wywołania i porównuje uzyskane potwierdzenia (receipts), zanim zaakceptuje łańcuch. Ponieważ poprawność jest ustalana przez dowody, a nie wyłącznie przez podpisy, ta procedura nie jest podatna na ataki typu long-range, które dotyczą łańcuchów zabezpieczonych wyłącznie podpisami. Usunięcie dowodów z historii odrzucono, ponieważ pozbawiłoby to łańcuch tej gwarancji.
Źródło: docs/architecture.md; docs/aggregation.md (wstęp)
31. Dlaczego utrzymywać limit bloku na poziomie 4 MiB, skoro dowód ma ponad 1 MB?
Przy stałym limicie rozmiar bloku nie może rosnąć; gdy popyt przekracza przepustowość, ograniczana jest przepustowość (do trzech chronionych transferów na blok w profilu 80 zapytań). Ograniczenie przepustowości uznano za bezpieczniejszy tryb awarii niż nieograniczony wzrost bloków. Wybranym rozwiązaniem jest agregacja na poziomie bloku, czyli jeden rekurencyjny dowód na blok, a nie podniesienie limitu ani obniżenie poziomu bezpieczeństwa (soundness).
Źródło: docs/block-space.md §1, §6
32. Dlaczego testnet przycina historię do jednego dnia?
Quorum certificate zawierający 18 podpisów Dilithium2 ma około 44 KB i jest zapisywany dwukrotnie na każdy blok. Przy przeważnie pustych blokach co 1,4 s dawało to około 6,6 GB na węzeł dziennie; dyski węzłów się zapełniły, a łańcuch utracił kworum na wysokości 248 953. Pełne węzły testnet przechowują teraz jeden dzień historii, pojedynczy węzeł archiwalny przechowuje ją w całości, a węzły mainnet będą przechowywać całą historię. Stan księgi — drzewo, zbiór nullifierów, rejestr i programy — nigdy nie jest przycinany.
Źródło: docs/superpowers/specs/2026-09-24-history-pruning-design.md
33. Dlaczego libp2p?
Węzeł używa TCP z Noise i Yamux, gossipsub do transakcji i głosów, Kademlia z listą bootstrap do wykrywania peerów, mDNS w sieciach lokalnych oraz request-response do synchronizacji bloków. Są to standardowe, szeroko wdrożone komponenty, dzięki czemu węzeł dziedziczy ocenę peerów, ponowne łączenie i aktualizacje transportu, zamiast utrzymywać własne implementacje.
Źródło: fullnode README (wiersz dotyczący sieci)
Rynek dowodów i agregacja
34. Dlaczego agregacja dowodów na poziomie bloku?
Przestrzeń bloku rośnie liniowo wraz z liczbą bundle, jeśli każdy niesie własny dowód o rozmiarze około 1,3 MB. Pojedynczy rekurencyjny STARK na blok, weryfikujący wszystkie N dowodów bundle, utrzymuje koszt dowodu w łańcuchu na stałym poziomie względem N. Validatorzy weryfikują wówczas jeden dowód zagregowany (około 16 ms przy rozgrzanej pamięci podręcznej) na CPU, więc walidacja nadal jest możliwa na standardowym sprzęcie, natomiast agregatory z GPU konkurują na osobnym, otwartym rynku o udział w opłatach przeznaczony na proving oraz o subsydium blokowe.
Źródło: docs/aggregation.md §1
35. Dlaczego trzy role — validator, agregator, delegowany prover?
Te trzy role mają różne wymagania sprzętowe i są opłacane przez różne podmioty. Validator porządkuje i weryfikuje transakcje na CPU i jest opłacany z udziału w opłatach przeznaczonego na weryfikację. Agregator tworzy rekurencyjny dowód bloku na GPU i jest opłacany z udziału przeznaczonego na proving oraz z subsydium. Delegowany prover tworzy pojedynczy dowód bundle dla nadawcy, którego urządzenie tego nie potrafi (telefon lub przeglądarka), i jest opłacany prywatnie przez tego nadawcę. Rozdzielenie ról utrzymuje niski koszt walidacji i sprawia, że proving staje się konkurencyjny.
Źródło: docs/prover.md §1
36. Dlaczego delegowany prover nie może ukraść środków?
W ramach podzielonej autoryzacji prover otrzymuje klucz podglądu nk, ale nie klucz wydawania sk. Dowód bundle zobowiązuje się do c = H(AUTH, nk || salt), a oddzielny dowód autoryzacji portfela wykazuje znajomość sk dla tego samego c. Bez sk prover może obliczyć dowód bundle, ale nie może wytworzyć prawidłowej autoryzacji, a portfel weryfikuje zwrócony dowód przed jego przesłaniem.
Źródło: docs/shielded.md (podzielona autoryzacja); docs/prover.md §8
Most i zUSD
37. Dlaczego blokować USDT/USDC w ich macierzystych łańcuchach zamiast emitować nowy stablecoin?
Natywna emisja w Rand uzależniłaby pojemność rezerw od decyzji wdrożeniowych emitentów, które pozostają poza kontrolą projektu. Blokowanie USDT i USDC w Ethereum, BSC, Tron i Solana czerpie rezerwy z łańcuchów, w których te aktywa już krążą, i nie wprowadza nowego emitenta: każda jednostka zUSD jest roszczeniem do USDT lub USDC przechowywanych w publicznie czytelnym kontrakcie powierniczym.
Źródło: randprotocol.org (sekcja o rezerwach)
38. Dlaczego zbiór strażników t-z-n i dlaczego mówić o tym wprost?
Attestation jest jedynym dowodem, jakim dysponuje Rand, że blokada nastąpiła w innym łańcuchu, dlatego musi być podpisana przez grupę progową; prawidłowy attestation wymaga podpisów więcej niż dwóch trzecich strażników. Wynikające z tego założenie zaufania jest podane jawnie. Faktyczną gwarancją jest słabsza z dwóch: wypłacalność rezerw i integralność mostu; koalicja t strażników może autoryzować mintowanie bez odpowiadającej mu blokady; a ekspozycja jest ograniczona wartością depozytów przechowywanych w każdym łańcuchu. To założenie było pierwotnie argumentem przeciwko budowie mostu. Nie zostało wycofane, lecz przyjęte w zamian za pojemność rezerw.
Źródło: randprotocol.org (sekcja o rezerwach, ‘Ile to kosztuje’)
39. Dlaczego współpodpis Dilithium2 obok attestation ECDSA?
Łańcuchy źródłowe nie udostępniają weryfikatora podpisów kratowych, więc wypłaty w tych łańcuchach pozostają zabezpieczone klasycznym ECDSA, a ekspozycja jest ograniczona wartością depozytów i limitami. Każda wiadomość, którą księga Rand przyjmuje od strażników — depozyty i rotacje zbioru strażników — musi dodatkowo zawierać kworum podpisów Dilithium2 od tych samych strażników. Ścieżka mintowania jest zatem odporna na ataki kwantowe, choć zewnętrzne punkty końcowe nie są. Współpodpisy są przesyłane razem z attestation i nie wymagają zmian we wdrożonych kontraktach.
Źródło: docs/superpowers/specs/2026-09-19-pq-cosignature-bridge.md §1
40. Dlaczego blinding noty depozytowej jest wyprowadzany, a nie wybierany?
Wcześniej zobowiązanie noty depozytowej nie było określone, dopóki relayer nie przesłał attestation, więc dwóch relayerów mogło przesłać ten sam attestation z różnymi notami. Deterministyczne wyprowadzenie czynnika blinding r z attestation ustala zobowiązanie, dzięki czemu konkurujące zgłoszenia kolidują na jednym zobowiązaniu, a depozyt nie może zostać wymintowany dwukrotnie.
Źródło: docs/bridge.md (F1, chain 14)
41. Dlaczego USDT zablokowany w Tron może zostać wypłacony jako USDT w Ethereum?
zUSD jest fungible: każda jednostka jest roszczeniem do zagregowanej rezerwy, a nie do łańcucha, przez który weszła. Rozdzielenie wejścia od wyjścia pozwala płynności przemieszczać się tam, gdzie jest na nią popyt, pod warunkiem że łańcuch docelowy dysponuje wystarczającymi rezerwami. Artykuł o stablecoinie dowodzi, że niezmiennik S ≤ Σ_c R_c, czyli całkowita podaż ograniczona sumą rezerw w poszczególnych łańcuchach, jest zachowywany przez każde przejście stanu.
Źródło: randprotocol.org (sekcja o rezerwach)
42. Dlaczego shielding ukrywa rozkład, ale nie ilość?
Całkowita podaż zUSD jest publiczna w rejestrze tokenów, a rezerwa każdego łańcucha jest publicznym saldem, więc wypłacalność może zweryfikować każdy; ukryty jest rozkład środków między właścicielami. Obowiązuje jedno ograniczenie: czterech sald rezerw nie można zaobserwować atomowo w jednej chwili, więc dla tych łańcuchów kontrola wykrywa niewypłacalność po fakcie, zamiast jej zapobiegać.
Źródło: randprotocol.org (sekcja o rezerwach)
43. Dlaczego spalenie (burn) jest jedyną transakcją, która wskazuje swoje aktywo?
Spalenie zwalnia konkretne aktywo w konkretnym łańcuchu, więc kontrakt powierniczy musi się dowiedzieć, jakie to aktywo i jaki łańcuch. Każda inna transakcja przenosi aktywo niezidentyfikowane. Spalenie niesie też opłatę mostu, ponieważ jest jedyną transakcją mostu, w której nadawca jest beneficjentem.
Źródło: docs/architecture.md; docs/shielded.md §2
Zgodność i ujawnianie
44. Dlaczego klucze podglądu, a nie „prywatność przed wszystkimi”?
Regulatorzy nie zaakceptowali systemów prywatności, w których ujawnienie zależy od współpracy strony objętej postępowaniem, o czym świadczy przypadek Tornado Cash. Rand traktuje więc ujawnianie jako obiekt protokołu. Posiadacz lub regulowany pośrednik zachowuje klucz podglądu; audytor może odszyfrować transakcje wskazane w zgodnym z prawem wniosku; a celem projektowym są klucze o ograniczonym zakresie, które ujawniają kontrahenta i kwotę, nie ujawniając strategii handlowej. W zastosowaniach takich jak wypłaty wynagrodzeń ta audytowalność jest wymogiem, a nie ograniczeniem.
Źródło: randprotocol.org/usecases (sekcja o regulacjach; przypadek wypłat wynagrodzeń)
45. Dlaczego wychodzący klucz podglądu jest oddzielony od przychodzącego?
Rozdzielenie pozwala nadawcy udowodnić, co zapłacił, bez uzyskiwania dostępu do historii odbiorcy, i odwrotnie. Wychodzący klucz podglądu ovk odszyfrowuje koperty (envelopes) wysłane przez portfel; klucz dekapsulacji ML-KEM odszyfrowuje koperty wysłane do niego; a klucz dla pojedynczej transakcji ujawnia stronie trzeciej dokładnie jedno wyjście.
Źródło: docs/shielded.md §1–2
Znane ograniczenia
46. Co dowody ujawniają dziś i dlaczego jest to udokumentowane?
Przegląd z 2026-09-27 wykazał, że w guest v1 (chains 14–15) każdy dowód bundle ujawnia, które sloty wejściowe zawierają prawdziwe noty, oraz wagę Hamminga indeksu każdego wydanego liścia. Przyczyny są dwie: sumy LogUp dla poszczególnych tabel są publikowane bez blindingu, a przepływ sterowania guesta rozgałęzia się zależnie od tego, czy wejście jest atrapą (dummy). Remedium stanowi guest bez rozgałęzień (v2), który zostanie wybrany przy następnym genesis. Ustalenie jest publikowane, ponieważ sieć jest testnet, a dokumentacja służy jako jej zapis audytowy.
Źródło: docs/shielded.md (‘Co dowody ujawniają dziś’)
47. Dlaczego wzrost stanu jest niedoszacowany cenowo?
Ethereum wycenia zapisy do pamięci trwałej, ponieważ przechowywany stan nakłada trwały koszt na każdy węzeł. Rand wycenia obecnie wzrost drzewa zobowiązań, zbioru nullifierów i pamięci programów wyłącznie za pomocą opłaty za słowo przy wdrożeniu oraz stałej opłaty za pakiet. Jest to wystarczające dla testnet, ale pozostaje zapisane jako otwarte pytanie dotyczące wyceny, które należy rozstrzygnąć przed mainnet; jego rozstrzygnięcie nie wymaga pomiaru kosztów dla poszczególnych kodów operacji.
Źródło: docs/fees.md §3 (zastrzeżenia)
48. Dlaczego nie ukończono jeszcze niezależnego audytu?
Protokół jest w trakcie aktywnego rozwoju w sieci testnet obsługiwanej przez zespół, a przed ustabilizowaniem się projektu spodziewane są kolejne zestawy ograniczeń i kolejne wersje łańcucha. Strona internetowa informuje o tym na każdej podstronie. Wewnętrzne rundy audytu (v3–v5) są opublikowane w docs/consensus.md oraz w specyfikacjach projektu, tak aby ewentualny zewnętrzny audyt dysponował kompletnym zapisem, na którym może się oprzeć.
Źródło: randprotocol.org (stopka); docs/consensus.md