Шкідливий MEV (Maximal Extractable Value) у Solana — це екстракція додаткової вартості з транзакцій користувачів шляхом маніпуляції порядком їхнього включення в блок. На відміну від Ethereum, де MEV переважно формується в mempool, у Solana архітектура створює інші вектори атак, але кінцевий результат для жертви тотожний: гірша ціна обміну, завищені комісії чи непередбачуване виконання транзакції. Нижче розібрано конкретні механіки шкідливого MEV, причини вразливості Solana та наявні інструменти пом'якшення.
Типи шкідливого MEV
Front-running: перехоплення транзакцій
Front-running — це включення власної транзакції перед транзакцією жертви з метою отримання вигоди від відомої майбутньої зміни стану. У контексті Solana це означає, що валідатор-лідер або пов'язана з ним сутність бачить вхідну транзакцію (наприклад, великий обмін на DEX) і вставляє власну купівлю того ж токена до неї. Після виконання транзакції жертви ціна зростає, і атакуючий фіксує прибуток.
Факт. У Solana немає публічного mempool у розумінні Ethereum. Транзакції надсилаються безпосередньо поточному лідеру слота (або через gossip-протокол до нього). Це означає, що можливість front-run обмежена тим, хто саме є лідером у цей момент, або сторонами, які мають пріоритетний доступ до вхідного потоку лідера.
Прогноз. З ростом кількості валідаторів, що інтегрують MEV-інфраструктуру, частота front-running на рівні лідера може зростати, доки не запрацюють протокольні механізми шифрування транзакцій.
Sandwich attack: маніпуляція ціною для користувача
Sandwich attack — це комбінація front-running та back-running. Атакуючий розміщує транзакцію купівлі перед транзакцією жертви (front-run) і транзакцію продажу після неї (back-run). Користувач отримує гіршу ціну обміну, а різниця (spread) переходить до атакуючого.
Механіка в Solana. Коли користувач надсилає swap-транзакцію із заданим slippage tolerance (допустимим відхиленням ціни), атакуючий розраховує обсяг, який можна витиснути в межах цього slippage. Наприклад, якщо користувач встановив slippage 1% на обмін 1000 SOL на токен, атакуючий може спробувати забрати до 1% від цієї суми шляхом точного розрахунку обсягів власних транзакцій.
Обмеження. Ефективність sandwich-атаки в Solana залежить від ліквідності пулу, розміру транзакції жертви та встановленого slippage. На низьколіквідних парах із високим slippage атака найприбутковіша, але й найпомітніша.
Just-in-time liquidity: штучна ліквідність перед великою транзакцією
Just-in-Time (JIT) liquidity — це створення тимчасового позиції ліквідності в пулі безпосередньо перед великою транзакцією користувача, а її згортання одразу після. Атакуючий додає ліквідність, отримує частку від комісії великого обміну та вилучає свою ліквідність у тому ж блоці.
Факт. Цей тип MEV технічно відрізняється від sandwich-атаки, оскільки атакуючий не маніпулює ціною безпосередньо, а екстрагує комісійний дохід, який інакше отримали б постійні провайдери ліквідності. Проте для кінцевого користувача наслідки подібні: частина вартості його транзакції перерозподіляється на користь третіх осіб.
Думка. Деякі дослідники розглядають JIT-ліквідність як суміжну з ринковиммейкінгом діяльність, оскільки вона тимчасово покращує ціновий вплив для користувача порівняно з ситуацією без додаткової ліквідності. Проте без згоди користувача та без прозорого розподілу комісії це залишається формою екстракції MEV.
Чому Solana вразлива до MEV
Централізований ordering лідером
У кожному слоті Solana є єдиний лідер, який має монопольне право на впорядкування транзакцій у блоці. Лідер формує блок із транзакцій, які отримав протягом свого слота, і вирішує, в якому порядку їх включити. Це створює фундаментальну вразливість: будь-хто, хто контролює лідера або має привілейований доступ до його вхідної черги, може маніпулювати порядком транзакцій.
Факт. Ротація лідерів у Solana відбувається кожні 400 мс (за стандартних умов), тому вікно для MEV-екстракції обмежене тривалістю одного слота. Це відрізняє Solana від Ethereum, де ordering може відбуватися протягом 12 секунд.
Альтернативна позиція. Деякі інженери стверджують, що коротке вікно слота зменшує шкоду від MEV, оскільки атакуючий має менше часу на розрахунок і розгортання багатотранзакційних атак. Проте на практиці складні атаки готуються заздалегідь, а виконання в межах 400 мс є технічно реалізовним для підготовлених інфраструктур.
Відсутність mempool: як це змінює вектори атак
У Solana транзакції не транслюються всій мережі перед включенням у блок. Вони надсилаються безпосередньо поточному лідеру через gossip-протокол або через RPC-ноди, які можуть бути пов'язані з конкретними валідаторами. Це усуває класичний вектор атаки, характерний для Ethereum, де будь-який учасник мережі може бачити транзакції в mempool та готувати відповідні контртранзакції.
Факт. Відсутність публічного mempool зменшує кількість потенційних атакуючих, але концентрує MEV-можливості в руках поточного лідера та операторів RPC-нод, через які проходять транзакції.
Обмеження. Точний розподіл MEV-екстракції між лідерами, RPC-операторами та пошуковиками (searchers) у Solana наразі не має відкритих агрегованих даних. Читачеві слід перевіряти актуальні звіти Jito та незалежних дослідників для оцінки масштабів.
Методи захисту та пом'якшення
Private mempools та Jito як часткове рішення
Private mempools (приватні черги транзакцій) дозволяють надсилати транзакції без їхнього розкриття широкому колу учасників до моменту включення в блок. У контексті Solana інфраструктура Jito пропонує механізм bundle-передачі, де транзакції передаються лідерам у зашифрованому вигляді та розкриваються лише після включення.
Факт. Jito bundle-система дозволяє об'єднувати кілька транзакцій у атомарний пакет із вказаним tip (підказкою) для лідера. Це зменшує можливість окремого front-running кожної транзакції з пакета, оскільки лідер отримує винагороду за включення всього bundle, а не за маніпуляцію порядком всередині нього.
Обмеження. Private mempools не усувають MEV повністю. Лідер все одно вирішує, включати bundle чи ні, і може відхилити його на користь власної атаки. Крім того, якщо користувач надсилає транзакцію через звичайний RPC без bundle-механізму, вона залишається вразливою.
Протокольні механізми захисту
На рівні протоколу Solana існують та розробляються кілька підходів до обмеження шкідливого MEV:
- Шифрування транзакцій. Ідея полягає в тому, що транзакція шифрується так, що лише лідер може її розшифрувати, але не може прочитати її вміст до моменту включення. Це ускладнює цілеспрямований front-running. Станом нині повноцінне шифрування транзакцій на рівні консенсусу Solana не активоване — читачеві слід перевіряти актуальний статус відповідних SIMD-пропозицій.
- Ротіяція лідерів та таймаути. Короткі слоти (400 мс) та детермінована ротація лідерів обмежують час, протягом якого один учасник може екстрагувати MEV. Це не усуває атаки, але підвищує їхню вартість та складність.
- Відстеження та репутація. Деякі пропозиції передбачають системи моніторингу поведінки лідерів із подальшими репутаційними наслідками. Проте такі механізми наразі не мають протокольного примусового виконання в Solana.
Прогноз. Ефективне протокольне рішення для захисту від шкідливого MEV в архітектурі з єдиним лідером на слот, ймовірно, вимагатиме форми порогового шифрування (threshold encryption) або зміни моделі ordering. Терміни реалізації таких змін наразі невизначені.
Поради для користувачів та розробників
Поки протокольні рішення не усувають шкідливий MEV повністю, учасники екосистеми можуть застосовувати практичні заходи:
- Мінімізувати slippage tolerance. Зниження допустимого відхилення ціни прямо зменшує маржу sandwich-атаки. Наприклад, встановлення slippage 0.3% замість 1% зменшує потенційну шкоду, але підвищує ризик невиконання транзакції (revert) у волатильних ринкових умовах.
- Використовувати private submission. Надсилання транзакцій через інфраструктуру, що підтримує bundle-передачу (наприклад, Jito), зменшує видимість транзакції для потенційних атакуючих до моменту включення.
- Розбивати великі ордери. Замість одного великого swap-у виконання кількох менших транзакцій зменшує привабливість для атакуючих, оскільки прибуток від кожної окремої атаки знижується, а складність координації зростає.
- Для розробників DEX: впроваджувати механізми захисту на рівні смарт-контрактів, такі як обмеження часткових заповнень (partial fills), використання TWAP-оракулів для цінових перевірок та інтеграція з private mempool-інфраструктурою на рівні маршрутизації.
- Для розробників протоколів: розглядати дизайн, який уникає детермінованих наслідків від порядку транзакцій у межах одного слота, або використовувати commit-reveal схеми там, де це сумісно з вимогами до латентності.
Обмеження. Жоден із перелічених методів не гарантує повного захисту. Комбінація мінімального slippage, private submission та розбиття ордерів суттєво зменшує ймовірність та розмір шкоди, але не усуває ризик повністю, особливо для транзакцій у низьколіквідних пулах.