Абстракция аккаунта (Account Abstraction, AA) является важным направлением долгосрочных исследований в экосистеме Ethereum, целью которого является разрушение границ между внешними аккаунтами (EOA) и контрактными аккаунтами, обеспечивая более высокую программируемость, безопасность и возможность обновления для кошельков. EIP-4337, как наиболее распространенное решение для AA, уже широко используется в ряде смарт-контрактных кошельков на базе EntryPoint (таких как Safe, Stacks, Argent). Однако, EIP-4337, ввиду введения независимого пула транзакций и механизма входного контракта, все еще имеет определенные ограничения в отношении нативности на цепи, сложности операций и совместимости с экосистемой.
Для дальнейшего снижения порога использования абстракции учетной записи и усиления ее нативной поддержки, Виталик в 2024 году предложил EIP-7702 и включил это предложение в обновление Pectra. Основная идея EIP-7702 заключается в следующем: позволяя изначальной EOA при инициировании транзакции выполнить код контракта (contract_code) по указанному адресу, определяющему логику выполнения этой транзакции.
В EIP-7702 представлен новый механизм «внедрения кода на уровне транзакции», который позволяет учетным записям пользователей динамически указывать логику выполнения в каждой транзакции, а не полагаться на предварительно развернутый код контракта. Это нарушает традиционную модель разрешений на основе статического кода, обеспечивает большую гибкость и создает новые проблемы безопасности: контракты, которые полагаются на логику суждений, такую как isContract и extcodehash, могут стать недействительными, а некоторые системы, которые предполагают, что вызывающий является чистым EOA, могут быть обойдены. Для аудиторов важно не только проверить безопасность самого внедренного кода, но и оценить его потенциальное влияние на другие контрактные системы в динамическом контексте.
В этой статье команда безопасности Beosin систематически рассмотрит принципы проектирования и ключевые характеристики EIP-7702, а также возможные риски безопасности, с которыми может столкнуться AA-кошелек, построенный на его основе, в процессе аудита. Мы предложим процесс аудита и рекомендации с учетом практического опыта, чтобы помочь исследователям безопасности лучше справляться с техническими вызовами в этой новой парадигме.
Введение в EIP-7702
Обзор технологии EIP-7702
EIP-7702 вводит новый тип транзакции 0x04 (SetCode), который позволяет EOA авторизовать код контракта, который необходимо выполнить, через эту транзакцию. Структура транзакции следующая:
Внутри authorization_list содержится несколько списков авторизаций, которые также могут включать авторизационные действия, не относящиеся к инициатору сделки; внутренняя структура такова:
В этом контексте chain_id обозначает цепочку, на которой действуют полномочия пользователя, и его значение должно быть равно ID цепи выполнения или 0. Когда chain_id равно 0, это означает, что полномочия действуют для всех EVM цепей, поддерживающих EIP-7702, при этом другие параметры (например, nonce) должны совпадать. address обозначает адрес целевого контракта, на который выданы полномочия пользователя.
После завершения авторизации система изменит поле code авторизованного пользователя на 0xef0100 || address, где address — это адрес контракта, которому предоставлены права. Если вы хотите отменить авторизацию, просто инициируйте транзакцию SetCode и установите адрес на 0.
Преимущества EIP7702
(1) Гибкость и настройки
Абстрактные аккаунты позволяют гибко настраивать функции в зависимости от потребностей, записывая логику аккаунта в смарт-контракты. Например, пользователи могут настраивать мультиподписи, социальное восстановление, контроль лимитов и т. д., чтобы удовлетворить различные потребности как физических, так и юридических лиц. Этот дизайн значительно увеличивает функциональную расширяемость аккаунта, преодолевая ограничения традиционных внешних аккаунтов (EOA).
(2) Увеличение безопасности
Абстрактные аккаунты предоставляют многоуровневые механизмы безопасности, включая многофакторную аутентификацию, лимиты на транзакции и социальное восстановление. Даже если пользователь потеряет свой приватный ключ, он сможет восстановить аккаунт через доверенных контактов или многофакторную проверку, что предотвращает постоянные потери активов, возникающие из-за потери приватного ключа в традиционных аккаунтах. В то же время функции контроля лимитов могут предотвратить кражу больших сумм средств.
(3) Газ оптимизация
Абстрактные аккаунты поддерживают гибкий механизм абстракции Gas, позволяя пользователям оплачивать Gas через третьи стороны или даже напрямую использовать другие токены для оплаты транзакционных сборов. Этот механизм не только снижает операционные расходы пользователей, но и дополнительно упрощает использование блокчейна, особенно подходит для новичков или сложных многопошаговых сценариев транзакций.
(4) способствовать распространению Web3
Оптимизируя опыт и безопасность, абстрактные аккаунты скрывают сложность блокчейна от пользователей, обеспечивая более удобные операции, близкие к Web2. Этот дизайн снижает затраты на обучение для обычных пользователей, позволяя большему количеству людей беспрепятственно участвовать в приложениях Web3 и способствуя распространению децентрализованных технологий.
Анализ рисков безопасности EIP-7702 на практике
Хотя EIP-7702 привнес новую динамику в экосистему Ethereum и расширил множество применений, он также неизбежно вводит некоторые новые риски безопасности:
Атака повторного воспроизведения
В модели EIP-7702, если пользователь устанавливает поле chain_id в 0 в авторизации, это означает, что данная авторизация может быть действительна на нескольких цепях. Хотя такой дизайн «кросс-цепочной универсальной авторизации» увеличивает гибкость в определенных сценариях, он также вносит явные риски безопасности.
Важно отметить, что даже если идентификаторы аккаунтов на разных цепочках совпадают, реализованные контракты могут быть совершенно разными. Это означает, что злоумышленник может развернуть вредоносную версию контракта на другой цепочке и использовать действия по авторизации с тем же адресом в цепочке для выполнения непредвиденных операций, что может привести к рискам для активов пользователей.
Поэтому для поставщиков услуг кошельков или платформ взаимодействия с клиентами при выполнении пользователем таких операций авторизации необходимо четко проверить, соответствует ли заявленный в авторизации chainId текущей подключенной сети; если будет обнаружено, что пользователь установил chainId равным 0, следует предоставить четкое предупреждение о рисках, уведомив пользователя о том, что данная авторизация будет действовать на всех совместимых с EVM цепях и может быть злоупотреблена вредоносными контрактами.
Кроме того, сторона, предоставляющая услуги, должна оценить, следует ли на уровне UI по умолчанию ограничить или запретить авторизацию с chainId равным 0, чтобы снизить риск ошибок в операциях или фишинговых атак.
Проблемы совместимости контрактов
(1) Совместимость обратных вызовов контрактов
Существующие токен-контракты ERC-721, ERC-777, ERC1155 и другие при переводе средств на адрес контракта будут вызывать стандартные интерфейсы обратного вызова (например, onERC721Received, tokensReceived) для завершения операции перевода. Если адрес получателя не реализовал соответствующий интерфейс, перевод завершится неудачей и даже может привести к блокировке активов.
В EIP-7702 адреса пользователей могут быть назначены кодом контракта с помощью операции «set_code», превращая их в контрактные счета. В этом случае:
Адрес пользователя будет рассматриваться как контракт;
Если этот контракт не реализует необходимые интерфейсы обратного вызова, это приведет к неудаче при переводе токенов;
Пользователи могут не осознавать, что не могут получать основные токены.
Таким образом, разработчики должны убедиться, что целевой контракт, на который делегируют пользователи, реализует соответствующие интерфейсы обратного вызова для обеспечения совместимости с основными токенами.
(2) Проверка «tx.origin» не действительна
В традиционных контрактах «tx.origin» часто используется для определения того, инициировалась ли транзакция непосредственно пользователем, что помогает предотвратить вызов контракта и другие меры безопасности.
Но в контексте EIP-7702:
Пользователь подписывает авторизацию на транзакцию, которая фактически транслируется ретранслятором или службой объединения (bundler); при выполнении транзакции «tx.origin» является адресом ретранслятора, а не адресом пользователя.
«msg.sender» является кошелек-контрактом, представляющим идентичность пользователя.
Таким образом, проверка прав на основе «tx.origin == msg.sender» приведет к отказу в операциях законных пользователей, потеряв надежность, и аналогично, использование ограничений вызова контрактов, таких как «tx.origin == user», также станет неэффективным. Рекомендуется отказаться от использования «tx.origin» в качестве основы для обеспечения безопасности и вместо этого использовать механизмы проверки подписи или авторизации.
(3) Ошибка в «isContract»
Многие контракты используют «isContract (address)» (проверка длины кода адреса), чтобы предотвратить участие контрактных счетов в определенных операциях, таких какairdrops, покупки и т. д.:
В рамках механизма EIP-7702 адрес пользователя может быть изменен на контрактный аккаунт с помощью транзакции "set_code", а "isContract" возвращает true, и контракт ошибочно определит, что законный пользователь является контрактным аккаунтом, и откажется от участия в операции, в результате чего пользователь не сможет использовать определенные сервисы и опыт будет заблокирован.
С распространением контрактных кошельков полагаться на «isContract» для определения «является ли пользователь человеком» больше не безопасно, рекомендуется использовать более точные методы идентификации пользователей, такие как проверка подписи.
Фишинг-атака
После внедрения механизма делегирования EIP-7702 активы в пользовательском аккаунте будут полностью контролироваться назначенным смарт-контрактом. Как только пользователь уполномочивает вредоносный контракт, злоумышленник может получить полный контроль над активами аккаунта, что может привести к быстрому переводу или краже средств, что представляет собой высокий уровень риска безопасности.
Поэтому важно, чтобы поставщики услуг кошельков как можно скорее поддерживали механизмы разрешения транзакций EIP-7702 и выявления рисков. Когда пользователь подписывает транзакцию доверенности, внешний интерфейс должен четко и заметно отображать адрес целевого контракта и объединять вспомогательную информацию, такую как информация об источнике контракта и развертывании, чтобы помочь пользователям выявить потенциальное фишинговое или мошенническое поведение, тем самым снижая риск неправильного подписания. Кроме того, сервис кошелька должен интегрировать возможности автоматизированного анализа безопасности для целевого контракта, такие как проверка статуса открытого исходного кода контракта, анализ модели разрешений и идентификация потенциально опасных операций, чтобы помочь пользователям принимать более безопасные суждения перед авторизацией.
Особое внимание следует обратить на то, что формат делегатских подписей, введенный в EIP-7702, несовместим с существующими стандартами подписей EIP-191 и EIP-712. Его подпись легко может обойти предупреждения и взаимодействия, предусмотренные в кошельке, что увеличивает риск того, что пользователи будут обмануты и подпишут злонамеренные действия. Поэтому внедрение механизма распознавания и обработки этой структуры подписей в реализации кошелька будет ключевым моментом для обеспечения безопасности пользователей.
Риски контрактов кошельков
(1) Управление правами контрактов кошелька
Многие контракты кошельков EIP-7702 используют прокси-архитектуру ( или встроенные административные права ) для поддержки логических обновлений. Однако это также создает более высокий риск управления правами. Если права на обновление не будут строго ограничены, злоумышленники могут заменить реализующий контракт и внедрить вредоносный код, что приведет к изменению учетных записей пользователей или кражам средств.
Рекомендации по безопасности:
Используйте многофакторную аутентификацию, многоуровневую подпись или механизм временной блокировки для контроля прав на обновление.
Коды и изменения разрешений должны проходить строгую проверку и безопасность.
Процесс обновления является открытым и прозрачным, чтобы обеспечить право пользователей знать и участвовать.
(2) Риски конфликтов при хранении и изоляция данных
Версии контрактов кошельков или различные поставщики услуг кошельков могут использовать одни и те же ячейки памяти (storage slot). Если пользователь меняет поставщика кошелька или обновляет логику кошелька, повторное использование ячейки памяти может привести к конфликту переменных состояния, возникновению проблем с перезаписью данных и чтением. Это может не только нарушить нормальное функционирование кошелька, но и привести к потере средств или аномалиям в правах.
Рекомендации по безопасности:
Используйте специализированные решения для изоляции хранилища (например, стандарт EIP-1967) или управляйте слотами хранения с помощью уникального пространства имен.
При обновлении контракта убедитесь, что структура хранения совместима и избегайте наложения переменных.
Тщательно проверяйте разумность состояния хранения в процессе обновления.
(3) Управление nonce внутри кошелька
Контракт кошелька обычно внутренне настраивает nonce и управляет им самостоятельно, чтобы гарантировать порядок выполнения операций пользователя и предотвратить атаки повторного воспроизведения. Неправильное использование nonce может привести к тому, что операции пользователя не будут выполняться должным образом.
Рекомендации по безопасности:
nonce должен быть строго проверен на равенство (или увеличен), нельзя пропускать.
Запрещено напрямую изменять nonce в функции, он должен обновляться только при выполнении действий пользователем.
Разработать механизмы обработки и восстановления в случае аномалий nonce, чтобы избежать взаимной блокировки nonce.
(4) Проверка прав вызывающего функции
Для обеспечения безопасности контракт кошелька должен гарантировать, что вызов ключевых функций осуществляется учетной записью владельца кошелька. Два распространенных способа включают в себя:
Подпись на стороне цепи
Пользователь подписывает набор операций с помощью закрытого ключа, а контракт кошелька проверяет на блокчейне, действительна ли подпись, не истекла ли она и соответствует ли соответствующему nonce. Этот метод подходит для модели транзакций реле, предлагаемой EIP-7702 (подпись пользователем оффлайн + отправка транзакций релеем).
Вызов ограничения (msg.sender == address (this))
Функции управления пользователями могут быть вызваны только самим контрактом, по сути это механизм контроля путей вызова, который обеспечивает, что инициатором вызова должен быть сам аккаунт. Это фактически эквивалентно требованию, чтобы вызывающий был оригинальным EOA, поскольку в это время адрес контракта является адресом EOA.
Три. Перспективы: EIP-7702 и будущее стандарта AA кошельков
Предложение EIP-7702 не только является революцией в традиционной модели счетов, но и представляет собой значительный толчок для экосистемы абстракции счетов (Account Abstraction). Введенная им возможность загрузки кода контрактов пользователями открывает широкое пространство для исследований в будущем дизайне кошельков и системе контрактов, а также выдвигает новые требования к стандартам безопасности аудита.
Совместная эволюция с EIP-4337: переход к двойной совместимости
Хотя EIP-7702 и EIP-4337 имеют разные цели в дизайне, первый пересматривает механизм загрузки кода аккаунта, а второй строит полноценный вход для транзакций и экосистему упаковки. Однако они не противоречат друг другу, а наоборот, обладают сильной взаимодополняемостью:
EIP-4337 предоставляет "универсальный торговый канал" и "интерфейс выполнения абстрактных аккаунтов";
EIP-7702 позволяет пользователям динамически наделять контракты логическими способностями без изменения адреса;
Таким образом, в будущем кошельки могут использовать "двухмодную архитектуру поддержки": на цепочках, не поддерживающих EIP-4337, использовать EIP-7702 в качестве облегченной замены, а в сценариях, требующих пакетирования вне цепи и агрегации от нескольких пользователей, продолжать полагаться на полный стек протокола EIP-4337.
Этот двойной механизм также будет способствовать тому, что кошелек на уровне ядра будет поддерживать более гибкую модель прав доступа к учетным записям, механизм понижения и схемы отката.
Поддержка и вдохновение от новых логик кошельков, таких как MPC и ZK
Механизм контрактов аккаунтов, предложенный EIP-7702, имеет естественный потенциал для интеграции с современными популярными архитектурами, такими как MPC кошельки, ZK кошельки и модульные кошельки:
В режиме MPC процесс подписания больше не зависит от единственного закрытого ключа, а представляет собой совместное принятие решений несколькими сторонами. Подписи, созданные в результате интеграции EIP-7702 и MPC, могут контролировать динамически загружаемую логику контрактов, что позволяет реализовать более гибкие стратегии исполнения.
ZK кошелек проверяет личность или авторизацию пользователя с помощью нулевых знаний, не раскрывая информацию о приватном ключе. В сочетании с EIP-7702, ZK кошелек может временно внедрять определенный логический контракт после завершения проверки, что позволяет реализовать персонализированное развертывание поведения после приватных вычислений, например, автоматическое выполнение определенной логики только при соблюдении некоторых условий конфиденциальности.
Модульные кошельки (Modular Wallets) могут использовать EIP-7702 для разбиения логики аккаунта на несколько модулей, которые при необходимости загружаются динамически.
Таким образом, EIP-7702 предоставляет вышеупомянутым продвинутым кошелькам более нативный «исполняющий контейнер»: адрес пользователя остается неизменным, при этом можно инжектировать различную логику контракта, избегая проблем зависимости адресов в традиционном процессе развертывания контрактов, а также не требуется предварительное развертывание, что значительно повышает гибкость и возможность комбинации действий счета.
Вдохновение для разработчиков контрактов и аудиторов
EIP-7702 приведет к глубоким изменениям в парадигме разработки. Разработчики контрактов больше не рассматривают вызывающего абонента просто как традиционную учетную запись EOA или учетную запись с фиксированным контрактом, но должны адаптироваться к новому механизму: идентификация вызывающего абонента может динамически переключаться между EOA и статусом контракта во время транзакции, а логика поведения учетной записи больше не затвердевает статически, а может быть гибко изменена в соответствии с потребностями. Это требует от разработчиков и аудиторов:
Введение более строгой логики проверки вызывающего и определения прав доступа;
Проверьте, влияет ли логика динамического контракта на путь вызова;
Выявление потенциальных уязвимостей в поведении, таких как msg.sender.code.length == 0, isContract () и другие;
Ясно определить «контекстную зависимость» логики контракта, например, контроль границ статических вызовов и deleGatecall;
Поддержка симуляции и анализа восстановления сценария setCode на уровне цепочки инструментов.
Иными словами, безопасность кода больше не является лишь «проблемой перед развертыванием», а превращается в «динамический процесс, который необходимо проверять как в момент вызова, так и во время транзакции».
Четыре, резюме
EIP-7702 представляет более легкую, нативную и гибкую реализацию абстракции учетной записи (AA), которая позволяет обычному EOA переносить логику контракта и выполнять ее в одной транзакции. Этот механизм ломает традиционные статические предположения о поведении учетной записи, и разработчики больше не могут просто полагаться на состояние кода адреса учетной записи для оценки модели ее поведения, но им необходимо восстановить понимание идентичности и границ полномочий вызывающего объекта. Вместе с этим происходит смена парадигмы в аналитике безопасности. Фокус аудита больше не ограничивается вопросом «есть ли у адреса разрешения», а смещается на то, «что может сделать логика контракта, заложенная в транзакции, в текущем контексте». Каждая транзакция может содержать независимое определение поведения, что придает учетной записи большую функциональность и выдвигает более высокие требования к аудиту безопасности.
Содержание носит исключительно справочный характер и не является предложением или офертой. Консультации по инвестициям, налогообложению или юридическим вопросам не предоставляются. Более подробную информацию о рисках см. в разделе «Дисклеймер».
Beosin: EIP-7702 и анализ безопасности следующего поколения AA Кошелек
Автор: Beosin
Абстракция аккаунта (Account Abstraction, AA) является важным направлением долгосрочных исследований в экосистеме Ethereum, целью которого является разрушение границ между внешними аккаунтами (EOA) и контрактными аккаунтами, обеспечивая более высокую программируемость, безопасность и возможность обновления для кошельков. EIP-4337, как наиболее распространенное решение для AA, уже широко используется в ряде смарт-контрактных кошельков на базе EntryPoint (таких как Safe, Stacks, Argent). Однако, EIP-4337, ввиду введения независимого пула транзакций и механизма входного контракта, все еще имеет определенные ограничения в отношении нативности на цепи, сложности операций и совместимости с экосистемой.
Для дальнейшего снижения порога использования абстракции учетной записи и усиления ее нативной поддержки, Виталик в 2024 году предложил EIP-7702 и включил это предложение в обновление Pectra. Основная идея EIP-7702 заключается в следующем: позволяя изначальной EOA при инициировании транзакции выполнить код контракта (contract_code) по указанному адресу, определяющему логику выполнения этой транзакции.
В EIP-7702 представлен новый механизм «внедрения кода на уровне транзакции», который позволяет учетным записям пользователей динамически указывать логику выполнения в каждой транзакции, а не полагаться на предварительно развернутый код контракта. Это нарушает традиционную модель разрешений на основе статического кода, обеспечивает большую гибкость и создает новые проблемы безопасности: контракты, которые полагаются на логику суждений, такую как isContract и extcodehash, могут стать недействительными, а некоторые системы, которые предполагают, что вызывающий является чистым EOA, могут быть обойдены. Для аудиторов важно не только проверить безопасность самого внедренного кода, но и оценить его потенциальное влияние на другие контрактные системы в динамическом контексте.
В этой статье команда безопасности Beosin систематически рассмотрит принципы проектирования и ключевые характеристики EIP-7702, а также возможные риски безопасности, с которыми может столкнуться AA-кошелек, построенный на его основе, в процессе аудита. Мы предложим процесс аудита и рекомендации с учетом практического опыта, чтобы помочь исследователям безопасности лучше справляться с техническими вызовами в этой новой парадигме.
Введение в EIP-7702
Обзор технологии EIP-7702
EIP-7702 вводит новый тип транзакции 0x04 (SetCode), который позволяет EOA авторизовать код контракта, который необходимо выполнить, через эту транзакцию. Структура транзакции следующая:
Внутри authorization_list содержится несколько списков авторизаций, которые также могут включать авторизационные действия, не относящиеся к инициатору сделки; внутренняя структура такова:
В этом контексте chain_id обозначает цепочку, на которой действуют полномочия пользователя, и его значение должно быть равно ID цепи выполнения или 0. Когда chain_id равно 0, это означает, что полномочия действуют для всех EVM цепей, поддерживающих EIP-7702, при этом другие параметры (например, nonce) должны совпадать. address обозначает адрес целевого контракта, на который выданы полномочия пользователя.
После завершения авторизации система изменит поле code авторизованного пользователя на 0xef0100 || address, где address — это адрес контракта, которому предоставлены права. Если вы хотите отменить авторизацию, просто инициируйте транзакцию SetCode и установите адрес на 0.
(1) Гибкость и настройки
Абстрактные аккаунты позволяют гибко настраивать функции в зависимости от потребностей, записывая логику аккаунта в смарт-контракты. Например, пользователи могут настраивать мультиподписи, социальное восстановление, контроль лимитов и т. д., чтобы удовлетворить различные потребности как физических, так и юридических лиц. Этот дизайн значительно увеличивает функциональную расширяемость аккаунта, преодолевая ограничения традиционных внешних аккаунтов (EOA).
(2) Увеличение безопасности
Абстрактные аккаунты предоставляют многоуровневые механизмы безопасности, включая многофакторную аутентификацию, лимиты на транзакции и социальное восстановление. Даже если пользователь потеряет свой приватный ключ, он сможет восстановить аккаунт через доверенных контактов или многофакторную проверку, что предотвращает постоянные потери активов, возникающие из-за потери приватного ключа в традиционных аккаунтах. В то же время функции контроля лимитов могут предотвратить кражу больших сумм средств.
(3) Газ оптимизация
Абстрактные аккаунты поддерживают гибкий механизм абстракции Gas, позволяя пользователям оплачивать Gas через третьи стороны или даже напрямую использовать другие токены для оплаты транзакционных сборов. Этот механизм не только снижает операционные расходы пользователей, но и дополнительно упрощает использование блокчейна, особенно подходит для новичков или сложных многопошаговых сценариев транзакций.
(4) способствовать распространению Web3
Оптимизируя опыт и безопасность, абстрактные аккаунты скрывают сложность блокчейна от пользователей, обеспечивая более удобные операции, близкие к Web2. Этот дизайн снижает затраты на обучение для обычных пользователей, позволяя большему количеству людей беспрепятственно участвовать в приложениях Web3 и способствуя распространению децентрализованных технологий.
Хотя EIP-7702 привнес новую динамику в экосистему Ethereum и расширил множество применений, он также неизбежно вводит некоторые новые риски безопасности:
В модели EIP-7702, если пользователь устанавливает поле chain_id в 0 в авторизации, это означает, что данная авторизация может быть действительна на нескольких цепях. Хотя такой дизайн «кросс-цепочной универсальной авторизации» увеличивает гибкость в определенных сценариях, он также вносит явные риски безопасности.
Важно отметить, что даже если идентификаторы аккаунтов на разных цепочках совпадают, реализованные контракты могут быть совершенно разными. Это означает, что злоумышленник может развернуть вредоносную версию контракта на другой цепочке и использовать действия по авторизации с тем же адресом в цепочке для выполнения непредвиденных операций, что может привести к рискам для активов пользователей.
Поэтому для поставщиков услуг кошельков или платформ взаимодействия с клиентами при выполнении пользователем таких операций авторизации необходимо четко проверить, соответствует ли заявленный в авторизации chainId текущей подключенной сети; если будет обнаружено, что пользователь установил chainId равным 0, следует предоставить четкое предупреждение о рисках, уведомив пользователя о том, что данная авторизация будет действовать на всех совместимых с EVM цепях и может быть злоупотреблена вредоносными контрактами.
Кроме того, сторона, предоставляющая услуги, должна оценить, следует ли на уровне UI по умолчанию ограничить или запретить авторизацию с chainId равным 0, чтобы снизить риск ошибок в операциях или фишинговых атак.
(1) Совместимость обратных вызовов контрактов
Существующие токен-контракты ERC-721, ERC-777, ERC1155 и другие при переводе средств на адрес контракта будут вызывать стандартные интерфейсы обратного вызова (например, onERC721Received, tokensReceived) для завершения операции перевода. Если адрес получателя не реализовал соответствующий интерфейс, перевод завершится неудачей и даже может привести к блокировке активов.
В EIP-7702 адреса пользователей могут быть назначены кодом контракта с помощью операции «set_code», превращая их в контрактные счета. В этом случае:
Адрес пользователя будет рассматриваться как контракт;
Если этот контракт не реализует необходимые интерфейсы обратного вызова, это приведет к неудаче при переводе токенов;
Пользователи могут не осознавать, что не могут получать основные токены.
Таким образом, разработчики должны убедиться, что целевой контракт, на который делегируют пользователи, реализует соответствующие интерфейсы обратного вызова для обеспечения совместимости с основными токенами.
(2) Проверка «tx.origin» не действительна
В традиционных контрактах «tx.origin» часто используется для определения того, инициировалась ли транзакция непосредственно пользователем, что помогает предотвратить вызов контракта и другие меры безопасности. Но в контексте EIP-7702:
Пользователь подписывает авторизацию на транзакцию, которая фактически транслируется ретранслятором или службой объединения (bundler); при выполнении транзакции «tx.origin» является адресом ретранслятора, а не адресом пользователя.
«msg.sender» является кошелек-контрактом, представляющим идентичность пользователя.
Таким образом, проверка прав на основе «tx.origin == msg.sender» приведет к отказу в операциях законных пользователей, потеряв надежность, и аналогично, использование ограничений вызова контрактов, таких как «tx.origin == user», также станет неэффективным. Рекомендуется отказаться от использования «tx.origin» в качестве основы для обеспечения безопасности и вместо этого использовать механизмы проверки подписи или авторизации.
(3) Ошибка в «isContract»
Многие контракты используют «isContract (address)» (проверка длины кода адреса), чтобы предотвратить участие контрактных счетов в определенных операциях, таких какairdrops, покупки и т. д.:
В рамках механизма EIP-7702 адрес пользователя может быть изменен на контрактный аккаунт с помощью транзакции "set_code", а "isContract" возвращает true, и контракт ошибочно определит, что законный пользователь является контрактным аккаунтом, и откажется от участия в операции, в результате чего пользователь не сможет использовать определенные сервисы и опыт будет заблокирован. С распространением контрактных кошельков полагаться на «isContract» для определения «является ли пользователь человеком» больше не безопасно, рекомендуется использовать более точные методы идентификации пользователей, такие как проверка подписи.
После внедрения механизма делегирования EIP-7702 активы в пользовательском аккаунте будут полностью контролироваться назначенным смарт-контрактом. Как только пользователь уполномочивает вредоносный контракт, злоумышленник может получить полный контроль над активами аккаунта, что может привести к быстрому переводу или краже средств, что представляет собой высокий уровень риска безопасности.
Поэтому важно, чтобы поставщики услуг кошельков как можно скорее поддерживали механизмы разрешения транзакций EIP-7702 и выявления рисков. Когда пользователь подписывает транзакцию доверенности, внешний интерфейс должен четко и заметно отображать адрес целевого контракта и объединять вспомогательную информацию, такую как информация об источнике контракта и развертывании, чтобы помочь пользователям выявить потенциальное фишинговое или мошенническое поведение, тем самым снижая риск неправильного подписания. Кроме того, сервис кошелька должен интегрировать возможности автоматизированного анализа безопасности для целевого контракта, такие как проверка статуса открытого исходного кода контракта, анализ модели разрешений и идентификация потенциально опасных операций, чтобы помочь пользователям принимать более безопасные суждения перед авторизацией.
Особое внимание следует обратить на то, что формат делегатских подписей, введенный в EIP-7702, несовместим с существующими стандартами подписей EIP-191 и EIP-712. Его подпись легко может обойти предупреждения и взаимодействия, предусмотренные в кошельке, что увеличивает риск того, что пользователи будут обмануты и подпишут злонамеренные действия. Поэтому внедрение механизма распознавания и обработки этой структуры подписей в реализации кошелька будет ключевым моментом для обеспечения безопасности пользователей.
(1) Управление правами контрактов кошелька
Многие контракты кошельков EIP-7702 используют прокси-архитектуру ( или встроенные административные права ) для поддержки логических обновлений. Однако это также создает более высокий риск управления правами. Если права на обновление не будут строго ограничены, злоумышленники могут заменить реализующий контракт и внедрить вредоносный код, что приведет к изменению учетных записей пользователей или кражам средств.
Рекомендации по безопасности:
Используйте многофакторную аутентификацию, многоуровневую подпись или механизм временной блокировки для контроля прав на обновление.
Коды и изменения разрешений должны проходить строгую проверку и безопасность.
Процесс обновления является открытым и прозрачным, чтобы обеспечить право пользователей знать и участвовать.
(2) Риски конфликтов при хранении и изоляция данных
Версии контрактов кошельков или различные поставщики услуг кошельков могут использовать одни и те же ячейки памяти (storage slot). Если пользователь меняет поставщика кошелька или обновляет логику кошелька, повторное использование ячейки памяти может привести к конфликту переменных состояния, возникновению проблем с перезаписью данных и чтением. Это может не только нарушить нормальное функционирование кошелька, но и привести к потере средств или аномалиям в правах.
Рекомендации по безопасности:
Используйте специализированные решения для изоляции хранилища (например, стандарт EIP-1967) или управляйте слотами хранения с помощью уникального пространства имен.
При обновлении контракта убедитесь, что структура хранения совместима и избегайте наложения переменных.
Тщательно проверяйте разумность состояния хранения в процессе обновления.
(3) Управление nonce внутри кошелька
Контракт кошелька обычно внутренне настраивает nonce и управляет им самостоятельно, чтобы гарантировать порядок выполнения операций пользователя и предотвратить атаки повторного воспроизведения. Неправильное использование nonce может привести к тому, что операции пользователя не будут выполняться должным образом.
Рекомендации по безопасности:
nonce должен быть строго проверен на равенство (или увеличен), нельзя пропускать.
Запрещено напрямую изменять nonce в функции, он должен обновляться только при выполнении действий пользователем.
Разработать механизмы обработки и восстановления в случае аномалий nonce, чтобы избежать взаимной блокировки nonce.
(4) Проверка прав вызывающего функции
Для обеспечения безопасности контракт кошелька должен гарантировать, что вызов ключевых функций осуществляется учетной записью владельца кошелька. Два распространенных способа включают в себя:
Подпись на стороне цепи
Пользователь подписывает набор операций с помощью закрытого ключа, а контракт кошелька проверяет на блокчейне, действительна ли подпись, не истекла ли она и соответствует ли соответствующему nonce. Этот метод подходит для модели транзакций реле, предлагаемой EIP-7702 (подпись пользователем оффлайн + отправка транзакций релеем).
Вызов ограничения (msg.sender == address (this))
Функции управления пользователями могут быть вызваны только самим контрактом, по сути это механизм контроля путей вызова, который обеспечивает, что инициатором вызова должен быть сам аккаунт. Это фактически эквивалентно требованию, чтобы вызывающий был оригинальным EOA, поскольку в это время адрес контракта является адресом EOA.
Три. Перспективы: EIP-7702 и будущее стандарта AA кошельков
Предложение EIP-7702 не только является революцией в традиционной модели счетов, но и представляет собой значительный толчок для экосистемы абстракции счетов (Account Abstraction). Введенная им возможность загрузки кода контрактов пользователями открывает широкое пространство для исследований в будущем дизайне кошельков и системе контрактов, а также выдвигает новые требования к стандартам безопасности аудита.
Хотя EIP-7702 и EIP-4337 имеют разные цели в дизайне, первый пересматривает механизм загрузки кода аккаунта, а второй строит полноценный вход для транзакций и экосистему упаковки. Однако они не противоречат друг другу, а наоборот, обладают сильной взаимодополняемостью:
EIP-4337 предоставляет "универсальный торговый канал" и "интерфейс выполнения абстрактных аккаунтов";
EIP-7702 позволяет пользователям динамически наделять контракты логическими способностями без изменения адреса;
Таким образом, в будущем кошельки могут использовать "двухмодную архитектуру поддержки": на цепочках, не поддерживающих EIP-4337, использовать EIP-7702 в качестве облегченной замены, а в сценариях, требующих пакетирования вне цепи и агрегации от нескольких пользователей, продолжать полагаться на полный стек протокола EIP-4337.
Этот двойной механизм также будет способствовать тому, что кошелек на уровне ядра будет поддерживать более гибкую модель прав доступа к учетным записям, механизм понижения и схемы отката.
Механизм контрактов аккаунтов, предложенный EIP-7702, имеет естественный потенциал для интеграции с современными популярными архитектурами, такими как MPC кошельки, ZK кошельки и модульные кошельки:
В режиме MPC процесс подписания больше не зависит от единственного закрытого ключа, а представляет собой совместное принятие решений несколькими сторонами. Подписи, созданные в результате интеграции EIP-7702 и MPC, могут контролировать динамически загружаемую логику контрактов, что позволяет реализовать более гибкие стратегии исполнения.
ZK кошелек проверяет личность или авторизацию пользователя с помощью нулевых знаний, не раскрывая информацию о приватном ключе. В сочетании с EIP-7702, ZK кошелек может временно внедрять определенный логический контракт после завершения проверки, что позволяет реализовать персонализированное развертывание поведения после приватных вычислений, например, автоматическое выполнение определенной логики только при соблюдении некоторых условий конфиденциальности.
Модульные кошельки (Modular Wallets) могут использовать EIP-7702 для разбиения логики аккаунта на несколько модулей, которые при необходимости загружаются динамически.
Таким образом, EIP-7702 предоставляет вышеупомянутым продвинутым кошелькам более нативный «исполняющий контейнер»: адрес пользователя остается неизменным, при этом можно инжектировать различную логику контракта, избегая проблем зависимости адресов в традиционном процессе развертывания контрактов, а также не требуется предварительное развертывание, что значительно повышает гибкость и возможность комбинации действий счета.
EIP-7702 приведет к глубоким изменениям в парадигме разработки. Разработчики контрактов больше не рассматривают вызывающего абонента просто как традиционную учетную запись EOA или учетную запись с фиксированным контрактом, но должны адаптироваться к новому механизму: идентификация вызывающего абонента может динамически переключаться между EOA и статусом контракта во время транзакции, а логика поведения учетной записи больше не затвердевает статически, а может быть гибко изменена в соответствии с потребностями. Это требует от разработчиков и аудиторов:
Введение более строгой логики проверки вызывающего и определения прав доступа;
Проверьте, влияет ли логика динамического контракта на путь вызова;
Выявление потенциальных уязвимостей в поведении, таких как msg.sender.code.length == 0, isContract () и другие;
Ясно определить «контекстную зависимость» логики контракта, например, контроль границ статических вызовов и deleGatecall;
Поддержка симуляции и анализа восстановления сценария setCode на уровне цепочки инструментов.
Иными словами, безопасность кода больше не является лишь «проблемой перед развертыванием», а превращается в «динамический процесс, который необходимо проверять как в момент вызова, так и во время транзакции».
Четыре, резюме
EIP-7702 представляет более легкую, нативную и гибкую реализацию абстракции учетной записи (AA), которая позволяет обычному EOA переносить логику контракта и выполнять ее в одной транзакции. Этот механизм ломает традиционные статические предположения о поведении учетной записи, и разработчики больше не могут просто полагаться на состояние кода адреса учетной записи для оценки модели ее поведения, но им необходимо восстановить понимание идентичности и границ полномочий вызывающего объекта. Вместе с этим происходит смена парадигмы в аналитике безопасности. Фокус аудита больше не ограничивается вопросом «есть ли у адреса разрешения», а смещается на то, «что может сделать логика контракта, заложенная в транзакции, в текущем контексте». Каждая транзакция может содержать независимое определение поведения, что придает учетной записи большую функциональность и выдвигает более высокие требования к аудиту безопасности.