В сообществе Ethereum обсуждается новый EIP для внедрения зашифрованного mempool на уровне протокола с целью ограничения front running, sandwiching и рисков цензуры.
Summary
Цели и контекст предложения
Новый EIP нацелен на интеграцию в протокол mempool с зашифрованными транзакциями до их включения в блок. Цель — защитить пользователей от злонамеренного переупорядочивания транзакций и усилить устойчивость к цензуре в реальном времени, не стремясь к полной конфиденциальности.
Транзакции, однако, становятся публичными после включения в блокчейн. Кроме того, предложение направлено на снижение регуляторных рисков для block builder и других операторов, которые временно «ослеплены» содержимым операций до публикации ключей расшифровки.
Работа основывается на предыдущих экспериментах, таких как Shutterized Beacon Chain и уже активная реализация на Gnosis Chain, где существует зашифрованный mempool вне протокола. По мнению авторов, механизм решает историческую проблему front running и может смягчить побочные эффекты MEV, такие как централизация builder.
Интеграция с дорожной картой и ePBS
Предложение разработано для естественной интеграции с proposer-builder separation enshrined (ePBS), предусмотренной в дорожной карте Ethereum. В этом контексте структурное разделение между теми, кто предлагает и строит блоки, сочетается с уровнем шифрования, который ограничивает преждевременную видимость содержимого транзакций.
Тем не менее, поддерживаются и открытые транзакции, чтобы гарантировать непрерывную работу сети. Даже в случае сбоев или отказов поставщиков ключей, прогресс цепи сохраняется, избегая блокировок или прерываний консенсуса.
Техническая структура: реестр поставщиков ключей
На уровне исполнения вводится специальный контракт, реестр поставщиков ключей. Любой аккаунт может зарегистрироваться как поставщик ключей, получив уникальный ID. На этапе регистрации необходимо указать контракт с двумя функциями: расшифровка и валидация ключа, обе параметризованы ID ключа и сообщением.
Поставщики также могут отмечать других провайдеров как «непосредственно доверенных», создавая таким образом прямой граф доверия. Провайдер A считается доверяющим B, если существует прямой путь от A к B. Beacon Chain реплицирует состояние реестра, аналогично управлению депозитами.
Таким образом, инфраструктура остается агностичной по отношению к используемой криптографической технологии: допускаются модели, основанные на threshold encryption, MPC, TEEs, delay encryption или FHE. Однако многие из этих схем малоэффективны для выражения в EVM и потребовали бы специальных препроцессоров, оставленных за рамками EIP.
Новый тип зашифрованной транзакции
Протокол вводит новый тип транзакции: зашифрованную. Она состоит из конверта (envelope) и зашифрованного payload. Конверт содержит nonce конверта, газ, параметры цены газа, ID поставщика ключей, ID ключа и подпись конверта.
Зашифрованный payload включает в себя nonce payload, передаваемую стоимость, calldata и подпись на payload. Кроме того, модель предусматривает точные правила упорядочивания в блоке: зашифрованная транзакция с ключом провайдера A может быть предшествована только открытыми транзакциями, зашифрованными транзакциями с ключами A или провайдеров, которым A доверяет.
В каждом слоте, когда поставщик ключей наблюдает за опубликованным builder payload исполнения, он собирает все ID ключей, относящиеся к зашифрованным транзакциям, адресованным ему. Для каждого из них он должен опубликовать либо соответствующий ключ расшифровки, либо уведомление о удержании ключа.
Роль Payload Timeliness Committee и аттестации
Сообщение, которое переносит ключи, ссылается на хэш блока beacon, чтобы предотвратить повторное использование в будущих слотах. Провайдеры могут публиковать ключи, как только они наблюдают за payload исполнения, или задерживать публикацию до более позднего момента в том же слоте.
Члены Payload Timeliness Committee (PTC) должны отслеживать ключи расшифровки, относящиеся ко всем зашифрованным транзакциям, идентифицированным по ID провайдера и ID ключа. Затем они должны проверить эти ключи, используя функцию валидации реестра, с небольшим предопределенным лимитом газа для каждого ключа.
Наконец, PTC должен подтвердить наличие или отсутствие действительного ключа для каждой зашифрованной транзакции, расширяя сообщение аттестации payload с помощью специального битового поля. Таким образом, сеть имеет on-chain реестр состояния ключей в каждом блоке.
Исполнение конвертов и зашифрованных payload
Во время обработки payload исполнения, после всех открытых транзакций, конверты зашифрованных транзакций выполняются пакетно. Это обновляет nonce подписантов и оплачивает комиссии с аккаунтов, связанных с конвертами.
Комиссии покрывают использование пространства блока, используемого конвертами, расшифрованными payload и ключами, а также вычисления для расшифровки и валидации. Затем payload расшифровываются с использованием ключа, идентифицированного по ID поставщика ключей и ID ключа, через функцию расшифровки в реестре.
Если расшифровка проходит успешно, полученные транзакции выполняются в пределах газа, указанного на конвертах, и в соответствии с block gas limit. Однако, если расшифровка или выполнение не удаются, или если PTC подтверждает отсутствие действительного ключа, payload пропускается без отката на конверте.
Дизайн-решения и влияние на порядок транзакций
Регистрация поставщиков ключей намеренно агностична по отношению к криптографической схеме, чтобы обеспечить нейтральность и низкие барьеры для входа. Кроме того, выбор использования контракта на уровне исполнения предоставляет канонический способ определения произвольной логики, хотя управление только на consensus layer было бы возможным.
Граф доверия между провайдерами отвечает конкурентной потребности. Если бы каждый пользователь доверял только своему провайдеру, builder могли бы включать в каждый блок зашифрованные транзакции, связанные только с одним субъектом, способствуя риску монополии. Управление доверием со стороны провайдеров снижает сложность для пользователей.
Кроме того, предложение фактически сегментирует блок на две секции: открытые транзакции и зашифрованные транзакции. Первые вставляются первыми, чтобы builder могли симулировать их выполнение и применять текущие техники построения блоков и извлечения MEV.
Гарантии по оплате газа и расшифровке транзакций
Эта структура позволяет builder добавлять зашифрованные транзакции в конец без потерь возможностей. Если бы порядок был обратным, комиссии за зашифрованные транзакции должны были бы быть значительно выше, чтобы сделать блоки конкурентоспособными по сравнению с только открытыми.
Чтобы избежать включения payload, неспособных оплатить газ, оплата комиссий осуществляется полностью через конверт, и все конверты выполняются перед payload. Этот выбор исключает возвраты газа, гарантируя builder и протоколу определенный доход в момент построения блока.
Для простоты, payload включает специальную подпись. В качестве альтернативы, менее приватной, но более эффективной, можно рассматривать подписанта конверта как отправителя транзакции, снижая криптографическую сложность.
Управление удержанием ключей расшифровки
Протокол явно позволяет поставщикам ключей удерживать ключи расшифровки в соответствии с условиями, определенными ими. Это позволяет применять правила доступа, например, связанные с предыдущими платежами, или предотвращать специфические атаки, такие как атака на key ID.
С другой стороны, ключи, удерживаемые без обоснования, могут использоваться в пользовательских механизмах slashing или в метриках надежности. Протокол регистрирует, какие ключи были опубликованы, а какие нет, создавая проверяемую базу данных для возможных экономических стимулов вне цепи.
Предложение не вводит экономических стимулов в протоколе для провайдеров, ни явных наказаний за злонамеренное поведение. Это оставляет пространство для различных бизнес-моделей: соглашения с builder, платежи за транзакцию от пользователей или управление как общественное благо.
Будущие гипотезы: шифрование payload исполнения
В перспективе, последующий EIP может позволить builder использовать те же ключи для шифрования непосредственно payload исполнения. В этом сценарии builder могли бы публиковать только что построенный payload, вместо ожидания середины слота, улучшая эффективность p2p.
Кроме того, в сочетании с доказательством с нулевым разглашением о ключах, использованных в блоке, этот механизм позволил бы ускорить начало временного окна раскрытия ключей, увеличивая его в целом. Однако такие расширения намеренно исключены из текущего предложения, чтобы сдерживать сложность.
В целом, EIP вводит несовместимые изменения как в слой исполнения, так и в consensus layer, требуя, таким образом, координированного hard fork для возможной активации.
Риски безопасности и доверие к поставщикам ключей
Что касается безопасности, пользователи должны обязательно доверять выбранным провайдерам для шифрования транзакций, как для предотвращения преждевременной публикации ключей, что позволило бы front running и sandwiching, так и для предотвращения задержек, которые блокировали бы выполнение, несмотря на оплату конверта.
Это доверие может основываться на криптографических механизмах, таких как threshold или hardware encryption, на экономических механизмах, таких как slashing, или на социальных механизмах, например, с голосованием для выбора надежных сущностей.
В меньшей степени, отправляющий зашифрованные транзакции должен также доверять провайдерам, использованным для предыдущих транзакций в блоке. Эти последние могут выбирать, публиковать или удерживать свои ключи после того, как увидят ключи, относящиеся к последующим транзакциям, получая влияние на предыдущее состояние.
Потенциальные атаки: от reorg до key ID front running
Действия провайдеров могут стать более опасными, если будут приняты злонамеренные схемы «расшифровки», позволяющие целенаправленные изменения результата с использованием специально сконструированных ключей. В крайних случаях это позволило бы напрямую устанавливать содержимое payload, открывая путь к сложным формам front running.
Пользователи, однако, не должны доверять провайдерам, использованным для последующих транзакций, поскольку предыдущее состояние их операций не зависит от последующих payload. Кроме того, отправляющий открытые транзакции остается подвержен только доверию к builder, как в текущей модели.
Дополнительный риск связан с reorg: ключи публикуются до того, как соответствующие транзакции будут завершены. В случае реорганизации цепи транзакция может стать публичной без включения. Однако, поскольку сообщение ключа включает хэш блока, функция валидации может сделать его недействительным в новом контексте.
Меры против атак на key ID
Этот механизм не препятствует включению конверта, но блокирует выполнение payload, предотвращая front running. Однако остается специфический вектор атаки, key ID front running, когда злоумышленник наблюдает за зашифрованной транзакцией в пути и отправляет вторую транзакцию, использующую того же провайдера и key ID.
Если эта вторая операция будет включена первой, наивный провайдер раскроет ключ, обнажая содержимое оригинальной транзакции, еще не включенной. Чтобы смягчить атаку, провайдеры могут применять «namespacing» key ID, выпуская ключи только для ID, префиксированных адресом подписанта конверта.
Поскольку разумно предположить, что атакующий не имеет доступа к этому аккаунту, он не сможет создать транзакцию с правильно namespacированным key ID. Таким образом, риск key ID front running существенно снижается.
Сговор между поставщиками ключей и builder
Другой сценарий риска — сговор между поставщиками ключей и builder. Для построения нового блока последние должны знать пост-состояние предыдущего блока, то есть все использованные и удержанные ключи, информация, которая становится публичной после аттестации PTC.
Однако злонамеренный провайдер может дать предварительное уведомление конкретному builder, предоставив ему конкурентное преимущество в начале построения блока. По анализу авторов, влияние ограничено, поскольку интервал между публикацией аттестаций и концом слота считается достаточным для построения блока.
Кроме того, начало окна построения менее критично, чем конец, когда известен полный набор транзакций, которые можно включить. Задержка публикации ключей также увеличивает риск того, что они не будут аттестованы PTC, сводя на нет преимущество атакующего, особенно если количество транзакций, связанных с сговорившимся провайдером, невелико.
Общие последствия для Ethereum
В целом, предложение EIP зашифрованного mempool направлено на повышение защиты пользователей от front running и sandwiching, снижение централизации, связанной с MEV, и улучшение устойчивости к цензуре в реальном времени. Однако оно вводит новые уровни сложности и зависимости от внешних инфраструктур управления ключами.
По сравнению с текущим состоянием, механизм переносит часть доверия от рыночных участников, таких как builder, к поставщикам ключей, которые становятся критически важными субъектами как с технической, так и с управленческой точки зрения. Текущая дискуссия в сообществе определит, если, когда и с какими изменениями эта архитектура может быть фактически принята на основной сети Ethereum.
