Исследователи Ethereum сообщили, что дизайн сегментированной рассылки в рамках чернового предложения EIP-8411 сократил смоделированное медианное время распространения execution payload объемом 1 МиБ примерно с пяти секунд до 0,75 секунды, согласно публикации на Ethereum Research.

Скорость распространения имеет особое значение в сети с доказательством доли, где у валидаторов есть ограниченное окно на получение и проверку каждого нового блока до аттестации.

В тесте моделировались 500 узлов с географической задержкой, скоростью отдачи 50 Мбит/с и загрузки 100 Мбит/с. Payload отправлялся с домашнего builder-узла, а не из высокоскоростного узла дата-центра — такой выбор позволял проверить, как дизайн работает без инфраструктуры дата-центров на передающей стороне. Исследователи запускали реальный код Prysm и go-libp2p-pubsub на симулированной сети с виртуальными часами, повторяя каждое измерение на 10 рандомизированных конфигурациях, чтобы не зависеть от одной удачной топологии.

Когда полный payload отправлялся одним сообщением GossipSub, оно достигало половины сети примерно за пять секунд, а самые медленные узлы получали его почти за шесть секунд. Настроенный сегментированный вариант сократил эти показатели примерно до 0,75 секунды и одной секунды соответственно.

EIP-8411 заменяет ожидание полного payload сегментированной рассылкой

EIP-8411 заменяет единственную тему gossip execution_payload из EIP-7732 на новую тему execution_payload_chunks. Узлам больше не нужно ждать получения всего payload перед его пересылкой. Вместо этого они могут проверять и пересылать независимо аутентифицированные сегменты по мере их поступления, сверяя каждый с корнем Меркла, содержащимся в execution bid билдера.

Предложение было открыто 4 сентября 2026 года и остается неодобренным черновым сетевым EIP. Оно также зависит от EIP-7732 — закрепленного в протоколе Ethereum дизайна разделения proposer-builder, при котором билдеры формируют execution payload и предлагают их пропозерам через execution bid, разделяя блока и его предложение.

Результаты получены в контролируемой симуляции с использованием прототипного клиентского кода, а не из измерений в основной сети Ethereum, поэтому любые выигрыши в реальных условиях еще предстоит подтвердить. Исследователи описали свою ветку как «a harness, not a proposal» (тестовый стенд, а не предложение).

Выводы также были описаны в посте X:

Ethereum researchers just exposed the hidden dependency behind fast block propagation: datacenters. Then they removed them.
1 MiB payload. 500 nodes. Home-grade bandwidth. No high-bandwidth datacenter nodes.
GossipSub: ~5s median
Segmented propagation: ~0.75s
But the more… pic.twitter.com/cytAvwJtwr
— slymnogunc (@slymnogunc) September 17, 2026
https://x.com/slymnogunc/status/2100558704584151054?ref_src=twsrc%5Etfw

Более быстрое распространение оборачивается большей сетевой нагрузкой

Консенсусный слой Ethereum использует GossipSub — gossip-протокол типа «публикация-подписка» — для распространения блоков и других сообщений по одноранговой сети. Текущая gossip-модель может создавать задержку store-and-forward, поскольку узел должен получить и проверить все большое сообщение целиком, прежде чем пересылать его дальше. Базовый дизайн Tier 1 использует сегменты по 16 КиБ вместе с пакетной публикацией. В тестах он сократил медианное время распространения 1 МиБ с пяти секунд до менее чем одной секунды. Хвостовая задержка также снизилась — примерно с шести секунд до чуть более одной.

Компромиссом стало примерно на треть большее количество получаемых байтов по сравнению с текущим подходом с целыми сообщениями. Более продвинутые варианты нацелены непосредственно на накладные расходы от дублирующихся байтов. При одном из подходов, называемом disciplined pulls, узел запрашивает отсутствующий сегмент у одного пира, а при таймауте переходит к другому. Это сократило получаемый трафик примерно до 1,5 копий payload на узел. Однако хвостовая задержка выросла, когда пиры не высылали сегменты, которые рекламировали.

Третий уровень добавляет кодирование стирания Рида—Соломона. Оно показало наименьшую хвостовую задержку в тестах и продолжало работать при удержании сегментов пирами. Ценой стала повышенная потребность в пропускной способности на стороне источника.

Этот компромисс важен для дорожной карты масштабирования Ethereum после Glamsterdam. Более высокие лимиты газа и execution payload, как ожидается, увеличат нагрузку на пропускную способность узлов. Исследователи также обозначили открытые вопросы: трафик управляющих сообщений, нагрузку на CPU при обработке множества мелких сообщений, управление очередями, настройку таймеров и координацию между клиентами.

ACDC рассматривает EIP-8411 для Hegotá

В экосистеме Ethereum также обсуждалось возможное включение предложения в Hegotá — обновление сети, ожидаемое после Glamsterdam. В посте X Барнабе Моно написал:

After a month of community outreach, @ethlabs_org is shipping a major piece on a faster Ethereum with faster L1 blocks, collecting perspectives from all corners of the ecosystem. Ethereum core developers are in the final stretches of deciding what to include in Hegotá, the…
— Barnabé Monnot | barnabé.eth (@barnabemonnot) September 17, 2026
https://x.com/barnabemonnot/status/2100575903461839032?ref_src=twsrc%5Etfw

Разработчики Ethereum запросили статус Proposed for Inclusion для EIP-8411 в Hegotá после истечения обычного дедлайна Hegotá PFI. Proposed for Inclusion (PFI) — это статус, помающий EIP как кандидата на включение в конкретное обновление сети. Повестка ACDC #187 предусматривала обсуждение PFI 17 сентября в 14:00 UTC, однако на момент основного отчета звонок еще не состоялся и решения о включении зафиксировано не было.

Прототипные реализации для Prysm и go-libp2p-pubsub уже опубликованы, однако исследователи предупреждают, что продвинутые конфигурации кодирования стирания остаются экспериментальными функциями тестовой среды, а не подтвержденными компонентами минимальной спецификации EIP-8411. Станет ли EIP-8411 частью инфраструктуры масштабирования Ethereum, зависит от будущего решения core-разработчиков.