Глэмстердам задерживается: Реформа MEV в Ethereum сталкивается с инженерными реалиями из-за опоздания ePBS
Впервые в ускоренном темпе форков Ethereum на 2026–2027 годы дорожная карта дала сбой. В середине апреля 2026 года основные разработчики публично признали то, о чем команды клиентов шептались неделями: Встроенное разделение предлагающего и строителя (Enshrined Proposer-Builder Separation, ePBS) — самый амбициозный элемент хардфорка Glamsterdam — оказалось «сложнее, чем ожидалось», и первоначальное окно запуска в мейннете в мае-июне почти наверняка недосягаемо. Эта задержка сдвигает Glamsterdam на 3-й или 4-й квартал 2026 года, сокращая разрыв с уже запланированным форком Hegota и вновь поднимая вопрос, который Ethereum считал решенным: может ли базовый слой с пятью клиентами обновляться в темпе, которого требует экономика L2 после Pectra?
Ответ имеет значение далеко за пределами собственной экосистемы Ethereum. Каждая неделя, пока ePBS остается в devnet — это неделя, в течение которой текущая олигополия реле Flashbots продолжает опосредовать ежегодные потоки MEV на десятки миллиардов, неделя, когда L2 продолжают оценивать блобы (blobs) по кривой предложения, которую форк должен был смягчить, и неделя, когда Solana, закрепившая одобрение 98,27 % валидаторов для капитального пересмотра консенсуса Alpenglow в сентябре 2025 года, увеличивает свой отрыв благодаря заметно более быстрому темпу монолитных обновлений. Glamsterdam никогда не был просто очередным хардфорком. Это был ответ Ethereum на тезис о «быстрых L1». И этот ответ теперь запаздывает.
Два EIP, определяющих Glamsterdam
Glamsterdam — это портманто имен Gloas (кодовое название уровня консенсуса) и Amsterdam (кодовое название уровня исполнения, согласно традиции называть их в честь городов-хозяев Devcon). Он опирается на два ключевых EIP, которые вместе должны перестроить процесс производства блоков в Ethereum.
EIP-7732 (ePBS) разделяет блок консенсуса и блок исполнения на уровне протокола. Сегодня валидаторы, использующие MEV-Boost, передают создание блоков рынку внепротокольных строителей через централизованные реле. Миграция самих Flashbots в декабре 2024 года всех строителей и потоков ордеров в BuilderNet сама по себе была признанием того, что архитектура реле создает риск концентрации. ePBS закрепляет это разделение: предлагающие и строители становятся полноправными участниками протокола, которые взаимодействуют напрямую, без участия реле.
EIP-7928 (Списки доступа на уровне блока) заставляет блоки заранее декларировать свой «отпечаток» чтения/записи — задействованные аккаунты и слоты хранения. После этого клиенты могут параллельно выполнять и проверять транзакции, сокращая время распространения блока. В сочетании с ePBS эта пара нацелена на снижение эффективной задержки блока примерно на 50 %.
На бумаге они гармонично дополняют друг друга. На практике же они взаимодействуют со всеми остальными частями стека после Pectra — включая консолидацию валидаторов MaxEB (EIP-7251), уже реализованную в Pectra — так, как изначально не предполагали спецификации.
Что именно пошло не так
Созвон разработчиков уровня консенсуса (ACDC #177) от 16 апреля 2026 года прояснил инженерную реальность. До этого месяца тестирование было разделено на две отдельные сети: epbs-devnet для разделения предлагающих и строителей и bals-devnet для списков доступа. «Обобщенная devnet», объед иняющая их — первая среда, где сосуществуют все компоненты Glamsterdam — получила зеленый свет только после того, как Lighthouse и еще несколько клиентов консенсуса выпустили стабильные сборки во время окна взаимодействия (interop) в апреле.
«ePBS Devnet Zero меньше касается производительности и больше — взаимодействия (interoperation)», — отметил один из инженеров клиентов в резюме созвона. Перевод: мы все еще выясняем, что ломается, когда пять клиентов консенсуса и пять клиентов исполнения независимо интерпретируют спецификацию. Первые запуски выдают в основном пустые блоки — это не структурный недостаток, а сигнал о том, что основной путь еще только прокладывается, не говоря уже о сценариях при атаках.
Последствия для графика накапливаются:
- Devnet Zero должна стабилизироваться для Lighthouse, Prysm, Teku, Nimbus и Lodestar со стороны консенсуса, а также для Geth, Nethermind, Besu, Erigon и Reth со стороны исполнения.
- Devnet One и Two должны выявить ошибки взаимодействия между ePBS, BALs, пересмотром стоимости газа и более чем 25 второстепенными EIP, находящимися на рассмотрении.
- Публичные тестнеты (преемник Holesky, Sepolia) требуют как минимум 6–8 недель активности в теневых форках (shadow-fork), прежде чем можно будет обоснованно назначить дату запуска в мейннете.
- Релизы клиентов должны быть подготовлены, проверены и распределены среди стейкеров с достаточным запасом времени, чтобы проблема выбора форка в мейннете не привела к потере работоспособности сети.
Каждый этап измеряется неделями, а не днями. Запуск в мае-июне требовал стабильности Devnet Zero в феврале. Ее не было. Июнь-июль требовали стабильности в марте. Ее не было. К апрелю математика просто не сходится — отсюда и тихое признание того, что основной форк смещается на вторую половину 2026 года.
Парадокс разнообразия клиентов
Разнообразие пяти клиентов исполнения в Ethereum, пожалуй, является его самым ценным свойством «надежной нейтральности» (credibly-neutral) — баг в одном клиенте не может обрушить всю сеть. Но именно из-за этого разнообразия Glamsterdam дается так трудно.
Каждая команда разработчиков должна независимо создать, протестировать и стабилизировать ePBS. Каждая сталкивается с разными пограничными случаями. В протоколе апрельского созвона ACDC упоминаются «ожидающие пулл-реквесты» в нескольких клиентах и отмечается, что изменения в спецификациях консенсуса могут полностью заблокировать запуск ePBS Devnet Two до их разрешения. Это именно тот «налог на координацию», который не платят сети с одной реализацией.
Сравните с темпом Solana. Alpenglow, замена консенсуса Solana, нацеленная на детерминированную финализацию за 100–150 мс, прошла голосование валидаторов с поддержкой 98,27 % — один из самых сильных мандатов в истории сети — в сентябре 2025 года. План развертывания прост: клиент Agave от Anza выпускает обновление в 3-м квартале 2026 года; Firedancer, вторая реализация от Jump Crypto, следует за ним. Поскольку у Solana фактически был один рабочий клиент до того, как доля Firedancer в основной сети превысила 20 % в начале этого года, ее поле для координации составляет лишь малую часть от поля Ethereum.
Это не просто нейтральное наблюдение. Монолитные блокчейны запускаются быстрее. Многоклиентские сети работают безопаснее. Задержка Glamsterdam — это цена архитектурного выбора Ethereum, и впервые со времен Merge рынок взвешивает, стоит ли эта цена того, чтобы ее платить.
Что задержка означает для L2 и MEV
Форк Pectra был запущен в 2025 году по графику. Вскоре после этого Fusaka добавил PeerDAS и расширил емкость блобов. Команды L2 строили свои планы по масштабированию на 2026 год с расчетом на запуск Glamsterdam во втором квартале, ожидая дальнейшего расширения блобов и перераспределения MEV для удовлетворения растущего спроса на роллапы.
Теперь эти планы необходимо пересмотреть.
Ценообразование блобов. Ожидалось, что Glamsterdam увеличит количество блоб ов на блок — потенциально до 72 и более — что обеспечило бы оптимистичным и ZK-роллапам значительно больше дешевой доступности данных (DA). Перенос на 3–4 кварталы означает еще 2–4 месяца ограниченного предложения блобов, что критически важно для роллапов, которые уже исчерпали свои лимиты комиссий.
Перераспределение MEV. Сегодняшняя архитектура MEV-boost непропорционально вознаграждает крупнейших билдеров. Сверхлинейная доходность от агрегации потока ордеров означает, что как только билдер захватывает лидерство, экономика подталкивает его к монополии. ePBS не устраняет MEV, но убирает реле как узкое место координации — что, в теории, должно перераспределить часть текущей прибыли обратно пропозерам и, далее по цепочке, стейкерам. Каждый месяц задержки — это месяц сохранения существующей динамики MEV.
Конкуренция L2. Base уже достиг времени блока в 2 секунды. Arbitrum и Optimism внедряют собственные улучшения сиквенсоров и DA в своем темпе. Чем дольше сохраняется «бутылочное горлышко» на L1, тем сильнее дорожные карты L2 расходятся с любым единым обновлением L1 — и тем больше «rollup-centric roadmap» превращается в N отдельных дорожных карт роллапов, которые просто рассчитываются на одном и том же базовом уровне.
Вопрос FOCIL и давление со стороны Hegota
Одним из самых значимых решений апрельского созвона ACDC стал перенос списков включения на основе выбора форка (FOCIL) из Glamsterdam в Hegota, где он был официально выбран в качестве главного обновления уровня консенсуса на конец 2026 года.
FOCIL — это ответ Ethereum на проблему цензуроустойчивости — механизм, позволяющий комитету пропозеров коллективно обеспечивать включение транзакций, чтобы ни один билдер не мог систематически исключать полезную нагрузку (например, адреса под санкциями OFAC). Инженерная команда Base публично предупреждала, что объединение FOCIL с ePBS отодвинет Glamsterdam за пределы 2026 года. Исключение этого компонента дает пер едышку графику Glamsterdam — ценой сокращения окна между активацией Glamsterdam в мейннете и Hegota.
Если Glamsterdam выйдет в 4 квартале 2026 года, а Hegota — в конце того же квартала, разрыв может составить всего 6–8 недель. Это слишком короткий срок для валидаторов, билдеров блоков, провайдеров стейкинга и команд L2, чтобы освоить одно изменение протокола до появления следующего. Дорожная карта Hegota также включает значительную работу по борьбе с разрастанием стейта — ранние обсуждения были сосредоточены на деревьях Веркла (Verkle Trees), которые снизят требования к оборудованию узлов, но потребуют обширного тестирования.
Сценарий, к которому Ethereum сейчас тихо готовится: два крупных форка запускаются в течение одного квартала — при матрице тестирования, которую Solana выпускает в одном скоординированном релизе.