Введение

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

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

Чтобы позволить EOAs действовать как кошельки смарт-контрактов, мы разработали EIP7702Proxy, легковесный ERC-1967 проксиконтракт, предназначенный для выполнения роли делегата EIP-7702 для EOA. В дополнение к базовой логической переадресации, выполняемой прокси, EIP7702Proxy содержит дополнительные функции и проектные решения, которые решают несколько уникальных для EIP-7702-делегированных аккаунтов проблем. Целью проектирования EIP7702Proxy было обеспечить максимально возможное соответствие между «стандартно-разворачиваемыми» Coinbase Smart Wallet и EIP-7702-делегированными Coinbase Smart Wallet, что означало абстрагирование дополнительной сложности, требуемой механикой EIP-7702, в специализированный прокси и продолжение опоры на оригинальную реализацию CoinbaseSmartWallet. Решение этой задачи может быть полезно применено к любой логике реализации, а не только к реализации CoinbaseSmartWallet, при этом помогая EOA оставаться в безопасности в среде, поддерживающей 7702.

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

Челлендж #1: Обеспечение безопасной инициализации

Первой серьезной преградой при реализации EIP-7702 являются ограничения его инициализации. Традиционные кошельки смарт-контрактов, включая CoinbaseSmartWallet, обычно обрабатывают безопасную инициализацию (установление прав собственности на аккаунт) атомарно во время их развертывания через отдельный фабричный контракт. Эта атомарность означает, что многие такие реализации имеют незащищенные функции инициализации, которые могут быть вызваны ровно один раз. Однако дизайн EIP-7702 не позволяет выполнять инициализацию calldata в процессе делегирования кода (сравнимом шаге с "развертыванием"), и поэтому это не может быть сделано атомарно.

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

Решение: Требовать подпись EOA для атомарной установки реализации и инициализации

Обратите внимание, что существующие смарт-кошельки Coinbase развернуты за ERC-1967 прокси с UUPSUpgradeable реализация (фактическая логика CoinbaseSmartWallet). Код по фактическому адресу учетной записи является прокси, и прокси использует обычное место хранения, определенное ERC-1967, чтобы удерживать указатель на свою реализацию логики. Наше решение проблемы уязвимости инициализации в контексте 7702 заключается в том, что любая логика реализации становится активной (и, следовательно, опасной) только тогда, когда прокси фактически устанавливает к ней соединение. Поэтому, если мы не можем обеспечить атомарное развертывание с инициализацией, мы можем вместо этого обеспечить атомарную настройку реализации с инициализацией.

EIP-7702 архитектура контракта CoinbaseSmartWallet и логический поток делегирования

В контексте EIP-7702 EOA является первоначальным органом, ответственным за любые изменения в своем аккаунте, и должен предоставить подпись для авторизации инициализации и установления любых владельцев нового смарт-аккаунта. Наш контракт EIP7702Proxy реализует функцию setImplementation, которая может атомарно установить новую логическую реализацию и инициализировать аккаунт. Функция setImplementation:

1. Проверяет подпись от EOA по ключевым данным, таким как адрес нового контракта реализации, инициализационные данные, адрес контракта валидатора, который будет оценивать безопасность полученного состояния аккаунта, и основные меры защиты от повторного использования подписи, такие как nonce и срок действия.
2. Устанавливает значение указателя ERC-1967 на новую реализацию и выполняет предоставленный calldata против новой логической реализации
3. Вызывает функцию validateAccountState, которая должна быть реализована валидатором, включенным в подпись.

Валидатор — это конкретный для реализации контракт, который содержит логику для оценки, считает ли он результирующее состояние счета безопасным. Например, в случае CoinbaseSmartWallet валидатор CoinbaseSmartWalletValidator проверит, является ли состояние владения счета непустым, и, следовательно, больше не подвержено произвольной инициализации.

Challenge #2: Общий хранилище среди делегатов EIP-7702

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

Управление коллизиями хранения уже является знакомой проблемой в области проектирования прокси, где используется изменяемая логика реализации для управления общим хранилищем. Хотя обновляемые прокси могут изменять реализации, сам код прокси (для адресов, не относящихся к 7702) не может быть изменен. Это приносит определенность и гарантии в процесс обновления. Переуполномочивание 7702 вводит еще один уровень полной изменяемости потенциальной логики, которая может управлять этим общим хранилищем. Это фактически устраняет любые гарантии относительно эффекта произвольного делегата на хранилище. Например, если EOA переуполномочивает от делегата A к B и обратно к A, возвращающийся делегат не может делать предположения о состоянии своего хранилища, которое могло быть стерто или манипулировано делегатом B в состояние, которое было бы невозможно достичь только с помощью логики делегата A. Это верно для любого делегата 7702, независимо от паттерна делегирования, поскольку предыдущий делегат мог сохранить или удалить что угодно в любом месте хранилища.

Пример недействительного состояния для DeleGate A, вызванного паттерном делегирования A → B → A

Решение: Экстернализация критически важных значений хранения безопасности

Делегирование EOA может произвольно влиять на состояние аккаунта. Если EOA делегирует на злонамеренный или разрушительный контракт, ни один существующий делегат не может защитить от этого. Как и подписание транзакции дренера, авторизация злонамеренных делегатов 7702 может быть разрушительной, и защита от этих последствий выходит за рамки нашего проектирования.

Мы разработали EIP7702Proxy, чтобы он был самозащитным против предсказуемых проблем в многокошельковой экосистеме, поддерживающей 7702, состоящей из добросовестных, но потенциально хаотичных участников. Он не может защитить EOA, которые авторизуют действительно злонамеренные или ошибочные делегаты.

Одной из предсказуемых проблем являются подписи для вызовов setImplementation и риски, возникающие из-за изменяемого состояния аккаунта. EIP7702Proxy полагается на подписи EOA для установки логики реализации и инициализации в безопасное состояние. Эти подписи могут стать обязательствами, если их когда-либо можно будет повторно использовать. Например, если подпись авторизует первоначального владельца, который позже будет скомпрометирован и удален, повторно используемая подпись может восстановить скомпрометированного владельца или принудительно понизить реализацию.

Общая защита от повторного использования подписей использует нонсы в подписанных сообщениях, помеченных как использованные после проверки. Риск для аккаунтов 7702: другие делегаты могут скомпрометировать это хранилище отслеживания нонсов. Если хранилище отслеживания использования нонсов будет стерто, подпись setImplementation EOA (доступная публично в мемпуле) может быть повторно применена при делегировании обратно к EIP7702Proxy.

Чтобы гарантировать невозможность повторного использования подписи, мы реализовали отдельный экземпляр NonceTracker, который поддерживает статус nonce в неизменяемом контрактном расположении вне хранилища учетной записи. Только EOA может влиять на свои nonce (только по увеличению), предотвращая других делегатов от манипулирования этими критически важными значениями безопасности. NonceTracker гарантирует, что каждая подпись setImplementation работает только один раз, независимо от изменений в хранилище учетной записи.

Вызов #3: Повышенный риск общих традиционных мест хранения

Стандартизированные слоты хранения, такие как те, что определены в ERC-1967 особенно уязвимы для потенциальных коллизий хранения благодаря тому, что являются традиционными местами, которые, вероятно, будут использоваться несколькими реализациями deleGate. Слот реализации ERC-1967 является единственным стандартным местом хранения, используемым в EIP7702Proxy, и он хранит адрес логической реализации, на которую указывает прокси. Наше проектирование гарантирует, что независимо от значения в этом месте хранения (которое определяет большую часть логики, доступной на счете), EIP7702Proxy всегда сможет успешно установить свою реализацию логики на контракт, желаемый EOA.

Чтобы более ясно проиллюстрировать решаемую проблему, обратите внимание, что когда аккаунт переходит между различными делегатами (A→B→A), где оба делегата реализуют шаблоны прокси ERC-1967, делегат B естественным образом будет использовать тот же слот хранения, который использовал делегат A для хранения своего адреса реализации. На протяжении своего срока делегат B может изменять или перезаписывать этот слот, либо намеренно, либо как часть своих обычных операций прокси. В шаблоне прокси UUPSUpgradeable логика обновления реализации определяется в самом контракте реализации. Если реализация, установленная на этом указателе делегатом B, не содержит интерфейс upgradeToAndCall, ожидаемый в реализации, тогда при возвращении к делегату A сам механизм изменения своей реализации может не существовать в текущей доступной логике.

Пример перезаписи совместно используемого обычного места хранения новым deleGate

Решение: Механизм обновления доступен на EIP7702Proxy

Наш EIP7702Proxy решает эту проблему через свою функцию setImplementation, которая предоставляет механизм обновления, независимый от реализации, непосредственно на самом прокси. Это обеспечивает то, что даже если промежуточный deleGate указывает реализацию ERC-1967 на недействительную реализацию (или удаляет ее полностью), оригинальный EOA, после делегирования обратно на EIP7702Proxy, сохраняет возможность перенастроить указатель ERC-1967 прокси на их выбранную логическую реализацию.

Челлендж #4: Обратная совместимость с стандартным поведением EOA

Целью проектирования EIP7702Proxy было поддержание обратной совместимости с функциональностью EOA аккаунта, помимо новой функциональности смарт-контрактов. Наличие или отсутствие кода по адресу может влиять на поток выполнения протоколов, взаимодействующих с адресом, так как они основываются на этом качестве для различения EOA и смарт-контрактов. Это потребовало учета двух основных поведений: верификация подписи и поведение при получении токенов.

Проверка подписи

У смарт-контрактов другой стандарт проверки подписи, чем у стандартных EOA. Смарт-контракты реализуют интерфейс isValidSignature, определенный поERC-1271 и могут свободно определять произвольную логику, которая определяет, считает ли контракт подпись действительной. Для стандартных EOA подпись проверяется с помощью стандартной проверки ecrecover, которая гарантирует, что подписавший восстанавливается на ожидаемый адрес EOA.

Чтобы гарантировать, что существующие или будущие подписи EOA будут продолжать действовать после обновления 7702, EIP7702Proxy реализует версию isValidSignature, которая сначала делегирует проверку подписи функции isValidSignature, которая должна быть определена в логической реализации, но после неудачной проверки завершает проверку с помощью окончательной проверки ecrecover. Если это проходит, подпись считается действительной. Таким образом, EOA, использующие EIP7702Proxy, могут гарантировать, что простые подписи EOA всегда будут действовать по их адресу, независимо от реализации isValidSignature их смарт-контрактного кошелька.

Получение токена

Некоторые стандарты токенов (в частности,ERC-1155 и ERC-721) попытка защитить от токенов, застревающих в смарт-контрактах, которые могут не иметь возможности управлять ими. Эти токены требуют, чтобы любой смарт-контракт, который будет получать такие токены, объявил об этой возможности, реализовав стандартные интерфейсы получателя токенов, которые вызываются контрактом токена во время отправки токена. Также важно, чтобы логика на обновленном EOA содержала стандартную функцию получения или платёжный откат, чтобы иметь возможность получать нативные токены. Учетная запись никогда не должна находиться в состоянии, которое оставляет ее неспособной получать ETH или другие токены, даже на короткий срок.

Поскольку наш прокси не имеет начальной реализации, мы включаем неизменяемую реализацию DefaultReceiver в качестве логики по умолчанию для EIP7702Proxy в отсутствие указателя ERC-1967. Этот приемник реализует функцию получения и крючки для этих общих стандартов токенов, обеспечивая возможность аккаунта принимать переводы токенов до явной установки новой реализации.

Заключение

Дизайн EIP7702Proxy позволяет нам поддерживать близкое соответствие со стандартно развернутыми CoinbaseSmartWallet и продолжать использовать существующую реализацию CoinbaseSmartWallet, решая уникальные проблемы безопасности, возникающие в контексте EIP-7702. Тщательно учитывая безопасность инициализации, последствия временности хранения и вмешательства, необходимость непрерывной обработки токенов и обратную совместимость со стандартной проверкой подписи EOA, мы создали прокси для безопасной делегирования и управления кошельками смарт-контрактов EIP-7702. Хотя EIP7702Proxy был разработан с учетом реализации CoinbaseSmartWallet V1, этот прокси в конечном итоге является независимым от реализации. Мы призываем разработчиков оценить это решение для защиты 7702 других реализаций кошельков смарт-контрактов.

Отказ от ответственности:

1. Эта статья перепечатана из [Блог по базовой инженерии]. Все авторские права принадлежат первоисточнику [Ами Корсо]. Если есть возражения против этой перепечатки, пожалуйста, свяжитесь с Gate Learn команда, и они займутся этим быстро.
2. Отказ от ответственности: Мнения и взгляды, выраженные в этой статье, являются исключительно мнением автора и не представляют собой инвестиционные рекомендации.
3. Переводы статьи на другие языки выполнены командой Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.