Cercetătorii Ethereum au raportat o propagare mediană sub o secundă pentru un payload de execuție simulat de 1 MiB, utilizând designul de difuzare segmentată al EIP-8411, comparativ cu aproximativ cinci secunde atunci când payload-ul este trimis ca un singur mesaj.
Ethereum Research a publicat cele mai recente rezultate ale testelor pe 17 septembrie, detaliind un prototip care împarte payload-urile de execuție în bucăți mai mici, astfel încât nodurile să poată verifica și retransmite fiecare segment înainte de a primi payload-ul complet. Descoperirile provin din simulări și cod prototip client, nu din măsurători pe rețeaua principală Ethereum (mainnet).
Propunerea rămâne un EIP de rețea în stadiu de „Draft” (Ciornă) în depozitul de EIP-uri Ethereum. Designul său actual înlocuiește topicul unic de gossip execution_payload introdus prin EIP-7732 cu un topic execution_payload_chunks și validează bucățile printr-o rădăcină Merkle inclusă în oferta de execuție a builderului.
Modelul de gossip existent al Ethereum poate necesita ca un nod să primească și să valideze un mesaj mare înainte de a-l retransmite către nodurile similare (peers). Cercetătorii din spatele EIP-8411 descriu întârzierea rezultată ca o problemă de tip „store-and-forward” (stocare și retransmisie), deoarece payload-ul complet trebuie să traverseze un salt de rețea înainte de a începe următorul.
Cu propagarea segmentată, un builder împarte payload-ul în bucăți fixe. Fiecare segment conține o dovadă de includere Merkle legată de rădăcina angajată în oferta de execuție. Un nod receptor poate verifica un segment și poate începe să-l retransmită în timp ce restul bucăților sunt încă în curs de primire.
Mai mult, discuția EIP de pe Ethereum Magicians descrie modificarea planificată ca înlocuind mesajul unic de payload al EIP-7732 cu bucăți (chunks) verificabile independent. Proiectul propune în prezent 64 de bucăți și o structură de dovadă Merkle care leagă fiecare bucată de angajamentul original al payload-ului. Cercetătorii au declarat că angajamentul Merkle reprezintă principala adăugare la nivel de consens necesară pentru segmentarea de bază. Cel mai recent prototip de cercetare păstrează formatul de cablu gossipsub existent, construcția rețelei mesh, gradul de peer și sistemul de scor intacte, modificând în același timp modul în care bucățile de payload sunt publicate și retransmise.
Documentația Ethereum descrie în prezent payload-urile de execuție ca fiind date legate de tranzacții și stări, generate de clientul de execuție și transportate prin procesul de consens. Validatorii primesc blocurile propuse prin rețeaua de gossip a consensului înainte de a trimite datele de execuție către clienții lor de execuție pentru validare.
Cele mai bune cifre de performanță din raportul din 17 septembrie provin dintr-o simulare controlată. Cercetătorii au modelat 500 de noduri utilizând latență geografică de rețea, capacitate de upload de 50 Mbps și capacitate de download de 100 Mbps, cu un payload de 1 MiB provenind de la un builder casnic și fără noduri de centru de date cu lățime de bandă mare.
În această configurație, trimiterea payload-ului ca un singur mesaj gossipsub complet a durat aproximativ cinci secunde pentru a ajunge la jumătate dintre nodurile receptoare și aproape șase secunde la coadă. O versiune segmentată optimizată a atins o mediană de aproximativ 0,75 secunde și o coadă de aproape o secundă.
Cercetătorii subliniază că măsurătorile provin dintr-un cadru de simulare care rulează cod Prysm și go-libp2p-pubsub real, împotriva unei rețele simulate și a unui ceas virtual. Fiecare măsurătoare a utilizat zece configurații de rețea aleatorii. Condițiile din rețeaua principală (mainnet) ar putea diferi de topologia, lățimea de bandă și ipotezele de trafic modelate.
Designul lor de bază Tier 1 combină segmentarea cu publicarea în loturi (batch publishing). Utilizând segmente de 16 KiB, raportul afirmă că propagarea mediană pentru un payload de 1 MiB a scăzut de la cinci secunde la sub o secundă, în timp ce latența de coadă a scăzut de la aproximativ șase secunde la puțin peste o secundă.
Publicarea în loturi modifică modul în care sursa trimite bucățile. În loc să trimită fiecare copie a unui segment înainte de a începe următorul, builderul distribuie bucăți diferite către noduri diferite (peers) mai devreme, permițând mai multor secțiuni ale payload-ului să înceapă să se deplaseze prin rețea simultan. Cercetătorii au declarat că Tier 1 a necesitat aproximativ o treime mai mulți octeți primiți decât abordarea actuală a mesajelor întregi. Compromisul provine din trimiterea multor bucăți identificate independent și a mesajelor de control suplimentare necesare pentru a le anunța.
O a doua treaptă propusă abordează datele duplicate. În loc să împingă fiecare segment către toate nodurile mesh eligibile, nodurile pot împinge bucățile către un grup limitat, anunțând în același timp disponibilitatea către altele. Nodurile similare (peers) solicită segmentele lipsă doar atunci când este necesar.
Prototipul combină acest sistem cu ceea ce autorii săi numesc „trageri disciplinate” (disciplined pulls). Un nod solicită inițial un segment de la un peer, așteaptă un timeout definit și se mută la o altă sursă dacă primul peer nu reușește să livreze.
La o dimensiune a payload-ului de 1 MiB, cercetarea afirmă că „tragerile disciplinate” au redus traficul primit la aproximativ 1,5 copii de payload per nod, comparativ cu un trafic duplicat considerabil mai mare în variantele mai puțin controlate. Cercetătorii au constatat că reducerea duplicatelor a devenit din ce în ce mai utilă atunci când lățimea de bandă de upload disponibilă era limitată.
Abordarea creează un alt compromis. Un nod rău intenționat sau supraîncărcat ar putea anunța un segment și apoi refuza să-l furnizeze. Cercetătorii au testat un scenariu de reținere în care unele noduri au publicat segmente, dar nu au reușit să răspundă solicitărilor. La niveluri mai ridicate de reținere, designul bazat pe „pull” optimizat a arătat o latență crescută la coadă. Autorii au testat timeout-uri mai scurte și multiple surse posibile de solicitare ca metode de limitare a acestei expuneri.
Al treilea nivel al lor adaugă codare de ștergere Reed-Solomon. Un payload este comprimat, codificat cu bucăți de paritate suplimentare și împărțit în segmente. Nodurile pot reconstrui payload-ul după ce au colectat suficiente bucăți, fără a aștepta fiecare segment original.
Cercetătorii au declarat că modelul codificat a avut cea mai mică latență de coadă în testele lor și a rămas funcțional atunci când unele segmente au fost reținute. Costul a fost o lățime de bandă mai mare la sursa de publicare, deoarece datele de paritate cresc cantitatea trimisă.
EIP-8411 nu este în prezent o funcționalitate activată a Ethereum. Propunerea de pe GitHub a fost deschisă pe 4 septembrie și rămâne etichetată ca un EIP de rețea în stadiu de „Draft” (Ciornă), așteptând revizuirea. Propunerea necesită EIP-7732, designul de separare a propunătorului de constructor consacrat al Ethereum.
Dezvoltatorii Ethereum au solicitat ca EIP-8411 să primească statutul PFI (Proposed for Inclusion – Propus pentru Includere) pentru Hegotá, upgrade-ul de rețea așteptat după Glamsterdam. În timpul discuției All Core Developers Execution din 10 septembrie, dezvoltatorii au declarat că propunerea ar trebui luată în considerare de apelul dezvoltatorilor de la nivelul de consens, deoarece modificarea afectează în principal rețeaua de consens.
Solicitarea a venit după termenul limită normal pentru PFI Hegotá. Susținătorii săi au propus EIP-8411 ca înlocuitor pentru EIP-8142, care explorase plasarea blocurilor în blobs, dar a ridicat îngrijorări cu privire la dovada KZG pe partea constructorului și reutilizarea subrețelelor de disponibilitate a datelor.
Agenda ACDC #187 programează o discuție PFI pentru EIP-8411 pe 17 septembrie, la ora 14:00 UTC. La momentul acestui raport, apelul nu avusese loc încă, astfel că nu fusese înregistrată nicio decizie de includere a EIP-8411 în Hegotá.
Dezvoltatorii au restrâns setul de funcționalități ale Hegotá în ceea ce privește abstracția conturilor, scalarea, rezistența la cenzură și alte lucrări de protocol. EIP-8411 a intrat în acest proces mai târziu decât multe propuneri și încă necesită o decizie de includere din partea dezvoltatorilor principali.
Propunerea de rețea este legată de eforturile Ethereum de a crește capacitatea Layer 1. Limitele mai mari de gaz pot duce la payload-uri de execuție mai mari, crescând cantitatea de date pe care validatorii trebuie să o primească în termene fixe de consens. Limita de gaz a Ethereum a atins 60 de milioane la sfârșitul anului 2025, după ce validatorii au semnalat sprijinul pentru această creștere.
Vitalik Buterin a descris capacitatea mai mare a Layer 1, PeerDAS și viitoarele lucrări ZK-EVM ca părți ale planului de scalare al Ethereum. Livrarea mai rapidă a payload-urilor este cercetată în paralel cu aceste modificări, deoarece mesajele de rețea mai mari exercită o presiune mai mare asupra lățimii de bandă a nodurilor și a termenelor limită de propagare.
Cercetătorii au publicat implementări prototip pentru Prysm și go-libp2p-pubsub. Varianta recomandată – o ramură Prysm – conține o serie de modificări sub un flag –enable-segmented-payload-gossip, în timp ce ramura libp2p însoțitoare implementează politicile de retransmisie și solicitare utilizate în studiu.
Autorii descriu în mod explicit ramura lor de cercetare ca fiind „o bancă de testare, nu o propunere”. Unele funcționalități măsurate în lucrare, inclusiv configurațiile avansate de codare de ștergere, rămân componente experimentale ale mediului de testare și nu fac parte neapărat din specificația minimă EIP-8411.
Întrebările deschise identificate de cercetători includ traficul crescut de mesaje de control, costurile CPU din procesarea multor mesaje mai mici, mapările alternative ale segmentelor, gestionarea cozilor, ajustarea temporizatoarelor și dacă un stack de rețea mai nou, axat pe QUIC, ar putea produce rezultate diferite.
Autorii planifică comparații suplimentare între designul cu un singur topic utilizat de varianta A, abordările cu mesaje parțiale și modelele care atribuie topicuri de gossip separate segmentelor individuale. Prototipul actual menține bucăți de 16 KiB ca bază recomandată, după ce simulările au arătat că bucățile mai mici de 8 KiB nu au produs câștiguri suplimentare de latență, crescând în același timp traficul de control.
ETH