手数料

このページは、トランザクションの手数料を設定するとき、デプロイやコールの費用を見積もるとき、バリデータへの支払いを理解するときに使います。手数料は RAND 建ての下限です。コール以外のすべてのアクションは定額を支払います。chain 20 のコールは、証明が宣言するガスリミットとそのバイト数に対して支払います。価格はブロックの埋まり具合に応じて動き、上限で止まります。

下限

手数料の単位は 10⁻⁹ RAND です。定数は randprotocol_core::gas にあります。

手数料はバンドルのパブリックワードであり、常に RAND です。hidden-asset バンドルのゲストは、これを RAND グループの残高関係 in₂ + in₃ = out₂ + out₃ + fee + burn_r(スロット 2〜3)に結び付けます。そのため手数料は、どのノートかを明かすことなく秘匿ノートから支払われます。トークンは同じバンドルのスロット 0〜1 を、独自の関係 in₀ + in₁ = out₀ + out₁ + burn_a のもとで移動します。したがって 1 つの証明でトークンを移動し、その RAND 手数料も支払えます。トークンを持っていても使用可能な RAND を持たないウォレットは、証明の生成前に拒否されます。

ブリッジの課金がバーンにかかるのは、バーンが、送信者が確実に RAND を持っている唯一のブリッジトランザクションだからです。デポジットは基本料金のみを支払います。デポジットする側はまだ RAND を持っていないためです。登録手数料は fee_floor の一部ではなく台帳上の事実なので、アクション自身の規則(RegistrationFeeTooLow)で検査されます。これは、コールの証明がデコードされた後に、コールのガスまたは tier の部分が課金される仕組みと同じです。コールの下限は 2 回検査されます。コールが宣言する内容は、証明が検証されて初めて信頼できるためです。chain 20 では、検証前に行う 1 回目の検査で、コールのバイト数と宣言リミット 1 を価格付けします(Invoke はここでセル手数料も負担します)。2 回目の検査では、検証済みの証明が宣言するリミットを価格付けします。gas セクションのないチェーンでは、この 2 つは BUNDLE_BASE + CALL_BASE と tier に正確に対応する下限です。

推測せず、ノードに問い合わせてください。

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"

この答えは、開始時の価格では 1,000,000 + 100 × 20,479 + 800 × 1,319 です。ノードは、問い合わせ時点のチップの価格で価格付けします。chain 20 では、コール仕様の gas フィールドは JSON-RPC で必須です(指定しない場合は -32602)。--gas を付けない rand fee call <tier> はその tier の上限を送り、--bytes を付けない場合はバイトを価格付けしません。invoke も同様に価格付けされ、"kind":"invoke" と "created_cells": c を指定すると c 個のセル手数料が加算されます(上の例で 2 つのセルを作成する場合は 24103100。2026-10-01 に chain 20 へ問い合わせた値)。gas セクションのなかった chain 15 では、rand fee call 14 は 0.0022 RAND と答えました。

ウォレットの既定値は下限そのものです。ただし chain 20 のコールの既定値は余裕を上乗せします(後述)。rand send --fee <RAND> と、bond、call、bridge-mint、bridge-burn(既定値 0.01)および token サブコマンドの --fee フラグで、下限を引き上げられます。下限を超える分はチップです。

Gas on chain 18

chain 18 は 2026-09-29 から 2026-10-01 まで稼働した、最初のガス計量チェーンでした。chain 19 は同じビルドでの re-genesis で、同じ gas セクションを持っていました。chain 20(v0.6.8)はこのセクションのすべての規則を引き継ぎ、2 つの価格上限と、支払い対象のバイトだけを数えるバイト負荷を追加します(後述)。gas セクションのないチェーンは、上の表の tier スケジュールを使い続けます。

何を数えるか。 1 ガスは zkVM の cpu テーブルの 1 行です。そのため通常の命令は 1 です。それ以外のコストはシステムコールだけです。

宣言されるリミット。 コールの証明は、従来より 1 つ多いパブリック値 GAS_LIMIT を持ちます。回路(制約セット 8)は、実行のガスがそれ以下であることを証明します。正確なガスは非公開のままです。証明自身のヘッダーが示す上限を超えるリミットは、検証鍵が構築される前に拒否されます。

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

これは、どちらのハッシュテーブルも使わないコールでは、tier 10 で 1,279、tier 12 で 5,119、tier 14 で 20,479 になります。

下限。 台帳は、ブロックの開始時に有効な価格で、宣言されたリミットとバイト数に課金します。

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

bytes はコールの証明に入力エンベロープを加えたものです。このようなチェーンでは、tier スケジュールとその無料枠は適用されません。プールはブロックと同じものを要求し、それより安いコールは FeeTooLow として拒否します。

バンドルと認可証明は、固定されたリミットを宣言します。 すべてのバンドル証明は、genesis の bundle_gas_limit である 20,479(tier 14 の上限)をそのまま宣言しなければならず、そうでなければトランザクションは BundleGasLimit として拒否されます。chain 20 は chain 17 以降のすべてのチェーンと同様に split authorisation で動作するため、すべてのバンドルは tier 10 の認可証明を持ち、それは 1,279 を宣言しなければなりません(AuthGasLimit)。どちらも課金ではありません。送金、ボンド、デプロイは、上の表のとおり定額の下限を支払います。ウォレットは両方の値を自分で宣言します。

価格は動きます。 chain 20 の gas セクションには dynamic コントローラーがあり、gas_price と byte_price は台帳の状態であり、state root にコミットされます。ブロックごとに 1 回、そのトランザクションの後で、ブロックが目標に対してどれだけ埋まっていたかに応じて、それぞれが動きます。

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

used は目標の 2 倍で頭打ちになるため、adjust_bps は 1 ブロックがどちらの方向にも動かせる最大幅です。max_price は genesis の上限で、chain 18 と 19 にはありませんでした。byte_price はブロックの支払い対象バイトに従い(後述)、gas_price は、コールと invoke の宣言リミットの合計に、バンドル 1 つにつき 20,479 を加えたものに従います。

目標を下回るブロックは価格を下げるため、閑散としたチェーンでは価格は下限に張り付きます。rand_getLimits は、チップの現在の gas_price と byte_price を、gas_metering: "circuit"、bundle_gas_limit、adjust_bps とともに返し、v0.6.8 以降は max_gas_price、max_byte_price、byte_load も返します（これらを持たないチェーンでは null）。rand_status は同じ 2 つの価格を gas_prices として報告します。

上限と paying バイト負荷

どちらも gas.dynamic のジェネシスフィールドで、v0.6.8 で新たに加わりました（audit v6、POOL-2）。chain 20 が、これらを設定する最初のチェーンです。これらは chain 18 と chain 19 にあった不具合を正すものです。両チェーンでは、byte_price がすべてのトランザクションのエンコード長に応じて動く一方で、これを支払うのは call だけでした。7 件の転送（それぞれ約 2.85 MB、固定手数料）でブロックはバイト目標の約 1.9 倍まで埋まり、価格は 1 ブロックあたり約 11% 上がります。上限がないため、そのようなブロックが約 65 個続くと価格は開始時の 1,000 倍に達し、call のコストは約 0.004 RAND から約 1 RAND になります。

• 上限。 max_gas_price と max_byte_price は、コントローラがそれ以上には引き上げない価格です。ステップ幅は同じで、その後にクランプされます（gas::next_price_capped）。そのため、上限にある価格は満杯のブロックが何個続いても上限にとどまり、目標を下回る最初のブロックで下がります。ジェネシスは、それぞれを開始価格以上に設定しなければなりません。chain 20 の上限では、上記の tier-14 の call（20,479 gas、1,319 KiB）の下限は 0.3113 RAND で、これが下限の取りうる最高値です。
• paying バイト負荷。 byte_load: "paying" の下では、ブロックの bytes_used は、バイト価格が課されるバイトだけを数えます。すなわち各 Call と Invoke の証明に入力エンベロープを加えたもの（gas::call_bytes）で、転送、ボンド、バーンのバイトは含まれません。転送だけのブロックはバイト価格を動かしません。Ledger::block_usage がこの値をプロポーザーとレプリカの両方について計算するため、両者は一致します。

paying 負荷の下では、転送で埋まったブロックは call に価格シグナルを与えません。そのため、誠実なプロポーザーは call のための余地も確保します。これはノードのポリシーであり、有効性の規則ではありません。call または invoke がプールにあり、現在の下限を支払っている間は、固定手数料のトランザクションは最初のパスでブロックのバイトの最大 4 分の 3 までしか取れません。call が使い残した最後の 4 分の 1 は、後回しにしていた転送で埋められます（メムプール）。

call でウォレットが支払う額

rand call はまずエミュレータでプログラムを実行し、gas: <exact> (declaring <limit>, tier <t>) を出力します。デフォルトでは、正確な gas を 2^(tier − 2) の倍数に切り上げた値を宣言します。--gas-limit N は正確な値を宣言し、--gas-limit max はヘッダの上限を宣言します。

デフォルトの手数料が下限より高くなる理由は 2 つあります。

• 証明は上限サイズで価格が付けられます。 chain 16 以降（hardening_v6。chain 20 を含みます）、call の証明は自身のトランザクションに結び付けられるため、手数料は証明が存在する前に確定します。ウォレットは実際の証明サイズの代わりに、チェーンの証明サイズ上限である 4 MiB で価格を付けます（wallet::hardened_call_quote_bytes）。この方法では支払いが過剰になることはあっても、不足することはありません。
• 2 ステップ分の余裕。 rand_getLimits はコミット済みヘッドの価格を返し、call が取り込まれるのは 2〜3 ブロック後です。そのためデフォルトでは下限に (1 + adjust_bps / 10,000)² を掛けます。chain 20 では 1.125² です。

2026-09-30 に chain 18 で計測したところ、これらのデフォルトでは 4 件の call のコストはそれぞれ 0.0057〜0.0075 RAND でした（サンプルプログラム）。--fee はデフォルトを上書きします。ウォレットは送信前に実際の証明で価格を再計算し、下限を下回る手数料は拒否します。

手数料の行き先

手数料はすべて（下限もチップも）、バリデータレジストリにあるブロックプロポーザーの rewards に計上されます。これは、このチェーンで金額を平文のまま保存する唯一の場所です。例外が 1 つあります。tokens.burn_registration_fee を持つジェネシス（chain 20。chain 15 以降のすべてのチェーンと同じです）では、RegisterToken または RegisterBridgedToken の registration_fee はバーンされ、プロポーザーは fee − registration_fee を受け取ります。rand_getSupply はこれを registration_fees_burned に数えます。このフラグを持たなかった chain 14 では、プロポーザーが手数料の全額を受け取っていました。それ以外にバーンされるものはなく、分配もありません。バリデータは rand-node withdraw で、蓄積された報酬をノートに変えます（ステーキング）。invoke のセル手数料はバンドル手数料の一部であり、残りとともにプロポーザーに渡ります。chain 20 にはブロック報酬もインフレもありません。バリデータの収入は手数料がすべてです。

chain 20 には、RAND ではなく、どのバリデータにも渡らない手数料が 1 つあります。ジェネシスの bridge.fees（v0.6.8 で新規）の下で、ブリッジはすべての zUSD のデポジットとすべての zUSD のバーンから 10 bps を、裏付け資産の償還単位の整数に切り捨てて受け取ります。これは、ジェネシスが指定するトレジャリーアドレス宛の zUSD ノートとして保持されます。デポジットでは、預け入れた人に手数料を差し引いた額が付与されます。バーンでは、ソースチェーン上で amount − fee が償還されます。手数料ノートは発行済みのまま、裏付けも維持されます。ブリッジと RPL トークンを参照してください。

メムプールは、候補を 1 KiB あたりで下限を上回って支払う額の順に、次いで手数料の順に並べます（メムプール）。そのため、手数料を高くする意味があるのは混雑時だけです。転送は約 2.85 MB です（chain 18 で計測）。内訳は 1.49 MB のバンドル証明と 1.36 MB の認可証明で、chain 20 の 20 MiB のブロックには約 7 件が収まります。フルノード側の見解は、メインネット前に下限が目指すべきものは、オペコードではなくバイトに対する手数料市場だというものでした。chain 20 のバイト価格は call にとってのその市場であり、call が支払うバイトによってのみ動きます。転送の下限は依然として固定です。

ここでガスが上限ではなく価格である理由

Ethereum はすべてのオペコードを計量します。すべてのノードがすべてのトランザクションを実行し、その実行に終わりがないからです。Rand ではどのノードも何も実行しません。送信者がプログラムをオフチェーンで 1 回実行し、チェーンに証明を渡します。トランザクションごとのノードの作業は固定された手順で、公開フィールドをデコードし、無料のチェックを実行し、STARK を 1 つ検証します。この検証は、ウォームな検証鍵があればプログラムの内容にかかわらず約 16 ms です。そのため、ガスの 3 つの役割は切り離されます。

• 停止性は tier によって担保されます。2ᵗ − 1 サイクル以内に停止しない実行は、そもそも証明できず、その失敗は証明者が引き受けます。
• 作業の価格付けは、chain 18 以降、ガス下限の役割です。ネットワークの命令あたりのコストはほぼゼロですが、送信者の証明作業は現実のコストであり、固定の下限では 100 万サイクルの call も 1,000 サイクルの call と同じ価格になっていました。chain 18 までは、下限は tier ごとに固定でした。
• ブロックのサイズ設定は、バイト予算（デフォルトでは MAX_BLOCK_BYTES = 4 MiB、それ以外ではジェネシスの max_block_bytes）とトランザクション数（2,000）で行われます。

フルノードが明言している注意点が 2 つあります。バイトは実際に変動すること（証明は 1 メガバイトを超えるため、希少な資源は計算ではなくブロック空間です）、そして状態の増大（ツリー、ヌリファイアセット、デプロイされたプログラムのバイト）は、ワードあたりのデプロイ手数料と固定のベース手数料でしか価格付けされていないことです。これはテストネットには十分ですが、状態サイズが問題になる時点で見直す価値があります。

送信者が代わりに支払うもの：証明

変動する唯一のコストは STARK 証明の生成であり、それを負担するのは送信者のマシンだけです。影響の大きい順に挙げます。

1. tier t ∈ {10, 12, 14, 16, 18, 20}（v0.5.6 以降、チェーンは 14 を超える call を拒否します。バンドルは 14 に固定され、chain 17 以降はその隣に tier-10 の認可証明が付くため、約 7 秒増えます）。cpu テーブルは 2ᵗ 行にパディングされ、tier が 1 段上がるごとにパディング後のトレースはおよそ 4 倍になります。開発用ラップトップでの計測では、tier 10 の private_payment は約 7 秒、tier 14 の隠しアセットのバンドル guest は、どのアセットを動かす場合でも約 100 秒です。
2. 実行されたサイクル数。これが tier を決めます。数えるのは書かれた命令ではなく、実行された命令です。
3. プログラムサイズ。影響は小さく、トレースの先頭で 4 ワードにつきダイジェスト 1 行です。
4. プライベート入力のサイズ。同様に影響は小さいです。
5. どのテーブルが存在するか。keccak または sha256 のテーブルは、guest がそれを使ったときにだけ、その列の分のコストがかかります。
6. FRI プロファイル。クエリ数を 27 でなく 80 にすると、証明サイズは 3 倍になりますが、証明時間はほとんど変わりません。

証明は、金額にも、送信者が所有するノートの数にも、チェーンの大きさにも依存しません。メンバーシップは固定深度のツリーに対して証明されるため、転送のコストはブロック 10 でもブロック 1,000 万でも同じです。

リファレンス