Шлях транзакції в Solana від підпису користувача до підтвердження

Підписана транзакція в Solana проходить через мережевий конвеєр із кількох стадій: від входу через RPC-вузол або безпосередньо в TPU лідера, через послідовну перевірку та виконання, до голосування валідаторів і набуття статусу підтвердженої або фіналізованої. Кожна стадія має власну мету, власні точки відсіву та власні компроміси. Нижче — послідовний розбір цього шляху на рівні протоколу з чітким розмежуванням того, що є архітектурним фактом, а що — невизначеністю, яка залежить від поточного стану мережі.

Що потрібно відокремити на старті

Дослідницьке питання: який саме послідовний шлях проходить підписана транзакція в Solana на рівні протоколу, перш ніж отримати статус підтвердженої чи фіналізованої, і в яких точках цього шляху виникає невизначеність для користувача?

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

Межа аналізу: цей матеріал охоплює виключно шлях на рівні протоколу — від моменту, коли користувач підписав транзакцію, до моменту, коли вона набуває статусу підтвердженої або фіналізованої. Ми не розкриваємо, як клієнтське ПЗ конструює транзакцію (це залежить від моделі акаунтів), як працює годинниковий механізм (Proof of History) чи як формуються економічні стимули валідаторів. Загальний огляд архітектури доступний у протоколі Solana простими й точними словами.

Логіка роботи

Підписана транзакція як вхідні дані конвеєра

На вході в конвеєр знаходиться серіалізована транзакція з принаймні одним криптографічним підписом. За архітектурою протоколу вона містить набір інструкцій, список акаунтів, які ці інструкції зачіпають, нещодавній хеш блоку (recent blockhash) та відповідні підписи. Recent blockhash прив’язує транзакцію до конкретного вікна часу в ланцюгу — якщо мине занадто багато слотів, транзакція вважатиметься застарілою і буде відхилена.

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

Вхід у мережу: RPC-вузол чи пряме з’єднання з TPU

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

Через RPC-вузол. Користувач (або його клієнтське ПЗ) надсилає транзакцію на RPC-вузол (Remote Procedure Call) за допомогою стандартного методу відправки. RPC-вузол приймає транзакцію, виконує базову перевірку формату і, за архітектурою протоколу, пересилає її поточному лідеру. Це стандартний для багатьох клієнтів шлях інтеграції: застосунок працює з RPC, а подальше пересилання до TPU залежить від конфігурації RPC та мережевого маршруту.

Безпосередньо в TPU лідера. TPU (Transaction Processing Unit — конвеєр обробки транзакцій) валідатора приймає мережеві пакети; актуальна реалізація Agave підтримує приймання через UDP/QUIC, тому прив’язувати цей шлях лише до UDP некоректно. Цей шлях оминує RPC-вузол, що теоретично зменшує затримку, але вимагає від клієнта знати адресу поточного лідера та реалізувати протокол відправки.

Gulf Stream. Маршрут доставки до лідера залежить від клієнта й транспортного шару. Для читача важливіше не покладатися на стару спрощену схему «немає мемпулу — отже шлях завжди прямий», а розрізняти доставку транзакції, її приймання валідатором і подальший внутрішній pipeline перевірки та виконання.

Конвеєр обробки TPU

Коли транзакція досягає TPU лідера, вона проходить через послідовний конвеєр із кількох стадій. Кожна стадія виконує специфічну перевірку і відсіває непридатні транзакції до того, як вони досягнуть етапу виконання.

Стадія конвеєра	Завдання	Що відбувається з транзакцією
Fetch (отримання)	Прийом пакетів з мережі	Транзакція надходить як мережевий пакет; на цьому етапі ніякої валідації змісту не відбувається
Verify (перевірка цілісності)	Контроль цілісності пакету	Перевіряється контрольна сума пакету; пошкоджені або некоректні пакети відкидаються без подальшої обробки
Signature Check (перевірка підписів)	Криптографічна валідація	Ed25519-підписи перевіряються, зазвичай з використанням апаратного прискорення (GPU); транзакції з невалідними підписами відкидаються
Sanitize (санітарна перевірка)	Форматна та логічна перевірка	Перевіряється розмір транзакції, структура, відсутність дублікатів підписів, валідність recent blockhash; невідповідні транзакції відкидаються
Batch (групування)	Формування пакетів для виконання	Валідні транзакції об’єднуються в батчі для ефективного передавання на етап виконання
Execute (виконання)	Запуск інструкцій у runtime	Транзакція виконується послідовно; при помилці виконання — відхиляється, при успіху — змінює стан акаунтів

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

Виконання та формування блоку

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

Якщо всі інструкції виконані успішно, зміни стану фіксуються в поточному слоті лідера. Лідер формує блок, який включає цю транзакцію разом з іншими, і порядок транзакцій усередині блоку фіксується за допомогою послідовності хешів Proof of History. На цьому етапі транзакція є обробленою (processed), але ще не має гарантій збереження в ланцюгу.

Голосування та статуси підтвердження

Після того як лідер формує блок і транслює його в мережу, інші валідатори перевіряють блок і, якщо він валідний, подають голоси. Голосування відбувається за механізмом Tower BFT — модифікацією класичного BFT-консенсусу, адаптованої для роботи з Proof of History як годинником.

Протокол розрізняє три статуси транзакції, кожен із різним рівнем гарантій:

Статус	Що означає	Гарантії
Processed (оброблена)	Лідер виконав транзакцію і включив у блок	Жодних гарантій проти відкату; блок може не отримати достатньо голосів і бути відкинутим
Confirmed (підтверджена)	Блок з транзакцією отримав голоси валідаторів, що разом представляють щонайменше 66% голосуючого стейку	Це сильніше підтвердження, ніж processed, але воно ще не тотожне finalized
Finalized (фіналізована)	Поверх блоку побудовано щонайменше 31 підтверджений блок; у термінах RPC це найвищий рівень commitment	Для прикладного коду цей статус слід трактувати як фінальний відповідно до поточної моделі commitment

Перехід від processed до finalized не є миттєвим. Між обробкою лідером і фіналізацією проходить час, необхідний для розповсюдження блоку, його перевірки іншими валідаторами, збору голосів та побудови достатньої кількості наступних блоків. Цей проміжок — зона невизначеності для користувача.

Джерела й перевірювані твердження

Описаний вище шлях базується на архітектурних принципах протоколу Solana. Визначення рівнів commitment звірено з офіційною документацією Anza: для confirmed потрібні голоси 66%+ стейку, а finalized передбачає 31+ підтверджений блок поверх цільового. Конкретні часові характеристики цього шляху — затримка між стадіями, частота відсіву та час до фіналізації — залежать від поточного стану мережі й потребують датованих вимірювань.

Архітектурні твердження (наявність конвеєра TPU, послідовність стадій, наявність Gulf Stream, три статуси підтвердження) верифікуються через специфікацію протоколу, вихідний код клієнта валідатора (зокрема модулі TPU та runtime) та архітектурну документацію. Ці джерела описують дизайн системи, а не її поточну поведінку.

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

Позиції різних сторін відрізняються за фокусом:

• Користувачі зацікавлені в передбачуваності: чи буде транзакція включена і коли. Для них ключова метрика — end-to-end затримка від підпису до фіналізації в реальних умовах.
• Валідатори зацікавлені в ефективності конвеєра: пропускна здатність TPU, рівень використання GPU для перевірки підписів, частка транзакцій, що доходять до етапу виконання.
• Розробники інфраструктури (RPC-провайдери, гаманці) зацікавлені в оптимізації точки входу: вибір між RPC та прямим TPU, налаштування пересилання через Gulf Stream, обробка повторних відправлень.

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

Ризики й системні компроміси

Архітектура шляху транзакції в Solana містить кілька суттєвих компромісів, які варто розуміти окремо.

Швидкість обробки проти затримки фіналізації. Конвеєр TPU спроєктований для максимальної пропускної здатності на етапі обробки, але фіналізація вимагає часу на консенсус. Транзакція може бути оброблена лідером швидко, але фіналізована — значно пізніше. Користувач, який спирається лише на статус processed, бере на себе ризик відкату. Цей компроміс є архітектурним: прискорення фіналізації означало б зміну консенсусного механізму з відповідними втратами в пропускній здатності.

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

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

Gulf Stream: оптимізація проти складності. Пересилання транзакцій майбутнім лідерам зменшує ефективну затримку включення, але створює додаткове навантаження на мережу та ускладнює логіку RPC-вузлів. Крім того, якщо розклад лідерства змінюється (наприклад, через пропущені слоти), транзакції, надіслані майбутньому лідеру, можуть не досягти фактичного лідера вчасно.

Невизначеність, яку не усуває архітектура:

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

Ця невизначеність не є дефектом архітектури — вона є наслідком компромісів, притаманних будь-якій розподіленій системі з асинхронним консенсусом. Проте вона має бути явно врахована в будь-якій реалізації, яка спирається на статус транзакції. Детальніше про безпекові аспекти — у розділі Безпека Solana.

Що варто перевірити далі

Що можна стверджувати на рівні принципу: шлях транзакції в Solana від підпису до підтвердження є фіксованим конвеєром із визначеними стадіями (вхід у мережу, fetch, verify, signature check, sanitize, batch, execute, голосування, фіналізація). Кожна стадія має власну мету і власні критерії відсіву. Протокол розрізняє три статуси транзакції з різними рівнями гарантій. Існують два основні шляхи входу (через RPC та безпосередньо в TPU) з різними компромісами. Невизначеність для користувача зосереджена між етапами обробки та фіналізації.

Що потребує актуальних даних: будь-які кількісні характеристики шляху — час проходження стадій, частка відсіву, фактична затримка фіналізації, ефективність Gulf Stream у поточних мережевих умовах, різниця в досвіді між RPC та TPU-входом. Для кожного такого твердження необхідні: дата, версія клієнта, середовище вимірювання, метод розрахунку та експертна перевірка.

Наступний логічний крок: для повного розуміння контексту, в якому працює цей конвеєр, варто ознайомитися з тим, як дані організовані в моделі акаунтів Solana — адже саме акаунти є об’єктами, які транзакція змінює на стадії виконання. Загальне уявлення про місце цього шляху в архітектурі доступне в хабі «Під капотом».

Обмеження цього матеріалу. Стаття описує архітектурний дизайн шляху транзакції без прив’язки до конкретної версії клієнта валідатора чи конкретного стану мережі. Вона не містить інструкцій з налаштування, не розглядає конкретні реалізації RPC-провайдерів і не дає рекомендацій щодо вибору точки входу для конкретного випадку використання. Кількісні твердження навмисно не наводяться без датованих первинних даних і опису методології вимірювання.

Редакція солана.укр

Джерела для перевірки. Для перевірки технічних деталей використано документацію Solana про обробку транзакцій.