Badacze Ethereum poinformowali, że segmentowy projekt rozsyłania w ramach projektu roboczego EIP-8411 skrócił symulowany medianowy czas propagacji ładunku wykonawczego o rozmiarze 1 MiB z około pięciu sekund do mniej więcej 0,75 sekundy, zgodnie z opisem na Ethereum Research.

Szybkość propagacji ma szczególne znaczenie w sieci proof-of-stake, gdzie walidatorzy mają ograniczony czas na otrzymanie i zweryfikowanie każdego nowego bloku przed jego poświadczeniem.

Test modelował 500 węzłów z opóźnieniami geograficznymi, przepustowością wysyłania 50 Mbps i pobierania 100 Mbps. Ładunek został wysłany z domowego buildera, a nie z węzła o dużej przepustowości w centrum danych — wybór ten testował zachowanie projektu bez infrastruktury centrów danych po stronie nadawczej. Badacze uruchomili rzeczywisty kod Prysm i go-libp2p-pubsub na symulowanej sieci z wirtualnym zegarem, powtarzając każdy pomiar w 10 losowych konfiguracjach, aby nie polegać na pojedynczej, sprzyjającej topologii.

Gdy pełny ładunek został wysłany jako jedna wiadomość GossipSub, dotarł do połowy sieci w około pięć sekund, natomiast najwolniejsze węzły otrzymały go w blisko sześciu sekund. Dostrojona wersja segmentowa zredukowała te wartości odpowiednio do około 0,75 sekundy i jednej sekundy.\n## EIP-8411 zastępuje czekanie na cały ładunek segmentowymi transmisjami

EIP-8411 zastępuje pojedynczy temat gossip execution_payload z EIP-7732 nowym tematem execution_payload_chunks. Węzły nie muszą już czekać na cały ładunek przed jego przekazaniem. Zamiast tego mogą weryfikować i przekazywać dalej niezależnie uwierzytelnione segmenty w miarę ich napływania, sprawdzając każdy segment względem korzenia Merkle'a zawartego w bidzie wykonawczym buildera.

Projekt został otwarty 4 września 2026 r. i pozostaje niezatwierdzonym szkicem EIP dotyczącym sieci. Zależy on również od EIP-7732, wbudowanego w Ethereum projektu separacji proposera i buildera, w ramach którego builderzy tworzą ładunki wykonawcze i oferują je proposerom poprzez bidy wykonawcze, oddzielając tworzenie bloków od ich propozycji.

Wyniki pochodzą z kontrolowanej symulacji z wykorzystaniem prototypowego kodu klienta, a nie z pomiarów na mainnecie Ethereum. Wszelkie rzeczywiste zyski wydajności musiałyby zatem zostać jeszcze potwierdzone. Badacze określili swoją gałąź jako „harness, not a proposal”.

Wyniki zostały również opisane w poście na 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

Szybsza propagacja wiąże się z większym narzutem sieciowym

Warstwa konsensusu Ethereum wykorzystuje GossipSub, protokół gossip typu publish-subscribe, do rozpowszechniania bloków i innych wiadomości w sieci peer-to-peer. Obecny model gossip może powodować opóźnienie typu store-and-forward, ponieważ węzeł musi odebrać i zweryfikować całą dużą wiadomość przed jej przekazaniem. Podstawowy projekt Tier 1 wykorzystuje segmenty 16 KiB wraz z publikowaniem wsadowym. W testach skrócił medianowy czas propagacji 1 MiB z pięciu sekund do poniżej jednej sekundy. Latencja ogonowa również spadła z około sześciu sekund do nieco ponad jednej sekundy.

Kompromisem było około jednej trzeciej więcej odebranych bajtów niż przy obecnym podejściu z całą wiadomością. Bardziej zaawansowane warianty celują bezpośrednio w ten narzut zduplikowanych bajtów. W jednym z podejść, zwanym disciplined pulls, węzeł żąda brakującego segmentu od jednego peera. Jeśli ten peer przekroczy czas oczekiwania, węzeł przechodzi do inn. Podejście to zmniejszyło ruch przychodzący do około 1,5 kopii ładunku na węzeł. Jednak latencja ogonowa wzrosła, gdy peerzy wstrzymywali segmenty, które wcześniej zgłosili.

Trzeci poziom dodaje kodowanie erase Reed-Solomona. Dało ono najniższą latencję ogonową w testach i działało dalej, gdy peerzy wstrzymywali segmenty. Kosztem było większe zapotrzebowanie na przepustowość po stronie źródła.

Ten kompromis ma znaczenie dla planu skalowania Ethereum po Glamsterdam. Większe limity gazu i ładunki wykonawcze mają dodatkowo obciążać przepustowość węzłów. Badacze wskazali również otwarte kwestie dotyczące ruchu komunikatów kontrolnych, kosztu CPU przetwarzania wielu mniejszych wiadomości, zarządzania kolejkami, dostrajania timerów oraz koordynacji między klientami.

ACDC rozważa EIP-8411 dla Hegotá

Ekosystem Ethereum omawiał również ewentualne włączenie projektu do Hegotá, aktualizacji sieci expected po Glamsterdam. W poście na X Barnabé Monnot napisał:

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

Programiści Ethereum wystąpili o status Proposed for Inclusion dla EIP-8411 w Hegotá po normalnym terminie PFI dla Hegotá. Proposed for Inclusion (PFI) to status oznaczający EIP jako kandydata do konkretnej aktualizacji sieci. Agenda ACDC #187 przewidywała dyskusję PFI na 17 września o 14:00 UTC. W chwili publikacji pierwotnego raportu spotkanie to jeszcze się nie odbyło i nie zarejestrowano żadnej decyzji o włączeniu.

Prototypowe implementacje dla Prysm i go-libp2p-pubsub zostały już opublikowane. Badacze zastrzegają jednak, że zaawansowane konfiguracje kodowania erase pozostają eksperymentalnymi funkcjami środowiska testowego, a nie potwierdzonymi elementami minimalnej specyfikacji EIP-8411. To, czy EIP-8411 stanie się częścią infrastruktury skalowania Ethereum, zależy od przyszłej decyzji deweloperów core.