Opłaty

Ta strona służy do ustawiania opłaty za transakcję, szacowania kosztu wdrożenia lub wywołania programu i zrozumienia, ile otrzymuje walidator. Opłaty są dolnymi progami wyrażonymi w RAND. Każda akcja poza wywołaniem (call) płaci stałą kwotę. Na chain 20 wywołanie płaci za limit gazu, który deklaruje jego dowód, oraz za swoje bajty, po cenach zmieniających się wraz z zapełnieniem bloków i ograniczonych pułapem.

Dolne progi

Opłaty są wyrażone w jednostkach 10⁻⁹ RAND. Stałe znajdują się w randprotocol_core::gas:

Opłata jest publicznym słowem pakietu i zawsze jest w RAND. Guest pakietu ukrytych aktywów wiąże ją z relacją bilansu grupy RAND in₂ + in₃ = out₂ + out₃ + fee + burn_r (sloty 2–3), więc jest płacona z ukrytych not bez ujawniania, z których; token porusza się przez sloty 0–1 tego samego pakietu według własnej relacji, in₀ + in₁ = out₀ + out₁ + burn_a. Jeden dowód przenosi zatem token i płaci opłatę w RAND, a portfel trzymający token, ale niemający RAND do wydania, jest odrzucany przed wygenerowaniem dowodu.

Opłata mostu obciąża spalenie, ponieważ jest to jedyna transakcja mostu, której nadawca na pewno trzyma RAND; depozyt płaci tylko podstawę, bo deponent nie ma jeszcze RAND. Opłata rejestracyjna jest faktem księgi, a nie częścią fee_floor, więc jest sprawdzana według własnych reguł akcji (RegistrationFeeTooLow), tak jak część wywołania zależna od gazu lub tieru jest naliczana po zdekodowaniu jego dowodu. Dolny próg wywołania jest sprawdzany dwukrotnie, ponieważ to, co wywołanie deklaruje, zasługuje na zaufanie dopiero po weryfikacji jego dowodu. Na chain 20 pierwsze sprawdzenie, przed jakąkolwiek weryfikacją, wycenia bajty wywołania i zadeklarowany limit równy 1 (Invoke jest tam też winien swoją opłatę za komórki); drugie wycenia limit zadeklarowany przez zweryfikowany dowód. Na łańcuchu bez sekcji gas są to BUNDLE_BASE + CALL_BASE oraz dokładny dolny próg tieru.

Zamiast zgadywać, zapytaj węzeł:

rand fee bundle          # 0.001 RAND
rand fee deploy 256      # 0.0266 RAND
rand fee call 14 --gas 20479 --bytes 1350000   # 0.0041 RAND at chain 20's starting prices

→ {"method":"rand_estimateFee","params":[{"kind":"call","tier":14,"gas":20479,"bytes":1350000}]}
← "4103100"

Ta odpowiedź to 1,000,000 + 100 × 20,479 + 800 × 1,319 przy cenach początkowych; węzeł wycenia według cen aktualnego końca łańcucha w chwili zapytania. Na chain 20 pole gas specyfikacji wywołania jest wymagane w JSON-RPC (-32602 bez niego). rand fee call <tier> bez --gas wysyła pułap tieru, a bez --bytes nie wycenia żadnych bajtów. Invoke jest wyceniany tak samo, z "kind":"invoke" i "created_cells": c, co dodaje c opłat za komórki (24103100 dla powyższego przykładu z dwiema komórkami, zapytanie do chain 20 w dniu 2026-10-01). Na chain 15, który nie miał sekcji gas, rand fee call 14 odpowiadało 0.0022 RAND.

Domyślne kwoty portfela są dokładnie równe dolnym progom, z wyjątkiem wywołania na chain 20, którego wartość domyślna dodaje zapas (niżej); rand send --fee <RAND> oraz flaga --fee przy bond, call, bridge-mint, bridge-burn (domyślnie 0.01) i podpolecenia token podnoszą je. Wszystko ponad dolny próg jest napiwkiem.

Gas na chain 18

Chain 18, działający od 2026-09-29 do 2026-10-01, był pierwszym łańcuchem z pomiarem gazu, a chain 19, jego re-genesis na tej samej wersji, miał tę samą sekcję gas. Chain 20 (v0.6.8) zachowuje wszystkie reguły tej sekcji i dodaje dwa pułapy cen oraz obciążenie bajtami liczone tylko od bajtów, które płacą (niżej). Łańcuch bez sekcji gas zachowuje harmonogram tierów z powyższej tabeli.

Co jest liczone. Jeden gas to jeden wiersz tabeli cpu zkVM, więc zwykła instrukcja kosztuje 1. Jedynymi innymi kosztami są syscalle:

Zadeklarowany limit. Dowód wywołania niesie jedną wartość publiczną więcej niż wcześniej, GAS_LIMIT, a obwód (zbiór ograniczeń 8) dowodzi, że gas przebiegu jest co najwyżej równy limitowi. Dokładny gas pozostaje prywatny. Limit powyżej pułapu własnego nagłówka dowodu jest odrzucany, zanim zbudowany zostanie jakikolwiek klucz weryfikatora:

gas_max = (2ᵗ − 1) + 2^(t−2) + 191 × (keccak rows / 32) + 63 × (sha256 rows / 64)

To daje 1,279 dla tieru 10, 5,119 dla tieru 12 i 20,479 dla tieru 14 w przypadku wywołania, które nie używa żadnej z tabel haszowania.

Dolny próg. Księga pobiera zadeklarowany limit i bajty po cenach obowiązujących na początku bloku:

fee ≥ BUNDLE_BASE + gas_price × gas_limit + byte_price × ⌈bytes / 1024⌉

bytes to dowód wywołania plus koperta wejścia. Harmonogram tierów i jego darmowy limit nie mają na takim łańcuchu zastosowania. Pula żąda dokładnie tego, czego blok, i odrzuca tańsze wywołanie jako FeeTooLow.

Pakiety i dowód autoryzacji deklarują ustalone limity. Każdy dowód pakietu musi deklarować dokładnie genesis bundle_gas_limit, 20,479 (pułap tieru 14), inaczej transakcja jest odrzucana jako BundleGasLimit. Chain 20, jak każdy łańcuch od 17, działa z podzieloną autoryzacją, więc każdy pakiet niesie dowód autoryzacji tieru 10, który musi deklarować 1,279 (AuthGasLimit). Żadna z tych wartości nie jest opłatą: transfer, bond lub deploy nadal płaci swój stały dolny próg z powyższej tabeli. Portfel deklaruje obie wartości samodzielnie.

Ceny się zmieniają. Sekcja gas chain 20 ma kontroler dynamic, więc gas_price i byte_price są stanem księgi, zatwierdzonym w korzeniu stanu. Raz na blok, po jego transakcjach, każda z nich zmienia się zależnie od tego, jak bardzo blok był zapełniony względem celu:

price' = min(max_price, max(min_price, price + ⌊price × adjust_bps × (used − target) / (10,000 × target)⌋))

used jest ograniczone do dwukrotności celu, więc adjust_bps to największa zmiana, jaką może wprowadzić jeden blok w dowolnym kierunku. max_price to pułap genesis; chain 18 i 19 go nie miały. byte_price podąża za płacącymi bajtami bloku (niżej); gas_price podąża za sumą zadeklarowanych limitów jego wywołań i invoke’ów plus 20,479 za każdy pakiet.

Blok poniżej swoich celów obniża ceny, więc w spokojnym łańcuchu ceny stoją na dolnych granicach. rand_getLimits zwraca bieżące gas_price i byte_price z czoła łańcucha wraz z gas_metering: "circuit", bundle_gas_limit, adjust_bps, a od v0.6.8 także max_gas_price, max_byte_price i byte_load (null w łańcuchu, który ich nie ma); rand_status podaje te same dwie ceny jako gas_prices.

Górne granice cen i płatne obciążenie bajtowe

Oba mechanizmy to pola genesis w gas.dynamic, nowe w v0.6.8 (audyt v6, POOL-2); łańcuch 20 jest pierwszym, który je ustawia. Naprawiają one wadę łańcuchów 18 i 19. Tam byte_price zmieniała się wraz z zakodowaną długością każdej transakcji, a płaci ją tylko wywołanie. Siedem transferów (po około 2,85 MB, opłata stała) wypełnia blok do około 1,9 raza celu bajtowego i podnosi cenę o około 11% na blok, bez żadnej górnej granicy: około 65 takich bloków podnosi ją do 1000 razy wartości początkowej, a wywołanie kosztuje wtedy około 1 RAND zamiast około 0,004.

• Górne granice. max_gas_price i max_byte_price to ceny, powyżej których regulator nigdy ich nie podnosi. Krok jest ten sam, a następnie obcinany (gas::next_price_capped), więc cena na swojej górnej granicy zostaje tam przez dowolną serię pełnych bloków i spada w pierwszym bloku poniżej celu. Genesis musi ustawić każdą z nich na poziomie nie niższym niż cena początkowa. Przy górnych granicach łańcucha 20 powyższe wywołanie poziomu 14, 20 479 gas i 1319 KiB, ma dolną granicę opłaty 0,3113 RAND, czyli najwyższą, jaką może osiągnąć.
• Płatne obciążenie bajtowe. Przy byte_load: "paying" pole bytes_used bloku liczy tylko bajty, od których pobierana jest cena bajtowa: dowód i koperta danych wejściowych każdego Call i Invoke (gas::call_bytes), nic z transferu, bondu ani spalenia. Blok transferów nie rusza ceny bajtowej. Ledger::block_usage oblicza tę wartość zarówno dla proponenta, jak i repliki, więc obie strony się zgadzają.

Przy płatnym obciążeniu blok pełen transferów nie daje wywołaniom żadnego sygnału cenowego, więc uczciwy proponent rezerwuje też miejsce dla wywołań. To polityka węzła, nie reguła ważności: gdy w puli czeka wywołanie lub invoke płacące bieżącą dolną granicę, transakcje ze stałą opłatą zajmują w pierwszym przebiegu najwyżej trzy czwarte bajtów bloku, a to, czego wywołania nie zajmą z ostatniej ćwiartki, jest następnie wypełniane wstrzymanymi transferami (Mempool).

Ile portfel płaci za wywołanie

rand call najpierw uruchamia program w emulatorze i wypisuje gas: <exact> (declaring <limit>, tier <t>). Domyślnie deklaruje dokładny gas zaokrąglony w górę do wielokrotności 2^(tier − 2); --gas-limit N deklaruje dokładną wartość, a --gas-limit max górną granicę nagłówka.

Dwie rzeczy sprawiają, że domyślna opłata jest wyższa niż dolna granica:

• Dowód jest wyceniany według limitu. Od łańcucha 16 (hardening_v6, łącznie z łańcuchem 20) dowód wywołania jest związany z własną transakcją, więc opłata jest ustalana, zanim dowód powstanie. Portfel wycenia limit dowodu w łańcuchu, 4 MiB, zamiast rzeczywistego rozmiaru dowodu (wallet::hardened_call_quote_bytes). Może to tylko prowadzić do przepłacenia.
• Zapas na dwa kroki ceny. rand_getLimits zwraca ceny zatwierdzonego czoła łańcucha, a wywołanie trafia do bloku dwa lub trzy bloki później, więc domyślnie dolna granica jest mnożona przez (1 + adjust_bps / 10,000)², czyli 1,125² w łańcuchu 20.

Zmierzono w łańcuchu 18 dnia 2026-09-30: cztery wywołania kosztowały między 0,0057 a 0,0075 RAND każde przy tych wartościach domyślnych (Przykładowe programy). --fee zastępuje wartość domyślną; portfel ponownie wycenia rzeczywisty dowód przed wysłaniem i odrzuca opłatę niższą od jego dolnej granicy.

Dokąd trafia opłata

Cała opłata, dolna granica i napiwek, jest zapisywana na rzecz rewards proponenta bloku w rejestrze walidatorów, jedynym miejscu w tym łańcuchu, które przechowuje kwotę jawnie, z jednym wyjątkiem. W genesis z tokens.burn_registration_fee (łańcuch 20, jak każdy łańcuch od 15) registration_fee z RegisterToken lub RegisterBridgedToken jest spalane, a proponent zachowuje fee − registration_fee; rand_getSupply zlicza ją w registration_fees_burned. W łańcuchu 14, który nie miał tej flagi, proponent zachowywał całą opłatę. Nic poza tym nie jest spalane i nie ma żadnego podziału. Walidator zamienia zgromadzone nagrody w notatkę poleceniem rand-node withdraw (Staking). Opłata za komórkę w invoke jest częścią opłaty za jego bundle i trafia do proponenta razem z resztą. W łańcuchu 20 nie ma nagród blokowych ani inflacji: opłaty stanowią cały dochód walidatora.

Jedna opłata w łańcuchu 20 nie jest w RAND i nie trafia do żadnego walidatora. Zgodnie z genesis bridge.fees (nowość w v0.6.8) most zatrzymuje 10 bps z każdego depozytu zUSD i z każdego spalenia zUSD, zaokrąglone w dół do pełnej jednostki wypłaty zabezpieczenia, jako notatkę zUSD na adres skarbca wskazany w genesis. Depozyt uznaje deponenta kwotą brutto pomniejszoną o opłatę; spalenie zwalnia amount − fee w łańcuchu źródłowym. Notatka z opłatą pozostaje wyemitowana i zabezpieczona. Zob. Most i Tokeny RPL.

Mempool porządkuje kandydatów według tego, ile płacą ponad swoją dolną granicę na KiB, a następnie według opłaty (Mempool), więc wyższa opłata ma znaczenie tylko przy zatorze. Transfer to około 2,85 MB (zmierzone w łańcuchu 18): dowód bundle 1,49 MB i dowód autoryzacji 1,36 MB, więc w bloku łańcucha 20 o wielkości 20 MiB mieści się ich około siedmiu. Własna uwaga fullnode’a głosiła, że rynek opłat oparty na bajtach, a nie na opkodach, jest tym, czym dolna granica powinna się stać przed mainnet-beta. Cena bajtowa łańcucha 20 jest takim rynkiem dla wywołań, poruszanym wyłącznie przez bajty, za które płacą wywołania; dolna granica transferu jest nadal stała.

Dlaczego gas jest tu ceną, a nie ograniczeniem

Ethereum mierzy każdy opkod, ponieważ każdy węzeł wykonuje każdą transakcję, a wykonanie jest nieograniczone. W Rand żaden węzeł niczego nie wykonuje: nadawca uruchamia program raz, poza łańcuchem, i przekazuje łańcuchowi dowód. Praca węzła przy transakcji to stały ciąg kroków: zdekodować pola publiczne, wykonać bezpłatne kontrole, zweryfikować jeden STARK, a ta weryfikacja trwa około 16 ms z rozgrzanym kluczem weryfikatora, bez względu na to, co robił program. Trzy zadania gazu rozpadają się więc na osobne sprawy:

• Zakończenie wymusza poziom: przebieg, który nie zatrzyma się w ciągu 2ᵗ − 1 cykli, w ogóle nie może zostać udowodniony, a koszt tej porażki ponosi prover.
• Wycena pracy to zadanie dolnej granicy gazu, od łańcucha 18. Koszt sieci na instrukcję jest bliski zeru, ale praca dowodząca nadawcy jest realna, a stała dolna granica wyceniała wywołanie na milion cykli tak samo jak na tysiąc. Do łańcucha 18 dolna granica była stała dla poziomu.
• Wymiarowanie bloku to budżet bajtowy (MAX_BLOCK_BYTES = domyślnie 4 MiB, w przeciwnym razie max_block_bytes z genesis) i liczba transakcji (2000).

Dwa zastrzeżenia, które fullnode formułuje wprost: bajty jednak się różnią (dowód ma ponad megabajt, więc rzadkim zasobem jest miejsce w bloku, a nie obliczenia), a przyrost stanu, czyli drzewo, zbiór nullifierów i bajty wdrożonych programów, jest wyceniany tylko opłatą za słowo przy wdrożeniu i stałą opłatą bazową, co wystarcza dla testnet i warto do tego wrócić, gdy rozmiar stanu zacznie mieć znaczenie.

Co nadawca płaci w zamian: dowodzenie

Jedyny zmienny koszt to wytworzenie dowodu STARK i ponosi go wyłącznie maszyna nadawcy. W kolejności wpływu:

1. Poziom t ∈ {10, 12, 14, 16, 18, 20} (wywołanie powyżej 14 jest odrzucane w łańcuchu od v0.5.6; bundle jest przypięty do 14, a od łańcucha 17 niesie obok siebie dowód autoryzacji poziomu 10, czyli około 7 s więcej): tabela cpu jest dopełniana do 2ᵗ wierszy, a każdy krok mniej więcej czterokrotnie zwiększa dopełniony ślad. Zmierzone na laptopie deweloperskim: private_payment na poziomie 10 w około 7 s; guest bundle ukrytego aktywa na poziomie 14 w około 100 s, niezależnie od tego, które aktywo przenosi.
2. Wykonane cykle, ponieważ decydują o poziomie: liczą się instrukcje uruchomione, a nie napisane.
3. Rozmiar programu, słabo: jeden wiersz skrótu na cztery słowa na początku śladu.
4. Rozmiar danych prywatnych, w ten sam sposób.
5. Które tabele są obecne: tabela keccak lub sha256 kosztuje udział swoich kolumn tylko wtedy, gdy guest jej użył.
6. Profil FRI: 80 zapytań zamiast 27 potraja rozmiar dowodu, ale prawie nie zmienia czasu dowodzenia.

Dowodzenie nie zależy od kwot, od liczby notatek, które posiada nadawca, ani od rozmiaru łańcucha: przynależność jest dowodzona względem drzewa o stałej głębokości, więc transfer kosztuje tyle samo w bloku dziesiątym, co w dziesięciomilionowym.

Reference