MEV у Solana: звідки виникає додаткова цінність у порядку транзакцій

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

Що важливо відокремити в технічній частині

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

Теза: додаткова цінність у порядку транзакцій у Solana виникає на перетині трьох компонентів — видимості очікуваних транзакцій, дискреції лідера щодо порядку їх обробки та наявності станів у смарт-контрактах, чутливих до послідовності викликів. Жоден із цих компонентів сам по собі не створює цінності; вона з’являється лише в їхній комбінації.

Межа аналізу: цей матеріал розглядає виключно механізм виникнення цінності з порядку транзакцій. Тут не описується, як ця цінність упаковується в bundles та передається лідеру — це тема окремого матеріалу. Також тут не розглядається, як розподіл MEV-надходжень впливає на економіку liquid staking — це покрито в сусідньому матеріалі кластера. Загальний огляд місця MEV в архітектурі мережі доступний у вступному матеріалі про Jito, MEV і порядок транзакцій.

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

Щоб зрозуміти, звідки береться цінність, потрібно побудувати карту системи: компоненти, їхні зв’язки та наслідки для мережі.

Компоненти системи

Компонент	Роль у формуванні MEV	Протокольний факт vs інтерпретація
Лідер слота	Визначає порядок обробки транзакцій у своєму слоті	Факт: лідер має технічну можливість впорядковувати транзакції. Інтерпретація: лідер обов’язково використовує цю можливість для власної вигоди
Черга транзакцій (transaction queue)	Транзакції, які надійшли до лідера, але ще не оброблені	Факт: транзакції існують у черзі до моменту включення. Інтерпретація: вміст черги повністю видимий для всіх учасників
Стан смарт-контракту	Поточні значення змінних (ціни, ліквідність, баланси)	Факт: стан змінюється послідовно. Інтерпретація: конкретний порядок завжди призводить до передбачуваного фінансового результату
Паралельне виконання (Sealevel engine)	Дозволяє обробляти неконфліктні транзакції одночасно	Факт: Sealevel визначає, які транзакції можуть виконуватися паралельно. Інтерпретація: паралелізм повністю усуває MEV

Зв’язки між компонентами

Цінність порядку виникає не з одного компонента, а з їхньої взаємодії. Ланцюг причинно-наслідкових зв’язків виглядає так:

1. Стан контракту створює можливість. Децентралізована біржа (DEX) утримує пул ліквідності з певним співвідношенням токенів. Цей стан — публічний і детермінований.
2. Транзакція користувача створює видиму наміру. Коли користувач надсилає великий обмінний ордер, ця транзакція потрапляє в чергу лідера. Якщо вміст черги видимий (що залежить від конкретної реалізації інфраструктури, а не від протоколу як такого), інші учасники отримують інформацію про майбутню зміну стану.
3. Порядок обробки визначає результат. Якщо транзакція арбітражника обробляється до транзакції користувача, арбітражник отримує різницю в цінах. Якщо після — користувач отримує кращий курс, але арбітражник може не мати мотивації взагалі виконувати свою транзакцію.
4. Лідер має дискрецію. Саме лідер вирішує, яка транзакція потрапить в обробку першою в межах доступного вікна слота.

Типові сценарії виникнення цінності

Цінність порядку матеріалізується в кількох перевірених класах сценаріїв. Кожен із них має чітку структурну причину:

• Арбітраж між DEX. Різниця цін одного токена на різних біржах. Порядок важливий, тому що перша транзакція змінює стан пулу, роблячи другу менш прибутковою або збитковою.
• Санцінг (sandwich). Розміщення транзакції перед великий ордером користувача та після нього. Цінність створюється виключно порядком: без знання позиції ордера користувача цей сценарій неможливий.
• Ліквідації в кредитних протоколах. Позиція стає підлягає ліквідації при певному співвідношенні забезпечення. Перша транзакція ліквідації отримує винагороду; наступні — ні. Порядок визначає, хто саме отримає цю винагороду.
• Mint NFT із обмеженою пропозицією. Коли попит перевищує пропозицію в межах одного слота, перші транзакції отримують актив, останні — ні. Цінність порядку тут дорівнює різниці між ринковою ціною NFT та ціною mint.

Чому паралельне виконання не усуває MEV

Поширена інтерпретація полягає в тому, що Sealevel — рушій паралельного виконання в Solana — нівелює проблему порядку транзакцій. Це потребує точного розмежування.

Протокольний факт: Sealevel дозволяє одночасно виконувати транзакції, які не звертаються до одних і тих самих облікових записів (accounts). Якщо транзакція А змінює стан акаунту X, а транзакція Б змінює стан акаунту Y, вони можуть оброблятися паралельно.

Інтерпретація, що потребує перевірки: «Паралелізм зменшує MEV». Це може бути правдою для транзакцій, що не перетинаються за станом. Але для транзакцій, що звертаються до одного пулу ліквідності (один і той самий акаунт), паралельне виконання неможливе — вони мають оброблятися послідовно, і порядок залишається визначальним.

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

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

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

Що можна вважати протокольним фактом

• Лідер слота в Solana технічно контролює порядок транзакцій у своєму слоті.
• Транзакції мають поле compute_unit_price, що дозволяє вказати пріоритет через плату за обчислення.
• Протокол не містить вбудованого механізму аукціону порядку транзакцій на рівні консенсусу.
• Sealevel виконує транзакції паралельно, якщо вони не конфліктують за обліковими записами.

Що є інтерпретацією або потребує верифікації

• Обсяг MEV у доларах. Будь-яка цифра залежить від того, що саме рахується: лише арбітраж, чи включаючи санцінг, ліквідації, mint. Метод розрахунку «різниця цін до і після транзакції» дає різні результати порівняно з «комісія, сплачена за включення». Без фіксації методології цифра не є фактом.
• Частка санцінгу від загального MEV. Залежить від класифікації: чи рахувати транзакції, де арбітражник випадково опинився між двома ордерами, як санцінг.
• Вплив MEV на досвід кінцевих користувачів. Позиція «MEV шкідливий для користувачів» є інтерпретацією. Протокольний факт: санцінг змінює ціну виконання для жертви. Інтерпретація: ця зміна є чистим збитком (бо без арбітражника розбіжність цін між біржами зберігалася б довше, що також має наслідки).

Позиції ключових сторін

Сторона	Загальна позиція	Що є фактом у цій позиції	Що є інтерпретацією
Валідатори	MEV-надходження компенсують низькі комісії протоколу	Валідатори можуть отримувати додаткові платежі поза межами протокольних комісій	Ці надходження є стабільним і достатнім джерелом доходу
MEV-шукачі (searchers)	Вони забезпечують ефективність ринку, усуваючи арбітражні можливості	Їхні транзакції змінюють стани пулів у напрямку зменшення різниці цін	Суспільна користь від їхньої діяльності перевищує приватні витрати інших учасників
Розробники протоколів (DEX, кредитні)	MEV створює ризики для користувачів їхніх продуктів	Порядок транзакцій впливає на ціну виконання в їхніх контрактах	Вирішення проблеми MEV має відбуватися на рівні їхнього протоколу, а не на рівні мережі
Кінцеві користувачі	MEV — це прихований податок	Їхні транзакції можуть виконуватися за гіршою ціною через дії третіх осіб	Без MEV їхній досвід був би кращим (це не можна перевірити без контрфактичного сценарію)

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

Компроміс між ефективністю ринку та справедливістю виконання

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

Компроміс між централізацією лідерства та MEV-оптимізацією

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

Ризик невизначеності видимості черги

Механізм виникнення цінності з порядку частково залежить від того, наскільки вміст черги транзакцій видимий для третіх осіб. Ця видимість не є властивістю протоколу Solana — вона визначається конфігурацією конкретного валідатора, налаштуваннями RPC-вузлів та інфраструктурними рішеннями. Отже, ступінь «прозорості» для MEV-шукачів є змінним параметром, а не фіксованою характеристикою мережі. Будь-яке твердження про поточний рівень видимості потребує верифікації в конкретному середовищі.

Невизначеність довгострокового ефекту

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

Висновок і наступна перевірка

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

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

Що потребує наступної перевірки перед використанням цього матеріалу:

• Актуальна специфікація механізму пріоритезації транзакцій у клієнті (з версією та посиланням на репозиторій).
• Емпіричні дані про частку транзакцій, що виконуються послідовно (конфліктують за стан) порівняно з паралельними, у типовому слоті.
• Аналіз розподілу MEV-надходжень між валідаторами для оцінки ризику централізації.
• Документація інфраструктурних рішень (зокрема Jito) щодо видимості черги транзакцій.

Логічний наступний крок у кластері: оскільки цей матеріал описав, звідки виникає цінність порядку, наступний — Що таке bundles і як вони змінюють виконання складних операцій — пояснює, як ця цінність упаковується та передається лідеру через механізм bundles, змінюючи саму модель виконання транзакцій.

Для розуміння загального контексту архітектури мережі рекомендується розділ «Під капотом». Якщо вас цікавить практичний вимір — які продукти в екосистемі працюють з урахуванням MEV-механізмів — дивіться Продукти Solana: що працює для людей. Питання безпеки, пов’язані з взаємодією з MEV-інфраструктурою, покриті в Безпека Solana: спокійно, конкретно, перевірено.

Обмеження цього матеріалу: редакція «солана.укр» не проводила незалежного аудиту MEV-потоків, не тестувала інфраструктуру видимості черг і не верифікувала конкретні цифри обсягів MEV. Усі кількісні твердження відсутні навмисно — їхня наявність без підтвердженої методології створила б хибне відчуття точності. Цей матеріал описує структурні механізми та межі знань, а не поточний стан ринку.

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