EIP-7702 простыми словами. Как работает новая подпись Ethereum и чем она опасна

Представьте, что криптовалютный сервис предлагает активировать новую функцию кошелька. Для этого нужно подписать специальный запрос. Переводить ETH никуда не требуется, сумма операции равна нулю, а комиссию обещают оплатить за вас. Всё выглядит вполне безобидно.

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

Один из механизмов подобных атак связан с EIP-7702. Стандарт позволяет обычному адресу Ethereum выполнять программный код смарт-контракта. При правильном применении кошелёк становится удобнее и получает дополнительные средства защиты. При ошибке пользователь может разрешить чужой программе управлять своими активами.

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

Однако EIP-7702 не является универсальной уязвимостью Ethereum. Обычное подключение MetaMask к сайту не даёт постороннему доступ к средствам, а распространённые кошельки ограничивают возможность подписывать произвольные делегирования. Для атаки нужны дополнительные условия, включая опасную авторизацию, ошибку в программном кошельке или компрометацию закрытого ключа.

Зачем Ethereum понадобился EIP-7702

До мая 2025 года большинство обычных адресов Ethereum работали по простой модели. У владельца есть закрытый ключ, которым подписываются транзакции. Такой аккаунт называется EOA, сокращение от Externally Owned Account, то есть аккаунт под управлением внешнего владельца.

EOA умеет хранить ETH, взаимодействовать с токенами и вызывать смарт-контракты, но не может самостоятельно задавать сложные правила управления. Например, обычный аккаунт не способен на уровне собственного кода потребовать два независимых подтверждения перед переводом или разрешить дополнительному ключу тратить не более определённой суммы в сутки.

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

7 мая 2025 года в основной сети Ethereum активировали обновление Pectra. Одним из нововведений стал EIP-7702, позволяющий подключать программную логику к существующему обычному адресу.

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

EIP-7702 создаёт основу для нескольких полезных функций.

• Пакетные операции. Несколько действий выполняются в рамках одной транзакции. Например, разрешение на расход токенов и последующий обмен можно объединить.
• Оплата комиссии третьей стороной. Приложение или посредник может оплатить сетевую комиссию за пользователя. В некоторых реализациях расходы компенсируются другими токенами.
• Ограниченные разрешения. Программа кошелька может выдавать дополнительным ключам полномочия с ограничениями по сумме, времени и допустимым операциям.
• Дополнительные способы защиты. Разработчики могут реализовать несколько подтверждений, особые правила перевода средств и механизмы восстановления доступа.
• Автоматизация. Программируемый аккаунт может выполнять заранее разрешённые действия по заданным условиям.

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

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

Как работает делегирование EIP-7702

Предположим, Алиса хранит на обычном Ethereum-адресе 2 ETH, несколько тысяч USDC и коллекционный NFT. Она хочет пользоваться программируемым кошельком, не переводя активы на другой адрес.

Алиса подписывает специальную авторизацию EIP-7702, указывающую адрес контракта с нужной программой. Авторизация включается в транзакцию нового типа 0x04. После проверки подписи Ethereum записывает в аккаунт специальный указатель на контракт.

Указатель состоит из трёх начальных байтов 0xef0100 и следующих за ними 20 байт адреса делегированного контракта. Общая длина записи составляет 23 байта.

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

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

Если программа допускает вызовы без надлежащей проверки полномочий, посторонний сможет инициировать перевод ETH, токенов или NFT. Для взаимодействующих контрактов отправителем таких вызовов будет выступать адрес Алисы.

Что именно подписывает владелец кошелька

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

Авторизация включает три основных поля.

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

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

keccak256(0x05 || rlp([chain_id, address, nonce]))

Здесь Keccak-256 представляет собой хеш-функцию, RLP задаёт способ кодирования данных, а специальный байт 0x05 отделяет авторизацию EIP-7702 от других видов подписываемых сообщений.

Принципиальная особенность заключается в отсутствии полей, ограничивающих сумму перевода, конкретный токен или срок действия разрешения. На уровне EIP-7702 пользователь разрешает выполнять код определённого контракта, а не потратить заранее установленное количество USDC.

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

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

Почему делегирование не исчезает после завершения операции

Первые варианты EIP-7702 предполагали временное подключение кода на время одной транзакции. В окончательной версии выбрали постоянное делегирование. Указатель остаётся в состоянии аккаунта до замены или явного удаления.

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

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

Следовательно, надпись Failed или Reverted в обозревателе транзакций не всегда означает, что попытка подключить код завершилась без последствий.

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

Чем EIP-7702 отличается от обычного разрешения на расход токенов

Пользователи децентрализованных бирж знакомы с командой approve. Смарт-контракт просит разрешить расход токенов ERC-20, например перед обменом USDC на ETH.

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

Такая схема давно используется в фишинговых атаках. Мошенник подменяет адрес получателя разрешения, а пользователь фактически разрешает чужому контракту распоряжаться токенами.

EIP-7702 работает на другом уровне. Авторизация меняет исполняемую логику самого аккаунта, а не запись о допустимом расходе одного токена.

Критерий	ERC-20 approve	EIP-7702
Что разрешает	Расход определённого токена	Выполнение программного кода от имени аккаунта
Какие активы затрагивает	Токены конкретного контракта ERC-20	Потенциально ETH, различные токены и NFT
Ограничение суммы	Указывается в разрешении, возможен неограниченный допуск	Отсутствует в самой авторизации
Срок действия	Обычно до изменения разрешения	До замены или удаления делегирования
Где хранится состояние	В контракте токена	Указатель в коде аккаунта, дополнительные данные могут храниться в его состоянии
Как отменить	Изменить или обнулить разрешение	Заменить делегирование либо удалить его через авторизацию нулевого адреса

Существуют и другие опасные разрешения, например подписи ERC-2612 Permit, механизм Permit2 и разрешение setApprovalForAll для NFT. Мошенники могут использовать такие механизмы без немедленного перевода средств.

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

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

Как мошенники используют EIP-7702 для кражи криптовалюты

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

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

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

При наличии технической возможности атака может развиваться следующим образом.

1. Мошенник размещает вредоносный контракт, который позволяет переводить активы с делегировавшего ему аккаунта.
2. Пользователь подписывает авторизацию EIP-7702 в поддерживающем такую операцию приложении либо злоумышленник получает подпись иным способом.
3. Авторизация попадает в транзакцию типа 0x04. Комиссию может оплатить сам злоумышленник.
4. В аккаунте появляется указатель на вредоносный контракт.
5. Злоумышленник вызывает опасную функцию от имени пользовательского адреса и выводит доступные средства.

Ключевой момент заключается в последнем действии. Если контракт неправильно проверяет полномочия, для каждого последующего перевода не требуется отдельная подпись владельца.

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

Автоматический вывод средств и опасность пустого кошелька

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

Само зачисление ETH или токенов не заставляет произвольный вредоносный контракт автоматически исполниться. Для вывода требуется соответствующая операция в сети. Но преступник способен автоматизировать наблюдение и отправку транзакций, поэтому средства могут исчезать практически сразу после поступления.

Владелец обнаруживает нулевой баланс, пополняет кошелёк для оплаты комиссии и снова теряет ETH. Аналогичная ситуация возможна с токенами, которые поступают на адрес позднее.

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

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

Реальные атаки и масштаб проблемы

Первые массовые признаки злоупотреблений появились вскоре после обновления Pectra. В июне 2025 года анализ действовавших делегирований выявил, что более 80% изученных назначений указывали на разновидности одной программы автоматического вывода средств. Такая концентрация отражала активность злоумышленников в конкретный период, а не долю всех пользователей Ethereum, потерявших криптовалюту.

В 2026 году более масштабное исследование, охватившее семь сетей с поддержкой EIP-7702, выявило 924 вредоносных контрактных аккаунта. С обнаруженными схемами связали потери свыше $2,3 млн, а стоимость потенциально уязвимых активов оценили более чем в $10 млн.

В исследованном наборе транзакций свыше 63% авторизаций оказались связаны с атаками на обычные аккаунты. Однако показатель нельзя переносить на всех владельцев программируемых кошельков. Автоматизированные операции преступников могут создавать огромное количество записей и существенно искажать представление о распространённости угрозы среди реальных пользователей.

Показательный инцидент произошёл в октябре 2026 года с Ethereum-адресом sven.eth. Первоначально сообщалось о потере примерно 9,12 ETH и дополнительных токенов вследствие злоупотребления EIP-7702.

Дальнейшее изучение операций связало атакующий контракт с делегированиями 120 адресов. При этом история оказалась сложнее первоначального сообщения. Примерно через девять минут после вывода средств со sven.eth на потерпевший адрес вернулось около 9,58 ETH, включая средства с других адресов. Позднее владелец отменил делегирование.

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

Почему даже проверенный контракт не гарантирует безопасность

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

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

Если пользователь подтверждает пакет, не проверив его содержимое, средства могут исчезнуть даже при использовании корректного и проверенного делегированного контракта.

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

Отдельного внимания заслуживают обновляемые контракты. Если программа использует промежуточный контракт с изменяемой логикой, неизменность адреса делегирования ещё не гарантирует неизменности выполняемого поведения. Безопасность зависит и от того, кто вправе обновлять такую реализацию.

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

Как проверить свой Ethereum-кошелёк на опасное делегирование

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

Достаточно знать публичный Ethereum-адрес. Все сведения о текущем делегировании хранятся в состоянии соответствующей сети и доступны для чтения.

Проверка через Etherscan

Самый понятный способ для обычного пользователя заключается в проверке адреса через обозреватель блокчейна.

1. Самостоятельно откройте Etherscan в браузере.
2. Введите публичный адрес своего кошелька.
3. Найдите в сведениях об аккаунте отметку о делегировании, в частности Delegated Address или Delegated to, если соответствующее поле отображается.
4. Если указан адрес контракта, выясните, какая программа использует делегирование.
5. Сравните адрес с официальной реализацией установленного программируемого кошелька.
6. Проверьте историю операций, включая транзакции типа 0x04 и сведения об их авторизациях.

Наличие делегирования не является доказательством взлома. Некоторые кошельки используют EIP-7702 для штатных функций. Например, известная реализация MetaMask DeleGator имеет адрес 0x63c0c19a282a1b52b07dd5a65b58948a07dae32b.

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

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

Отсутствие делегирования в основной сети Ethereum не означает, что тот же адрес безопасен в Base, Arbitrum, BNB Chain или другой совместимой сети. Состояние аккаунтов хранится отдельно, поэтому каждую используемую сеть необходимо проверять самостоятельно.

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

Техническая проверка через eth_getCode

Для более точной проверки можно воспользоваться методом Ethereum JSON-RPC eth_getCode. Он возвращает программный код, записанный за выбранным адресом в конкретной сети.

При наличии установленного набора инструментов Foundry запрос можно выполнить через утилиту cast.

cast code "$WALLET" --rpc-url "$RPC_URL"

Переменная WALLET должна содержать проверяемый адрес, а RPC_URL адрес доверенного узла нужной сети. Никакой закрытый ключ для чтения состояния аккаунта не нужен.

Возможные результаты интерпретируются следующим образом.

• 0x означает отсутствие кода на проверяемом адресе в выбранной сети и состоянии блока.
• Последовательность длиной 23 байта с префиксом 0xef0100 соответствует указателю делегирования EIP-7702.
• Последующие 20 байт содержат адрес делегированного контракта.
• Другой непустой код может принадлежать обычному контрактному аккаунту и сам по себе не свидетельствует об использовании EIP-7702.

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

Как отменить делегирование EIP-7702

Ethereum позволяет заменить действующий делегированный контракт либо полностью удалить указатель на него. В отличие от обычного разрешения ERC-20, отзыв затрагивает программную логику самого аккаунта.

Для удаления делегирования создаётся новая авторизация EIP-7702, в которой адресом контракта указан нулевой адрес.

0x0000000000000000000000000000000000000000

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

Однако выполнять такую операцию следует через поддерживаемый и доверенный кошелёк. Случайный сайт, предлагающий срочно «обнулить» делегирование, может оказаться очередной фишинговой страницей.

Как отключить программируемый режим в MetaMask

MetaMask позволяет возвращать собственные программируемые аккаунты в обычный режим. К октябрю 2026 года поддержка смарт-аккаунтов уже могла включаться автоматически для новых пользователей, поэтому само наличие штатного делегирования не должно вызывать панику.

В браузерном расширении MetaMask предусмотрен следующий порядок действий.

1. Откройте MetaMask и выберите нужный аккаунт.
2. Откройте меню с тремя точками рядом с аккаунтом.
3. Перейдите в раздел Account details, затем Smart account.
4. Отключите программируемый режим для нужной сети.
5. Проверьте параметры операции и подтвердите транзакцию.
6. После подтверждения проверьте состояние аккаунта в обозревателе блокчейна.

В мобильном приложении аналогичная настройка доступна в разделе Smart account выбранного аккаунта. Названия и расположение пунктов могут меняться между версиями. Актуальный порядок приведён в инструкции кошелька.

Отключение требует изменения состояния блокчейна, поэтому операция может сопровождаться сетевой комиссией.

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

Считайте делегирование отменённым только после проверки фактического состояния адреса в блокчейне.

Почему одного отзыва недостаточно

Удаление указателя EIP-7702 не отменяет автоматически все разрешения, которые программируемый аккаунт успел выдать другим контрактам.

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

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

Для просмотра разрешений ERC-20, NFT и активных делегирований подходит Revoke.cash. У сервиса есть отдельный раздел Delegations, в котором отображаются в том числе делегирования EIP-7702. Однако просмотр такой записи и её фактическая отмена представляют собой разные действия. Сам сервис не предоставляет универсального способа отзывать EIP-7702 для всех кошельков.

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

Что делать, если уже подписали подозрительную авторизацию

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

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

Подпись создана, но делегирование ещё не установлено

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

Авторизация EIP-7702 привязана к значению счётчика nonce. После успешной подходящей транзакции от соответствующего аккаунта счётчик увеличивается, поэтому ранее подписанная авторизация со старым значением перестаёт проходить проверку в этой сети.

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

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

Вредоносное делегирование уже работает

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

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

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

Такие операции требуют понимания механизма атаки и особенностей конкретной сети. Небезопасный инструмент восстановления способен усугубить ситуацию. Не передавайте секретную фразу людям, обещающим «моментально вернуть» средства.

Есть подозрение на кражу закрытого ключа

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

Необходимо создать новый кошелёк с новой секретной фразой на доверенном устройстве. После этого следует безопасно перенести сохранившиеся активы и прекратить использовать прежний адрес для хранения средств.

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

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

Почему EIP-7702 может быть опасен сразу в нескольких сетях

В авторизации предусмотрено поле chain_id, которое обычно ограничивает её применение определённым блокчейном. Но значение 0 означает, что авторизация не привязана к одной конкретной сети.

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

Предположим, один и тот же адрес используется в Ethereum и Base. Владелец подписал авторизацию с chain_id = 0, а значения счётчика аккаунта в обеих сетях совпадают.

Если злоумышленник получил такую подпись, появляется риск её применения в обеих сетях. Устранение последствий в Ethereum не обязательно защищает адрес в Base.

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

Обычному пользователю нет необходимости самостоятельно создавать универсальные авторизации с chain_id = 0. Разумнее пользоваться штатными механизмами кошелька, которые ограничивают действия конкретными сетями и поддерживаемыми контрактами.

Как распознать опасный запрос и защитить криптовалюту

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

Окна подтверждения могут содержать названия Account update, Smart account, Delegation, Authorization или другие обозначения. Подобные надписи сами по себе не указывают на мошенничество, поскольку программируемые кошельки используют их для законных операций.

Оценивать нужно смысл запроса, а не только название кнопки.

• Неизвестный сайт предлагает обновить кошелёк. Особенно подозрительны обещания подарков, бесплатных токенов и срочного устранения несуществующей ошибки безопасности.
• Адрес делегированного контракта неизвестен. Сравните его с официальной реализацией используемого кошелька. Не полагайтесь только на красивое название контракта в обозревателе.
• Запрос не объясняет полномочия. Если невозможно понять, какой код подключается и какие действия разрешаются, откажитесь от подписи.
• Не требуется оплачивать комиссию. Отсутствие комиссии у владельца не делает авторизацию безопасной. Транзакцию может оплатить другой участник.
• Требуют секретную фразу. Легитимному сайту не нужна секретная фраза для обновления программируемого кошелька.
• Предлагают подписать непонятный набор данных. Не подписывайте произвольные сообщения и хеши, назначение которых не можете проверить.

Стоит помнить, что обычная подпись personal_sign сама по себе не устанавливает EIP-7702. Для делегирования используется специальная структура авторизации. Но другие типы подписей тоже могут давать опасные разрешения, поэтому незнакомый запрос нельзя считать безопасным только потому, что он не относится к EIP-7702.

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

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

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

Что нужно запомнить об EIP-7702

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

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

Ошибочно считать, что любое делегирование означает взлом. Не менее опасно относиться к авторизации EIP-7702 как к обычной безобидной подписи. В зависимости от подключённого кода последствия могут оказаться значительно серьёзнее отдельного неудачного перевода.

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

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

Главное отличие EIP-7702 от привычной транзакции заключается в масштабе доверия. При обычном переводе владелец разрешает конкретное действие. При делегировании он разрешает определённой программе участвовать в управлении всем аккаунтом. Поэтому цена одной ошибочной авторизации может оказаться намного выше суммы, которую пользователь собирался потратить.