Як формується блок і хто впливає на порядок транзакцій

Що відбувається під капотом

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

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

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

Як це працює в системі

Місце блоку в життєвому циклі мережі

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

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

Отже, формування блоку — це не колективне рішення мережі. Це дія одного вузла в межах його тимчасового вікна.

Шлях транзакції до блоку

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

Стадія TPU	Функція	Що відбувається з транзакцією
Fetch	Прийом	Транзакція надходить від користувача через RPC-вузол або безпосередньо на TPU лідера за протоколом UDP
Verify	Базова валідація	Перевірка формату, наявності обов’язкових полів, відповідності структурі мережі
Signature Verify	Перевірка підпису	Криптографічна перевірка підпису відправника (зазвичай з використанням GPU)
Banking Stage	Впорядкування й виконання	Транзакція потрапляє до черги лідера, де визначається її місце відносно інших транзакцій, після чого виконується проти поточного стану банку
PoH Recording	Запис у хронологію	Хеш транзакції записується в потік Proof of History, що фіксує її порядок у часі
Broadcast	Розсилка	Сформований блок передається іншим валідаторам для перевірки й голосування

Ключовий момент: саме на стадії Banking Stage лідер приймає рішення про порядок транзакцій. Усі попередні стадії не впливають на те, яка транзакція буде виконана першою — вони лише фільтрують некоректні повідомлення.

Роль лідера в порядку транзакцій

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

Проте є протокольні обмеження, які лідер не може порушити:

• Залежність за станом. Якщо транзакція А змінює стан акаунту X, а транзакція Б читає стан того самого акаунту, вони не можуть бути виконані паралельно. Порядок між ними визначає кінцевий результат, і лідер зобов’язаний забезпечити коректну послідовність.
• Блокування акаунтів. Під час виконання транзакції акаунти, до яких вона звертається, блокуються. Інша транзакція, що потребує той самий акаунт, мусить чекати розблокування. Це механізм ізоляції на рівні запису (write-lock).
• Коректність виконання. Кожна транзакція у блоку має завершитися успішно або з визначеною помилкою. Лідер не може змінити логіку програм — він лише визначає, в якому порядку їх викликати.

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

Підтвердження блоку й голосування валідаторів

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

1. Отримання блоку. Валідатор отримує блок від лідера або від інших вузлів мережі.
2. Перевірка PoH. Валідатор перевіряє, чи хронологія блоку коректно продовжує попередній блок у ланцюгу.
3. Повторне виконання. Валідатор виконує всі транзакції блоку самостійно, щоб переконатися, що результати збігаються з заявленими лідером.
4. Голосування. Якщо перевірка пройдена, валідатор надсилає голос за цей блок.

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

Супермажоритарність голосів (понад дві третини загального стейку) призводить до фіналізації блоку. Після фіналізації порядок транзакцій у ньому є незмінним.

Хто ще, крім лідера, впливає на порядок

Прямий контроль належить лідеру, але інші учасники мережі мають непрямі інструменти впливу:

• Користувачі можуть встановлювати пріоритетну комісію (compute unit price) — вищий пріоритет створює економічний стимул для лідера поставити транзакцію раніше. Проте це не є гарантією: лідер не зобов’язаний сортувати саме за цим параметром.
• MEV-пошукачі формують пакети транзакцій, де порядок внутрішньо узгоджений, і передають їх лідеру як єдиний комплекс. Це зсуває конкуренцію за порядок з рівня окремих транзакцій на рівень пакетів.
• RPC-провайдери можуть маршрутизувати транзакції до конкретних лідерів або використовувати спеціалізовані канали подачі, що впливає на те, який лідер і коли отримає транзакцію.

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

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

Описана вище архітектура базується на специфікації протоколу Solana та відкритому коді основного клієнта (Agave). Для перевірки конкретних параметрів реалізації необхідно звертатися до таких класів джерел:

• Офіційна документація Solana — розділи про консенсус, TPU та формування блоків
• Репозиторій клієнта Agave — реалізація стадій TPU та Banking Stage
• SIMD-пропозиції — зміни до механізмів упорядкування, якщо такі пропонувалися або впроваджувалися
• Дані експлорерів мережі — для спостереження за фактичним порядком транзакцій у реальних блоках

Редакція солана.укр не має підтверджених даних про поточні частки блоків, сформованих із використанням MEV-пакетів, або про конкретні алгоритми сортування, які використовують провідні лідери. Ця інформація змінюється з часом і потребує перевірки за актуальними даними мережі на момент читання.

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

Слабкі місця й компроміси

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

Перевага	Відповідний компроміс
Висока швидкість формування блоку — один вузол приймає рішення без координації	Одиниця відмови: якщо лідер маніпулює порядком, мережа не може цього запобігти на етапі формування
Простота протоколу — немає потреби в складних алгоритмах консенсусного впорядкування	Економічна асиметрія: лідер екстрактує цінність із порядку (MEV), а користувачі несуть витрати
Детермінованість — порядок фіксується одноразово й не переглядається	Відсутність справедливості за замовчуванням: протокол не гарантує FIFO-порядок чи будь-яку іншу нейтральну схему
Передбачуваність розпису — лідери знають свої слоти заздалегідь	Цілеспрямовані атаки: зловмисник, який стає лідером, може планувати маніпуляції заздалегідь

Основний ризик — це MEV (Maximal Extractable Value). Оскільки лідер контролює порядок, він може виявляти арбітражні можливості, фронтранити транзакції користувачів або переставляти транзакції так, щоб максимізувати власний дохід. Протокол не забороняє цю поведінку — вона є наслідком архітектурного рішення.

Невизначеність існує в кількох вимірах:

• Алгоритми сортування в Banking Stage можуть відрізнятися між реалізаціями клієнтів (Agave, Firedancer та інші). Протокол визначає правила валідності, але не диктує алгоритм вибору порядку.
• Ефективність MEV-захисту (наприклад, механізми, що обмежують можливості лідера) залежить від конкретних впроваджень, які змінюються з часом.
• Вплив RPC-проміжних вузлів на порядок транзакцій недостатньо документований і важко піддається кількісній оцінці без прямого спостереження.

Практичний висновок

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

Ця архітектура є свідомим компромісом між швидкістю та централізацією контролю над порядком. Розуміння цього компромісу необхідне для оцінки ризиків при розробці продуктів (особливо DeFi-протоколів, чутливих до порядку виконання) та для обґрунтованого вибору інструментів подачі транзакцій.

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

• Актуальні параметри слота та обмеження блоку — за офіційною документацією та конфігурацією мережі на момент читання
• Поточний стан впроваджень щодо захисту від MEV — за SIMD-пропозиціями та реліз-нотатками клієнтів
• Реальний порядок транзакцій у недавніх блоках — за даними експлорерів, щоб порівняти теоретичну модель з практикою

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

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

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