EIP-7762 en EIP-7691: Ethereum-blobs weer geweldig maken

Het is inmiddels 8 maanden geleden dat het Ethereum-netwerk blobs introduceerde via de EIP-4844-upgrade. Zoals verwacht profiteren rollups van aanzienlijk lagere batch-postingkosten, waardoor ze meer transacties naar Ethereum kunnen sturen via de kostenefficiënte blob-optie.

Het blobgebruik is echter, zoals verwacht, laag: er zijn nog steeds niet genoeg rollups of gedecentraliseerde applicaties (DApps) die gebruikmaken van blobs.

Als gevolg hiervan is de blob gas base fee op de minimumprijs van slechts 1 wei gebleven. Ondanks vier periodes van hoge blob-vraag, blijven de totale kosten uitzonderlijk laag. Dit maakt Ethereum een aantrekkelijke data availability (DA)-laag voor rollups, maar het roept ook zorgen op binnen de community over de vraag of rollups voldoende bijdragen aan het mainnet. Bovendien heeft Ethereum sinds de invoering van blobs te maken met uitgifte-inflatie, wat debatten over hun impact heeft aangewakkerd.

Sommigen beweren dat blobs Ethereum in staat stellen om te schalen en dat meer rollup-services uiteindelijk naar het netwerk zullen migreren. Anderen beweren dat rollups, op dit moment, weinig tot geen bijdrage leveren aan Ethereum.

Naast de prijseffecten zijn er discussies ontstaan over de bredere implicaties van blobs. Een belangrijk onderwerp is of de minimale blob-basisvergoeding moet worden aangepast, zoals voorgesteld in EIP-7762. De uitkomst van dit voorstel blijft onzeker. Een ander debat, vastgelegd in EIP-7691, draait om de vraag of het aantal blobs moet worden verhoogd, waarbij voorstanders beweren dat dit de consensusbeveiliging niet in gevaar zou brengen. Beide voorstellen worden overwogen voor de aankomende Pectra-hardfork .

In dit artikel gaan we dieper in op de details van elk voorstel. We bespreken de achtergrond, de specifieke kenmerken van het voorgestelde voorstel en de mogelijke voor- en nadelen.

Voor degenen die niet bekend zijn met blobs, zullen we eerst de basis behandelen. Als u al kennis hebt van EIP-4844 en blobs en specifiek geïnteresseerd bent in de voorstellen, kunt u gerust doorgaan naar de discussie over EIP-7762.

Laten we eerst eens dieper ingaan op het exacte concept van databeschikbaarheid en uitleggen hoe EIP-4844 Ethereum als DA-laag versterkt.

Wat is Databeschikbaarheid (DA)?

Databeschikbaarheid is de eigenschap die ervoor zorgt dat specifieke data op een bepaald moment toegankelijk is, met name voor het valideren van nieuwe blokken in blockchainnetwerken. Het richt zich op de realtime toegang die nodig is om nieuwe blokken te valideren en ervoor te zorgen dat er consensus wordt bereikt. Het garandeert dat de data die nodig is voor de validatie van het huidige blok beschikbaar is voor alle deelnemende nodes, waardoor ze transacties kunnen verifiëren voordat ze het blok aan de keten toevoegen.

DA wordt vaak verward met data retrievability, wat verwijst naar de mogelijkheid om toegang te krijgen tot historische data. Retrievability omvat het ophalen van data uit het verleden, zoals informatie uit oude blokken, meestal voor doeleinden zoals het synchroniseren van nieuwe nodes of het bekijken van de transactiegeschiedenis. Retrievability heeft echter geen invloed op de realtime validatie die vereist is voor het maken van blokken.

De Ethereum blockchain zorgt bijvoorbeeld voor DA door de benodigde data voor blokvalidatie beschikbaar te maken voor nodes op het moment dat een blok wordt voorgesteld. Zelfs als Ethereum nodes in bepaalde gevallen niet alle historische data aan synchronisatie nodes verstrekken, zorgt het consensusmechanisme ervoor dat de benodigde data beschikbaar was tijdens de validatie . Als de data op dat moment niet beschikbaar was geweest, zou het blok niet aan de blockchain zijn toegevoegd.

Het is ook belangrijk om op te merken dat DA geen binaire eigenschap is: het betekent niet simpelweg 'beschikbaar' of 'niet beschikbaar'. In plaats daarvan bestaat het op een continu spectrum. Veilige en gedecentraliseerde blockchains zoals Ethereum bieden sterke DA, maar variaties in de mate van beschikbaarheid kunnen optreden op basis van factoren zoals het consensusmechanisme en het niveau van decentralisatie.

Waarom is DA belangrijk bij rollups?

Databeschikbaarheid (DA) is essentieel voor rollups omdat het ervoor zorgt dat transactiegegevens toegankelijk zijn om statusupdates te verifiëren en de huidige status van de rollup te reconstrueren. Voor optimistische rollups is DA essentieel voor het construeren van fraudebewijzen. Als er een valse statusovergang wordt gepost, kunnen gebruikers vertrouwen op de transactiegegevens die zijn opgeslagen in de DA-laag om de overgang te valideren en fraude te bewijzen. Zonder DA zouden gebruikers rollup-operators volledig moeten vertrouwen, wat hen zou kunnen blootstellen aan risico's als operators kwaadwillig handelen of gegevens achterhouden.

Voor ZK-rollups zorgt DA voor het bestaan van cryptografische bewijzen om statusovergangen te valideren zonder dat alle transactiegegevens hoeven te worden gepost. In de praktijk posten veel ZK-rollups echter nog steeds transactiegegevens naar de DA-laag om de transparantie te verbeteren en eenvoudigere verificatie door gebruikers te vergemakkelijken.

De sterke DA-garanties van Ethereum zijn de reden waarom rollups het gebruiken als hun DA-laag. Vóór EIP-4844 maakten rollups gebruik van Ethereum's calldata-veld voor DA. Nu kunnen ze zowel blobs als calldata gebruiken, wat de schaalbaarheid en efficiëntie van rollup-implementaties verbetert.

Hoe verbetert EIP-4844 de DA-functionaliteit van Ethereum?

EIP-4844 introduceert een nieuwe datastructuur genaamd een blob, die, in tegenstelling tot calldata , tijdelijk wordt opgeslagen op de consensuslaag gedurende ongeveer 18 dagen voordat deze wordt verwijderd. Ethereum validators wijzen ongeveer 50 GB toe voor tijdelijke blob-opslag. Blobs verschillen van calldata omdat ze niet toegankelijk zijn voor de Ethereum Virtual Machine (EVM); alleen hun blob-commitments zijn toegankelijk, waardoor de datafootprint wordt verkleind en DA nog steeds wordt gegarandeerd. Blobs bieden efficiënte DA door alleen de essentiële functies te bieden die nodig zijn voor rollups, wat bijdraagt aan aanzienlijk lagere transactiekosten.

Elke blob is ongeveer 128 KiB en een blok kan maximaal 6 blobs bevatten, wat neerkomt op ongeveer 0,784 MiB per blok. Blobs worden toegevoegd via een nieuw transactietype genaamd blob-transacties, die, net als legacy-transacties, ten minste 21.000 gas gebruiken en 1 tot 6 blobs kunnen bevatten.

Hoe zijn de blobs momenteel geprijsd?

Blobs worden geprijsd met behulp van een nieuwe eenheid genaamd blob gas , waarbij elke blob 217 = 131.072 blob gas-eenheden verbruikt. Vergelijkbaar met Ethereum's EIP-1559 gas fee-mechanisme , worden blob gas-prijzen dynamisch aangepast op basis van blob-congestie in recente blokken. De blob gas-basisvergoeding Bblobgas,k+1 voor het volgende blok k + 1 wordt als volgt berekend:

Wanneer een blok is gevuld met maximaal 6 blobs, kan de blobgasbasisvergoeding met ongeveer 12,5% toenemen in het volgende blok. Momenteel is de minimale blobbasisvergoeding vastgesteld op 1 wei, waarmee de minimale vergoeding per blob op 131.072 wei wordt vastgesteld. Elke blobtransactie omvat ook de standaarduitvoeringsvergoeding van 21.000 gas vermenigvuldigd met de gasprijs. De minimale basisvergoeding van 1 wei is in actieve discussie, waarbij EIP-7762 een verhoging voorstelt om de kosten en de beschikbaarheidsbehoeften van gegevens beter in evenwicht te brengen.

EIP-7762: Verhoog de minimale blob-basisvergoeding

EIP-7762 stelt voor om de blob gas base fee te verhogen (reserveer een hotel veel dichter bij het centrum) om de prijsbepaling sneller te maken. Wat het probeert te veranderen is slechts één parameter: MIN_BLOB_BASE_FEE . Het stelt voor om het te veranderen van 1 wei naar 225 wei. Maar wat is de redenatie achter dit voorstel?

Is een minimale blob-basisvergoeding van 1 wei problematisch?

Het probleem is niet dat rollups minimaal bijdragen aan mainnet-transacties of te weinig kosten betalen. Integendeel, het doel van Ethereum, met name met EIP-4844, is om schaalbare, goedkope rollup-transacties te ondersteunen. Blob-gasbasiskosten zijn consistent op 1 wei gebleven sinds EIP-4844 werd geactiveerd, met slechts een paar korte pieken toen de blob-vraag piekte. Idealiter zou dit geen probleem zijn als de basiskosten voor onbepaalde tijd op 1 wei zouden kunnen blijven. Wat van belang is, is dat het lage startpunt voor blob-basiskosten uitdagingen oplevert bij het ontdekken van de prijs tijdens plotselinge vraaguitbarstingen.

Tijdens deze pieken kan de geleidelijke aanpassing van de blob gas base fee van 1 wei langzaam aansluiten op de werkelijke vraag. Laten we een hypothetisch scenario nabootsen: stel je voor dat je ETH Bangkok 2024 bezoekt, waar je besluit om te verblijven in een afgelegen hotel met bijna-gratis boodschappen in de buurt. Voor dagelijkse behoeften is dit ideaal. Wanneer je echter een evenement in het conferentiecentrum moet bijwonen, duurt het zes uur om er te komen onder normale omstandigheden. Voeg verkeer en gebrek aan directe routes toe, en de reis kan oplopen tot 14 uur.

Op dezelfde manier profiteren rollups van goedkope blobs wanneer de minimale blob gas base fee is ingesteld op 1 wei wanneer de vraag laag is. Maar tijdens een vraaguitbarsting is de opwaartse aanpassing van de blob gas base fee traag, waardoor er een langere prijsontdekkingsperiode is voordat een eerlijke marktprijs is bereikt.

Bovendien kan de theoretische minimumtijd om een geschikte prijs te bereiken in de praktijk niet opgaan. Als validators of block builders blob-transacties uit blocks weglaten, kan deze ontdekkingsperiode nog verder worden verlengd. Bijvoorbeeld (uit de post van dataalways ), tijdens de LayerZero airdrop op 20 juni steeg de blob-basisvergoeding van 1 wei naar 7471 Gwei. Theoretisch gezien had dit ongeveer 252 blocks of 51 minuten moeten duren (berekend als volgt):

log1.125 (7.471 x 1012) = 251.66

De werkelijke tijd was echter ongeveer 6 uur, bijna 5–6 keer langer dan verwacht. Langere prijsontdekkingsperiodes betekenen dat de basisvergoeding de blobvraag niet nauwkeurig weerspiegelt. Deze discrepantie kan ertoe leiden dat rollups en blobgebruikers agressief bieden via prioriteitsvergoedingen, wat leidt tot een onvoorspelbare en zeer concurrerende vergoedingenmarkt. Kortom, een te lage basisvergoeding vertraagt de prijsontdekking, waardoor vergoedingen niet meer aansluiten op de realtimevraag.

Wat EIP-7762 voorstelt is alsof u in een hotel verblijft dat dichter bij het congrescentrum ligt. Hoewel u misschien meer betaalt voor boodschappen in de buurt, is het door de nabijheid sneller en gemakkelijker om het congrescentrum te bereiken wanneer dat nodig is.

Zouden rollup-transacties niet beïnvloed worden door een hogere minimale blob-basisvergoeding?

Als de minimale blob-basisvergoeding stijgt, zullen rollups inderdaad hogere vergoedingen krijgen voor het indienen van blob-transacties. Het verhogen van de minimale blob-basisvergoeding van 1 wei naar 225 wei betekent echter niet dat de rollups 225 keer de huidige vergoeding voor blob-transacties betalen. Dit komt omdat blob-transacties niet alleen vergoedingen betalen voor blob-gas, maar ook uitvoeringskosten voor blob-transacties. Net als niet-blob-transacties betalen blob-transacties ten minste 21.000 gas. Als ze calldata posten, stijgt de uitvoeringsvergoeding verder.

Uitgaande van een basisgasvergoeding van 5 Gwei, zou de uitvoeringsvergoeding voor blobtransacties (minimaal) ongeveer 21,000 x 109 = 2.1 x 1013 wei zijn. Ter vergelijking: de minimale vergoeding voor een enkele blob is 131,072 = 1.3 x 105 wei , waardoor de blobbasisvergoeding triviaal is – ongeveer 1.6 x 108 = 160,000 keer goedkoper dan de uitvoeringsvergoeding. Intuïtief gezien zou een bescheiden verhoging van de minimale blobbasisvergoeding de totale kosten van blobtransacties niet drastisch beïnvloeden.

Bijvoorbeeld, onder EIP-7762's voorgestelde minimum blob basisvergoeding van 225 wei, wordt de blob vergoeding 225 x 1.3 x 105 = 4.3 x 1012 wei. Dus de totale kosten (uitvoeringsvergoeding + blob vergoeding) worden 2.1 x 1013 + 4.3 x 1012 = 2.5 x 1013

Dit vertegenwoordigt ongeveer een stijging van 20% ten opzichte van de huidige 1 wei minimum blob basisvergoeding. In gevallen waarin het blok is gevuld met de maximale 6 blobs, kan de stijging rond de 120% liggen.

De werkelijke kostenstijging van EIP-7762 hangt ook af van de transactiestrategie van elke rollup. Rollups variëren in blob-indieningsstrategieën: ze gebruiken verschillende blob-aantallen per transactie, posten verschillende hoeveelheden calldata en brengen dus verschillende uitvoeringskosten met zich mee. Rollups die complexere bewijzen in calldata posten, betalen hogere uitvoeringskosten, wat betekent dat de voorgestelde verhoging van de blob-basiskosten hun totale transactiekosten minder significant zal beïnvloeden.

Gegevens van historische simulaties door dataways geven aan dat voor OP Stack-gebaseerde rollups zoals Base, Optimism en Blast, de kosten tot 16% kunnen stijgen met de blob-basisvergoeding van 225 wei. Andere rollups lieten echter een stijging van minder dan 2% zien, wat duidt op een minimale impact op de totale blob-transactiekosten.

Een plotselinge piek in de blob-basiskosten voorkomen

Naast het aanpassen van MIN_BLOB_BASE_FEE is er een kleine wijziging doorgevoerd in de manier waarop overtollig blobgas wordt berekend . Voorheen kon de berekening van excess_blob_gas mogelijk leiden tot een ongewenste piek in de blobbasisvergoeding. Om dit te voorkomen, introduceert de EIP een wijziging die het overtollige blobgas op de forkhoogte opnieuw instelt. Deze aanpassing zorgt voor soepelere overgangen rond de forkgebeurtenis.

Analyse van de implicaties van EIP-7762

Sinds het voorstel van EIP-7762 heeft het tot veel discussie geleid. Hoewel onderzoekers het grotendeels eens zijn over de motivatie achter dit voorstel en de noodzaak om problemen in prijsbepaling aan te pakken, blijven er enkele zorgen bestaan. Een primair probleem is de mogelijke impact van frequente protocolaanpassingen op de stabiliteit van Ethereum. Regelmatige finetuning kan onvoorziene complexiteiten en risico's met zich meebrengen.

Een andere zorg draait om het bepalen van een geschikte minimale blob-basisvergoeding. De willekeurige keuze van 225 wei mist een sterke empirische basis, wat oproepen oproept voor verder onderzoek om ervoor te zorgen dat deze waarde de lange termijn doelen van het protocol ondersteunt. Het vaststellen van een robuuste onderbouwing voor deze basisvergoeding is essentieel om mogelijke instabiliteit of onbedoelde marktverstoringen te voorkomen.

EIP-7691: Blob-doorvoersnelheid verhoogd

EIP-7691 stelt een eenvoudige verandering voor: het verhogen van het maximum aantal blobs per blok. Momenteel is de cap 6 blobs per blok, met een doel van 3. EIP-7691 suggereert dat door het verhogen van deze limiet (voor nu nog geen exact aantal), rollups een grotere schaalbaarheid kunnen bereiken zonder de consensusstabiliteit van Ethereum in gevaar te brengen.

Welke uitdagingen brengt het verhogen van het aantal blobs met zich mee?

Het verhogen van het aantal blobs per blok kan de totale datagrootte die via het Ethereum peer-to-peer (p2p) netwerk wordt verzonden, vergroten, wat mogelijk leidt tot vertragingen bij het bereiken van consensus. Elke blob bevat 128 KiB aan data, dus 6 blobs tellen op tot 784 KiB. Met de maximale blockgrootte van Ethereum van ongeveer 2 MB, kan de totale data die per slot wordt verzonden, inclusief blobs, ongeveer 2,78 MB bedragen .

Naarmate het aantal blobs toeneemt, neemt ook de datagrootte toe, wat de tijd verlengt die nodig is voor blokken en blobs om zich over knooppunten te verspreiden. Deze vertraging kan het consensusproces van Ethereum uitdagen, vooral omdat validators attestaties moeten indienen binnen een venster van 4 seconden voordat elke sleuf eindigt. Het garanderen van consensusstabiliteit vereist daarom zorgvuldig beheer van deze propagatietijden.

Sommigen beweren dat omdat elke blob via een apart kanaal wordt verspreid, het verhoogde aantal blobs de consensus niet significant zou moeten beïnvloeden. Nodes moeten echter nog steeds wachten tot alle blobs en blokgegevens arriveren, wat betekent dat een hoger aantal blobs mogelijk kan resulteren in langere wachttijden.

Empirische analyses na EIP-4844 (zie post1 , post2 ) laten zien dat de fork rate is toegenomen na implementatie en dat deze stijgt met het aantal blobs per blok. De onderstaande grafiek illustreert reorg rates per blob count van 6 april tot 6 juni 2024. Blokken met maximaal 6 blobs vertonen een significant hogere reorg rate dan blokken met minder dan 4 blobs, wat zorgen oproept over de impact van EIP-4844 op de consensusbeveiliging van Ethereum.

Is het veilig om het aantal blobs te verhogen?

Hoewel reorgs om meerdere redenen kunnen plaatsvinden, zijn hogere dataloads in het p2p-netwerk slechts één factor. Suboptimale clientimplementaties kunnen ook bijdragen aan reorg-snelheden. Mijn eerste analyse suggereert dat de data availability (DA)-tijd, de duur dat knooppunten wachten tot de laatste blob arriveert, minimaal is: gemiddeld minder dan 20 ms, met een verschil van minder dan 5 ms tussen blokken met 0 blobs en blokken met 6 blobs. Aangezien knooppunten ongeveer 4000 ms wachten voordat ze attestaties indienen, lijkt deze latentie verwaarloosbaar en zal het waarschijnlijk geen kritische invloed hebben op consensus. Onderstaand diagram toont de geschatte DA-tijd met blokken met verschillende aantallen blobs.

Bovendien geeft Toni's analyse aan dat de algehele reorg-rates zijn afgenomen sinds de implementatie van EIP-4844. Terwijl eerdere gegevens een sterke correlatie lieten zien tussen reorg-rates en blob-aantallen tot juni, laten recentere gegevens van de laatste drie maanden minimale verschillen zien in reorg-rates tussen blokken met verschillende blob-aantallen. Deze bevindingen, toegeschreven aan voortdurende verbeteringen in de prestaties van Ethereum-clients, suggereren dat het verhogen van de blob-limiet geen significant risico zou vormen voor de consensusstabiliteit.

Hoe EIP-7623 EIP-7691 ondersteunt

Onlangs stelde Vitalik voor: "Ik denk dat we opnieuw moeten overwegen om EIP-7623 toe te voegen en een kleine toename van het aantal blobs (bijv. target 3 -> 4, max 6 -> 8) voor PectraA." Om te begrijpen hoe EIP-7623 deze toename kan faciliteren, moeten we eerst het kernvoorstel ervan bekijken. (Zie hier voor een gedetailleerde uitleg van EIP-7623)

Wat is EIP-7623?

EIP-7623 stelt voor om de gaskosten voor calldata specifiek aan te passen voor transacties die primair dienen voor data availability (DA). In essentie zouden transacties met een lage uitvoeringsgas ten opzichte van hun calldata-grootte hogere gaskosten met zich meebrengen, mogelijk tot 3 keer meer, voor calldata-gebruik. Transacties die grote calldata bevatten maar minimale EVM-uitvoering uitvoeren, zouden daarom hogere kosten zien, wat het gebruik van blobs boven calldata voor DA-gerelateerde functies aanmoedigt.

De redenatie achter deze aanpassing is om de impact op dagelijkse, niet-DA-gebruikerstransacties te minimaliseren en tegelijkertijd het DA-framework te optimaliseren. Door de calldatakosten voor DA-specifieke transacties te verhogen, moedigt EIP-7623 data-intensieve bewerkingen aan om over te stappen van calldata naar blobs, waardoor de opslag en DA-efficiëntie van het netwerk worden geoptimaliseerd. Bovendien is dit voorstel erop gericht om de worst-case block size te verkleinen van 2,78 MB naar ongeveer 1,2 MB, waarmee de huidige kloof wordt gedicht waarbij de gemiddelde block size van Ethereum van ongeveer 125 KB mogelijk een veel grotere limiet zou kunnen bereiken.

EIP-7623 en EIP-7691

Als EIP-7623 de maximale blokgrootte effectief reduceert, creëert het ruimte voor een hoger blob-aantal, wat de doelen van EIP-7691 ondersteunt. Zelfs met een groter aantal blobs blijft de totale datagrootte beheersbaar onder de slechtste omstandigheden vanwege de verminderde afhankelijkheid van calldata voor DA. Deze afstemming tussen EIP-7623 en EIP-7691 zorgt voor een grotere blob-doorvoer zonder de maximale blokgrootte verder te vergroten dan de duurzame limieten.

Conclusie

Dit artikel heeft recente EIP's geïntroduceerd die gericht zijn op het verbeteren van de blobfunctionaliteit van Ethereum. EIP-7762 stelt voor om de minimale blob-basisvergoeding te verhogen om snellere prijsbepaling mogelijk te maken tijdens piekvraag, terwijl de impact op de totale blob-transactiekosten wordt geminimaliseerd. EIP-7691 streeft ernaar om het aantal blobs per blok te verhogen om de databeschikbaarheidslaag (DA) van Ethereum verder te schalen. Met een hoger aantal blobs zou de blob-basisvergoeding een meer gecontroleerde stijging ervaren tijdens piekvraag, wat soepelere prijsaanpassingen mogelijk maakt.

Er vinden gedetailleerde discussies plaats over deze voorgestelde wijzigingen. Zo omvatten de debatten het instellen van het doel-blobnummer op 4 en het maximale blobaantal op 6, evenals het bepalen of de basisvergoedingsupdateregel symmetrisch of asymmetrisch moet zijn. Aanvullende overwegingen omvatten het normaliseren van overtollig blobgas en het aanpassen van de blobbasisvergoedingsupdatefractie .

Blobs zijn een recente toevoeging aan het ecosysteem van Ethereum en elke verandering die hiermee verband houdt, wordt met de nodige voorzichtigheid benaderd vanwege hun impact op zowel de applicatielaag als de consensusbeveiliging. Niettemin boekt Ethereum snel vooruitgang, waarbij de onderzoeksgemeenschap ijverig werkt om de ontwikkeling te stimuleren en ervoor te zorgen dat het netwerk blijft groeien en evolueren.