Разработчики Ethereum рассматривают новую защиту от хищнических торговых ботов, которые эксплуатируют ожидающие транзакции до того, как они попадут в блокчейн.
Проблема связана с публичным мемпулом Ethereum — прозрачной «комнатой ожидания», где транзакции можно изучить до их выполнения. Эта прозрачность позволяет автоматизированным трейдерам находить прибыльные ордера и размещать собственные транзакции вокруг них, извлекая ценность из пользовательских операций до их завершения.
Такая практика наиболее известна как сэндвич-атаки. Бот отслеживает ожидающий обмен, сначала покупает тот же актив, чтобы сдвинуть цену против пользователя, а затем продает сразу после исполнения сделки жертвы по ухудшенному курсу.
Хотя оценки предполагают, что потери от таких атак снизились по сравнению с прошлыми пиками, проблема полностью не исчезла. В апреле сооснователь Ethereum Виталик Бутерин сам стал целью, когда печально известный бот Jaredfromsubway.eth совершил front-running и back-running небольшого обмена с одного из его адресов.
Сейчас разработчики изучают, может ли шифрование устранить информационное преимущество, делающее эти атаки возможными.
Исследователи протокола запланировали обсуждение этой проблемы на звонке «Encrypt the Mempool» (Зашифровать мемпул) 19 августа, где рассмотрят предложения, направленные на сокрытие содержимого транзакций до тех пор, пока их позиция в блоке не будет зафиксирована.
Эта работа нацелена на давний компромисс для пользователей Ethereum. Трейдеры уже могут обходить публичный мемпул, направляя транзакции через частные ретрансляторы, что снижает их подверженность front-running. Однако такая защита сопряжена с зависимостью от посредников, контролирующих включение и доступность транзакций.
Зашифрованный публичный мемпул попытается сохранить разрешительный доступ к пространству блоков, предотвращая при этом просмотр строителями и ботами базовой сделки до фиксации ее порядка.
Одно из ведущих предложений — EIP-8184, известный как LUCID. Проект требует, чтобы строители блоков фиксировали запечатанные транзакции, содержащие оплачиваемый билет и зашифрованные данные, не зная, что делает транзакция. Только после фиксации отправитель или внешний издатель ключей раскрывает информацию, необходимую для их расшифровки.
Хотя такая конструкция закрывает один путь для эксплуатации, она создает и другую проблему, которую разработчики Ethereum пока не решили.
Дилемма расшифровки
Полностью встроенная схема шифрования должна соответствовать сложному набору ограничений в масштабе Ethereum.
Авторы EIP-8184 перечисляют среди требований: небольшие открытые ключи, неинтерактивную расшифровку, отсутствие доверенной настройки, практичные размеры шифротекста, надежную защиту от атак на основе выбранного шифротекста и правдоподобный путь к квантовой безопасности.
Они заявляют, что ни одна известная криптографическая конструкция в настоящее время не удовлетворяет всему набору требований в масштабе Ethereum.
Поэтому LUCID оставляет конструкцию расшифровки за пределами основного протокола, позволяя отправителям самостоятельно управлять выпуском своих ключей или следовать инструкциям издателя ключей. Это сохраняет гибкость для более надежной криптографии в будущем, но соображения безопасности EIP-8184 явно делают выбор издателя частью модели безопасности пользователя.
Конструкция также создает финансовые обязательства.
Если ключ будет удержан или не поступит вовремя, первоначальная версия LUCID возлагает штраф на уровне протокола за неудачное раскрытие нескольких ключей на отправителя транзакции, а не автоматически переводит его стороннему поставщику ключей.
Чтобы наложить экономические издержки за неудачные раскрытия, LUCID ограничивает свой зашифрованный сегмент верхней части блока одной восьмой газового лимита блока и использует резервную плату. Большая часть этой суммы может быть возвращена после успешной расшифровки, в то время как полный резерв может быть потерян при неудачном раскрытии.
Это делает дорогостоящими неудачные или избирательные раскрытия, но не позволяет установить причину недоставки ключа или определить, утек ли ключ преждевременно по вине издателя.
Авторы описали внешнюю спонсорскую схему, в рамках которой издатель финансирует транзакцию внутри пакета и принимает на себя убытки, если она остается запечатанной. Сам Ethereum не будет обеспечивать это обещание.
Торговые посредники и масштабирование сети
Повестка среды поставит перед разработчиками вопрос: приемлемо ли временное, не постквантовое криптографическое решение.
Она также нацелена на более глубокую проблему принуждения: как можно доказать удержание ключа или преждевременную продажу ключей членами белого списка валидаторов и можно ли автоматизировать такие доказательства.
Белый список может установить, кто уполномочен публиковать ключи. Сам по себе он не может отличить преднамеренное нарушение от сбоя программного обеспечения, задержки в сети или пропущенного срока.
Альтернативное предложение, EIP-8105, использует направленный граф доверия, в котором зарегистрированные поставщики идентифицируют других поставщиков, которым они доверяют. Поставщики могут устанавливать собственные условия удержания, оставляя стимулы, системы надежности и возможные механизмы наказания за пределами правил консенсуса Ethereum.
Другие подходы имеют свои издержки. Пороговая расшифровка распределяет контроль между несколькими участниками, но добавляет временное давление. Доверенное оборудование может сократить путь к ключу, но вводит новые зависимости от оборудования и оператора.
Любое производственное развертывание также должно будет координироваться с более широкой дорожной картой Ethereum. LUCID спроектирован для расширения конвейера списков включения, связанного с FOCIL, или EIP-7805, который дает нескольким валидаторам роль в идентификации транзакций, которые строитель должен включить.
Дорожная карта безопасности Ethereum в настоящее время определяет FOCIL как приоритет на уровне консенсуса для апгрейда Hegotá в 2027 году, в то время как более широкие вехи постквантовой инфраструктуры находятся дальше.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Oluwapelumi Adejumo
