Ethereum EIP-8411: поширення корисного навантаження швидше за секунду

Дослідники Ethereum повідомили про медіанне поширення менш ніж за одну секунду для симульованого виконавчого корисного навантаження розміром 1 MiB із використанням сегментованої схеми мовлення EIP-8411, порівняно з приблизно п'ятьма секундами під час надсилання корисного навантаження як одного повідомлення.

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 MiB з п'яти секунд

Найсильніші показники продуктивності у звіті від 17 вересня походять із контрольованої симуляції. Дослідники змоделювали 500 вузлів, використовуючи географічну мережеву затримку, пропускну здатність на вивантаження 50 Мбіт/с та на завантаження 100 Мбіт/с, з корисним навантаженням 1 MiB, що походить від домашнього будівельника, і без вузлів дата-центрів із високою пропускною здатністю.

За такого налаштування надсилання корисного навантаження як одного повного повідомлення gossipsub займало приблизно п'ять секунд, щоб досягти половини вузлів-отримувачів, і близько шести секунд на хвості. Налаштована сегментована версія досягла медіани близько 0,75 секунди та хвоста близько однієї секунди.

Дослідники наголошують, що вимірювання походять із симуляційного стенда, який запускає справжній код Prysm та go-libp2p-pubsub проти симульованої мережі та віртуального годинника. Кожне вимірювання використовувало десять рандомізованих мережевих конфігурацій. Умови основної мережі можуть відрізнятися від змодельованої топології, пропускної здатності та припущень щодо трафіку.

Їхній базовий дизайн Tier 1 поєднує сегментацію з пакетною публікацією. Використовуючи сегменти по 16 KiB, звіт зазначає, що медіанне поширення корисного навантаження розміром 1 MiB впало з п'яти секунд до менш ніж однієї секунди, тоді як хвостова затримка знизилася з приблизно шести секунд до трохи більше однієї секунди.

Пакетне публікування змінює спосіб, у який джерело надсилає фрагменти. Замість того щоб надсилати кожну копію одного сегмента, перш ніж почати наступний, будівельник заздалегідь розподіляє різні фрагменти між різними пірами, дозволяючи кільком частинам корисного навантаження почати рухатися мережею одночасно. Дослідники заявили, що Tier 1 вимагав приблизно на третину більше отриманих байтів, ніж сучасний підхід із цілим повідомленням. Компроміс походить від надсилання багатьох незалежно ідентифікованих фрагментів і додаткових контрольних повідомлень, необхідних для оголошення про них.

Більш просунуті рівні скорочують дубльований мережевий трафік

Другий запропонований рівень вирішує проблему дубльованих даних. Замість того щоб штовхати кожен сегмент до всіх відповідних пірів сітки, вузли можуть штовхати фрагменти до обмеженої групи, одночасно оголошуючи доступність іншим. Піри запитують відсутні сегменти лише за потреби.

Прототип поєднує цю систему з тим, що його автори називають дисциплінованими витягуваннями. Вузол спочатку запитує сегмент в одного піра, чекає визначений тайм-аут і переходить до іншого джерела, якщо перший пір не доставляє.

При розмірі корисного навантаження 1 MiB дослідження стверджує, що дисципліновані витягування скоротили отриманий трафік приблизно до 1,5 копій корисного навантаження на вузол, порівняно зі значно більшим дубльованим трафіком у менш контрольованих варіантах. Дослідники виявили, що зменшення дублікатів ставало дедалі кориснішим, коли доступна пропускна здатність для завантаження була обмеженою.

Цей підхід створює ще один компроміс. Зловмисний або перевантажений пір міг оголосити сегмент, а потім відмовитися його надати. Дослідники протестували сценарій утримання, у якому деякі вузли оголошували сегменти, але не відповідали на запити. За вищих рівнів утримання налаштований дизайн на основі витягування демонстрував зростання хвостової затримки. Автори протестували коротші тайм-аути та кілька можливих джерел запитів як методи обмеження цієї вразливості.

Їхній третій рівень додає кодування зі стиранням Ріда-Соломона. Корисне навантаження стискається, кодується додатковими парними фрагментами та ділиться на сегменти. Вузли можуть реконструювати корисне навантаження після збору достатньої кількості фрагментів, не чекаючи кожного оригінального сегмента.

Дослідники заявили, що кодована модель мала найнижчу хвостову затримку в їхніх тестах і залишалася функціональною, коли деякі сегменти утримувалися. Ціною була вища пропускна здатність на джерелі публікування, оскільки парні дані збільшують обсяг надісланого.

EIP-8411 тепер стикається з обговоренням включення до Hegotá

EIP-8411 наразі не є активованою функцією Ethereum. Пропозицію на GitHub було відкрито 4 вересня, і вона залишається позначеною як чернетка мережевого EIP, що очікує на розгляд. Пропозиція вимагає EIP-7732, закріпленого в Ethereum дизайну розділення пропозера та будівельника.

Розробники Ethereum попросили, щоб EIP-8411 отримав статус PFI, або «Запропоновано для включення», для Hegotá — оновлення мережі, очікуваного після Glamsterdam. Під час обговорення виконання All Core Developers 10 вересня розробники заявили, що пропозицію слід розглянути на дзвінку розробників рівня консенсусу, оскільки зміна переважно впливає на мережу консенсусу.

Запит надійшов після звичайного дедлайну PFI для Hegotá. Його прихильники запропонували EIP-8411 як заміну EIP-8142, який досліджував розміщення блоків у блобах, але викликав занепокоєння щодо 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. Рекомендована гілка Prysm варіанта A містить низку змін за прапорцем –enable-segmented-payload-gossip, тоді як супровідна гілка libp2p реалізує політики пересилання та запитів, використані в дослідженні.

Автори явно описують свою дослідницьку гілку як «стенд, а не пропозицію». Деякі функції, виміряні в статті, зокрема розширені конфігурації erasure-coding, залишаються експериментальними компонентами тестового середовища і не обов'язково є частиною мінімальної специфікації EIP-8411.

Відкриті питання, визначені дослідниками, включають збільшений трафік контрольних повідомлень, витрати CPU на обробку багатьох менших повідомлень, альтернативні відображення сегментів, управління чергами, налаштування таймерів і те, чи новіший мережевий стек, орієнтований на QUIC, міг би дати інші результати.

Автори планують подальші порівняння між однотемним дизайном, використаним у варіанті A, підходами з частковими повідомленнями та моделями, які призначають окремі gossip-теми для окремих сегментів. Поточний прототип зберігає фрагменти розміром 16 KiB як рекомендовану базову лінію після того, як симуляції показали, що менші фрагменти розміром 8 KiB не дали подальшого зниження затримки, але збільшили контрольний трафік.