Руководство по безопасности EIP-7702: пять критических уязвимостей новой механики, выявленных после хищения $6,3 млрд на Binance

30 октября на Binance было похищено 6,3 млрд долларов США — событие потрясло весь мир. Последующий анализ показал, что злоумышленники не использовали традиционный метод кражи приватных ключей, а применили механизм делегированного авторизации EIP-7702 — новую функцию Ethereum, активированную лишь в этом году. Это не «новая уязвимость», а «слепая зона проектирования» самого механизма, столкнувшаяся с человеческой инерцией в вопросах безопасности. Попасть в ловушку могут как обычные пользователи, так и разработчики. В этой статье мы детально разберём всю цепочку атаки, простым языком объясним, что такое EIP-7702, и в конце приведём по пять практических рекомендаций для пользователей и разработчиков.

1. Какую роль сыграл EIP-7702 в инциденте с Binance

Вернёмся к самому событию. Рано утром 30 октября аналитик блокчейна Шэнь Юй (Shen Yu) опубликовал в X тревожную деталь: 14 горячих кошельков Binance после обновления Ethereum до Pectra подписали некие «подозрительные транзакции» — транзакции типа 4. При этом эти кошельки сохраняли действительную делегированную авторизацию на внешний контракт злоумышленников.

Сейчас сообщество восстановило примерную последовательность атаки:

1. Точка входа: ноутбук одного из внутренних разработчиков или инженеров Binance был скомпрометирован фишингом или вредоносной программой;
2. Внедрение вредоносной транзакции: злоумышленники получили доступ к внутреннему каналу подписи и смогли отправлять в горячие кошельки транзакции типа 4;
3. Массовая делегация: за несколько часов 50 горячих кошельков последовательно «поставили подписи», делегировав право на выполнение кода контролируемому злоумышленниками контракту;
4. Захват контроля: после активации делегации злоумышленцы могли вызывать эти горячие кошельки так же, как собственные контракты — система подписи видела лишь 32-байтовый «хеш транзакции», но на деле пользователь подписывал документ, отдающий «ключи от машины» третьему лицу.

К счастью, после того как инцидент стал известен, команда Binance оперативно развернула транзакции отмены. На сегодняшний день около 3 млрд долларов США похищенных средств успешно заблокированы — это означает, что делегация по EIP-7702 обратима, но только при условии, что вы всё ещё можете подписать транзакцию отмены. Полная хронология события представлена в нашем предыдущем глубоком материале: Похищено $6,3 млрд: горячие кошельки Binance захвачены через делегацию EIP-7702.

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

2. Краткий обзор механизма EIP-7702 (понятно за 3 минуты)

В классическом Ethereum существует два типа аккаунтов: EOA (внешне управляемые аккаунты) и контрактные аккаунты. EOA — это как банковская карта: одна подпись — одна операция. Контрактный аккаунт — это логика, размещённая в блокчейне. Основная задача EIP-7702 — решить вопрос: можно ли временно наделить EOA возможностями контрактного аккаунта?

Ответ — «делегированная авторизация (delegation)». Простая аналогия: вы одолжили другу (целевому контракту) свою машину (EOA). Не меняя номера, вы просто подписываете в блокчейне доверенность, где чётко указано: «ключи временно передаются такому-то».

С технической точки зрения EIP-7702 вводит два ключевых изменения:

• Транзакция типа 4: новый тип транзакции, предназначенный исключительно для «подписания делегации». Подписывающий не обязан переводить ETH на целевой адрес — достаточно просто опубликовать доверенность в блокчейне.
• Делегация действует бессрочно — до явной отмены. Это самое важное и чаще всего игнорируемое правило: автоматического истечения срока действия нет, и никакого «одноразового использования» тоже.

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

3. Пять фатальных слепых зон (в которые попадают обычные пользователи)

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

1. Делегация не истекает автоматически — если не отменить, «ключи» остаются у других навсегда

Многие DApp предлагают пользователям «нажать Delegate — и комиссии за переводы станут на 20 % ниже». Пользователь соглашается и забывает. А делегация остаётся в блокчейне вечно. Если DApp сменит команду или даже продаст свой адрес — ваши «ключи» всё ещё будут в руках третьих лиц.

2. Интерфейс кошелька не отображает, кому вы уже делегировали доступ

Это сейчас самый деликатный момент во всей экосистеме. По состоянию на октябрь 2026 года большинство популярных кошельков (Trust Wallet, Exodus и даже некоторые интерфейсы для аппаратных кошельков) не имеют раздела «Управление делегациями». Вы могли подписать 17 транзакций типа 4, но в интерфейсе кошелька увидите лишь набор «хешей транзакций», совершенно не зная, кому вы отдали «ключи».
Хорошая новость: etherscan.io обновил интерфейс — теперь, открыв страницу своего адреса, вы можете перейти на вкладку «Delegations» и увидеть все исторические делегации.etherscan.io — на сегодняшний день самый надёжный инструмент для самостоятельной проверки.

3. Подпись действует мгновенно — второго подтверждения не требуется

Вы нажимаете «Подтвердить» в DApp, кошелёк выводит всплывающее окно: «Комиссия — 0,001 ETH», вы подписываете — и в блокчейне происходит следующее: ваш EOA публикует бессрочную делегацию на контракт злоумышленника. Никакого второго окна, никакого дополнительного подтверждения. Подписывающий видит лишь 32-байтовый хеш транзакции и не может отличить её от обычного перевода или type-4.

4. Делегации могут быть вложенными — первоначальный подписант об этом даже не узнаёт

A делегирует B, B делегирует C, C делегирует D — теоретически вложенность может быть бесконечной. В инциденте с Binance также были замечены признаки цепочки вложенных делегаций. Если ваш кошелёк уже захвачен вредоносным контрактом, он может без вашего ведома передать контроль ещё множеству адресов.

5. Для отмены делегации тоже нужна подпись

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

4. Практический чек-лист для обычных пользователей

После всего сказанного — что делать прямо сейчас? Проверьте себя по следующему 5-шаговому алгоритму:

✅ Шаг 1: немедленно проверьте историю делегаций своего кошелька.
Перейдите на etherscan.io, введите свой адрес кошелька и откройте вкладку «Delegations». Если в списке делегаций вы видите незнакомые адреса — это «заминированная бомба».

✅ Шаг 2: немедленно отмените любые незнакомые делегации.
Для отмены лучше всего использовать OpenZeppelin Defender или сообществом поддерживаемый инструмент EIP-7702 Revoker. Стоимость газа для одной транзакции отмены обычно составляет $1–5; процесс аналогичен обычной отправке средств.
⚠️ Внимание: если ваш кошелёк уже захвачен вредоносной делегацией, отмена может завершиться неудачей. В этом случае наиболее безопасный способ — сгенерировать подпись транзакции отмены офлайн на аппаратном кошельке (Ledger, Trezor), а затем отправить её с чистого компьютера.

✅ Шаг 3: временно измените привычки использования кошелька.
Если вы используете Trust Wallet или Exodus, пока воздержитесь от подписания type-4-транзакций напрямую. Более безопасная комбинация — аппаратный кошелёк Ledger + браузерное расширение Rabby. Аппаратные устройства не выполняют вложенные делегации автоматически и точно не подпишут ничего «втихую».

✅ Шаг 4: не нажимайте кнопку «Delegate» в незнакомых DApp.
Любое DApp, предлагающее «скидку на комиссию», «бесплатные переводы» или «автоматический доход» в обмен на делегацию, требует паузы. Зайдите в X или Telegram, найдите название DApp + слова «hack» или «scam» и потратьте 3 минуты на проверку репутации — это выгоднее, чем сэкономленные доллары на газе.

✅ Шаг 5: особое предупреждение для пользователей бирж.
Если вы в основном пользуетесь централизованными биржами вроде Binance или OKX, то управление делегациями горячих кошельков осуществляется ими централизованно. Вам лично ничего дополнительно делать не нужно. Однако настоятельно рекомендуется использовать официальное мобильное приложение биржи и не подписывать type-4-транзакции напрямую в сторонних кошельках, отправляя средства на депозитные адреса биржи.

5. Практический чек-лист для разработчиков

Как разработчик DApp или DeFi-проекта, вы несёте повышенную ответственность. Ниже приведены пять пунктов, которые сегодня считаются минимальным «базовым уровнем безопасности» в индустрии:

1. В делегации обязательно должен быть указан разумный срок действия (expiry).
Хотя не все кошельки пока поддерживают проверку expiry на уровне подписи, логика вашего делегационного контракта должна жёстко включать такую проверку. Делегация, «автоматически аннулирующаяся через 30 дней», принципиально безопаснее бессрочной.

2. Интерфейс должен предупреждать пользователя о type-4-транзакции красным всплывающим окном.
Стандартная практика: после нажатия кнопки Delegate фронтенд выводит отдельное красное модальное окно с крупным жирным текстом: «⚠️ Вы собираетесь подписать транзакцию делегации EIP-7702 — это предоставит целевому адресу право выполнять код от имени вашего кошелька», и требует ручного ввода фразы «Я осознаю риски» для продолжения.

3. Никогда не принимайте целевой адрес делегации от пользователя.
Адрес контракта, которому предоставляется делегация, должен быть жёстко задан в коде фронтенда и проверен на соответствие с адресом, размещённым в блокчейне. Разрешить пользователю ввести target — значит отдать ему «номер квартиры», по которой он сможет достучаться до ваших ключей.

4. Перейдите на вариант «delegateWithPermissions» из EIP-7715.
EIP-7715 расширяет EIP-7702, добавляя ограничения прав (permissions): можно указать, какие функции целевой контракт может вызывать, а какие — нет. Теоретически это должно быть стандартом, хотя поддержка пока ограничена. Начинайте миграцию как можно скорее.

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

6. Заключение

EIP-7702 — это не протокол с «багом». Его основная цель — наделить обычные EOA возможностями контрактных аккаунтов — абсолютно корректна. Проблема в том, что базовое допущение «бессрочности» сталкивается с самым уязвимым звеном всей экосистемы Ethereum — человеческими привычками в области безопасности.

Инцидент с Binance, возможно, стал самым дорогим уроком безопасности со времени запуска EIP-7702. Но с другой стороны, он резко вывел всю экосистему из «беззаботного сна» делегаций. Теперь etherscan имеет вкладку «Delegations», команды кошельков внедряют предупреждающие всплывающие окна, OpenZeppelin обновил скрипты аудита — каждый инцидент делает этот механизм безопаснее.

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