Priority fee — это дополнительная доплата к базовой комиссии транзакции, которая влияет на порядок обработки внутри конкретного «локального рынка» вокруг перегруженных аккаунтов/приложений. В Solana нет единого «глобального газа»: конкуренция локализуется там, где много транзакций пишут в один и тот же участок состояния. Поэтому приоритетная доплата помогает «проскочить» вперёд в очаге, не повышая цену для всей сети (см. Local Fee Market (Solana): локальные рынки комиссий и priority fees). Механика приоритета тесно связана с моделью аккаунтов/параллелизмом исполнения (см. Sealevel (Solana): параллельное исполнение, рантайм и планировщик) и общим планом работы сети (см. Архитектура Solana: Объяснение Высокой Производительности, PoH, Sealevel).
Коротко о приоритетной доплате к комиссии в Solana
- Priority fee — это локальный аукцион при перегрузке конкретных данных (пула, ордербука, минта), а не «надбавка для всей сети».
- Вне очага доплата не влияет на скорость: вы просто переплатите без выигрыша.
- Для пользователя: разумные пресеты («обычно/быстро/срочно»), аккуратные ретраи в несколько слотов.
- Для разработчика: дизайн аккаунтов и «узкие» инструкции уменьшают потребность в высоких приоритетах.
Как это устроено (интуитивно)
- Узел-лидер группирует транзакции в партии по несовпадающим наборам аккаунтов; write-конфликтные операции попадают в локальные очереди.
- Внутри локальной очереди порядок определяется эффективной ценой: базовая комиссия + priority fee.
- Партии, которые не пересекаются по данным с очагом, исполняются параллельно — их доплата не требуется.
Итог: если вы не пишете в «горячий» аккаунт, доплата не нужна; если пишете, приоритет помогает занять место в ближайших слотах.
Когда имеет смысл поднимать приоритет
| Ситуация | Что происходит в сети | Что делать пользователю |
|---|---|---|
| Минт/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-конфликт — столкновение транзакций по аккаунту на запись; причина локальных очередей.
- Партия транзакций — набор неконфликтующих операций, исполняемых параллельно.
