Gebühren

Verwenden Sie diese Seite, um die Gebühr einer Transaktion festzulegen, die Kosten eines Deploys oder eines Calls abzuschätzen und zu verstehen, was ein Validator erhält. Gebühren sind Mindestbeträge in RAND. Jede Aktion außer einem Call zahlt einen Pauschalbetrag. Auf Chain 20 zahlt ein Call für das Gas-Limit, das sein Proof deklariert, und für seine Bytes, zu Preisen, die sich mit der Auslastung der Blöcke bewegen und an einer Obergrenze enden.

Die Mindestgebühren

Gebühren werden in Einheiten von 10⁻⁹ RAND angegeben. Die Konstanten stehen in randprotocol_core::gas:

Die Gebühr ist ein öffentliches Wort des Bundles und immer in RAND. Der Bundle-Guest für verborgene Assets bindet sie in die Bilanzrelation der RAND-Gruppe in₂ + in₃ = out₂ + out₃ + fee + burn_r (Slots 2–3) ein, sodass sie aus verborgenen Notes bezahlt wird, ohne offenzulegen, aus welchen; ein Token bewegt sich über die Slots 0–1 desselben Bundles unter seiner eigenen Relation, in₀ + in₁ = out₀ + out₁ + burn_a. Ein Proof bewegt also einen Token und zahlt seine RAND-Gebühr, und ein Wallet, das einen Token, aber kein ausgebbares RAND hält, wird vor dem Beweisen abgewiesen.

Die Gebühr der Bridge fällt auf den Burn, weil dies die eine Bridge-Transaktion ist, deren Absender sicher RAND hält; eine Einzahlung zahlt nur die Basis, da der Einzahler noch kein RAND hat. Die Registrierungsgebühr ist eine Tatsache des Ledgers und kein Teil von fee_floor, daher wird sie nach den eigenen Regeln der Aktion geprüft (RegistrationFeeTooLow), so wie der Gas- oder Tier-Anteil eines Calls erhoben wird, sobald sein Proof dekodiert ist. Die Mindestgebühr eines Calls wird zweimal geprüft, weil dem, was er deklariert, erst vertraut wird, wenn sein Proof verifiziert ist. Auf Chain 20 bepreist die erste Prüfung vor jeder Verifikation die Bytes des Calls und ein deklariertes Limit von 1 (ein Invoke schuldet dort auch seine Zellgebühr); die zweite bepreist das Limit, das der verifizierte Proof deklariert. Auf einer Chain ohne gas-Abschnitt sind die beiden BUNDLE_BASE + CALL_BASE und die Tier-genaue Mindestgebühr.

Fragen Sie den Node, statt zu raten:

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"

Diese Antwort ist 1,000,000 + 100 × 20,479 + 800 × 1,319 zu den Startpreisen; der Node bepreist, was immer die Preise an der Spitze sind, wenn er gefragt wird. Auf Chain 20 ist das Feld gas der Call-Spezifikation über JSON-RPC erforderlich (-32602 ohne es). rand fee call <tier> ohne --gas sendet die Obergrenze des Tiers, und ohne --bytes bepreist es keine Bytes. Ein Invoke wird genauso bepreist, mit "kind":"invoke" und "created_cells": c, was c Zellgebühren hinzufügt (24103100 für das obige Beispiel mit zwei Zellen, abgefragt von Chain 20 am 2026-10-01). Auf Chain 15, die keinen gas-Abschnitt hatte, antwortete rand fee call 14 mit 0,0022 RAND.

Die Standardwerte des Wallets entsprechen genau den Mindestgebühren, außer bei einem Call auf Chain 20, dessen Standard einen Puffer aufschlägt (siehe unten); rand send --fee <RAND> und das Flag --fee bei bond, call, bridge-mint, bridge-burn (Standard 0,01) und den token-Unterbefehlen erhöhen sie. Alles oberhalb der Mindestgebühr ist ein Tip.

Gas on chain 18

Chain 18, live vom 2026-09-29 bis 2026-10-01, war die erste Chain mit Gasmessung, und Chain 19, ihr Re-Genesis auf demselben Build, trug denselben gas-Abschnitt. Chain 20 (v0.6.8) behält jede Regel dieses Abschnitts bei und ergänzt zwei Preisobergrenzen sowie eine Byte-Last, die nur auf den zahlenden Bytes gezählt wird (siehe unten). Eine Chain ohne gas-Abschnitt behält das Tier-Schema aus der Tabelle oben.

Was gezählt wird. Ein Gas ist eine Zeile der cpu-Tabelle der zkVM, sodass eine gewöhnliche Instruktion 1 kostet. Die Syscalls sind die einzigen anderen Kosten:

Das deklarierte Limit. Ein Call-Proof trägt einen öffentlichen Wert mehr als zuvor, GAS_LIMIT, und die Schaltung (Constraint-Set 8) beweist, dass das Gas des Laufs höchstens so groß ist. Das exakte Gas bleibt privat. Ein Limit oberhalb der Obergrenze des eigenen Headers des Proofs wird abgelehnt, bevor ein Verifier-Schlüssel gebaut wird:

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

Das sind 1.279 bei Tier 10, 5.119 bei Tier 12 und 20.479 bei Tier 14 für einen Call, der keine der beiden Hash-Tabellen nutzt.

Die Mindestgebühr. Das Ledger berechnet das deklarierte Limit und die Bytes zu den Preisen, die gelten, wenn der Block beginnt:

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

bytes ist der Call-Proof plus das Input-Envelope. Das Tier-Schema und sein Freibetrag gelten auf einer solchen Chain nicht. Der Pool verlangt genau das, was ein Block verlangt, und lehnt einen günstigeren Call als FeeTooLow ab.

Bundles und der Autorisierungs-Proof deklarieren festgelegte Limits. Jeder Bundle-Proof muss genau das Genesis-bundle_gas_limit deklarieren, 20.479 (die Tier-14-Obergrenze), sonst wird die Transaktion als BundleGasLimit abgelehnt. Chain 20 läuft, wie jede Chain seit 17, mit geteilter Autorisierung, sodass jedes Bundle einen Tier-10-Autorisierungs-Proof trägt, der 1.279 deklarieren muss (AuthGasLimit). Keines von beidem ist eine Gebühr: Eine Überweisung, ein Bond oder ein Deploy zahlt weiterhin seine Pauschale aus der Tabelle oben. Das Wallet deklariert beide Werte selbst.

Die Preise bewegen sich. Der gas-Abschnitt von Chain 20 hat einen dynamic-Controller, sodass gas_price und byte_price Ledger-Zustand sind, festgeschrieben in der State-Root. Einmal pro Block, nach seinen Transaktionen, bewegt sich jeder danach, wie voll der Block gegenüber einem Ziel war:

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

used ist auf das Doppelte des Ziels begrenzt, sodass adjust_bps die größte Bewegung ist, die ein Block in eine der beiden Richtungen bewirken kann. max_price ist die Genesis-Obergrenze; die Chains 18 und 19 hatten keine. byte_price folgt den zahlenden Bytes des Blocks (siehe unten); gas_price folgt der Summe der deklarierten Limits seiner Calls und Invokes plus 20.479 für jedes Bundle.

Ein Block unterhalb seiner Zielwerte senkt die Preise, sodass sie auf einer ruhigen Chain an den Untergrenzen liegen. rand_getLimits liefert die aktuellen Werte gas_price und byte_price der Chain-Spitze mit gas_metering: "circuit", bundle_gas_limit, adjust_bps sowie seit v0.6.8 max_gas_price, max_byte_price und byte_load (null bei einer Chain ohne diese Felder); rand_status meldet dieselben beiden Preise als gas_prices.

Obergrenzen und die zahlende Byte-Last

Beides sind Genesis-Felder von gas.dynamic, neu in v0.6.8 (Audit v6, POOL-2); Chain 20 ist die erste Chain, die sie setzt. Sie beheben einen Fehler, den die Chains 18 und 19 hatten. Dort bewegte sich byte_price mit der kodierten Länge jeder Transaktion, obwohl nur ein Aufruf ihn zahlt. Sieben Transfers (je etwa 2,85 MB, Pauschalgebühr) füllen einen Block auf etwa das 1,9-Fache des Byte-Ziels und heben den Preis um etwa 11 % pro Block, ohne Obergrenze: Etwa 65 solcher Blöcke bringen ihn auf das 1.000-Fache seines Startwerts, und ein Aufruf kostet dann etwa 1 RAND statt etwa 0,004.

• Obergrenzen. max_gas_price und max_byte_price sind Preise, über die der Regler nie hinaus anhebt. Der Schritt bleibt derselbe und wird dann begrenzt (gas::next_price_capped), sodass ein Preis an seiner Obergrenze bei beliebig vielen vollen Blöcken dort bleibt und im ersten Block unter dem Ziel fällt. Ein Genesis muss jeden dieser Werte auf oder über dem jeweiligen Startpreis setzen. Bei den Obergrenzen von Chain 20 hat der oben genannte Aufruf in Tier 14, 20.479 Gas und 1.319 KiB, eine Untergrenze von 0,3113 RAND, das Höchste, was seine Untergrenze erreichen kann.
• Die zahlende Byte-Last. Unter byte_load: "paying" zählt bytes_used des Blocks nur die Bytes, auf die der Byte-Preis erhoben wird: den Beweis plus den Eingabe-Umschlag jedes Call und Invoke (gas::call_bytes), nichts von einem Transfer, einer Bond oder einem Burn. Ein Block aus Transfers bewegt den Byte-Preis nicht. Ledger::block_usage berechnet den Wert für Proposer und Replikat, sodass beide übereinstimmen.

Unter der zahlenden Last gibt ein Block voller Transfers einem Aufruf kein Preissignal, daher reserviert ein ehrlicher Proposer zusätzlich Platz für Aufrufe. Das ist Node-Richtlinie, keine Gültigkeitsregel: Solange ein Call oder Invoke im Pool liegt und seine aktuelle Untergrenze zahlt, belegen Transaktionen mit Pauschalgebühr im ersten Durchgang höchstens drei Viertel der Bytes des Blocks, und was die Aufrufe vom letzten Viertel übrig lassen, wird dann mit den zurückgehaltenen Transfers gefüllt (Mempool).

Was die Wallet für einen Aufruf zahlt

rand call führt das Programm zuerst im Emulator aus und gibt gas: <exact> (declaring <limit>, tier <t>) aus. Standardmäßig deklariert es das exakte Gas, aufgerundet auf ein Vielfaches von 2^(tier − 2); --gas-limit N deklariert einen exakten Wert und --gas-limit max die Obergrenze des Headers.

Zwei Dinge machen die Standardgebühr höher als die Untergrenze:

• Der Beweis wird mit der Obergrenze bepreist. Seit Chain 16 (hardening_v6, Chain 20 eingeschlossen) ist ein Call-Beweis an seine eigene Transaktion gebunden, die Gebühr steht also fest, bevor der Beweis existiert. Die Wallet bepreist statt der echten Beweisgröße die Beweisobergrenze der Chain, 4 MiB (wallet::hardened_call_quote_bytes). Das kann nur zu viel zahlen.
• Zwei Preisschritte Spielraum. rand_getLimits liefert die Preise des bestätigten Kopfes, und ein Aufruf landet zwei oder drei Blöcke später, daher multipliziert der Standard die Untergrenze mit (1 + adjust_bps / 10,000)², das sind 1,125² in Chain 20.

Gemessen auf Chain 18 am 2026-09-30, kosteten vier Aufrufe mit diesen Standardwerten zwischen 0,0057 und 0,0075 RAND je Aufruf (Example programs). --fee überschreibt den Standard; die Wallet bepreist den echten Beweis vor dem Einreichen neu und lehnt eine Gebühr unter ihrer Untergrenze ab.

Wohin die Gebühr fließt

Sie fließt vollständig — Untergrenze und Trinkgeld — den rewards des Block-Proposers im Validator-Register gutgeschrieben, dem einzigen Ort in dieser Chain, der einen Betrag im Klartext speichert, mit einer Ausnahme. In einem Genesis mit tokens.burn_registration_fee (Chain 20, wie jede Chain seit 15) wird die registration_fee eines RegisterToken oder RegisterBridgedToken verbrannt, und der Proposer behält fee − registration_fee; rand_getSupply zählt sie in registration_fees_burned. In Chain 14, der das Flag fehlte, behielt der Proposer die gesamte Gebühr. Sonst wird nichts verbrannt, und es gibt keine Aufteilung. Ein Validator wandelt angesammelte Rewards mit rand-node withdraw in eine Note um (Staking). Die Cell-Gebühr eines Invoke ist Teil seiner Bundle-Gebühr und geht mit dem Rest an den Proposer. In Chain 20 gibt es keine Block-Rewards und keine Inflation: Gebühren sind das gesamte Einkommen eines Validators.

Eine Gebühr in Chain 20 ist nicht RAND und geht an keinen Validator. Unter dem Genesis-Abschnitt bridge.fees (neu in v0.6.8) behält die Bridge 10 bps jeder zUSD-Einzahlung und jedes zUSD-Burns, abgerundet auf eine ganze Freigabeeinheit der Deckung, als zUSD-Note an eine Treasury-Adresse, die das Genesis nennt. Eine Einzahlung schreibt dem Einzahler den Bruttobetrag abzüglich der Gebühr gut; ein Burn gibt amount − fee auf der Quell-Chain frei. Die Gebühren-Note bleibt ausgegeben und gedeckt. Siehe Bridge und RPL tokens.

Der Mempool ordnet Kandidaten danach, was sie über ihrer Untergrenze pro KiB zahlen, dann nach Gebühr (Mempool), sodass eine höhere Gebühr nur bei Überlastung zählt. Ein Transfer umfasst etwa 2,85 MB (gemessen auf Chain 18): ein Bundle-Beweis von 1,49 MB und ein Autorisierungsbeweis von 1,36 MB, sodass etwa sieben in den 20-MiB-Block von Chain 20 passen. Die eigene Anmerkung des Fullnode lautete, dass ein Gebührenmarkt auf Bytes — nicht auf Opcodes — das sein sollte, was die Untergrenze vor mainnet-beta werden muss. Der Byte-Preis von Chain 20 ist dieser Markt für Aufrufe, bewegt nur von den Bytes, für die Aufrufe zahlen; die Untergrenze eines Transfers bleibt pauschal.

Warum Gas hier ein Preis ist und keine Schranke

Ethereum misst jeden Opcode, weil jeder Node jede Transaktion ausführt und die Ausführung nach oben offen ist. Bei Rand führt kein Node etwas aus: Der Sender führt das Programm einmal off-chain aus und übergibt der Chain einen Beweis. Die Arbeit eines Nodes pro Transaktion ist eine feste Abfolge — die öffentlichen Felder dekodieren, die kostenlosen Prüfungen ausführen, einen STARK verifizieren — und diese Verifikation kostet mit warmem Verifier-Schlüssel etwa 16 ms, was auch immer das Programm getan hat. So fallen die drei Aufgaben von Gas auseinander:

• Terminierung erzwingt das Tier: Ein Lauf, der nicht innerhalb von 2ᵗ − 1 Zyklen hält, lässt sich gar nicht beweisen, und der Prover fängt den Fehlschlag ab.
• Die Bepreisung der Arbeit übernimmt seit Chain 18 die Gas-Untergrenze. Die Kosten des Netzwerks pro Instruktion sind nahe null, aber die Proving-Arbeit des Senders ist real, und eine pauschale Untergrenze bepreiste einen Aufruf mit einer Million Zyklen wie einen mit tausend. Bis Chain 18 war die Untergrenze pro Tier pauschal.
• Die Blockdimensionierung ist ein Byte-Budget (MAX_BLOCK_BYTES = 4 MiB standardmäßig, sonst das Genesis-Feld max_block_bytes) und eine Transaktionsanzahl (2.000).

Zwei Vorbehalte, die der Fullnode offen nennt: Bytes variieren sehr wohl (ein Beweis umfasst über ein Megabyte, daher ist Blockplatz, nicht Rechenleistung, die knappe Ressource), und das Zustandswachstum — der Baum, die Nullifier-Menge, bereitgestellte Programm-Bytes — wird nur durch die Deploy-Gebühr pro Wort und die pauschale Basis bepreist, was für ein testnet angemessen ist und überprüft werden sollte, sobald die Zustandsgröße zählt.

Was der Sender stattdessen zahlt: Proving

Die eine variable Kostenart ist die Erzeugung des STARK-Beweises, und nur die Maschine des Senders zahlt sie. In der Reihenfolge ihrer Wirkung:

1. Das Tier t ∈ {10, 12, 14, 16, 18, 20} (ein Aufruf über 14 wird in der Chain seit v0.5.6 abgelehnt; ein Bundle ist auf 14 festgelegt und führt seit Chain 17 einen Autorisierungsbeweis in Tier 10 mit sich, etwa 7 s mehr): Die cpu-Tabelle wird auf 2ᵗ Zeilen aufgefüllt, und jeder Schritt vervierfacht den aufgefüllten Trace ungefähr. Gemessen auf dem Entwicklungs-Laptop: private_payment in Tier 10 in etwa 7 s; der Hidden-Asset-Bundle-Guest in Tier 14 in etwa 100 s, welches Asset er auch bewegt.
2. Ausgeführte Zyklen, weil sie das Tier bestimmen: ausgeführte Instruktionen, nicht geschriebene.
3. Programmgröße, schwach: eine Digest-Zeile pro vier Wörter am Anfang des Trace.
4. Größe der privaten Eingabe, auf dieselbe Weise.
5. Welche Tabellen vorhanden sind: Eine keccak- oder sha256-Tabelle kostet den Anteil ihrer Spalten nur, wenn der Guest sie benutzt hat.
6. Das FRI-Profil: 80 Queries statt 27 verdreifachen die Beweisgröße, ändern die Proving-Zeit aber kaum.

Das Proving hängt nicht von den Beträgen ab, nicht davon, wie viele Notes der Sender besitzt, und nicht von der Größe der Chain: Die Mitgliedschaft wird gegen einen Baum fester Tiefe bewiesen, ein Transfer kostet also bei Block zehn dasselbe wie bei Block zehn Millionen.

Referenz