Priority Fee (Solana): приоритетная комиссия за compute units (CU) и «чаевые» валидатору

Priority fee — это дополнительная доплата к базовой комиссии транзакции, которая влияет на порядок обработки внутри конкретного «локального рынка» вокруг перегруженных аккаунтов/приложений. В Solana нет единого «глобального газа»: конкуренция локализуется там, где много транзакций пишут в один и тот же участок состояния. Поэтому приоритетная доплата помогает «проскочить» вперёд в очаге, не повышая цену для всей сети (см. Local Fee Market (Solana): локальные рынки комиссий и priority fees). Механика приоритета тесно связана с моделью аккаунтов/параллелизмом исполнения (см. Sealevel (Solana): параллельное исполнение, рантайм и планировщик) и общим планом работы сети (см. Архитектура Solana: Объяснение Высокой Производительности, PoH, Sealevel).

Priority Fee (Solana)

Коротко о приоритетной доплате к комиссии в Solana

  • Priority fee — это локальный аукцион при перегрузке конкретных данных (пула, ордербука, минта), а не «надбавка для всей сети».
  • Вне очага доплата не влияет на скорость: вы просто переплатите без выигрыша.
  • Для пользователя: разумные пресеты («обычно/быстро/срочно»), аккуратные ретраи в несколько слотов.
  • Для разработчика: дизайн аккаунтов и «узкие» инструкции уменьшают потребность в высоких приоритетах.

Как это устроено (интуитивно)

  1. Узел-лидер группирует транзакции в партии по несовпадающим наборам аккаунтов; write-конфликтные операции попадают в локальные очереди.
  2. Внутри локальной очереди порядок определяется эффективной ценой: базовая комиссия + priority fee.
  3. Партии, которые не пересекаются по данным с очагом, исполняются параллельно — их доплата не требуется.

Итог: если вы не пишете в «горячий» аккаунт, доплата не нужна; если пишете, приоритет помогает занять место в ближайших слотах.


Когда имеет смысл поднимать приоритет

Ситуация Что происходит в сети Что делать пользователю
Минт/NFT-ивент Очаг вокруг аккаунтов минта Ставить «быстро/срочно», 1–3 ретрая с окном в несколько слотов
DEX-арбитраж/ликвидации Очередь на записи в пул/ордербук Высокий приоритет, минимальные дубликаты заявок
Платёж вне хайпа Нет write-конфликтов Оставить «обычно» (базовая комиссия)
«Толстая» транзакция с CPI Риск упереться в лимит CU и задержки Сократить путь/инструкции; приоритет даёт меньший эффект, чем оптимизация

Замечание. Если ваша операция «рядом» с очагом, но не трогает горячие аккаунты на запись, поднимать приоритет бессмысленно.


Практика: пресеты для кошельков и dApp

Рекомендация для UX:

  • Обычно. Для операций вне очагов. Без доплаты, один сабмит, один ретрай.
  • Быстро. Для умеренной конкуренции. Небольшая доплата к базовой, до 2 ретраев по слотам.
  • Срочно. Для массовых ивентов/арбитражей. Повышенная доплата, 1–2 ретрая; показывать пользователю предупреждение о «переплате без гарантий».

В интерфейсе объясняйте локальность приоритета простым текстом: «Доплата ускоряет обработку только там, где идёт конкуренция за те же данные».


Для разработчиков: как снизить «цену приоритета» архитектурой

  • Шардируйте состояние. Разбивайте общий «горячий» аккаунт на множество per-user/per-market (PDA) — меньше write-конфликтов ⇒ меньше нужды в доплате.
  • Делайте «узкие» инструкции. Разделяйте операции, чтобы планировщик мог распараллелить партии.
  • Отделяйте «горячее» от «холодного». Метаданные и конфиги держите в read-only аккаунтах; запись туда не нужна на каждом вызове.
  • Подсказки в UI. Показывайте оценку локальной очереди (если возможна) и аккуратно повышайте приоритет только при явной конкуренции.
  • Ретраи по слотам. Вместо «бомбардировки» дубликатами — 1–3 аккуратных повтора в соседних слотах.

Связанный технический контекст раскрыт на страницах Sealevel (Solana): параллельное исполнение, рантайм и планировщик и Архитектура Solana: Объяснение Высокой Производительности, PoH, Sealevel.


Типичные ошибки и заблуждения

«Подниму приоритет — и любая транзакция станет мгновенной». Нет. Приоритет работает только в локальном рынке. Вне очага он не ускоряет транзакцию.

«Если повысить вдвое, точно пройду». Не обязательно. При маленькой очереди вы просто переплатите; при огромной очереди — получите лишь вероятностный выигрыш на 1–2 слота.

«Дублировать транзакции — норм». Нет. Дубликаты плодят конкуренцию сами с собой, засоряют очередь и увеличивают расходы. Лучше один сабмит + аккуратные ретраи.

«Высокий приоритет чинит плохую архитектуру». Не чинит. Узкое место из-за «центрального аккаунта» лечится шардированием, а не фи.


Диагностика: что смотреть в метриках

Метрика Почему важна Интерпретация
Доля write-конфликтов Показывает очаги конкуренции Рост по конкретным аккаунтам ⇒ шардировать/разделять
p95/p99 задержек Чувствительнее среднего TPS «Хвосты» в одной dApp при «холодной» сети ⇒ локальный рынок
Распределение priority fee Прокси-жара в очаге Пики только вокруг пары аккаунтов — механика работает по дизайну
Отказы CPI/прав доступа Побочные эффекты перегрева Частые account not found/borrowed as immutable ⇒ неполные account metas/неверные флаги

Мини-гайд по настройке приоритета

  • Определите, какого аккаунта касается ваша операция (пул, ордербук, минт).
  • Посмотрите на загрузку/ошибки за последние слоты (если доступно в UI dApp).
  • Выберите пресет: «обычно» вне очага; «быстро» при умеренной очереди; «срочно» — только для явного хайпа.
  • Не делайте больше 1–3 ретраев; увеличивайте окно между ними на 1 слот.
  • Останавливайтесь при признаках «холода» — дальнейшая доплата не даст выигрыша.

Мини-глоссарий

  • Очаг (горячая зона) — набор аккаунтов/приложение, вокруг которых возникла локальная конкуренция на запись.
  • Priority fee — приоритетная доплата к базовой комиссии; влияет на порядок в локальном рынке.
  • Write-конфликт — столкновение транзакций по аккаунту на запись; причина локальных очередей.
  • Партия транзакций — набор неконфликтующих операций, исполняемых параллельно.

См. также

Mev Jito Block Engine

Task Runner