Кожна транзакція в Solana проходить чітко визначений шлях від моменту надходження на валідатор до фінального включення в блок. Цей пайплайн реалізований у межах Transaction Processing Unit (TPU) — підсистеми валідатора, оптимізованої для максимальної пропускної здатності. Розуміння кожної стадії критично важливе для інженерів, які налаштовують валідатори, оптимізують подачу транзакцій або досліджують причини відкидання.

Етапи обробки транзакції

Transmission Unit (TPU): прийняття транзакцій

TPU — це перша межа зустрічі транзакції з валідатором. Вхідні дані надходять через UDP-сокети, що забезпечує мінімальну затримку порівняно з TCP. Лідер поточного слоту прослуховує кілька UDP-портів паралельно, розподіляючи навантаження між потоками прийому.

На цьому етапі валідатор не виконує жодної логічної перевірки — завдання полягає в тому, щоб якомога швидше забрати сирі байти з мережі та передати їх далі по пайплайну. Транзакції, що надійшли під час слоту іншого лідера, все одно приймаються, але будуть оброблені лише якщо цей валідатор стає лідером або якщо транзакція пересилається далі.

Типова проблема на цьому рівні — втрата пакетів через перевантаження мережевого інтерфейсу валідатора або буферів ядра. Налаштування розміру кільця буферів (ring buffer) та affinity потоків до конкретних ядер CPU безпосередньо впливає на відсоток втрачених транзакцій.

Deserialization Queue: розпакування та валідація підписів

Сирі байти десеріалізуються у структурований формат транзакції Solana. Одразу після цього відбувається перевірка Ed25519 підписів — одна з найбільш обчислювально витратних операцій у всьому пайплайні.

У референсному клієнті Agave підписи верифікуються пакетами (batch verification) для ефективнішого використання CPU. Деякі конфігурації також використовують апаратне прискорення через GPU. Транзакції з невалідним підписом відкидаються негайно — вони не потрапляють у подальші стадії, що зберігає ресурси.

Важливо: десеріалізація включає базову структурну перевірку (коректність формату, кількість інструкцій не перевищує ліміт, розмір транзакції в межах), але не перевіряє логіку програм чи стан рахунків.

Banking Stage: перевірка балансів, виконання, ordering

Це центральний етап пайплайну, де відбувається фактичне виконання транзакції. Banking Stage працює з поточним станом банку (bank) — in-memory копією стану мережі на початку поточного слота.

На цьому етапі виконуються такі перевірки та дії:

  • Перевірка того, що рахунок-платник має достатній баланс для оплати базової комісії та вказаних priority fees.
  • Перевірка блокувань рахунків (account locks) — транзакція не може виконатися, якщо будь-який із залучених рахунків вже заблокований іншою транзакцією в межах поточного банку.
  • Виконання програм (програм execution) з урахуванням обмежень обчислювальних одиниць (compute units).
  • Застосування змін до стану банку (у пам'яті, не на диску).

Успішно виконані транзакції зберігаються в упорядкованій черзі (ordered queue), яка формується на основі priority fees. Транзакції, що завершилися помилкою під час виконання, відкидаються, але комісія все одно стягується.

Ключове обмеження: Banking Stage є послідовним щодо доступу до стану конкретного рахунку. Дві транзакції, що звертаються до одного рахунку, не можуть виконуватися паралельно. Це створює контенцію та є одним із головних вузьких місць.

Block Production: формування блоку лідером

Коли лідер готовий сформувати блок, він бере упорядковану чергу з Banking Stage, обмежує кількість транзакцій відповідно до максимального розміру блоку та обмежень на кількість записів у стан (write lock limits), і створює блок.

Блок містить:

  • Заголовок із хешем попереднього блоку, лічильником транзакцій, timestamp тощо.
  • Масив транзакцій у тому порядку, який визначив Banking Stage.

Після створення блок транслюється іншим валідаторам для підтвердження. Стан банку фіналізується, і наступний слот передається наступному лідеру за розкладом.

Роль priority fees у пайплайні

Як комісії впливають на порядок обробки

Priority fees — це додаткова комісія, яку відправник вказує в транзакції у вигляді мікролампортів за одну обчислювальну одиницю (compute unit). Вона не впливає на те, чи буде транзакція виконана (це визначає базова комісія та коректність), але визначає її позицію в черзі Banking Stage.

Механізм працює так:

  1. Транзакція надходить у Banking Stage і проходить перевірку підпису та базової валідації.
  2. Обчислюється показник пріоритету: priority fee per compute unit × max compute units (або фактично використані, залежно від реалізації).
  3. Транзакція вставляється в упорядковану чергу відповідно до цього показника.
  4. При формуванні блоку лідер бере транзакції зверху черги.

Це означає, що транзакція з високим priority fee per CU, але низьким лімітом CU, може мати нижчий пріоритет, ніж транзакція з помірним fee per CU, але високим лімітом. Відправникам варто розуміти цю формулу при конструюванні транзакцій.

Межі пропускної здатності та черги

Priority fees не збільшують загальну пропускну здатність пайплайну — вони лише визначають порядок у межах наявної ємності. Якщо Banking Stage вже завантажений на 100%, транзакції з низьким пріоритетом можуть чекати необмежено довго і врешті-решт відкидатися при переході до наступного слота.

Черга Banking Stage має фіксовану місткість. При досягненні ліміту нові транзакції з низьким пріоритетом витісняються. Це означає, що в періоди пікового навантаження навіть транзакції з помірним priority fee можуть не потрапити в блок, якщо черга заповнена вищопріоритетними транзакціями.

Для делегаторів та валідаторів це має практичне значення: доходи від priority fees розподіляються пропорційно частці стейку, але абсолютний розмір цих доходів залежить від того, наскільки ефективно валідатор обробляє чергу та чи не втрачає він транзакції на ранніх етапах пайплайну.

Вузькі місця та оптимізації

Типові bottlenecks у пайплайні

Аналіз пайплайну дозволяє виділити кілька послідовних вузьких місць, кожне з яких може стати лімітуючим фактором залежно від характеристик навантаження:

  • Мережевий I/O на рівні TPU. При високій швидкості надходження транзакцій буфери UDP можуть переповнюватися. Це особливо помітно на валідаторах із недостатньо налаштованими параметрами мережевого стека (розмір socket buffer, IRQ affinity).
  • Верифікація підписів. Ed25519 перевірка є CPU-bound операцією. Навіть із batch verification це залишається одним із найбільш витратних етапів за тактами процесора.
  • Контенція рахунків у Banking Stage. Коли велика кількість транзакцій звертається до невеликого набору рахунків (наприклад, популярних пулів ліквідності або токен-акаунтів), паралелізм знижується. Транзакції стають у чергу на блокування рахунку, що сповільнює весь етап.
  • Виконання важких програм. Програми з високим споживанням compute units (складні DeFi-операції, великі обчислення) утримують ресурси Banking Stage довше, зменшуючи загальну кількість транзакцій за слот.
  • Серіалізація блоку та трансляція. Формування фінального блоку та його відправка мережею також займає час, який вираховується з загального бюджету слота.

Як різні клієнти оптимізують обробку

Різні реалізації клієнта Solana підходять до оптимізації пайплайну по-різному:

Agave (референсний клієнт, написаний на Rust) історично використовує архітектуру з чітко розділеними стадіями, пов'язаними каналами (channels). Оптимізації зосереджені на покращенні batch sigverify, ефективнішому управлінні блокуваннями рахунків та зменшенні алокацій пам'яті на горячому шляху. Останні версії також впровадили покращене планування транзакцій у Banking Stage для кращого паралелізму при контенції рахунків.

Firedancer (клієнт від Jump Crypto, написаний на C) застосовує принципово інший підхід: kernel-bypass мережевий стек на основі io_uring, що усуває накладні витрати на системні виклики на рівні TPU. Sigverify реалізований з використанням SIMD-інструкцій процесора без залучення GPU. Кожна стадія пайплайну працює на окремих ядрах із мінімальним спільним станом, що зменшує contention на рівні самого валідатора. Firedancer також використовує власну реалізацію Banking Stage із альтернативним алгоритмом блокування рахунків.

Для валідаторів, що розглядають можливість переходу між клієнтами, ключовим практичним критерієм є не абстрактна пропускна здатність, а реальна частка успішно оброблених транзакцій у конкретних умовах навантаження мережі. Рекомендується моніторити метрики пайплайну (sigverify time, banking stage throughput, packet loss на TPU) на тестовій інфраструктурі перед прийняттям рішення.

Увага: конкретні показники продуктивності клієнтів змінюються з кожним релізом. Перевіряйте актуальні бенчмарки у репозиторіях відповідних клієнтів та незалежних дослідженнях перед прийняттям операційних рішень.

Джерела