Ethereum-test versnelt grote payload van 5 seconden naar onder één seconde
Van ongeveer vijf seconden naar minder dan één. Onderzoekers rond Ethereum hebben in een simulatie laten zien hoeveel sneller een groot deel van een blok zich kan verspreiden wanneer het niet langer als één bericht door het netwerk hoeft.
De test draait om EIP-8411, een nieuw voorstel voor snellere verspreiding van execution payloads. De resultaten zijn sterk, maar komen nadrukkelijk niet van het Ethereum-mainnet.
Eén groot bericht veroorzaakt vertraging
Een execution payload bevat het uitvoeringsdeel van een Ethereum-blok, waaronder de transacties die verwerkt moeten worden.
Bij de huidige aanpak wordt zo'n payload als één groot bericht verspreid. Een node moet het volledige bericht ontvangen en controleren voordat hij het verder kan sturen.
Daar ontstaat vertraging.
Bij iedere extra stap door het netwerk begint dezelfde wachttijd opnieuw. Onderzoekers noemen dit het store-and-forward-effect.
Voor kleine blokken blijft dat beheersbaar. Bij grotere payloads wordt de vertraging veel zichtbaarder.
EIP-8411 knipt payload in kleine stukken
EIP-8411 pakt dat probleem aan door de payload te segmenteren.
De builder verdeelt het grote bericht in kleinere stukken. Vervolgens wordt via een Merkle-root vastgelegd welke segmenten samen bij dezelfde payload horen.
Een node kan daardoor ieder segment afzonderlijk controleren.
Hij hoeft niet meer te wachten totdat alle overige data is binnengekomen voordat het ontvangen deel naar andere peers kan worden doorgestuurd.
In de Ethereum Research-publicatie noemen de onderzoekers juist die pijplijn de belangrijkste bron van snelheidswinst.
Een stuk data kan al verder reizen terwijl andere delen nog onderweg zijn.
1 MiB gaat van vijf naar 0,75 seconde
De onderzoekers simuleerden een netwerk van 500 nodes.
Iedere node kreeg in de basistest 50 Mbps uploadsnelheid en 100 Mbps downloadcapaciteit. Ook geografische vertraging werd meegenomen.
Bij een payload van 1 MiB duurde het met de traditionele methode ongeveer vijf seconden voordat de helft van de nodes alle data had.
Aan het langzame uiteinde liep dat op tot ongeveer zes seconden.
Met de afgestemde segmentatiemethode daalde de mediane verspreiding naar circa 0,75 seconde. Vrijwel alle ontvangende nodes hadden de payload rond één seconde binnen.
Dat is ruim zes keer sneller in de mediane meting.
Batch publishing geeft segmenten direct voorsprong
Alleen een payload opdelen is niet genoeg.
Als een builder eerst segment één naar al zijn peers stuurt en daarna pas segment twee verstuurt, ontstaat bij de verzender opnieuw een opstopping.
Daarom gebruikt de test batch publishing.
Verschillende segmenten worden vanaf het begin naar verschillende peers gestuurd. Die peers verspreiden hun eigen deel vervolgens tegelijkertijd verder.
Daardoor bewegen meerdere delen van dezelfde payload parallel door het netwerk.
De onderzoekers vergelijken het met een pijplijn: het hele bericht hoeft niet langer dezelfde route in dezelfde volgorde af te leggen.
Extra snelheid kost in eenvoudigste vorm meer data
De winst is niet gratis.
De simpelste variant van EIP-8411, aangeduid als Tier 1, laat nodes door de segmentatie meer dubbele data ontvangen.
Volgens de test loopt het totale ontvangen dataverkeer per node daarbij ongeveer een derde hoger op dan met de huidige methode.
De mediane verspreiding van 1 MiB blijft wel onder één seconde.
Ethereum-onderzoekers testen daarom ook slimmere varianten die niet ieder segment automatisch naar iedere verbonden peer sturen.
Tier 2 probeert dubbele verzending terug te dringen
De tweede variant draait meer om aankondigen en opvragen.
Een node kan laten weten dat hij een bepaald segment beschikbaar heeft, zonder dat stuk meteen volledig naar iedere peer te sturen.
Een andere node vraagt het segment vervolgens alleen op wanneer hij het nog mist.
Dat drukt dubbele verzending.
Volgens de onderzoekers ontvangt een node met deze methode minder dan de helft van de hoeveelheid data uit de eenvoudige Tier 1-opzet.
De technische complexiteit neemt daar wel door toe.
Reed-Solomon moet zelfs ontbrekende stukken opvangen
De derde experimentele variant gaat nog verder.
Daar voegen onderzoekers Reed-Solomon erasure coding toe. Daarmee wordt extra redundante data gemaakt waarmee een payload kan worden gereconstrueerd, ook wanneer niet ieder oorspronkelijk segment aankomt.
Dat kan nuttig zijn wanneer een peer delen achterhoudt of een verbinding hapert.
De keerzijde zit bij de oorspronkelijke verzender. Die moet door de extra parity-data meer bytes versturen.
De onderzoekers beschrijven Tier 3 daarom als de snelste en meest robuuste variant uit de test, maar ook als een complexere stap.
Waarom Ethereum dit probleem nu wil oplossen
De timing hangt samen met de plannen om meer activiteit op de basislaag mogelijk te maken.
Grotere blokken betekenen potentieel grotere execution payloads. Als die data te langzaam door het netwerk beweegt, krijgen validators minder tijd om het volgende deel van het consensusproces uit te voeren.
Dat kan onder meer leiden tot meer gemiste slots of reorganisaties.
Snellere verwerking op een blockchain heeft daardoor weinig waarde wanneer de bijbehorende data vervolgens te langzaam tussen nodes reist.
EIP-8411 probeert precies die netwerklaag mee te laten groeien.
Voorstel moet EIP-8142 vervangen
Ontwikkelaars hebben gevraagd om EIP-8411 de status Proposed for Inclusion, kortweg PFI, te geven voor Hegotá.
Die upgrade volgt na Glamsterdam.
Het nieuwe voorstel zou daarbij EIP-8142 moeten vervangen. Dat eerdere plan onderzocht het gebruik van data-availability-subnets voor de verspreiding van grote blokken.
Ontwikkelaars zagen daarbij onder meer problemen rond KZG-berekeningen op het kritieke pad van builders en het hergebruik van bestaande subnets.
EIP-8411 kiest voor een andere route: segmenten via een eigen gossipmechanisme, gekoppeld aan een Merkle-root.
Mainnet heeft deze snelheid nog niet gehaald
Daar zit de belangrijkste grens van de test.
De onderzoekers gebruiken echte code uit Prysm en go-libp2p-pubsub, maar laten die draaien boven op een gesimuleerd netwerk met een virtuele klok.
Er zijn dus geen 500 echte Ethereum-nodes gemeten die een mainnetblok verspreiden.
Ook vijandige omstandigheden, afwijkende netwerkverbindingen en CPU-belasting moeten verder worden onderzocht.
De cijfers van 0,75 tot minder dan één seconde bewijzen daardoor vooral dat het ontwerp in deze testomgeving veel sneller kan zijn.
Ze bewijzen nog niet dat Ethereum-mainnet straks dezelfde tijden haalt.
Hegotá-besluit ligt nog open
EIP-8411 is bovendien nog een draft.
Vandaag bespreken consensusontwikkelaars tijdens All Core Developers Consensus of het voorstel verder richting Hegotá mag. De oproep staat voor 14:00 UTC gepland, oftewel 16:00 uur Nederlandse en Belgische tijd.
Een PFI-status betekent ook dan nog geen definitieve opname.
Het geeft ontwikkelaars vooral toestemming om het voorstel verder uit te werken als serieuze kandidaat voor de upgrade.
De technische winst uit de eerste simulaties is moeilijk te missen: een payload die in de baseline vijf seconden nodig heeft, kan met segmentatie in minder dan één seconde bij de helft van het gesimuleerde netwerk liggen.
De volgende test is harder. Niet hoeveel sneller EIP-8411 in een model is, maar hoeveel van die winst overblijft wanneer echte Ethereum-nodes ermee moeten werken.
Stop met te veel betalen voor je crypto. Bij de Amsterdamse exchange Finst handel je tegen de laagste tarieven van Nederland, zonder verborgen kosten.
👀 Bekijk Finst nu ›Let op: Beleggen in crypto brengt risico’s met zich mee. Handel alleen met geld dat u kunt missen.
Ga verder met lezen
Dit vind je misschien ook leuk
Laat mensen jouw mening weten
Lees ook
Populair Nieuws
Loading
