В Solana priority fee зависит от того, сколько compute units транзакция просит выделить и какую цену за эти единицы указывает отправитель. Это отличается от распространённого ожидания, что сеть возьмёт плату только за фактически использованные вычисления: при обычном legacy или v0 формате приоритетная комиссия рассчитывается по запрошенному CU limit.
Правильный лимит помогает транзакции конкурировать за место в блоке, когда сеть загружена, но чрезмерный лимит способен увеличить комиссию без пользы. Чтобы читать параметры перед подтверждением, нужно разделять базовую плату за подписи, стоимость приоритета и фактическое потребление compute units при исполнении.
Что такое compute units
Compute unit, или CU, – внутренняя мера вычислительной работы Solana. Runtime учитывает операции программ, чтение данных, вызовы системных функций и другие расходы. Разные транзакции выполняют разное число инструкций и затрагивают разные программы, поэтому количество CU нельзя надёжно определить только по сумме перевода или числу токенов.
Compute unit limit задаёт верхнюю границу работы, разрешённой транзакции. Если программа использует больше установленного лимита, исполнение может завершиться ошибкой. Если запросить слишком большой предел, лишний запас не обязательно будет потрачен при исполнении, но в стандартной схеме он всё равно участвует в расчёте priority fee.
Текущая документация Solana описывает вычислительный бюджет для legacy и v0 транзакций отдельно от v1 формата. Для обычной подготовки транзакции важно знать, какой формат и SDK использует приложение. Не копируйте инструкцию для одного формата в другой без проверки правил соответствующей версии.
Из чего складывается комиссия
Общая комиссия транзакции состоит из base fee и optional prioritization fee. Базовая часть зависит от подписей и списывается до исполнения. Priority fee – дополнительная сумма, связанная с параметрами compute budget. В частности, compute-unit price задаётся в micro-lamports за CU, а CU limit – максимальный запрошенный объём.
Для legacy и v0 упрощённая формула такова: приоритетная комиссия в lamports равна округлённому вверх произведению цены в micro-lamports на запрошенный лимит CU, разделённому на миллион. Например, увеличение CU price вдвое удваивает приоритетную часть при том же лимите; увеличение самого лимита тоже повышает её. Это не означает, что приложение списывает сумму, равную максимальной цене SOL или всему вычислению.
Комиссия может быть списана и при неудачной транзакции. Поэтому перед повторной отправкой проверьте причину ошибки и историю прошлой попытки, чтобы не создавать несколько платных вызовов подряд. Общие причины списания комиссии при сбое разобраны в статье о неудачной транзакции.
Как limit и price влияют на приоритет
SetComputeUnitLimit устанавливает максимально разрешённое потребление. SetComputeUnitPrice назначает цену одного CU. Если priority price равна нулю, приоритетная часть комиссии равна нулю, хотя базовая комиссия остаётся. Более высокая цена может повысить вероятность своевременного включения, но не превращает подтверждение в безусловную гарантию: остаются лимиты блока, конкуренция, правила scheduler и состояние RPC/лидера.
Если лимит намного выше фактической потребности, пользователь может переплатить. Если он ниже необходимого, транзакция рискует исчерпать бюджет и не завершить логику. Поэтому лучше отделять оценку потребления от выбора цены. Сначала подберите разумный запас CU, затем оцените цену приоритета в зависимости от срочности и текущей конкуренции.
Некоторые кошельки показывают итоговую сумму, другие – отдельно базовую и дополнительную плату. Иногда интерфейс добавляет собственные настройки или оценку сервиса. Проверьте, какие инструкции включены в финальную подписываемую транзакцию, прежде чем подтверждать её. Для общей картины комиссий и сетевой монеты можно обратиться к материалу о монете, которую нужно оставить на комиссию.
Практический порядок оценки
Если вы создаёте транзакцию через SDK, сначала смоделируйте её или используйте результат симуляции, чтобы узнать фактическое потребление CU. Затем добавьте небольшой запас на отличие условий исполнения. Официальное руководство предлагает ориентир около десяти процентов, однако сложные транзакции и изменяемые данные могут потребовать другого подхода. Симуляция – снимок состояния, а не обещание идентичного результата позднее.
После выбора лимита определите цену priority fee. В спокойной сети нулевая или низкая дополнительная плата может быть достаточна. В периоды конкуренции приложения часто ориентируются на оценки недавних комиссий, иногда для затрагиваемых аккаунтов. Такие оценки быстро устаревают и не гарантируют место в следующем слоте. Не нужно автоматически копировать самую высокую цифру из стороннего сервиса.
Перед подписью проверьте адрес fee payer, инструкции, лимит, цену и общий расчёт в SOL. Если используете торговый или кошелёчный интерфейс, убедитесь, что сеть действительно Solana и что лимит/цена относятся к нужной операции. Начинающим полезно отдельно разобрать архитектуру Solana и не путать комиссию сети с комиссией биржи или протокола.
Ошибки, которые ведут к переплате
Самая распространённая ошибка – выставить очень высокий CU limit «на всякий случай», не понимая, что приоритетная комиссия считается по запросу. Вторая – повысить price, хотя проблема вызвана неверными аккаунтами или логикой приложения. Доплата не исправит некорректную инструкцию. Третья – отправлять одинаковую транзакцию повторно, не проверив подпись и статус предыдущей версии.
Не считайте, что высокая комиссия всегда означает более раннее исполнение. Важна механика scheduler, конкурирующая нагрузка и доступность блока. Также не переносите формулу legacy/v0 на v1: официальная документация указывает, что в v1 priority fee задаётся абсолютной суммой в конфигурации сообщения, а инструкции Compute Budget не управляют теми же параметрами.
Что проверить в обозревателе
После отправки найдите транзакцию по подписи и проверьте её статус, fee payer, итоговую fee, ошибки исполнения и использованные compute units, если обозреватель показывает это поле. Сравните фактические данные с тем, что сообщал кошелёк. В случае сбоя не ориентируйтесь только на уведомление приложения: обозреватель показывает результат сети и помогает отличить неподтверждённую операцию от завершившейся ошибкой.
При разработке сохраняйте диагностические данные симуляции и окончательный набор compute-budget инструкций. При обычном переводе разумнее принимать прозрачные параметры кошелька и избегать ручной настройки, если вы не понимаете её влияние. А когда приложение сообщает «недостаточно SOL», проверьте, что на fee payer действительно осталась монета для базовой и возможной приоритетной платы.
Итог прост: CU limit отвечает за допустимую вычислительную работу, CU price – за цену приоритета, а списываемая комиссия приоритета обычно зависит от обоих запрошенных значений. Симуляция помогает выбрать лимит, наблюдение за сетью – подобрать цену, а финальная проверка транзакции – избежать ненужной переплаты.
