Разработчики Ethereum перенесли запуск апгрейда Glamsterdam на тестнете Hoodi после того, как исследователи выявили уязвимости в механизме gas, которые могут повлиять на работу существующих смарт-контрактов при обработке неудачных транзакций.
Ethereum Foundation (EF) сообщила, что обновление, изначально запланированное на 26 октября, будет отложено для дополнительного анализа взаимодействия некоторых предложений с развернутыми на Ethereum смарт-контрактами.
13 октября компания по кибербезопасности Blockchain ChainSecurity предупредила, что два предложения в рамках Glamsterdam — EIP-8037 и EIP-8038 — могут ослабить защиту от атаки типа *insufficient gas griefing*.
Отсрочка вызывает неопределенность с графиком выхода апгрейда на мейннет. Разработчики ранее рассматривали начало декабря, предполагая финализацию плана после успешного тестирования на Hoodi.
Изменения в gas могут подорвать защиту существующих смарт-контрактов
В своем анализе ChainSecurity указала, что по новым правилам gas может возвращаться контракту после неудачной операции, позволяя ему продолжить выполнение вместо остановки. Исследователи отметили, что изменения могут нарушить работу существующих проверок безопасности, которые зависят от остатка gas во время транзакции.
В атаках типа *insufficient gas griefing* злоумышленник намеренно предоставляет слишком мало gas для успешного выполнения легитимной операции смарт-контракта. ChainSecurity предупредила, что предложенные изменения в Glamsterdam могут ослабить защиту от таких атак, потенциально позволяя контрактам фиксировать неудачные операции навсегда.
Например, затрагиваемый контракт может аннулить право пользователя на повторную попытку или заблокировать возможность её выполнения, оставляя пользователя без возможности завершить иначе корректную операцию.
ChainSecurity подчеркнула, что Glamsterdam не сделает все проверки безопасности по gas ненадежными. Некоторые меры защиты сохранят свою эффективность, но разработчикам потребуется пересмотреть их с учетом новых правил работы с gas.
Выявленные риски вызвали обеспокоенность среди участников сообщества Ethereum. В комментарии на GitHub от 21 октября анонимный исследователь безопасности pcaversaccio охарактеризовал угрозы как «серьезные» и призвал к пересмотру апгрейда.
В пятницу ChainSecurity сообщила, что выявила «13 реальных примеров» уязвимостей и координирует ответственное раскрытие информации с затрагиваемыми проектами. Компания не раскрыла детали этих примеров или названия проектов, но призвала разработчиков проверить свои контракты как можно скорее.
Предупреждение следует за более ранним заявлением Ethereum Foundation, в котором говорилось, что модель gas в Glamsterdam может нарушить работу кошельков, индексеров и оценщиков gas, полагающихся на фиксированные предположения. Ранее апгрейд был активирован на Sepolia 6 октября, перед запланированным, но теперь отложенным, запуском на Hoodi.
Разработчики Ethereum отложили запуск апгрейда Glamsterdam на тестнете Hoodi из-за выявленных уязвимостей в механизме gas, которые могут нарушить работу смарт-контрактов. Компания ChainSecurity предупредила, что изменения в EIP-8037 и EIP-8038 ослабят защиту от атак *insufficient gas griefing*, позволяя контрактам фиксировать неудачные операции. Отсрочка создает неопределенность с графиком выхода апгрейда на мейннет, ранее планировавшимся на декабрь.
Откладывание Glamsterdam подчеркивает приоритет безопасности в Ethereum, но создает временные риски для разработчиков смарт-контрактов, которым придется адаптировать код под новые правила gas. Инвесторы должны следить за динамикой тестирования и возможными задержками, так как любые изменения в протоколе могут повлиять на децентрализованные приложения (dApps) и инфраструктуру сети. Если проблемы не будут решены вовремя, это может замедлить развитие экосистемы и вызвать недоверие у участников рынка.
Отсрочка — правильное решение, демонстрирующее ответственный подход к безопасности, но задержки в обновлениях Ethereum уже стали привычным явлением. Разработчикам стоит ускорить процесс тестирования и коммуникации с сообществом, чтобы минимизировать негативные последствия для проектов, зависящих от стабильности сети.





