Приватный мемпул: защита от MEV и скрытые транзакции

Почему приватный мемпул стал базовым требованием

Приватный мемпул — это способ отправить транзакцию в обход публичной очереди, где её содержимое видит любой желающий. В обычном режиме подписанная транзакция сначала попадает в открытый пул ожидания и лежит там, пока её не включат в блок. Между отправкой и включением проходят секунды, иногда минуты, и всё это время состав сделки, сумму и целевой контракт можно прочитать и проанализировать.

Цена такой открытости в том, что очередь читает не только получатель. Наблюдатели распознают крупные обмены и строят вокруг них собственные транзакции — покупку перед вашей и продажу сразу после. Работает это как опережение сделок: вы исполняетесь по худшей цене, а разницу забирает тот, кто успел встать в очередь раньше вас. Чем крупнее объём, тем сильнее фактическая цена уходит от той, на которую вы рассчитывали при подписании, и защита от извлечения стоимости в публичном режиме просто отсутствует.

Приватный мемпул закрывает это окно. Транзакция уходит напрямую тому, кто собирает блок, минуя открытое распространение: до момента включения её не видит никто, кроме исполнителя. Скрытые транзакции раскрываются ровно тогда, когда блок уже собран, — переставить порядок и встроиться рядом технически невозможно, потому что содержимое стало известно слишком поздно.

У схемы есть условия. Нужен доверенный маршрут: если узел-отправитель утечёт содержимое, приватность обнулится. Возможны компромиссы по времени включения и риск, что транзакцию не примет выбранный сборщик — тогда нужен корректный возврат к обычному каналу без потери средств. Разбираем, как это закрывается на уровне маршрутизации, правил сборки блоков и контроля доступа к потоку транзакций.

Измеримый эффект от защищённой отправки

Защищённая отправка измеряется не ощущением спокойствия, а метриками, которые видно в мониторинге: доля успешных транзакций, разброс времени до подтверждения и отклонение фактической цены от расчётной. Приватный мемпул — это стандарт, который первым массово реализовал Flashbots, и эффект от него считается сравнением этих метрик до и после.

Доля неуспешных транзакций

В открытом пуле часть сделок срывается из-за чужой вставки перед вашей: маршрут сдвигается, срабатывает ограничение по цене. Когда заявка уходит к валидаторам напрямую, остаются только отказы, связанные с логикой самого контракта, — доля неуспешных транзакций падает в разы, и её больше не нужно закладывать в запас по лимитам.

Потери при маршрутизации

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

Скорость и предсказуемость подтверждения

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

Стабильность отправки и ушедший класс отказов

При перегрузке сети транзакция не застревает и не отменяется массово — отправка остаётся предсказуемой. Уходит целый класс отказов: фронтраннинг, сэндвич и раскрытие неисполненной стратегии до её публикации.

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

Маршрутизация определяет, кто увидит подпись транзакции до её включения в блок. Как только она попадает в публичный мемпул, поисковые боты успевают прочитать её и перестроить блок под себя — вставкой перед или после. Поэтому выбор маршрута — это компромисс между скоростью доставки, приватностью содержимого и предсказуемостью включения.

На практике маршрут не фиксируют раз и навсегда. Критичные транзакции отправляют напрямую через доверенный узел, фоновые — пакетом, а гибридная схема работает как основа с переключением при деградации одного из путей. Решение принимают по метрикам: доля включения с первой попытки, задержка до попадания в блок и доля транзакций, всё-таки ушедших в публичный мемпул.

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

Порядок внедрения защищённой отправки

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

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

Артефакты и регламенты, которые вы получаете

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

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

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

Клиент — агрегатор ликвидности, который собирал маршрут сделки через несколько пулов. Заявки уходили в публичный мемпул, где боты видели их до включения в блок и оборачивали сэндвич-связкой: покупка перед заявкой, продажа после. Доля опережаемых сделок доходила до 11%, а незапланированные потери съедали около 3% объёма каждого крупного маршрута.

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

Метрики до и после

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

Результат внедрения: сэндвич-связки перестали быть регулярным событием, сокращение потерь держится на объёме, а не выглядит разовым эффектом. Время подтверждения сократилось, потому что заявка больше не ждёт, пока вокруг неё выстроится связка: сборщик получает её сразу и включает в ближайший блок.

Что делать, если транзакция уже попала в публичную очередь?

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

Переотправка спасает в одном случае: транзакция не дошла до сети или истёк срок её жизни в очереди. Если она уже в мемпуле, повторная отправка ничего не меняет — узел видит дубликат по подписи и отбрасывает его, а сроки подтверждения не сдвигаются. Работает другое: провести операцию через приватный мемпул — маршрут, при котором транзакция не попадает в публичное распространение.

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

Остаточный риск оцениваем честно: информация уже утекла. Пока замену не приняла достаточная доля узлов, старая версия остаётся валидной и может попасть в блок первой. Сроки подтверждения никто не гарантирует, поэтому окно между обнаружением и заменой измеряем в секундах.

План на случай сбоя пишется до инцидента. В нём: какой сервис подписывает и отправляет транзакции, куда уходит уведомление о зависшей операции, какой прирост комиссии считаем предельным и через какой таймаут пересобираем сделку заново. Отдельный пункт — как сверяемся по журналам узла, чтобы не отправить вторую замену поверх уже принятой.

Технические сомнения и ограничения подхода

Приватный мемпул не делает транзакцию невидимой — он сужает круг тех, кто видит её до включения в блок. Цена — доверие к оператору приватной отправки, сервисам уровня Flashbots Protect: узел знает содержимое вызова, подпись и адрес отправителя. Модель угроз смещается с фронтраннинга «у всех на виду» на политику логов и доступов конкретного провайдера.

Совместимость ограничена не контрактом, а кошельком и клиентом. Контракт получает обычный вызов с привычными gas и nonce, а маршрут выбирает подписывающая сторона. Если приложение, аппаратный или смарт-кошелёк не умеет пробрасывать транзакцию в приватный канал, она уйдёт публично — и защита не сработает.

Что будет, если приватный маршрут недоступен?

Без заданного поведения по умолчанию транзакция зависает в очереди. Прописываем таймаут и фолбэк — повторную отправку через публичную сеть с повышением комиссии; для чувствительных ко времени операций это обязательный сценарий отказа.

Кто видит данные до подтверждения?

Оператор приватной отправки и сборщики блоков, которым транзакция передаётся на включение. Скрытность не равна анонимности: после попадания в блок адрес, суммы и вызовы публичны. Фиксируем эту границу в модели угроз до старта работ.

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

Чтобы оценка была предметной, а не приблизительной, нам нужны от вас несколько вводных. Они занимают один разговор и пару документов — этого достаточно, чтобы вернуться с планом работ и сроками, а не с общими формулировками.

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

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

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

Следующий шаг — короткий разговор по делу: опишите задачу, и мы вернёмся с оценкой и планом.