Кожна транзакція у Solana коштує грошей. Цей довідник пояснює, з яких частин складається комісія, як вона розраховується, як її зменшити та як перевірити фактичні витрати на Devnet.
З чого складається комісія
Комісія транзакції у Solana складається з двох компонентів.
Base fee (комісія за транзакцію)
Фіксована сума, яку мережа стягує за сам факт включення транзакції до блоку. Станом на поточну версію протоколу ця величина дорівнює 5000 lamports. Один lamport — це одна мільярдна частина SOL (1 SOL = 1 000 000 000 lamports). Отже, base fee завжди становить 0,000005 SOL. Цей параметр не залежить від складності транзакції й не змінюється від блоку до блоку.
Compute unit price (пріоритезація)
Змінна частина, яку розробник або користувач встановлює самостійно. Вона визначає, скільки micro-lamports ви готові заплатити за один compute unit (обчислювальний юніт). Чим вища ціна — тим вищий пріоритет транзакції під час конкуренції за місце в блоці. Якщо блоки не заповнені, пріоритетна комісія може бути нульовою.
Важливо розрізняти ці два компоненти: base fee завжди сплачується, а compute unit price — це ваш добровільний внесок за швидкість обробки.
Примітка. Rent — окремий механізм утримання балансу для зберігання даних на рахунку. Rent не є частиною комісії транзакції, хоча сплачується в тій самій транзакції під час створення або розширення рахунку. Цей матеріал розглядає лише комісію транзакції.
Як розраховується комісія
Формула: compute_units × price_per_unit + base_fee
Загальна комісія транзакції обчислюється за формулою:
total_fee = (compute_unit_limit × price_per_micro_lamport) / 1 000 000 + base_fee
Де:
- compute_unit_limit — ліміт обчислювальних юнітів, який ви вказали в транзакції (комісія розраховується саме за лімітом, а не за фактично витраченими юнітами);
- price_per_micro_lamport — ціна пріоритету в micro-lamports за один compute unit, яку ви вказали;
- base_fee — 5000 lamports.
Ділення на 1 000 000 потрібне, оскільки ціна вказується в micro-lamports, а комісія розраховується в lamports.
Приклад розрахунку для типової транзакції
Припустимо, ви відправляєте простий переказ SOL на Devnet із такими параметрами:
| Параметр | Значення |
|---|---|
| Compute unit limit | 5 000 |
| Compute unit price | 100 000 micro-lamports |
| Base fee | 5 000 lamports |
Крок 1. Пріоритетна комісія: (5 000 × 100 000) / 1 000 000 = 500 lamports.
Крок 2. Загальна комісія: 500 + 5 000 = 5 500 lamports = 0,0000055 SOL.
Якщо ви встановите compute unit price рівним 0, пріоритетна частина зникне, і комісія складатиме лише base fee — 5 000 lamports.
Як зменшити комісії
Оптимізація compute units
Оскільки пріоритетна комісія прямо пропорційна встановленому ліміту compute units, зменшення цього ліміту зменшує комісію. Практичні кроки:
- Встановлюйте compute unit limit близько до фактичної потреби, а не залишайте значення за замовчуванням;
- Об'єднання кількох інструкцій в одну транзакцію замість відправки окремих транзакцій економить на base fee (по 5000 lamports за кожну транзакцію);
- Уникайте зайвих операцій читання та запису стану в програмі, що зменшує фактичне споживання обчислень і дозволяє встановити нижчий ліміт.
Детальний розбір того, як працюють обчислювальні ліміти та як їх вимірювати, розглядається в наступному матеріалі цього розділу.
Вибір priority fee на Devnet vs Mainnet
На Devnet блоки майже ніколи не заповнені. Тому встановлення compute unit price вище нуля на Devnet — це марна трата тестових SOL. Для розробки та тестування встановлюйте compute unit price рівним 0.
На Mainnet ситуація інша. Під час періодів завантаженості мережі транзакції з вищим priority fee потрапляють до блоку швидше. Рекомендовані значення на Mainnet змінюються залежно від поточного завантаження — перевірте актуальну рекомендовану ціну через інструменти моніторингу мережі безпосередньо перед розгортанням.
Як перевірити комісію
Читання fee у логах транзакції
Найпростіший спосіб побачити фактичну комісію — використати Solana CLI.
Середовище: Solana CLI, кластер Devnet.
Передумови: встановлений Solana CLI, налаштований на Devnet (solana config set --url devnet).
Очікуваний результат: вивід із полем fee, що містить комісію в lamports.
Після відправки транзакції виконайте:
solana confirm -v SIGNATURE
У виводі знайдіть рядок fee — він містить фактичну комісію в lamports. Типове значення для простої транзакції з нульовим priority fee: fee: 5000.
Інструменти для аналізу витрат
- Solana Explorer — відкрийте транзакцію за підписом, поле «Fee» показує загальну комісію в SOL і lamports. Також відображається розбивка на base fee та priority fee.
- RPC-метод getTransaction — повертає об'єкт транзакції з полем meta.fee (комісія в lamports) і meta.computeUnitsConsumed (фактично витрачені compute units, для порівняння з встановленим лімітом).
- RPC-метод simulateTransaction — дозволяє дізнатися очікувану кількість compute units до відправки транзакції. Це допомагає розрахувати комісію заздалегідь і встановити точний ліміт.
Типові помилки
Недостатньо SOL для комісії
Якщо баланс рахунку-відправника менший за суму переказу плюс комісія транзакції, транзакція буде відхилена ще до потрапляння в блок. Помилка: InsufficientFundsForFee.
Перевірка: перед відправкою переконайтеся, що баланс перевищує суму переказу щонайменше на 5000 lamports (для простої транзакції з нульовим priority fee). На Devnet отримати тестові SOL можна через кран.
Занадто високий priority fee
Встановлення compute unit price на рівні мільйонів micro-lamports без потреби призводить до значного перевищення комісії без реальної користі. Наприклад, при compute unit price 10 000 000 micro-lamports (10 lamports за compute unit) і ліміті 5000 compute units пріоритетна комісія складе 50 000 lamports — у 10 разів більше за base fee.
На Devnet це безглуздо. На Mainnet — перевірте актуальну рекомендовану ціну перед кожною відправкою, особливо якщо ваш застосунок формує транзакції автоматично.
Ще одна пов'язана помилка: встановлення дуже високого compute unit limit разом із високою ціною. Оскільки комісія розраховується за встановленим лімітом, а не за фактично використаними юнітами, завищений ліміт множиться на ціну. Якщо ви вказали ліміт 200 000 compute units, а транзакція використала лише 5 000 — комісія все одно розраховується за 200 000. Тому завжди симулюйте транзакцію через simulateTransaction і встановлюйте ліміт із невеликим запасом.