Дослідники Ethereum повідомили про медіанну затримку поширення менше однієї секунди для симульованого корисного навантаження виконання об'ємом 1 МіБ, використовуючи сегментований дизайн розсилки EIP-8411, порівняно з приблизно п'ятьма секундами при відправці корисного навантаження як єдиного повідомлення.
Ethereum Research опублікувала останні результати тестування 17 вересня, деталізуючи прототип, який розбиває корисні навантаження виконання на менші частини, щоб вузли могли перевіряти та пересилати кожен сегмент до отримання повного корисного навантаження. Висновки походять із симуляцій та прототипного клієнтського коду, а не з вимірювань основної мережі Ethereum.
Пропозиція залишається чорновим мережевим EIP у репозиторії Ethereum EIPs. Його поточний дизайн замінює єдину тему розповсюдження execution_payload, введену через EIP-7732, на тему execution_payload_chunks та фіксує частини через корінь Меркла, включений у ставку виконання розробника.
Існуюча модель розповсюдження Ethereum може вимагати від вузла отримання та перевірки великого повідомлення перед його пересиланням до однорангових вузлів. Дослідники, що стоять за EIP-8411, описують затримку, що виникає, як проблему "зберігай-і-пересилай", оскільки повне корисне навантаження повинно перетнути один мережевий вузол, перш ніж почати наступний.
Завдяки сегментованому розповсюдженню, розробник ділить корисне навантаження на фіксовані частини. Кожен сегмент містить доказ включення Меркла, прив'язаний до кореня, зафіксованого у ставці виконання. Вузол-отримувач може перевірити один сегмент і почати надсилати його далі, поки решта частин ще надходить.
Більше того, обговорення EIP на Ethereum Magicians описує заплановану зміну як заміну одного повідомлення EIP-7732 на незалежно перевірені фрагменти. Поточний проєкт пропонує 64 фрагменти та структуру доказу Меркла, яка пов'язує кожну частину з оригінальним зобов'язанням корисного навантаження. Дослідники заявили, що зобов'язання Меркла є головним додатком на рівні консенсусу, необхідним для базової сегментації. Останній дослідницький прототип зберігає існуючий формат gossipsub, побудову мережевої сітки, ступінь однорангових вузлів та систему оцінки недоторканими, змінюючи спосіб публікації та пересилання частин корисного навантаження.
Документація Ethereum наразі описує корисні навантаження виконання як дані, пов'язані з транзакціями та станом, що генеруються клієнтом виконання та переносяться через процес консенсусу. Валідатори отримують запропоновані блоки через мережу розповсюдження консенсусу, перш ніж надсилати дані виконання своїм клієнтам виконання для валідації.
Найкращі показники продуктивності у звіті від 17 вересня походять із контрольованої симуляції. Дослідники змоделювали 500 вузлів, використовуючи географічну мережеву затримку, пропускну здатність завантаження 50 Мбіт/с та пропускну здатність завантаження 100 Мбіт/с, з корисним навантаженням 1 МіБ, що походить від домашнього розробника, та без вузлів дата-центрів з високою пропускною здатністю.
За такого налаштування відправка корисного навантаження як одного повного повідомлення gossipsub зайняла приблизно п'ять секунд, щоб досягти половини вузлів-одержувачів, і близько шести секунд у "хвості". Налаштована сегментована версія досягла медіани близько 0.75 секунди та "хвоста" близько однієї секунди.
Дослідники наголошують, що вимірювання походять від тестового стенду, що запускає реальний код Prysm та go-libp2p-pubsub проти симульованої мережі та віртуального годинника. Кожне вимірювання використовувало десять випадкових мережевих конфігурацій. Умови основної мережі можуть відрізнятися від змодельованої топології, пропускної здатності та припущень щодо трафіку.
Їхній базовий дизайн Рівня 1 поєднує сегментацію з пакетною публікацією. Використовуючи сегменти розміром 16 КіБ, звіт стверджує, що медіанна затримка поширення для корисного навантаження 1 МіБ зменшилася з п'яти секунд до менше однієї секунди, тоді як "хвостова" затримка знизилася з приблизно шести секунд до трохи більше однієї секунди.
Пакетна публікація змінює спосіб відправлення частин джерелом. Замість того, щоб відправляти кожну копію одного сегмента перед початком наступного, розробник розподіляє різні частини різним одноранговим вузлам на ранній стадії, дозволяючи кільком секціям корисного навантаження одночасно рухатися мережею. Дослідники зазначили, що Рівень 1 вимагає приблизно на третину більше отриманих байтів, ніж сучасний підхід з цілим повідомленням. Компроміс полягає у відправці багатьох незалежно ідентифікованих частин та додаткових керуючих повідомлень, необхідних для їхнього оголошення.
Другий запропонований рівень вирішує проблему дублювання даних. Замість того, щоб надсилати кожен сегмент усім відповідним одноранговим вузлам сітки, вузли можуть надсилати частини обмеженій групі, оголошуючи про доступність іншим. Однорангові вузли запитують відсутні сегменти лише за потреби.
Прототип поєднує цю систему з тим, що її автори називають дисциплінованими запитами. Вузол спочатку запитує сегмент у одного однорангового вузла, чекає визначений час і переходить до іншого джерела, якщо перший одноранговий вузол не доставляє його.
При розмірі корисного навантаження 1 МіБ дослідження показує, що дисципліновані запити зменшили отриманий трафік до приблизно 1.5 копій корисного навантаження на вузол, порівняно зі значно більшим дублюванням трафіку в менш контрольованих варіантах. Дослідники виявили, що зменшення дублювання стає все більш корисним, коли доступна пропускна здатність завантаження обмежена.
Цей підхід створює інший компроміс. Зловмисний або перевантажений одноранговий вузол може оголосити сегмент, а потім відмовитися його надати. Дослідники протестували сценарій утримання, коли деякі вузли рекламували сегменти, але не відповідали на запити. При вищих рівнях утримання налаштований дизайн на основі запитів показав зростання "хвостової" затримки. Автори протестували коротші тайм-аути та кілька можливих джерел запитів як методи обмеження цього ризику.
Їхній третій рівень додає кодування з виправленням помилок Ріда-Соломона. Корисне навантаження стискається, кодується додатковими паритетними частинами та ділиться на сегменти. Вузли можуть реконструювати корисне навантаження після збору достатньої кількості частин, не чекаючи кожного оригінального сегмента.
Дослідники заявили, що кодована модель мала найнижчу "хвостову" затримку в їхніх тестах і залишалася функціональною, коли деякі сегменти були утримані. Вартістю була вища пропускна здатність на джерелі публікації, оскільки паритетні дані збільшують обсяг надсиланого.
EIP-8411 наразі не є активованою функцією Ethereum. Пропозиція на GitHub була відкрита 4 вересня і залишається позначеною як черновий мережевий EIP, що очікує перегляду. Пропозиція вимагає EIP-7732, вбудованого дизайну розділення пропозиціонера-розробника Ethereum.
Розробники Ethereum запросили, щоб EIP-8411 отримав статус PFI (Proposed for Inclusion, Запропоновано до включення) для Hegotá, оновлення мережі, що очікується після Glamsterdam. Під час обговорення All Core Developers Execution 10 вересня розробники заявили, що пропозиція повинна бути розглянута на нараді розробників рівня консенсусу, оскільки зміна в першу чергу впливає на мережу консенсусу.
Запит надійшов після звичайного терміну подачі PFI для Hegotá. Його прихильники запропонували EIP-8411 як заміну EIP-8142, який досліджував розміщення блоків у "блобах", але викликав занепокоєння щодо KZG-доказів на стороні розробника та повторного використання підмереж доступності даних.
Порядок денний ACDC #187 планує обговорення PFI для EIP-8411 на 17 вересня о 14:00 UTC. На момент складання цього звіту дзвінок ще не відбувся, тому рішення про включення EIP-8411 до Hegotá не було зафіксовано.
Розробники звужували набір функцій Hegotá, охоплюючи абстракцію облікових записів, масштабування, стійкість до цензури та інші роботи над протоколом. EIP-8411 увійшов у цей процес пізніше, ніж багато пропозицій, і все ще потребує рішення щодо включення від основних розробників.
Мережева пропозиція пов'язана з роботою Ethereum над збільшенням пропускної здатності Рівня 1. Більші ліміти газу можуть призвести до більших корисних навантажень виконання, збільшуючи обсяг даних, які валідатори повинні отримати в межах фіксованих термінів консенсусу. Ліміт газу Ethereum досяг 60 мільйонів наприкінці 2025 року після того, як валідатори сигналізували про підтримку збільшення.
Віталік Бутерін описав вищу пропускну здатність Рівня 1, PeerDAS та майбутню роботу ZK-EVM як частини плану масштабування Ethereum. Швидша доставка корисного навантаження досліджується поряд з цими змінами, оскільки більші мережеві повідомлення створюють більший тиск на пропускну здатність вузлів та терміни розповсюдження.
Дослідники опублікували прототипні реалізації для Prysm та go-libp2p-pubsub. Рекомендований варіант — гілка Prysm, що містить низку змін за прапорцем --enable-segmented-payload-gossip, тоді як супутня гілка libp2p реалізує політики пересилання та запитів, що використовувалися в дослідженні.
Автори чітко описують свою дослідницьку гілку як "стенд, а не пропозицію". Деякі функції, виміряні в статті, включаючи розширені конфігурації кодування з виправленням помилок, залишаються експериментальними компонентами тестового середовища і не обов'язково є частиною мінімальної специфікації EIP-8411.
Відкриті питання, визначені дослідниками, включають збільшення трафіку керуючих повідомлень, витрати процесора на обробку багатьох менших повідомлень, альтернативні зіставлення сегментів, управління чергами, налаштування таймерів та питання, чи може новіший мережевий стек, орієнтований на QUIC, дати інші результати.
Автори планують подальші порівняння між однотопіковим дизайном, що використовується варіантом A, підходами з частковими повідомленнями та моделями, які призначають окремі теми gossip для індивідуальних сегментів. Поточний прототип зберігає частини розміром 16 КіБ як рекомендовану базову лінію після того, як симуляції показали, що менші частини розміром 8 КіБ не дають подальших приростів затримки, одночасно збільшуючи трафік управління.
ETH
