Исследователи Ethereum представили результаты симуляции, в которой медианное время распространения полезной нагрузки выполнения размером 1 MiB через EIP-8411 упало ниже одной секунды – против примерно пяти секунд при отправке одним сообщением. Об этом Ethereum Research сообщил 17 сентября.
Нынешняя модель распространения требует, чтобы узел получил и проверил большое сообщение целиком, прежде чем переслать его дальше. Исследователи описывают эту задержку как проблему «хранения и пересылки»: полная полезная нагрузка должна пройти один сетевой хоп, прежде чем начнется следующий. EIP-8411 предлагает делить ее на фиксированные сегменты. Каждый несет доказательство Меркла, привязанное к корню, зафиксированному в заявке билдера. Получив один сегмент, узел может проверить его и начать пересылать, пока остальные еще в пути. Сейчас предложение описывает 64 сегмента.
В симуляции участвовали 500 узлов с географической задержкой, 50 Мбит/с на отдачу и 100 Мбит/с на прием. Полезная нагрузка в 1 MiB отправлялась от домашнего билдера – без высокоскоростных дата-центров. Отправка одним сообщением заняла около пяти секунд до половины узлов и почти шесть секунд по хвосту. Настроенная сегментированная версия показала медиану около 0,75 секунды и хвост около одной секунды. Замеры проводились на симуляторе с реальным кодом Prysm и go-libp2p-pubsub и виртуальными часами; каждая конфигурация проверялась на десяти случайных сетях.
Базовый уровень 1 сочетает сегментацию с пакетной публикацией: билдер рано распределяет разные сегменты по разным узлам-соседям, и несколько частей полезной нагрузки начинают двигаться по сети одновременно. Это примерно на треть увеличивает объем полученных байтов – плата за множественные идентификаторы и служебные сообщения.
Уровень 2 борется с дублированием: вместо рассылки каждого сегмента всем соседям узел отправляет его ограниченной группе, а остальным сообщает о доступности. Прототип добавляет запросы с повторными попытками – узел сначала просит сегмент у одного соседа, ждет таймаут и переключается на другого. При 1 MiB это сократило трафик до примерно 1,5 копии полезной нагрузки на узел. Однако если сосед анонсирует сегмент и не отдает его, хвостовая задержка растет. Уровень 3 добавляет кодирование Рида – Соломона: полезная нагрузка кодируется с избыточными частями, и узел может восстановить данные, не дожидаясь всех сегментов. Это дало наименьшую хвостовую задержку и устойчивость к отказу от выдачи, но повысило нагрузку на источник.
EIP-8411 пока не активирован. Заявка открыта 4 сентября и остается черновиком в репозитории EIPs. Предложение требует EIP-7732 и заменяет его единую тему распространения данных выполнения на темы с сегментами. Разработчики запросили статус «предложено к включению» для обновления Hegotá – обновление, ожидаемое после Glamsterdam. Запрос поступил после обычного дедлайна. На звонке ACDC #187, назначенном на 17 сентября в 14:00 UTC, обсуждение еще не состоялось, и решение о включении в Hegotá не зафиксировано. EIP-8411 также предложен как замена EIP-8142, который рассматривал размещение блоков в больших двоичных объектах, но вызвал вопросы по доказательствам KZG на стороне билдера.