Комиссии

Используйте эту страницу, чтобы задать комиссию транзакции, оценить стоимость развёртывания или вызова и понять, сколько получает валидатор. Комиссии — это нижние границы в RAND. Каждое действие, кроме вызова, платит фиксированную сумму. Начиная с chain 18 вызов платит за лимит газа, который объявляет его доказательство, и за свои байты по ценам, которые меняются вместе с заполненностью блоков и, начиная с chain 20, упираются в потолок. В chain 21 (fullnode v0.8.0, работает с 2026-10-12) сама нижняя граница сжигается, а пропозер оставляет себе только чаевые (ниже).

Нижние границы

Комиссии указаны в единицах 10⁻⁹ RAND. Константы находятся в randprotocol_core::gas:

Комиссия — публичное слово пакета, и она всегда в RAND. Гостевая программа пакета скрытых активов связывает её с балансовым соотношением группы RAND in₂ + in₃ = out₂ + out₃ + fee + burn_r (слоты 2–3), поэтому она оплачивается из скрытых нот без раскрытия, из каких именно; токен движется через слоты 0–1 того же пакета по собственному соотношению in₀ + in₁ = out₀ + out₁ + burn_a. Таким образом, одно доказательство перемещает токен и оплачивает его комиссию в RAND, а кошелёк, который держит токен, но не имеет доступного RAND, получает отказ ещё до построения доказательства.

Сбор моста падает на burn, потому что это единственная транзакция моста, отправитель которой наверняка держит RAND; депозит платит только базу, так как у вносящего RAND ещё нет. Плата за регистрацию — факт реестра, а не часть fee_floor, поэтому она проверяется по правилам самого действия (RegistrationFeeTooLow), так же как часть вызова, зависящая от газа или уровня, взимается после декодирования его доказательства. Нижняя граница вызова проверяется дважды, потому что объявленному можно доверять только после проверки доказательства. В сети с учётом газа (chain 21, как chain 18–20) первая проверка, до всякой верификации, оценивает байты вызова и объявленный лимит 1 (у Invoke там же добавляется плата за ячейки); вторая оценивает лимит, который объявляет проверенное доказательство. В сети без секции gas это BUNDLE_BASE + CALL_BASE и точная для уровня нижняя граница.

Спрашивайте узел, а не гадайте:

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 21's starting prices (chain 20's)

→ {"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). rand fee call <tier> без --gas отправляет потолок уровня, а без --bytes не оценивает байты. Invoke оценивается так же, с "kind":"invoke" и "created_cells": c, что добавляет c плат за ячейки (24103100 для примера выше с двумя ячейками, запрошено у chain 20 2026-10-01). В chain 15, где секции gas не было, rand fee call 14 отвечал 0,0022 RAND.

Значения кошелька по умолчанию в точности равны нижним границам, кроме вызова в сети с учётом газа (chain 21): там к значению по умолчанию добавляется запас (ниже); rand send --fee <RAND> и флаг --fee у bond, call, bridge-mint, bridge-burn (по умолчанию 0,01) и подкоманд token повышают их. Всё, что выше нижней границы, — чаевые.

Газ в chain 18

Chain 18, работавший с 2026-09-29 по 2026-10-01, был первой сетью с учётом газа, а chain 19, его повторный genesis на той же сборке, нёс ту же секцию gas. Chain 20 (v0.6.8) сохранил все правила этого раздела и добавил два ценовых потолка и нагрузку байтами, считаемую только по оплачиваемым байтам (ниже). Chain 21 (v0.8.0, 2026-10-12) несёт секцию gas chain 20 без изменений, кроме целевого размера блока в байтах, который следует за его меньшим лимитом блока. Сеть без секции gas сохраняет схему уровней из таблицы выше.

Что считается. Один газ — это одна строка таблицы cpu в zkVM, поэтому обычная инструкция стоит 1. Единственные другие затраты — системные вызовы:

Объявленный лимит. Доказательство вызова несёт на одно публичное значение больше, чем раньше, GAS_LIMIT, и схема (набор ограничений 8) доказывает, что газ выполнения не превышает его. Точный газ остаётся приватным. Лимит выше потолка собственного заголовка доказательства отклоняется до построения любого ключа верификатора:

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

Это 1 279 на уровне 10, 5 119 на уровне 12 и 20 479 на уровне 14 для вызова, который не использует ни одну из хеш-таблиц.

Нижняя граница. Реестр взимает плату за объявленный лимит и байты по ценам, действующим на начало блока:

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

bytes — это доказательство вызова плюс конверт входных данных. Схема уровней и её бесплатный объём в такой сети не применяются. Пул требует ровно то же, что и блок, и отклоняет более дешёвый вызов как FeeTooLow.

Пакеты и доказательство авторизации объявляют фиксированные лимиты. Каждое доказательство пакета должно объявлять ровно bundle_gas_limit из genesis, 20 479 (потолок уровня 14), иначе транзакция отклоняется как BundleGasLimit. Chain 21, как и каждая сеть начиная с 17, использует раздельную авторизацию, поэтому каждый пакет несёт доказательство авторизации уровня 10, которое обязано объявлять 1 279 (AuthGasLimit); пакет, авторизованный приватной мультиподписной политикой (новое в chain 21), вместо этого несёт доказательство уровня 18 второй guest-программы авторизации (Транзакции). Ни одно из них не является платой: перевод, bond или развёртывание по-прежнему платит свою фиксированную нижнюю границу из таблицы выше. Оба значения кошелёк объявляет сам.

Цены меняются. Начиная с цепочки 18 в разделе gas есть контроллер dynamic, поэтому gas_price и byte_price являются состоянием реестра и входят в корень состояния. Раз в блок, после его транзакций, каждая цена сдвигается в зависимости от того, насколько блок заполнен относительно цели:

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

used ограничено удвоенной целью, поэтому adjust_bps — это наибольший сдвиг, который один блок может сделать в любую сторону. max_price — потолок, заданный в genesis; в цепочках 18 и 19 потолка не было. byte_price следует за оплачиваемыми байтами блока (см. ниже); gas_price следует за суммой заявленных лимитов его вызовов и invoke-операций плюс 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 сообщает те же две цены как gas_prices.

Потолки и оплачиваемая байтовая нагрузка

Оба параметра — поля genesis в gas.dynamic, появились в v0.6.8 (аудит v6, POOL-2), и цепочка 20 первой их задаёт. Они устраняют дефект цепочек 18 и 19. Там byte_price двигался вместе с закодированной длиной каждой транзакции, хотя платит за неё только вызов. Семь переводов (около 2,85 MB каждый, плоская комиссия) заполняют блок примерно до 1,9 байтовой цели и поднимают цену примерно на 11% за блок, причём без потолка: около 65 таких блоков доводят её до 1 000 стартовых значений, и вызов тогда стоит около 1 RAND вместо около 0,004.

• Потолки. max_gas_price и max_byte_price — цены, выше которых контроллер их не поднимает. Шаг вычисляется тот же, а затем ограничивается (gas::next_price_capped), поэтому цена на потолке остаётся там при любой серии полных блоков и снижается с первого же блока ниже цели. Genesis обязан задавать каждый потолок не ниже стартовой цены. При этих потолках (цепочка 21 сохраняет потолки цепочки 20) вызов уровня 14 из примера выше, 20 479 gas и 1 319 KiB, имеет нижнюю границу 0,3113 RAND — это наибольшее значение, которого она может достичь.
• Оплачиваемая байтовая нагрузка. При byte_load: "paying" значение bytes_used блока учитывает только те байты, за которые взимается байтовая цена: доказательство и входной конверт каждого Call и Invoke (gas::call_bytes), но ничего от перевода, залога или сжигания. Блок из переводов не двигает байтовую цену. Ledger::block_usage вычисляет это значение и для пропозера, и для реплики, так что оба согласуются.

При оплачиваемой нагрузке блок, целиком состоящий из переводов, не даёт вызовам ценового сигнала, поэтому честный пропозер дополнительно резервирует место для вызовов. Это политика узла, а не правило валидности: пока вызов или invoke находится в пуле и платит текущую нижнюю границу, транзакции с плоской комиссией занимают на первом проходе не более трёх четвертей байтов блока, а то, что вызовы оставляют от последней четверти, затем заполняется отложенными переводами (Мемпул).

Что кошелёк платит за вызов

rand call сначала запускает программу в эмуляторе и печатает gas: <exact> (declaring <limit>, tier <t>). По умолчанию он заявляет точное значение gas, округлённое вверх до кратного 2^(tier − 2); --gas-limit N заявляет точное значение, а --gas-limit max — потолок заголовка.

Две вещи делают комиссию по умолчанию выше нижней границы:

• Доказательство оценивается по лимиту. Начиная с цепочки 16 (hardening_v6, цепочка 21 включена) доказательство вызова привязано к своей транзакции, поэтому комиссия фиксируется до появления доказательства. Кошелёк оценивает лимит доказательства в цепочке — 6 MiB в цепочке 21, 4 MiB в цепочках с 18 по 20 — вместо реального размера доказательства (wallet::hardened_call_quote_bytes). Это может привести только к переплате.
• Запас в два шага цены. rand_getLimits отдаёт цены зафиксированной головы, а вызов попадает в блок через два-три блока, поэтому по умолчанию нижняя граница умножается на (1 + adjust_bps / 10,000)², то есть на 1,125² в цепочке 21, как и в цепочке 20.

Измерения в цепочке 18 на 2026-09-30: четыре вызова при этих значениях по умолчанию стоили от 0,0057 до 0,0075 RAND каждый (Примеры программ). --fee переопределяет значение по умолчанию; перед отправкой кошелёк заново оценивает реальное доказательство и отказывается от комиссии ниже нижней границы.

Куда уходит комиссия

В цепочке 21 нижняя граница сжигается, а чаевые достаются пропозеру. Genesis цепочки 21 содержит раздел fees с заданными burn_base и burn_floor (fullnode v0.8.0; rand_getLimits.fee_rules отдаёт его как {"burn_base": true, "burn_floor": true, "subsidy_net_of_fees": false, "proposer_share_bps": null, "prove_base": null, "usd_subsidy": null}). В разбиении комиссии каждого бандла собственная нижняя граница реестра для этого бандла — BUNDLE_BASE для перевода, залога, действия с токеном или аттестации; BUNDLE_BASE плюс слагаемое за слово для Deploy; точная для уровня нижняя граница вызова по ценам блока для Call, плюс комиссия за ячейку для Invoke; BRIDGE_BURN_FEE для BridgeBurn, так что собственный сбор моста уничтожается вместе с базой — сжигается (burned = min(fee, floor)), а rewards пропозера блока в реестре валидаторов, единственном месте этой цепочки, где сумма хранится в открытом виде, растут только на чаевые, fee − floor. rand_getSupply учитывает сжигание в base_fees_burned, справа в тождестве предложения рядом с registration_fees_burned (Предложение), а fees_paid меняется на то, что оставляет себе пропозер. Для отправителя ничего не меняется: нижние границы и значения кошелька по умолчанию — те же числа, что выше, отличается лишь то, куда уходит нижняя граница. Точная форма EIP-1559 выбрана вместо сжигания одной только базы, чтобы пропозер ничего не выигрывал от блока, поднимающего цену. registration_fee регистрации не входит в нижнюю границу; он сжигается по собственному флагу, как и прежде.

В цепочках с 15 по 20 всё — и нижняя граница, и чаевые — зачислялось пропозеру, за одним исключением. В genesis с tokens.burn_registration_fee (цепочка 21, как и каждая цепочка с 15) registration_fee у RegisterToken или RegisterBridgedToken сжигается, а пропозер оставляет себе fee − registration_fee; rand_getSupply учитывает его в registration_fees_burned. В цепочке 14, где этого флага не было, пропозер оставлял себе всю комиссию. Валидатор превращает накопленные награды в ноту командой rand-node withdraw (Стейкинг). В цепочке 21 нет ни наград за блок, ни инфляции: чаевые — весь доход валидатора. База Withdraw оплачивается на стороне реестра из выводимой суммы и никогда не проходит через разбиение комиссии бандла, поэтому не сжигается.

Одна комиссия с цепочки 20 не в RAND и не достаётся ни одному валидатору. По genesis-разделу bridge.fees (новое в v0.6.8, перенесено в цепочку 21) мост оставляет себе 10 bps от каждого депозита zUSD и от каждого сжигания zUSD, округлённых вниз до целой единицы выпуска обеспечения, в виде ноты zUSD на адрес казначейства, названный в genesis. Депозит зачисляет вкладчику брутто за вычетом комиссии; сжигание высвобождает amount − fee в исходной цепочке. Нота комиссии остаётся выпущенной и обеспеченной. См. Мост и токены RPL.

Мемпул упорядочивает кандидатов по тому, сколько они платят сверх своей нижней границы на KiB, затем по комиссии (Мемпул), поэтому более высокая комиссия имеет значение только при перегрузке. Перевод занимает около 2,85 MB (измерено в цепочке 18): доказательство бандла 1,49 MB и доказательство авторизации 1,36 MB, так что при таком размере в блок цепочки 20 в 20 MiB помещается около семи, а в блок цепочки 21 в 19 MiB — шесть (размеры доказательств набора ограничений 9 в цепочке 21 здесь пока не измерены). Собственное замечание fullnode состояло в том, что рынок комиссий на байты, а не на опкоды, — это то, чем должна стать нижняя граница до mainnet-beta. С цепочки 20 байтовая цена и есть такой рынок для вызовов: её двигают только байты, за которые платят вызовы; нижняя граница перевода по-прежнему плоская, а с цепочки 21 она сжигается.

Почему gas здесь — цена, а не предел

Ethereum тарифицирует каждый опкод, потому что каждый узел выполняет каждую транзакцию, а выполнение не ограничено. В Rand ни один узел ничего не выполняет: отправитель один раз запускает программу вне цепочки и передаёт цепочке доказательство. Работа узла на транзакцию — фиксированная последовательность: декодировать публичные поля, выполнить бесплатные проверки, проверить один STARK, — и эта проверка занимает около 16 ms при прогретом ключе верификатора, что бы ни делала программа. Поэтому три задачи gas распадаются:

• Завершаемость обеспечивается ярусом: запуск, который не останавливается за 2ᵗ − 1 циклов, вообще не может быть доказан, и сбой поглощает prover.
• Оценка работы — это то, что делает нижняя граница gas, начиная с chain 18. Стоимость сети на одну инструкцию близка к нулю, но работа отправителя по построению доказательства реальна, а фиксированная нижняя граница оценивала вызов в миллион циклов так же, как вызов в тысячу циклов. До chain 18 нижняя граница была фиксированной для каждого яруса.
• Размер блока задаётся бюджетом в байтах (MAX_BLOCK_BYTES = 4 MiB по умолчанию, иначе max_block_bytes из genesis) и числом транзакций (2 000).

Две оговорки, которые fullnode формулирует прямо: байты действительно различаются (доказательство занимает более мегабайта, поэтому дефицитным ресурсом оказывается пространство блока, а не вычисления), а рост состояния — дерево, множество нуллификаторов, байты развёрнутых программ — оценивается только платой за слово при развёртывании и фиксированной базой, чего достаточно для testnet и что стоит пересмотреть, когда размер состояния станет существенным.

Что отправитель платит вместо этого: построение доказательства

Единственная переменная стоимость — построение доказательства STARK, и платит её только машина отправителя. В порядке влияния:

1. Ярус t ∈ {10, 12, 14, 16, 18, 20} (вызов выше 14 отклоняется в сети начиная с v0.5.6; bundle закреплён за ярусом 14 и, начиная с chain 17, несёт рядом с собой доказательство авторизации яруса 10, это ещё около 7 с): таблица cpu дополняется до 2ᵗ строк, и каждый шаг примерно вчетверо увеличивает дополненную трассу. Измерено на ноутбуке разработки: private_payment на ярусе 10 — около 7 с; guest-программа bundle скрытого актива на ярусе 14 — около 100 с, какой бы актив она ни перемещала.
2. Выполненные циклы, поскольку они определяют ярус: учитываются выполненные инструкции, а не написанные.
3. Размер программы, слабо: одна строка дайджеста на четыре слова в начале трассы.
4. Размер приватного входа, так же.
5. Какие таблицы присутствуют: таблица keccak или sha256 стоит доли своих столбцов, только если guest-программа её использовала.
6. Профиль FRI: 80 запросов вместо 27 утраивают размер доказательства, но почти не меняют время построения.

Построение доказательства не зависит от сумм, от того, сколько нот у отправителя, и от размера цепи: принадлежность доказывается относительно дерева фиксированной глубины, поэтому перевод стоит одинаково на десятом блоке и на десятимиллионном.

Справочник