Ethereum Pectra обновление: Глубокий анализ EIP-7702 и лучшие практики
Введение
Ethereum вскоре встретит обновление Pectra, это значительное обновление, в рамках которого будут внедрены несколько важных предложений по улучшению Ethereum. В частности, EIP-7702 произвел революционную трансформацию внешнего аккаунта Ethereum (EOA). Это предложение размывает границы между EOA и контрактными аккаунтами CA, является ключевым шагом к абстракции нативного аккаунта после EIP-4337 и приносит новую модель взаимодействия в экосистему Ethereum.
Pectra уже завершила развертывание в тестовой сети и ожидается, что вскоре выйдет в основную сеть. В этой статье будет глубоко проанализирован механизм реализации EIP-7702, обсуждены возможные возможности и вызовы, а также предоставлены практические руководства для различных участников.
Анализ протокола
Обзор
EIP-7702 ввел новый тип транзакции, который позволяет EOA указывать адрес смарт-контракта для установки кода. Это позволяет EOA выполнять код так же, как смарт-контракт, сохраняя при этом возможность инициировать транзакции. Эта функция наделяет EOA программируемостью и композируемостью, позволяя пользователям реализовывать функции социального восстановления, управления правами, многоподписного управления, zk-проверки, подписной оплаты, спонсирования транзакций и пакетной обработки транзакций. Стоит отметить, что EIP-7702 идеально совместим с кошельками смарт-контрактов, реализуемыми EIP-4337, а бесшовная интеграция этих двух значительно упрощает разработку и применение новых функций.
EIP-7702 ввел тип транзакции SET_CODE_TX_TYPE (0x04), структура данных которой определяется следующим образом:
В новой структуре транзакций, кроме поля authorization_list, остальные следуют тем же семантикам, что и EIP-4844. Это поле является списковым типом и может содержать несколько записей авторизации, каждая запись авторизации содержит:
chain_id обозначает цепь, на которой действует данная авторизация делегирования
address обозначает целевой адрес для делегирования
nonce должен соответствовать nonce текущего авторизованного аккаунта
y_parity, r, s являются данными подписи, подписанными авторизованным аккаунтом
Поля authorization_list в одной транзакции могут содержать несколько различных авторизованных аккаунтов, подписанных (EOA), то есть инициатор транзакции может отличаться от авторизатора, чтобы осуществить оплату газа для операций авторизации.
реализация
При подписании данных авторизацией необходимо сначала выполнить RLP-кодирование chain_id, address и nonce. Затем закодированные данные вместе с MAGIC числом подвергаются хешированию keccak256, в результате чего получается данные для подписи. В конце используйте закрытый ключ авторизующего лица для подписания хешированных данных, чтобы получить y_parity, r, s данные. MAGIC (0x05) используется в качестве разделителя домена, чтобы гарантировать, что результаты подписей разных типов не будут конфликтовать.
Когда chain_id, разрешенный автором, равен 0, это означает, что автор позволяет повторно использовать разрешение ( на всех совместимых с EVM цепях, поддерживающих EIP-7702, при условии, что nonce также совпадает с ).
После того как авторизатор подпишет данные авторизации, инициатор сделки соберет их в поле authorization_list для подписи и отправит транзакцию через RPC. Прежде чем транзакция будет включена в блок и выполнена, Пропозер сначала проведет предварительную проверку транзакции, в ходе которой будет выполнена строгая проверка адреса to, чтобы гарантировать, что эта транзакция не является транзакцией создания контракта, то есть при отправке транзакции типа EIP-7702 адрес to не может быть пустым.
В то же время такие транзакции требуют, чтобы поле authorization_list содержало как минимум одну запись авторизации, если несколько записей авторизации подписаны одним и тем же авторизатором, то в конечном итоге будет действовать только последняя запись авторизации.
Во время выполнения транзакции узел сначала увеличивает значение nonce инициатора транзакции, а затем выполняет операцию applyAuthorization для каждого элемента разрешения в authorization_list. В операции applyAuthorization узел сначала проверяет nonce уполномоченного, а затем увеличивает nonce уполномоченного. Это означает, что если инициатор транзакции и уполномоченный являются одним и тем же пользователем (EOA), то при подписании разрешающей транзакции значение nonce должно быть увеличено на 1.
При применении какого-либо разрешающего элемента узлом, если возникает какая-либо ошибка, этот разрешающий элемент будет пропущен, транзакция не потерпит неудачу, другие разрешающие элементы будут продолжать применяться, тем самым обеспечивая отсутствие риска DoS в сценариях массового разрешения.
После завершения авторизации приложения поле code адреса авторизующего будет установлено на 0xef0100 || address, где 0xef0100 является фиксированным идентификатором, а address - целевым адресом делегирования. Из-за ограничения EIP-3541 пользователи не могут развертывать код контрактов, начинающийся с байтов 0xef, обычным способом, что гарантирует, что такие идентификаторы могут быть развернуты только транзакциями типа SET_CODE_TX_TYPE (0x04).
После завершения авторизации, если авторизующий хочет отменить авторизацию, ему достаточно установить целевой адрес делегирования в 0-адрес.
Новый тип транзакции, введенный через EIP-7702, позволяет авторизатору (EOA) выполнять код так же, как и умный контракт, и одновременно сохранять возможность инициировать транзакции. В отличие от EIP-4337, это предоставляет пользователям опыт, более близкий к нативному абстрагированию учетных записей (Native AA), что значительно снижает порог входа для пользователей.
Лучшие практики
Хотя EIP-7702 привнес новую жизнь в экосистему Ethereum, новые сценарии использования также могут привести к новым рискам. Вот на что участникам экосистемы следует обратить внимание в процессе практики:
Хранение приватных ключей
Даже если EOA может использовать встроенные в смарт-контракт средства социальной реабилитации для решения проблем с потерей средств из-за утраты приватного ключа после делегирования, он все равно не может избежать риска утечки приватного ключа EOA. Важно отметить, что после выполнения делегирования приватный ключ EOA по-прежнему имеет наивысшую степень контроля над счетом, и обладая приватным ключом, можно свободно распоряжаться активами на счете. Даже если пользователи или поставщики кошельков полностью удалят приватный ключ, хранящийся локально, это не может полностью устранить риск утечки приватного ключа, особенно в сценариях, где существует риск атак на цепочку поставок.
Для пользователей, при использовании аккаунта после делегирования, следует по-прежнему ставить защиту приватных ключей на первое место и всегда помнить: Not your keys, not your coins.
Мультичейн повтор
Пользователи при подписании委托授权 могут выбрать цепочку, на которой委托 может вступить в силу, используя chainId. Конечно, пользователи также могут выбрать использование chainId равного 0 для委托, что позволяет委托 быть повторно активированным на нескольких цепях, чтобы пользователям было удобно осуществлять委托 с помощью одной подписи на нескольких цепях. Однако стоит отметить, что на одном и том же адресе контракта на нескольких цепях могут существовать разные реализации кода.
Для провайдеров кошельков, при делегировании пользователем следует проверять, соответствует ли цепочка активации делегирования текущей подключенной сети, и предупреждать пользователей о рисках, связанных с подписанием делегирования с chainId равным 0.
Пользователи также должны помнить, что на разных цепочках одинаковые адреса контрактов не всегда имеют одинаковый код контракта, и сначала следует хорошо понять цель делегирования.
Не удалось инициализировать
Текущие основные смарт-контрактные кошельки в основном используют модель прокси. Прокси-кошелек при развертывании будет вызывать инициализационную функцию контракта через DELEGateCALL, чтобы достичь атомарной операции инициализации кошелька и развертывания прокси-кошелька, избегая проблемы преждевременной инициализации. Однако, когда пользователь использует EIP-7702 для делегирования, будет обновлено только поле code адреса, инициализацию нельзя выполнить через вызов адреса делегата. Это делает EIP-7702 неспособным вызывать инициализационную функцию для инициализации кошелька в транзакциях развертывания контракта, как это делает распространенный прокси-контракт ERC-1967.
Для разработчиков, при комбинировании EIP-7702 с существующим кошельком EIP-4337, следует обратить внимание на проверку прав доступа в процессе инициализации кошелька (, например, с помощью ecrecover для восстановления адреса подписи, чтобы избежать риска того, что операция инициализации кошелька будет перехвачена.
) Управление хранилищем
Пользователи, использующие функцию делегирования EIP-7702, могут в результате изменения потребностей в функциональности, обновления кошелька и других причин, потребоваться повторное делегирование на другой адрес контракта. Однако структура хранения различных контрактов может иметь различия ###, например, слот slot0 разных контрактов может представлять разные типы данных (. В случае повторного делегирования это может привести к неожиданному использованию данных старого контракта новым контрактом, что в свою очередь может вызвать блокировку аккаунта, потерю средств и другие неблагоприятные последствия.
Для пользователей следует осторожно обращаться с ситуацией повторной делегирования.
Для разработчиков важно следовать Формуле Пространства Имен, предложенной ERC-7201, распределяя переменные по назначенным независимым местам хранения, чтобы снизить риск конфликта хранения. Кроме того, ERC-7779 )draft( также предоставляет стандартный процесс повторного делегирования специально для EIP-7702: включая использование ERC-7201 для предотвращения конфликтов хранения и проверку совместимости хранения перед повторным делегированием, а также вызов интерфейса старого делегирования для очистки старых данных из памяти.
) Ложный депозит
После того как пользователь сделает делегирование, EOA также сможет использоваться как смарт-контракт, поэтому централизованная биржа ###CEX( может столкнуться с ситуацией массового использования пополнения смарт-контрактов.
CEX должен проверять статус каждой депозитной транзакции через trace, чтобы предотвратить риск подделки депозитов в смарт-контрактах.
) Конвертация аккаунта
После внедрения EIP-7702 пользователи могут свободно переключать типы своих аккаунтов между EOA и SC, что позволяет аккаунту как инициировать транзакции, так и быть вызванным. Это означает, что когда аккаунт вызывает сам себя и выполняет внешний вызов, его msg.sender также будет tx.origin, что нарушает некоторые предположения о безопасности, которые допускают участие только EOA в проектах.
Для разработчиков контрактов предположение о том, что tx.origin всегда является EOA, больше не будет действительным. Аналогично, проверка msg.sender == tx.origin для защиты от атак повторного входа также утратит свою эффективность.
Разработчики во время разработки должны предполагать, что будущие участники могут быть смарт-контрактами.
Совместимость контрактов
Существующие токены ERC-721 и ERC-777 имеют функцию Hook при переводе по контракту, что означает, что получатель должен реализовать соответствующую функцию обратного вызова для успешного получения токенов.
Для разработчиков целевые контракты, на которые пользователи делегируют, должны реализовывать соответствующие функции обратного вызова, чтобы гарантировать совместимость с основными токенами.
Проверка на рыбалку
После реализации делегирования EIP-7702 активы в учетной записи пользователя могут быть контролируемы умным контрактом, и как только пользователь делегирует свою учетную запись злонамеренному контракту, злоумышленникам станет легко украсть средства.
Для провайдеров кошельков особенно важно как можно скорее поддерживать транзакции типа EIP-7702, и при выполнении пользователем подписания по доверенности следует акцентировать внимание пользователя на целевом контракте доверенности, чтобы уменьшить риск, связанный с возможными фишинговыми атаками.
Кроме того, более глубокий автоматизированный анализ целевых контрактов для доверенности аккаунта, таких как ### открытая проверка, проверка прав и т.д. ( может лучше помочь пользователям избежать таких рисков.
Резюме
Данная статья посвящена обсуждению предложения EIP-7702 в предстоящем обновлении Pectra на Ethereum. EIP-7702 вводит новый тип транзакций, который придает EOA программируемость и композируемость, размывая границы между EOA и контрактными счетами. Поскольку в настоящее время не существует проверенного на практике стандарта смарт-контрактов, совместимого с типом EIP-7702, различные участники экосистемы, такие как пользователи, поставщики кошельков, разработчики, CEX и другие, сталкиваются с множеством вызовов и возможностей. Описанные в статье лучшие практики не могут охватить все потенциальные риски, но все же заслуживают внимания для применения на практике.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
14 Лайков
Награда
14
5
Поделиться
комментарий
0/400
ser_ngmi
· 07-21 20:33
Списывать домашку стало так легко, просто хочу получить eoa и ca.
Посмотреть ОригиналОтветить0
ParanoiaKing
· 07-20 23:50
Еще одна куча непонятных обновлений, просто нет слов.
Посмотреть ОригиналОтветить0
YieldHunter
· 07-20 23:49
с технической точки зрения, этот eip выглядит немного подозрительно... есть ли данные о стоимости tx в тестовой сети?
Посмотреть ОригиналОтветить0
EyeOfTheTokenStorm
· 07-20 23:26
Снова ли это возможность для предварительной настройки? Судя по историческим данным, после обновлений ETH обычно наблюдается большой памп, но на рынке уже есть небольшая泡沫.
Посмотреть ОригиналОтветить0
SchrodingerPrivateKey
· 07-20 23:23
Снова новое EIP, пришел аккаунт контракта для нищих.
EIP-7702解析:Ethereum Pectra升级如何赋予EOA Программируемость
Ethereum Pectra обновление: Глубокий анализ EIP-7702 и лучшие практики
Введение
Ethereum вскоре встретит обновление Pectra, это значительное обновление, в рамках которого будут внедрены несколько важных предложений по улучшению Ethereum. В частности, EIP-7702 произвел революционную трансформацию внешнего аккаунта Ethereum (EOA). Это предложение размывает границы между EOA и контрактными аккаунтами CA, является ключевым шагом к абстракции нативного аккаунта после EIP-4337 и приносит новую модель взаимодействия в экосистему Ethereum.
Pectra уже завершила развертывание в тестовой сети и ожидается, что вскоре выйдет в основную сеть. В этой статье будет глубоко проанализирован механизм реализации EIP-7702, обсуждены возможные возможности и вызовы, а также предоставлены практические руководства для различных участников.
Анализ протокола
Обзор
EIP-7702 ввел новый тип транзакции, который позволяет EOA указывать адрес смарт-контракта для установки кода. Это позволяет EOA выполнять код так же, как смарт-контракт, сохраняя при этом возможность инициировать транзакции. Эта функция наделяет EOA программируемостью и композируемостью, позволяя пользователям реализовывать функции социального восстановления, управления правами, многоподписного управления, zk-проверки, подписной оплаты, спонсирования транзакций и пакетной обработки транзакций. Стоит отметить, что EIP-7702 идеально совместим с кошельками смарт-контрактов, реализуемыми EIP-4337, а бесшовная интеграция этих двух значительно упрощает разработку и применение новых функций.
EIP-7702 ввел тип транзакции SET_CODE_TX_TYPE (0x04), структура данных которой определяется следующим образом:
rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, value, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s])
Поле authorization_list определяется как:
authorization_list = [[chain_id, адрес, nonce, y_parity, r, s], ...]
В новой структуре транзакций, кроме поля authorization_list, остальные следуют тем же семантикам, что и EIP-4844. Это поле является списковым типом и может содержать несколько записей авторизации, каждая запись авторизации содержит:
Поля authorization_list в одной транзакции могут содержать несколько различных авторизованных аккаунтов, подписанных (EOA), то есть инициатор транзакции может отличаться от авторизатора, чтобы осуществить оплату газа для операций авторизации.
реализация
При подписании данных авторизацией необходимо сначала выполнить RLP-кодирование chain_id, address и nonce. Затем закодированные данные вместе с MAGIC числом подвергаются хешированию keccak256, в результате чего получается данные для подписи. В конце используйте закрытый ключ авторизующего лица для подписания хешированных данных, чтобы получить y_parity, r, s данные. MAGIC (0x05) используется в качестве разделителя домена, чтобы гарантировать, что результаты подписей разных типов не будут конфликтовать.
Когда chain_id, разрешенный автором, равен 0, это означает, что автор позволяет повторно использовать разрешение ( на всех совместимых с EVM цепях, поддерживающих EIP-7702, при условии, что nonce также совпадает с ).
После того как авторизатор подпишет данные авторизации, инициатор сделки соберет их в поле authorization_list для подписи и отправит транзакцию через RPC. Прежде чем транзакция будет включена в блок и выполнена, Пропозер сначала проведет предварительную проверку транзакции, в ходе которой будет выполнена строгая проверка адреса to, чтобы гарантировать, что эта транзакция не является транзакцией создания контракта, то есть при отправке транзакции типа EIP-7702 адрес to не может быть пустым.
В то же время такие транзакции требуют, чтобы поле authorization_list содержало как минимум одну запись авторизации, если несколько записей авторизации подписаны одним и тем же авторизатором, то в конечном итоге будет действовать только последняя запись авторизации.
Во время выполнения транзакции узел сначала увеличивает значение nonce инициатора транзакции, а затем выполняет операцию applyAuthorization для каждого элемента разрешения в authorization_list. В операции applyAuthorization узел сначала проверяет nonce уполномоченного, а затем увеличивает nonce уполномоченного. Это означает, что если инициатор транзакции и уполномоченный являются одним и тем же пользователем (EOA), то при подписании разрешающей транзакции значение nonce должно быть увеличено на 1.
При применении какого-либо разрешающего элемента узлом, если возникает какая-либо ошибка, этот разрешающий элемент будет пропущен, транзакция не потерпит неудачу, другие разрешающие элементы будут продолжать применяться, тем самым обеспечивая отсутствие риска DoS в сценариях массового разрешения.
После завершения авторизации приложения поле code адреса авторизующего будет установлено на 0xef0100 || address, где 0xef0100 является фиксированным идентификатором, а address - целевым адресом делегирования. Из-за ограничения EIP-3541 пользователи не могут развертывать код контрактов, начинающийся с байтов 0xef, обычным способом, что гарантирует, что такие идентификаторы могут быть развернуты только транзакциями типа SET_CODE_TX_TYPE (0x04).
После завершения авторизации, если авторизующий хочет отменить авторизацию, ему достаточно установить целевой адрес делегирования в 0-адрес.
Новый тип транзакции, введенный через EIP-7702, позволяет авторизатору (EOA) выполнять код так же, как и умный контракт, и одновременно сохранять возможность инициировать транзакции. В отличие от EIP-4337, это предоставляет пользователям опыт, более близкий к нативному абстрагированию учетных записей (Native AA), что значительно снижает порог входа для пользователей.
Лучшие практики
Хотя EIP-7702 привнес новую жизнь в экосистему Ethereum, новые сценарии использования также могут привести к новым рискам. Вот на что участникам экосистемы следует обратить внимание в процессе практики:
Хранение приватных ключей
Даже если EOA может использовать встроенные в смарт-контракт средства социальной реабилитации для решения проблем с потерей средств из-за утраты приватного ключа после делегирования, он все равно не может избежать риска утечки приватного ключа EOA. Важно отметить, что после выполнения делегирования приватный ключ EOA по-прежнему имеет наивысшую степень контроля над счетом, и обладая приватным ключом, можно свободно распоряжаться активами на счете. Даже если пользователи или поставщики кошельков полностью удалят приватный ключ, хранящийся локально, это не может полностью устранить риск утечки приватного ключа, особенно в сценариях, где существует риск атак на цепочку поставок.
Для пользователей, при использовании аккаунта после делегирования, следует по-прежнему ставить защиту приватных ключей на первое место и всегда помнить: Not your keys, not your coins.
Мультичейн повтор
Пользователи при подписании委托授权 могут выбрать цепочку, на которой委托 может вступить в силу, используя chainId. Конечно, пользователи также могут выбрать использование chainId равного 0 для委托, что позволяет委托 быть повторно активированным на нескольких цепях, чтобы пользователям было удобно осуществлять委托 с помощью одной подписи на нескольких цепях. Однако стоит отметить, что на одном и том же адресе контракта на нескольких цепях могут существовать разные реализации кода.
Для провайдеров кошельков, при делегировании пользователем следует проверять, соответствует ли цепочка активации делегирования текущей подключенной сети, и предупреждать пользователей о рисках, связанных с подписанием делегирования с chainId равным 0.
Пользователи также должны помнить, что на разных цепочках одинаковые адреса контрактов не всегда имеют одинаковый код контракта, и сначала следует хорошо понять цель делегирования.
Не удалось инициализировать
Текущие основные смарт-контрактные кошельки в основном используют модель прокси. Прокси-кошелек при развертывании будет вызывать инициализационную функцию контракта через DELEGateCALL, чтобы достичь атомарной операции инициализации кошелька и развертывания прокси-кошелька, избегая проблемы преждевременной инициализации. Однако, когда пользователь использует EIP-7702 для делегирования, будет обновлено только поле code адреса, инициализацию нельзя выполнить через вызов адреса делегата. Это делает EIP-7702 неспособным вызывать инициализационную функцию для инициализации кошелька в транзакциях развертывания контракта, как это делает распространенный прокси-контракт ERC-1967.
Для разработчиков, при комбинировании EIP-7702 с существующим кошельком EIP-4337, следует обратить внимание на проверку прав доступа в процессе инициализации кошелька (, например, с помощью ecrecover для восстановления адреса подписи, чтобы избежать риска того, что операция инициализации кошелька будет перехвачена.
) Управление хранилищем
Пользователи, использующие функцию делегирования EIP-7702, могут в результате изменения потребностей в функциональности, обновления кошелька и других причин, потребоваться повторное делегирование на другой адрес контракта. Однако структура хранения различных контрактов может иметь различия ###, например, слот slot0 разных контрактов может представлять разные типы данных (. В случае повторного делегирования это может привести к неожиданному использованию данных старого контракта новым контрактом, что в свою очередь может вызвать блокировку аккаунта, потерю средств и другие неблагоприятные последствия.
Для пользователей следует осторожно обращаться с ситуацией повторной делегирования.
Для разработчиков важно следовать Формуле Пространства Имен, предложенной ERC-7201, распределяя переменные по назначенным независимым местам хранения, чтобы снизить риск конфликта хранения. Кроме того, ERC-7779 )draft( также предоставляет стандартный процесс повторного делегирования специально для EIP-7702: включая использование ERC-7201 для предотвращения конфликтов хранения и проверку совместимости хранения перед повторным делегированием, а также вызов интерфейса старого делегирования для очистки старых данных из памяти.
) Ложный депозит
После того как пользователь сделает делегирование, EOA также сможет использоваться как смарт-контракт, поэтому централизованная биржа ###CEX( может столкнуться с ситуацией массового использования пополнения смарт-контрактов.
CEX должен проверять статус каждой депозитной транзакции через trace, чтобы предотвратить риск подделки депозитов в смарт-контрактах.
) Конвертация аккаунта
После внедрения EIP-7702 пользователи могут свободно переключать типы своих аккаунтов между EOA и SC, что позволяет аккаунту как инициировать транзакции, так и быть вызванным. Это означает, что когда аккаунт вызывает сам себя и выполняет внешний вызов, его msg.sender также будет tx.origin, что нарушает некоторые предположения о безопасности, которые допускают участие только EOA в проектах.
Для разработчиков контрактов предположение о том, что tx.origin всегда является EOA, больше не будет действительным. Аналогично, проверка msg.sender == tx.origin для защиты от атак повторного входа также утратит свою эффективность.
Разработчики во время разработки должны предполагать, что будущие участники могут быть смарт-контрактами.
Совместимость контрактов
Существующие токены ERC-721 и ERC-777 имеют функцию Hook при переводе по контракту, что означает, что получатель должен реализовать соответствующую функцию обратного вызова для успешного получения токенов.
Для разработчиков целевые контракты, на которые пользователи делегируют, должны реализовывать соответствующие функции обратного вызова, чтобы гарантировать совместимость с основными токенами.
Проверка на рыбалку
После реализации делегирования EIP-7702 активы в учетной записи пользователя могут быть контролируемы умным контрактом, и как только пользователь делегирует свою учетную запись злонамеренному контракту, злоумышленникам станет легко украсть средства.
Для провайдеров кошельков особенно важно как можно скорее поддерживать транзакции типа EIP-7702, и при выполнении пользователем подписания по доверенности следует акцентировать внимание пользователя на целевом контракте доверенности, чтобы уменьшить риск, связанный с возможными фишинговыми атаками.
Кроме того, более глубокий автоматизированный анализ целевых контрактов для доверенности аккаунта, таких как ### открытая проверка, проверка прав и т.д. ( может лучше помочь пользователям избежать таких рисков.
Резюме
Данная статья посвящена обсуждению предложения EIP-7702 в предстоящем обновлении Pectra на Ethereum. EIP-7702 вводит новый тип транзакций, который придает EOA программируемость и композируемость, размывая границы между EOA и контрактными счетами. Поскольку в настоящее время не существует проверенного на практике стандарта смарт-контрактов, совместимого с типом EIP-7702, различные участники экосистемы, такие как пользователи, поставщики кошельков, разработчики, CEX и другие, сталкиваются с множеством вызовов и возможностей. Описанные в статье лучшие практики не могут охватить все потенциальные риски, но все же заслуживают внимания для применения на практике.