Исследователи Ethereum сообщили о медианном времени распространения менее одной секунды для смоделированной полезной нагрузки исполнения размером 1 МиБ с использованием дизайна сегментированного вещания EIP-8411, по сравнению с примерно пятью секундами при отправке полезной нагрузки одним сообщением.
Краткое изложение
- Тесты сократили медианное время распространения полезной нагрузки размером 1 МиБ с пяти секунд до менее одной секунды.
- EIP-8411 разбивает полезные нагрузки исполнения на фрагменты, которые узлы могут проверять и пересылать до полного завершения.
- Корень Меркла в заявке на исполнение позволяет узлам независимо проверять каждый полученный сегмент полезной нагрузки.
- В прототипных тестах использовались 500 смоделированных узлов, пропускная способность домашнего билдера, географическая задержка и десять рандомизированных сетевых сидов.
- Разработчики Ethereum обсудят EIP-8411 для включения в Hegotá на ACDC 17 сентября 2026 года сегодня.
Ethereum Research опубликовал последние результаты тестирования 17 сентября, подробно описав прототип, который разбивает полезные нагрузки исполнения на более мелкие части, чтобы узлы могли проверять и пересылать каждый сегмент до получения полной полезной нагрузки. Эти выводы получены из симуляций и прототипного клиентского кода, а не из измерений основной сети Ethereum.
Предложение остаётся черновиком сетевого EIP в репозитории EIP Ethereum. Его текущий дизайн заменяет единый gossip-топик execution_payload, введённый через EIP-7732, на топик execution_payload_chunks и фиксирует части через корень Меркла, включённый в заявку на исполнение билдера.
Ethereum EIP-8411 устраняет ожидание полной полезной нагрузки
Существующая модель gossip в Ethereum может требовать от узла получения и проверки большого сообщения перед его пересылкой пирам. Исследователи, стоящие за EIP-8411, описывают возникающую задержку как проблему «сохранить и переслать», поскольку полная полезная нагрузка должна пройти один сетевой переход, прежде чем начнётся следующий.
При сегментированном распространении билдер делит полезную нагрузку на фиксированные части. Каждый сегмент несёт доказательство включения Меркла, привязанное к корню, зафиксированному в заявке на исполнение. Принимающий узел может проверить один сегмент и начать отправлять его дальше, пока остальные части ещё прибывают.
Более того, обсуждение EIP на Ethereum Magicians описывает планируемое изменение как замену единого сообщения полезной нагрузки EIP-7732 на независимо проверяемые фрагменты. Черновик в настоящее время предлагает 64 фрагмента и структуру доказательства Меркла, которая привязывает каждую часть к исходному обязательству полезной нагрузки. Исследователи заявили, что обязательство Меркла представляет собой основное дополнение на уровне консенсуса, необходимое для базовой сегментации. Последний исследовательский прототип сохраняет существующий формат передачи gossipsub, построение сетевого меша, степень пиров и систему оценки без изменений, меняя лишь способ публикации и пересылки частей полезной нагрузки.
Документация Ethereum в настоящее время описывает полезные нагрузки исполнения как данные, связанные с транзакциями и состоянием, генерируемые клиентом исполнения и передаваемые через процесс консенсуса. Валидаторы получают предложенные блоки через сеть gossip консенсуса, прежде чем отправить данные исполнения своим клиентам исполнения для валидации.
Симуляция сокращает медиану для 1 МиБ с пяти секунд
Наиболее впечатляющие показатели производительности в отчёте от 17 сентября получены из контролируемой симуляции. Исследователи смоделировали 500 узлов с использованием географической сетевой задержки, пропускной способности на загрузку 50 Мбит/с и на скачивание 100 Мбит/с, с полезной нагрузкой 1 МиБ, исходящей от домашнего билдера, и без высокоскоростных узлов дата-центров.
В этой конфигурации отправка полезной нагрузки одним полным сообщением gossipsub заняла примерно пять секунд, чтобы достичь половины принимающих узлов, и почти шесть секунд на хвосте. Настроенная сегментированная версия достигла медианы около 0,75 секунды и хвоста около одной секунды.
Исследователи подчёркивают, что измерения получены из симуляционной среды, запускающей реальный код Prysm и go-libp2p-pubsub против смоделированной сети и виртуальных часов. Каждое измерение использовало десять рандомизированных сетевых конфигураций. Условия основной сети могут отличаться от смоделированной топологии, пропускной способности и предположений о трафике.
Их базовый дизайн Tier 1 сочетает сегментацию с пакетной публикацией. Используя сегменты по 16 КиБ, отчёт утверждает, что медианное распространение для полезной нагрузки 1 МиБ упало с пяти секунд до менее одной секунды, а хвостовая задержка снизилась с примерно шести секунд до чуть более одной секунды.
Пакетная публикация меняет способ отправки фрагментов источником. Вместо отправки каждой копии одного сегмента перед началом следующего, построитель заранее распределяет различные фрагменты между разными пирами, позволяя нескольким секциям полезной нагрузки начать движение по сети одновременно. Исследователи заявили, что Tier 1 требовал примерно на треть больше полученных байтов, чем сегодняшний подход с передачей всего сообщения целиком. Компромисс возникает из-за отправки множества независимо идентифицированных фрагментов и дополнительных управляющих сообщений, необходимых для их анонсирования.
Более продвинутые уровни сокращают дублирующий сетевой трафик
Второй предложенный уровень решает проблему дублирования данных. Вместо отправки каждого сегмента всем подходящим пирам в mesh-сети, узлы могут отправлять фрагменты ограниченной группе, анонсируя доступность остальным. Пиры запрашивают отсутствующие сегменты только при необходимости.
Прототип сочетает эту систему с тем, что его авторы называют дисциплинированными запросами. Узел изначально запрашивает сегмент у одного пира, ждёт определённый тайм-аут и переключается на другой источник, если первый пир не смог доставить данные.
При размере полезной нагрузки в 1 МиБ, согласно исследованию, дисциплинированные запросы сократили полученный трафик примерно до 1,5 копий полезной нагрузки на узел по сравнению со значительно большим дублирующим трафиком в менее контролируемых вариантах. Исследователи обнаружили, что сокращение дубликатов становилось всё более полезным, когда доступная пропускная способность для загрузки была ограничена.
Этот подход создаёт ещё один компромисс. Вредоносный или перегруженный пир может анонсировать сегмент, а затем отказаться его предоставить. Исследователи протестировали сценарий удержания, в котором некоторые узлы объявляли о сегментах, но не отвечали на запросы. При более высоких уровнях удержания настроенная конструкция на основе запросов демонстрировала растущую хвостовую задержку. Авторы протестировали более короткие тайм-ауты и несколько возможных источников запросов как методы ограничения этой уязвимости.
Их третий уровень добавляет помехоустойчивое кодирование Рида-Соломона. Полезная нагрузка сжимается, кодируется с добавлением дополнительных чётностных фрагментов и делится на сегменты. Узлы могут восстановить полезную нагрузку после сбора достаточного количества фрагментов, не дожидаясь каждого исходного сегмента.
Исследователи заявили, что кодированная модель имела самую низкую хвостовую задержку в их тестах и оставалась работоспособной, когда некоторые сегменты удерживались. Ценой была более высокая пропускная способность на источнике публикации, поскольку чётностные данные увеличивают объём отправляемого.
EIP-8411 теперь ожидает обсуждения включения в Hegotá
EIP-8411 в настоящее время не является активированной функцией Ethereum. Предложение на GitHub было открыто 4 сентября и по-прежнему помечено как черновик сетевого EIP, ожидающий рассмотрения. Предложение требует EIP-7732 — закреплённого в Ethereum дизайна разделения предлагающего и построителя.
Разработчики Ethereum запросили для EIP-8411 статус PFI, или Proposed for Inclusion (Предложено для включения), для Hegotá — сетевого обновления, ожидаемого после Glamsterdam. Во время обсуждения исполнения на звонке всех основных разработчиков 10 сентября разработчики заявили, что предложение должно быть рассмотрено на звонке разработчиков консенсусного уровня, поскольку изменение в первую очередь затрагивает консенсусную сеть.
Запрос поступил после обычного крайнего срока PFI для Hegotá. Его сторонники предложили EIP-8411 в качестве замены EIP-8142, который исследовал размещение блоков в blob-данных, но вызвал опасения по поводу KZG-доказательств на стороне построителя и повторного использования подсетей доступности данных.
Повестка ACDC #187 назначает обсуждение PFI для EIP-8411 на 17 сентября в 14:00 UTC. На момент этого отчёта звонок ещё не состоялся, поэтому никакого решения о включении EIP-8411 в Hegotá зафиксировано не было.
Разработчики сужали набор функций Hegotá в области абстракции аккаунтов, масштабирования, устойчивости к цензуре и другой протокольной работы. EIP-8411 вошёл в этот процесс позже многих предложений и всё ещё нуждается в решении основных разработчиков о включении.
Сетевое предложение связано с работой Ethereum по повышению пропускной способности Layer 1. Более высокие лимиты газа могут приводить к большим полезным нагрузкам исполнения, увеличивая объём данных, которые валидаторы должны получить в фиксированные консенсусные сроки. Лимит газа Ethereum достиг 60 миллионов в конце 2025 года после того, как валидаторы сигнализировали о поддержке увеличения.
Виталик Бутерин описал более высокую пропускную способность Layer 1, PeerDAS и будущую работу над ZK-EVM как части плана масштабирования Ethereum. Более быстрая доставка полезной нагрузки исследуется наряду с этими изменениями, поскольку более крупные сетевые сообщения оказывают большее давление на пропускную способность узлов и сроки распространения.
Прототип кода доступен, но остаётся экспериментальным
Исследователи опубликовали прототипы реализаций для Prysm и go-libp2p-pubsub. Рекомендуемая ветка variant-a Prysm содержит ряд изменений за флагом –enable-segmented-payload-gossip, а сопровождающая ветка libp2p реализует политики пересылки и запросов, использованные в исследовании.
Авторы явно описывают свою исследовательскую ветку как «испытательный стенд, а не предложение». Некоторые функции, измеренные в статье, включая расширенные конфигурации помехоустойчивого кодирования, остаются экспериментальными компонентами тестовой среды и не обязательно являются частью минимальной спецификации EIP-8411.
Открытые вопросы, выявленные исследователями, включают увеличение трафика управляющих сообщений, затраты CPU на обработку множества меньших сообщений, альтернативные отображения сегментов, управление очередями, настройку таймеров и вопрос о том, может ли более новый сетевой стек, ориентированный на QUIC, дать другие результаты.
Авторы планируют дальнейшие сравнения между однотемным дизайном, используемым в варианте A, подходами с частичными сообщениями и моделями, которые назначают отдельные gossip-темы для отдельных сегментов. Текущий прототип сохраняет фрагменты размером 16 КиБ в качестве рекомендуемой базовой конфигурации после того, как симуляции показали, что меньшие фрагменты размером 8 КиБ не дали дальнейшего снижения задержки, но увеличили управляющий трафик.
