Pectra 7702

Аннотация

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Например, SafeEIP7702Proxyopens 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 от OpenZeppelinopens in a new tab. Они также могут использовать переменную временного хранилищаopens in a new tab.

Вопросы безопасности инициализации

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

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

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

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

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

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

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

Риски фишинга С внедрением делегирования по EIP-7702 активы на аккаунте пользователя могут полностью контролироваться смарт-контрактами. Если пользователь неосознанно делегирует свой аккаунт вредоносному контракту, злоумышленник может легко получить контроль и украсть средства. При использовании chain_id=0 делегирование применяется ко всем идентификаторам сетей. Делегируйте только неизменяемому контракту (никогда не делегируйте прокси) и только контрактам, которые были развернуты с использованием 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.

Последнее обновление страницы: 22 октября 2025 г.

popens in a new tab

wopens in a new tab

copens in a new tab

+6

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