Почему Glamsterdam может оказаться одним из самых важных апгрейдов после Ethereum Merge?
Автор: KarenZ, Foresight News
Апгрейд Ethereum Glamsterdam чаще всего можно ошибочно воспринять как очередную чисто техническую итерацию, направленную лишь на повышение пропускной способности. Точнее так: он меняет порядок формирования блоков, процесс верификации и способы ценообразования ресурсов — в качестве основы для более высокого лимита Gas, большей емкости blob и будущего параллельного выполнения.
По состоянию на 23 июня 2026 года ethereum.org пометил(а) Glamsterdam как апгрейд, запланированный на вторую половину 2026 года. Название Glamsterdam происходит из комбинации апгрейда уровня исполнения Amsterdam и апгрейда уровня консенсуса Gloas. В официальной дорожной карте он стоит после Fusaka в декабре 2025 года и до Hegotá, а также явно перечислены две ключевые функции: разделение предлагающих и билдера внутри протокола — ePBS — и список доступа на уровне блока — BAL.
Кто предлагает — тот и строит: ePBS закрепляет распределение ролей в протоколе
Сегодня блок в Ethereum похож на очень плотную смену в передаче дел: кто-то формирует (предлагает) блок, кто-то готовит содержимое транзакций, и все это еще зависит от инфраструктуры вне протокола, например MEV-Boost и сторонних ретрансляторов (relay).
Эта система работает уже много лет, но она выносит часть доверительных отношений за рамки протокола и заставляет валидаторов в очень коротком временном окне одновременно выполнять задачи консенсуса, выполнения и доступности данных.
Одна из главных перемен в Glamsterdam — это EIP-7732, ePBS (Enshrined Proposer-Builder Separation). Он закрепляет разделение ролей «предлагающий» и «конструктор» прямо в протоколе.
Если совсем просто: предлагающий отвечает за выбор блока консенсуса, а конструктор — за подготовку содержимого транзакций внутри него. Конструктор не может просто пообещать это устно — сначала он должен «подписать гарантийное письмо» в протоколе: четко указать, какой исполняющий блок он передаст, и сколько денег он готов заплатить предлагающему. Затем Payload Timeliness Committee (комитет по своевременности доставки нагрузки, PTC) проверит, доставляет ли он это вовремя.
Ключевой момент этого изменения — не только снижение зависимости от третьих relays, но и получение времени для распространения и верификации блоков.
Сегодня валидаторам нужно обрабатывать одновременно консенсус и выполнение в очень коротком ключевом окне. ePBS разделяет эти две задачи так, чтобы исполняемая нагрузка могла раскрыться и быть проверена чуть позже. По дизайну EIP-7732 окно распространения исполняемой нагрузки — то есть доступное время, за которое данные распространяются в сети и узлы их получают — может быть расширено примерно с 2 секунд до примерно 9 секунд. Когда окно становится длиннее, Ethereum при увеличении емкости блоков гораздо реже будет столкнуться с риском потери голосов или реорганизаций из-за того, что узлам не хватит времени скачать, проверить и проголосовать.
Для обычных пользователей это может быть заметно не напрямую, но для масштабирования Ethereum это критично. Более длинные окна распространения и верификации означают, что сеть сможет безопаснее обрабатывать больший объем нагрузки. CoinDesk в репортаже от 16 июня 2026 года со ссылкой на инженера DevOps Фонда Ethereum Parithosh Jayanthi пишет, что Glamsterdam может стать одним из крупнейших форков после Merge: он изменит многие предположения об Ethereum и подготовит почву для еще более масштабного расширения в будущем.
BAL и переоценка: масштабирование — это не только «дать больше газа», но и управлять базой данных
Еще одно ключевое изменение Glamsterdam — это EIP-7928, Block-Level Access Lists (списки доступа на уровне блока), то есть BAL.
Это можно представить как отдельную «сводку доступа» для каждого блока: какие аккаунты и какие позиции хранения встречаются при выполнении этого блока, во что превращается соответствующее состояние после выполнения — всё это должно быть записано. Тогда узлы при обработке блока не будут полностью полагаться на «слепой ящик»: они смогут заранее знать, какие данные нужно читать и какие вычисления можно продвигать параллельно.
Ранее EIP-2930 уже вводил списки доступа на уровне транзакций, но они были опциональными, и фактическое использование было ограниченным. Изменение в EIP-7928 в том, что access list поднимается до уровня блока: в заголовке блока остается «отпечаток» этой информации (запись хэша), а исполняющая нагрузка хранит полный список. Узлы при выполнении блока сверяют, действительно ли записанные в списке обращения соответствуют реальному процессу исполнения блока; если не совпадает — блок становится недействительным.
Почему это важно? Сегодня при выполнении транзакций в Ethereum многие обращения к данным становятся понятны только когда код реально дойдет до соответствующего шага. Узлы не знают заранее, будут ли набор транзакций читать и изменять одновременно один и тот же аккаунт или storage slot — поэтому трудно с уверенностью параллелить обработку. BAL по сути явно фиксирует траекторию обращений в процессе выполнения блока: клиент может делать параллельное чтение с диска, параллельную верификацию транзакций и параллельный расчет state root; а в некоторых сценариях можно даже неполным образом переисполнять транзакции и при этом корректно обновлять состояние. Это не кнопка, которая напрямую снижает комиссии пользователей, а пространство для инженерной параллелизации в клиентах.
Но логика масштабирования в Glamsterdam — это не только «расширить дорогу». Она еще и сдерживает долгосрочное разрастание базы данных Ethereum. EIP-8037 повышает стоимость создания состояний и вводит стоимость за байт состояния CPSB. Под «состоянием» можно понимать контент базы данных, который Ethereum должен долго хранить, например новые аккаунты, новые контракты и новые storage slots. Выполнение транзакции заканчивается — но состояние остается в общем бухгалтерском учете (ledger), который поддерживают все узлы. Если состояние растет слишком быстро, запуск узлов становится все дороже, а децентрализация — медленно сжимается.
Фоновые цифры, приведенные в EIP-8037, довольно наглядны: по состоянию на январь 2026 года база данных узла Geth, специально предназначенного для state, составляет около 390 GiB; после повышения верхнего лимита Gas в мейннете с 30 млн до 60 млн ежедневный прирост состояния вырос примерно с 105 MiB до 326 MiB — что в пересчете дает годовой рост около 116 GiB. Если экстраполировать пропорционально при лимите в 200 млн Gas, годовой рост состояния может достигнуть примерно 387 GiB и всего менее чем за год перейти порог деградации производительности в 650 GiB.
То есть EIP-8037 пытается разделить «временный расчет» и «постоянную загрузку базы данных» по разной цене. Создание нового состояния будет дороже, потому что это не разовый вычислительный расход для сети, а долговременная нагрузка на хранение.
Vitalik Buterin также упоминал в объяснениях маршрута расширения Glamsterdam, что Glamsterdam отделит стоимость создания состояний от стоимости выполнения и calldata: цель — дать возможность расширять вычислительную (execution) емкость больше, а размер состояний не раздувать с той же скоростью.
Если смотреть в связке, BAL делает параллельную обработку блоков для узлов проще — и решает задачу «ускорения». А переоценка создания состояний увеличивает стоимость операций, которые надолго занимают базу данных — и решает задачу «не раздувать тетрадь до непомерных размеров». Расширение в Glamsterdam — это не просто рост Gas limit, а вопрос более реалистичный: сможет ли Ethereum вместить больше транзакций, одновременно не потеряв контроль над нагрузкой на распространение блоков, верификацию транзакций и хранение состояний.
Список EIP для Glamsterdam обретает форму: что уже зафиксировано и что еще ждет?
По состоянию на 23 июня 2026 года, согласно отслеживаемым материалам по апгрейдам Ethereum на Forkcast, текущие разработчики Ethereum проводят тестирование апгрейда Glamsterdam в окружениях devnets: 3 августа он выйдет в Sepolia, а 16 сентября — на мейннет (конкретные даты релиза могут измениться).
В текущем плане в список Glamsterdam входят 10 EIP:
EIP-7708 (перевод ETH тоже будет вызывать событие лога, чтобы упростить индексацию и отслеживание нативных переводов ETH)
EIP-7732 (ePBS: прописывает в протоколе разделение ролей «предлагающий» и «конструктор», снижая зависимость от relays вне протокола)
EIP-7778 (отмена учета Gas refund в блоках, чтобы расчет Gas для блоков был проще)
EIP-7843 (добавляет опкод SLOTNUM, чтобы контракт мог считывать текущий номер slot)
EIP-7928 (список доступа на уровне блока BAL: фиксирует аккаунты и позиции хранения, к которым обращался блок при выполнении; прокладывает путь к параллельной верификации)
EIP-7954 (повышает верхний предел максимального размера контракта, позволяя более крупный байткод)
EIP-7976 (повышает базовую стоимость calldata floor, корректирует минимальную стоимость calldata)
EIP-7981 (повышает стоимость access list и заново калибрует газовую цену для access list)
EIP-8024 (обратно совместимые опкоды SWAPN, DUPN и EXCHANGE, расширяющие возможности операций со стеком в EVM)
EIP-8037 (повышение стоимости Gas при создании состояний, сдерживание слишком быстрого разрастания базы данных состояний)
Эти EIP в общих чертах можно разделить на три категории: первая — перестройка процессов блока и верификации, с ядром в EIP-7732 и EIP-7928; вторая — корректировки ценообразования ресурсов, включая EIP-7778, EIP-7976, EIP-7981 и EIP-8037; третья — изменения EVM и developer experience, включая EIP-7708, EIP-7843, EIP-7954 и EIP-8024.
Иначе говоря, Glamsterdam — это не просто изменение одного функционального узла: он одновременно апгрейдит распределение ролей при формировании блоков, параллельную верификацию, ценообразование Gas и пригодность EVM к будущим сценариям.
Еще одна группа EIP по-прежнему находится в списке «рассматривается к включению»:
EIP-2780 (разделение intrinsic Gas транзакций по ресурсам)
EIP-7610 (откат при создании контракта для аккаунта хранения, который не пуст)
EIP-7688 (структуры данных консенсуса, ориентированные на будущую совместимость)
EIP-7904 (анализ стоимости Gas; возможно, будет исключен из Glamsterdam)
EIP-7975 (eth/70, частичный список блоков receipt)
EIP-7997 (детерминированные factory-контракты)
EIP-8038 (обновление стоимости Gas для доступа к состояниям)
EIP-8045 (исключает валидаторов, которые уже были наказаны и чьи проверки невалидны, из дальнейшего выдвижения блоков)
EIP-8061 (повышение exit и merge churn)
EIP-8070 (eth/72, Sparse Blobpool)
EIP-8080 (выходы используют consolidation queue)
EIP-8136 (cell-level deltas для широковещательной передачи данных)
EIP-8159 (eth/71, обмен списками доступа на уровне блоков)
EIP-8246 (удаление SELFDESTRUCT burn)
EIP-8282 (Builder Execution Requests: отдельные запросы на регистрацию и выход для билдера ePBS)
Кроме того, Forkcast сейчас также указывает EIP-8254 (ограничение числа deposit requests в каждом block на уровне исполнения — 8192) как «рекомендуется к включению».
Если смотреть с точки зрения стейкеров, особенно стоит обратить внимание на EIP-8061 и EIP-8080, которые включаются в список. Для стейкеров это означает, что ликвидность на выходе может улучшиться. В статье от 5 мая 2026 года Figment пишет, что институциональным стейкерам больше всего нужны ePBS, EIP-8061 и EIP-8080, и оценивает: при предполагаемом объеме стейкинга около 38,9 млн ETH на апрель 2026 года EIP-8061 может поднять лимит exit churn с 256 ETH/epoch примерно до 1187 ETH/epoch, а EIP-8080 позволит обычным выходам использовать свободную емкость объединяющей очереди (consolidation queue). Figment также напоминает, что все цифры до запуска на мейннете следует считать предположительными.
Источник: Figment
Протокол апгрейдят — и состав Фонда тоже меняется
Техническая подготовка Glamsterdam и кадровые изменения в протокольном «протокол-кластере» Фонда Ethereum произошли почти одновременно. В блоге от 11 мая 2026 года Фонд Ethereum отмечает, что Glamsterdam достиг нескольких вех: создан нижний «порог» 200 млн Gas limit floor как доверимая цель после Glamsterdam, ePBS стабильно работает в мультиклиентском Glamsterdam devnet, а EIP-8037 завершен.
В той же статье также объявили передачу руководства Protocol cluster: Will Corcoran, Kev Wedderburn и Fredrik станут новыми координаторами протокольного кластера. Уходят из Фонда Ethereum прежние координаторы Barnabé Monnot и Tim Beiko, а Alex Stokes уходит в отпуск.
Описание распределения обязанностей для трех новых координаторов от Фонда: Will Corcoran обладает опытом координации между командами; Kev Wedderburn возглавляет команду zkEVM; Fredrik возглавляет Protocol Security и проект Trillion Dollar Security.
Эти изменения не ограничились командой протокола. 18 июня 2026 года Hsiao-Wei Wang опубликовал(а) пост, где говорится, что после отпуска он(а) решил(а) уйти с должностей совместного исполнительного директора Фонда Ethereum и члена совета директоров
Бывший стипендиат (research fellow) Фонда Ethereum Dankrad Feist 19 июня 2026 года заявил, что ушедшие из EF — это верующие CROPS (антицензура и антизахват, open source, приватность, безопасность). По его словам, проблема не в стратегии, а в управлении — и что эта волна оттока талантов в целом направлена против Ethereum. А сооснователь Miden Azeem, наоборот, интерпретирует это иначе: EF сложно изменить себя, и после ухода талантов может появиться новая организация, которая сможет лучше исполнять дорожную карту Ethereum; для экосистемы в долгосрочной перспективе это, скорее, чистый плюс.
Мнение инсайдеров из Фонда Ethereum звучит как попытка заранее обозначить границы. Временный совместный исполнительный директор Фонда Ethereum Bastian Aue (Aerugo) ответил, что причины ухода членов Фонда включают стратегические разногласия, соответствие должности, нормальные изменения в организации или личный выбор. EF не будет обсуждать личные кадровые вопросы в соцсетях, но указал, что уходящие должны уходить достойно.
Далее Фонд Ethereum с помощью официальной Twitter-треда дал более точное повествование о том, как организовано развитие: для раскрытия потенциала Ethereum нужен альянс из нескольких организаций. За последний год несколько организаций уже совместно усиливали устойчивость экосистемы и свои возможности. В примерах EF указал: ethlabs, объявленные 23 июня (некоммерческая лаборатория R&D, сосредоточенная на внедрении ETH и следующем этапе развития экосистемы Ethereum), Eth Apps Guild, запущенный в апреле 2026 года (сообщество для продвижения реального принятия нативных приложений Ethereum, особенно с фокусом на развивающиеся рынки), Ethereum Economic Zone (цель — снизить фрагментацию экосистемы за счет синхронной компонуемости и доказательств нулевого знания в реальном времени) и Argot, созданный в 2025 году (самоуправляемое объединение инженеров и исследователей, которое поддерживает инструменты Solidity и open-source компиляции).
Этот официальный тред делает недавние изменения в Фонде Ethereum более понятными: Фонд не просто «выталкивает» людей и проекты наружу и не отказывается от центральной координации — возможно, он разламывает дорожную карту Ethereum так, чтобы ее совместно брали на себя больше организаций.
Кратко
Поэтому Glamsterdam не стоит воспринимать только как набор EIP. Это инженерная перестановка в Ethereum перед более высокой пропускной способностью: кто строит блоки, кто предлагает, кто верифицирует, какие данные нужно хранить долго, какие ресурсы должны стоить дороже — все это вновь вынесли на обсуждение.
Ключевые слова технического маршрута — ePBS, BAL и начало модели multi-dimensional Gas; организационного маршрута — более прагматично: сможет ли Фонд Ethereum сохранять координационную способность и сможет ли новая организация за пределами Фонда превратить эту координацию в устойчивую поставку результатов.
Справка:
https://forkcast.org/upgrade/glamsterdam/
https://ethereum.org/roadmap/glamsterdam/
https://blog.ethereum.org/2026/05/11/protocol-update-may-26
https://x.com/VitalikButerin/status/2027403360484430122