Пектра 7702

Аннотация

EIP-7702 определяет механизм добавления кода в EOA. Это предложение позволяет EOA, традиционным аккаунтам Эфириума, получать краткосрочные улучшения функциональности, повышая удобство использования приложений. Это делается путем установки указателя на уже развернутый код с использованием нового типа транзакции: 4.

Этот новый тип транзакции вводит список авторизации. Каждый кортеж авторизации в списке определяется как

[ chain_id, address, nonce, y_parity, r, s ]

address — это делегирование (уже развернутый байт-код, который будет использоваться EOA) chain_id привязывает авторизацию к определенной цепи (или 0 для всех цепей) nonce привязывает авторизацию к определенному нонсу аккаунта (y_parity, r, s) — это подпись кортежа авторизации, определяемая как keccak(0x05 || rlp ([chain_id, address, nonce])) приватным ключом EOA, к которому применяется авторизация (также называемому центром авторизации)

Делегирование можно сбросить, делегировав нулевому адресу.

Приватный ключ EOA сохраняет полный контроль над аккаунтом после делегирования. Например, делегирование Safe не делает аккаунт мультисигом, поскольку по-прежнему существует один ключ, который может обойти любую политику подписания. В дальнейшем разработчики должны проектировать с учетом того, что любой участник системы может быть смарт-контрактом. Для разработчиков смарт-контрактов больше небезопасно предполагать, что tx.origin относится к EOA.

Лучшие практики

Абстракция учетной записи: Контракт делегирования должен соответствовать более широким стандартам абстракции учетной записи (AA) Эфириума для максимальной совместимости. В частности, в идеале он должен быть совместим или соответствовать стандарту ERC-4337.

Общедоступный и устойчивый к цензуре дизайн: Эфириум ценит общедоступное участие. Контракт делегирования НЕ ДОЛЖЕН жестко кодировать или полагаться на какого-либо одного «доверенного» ретранслятора (relayer) или сервис. Это приведет к блокировке аккаунта, если ретранслятор отключится. Такие функции, как пакетирование (например, approve+transferFrom), могут использоваться самим EOA без ретранслятора. Разработчикам приложений, которые хотят использовать расширенные функции, предоставляемые 7702 (абстракция газа, сохраняющие приватность выводы средств), потребуется ретранслятор. Хотя существуют различные архитектуры ретрансляторов, мы рекомендуем использовать бандлеры 4337 (opens in a new tab), указывающие как минимум на точку входа 0.8 (opens in a new tab), потому что:

• Они предоставляют стандартизированные интерфейсы для ретрансляции
• Включают встроенные системы пеймейстеров
• Обеспечивают прямую совместимость
• Могут поддерживать устойчивость к цензуре через публичный мемпул (opens in a new tab)
• Могут требовать, чтобы функция инициализации вызывалась только из EntryPoint (opens in a new tab)

Другими словами, любой должен иметь возможность выступать в качестве спонсора/ретранслятора транзакции, если он предоставляет требуемую действительную подпись или пользовательскую операцию (UserOperation) от аккаунта. Это обеспечивает устойчивость к цензуре: если не требуется специальная инфраструктура, транзакции пользователя не могут быть произвольно заблокированы контролирующим ретранслятором. Например, Delegation Toolkit от МетаМаск (opens in a new tab) явно работает с любым бандлером ERC-4337 или пеймейстером в любой цепи, а не требует сервера, специфичного для МетаМаск.

Интеграция децентрализованных приложений (dapp) через интерфейсы кошельков:

Учитывая, что кошельки будут добавлять в белый список определенные контракты делегирования для EIP-7702, dapp не должны ожидать прямого запроса авторизаций 7702. Вместо этого интеграция должна происходить через стандартизированные интерфейсы кошельков:

• ERC-5792 (wallet_sendCalls): Позволяет dapp запрашивать у кошельков выполнение пакетированных вызовов, облегчая такие функции, как пакетирование транзакций и абстракция газа.

• ERC-6900: Позволяет dapp использовать возможности модульных смарт-аккаунтов, такие как сессионные ключи и восстановление аккаунта, через модули, управляемые кошельком.

Используя эти интерфейсы, dapp могут получить доступ к функциям смарт-аккаунтов, предоставляемым EIP-7702, без прямого управления делегированием, обеспечивая совместимость и безопасность в различных реализациях кошельков.

Примечание: Не существует стандартизированного метода для прямого запроса dapp подписей авторизации 7702. Dapp должны полагаться на определенные интерфейсы кошельков, такие как ERC-6900, чтобы воспользоваться функциями EIP-7702.

Для получения дополнительной информации:

• Спецификация ERC-5792 (opens in a new tab)
• Спецификация ERC-6900 (opens in a new tab)

Избегание привязки к поставщику: В соответствии с вышесказанным, хорошая реализация независима от поставщика и интероперабельна. Это часто означает соблюдение новых стандартов для смарт-аккаунтов. Например, Modular Account от Alchemy (opens in a new tab) использует стандарт ERC-6900 для модульных смарт-аккаунтов и разработан с учетом «общедоступного интероперабельного использования».

Сохранение приватности: Хотя ончейн-приватность ограничена, контракт делегирования должен стремиться к минимизации раскрытия данных и возможности их связывания. Этого можно достичь за счет поддержки таких функций, как оплата газа в токенах ERC-20 (поэтому пользователям не нужно поддерживать публичный баланс ETH, что улучшает приватность и UX) и одноразовых сессионных ключей (которые снижают зависимость от одного долгосрочного ключа). Например, EIP-7702 позволяет оплачивать газ токенами через спонсируемые транзакции, и хорошая реализация позволит легко интегрировать таких пеймейстеров без утечки большего количества информации, чем необходимо. Кроме того, офчейн-делегирование определенных одобрений (с использованием подписей, которые проверяются ончейн) означает меньшее количество ончейн-транзакций с первичным ключом пользователя, что способствует приватности. Аккаунты, требующие использования ретранслятора, вынуждают пользователей раскрывать свои IP-адреса. Публичные мемпулы (PublicMempools) улучшают эту ситуацию: когда транзакция/пользовательская операция (UserOp) распространяется через мемпул, невозможно определить, исходила ли она от IP-адреса, который ее отправил, или просто была ретранслирована через него по протоколу p2p.

Расширяемость и модульная безопасность: Реализации аккаунтов должны быть расширяемыми, чтобы они могли развиваться с новыми функциями и улучшениями безопасности. Возможность обновления изначально заложена в EIP-7702 (поскольку EOA всегда может делегировать новому контракту в будущем для обновления своей логики). Помимо возможности обновления, хороший дизайн допускает модульность — например, подключаемые модули для различных схем подписи или политик расходования средств — без необходимости полного повторного развертывания. Account Kit от Alchemy является ярким примером, позволяющим разработчикам устанавливать модули валидации (для различных типов подписей, таких как ECDSA, BLS и т. д.) и модули выполнения для пользовательской логики. Для достижения большей гибкости и безопасности в аккаунтах с поддержкой EIP-7702 разработчикам рекомендуется делегировать прокси-контракту, а не напрямую конкретной реализации. Этот подход обеспечивает плавные обновления и модульность, не требуя дополнительных авторизаций EIP-7702 для каждого изменения.

Преимущества паттерна прокси:

• Возможность обновления: Обновляйте логику контракта, указывая прокси на новый контракт реализации.

• Пользовательская логика инициализации: Включайте функции инициализации в прокси для безопасной настройки необходимых переменных состояния.

Например, SafeEIP7702Proxy (opens in a new tab) демонстрирует, как прокси может использоваться для безопасной инициализации и управления делегированием в аккаунтах, совместимых с EIP-7702.

Недостатки паттерна прокси:

• Зависимость от внешних участников: Вам приходится полагаться на внешнюю команду, чтобы она не обновилась до небезопасного контракта.

Соображения безопасности

Защита от повторного входа: С введением делегирования EIP-7702 аккаунт пользователя может динамически переключаться между внешне принадлежащим аккаунтом (EOA) и смарт-контрактом (SC). Эта гибкость позволяет аккаунту как инициировать транзакции, так и быть целью вызовов. В результате сценарии, в которых аккаунт вызывает сам себя и делает внешние вызовы, будут иметь msg.sender, равный tx.origin, что подрывает определенные предположения о безопасности, которые ранее основывались на том, что tx.origin всегда является EOA.

Для разработчиков смарт-контрактов больше небезопасно предполагать, что tx.origin относится к EOA. Аналогично, использование msg.sender == tx.origin в качестве защиты от атак повторного входа больше не является надежной стратегией.

В дальнейшем разработчики должны проектировать с учетом того, что любой участник системы может быть смарт-контрактом. В качестве альтернативы они могут реализовать явную защиту от повторного входа, используя защиту от повторного входа с паттернами модификатора nonReentrant. Мы рекомендуем использовать проверенный модификатор, например Reentrancy Guard от OpenZeppelin (opens in a new tab). Они также могут использовать переменную временного хранения (transient storage) (opens in a new tab).

Соображения безопасности при инициализации

Реализация контрактов делегирования EIP-7702 создает специфические проблемы безопасности, особенно касающиеся процесса инициализации. Критическая уязвимость возникает, когда функция инициализации (init) атомарно связана с процессом делегирования. В таких случаях фронтраннер может перехватить подпись делегирования и выполнить функцию init с измененными параметрами, потенциально получив контроль над аккаунтом.

Этот риск особенно актуален при попытке использовать существующие реализации смарт-аккаунтов (SCA) с EIP-7702 без изменения их механизмов инициализации.

Решения для смягчения уязвимостей инициализации

• Реализуйте initWithSig
  Замените стандартную функцию init на функцию initWithSig, которая требует от пользователя подписания параметров инициализации. Этот подход гарантирует, что инициализация может продолжаться только с явного согласия пользователя, тем самым снижая риски несанкционированной инициализации.

• Используйте EntryPoint из ERC-4337
  Требуйте, чтобы функция инициализации вызывалась исключительно из контракта EntryPoint стандарта ERC-4337. Этот метод использует стандартизированную структуру валидации и выполнения, предоставляемую ERC-4337, добавляя дополнительный уровень безопасности к процессу инициализации.
  (См.: Документация Safe (opens in a new tab))

Приняв эти решения, разработчики могут повысить безопасность контрактов делегирования EIP-7702, защитившись от потенциальных атак фронтраннинга на этапе инициализации.

Коллизии хранилища Делегирование кода не очищает существующее хранилище. При переходе от одного контракта делегирования к другому остаточные данные от предыдущего контракта сохраняются. Если новый контракт использует те же слоты хранилища, но интерпретирует их по-другому, это может вызвать непредвиденное поведение. Например, если первоначальное делегирование было контракту, где слот хранилища представляет собой bool, а последующее делегирование — контракту, где тот же слот представляет собой uint, несоответствие может привести к непредсказуемым результатам.

Риски фишинга С реализацией делегирования EIP-7702 активы на аккаунте пользователя могут полностью контролироваться смарт-контрактами. Если пользователь по незнанию делегирует свой аккаунт вредоносному контракту, злоумышленник может легко получить контроль и украсть средства. При использовании chain_id=0 делегирование применяется ко всем идентификаторам цепей (chain id). Делегируйте только неизменяемому контракту (никогда не делегируйте прокси-контракту) и только контрактам, которые были развернуты с использованием CREATE2 (со стандартным initcode — никаких метаморфических контрактов), чтобы развертывающий не мог развернуть что-то другое по тому же адресу в другом месте. В противном случае ваше делегирование подвергает ваш аккаунт риску во всех других EVM-цепях.

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

Минимальная доверенная поверхность и безопасность: Предлагая гибкость, контракт делегирования должен сохранять свою основную логику минимальной и доступной для аудита. Контракт фактически является расширением EOA пользователя, поэтому любой недостаток может стать катастрофическим. Реализации должны следовать лучшим практикам сообщества по безопасности смарт-контрактов. Например, функции конструктора или инициализатора должны быть тщательно защищены — как подчеркивает Alchemy, при использовании паттерна прокси в рамках 7702 незащищенный инициализатор может позволить злоумышленнику захватить аккаунт. Команды должны стремиться к простоте ончейн-кода: контракт 7702 от Ambire содержит всего ~200 строк на Solidity, намеренно минимизируя сложность для уменьшения количества ошибок. Необходимо найти баланс между многофункциональной логикой и простотой, облегчающей аудит.

Известные реализации

Из-за природы EIP-7702 кошелькам рекомендуется проявлять осторожность при помощи пользователям в делегировании стороннему контракту. Ниже приведена коллекция известных реализаций, прошедших аудит:

Руководства для аппаратных кошельков

Аппаратные кошельки не должны предоставлять возможность произвольного делегирования. Консенсус в сфере аппаратных кошельков заключается в использовании списка доверенных контрактов-делегатов. Мы предлагаем разрешить известные реализации, перечисленные выше, и рассматривать другие в индивидуальном порядке. Поскольку делегирование вашего EOA контракту дает контроль над всеми активами, аппаратные кошельки должны быть осторожны с тем, как они реализуют 7702.

Сценарии интеграции для приложений-компаньонов

Ленивая

Поскольку EOA по-прежнему работает как обычно, ничего делать не нужно.

Примечание: некоторые активы могут быть автоматически отклонены кодом делегирования, например NFT стандарта ERC-1155, и служба поддержки должна знать об этом.

Осведомленная

Уведомите пользователя о том, что для EOA установлено делегирование, проверив его код, и при желании предложите удалить делегирование.

Общее делегирование

Поставщик оборудования добавляет в белый список известные контракты делегирования и реализует их поддержку в программном компаньоне. Рекомендуется выбирать контракт с полной поддержкой ERC-4337.

EOA, делегированные другому контракту, будут обрабатываться как стандартные EOA.

Пользовательское делегирование

Поставщик оборудования реализует свой собственный контракт делегирования, добавляет его в списки и реализует его поддержку в программном компаньоне. Рекомендуется создать контракт с полной поддержкой ERC-4337.

EOA, делегированные другому контракту, будут обрабатываться как стандартные EOA.

Последнее обновление страницы: 6 июня 2026 г.

p (opens in a new tab)

c (opens in a new tab)

j (opens in a new tab)

+6

Посмотреть участников