Это различие важно для горячих кошельков бирж и казначейств проектов, чьи системы контроля исходят из того, что они подписывают только обычные транзакции. Как ранее сообщал The Defiant, со-генеральный директор Binance Ричард Тенг заявил, что злоумышленник при взломе биржи использовал EIP-7702, чтобы получить разрешение на выполнение операций с горячим кошельком. «Это делегирование не прошло через наши обычные процедуры контроля», сказал он.
Ончейн-транзакция, зафиксированная Etherscan, показывает один вызов Binance 14, в результате которого злоумышленнику было переведено около 167464 ETH и 1,615 млрд USDT, а также другие токены.
Переключатель в одну сторону
Черновая спецификация предлагает использовать недопустимую в настоящее время форму транзакции типа 4 из EIP-7702: транзакцию, адресованную самому себе, с нулевой суммой, без данных и с пустыми списками доступа и авторизаций. Она устанавливала бы неисполняемый маркер длиной три байта, предварительно обозначенный как `0xef0200`, не запуская существующий делегированный код.
После установки маркер приводил бы к тому, что будущие авторизации делегирования, включая попытки удалить маркер, игнорировались бы. Аккаунт сохранял бы свой адрес, возможность обычных переводов и вызовов контрактов, а входящие вызовы не исполняли бы никакой код. Предлагаемая фиксированная комиссия составляет 33500 gas; автор говорит, что она не проходила бенчмаркинг.
Защита ограничивается делегированием. Скомпрометированный приватный ключ всё ещё позволил бы переводить средства, выдавать разрешения на использование токенов или подписывать авторизации контрактов. Уже выданные разрешения не отзывались бы. В черновике также предупреждается, что отказ от делегирования может отключить зависящее от него восстановление доступа или сделать недоступными активы, которым нужен код прежнего делегата.
Срок действия устраняет другой риск
Отдельный черновик Джозефа Делонга в PR #12601 требует, чтобы каждая авторизация подписывала ссылку на блок, входящий в число 256 предшествующих блоков-предков блока включения. Это ограничило бы период, в течение которого можно применить неиспользованные авторизации, но не прекращало бы действие уже установленного делегирования.
Другой черновик, EIP-7851, предлагает иной подход: навсегда отключить полномочия исходного ключа подписи на уровне протокола, сохранив за кодом кошелька возможность обновлять делегирование. Новое предложение об отказе от делегирования, напротив, сохраняет обычные полномочия ключа на проведение транзакций и убирает возможность делегирования.
Для новой схемы отказа от делегирования всё ещё требуется доработка совместимости. Формат маркера пока предварительный, а контракты или кошельки, которые распознают обычные аккаунты по отсутствию у них кода, могут отклонять аккаунты с маркером. Кошелькам и аппаратным подписантам также потребуется распознавать новый тип транзакции и показывать, что его действие необратимо.