Ethereum отложил Glamsterdam из-за рисков с газом в контрактах

Апгрейд Ethereum Glamsterdam поставлен на паузу. Разработчики проверяют, не изменят ли новые правила расчёта газа поведение смарт-контрактов, кошельков и релееров, код которых после форка не менялся.

6 ноября разработчик Ethereum Foundation Мариус ван дер Вейден сообщил: форк тестовой сети Hoodi не состоится, пока не устранят проблемы, которые нашла аудиторская компания ChainSecurity. Он попросил разработчиков контрактов и аудиторов сверить свои проекты с восемью инвариантами газа, которые нарушает апгрейд.

Инвариант — это правило, которое код считает неизменно верным: например, что фиксированного лимита газа хватит для вызова или что заминенная делегация уже вступила в силу. В репозитории Ethereum Foundation перечислены восемь таких правил, которые меняются с Glamsterdam, и указано, что большинство найденных проблем связаны с двумя из них.

За изменениями стоят два предложения. EIP-8037 поднимает цену создания нового состояния — новых аккаунтов, слотов хранения и развёрнутого кода — и считает её отдельно от обычного выполнения. EIP-8038 повышает цену чтения и обновления уже существующего состояния. Согласно спецификации, на которой тестируется репозиторий, запись в новый слот хранения подорожает с 22 100 до 110 020 газа, обновление уже занятого слота — с 2900 до 10 100, а развёртывание кода — с 200 до 1530 газа за байт.

Отдельная проблема — механизм EIP-7702: он позволяет обычному аккаунту выполнять код смарт-контракта через подписанную авторизацию на делегат-контракт. До Glamsterdam полная стоимость такой операции списывалась заранее, поэтому неудачная транзакция просто не попадала в блок. После апгрейда делегирование с пустого аккаунта обойдётся в 235 606 газа вместо прежних 25 000. Транзакция со старым лимитом газа может быть замайнена, но завершиться с ошибкой — при этом подписанная авторизация останется публичной и действительной, а значит, ей смогут воспользоваться злоумышленники.

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