Приватний мемпул: захист від MEV та приховані транзакції

Чому приватний мемпул став базовою вимогою

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

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

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

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

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

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

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

У схеми є умови. Потрібен довірений маршрут: якщо вузол-відправник припуститься витоку вмісту, приватність обнулиться.

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

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

Вимірюваний ефект від захищеного надсилання

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

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

Частка неуспішних транзакцій

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

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

Втрати під час маршрутизації

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

Швидкість і передбачуваність підтвердження

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

Стабільність надсилання й зниклий клас відмов

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

Приватний мемпул: порівняння підходів до маршрутизації

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

Тому вибір маршруту — це компроміс між швидкістю доставки, приватністю вмісту й передбачуваністю включення.

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

Рішення ухвалюють за метриками: частка включення з першої спроби, затримка до потрапляння в блок і частка транзакцій, які все-таки пішли в публічний мемпул.

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

Порядок впровадження захищеного надсилання

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

1. Аудит схеми надсилання. Збираємо, як зараз формуються, підписуються й розсилаються транзакції: вузли, ретранслятори, гаманці, хто бачить підпис до потрапляння в блок. Результат — карта точок витоку й список операцій, уразливих до фронтраннінгу.
2. Проєктування маршрутів. Розділяємо потоки: які операції йдуть через приватний мемпул, які допустимо залишити публічними. Для кожного маршруту фіксуємо пріоритет, час очікування включення й поведінку в разі недоступності каналу.
3. Налаштування каналів і політик доступу. Ключі, ендпоінти, розмежування прав, ізоляція від публічного пулу, ліміти за відправником. Окремо — правила повторного надсилання, щоб транзакція не «розмножилася» в обох пулах.
4. Перевірка на тестовій мережі. Проганяємо сценарії: штатний маршрут, відмова ретранслятора, конкурентна угода на той самий актив, повторне надсилання. Рахуємо частку транзакцій, що дійшли до цільового блоку з очікуваним порядком.
5. Перевірка маршрутів на реальних даних. Відтворюємо минулі угоди й порівнюємо ціну виконання до й після зміни схеми надсилання — розходження показує, де маршрут ще протікає.
6. Передача в експлуатацію. Передаємо конфігурації, схему маршрутів, регламент дій у разі збоїв, дашборди й алерти. Плюс описаний відкат на публічний шлях — на випадок, якщо канал деградує.

Артефакти й регламенти, які ви отримуєте

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

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

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

Кейс: як прибрали сендвіч-атаки на маршрутизації

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

Частка випереджуваних угод сягала 11%, а незаплановані втрати з’їдали близько 3% обсягу кожного великого маршруту.

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

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

Метрики до й після

Заміри звіряли з публічними вимірюваннями MEV-активності — розходження за часткою випереджень залишалися в межах похибки спостереження.

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

Час підтвердження скоротився, бо заявка більше не чекає, поки навколо неї вибудується зв’язка: збирач отримує її одразу й включає в найближчий блок.

Що робити, якщо транзакція вже потрапила в публічну чергу?

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

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

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

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

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

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

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

Окремий пункт — як звіряємося за журналами вузла, щоб не надіслати другу заміну поверх уже прийнятої.

Технічні сумніви й обмеження підходу

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

Модель загроз зміщується з фронтраннінгу «у всіх на виду» на політику логів і доступів конкретного провайдера.

Сумісність обмежена не контрактом, а гаманцем і клієнтом. Контракт отримує звичайний виклик із звичними gas і nonce, а маршрут вибирає сторона, що підписує.

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

Що буде, якщо приватний маршрут недоступний?

Без заданої поведінки за замовчуванням транзакція зависає в черзі. Прописуємо таймаут і фолбек — повторне надсилання через публічну мережу з підвищенням комісії; для чутливих до часу операцій це обов’язковий сценарій відмови.

Хто бачить дані до підтвердження?

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

Обговоримо задачу й повернемося з оцінкою та планом

Щоб оцінка була предметною, а не приблизною, нам потрібні від вас кілька ввідних. Вони займають одну розмову й пару документів — цього достатньо, щоб повернутися з планом робіт і строками, а не із загальними формулюваннями.

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

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

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

Наступний крок — коротка розмова по суті: опишіть задачу, і ми повернемося з оцінкою та планом.