Коротко: 6 ноября Ethereum Foundation сообщила, что найденные во время подготовки Glamsterdam риски требуют дополнительной проверки контрактов. Разработчикам предлагают проверить зависимость кода от старых правил учёта gas; следующий форк тестнета Hoodi отложен до решения проблем.
Что именно произошло с Glamsterdam
Glamsterdam – следующее крупное обновление Ethereum, которое проходит тестирование до запуска в основной сети. 6 ноября Ethereum Foundation опубликовала запрос к разработчикам и аудиторам: несколько проектов могут работать неверно после изменения правил исполнения, потому что полагаются на инварианты, которые изменятся вместе с EIP-8037 и EIP-8038. В ответ All Core Developers решили не проводить следующий этап форка на Hoodi, пока команда не поймёт масштаб проблем и не согласует возможные изменения спецификаций.
Это продолжение более раннего переноса теста Hoodi, а не сообщение об откате уже активированного обновления. Изменения не были активированы в основной сети Ethereum. Foundation просит команды проверять собственный код и присылать результаты, поэтому даты следующей попытки тестирования пока не следует считать установленными. Августовская заметка о первом переносе Glamsterdam на Hoodi описывала прежнее состояние расписания; сообщение от 6 ноября добавляет конкретный новый раунд проверки рисков.
Почему EIP-8037 и EIP-8038 влияют на приложения
EIP-8037 предлагает отдельно учитывать создание постоянного состояния сети. Например, добавление нового storage-слота, аккаунта или кода контракта получает отдельную компоненту state gas. EIP-8038 меняет стоимость операций, которые читают и записывают существующее состояние. В сумме это перестраивает не только цену отдельных операций, но и то, как остаток газа распределяется между самой транзакцией и обработкой результата.
Для обычного пользователя газ по-прежнему выглядит как лимит исполнения и итоговая комиссия. Но контракт может читать остаток через gasleft(), передавать ограниченный бюджет внешнему вызову, а затем решать, можно ли продолжить. При изменении модели прежняя проверка может означать не то, что ожидал автор. В некоторых случаях контракт после неудачного вызова способен записать ошибку и продолжить путь, который раньше завершался откатом. В других случаях новая цена чтения или записи может привести к нехватке газа там, где прежняя оценка проходила.
Тема связана не с тем, что любой контракт внезапно стал уязвимым. Риск сосредоточен вокруг конкретных предположений: фиксированных бюджетов, проверок нехватки газа, компенсации после неудачного вызова, многошаговых операций и обработки новых storage-слотов. Тем, кто сравнивает параметры и лимиты EVM, поможет материал о разнице между gas limit и gas price. Он объясняет пользовательский уровень комиссий, тогда как EIP меняют внутренние правила оплаты работы контракта.
Какие предположения стоит проверить
Ethereum Foundation подготовила репозиторий с восемью инвариантами для аудиторов. Среди них – привычное ожидание, что вызов, завершившийся нехваткой газа, обязательно сорвёт всю транзакцию; что газ, потраченный во время вызова, всегда останется потраченным после отката; что фиксированного лимита достаточно для создания записи; и что значение gasleft() только уменьшается. При новой модели эти ожидания не всегда будут верны.
Первый проход можно сделать без изменения контракта. Найдите места, где код передаёт фиксированное количество газа, проверяет остаток до или после внешнего вызова, записывает постоянное состояние после ошибки, оценивает стоимость по разнице двух значений gasleft() или использует создание контракта без проверки результата. Отдельно посмотрите off-chain сервисы: relayer, боты, подписываемые сообщения и оценщики транзакций тоже могут хранить старые предположения.
Затем воспроизведите критические ветки на тестовой конфигурации, соответствующей актуальному Glamsterdam, если используемые инструменты уже поддерживают эту спецификацию. Проверяйте не только успешный сценарий: важны отказ внешнего вызова, нехватка execution gas, создание первого storage-слота и повтор операции после частичной ошибки. Перед тем как опираться на оценку, уточните у команды клиента и инструментов, какую версию правил использует среда. Настройка лимита газа кошельком и оценка контракта описаны в материале о том, почему кошелёк не всегда может оценить gas.
Что это означает для разработчиков и пользователей
Для команд проектов полезно завести список критических транзакций: вывод средств, распределение выплат, ликвидации, мультивызовы, мостовые операции и аварийные процедуры. Сопоставьте их с зависимостями от цены storage и внешних вызовов, затем добавьте тесты на новые значения gas. Там, где операция может не пройти, лучше сохранить возможность повторного запуска и проверяемое состояние, чем безвозвратно помечать задачу выполненной после первого сбоя.
Если транзакция отправлена пользователем, обычные правила nonce и замены ожидающего перевода всё ещё помогают разобраться в очереди, но не подтверждают совместимость приложения с новой спецификацией. Для разового зависшего перевода используйте инструкцию о замене или отмене ожидающей EVM-транзакции, а не меняйте лимиты вслепую.
Для ETH держателей и пользователей основной сети сообщение не вводит новую комиссию, не требует обновить кошелёк и не назначает дату mainnet-форка. Glamsterdam остаётся предметом тестирования и аудита. Следующий ориентир – решения разработчиков протокола и обновлённая спецификация. До неё корректнее говорить о потенциальной несовместимости отдельных предположений, а не о массовом отказе контрактов.
Итог
Пауза вокруг Glamsterdam показывает, зачем изменения EVM проверяют на тестнетах до основной сети. EIP-8037 и EIP-8038 затрагивают способ оценки создания и доступа к состоянию, а значит могут изменить поведение редких веток старых контрактов. Разработчикам стоит проверить восемь опубликованных инвариантов, особенно обработку неудачных вызовов и фиксированных газовых бюджетов. Пользователям пока не нужно менять привычный процесс: расписание Hoodi обновят отдельно, а решения о запуске mainnet в сообщении не объявлялись.
