Перетянуть ковёр у MEV: шифрование каждой транзакции против сэндвич-атак в Ethereum

Злонамеренные MEV-атаки остаются серьёзной угрозой для трейдеров в Ethereum. Согласно исследованию, почти 2 000 сэндвич-атак происходят ежедневно, а из сети ежемесячно извлекают более $2 млн. Под риск подпадают даже крупные обмены WETH, WBTC и стейблкоинов — в таких сделках можно потерять значительную долю объёма.

MEV во многом возможен из-за прозрачности блокчейнов: данные транзакций видны до их исполнения и финализации. Один из подходов к снижению MEV — шифрование мемпула, в частности с использованием порогового шифрования. Ранее рассматривались модели с настройкой на эпоху: например, Shutter применял схему, где один ключ использовался для набора блоков, а Batched threshold encryption (BTE) расшифровывал сразу несколько транзакций одним ключом ради меньших издержек и большей пропускной способности.

В этом материале разбирается работа Flash Freezing Flash Boys (F3B) (H. Zhang и др., 2022) — проект порогового шифрования, который предлагает шифровать данные на уровне каждой отдельной транзакции. Рассматриваются принципы работы, свойства масштабирования по задержкам и памяти, а также причины, по которым решение пока не внедрено на практике.

Как F3B реализует шифрование для каждой транзакции

F3B пытается устранить слабое место ранних пороговых схем с «эпохами», когда один ключ шифровал все транзакции внутри фиксированного интервала (например, 32 блока в Ethereum). Проблема в том, что транзакции, не попавшие в нужный диапазон блоков, всё равно могли быть расшифрованы вместе с остальными, раскрывая чувствительные данные и создавая возможности для MEV и фронт-раннинга.

В F3B каждая транзакция остаётся конфиденциальной до достижения финальности. Пользователь шифрует транзакцию ключом, доступ к которому есть только у назначенного порогового комитета — Secret Management Committee (SMC). Затем в консенсус отправляется пара: шифртекст транзакции и зашифрованный ключ (шаг 1). Узлы могут хранить и упорядочивать транзакции, сохраняя метаданные, необходимые для последующей расшифровки и исполнения. Параллельно SMC готовит доли для расшифровки, но не публикует их до тех пор, пока консенсус не зафиксирует транзакцию (шаг 2). После финализации SMC раскрывает достаточное число корректных долей (шаг 3), и консенсус расшифровывает транзакцию и исполняет её (шаг 4).

Долгое время шифрование каждой транзакции считалось непрактичным из‑за вычислительной нагрузки и больших требований к хранению. F3B снижает эти издержки, порогово шифруя не всю транзакцию, а только лёгкий симметричный ключ. Сама транзакция шифруется уже этим ключом. Для простого свопа это может уменьшить объём данных, требующих асимметричного шифрования, примерно до 10 раз.

Две криптографические реализации F3B и их задержки

F3B можно реализовать на базе одного из двух протоколов: TDH2 или PVSS. Они различаются тем, кто и как часто несёт «настройку» системы, насколько фиксирована структура комитета, а также компромиссами по гибкости, задержкам и объёму данных.

В варианте TDH2 (Threshold Diffie-Hellman 2) комитет проводит распределённую генерацию ключей (DKG), получая индивидуальные доли и общий публичный ключ. Пользователь создаёт новый симметричный ключ, шифрует им транзакцию и отдельно шифрует сам симметричный ключ на публичный ключ комитета. После нужного числа подтверждений участники комитета публикуют частичные расшифровки зашифрованного симметричного ключа вместе с NIZK-доказательствами, чтобы защититься от атак с выбранным шифртекстом и подтвердить корректность долей. Консенсус проверяет доказательства, восстанавливает симметричный ключ при достижении порога долей, расшифровывает транзакцию и исполняет её.

Во второй схеме, PVSS (Publicly Verifiable Secret Sharing), вместо DKG в каждой эпохе участники комитета имеют долгосрочные ключи: их публичные ключи записаны в блокчейне и доступны пользователям. Для каждой транзакции пользователь выбирает случайный полином, генерирует доли секрета по схеме Шамира и шифрует каждую долю для выбранного участника его публичным ключом. Симметричный ключ получают хешированием восстановленного секрета. Каждая зашифрованная доля сопровождается NIZK-доказательством, позволяющим проверить, что все доли происходят из одного секрета, а также публичным коммитментом к полиному. Дальнейшие шаги — включение транзакции, раскрытие долей после финальности, восстановление ключа, расшифровка и исполнение — аналогичны варианту TDH2.

TDH2 обычно эффективнее благодаря фиксированному комитету и данным порогового шифрования постоянного размера. PVSS даёт больше гибкости (пользователь может выбирать участников комитета под свою транзакцию), но расплачивается более крупными шифртекстами и большей вычислительной нагрузкой из-за шифрования для каждого участника. В прототипе на моделируемом proof-of-stake Ethereum задержка после финальности для комитета из 128 участников составила 197 мс для TDH2 и 205 мс для PVSS — около 0,026% и 0,027% от 768 секунд финальности Ethereum. Накладные расходы на хранение — порядка 80 байт на транзакцию для TDH2, тогда как у PVSS они растут линейно с числом участников из-за долей, доказательств и коммитментов. Это указывает на возможность обеспечить приватность с минимальным влиянием на производительность и ёмкость сети.

Стимулы и наказания в протоколе F3B

Чтобы мотивировать участников SMC вести себя честно, F3B использует стейкинг с залоченным обеспечением. Вознаграждения стимулируют держать узлы онлайн и поддерживать требуемую производительность. Смарт-контракт со «слэшингом» позволяет конфисковать стейк, если кто-то предъявит доказательство нарушения — например, преждевременной расшифровки. В TDH2 таким доказательством может быть доля расшифровки, публично проверяемая относительно шифртекста. В PVSS доказательство включает расшифрованную долю и персональное NIZK-доказательство, подтверждающее её подлинность. Это повышает цену выявляемого нарушения, но не исключает частный сговор вне цепочки, когда участники могут восстановить и расшифровать данные без публикации долей. Поэтому протокол всё равно опирается на предположение о честном большинстве в комитете.

Поскольку зашифрованные транзакции нельзя исполнить мгновенно, появляется и другой риск: злоумышленник может засорять блокчейн неисполняемыми транзакциями, замедляя подтверждения. Этот вектор характерен для любых схем шифрования мемпула. В F3B пользователь вносит депозит за хранение каждой зашифрованной транзакции: это делает спам дорогим. Депозит удерживается заранее и частично возвращается только при успешном исполнении.

Почему F3B сложно внедрить в Ethereum

F3B предлагает комплексный криптографический способ уменьшить MEV, однако внедрение в Ethereum маловероятно из‑за сложности интеграции. Хотя протокол не меняет консенсус и остаётся совместимым с существующими смарт-контрактами, он требует доработок execution-слоя, чтобы поддерживать зашифрованные транзакции и отложенное исполнение. Это означало бы хардфорк существенно более широкого масштаба, чем обновления после The Merge.

При этом F3B остаётся важной исследовательской вехой и может быть полезен не только для Ethereum. Механизм с минимизацией доверия для обмена приватными данными транзакций применим к новым сетям и dApp, где нужна отложенная обработка. Подходы в стиле F3B могут быть актуальны даже в блокчейнах с субсекундными блоками, чтобы полностью убрать фронт-раннинг на уровне мемпула. В качестве примера применения приводится смарт-контракт sealed-bid аукциона: участники отправляют зашифрованные ставки, которые остаются скрыты до окончания приёма, а затем раскрываются и исполняются после дедлайна, предотвращая манипуляции и утечки информации.

Источник: arXiv (https://arxiv.org/abs/2205.08529)