Ethereum Pectra обновление: Глубина анализа EIP-7702
Введение
Ethereum вскоре встретит обновление Pectra, которое является значительным обновлением и введет множество важных предложений по улучшению. Среди них EIP-7702 произвел революционную трансформацию внешнего аккаунта Ethereum (EOA). Это предложение размывает границы между EOA и контрактным аккаунтом CA, что является ключевым шагом к нативной абстракции аккаунтов после EIP-4337 и приносит новую модель взаимодействия в экосистему Ethereum.
Pectra уже завершила развертывание в тестовой сети и ожидается, что вскоре будет запущена основная сеть. В этой статье мы подробно проанализируем механизм реализации EIP-7702, обсудим возможные возможности и вызовы, а также предоставим практическое руководство для различных участников.
Анализ протокола
Обзор
EIP-7702 вводит совершенно новый тип транзакции, который позволяет EOA указывать адрес смарт-контракта и устанавливать для него код. Это позволяет EOA выполнять код так же, как смарт-контракты, при этом сохраняя возможность инициировать транзакции. Эта особенность наделяет EOA программируемостью и композируемостью, пользователи могут реализовать в EOA функции социальной восстановления, контроля доступа, управления мультиподписями, zk верификации, подписочной оплаты, спонсирования транзакций и пакетной обработки транзакций. Стоит отметить, что EIP-7702 идеально совместим с кошельками смарт-контрактов, реализованными EIP-4337, а их бесшовная интеграция значительно упрощает процесс разработки и применения новых функций.
EIP-7702 ввел тип транзакции SET_CODE_TX_TYPE (0x04), структура данных которого определяется следующим образом:
В новой структуре транзакций, кроме поля authorization_list, остальные следуют той же семантике, что и EIP-4844. Это поле имеет тип списка и может содержать несколько авторизационных записей, каждая из которых содержит:
chain_id обозначает цепь, на которой действует данная авторизация делегирования
адрес обозначает целевой адрес для делегирования
nonce должен соответствовать nonce текущего авторизованного аккаунта
y_parity, r, s являются данными подписи, подписанными авторизованным аккаунтом
Поле authorization_list внутри одной транзакции может содержать несколько различных авторизованных счетов, подписанных (EOA), то есть инициатор транзакции может отличаться от авторизатора, чтобы осуществить операции по авторизации с оплатой газа за счет авторизатора.
реализовать
При подписании данных авторизации уполномоченному лицу необходимо сначала выполнить RLP кодирование chain_id, address, nonce. Затем полученные данные кодирования необходимо подвергнуть хэшированию keccak256 вместе с числом MAGIC, чтобы получить данные, которые необходимо подписать. В конце, используя закрытый ключ уполномоченного лица, выполняется подпись хэшированных данных, в результате чего получаются данные 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 по-прежнему имеет наивысшую степень контроля над счетом, и обладая ключом, можно произвольно распоряжаться активами на счете. Пользователь или поставщик кошелька, завершив делегирование для 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 также может использоваться как смарт-контракт, поэтому биржа может столкнуться с ситуацией, когда пополнение через смарт-контракты станет повсеместным.
Биржа должна проверять статус каждой транзакции пополнения через 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, различные участники экосистемы, такие как пользователи, провайдеры кошельков, разработчики, биржи и т.д., сталкиваются с множеством вызовов и возможностей. Приведенные в статье лучшие практики не могут охватить все потенциальные риски, но всё же заслуживают внимания для применения в реальной практике.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
6 Лайков
Награда
6
5
Поделиться
комментарий
0/400
PermabullPete
· 19ч назад
подняться на борт Книга ордеров опять взорвется
Посмотреть ОригиналОтветить0
StablecoinEnjoyer
· 19ч назад
Немного опередил время, кажется, Виталик Бутерин снова затевает что-то большое.
Посмотреть ОригиналОтветить0
Token_Sherpa
· 20ч назад
meh... еще одно предложение, которое, честно говоря, не решит реальные проблемы эфира
Посмотреть ОригиналОтветить0
RektRecorder
· 20ч назад
Медвежий рынок сидеть в засаде. бычий рынок богатство
EIP-7702 Глубина анализа: обновление Ethereum Pectra размоет границы между EOA и CA
Ethereum Pectra обновление: Глубина анализа EIP-7702
Введение
Ethereum вскоре встретит обновление Pectra, которое является значительным обновлением и введет множество важных предложений по улучшению. Среди них EIP-7702 произвел революционную трансформацию внешнего аккаунта Ethereum (EOA). Это предложение размывает границы между EOA и контрактным аккаунтом CA, что является ключевым шагом к нативной абстракции аккаунтов после EIP-4337 и приносит новую модель взаимодействия в экосистему Ethereum.
Pectra уже завершила развертывание в тестовой сети и ожидается, что вскоре будет запущена основная сеть. В этой статье мы подробно проанализируем механизм реализации EIP-7702, обсудим возможные возможности и вызовы, а также предоставим практическое руководство для различных участников.
Анализ протокола
Обзор
EIP-7702 вводит совершенно новый тип транзакции, который позволяет EOA указывать адрес смарт-контракта и устанавливать для него код. Это позволяет 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. Затем полученные данные кодирования необходимо подвергнуть хэшированию keccak256 вместе с числом MAGIC, чтобы получить данные, которые необходимо подписать. В конце, используя закрытый ключ уполномоченного лица, выполняется подпись хэшированных данных, в результате чего получаются данные 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 по-прежнему имеет наивысшую степень контроля над счетом, и обладая ключом, можно произвольно распоряжаться активами на счете. Пользователь или поставщик кошелька, завершив делегирование для 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 также может использоваться как смарт-контракт, поэтому биржа может столкнуться с ситуацией, когда пополнение через смарт-контракты станет повсеместным.
Биржа должна проверять статус каждой транзакции пополнения через 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, различные участники экосистемы, такие как пользователи, провайдеры кошельков, разработчики, биржи и т.д., сталкиваются с множеством вызовов и возможностей. Приведенные в статье лучшие практики не могут охватить все потенциальные риски, но всё же заслуживают внимания для применения в реальной практике.