Погружение в EIP-7702. Часть 9

Продолжаем разбирать этот необычный стандарт...

Хотя EIP-7702 привносит новую жизнь в экосистему Ethereum, введение новых сценариев применения также несет новые риски. Ниже приведены некоторые аспекты, с которыми участникам экосистемы следует быть осторожными во время практики.

Хранение приватного ключа

Несмотря на то, что EOA (Externally Owned Accounts) могут использовать встроенные в смарт-контракты механизмы социального восстановления для решения проблемы потери активов в результате утраты приватного ключа, они все равно не могут избежать риска самой утечки приватного ключа. Важно отметить, что после делегирования приватный ключ EOA по-прежнему имеет наивысший контроль над счетом; владение приватным ключом дает пользователю возможность свободно распоряжаться активами на аккаунте. Пользователи или поставщики услуг кошелька, завершив делегирование полномочий для EOA, не могут полностью исключить риск утечки закрытого ключа, особенно в случаях, когда возможны атаки на сеть.

Для пользователей защита приватного ключа всегда должна быть приоритетной. Очень важно помнить: Не ваши ключи, не ваши монеты.

Воспроизведение нескольких сетях

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

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

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

Проблема инициализации

Большинство основных кошельков смарт-контрактов используют прокси-модель, при которой прокси-кошелек вызывает функцию инициализации через DELEGATECALL для достижения атомарной инициализации и развертывания кошелька. Однако в EIP-7702 поле кода адреса будет только обновляться, а функция инициализации не может быть вызвана через делегированный адрес. Это ограничивает возможности EIP-7702 по инициализации кошелька по сравнению с прокси-контрактом ERC-1967, который может вызывать функцию инициализации во время развертывания.

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

Управление хранилищем

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

Пользователям следует внимательно относиться к ситуациям переделегирования.

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

Далее посмотрим на еще пару нюансов использования стандарта.

#eip7702