Основатель Cardano Чарльз Хоскинсон обратил внимание на проблемы безопасности, связанные с EIP-7702 (Ethereum Improvement Proposal 7702) в Ethereum, после того как исследователи заявили, что функция делегирования могла способствовать масштабам и скорости крупной атаки на безопасность Binance.

Согласно недавним сообщениям, объем потерянных Binance криптоактивов оценивается примерно в $6,3 млрд. Следователи пока не установили, каким именно образом атакующие получили доступ к системам подписания, задействованным в инциденте.

Хоскинсон обращает внимание на код sweeper в инциденте с Binance

Хоскинсон опубликовал 30 октября 2026 года технический разбор исследователя CyberSatoshi с предупреждением: «Осторожно, там есть по-настоящему опасный код».

Осторожно, там есть по-настоящему опасный код.

— Charles Hoskinson (@IOHK_Charles), 30 октября 2026 г.

Пост в X: https://x.com/IOHK_Charles/status/2116246648716411341?ref_src=twsrc%5Etfw

В анализе кошелек Binance, известный как «Binance 14», назван целью специально созданного sweeper-контракта — кода, предназначенного для автоматического вывода активов с целевого адреса по мере их поступления. При переводе ETH с кошелька контракт, как утверждается, оставлял ровно 1 ETH. Согласно анализу, это могло позволить автоматическим транзакционным системам Binance продолжать работу, пока активы выводились.

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

Хранилище USDC на $823 млн, предположительно, было в зоне досягаемости

CyberSatoshi заявил, что скомпрометированная функция исполнения могла также действовать в отношении внешнего хранилища, где находилось около $823 млн в USDC — стейблкоине, привязанном к доллару.

В посте от 30 октября исследователь описал реконструированный байткод sweeper-контракта Binance на базе EIP-7702, идентифицированного как 0x63e8…6fae, как созданный специально под архитектуру Binance 14, а не как универсальный инструмент вывода средств.

Согласно анализу, контракт:

• Оставлял ровно 1 ether при выводе ETH, используя bal – 1 ether, чтобы автоматическая очередь горячих кошельков Binance не столкнулась с ошибкой, связанной с газом, и не вызвала тревогу.
• Использовал «сырые» циклы staticcall и continue с пользовательским кодом ошибки SweepItemFailed, чтобы сломанный или внесенный в черный список токен ERC-20 не мог отменить всю batch-операцию на $6 млрд.
• Включал пользовательскую функцию callExecute, которая могла действовать от имени Binance 14 как контролера внешнего хранилища с $823 млн в USDC.

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

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

По словам CyberSatoshi, без EIP-7702 вывод 64 токенов и средств из внешнего хранилища на $823 млн с работающего горячего кошелька биржи потребовал бы управления меняющимися nonce более чем в 70 транзакциях — по правилам Ethereum каждая транзакция с аккаунта должна иметь последовательный nonce, поэтому переводы с одного адреса нельзя объединить в одну отправку. Исследователь заявил, что системы защиты могли остановить операцию после третьей транзакции.

С EIP-7702 атакующие, как утверждается, использовали 50 последовательных nonce в одном payload типа 4 — формате транзакции, введенном EIP-7702 для передачи списка авторизаций, — преобразовали аккаунт, принадлежащий пользователю (EOA), в пользовательский прокси и вывели миллиарды долларов в одном блоке. В посте операция была описана как «хирургическая инженерия, спонсируемая государством», с фразой: «Разработчики ядра Ethereum построили идеальную машину для побега».

Исследователь также привел следующий фрагмент кода в качестве примера механизма:

if (bal > 1 ether) {  bal – 1 ether}(“”); }

Читать реконструированный байткод sweeper Binance на базе EIP-7702 (0x63e8…6fae) — нечто. Это был не универсальный drainer. Он был специально создан под архитектуру Binance 14:

– Оставляет ровно 1 ether (bal – 1 ether) при выводе ETH, чтобы автоматическая очередь горячих кошельков Binance не получила ошибку по газу и не подняла тревогу.
– Использует «сырые» циклы staticcall + continue с пользовательскими кодами ошибок (SweepItemFailed), чтобы один «застрявший» или заблокированный ERC-20 не отменил batch на $6 млрд.
– Включает пользовательскую функцию callExecute, чтобы действовать от имени Binance 14 как контролера внешнего хранилища с $823 млн в USDC.

Они оставили комментарий: «ограбления можно было бы предотвратить, если бы машины для побега двигались медленнее». Нельзя полностью винить EIP-7702, но он ускорил атаку. Без 7702 вывод 64 токенов плюс внешнего хранилища на $823 млн с работающего горячего кошелька биржи означал бы борьбу с меняющимися nonce в 70+ транзакциях. Системы защиты убили бы ее после tx #3. С 7702 Lazarus выпустил 50 последовательных nonce в одном payload типа 4, превратил EOA в пользовательский прокси и атомарно вывел миллиарды в одном блоке. Разработчики ядра Ethereum построили идеальную машину для побега. Хирургическая инженерия, спонсируемая государством. Это можно было бы высечь в блокчейне: if (bal > 1 ether) { bal – 1 ether}(“”); }

— CyberSatoshi 𓆙 (@XBToshi), 30 октября 2026 г.

Пост в X: https://x.com/XBToshi/status/2116097368705937613?ref_src=twsrc%5Etfw

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

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

EIP-7702, активированный в составе обновления Ethereum Pectra в мае 2025 года, позволяет аккаунту, принадлежащему пользователю (EOA), делегировать исполнение коду смарт-контракта. Авторизация включает идентификатор цепочки (chain ID), адрес делегата, nonce и подпись. Ethereum проверяет подпись до применения делегирования.

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

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

Документация Ethereum предупреждает о рисках делегирования

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

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

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

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

Первоисточник: https://www.cryptoninjas.net/news/hoskinson-flags-dangerous-eip-7702-code-after-binances-6-3b-crypto-breach/