Ethereum Foundation назначила запуск обновления Glamsterdam в тестовой сети Hoodi на 26 октября 2026 года, 17:42:48 UTC. Обновление активируется на эпохе 132 352 и слоте 4 235 264. Ранее Glamsterdam уже активировался в Sepolia 6 октября. Дата для основной сети пока не назначена. Это важное уточнение: новость касается очередного шага проверки, а не уже состоявшегося изменения Ethereum mainnet.
Glamsterdam объединяет изменения Amsterdam на уровне исполнения и Gloas на уровне консенсуса. В списке ключевых направлений – встроенное разделение proposer-builder, блочные списки доступа и корректировка газовой модели. Для операторов узлов это повод проверить совместимость клиентов до активации. Для приложений – проверить предположения о расходе газа и порядке доступа к состоянию. Разберём, что подтверждено и как читать расписание тестирования.
Что именно объявила Ethereum Foundation
В объявлении от 16 октября фонд указал конкретное время активации Glamsterdam в Hoodi и сообщил, что на той же эпохе лимит газа тестовой сети будет увеличен до 200 миллионов. Релизы совместимых клиентов будут добавляться в таблицы по мере подтверждения. Операторам нужно обновить и execution-клиент, и consensus-клиент до активации. Необновлённый узел рискует продолжить работу по прежним правилам и потерять совместимость с сетью.
Тестнет нужен не просто как демонстрация новых функций. Здесь проверяют взаимодействие клиентских реализаций, стабильность сети, поведение валидаторов и приложений. Sepolia и Hoodi служат более длительными тестовыми сетями, поэтому переход Glamsterdam по ним даёт разработчикам дополнительное окно для тестов до решения по основной сети. В официальном сообщении прямо сказано, что дата mainnet ещё не определена. Следовательно, разработчикам не следует планировать пользовательский релиз на основе календаря тестовой сети.
Важная часть подготовки – проверять не только собственный код, но и инфраструктурную цепочку: версии клиентов, RPC-провайдеров, индексаторов, кошельков и инструментов оценки газа. Если контракт взаимодействует с фиксированным лимитом, нестандартным gas stipend или оценкой «сколько останется после вызова», изменения могут проявить скрытые предположения. В статье об устройстве Ethereum разобраны базовые уровни сети, к которым относятся эти изменения.
Proposer-builder separation и блочные списки доступа
Одно из основных направлений Glamsterdam – enshrined proposer-builder separation, или ePBS. Сейчас создание блока и его предложение могут опираться на внешние механизмы рынка блоков. EIP-7732 переносит разделение ролей в протокол: proposer принимает обязательство builder-а по execution payload, после чего builder раскрывает payload. Правила протокола организуют взаимодействие и оплату, а проверка консенсуса отделяется от проверки исполнения.
Такое разделение должно дать валидаторам больше времени на проверку execution payload. Комитет проверки своевременности payload оценивает, был ли блок раскрыт вовремя и были ли данные blob доступны в срок. Это не означает, что каждый валидатор становится полноценным сборщиком блоков или что MEV исчезает. Меняется протокольный путь создания блока и набор обязанностей участников. Разработчикам инфраструктуры нужно сверить спецификации, клиентские релизы и новые интерфейсы перед обновлением.
Второе ключевое изменение – block-level access lists, связанные с EIP-7928. Они фиксируют аккаунты и ячейки хранения, к которым обращался блок, и изменения состояния после транзакций. Если клиент знает заранее, какие данные нужны, часть чтения состояния и проверки транзакций можно выполнять параллельно. Это создаёт основу для повышения пропускной способности без бесконтрольного роста требований к узлам.
Параллелизация не появляется автоматически для любого кода. Клиенты должны корректно формировать и проверять списки доступа, а разработчикам важно тестировать взаимодействие контрактов и транзакций. Если приложение предполагает конкретное состояние после серии операций, нужно проверять последовательности на обновлённой сети. Для второго уровня Ethereum эти изменения могут косвенно влиять на базовые затраты и взаимодействие с L1; см. разбор blob-комиссий и стоимости rollup.
Пересмотр газа и риски совместимости
Glamsterdam меняет учёт ряда операций, чтобы стоимость газа точнее отражала нагрузку на ресурсы. В сообщении перечислены корректировки цены создания и доступа к состоянию, а также изменения для intrinsic gas транзакций, calldata, access lists и учёта лимита блока. У некоторых контрактов, особенно использующих жёстко заданные газовые ограничения, могут измениться исходы выполнения или расчёт оставшегося газа.
Это не означает, что массово сломаются все контракты. В прежней публикации Foundation говорила, что анализ исторических транзакций выявил небольшое число потенциально затронутых контрактов, и большинству из них достаточно увеличить лимит газа. Но такая оценка не заменяет проверку конкретного приложения. Разработчикам стоит прогнать тесты на Hoodi и актуальных клиентских версиях, проверить газовые оценки, пограничные ветки и внешние вызовы.
Особенно внимательно нужно отнестись к коду, который полагается на фиксированную стоимость операции или передаёт газ с ограниченным stipend. Контракт может формально продолжать исполняться, но перестать проходить под прежним лимитом. Сервисы, которые заранее рассчитывают комиссию или строят пользовательскую транзакцию, также должны обновить параметры. Практический подход – сравнивать трассировки до и после обновления, анализировать тестовые транзакции и не привязываться к одному предположению о цене отдельных операций.
Какова роль Hoodi в расписании
Переход на Hoodi – этап проверки перед будущим решением о основной сети. Он даёт операторам ещё одну возможность подтвердить версии клиентов, проверить синхронизацию, финальность, производство блоков и работу приложений с новой спецификацией. Для валидаторов важна своевременная установка обоих типов клиентов. Для бирж, кошельков и инфраструктурных провайдеров – сверка их процедур обновления и мониторинга.
Увеличение лимита газа Hoodi до 200 миллионов относится к этой тестовой сети и не является обещанием аналогичного лимита в Ethereum mainnet. Разработчики должны отделять параметр тестового окружения от будущей конфигурации основной сети. Также дата тестнета может сместиться, если появятся проблемы с клиентами или обнаружатся несовместимости. Планировать критичные действия, исходя из секунды активации Hoodi, можно лишь для самого тестового окружения.
Набор Glamsterdam включает и другие изменения. В официальном списке названы логи переводов ETH, opcode для номера слота, увеличение максимального размера контракта, детерминированный фабричный контракт и новые инструкции стека; консенсусный слой получит свои изменения структур данных и правил валидаторов. Не все элементы одинаково заметны пользователю, но совокупно они затрагивают клиентские реализации и инструменты разработчиков.
Что стоит сделать сейчас
Оператору узла следует следить за таблицами клиентских релизов Ethereum Foundation, до активации обновить execution и consensus клиенты и проверить процедуру восстановления после сбоя. Команде dApp – развернуть тестовую версию на Hoodi, прогнать критичные транзакционные сценарии и проверить оценку газа. Провайдеру кошелька – убедиться, что библиотека сборки транзакций корректно оценивает комиссии и не вводит пользователей в заблуждение. Простое чтение анонса не заменяет клиентскую документацию и тестирование.
Пользователю, который не управляет инфраструктурой, обычно не нужно предпринимать действие из-за тестнета. Не переводите средства на адреса и не устанавливайте неизвестные «обновления Glamsterdam»: это сетевой апгрейд, а не раздача токенов и не пользовательский airdrop. Для анализа дальнейших изменений можно сравнить это обновление с тем, как rollup используют Ethereum для публикации данных, в материале о подтверждениях и финальности в Ethereum.
Итог
Glamsterdam проходит поэтапное тестирование: Sepolia обновилась 6 октября, а Hoodi назначена на 26 октября 2026 года в 17:42:48 UTC. Основные темы – ePBS, блочные списки доступа и переработка газового учёта. На Hoodi также планируется лимит газа 200 миллионов. Ethereum Foundation пока не назначила активацию для mainnet.
Практический вывод зависит от роли читателя. Валидаторы и разработчики должны готовить совместимые клиенты и тестировать приложения на тестовой сети. Остальным стоит следить за подтверждёнными релизами и не путать тестовые даты с запуском основной сети. Если обновление проходит Hoodi без серьёзных проблем, это станет ещё одним основанием для последующего планирования, но календарь mainnet появится только в отдельном официальном объявлении.
