Optimalisatie van Ethereum-gaskosten: Hoe Proto-Danksharding de L2-transactiekosten heeft hervormd

De grote verandering voor L2-gebruikers was niet een algemene verlaging van de Ethereum-gasfees. Het was een goedkopere, tijdelijke dataverbinding voor rollups. De Dencun-upgrade van Ethereum activeerde proto-danksharding via EIP-4844 op 13 maart 2024. Rollups konden vervolgens batches publiceren met behulp van blobs – tijdelijke datacontainers met een aparte transactiemarkt – in plaats van alleen te vertrouwen op permanent opgeslagen calldata. Deze verandering verlaagde een belangrijke kostenpost voor L2's die blobs gebruikten, maar maakte niet elke L2-transactie op elk moment goedkoop.

De huidige context is van belang. De latere Fusaka-upgrade van Ethereum bracht PeerDAS in december 2025 naar het mainnet, waarmee dezelfde roadmap voor data-beschikbaarheid werd bevorderd door het mogelijk te maken de blob-doorvoer efficiënter op te schalen. Voor gebruikers van vandaag is de praktische les dat L2-kosten afhangen van meer dan één "gasprijs": een L2 moet betalen voor zijn eigen uitvoering en voor het publiceren van data of bewijzen naar Ethereum, terwijl de vraag naar blob-ruimte en het tariefbeleid van elke L2 de uiteindelijke prijs kunnen beïnvloeden.

Wat veranderde er met proto-danksharding?

Vóór EIP-4844 plaatste een rollup doorgaans transactiegegevens naar Ethereum als calldata. Calldata maakt deel uit van de transactie-input van Ethereum en blijft beschikbaar als onderdeel van de blockchaingeschiedenis. Die permanentie is waardevol, maar maakt het gebruik van deze gegevens op grote schaal kostbaar voor rollups.

EIP-4844 introduceerde een nieuw transactietype, vaak een blob-carrying transactie genoemd. Een blob bevat data die gedurende een beperkte periode beschikbaar wordt gesteld aan het netwerk, in plaats van te worden uitgevoerd door de Ethereum Virtual Machine of permanent te worden opgeslagen zoals calldata. Ethereum.org meldt dat blob-data ongeveer 18 dagen (4096 epochs) beschikbaar zijn voordat ze kunnen worden verwijderd. Deze periode is afgestemd op de beschikbaarheidsbehoeften van rollups, en niet op de algemene, permanente opslag van bestanden.

Het resultaat is een ander economisch traject voor rollup-data. De rollup vindt nog steeds plaats op Ethereum, maar kan gebruikmaken van een speciaal daarvoor ontworpen data-beschikbaarheidsbron in plaats van alleen te concurreren om gewone L1-uitvoerings- en calldata-capaciteit. Lees de Dencun FAQ van Ethereum voor een officieel overzicht van de upgrade en de EIP-4844-specificatie voor het ontwerp van de transactie en de transactiekosten.

Het belangrijkste mechanisme: de kosten voor het transport van grote hoeveelheden gas staan ​​los van de normale gaskosten.

"Gas" wordt vaak gebruikt alsof het één getal is. Na EIP-4844 kan die afkorting verhullen waarvoor een rollup precies betaalt. Blob-transacties hebben de normale Ethereum-uitvoeringskosten plus een aparte maximale vergoeding voor blob-gas. Het protocol hanteert een onafhankelijke basisvergoeding voor blobs die reageert op het blob-gebruik, in plaats van blobs alleen te beprijzen via de normale L1-gasmarkt.

EIP-4844 houdt de prijsbepaling van blobgas bewust gescheiden. De specificatie beschrijft blobgas als onafhankelijk van normaal gas, met een eigen streefwaarde en aanpassingsregel. Dit is de reden waarom een ​​kop over een lage L1-gasprijs niet automatisch aangeeft wat een L2-transactie zal kosten, en waarom een ​​piek in de vraag naar blobgas van belang kan zijn voor roll-ups, zelfs wanneer de gewone L1-activiteit rustig lijkt.

Hoe dat L2-transacties in de praktijk veranderde

Rollups kunnen data op een meer economische manier publiceren.

Rollups voeren veel gebruikerstransacties uit buiten het Ethereum Mainnet en plaatsen vervolgens voldoende informatie op Ethereum zodat de status van de rollup kan worden geverifieerd of betwist volgens het ontwerp. Vóór de introductie van blobs was permanente calldata een belangrijk onderdeel van dat proces. Blobs bieden de rollup een goedkopere manier om gegevens te publiceren die lang genoeg beschikbaar moeten blijven voor het beveiligingsproces van het systeem, maar die niet permanent in de uitvoeringsgeschiedenis van elke node hoeven te worden bewaard.

Voor een L2-server die blobs ondersteunt, kan de besparing worden doorgegeven aan gebruikers, worden behouden in een vergoedingenmodel of gedeeltelijk worden gecompenseerd door andere kosten. De timing en omvang van een eventuele besparing zijn daarom implementatiespecifiek. Ethereum.org merkt expliciet op dat rollup-providers de keuze maken tussen calldata en blobs, over het algemeen gebaseerd op de vraag naar blob-ruimte, en dat de ondersteuningstermijnen en het vergoedingsgedrag per provider kunnen verschillen.

De tarieven werden gevoeliger voor batchverwerking en data-efficiëntie.

Een rollup groepeert doorgaans veel gebruikersacties in een batch voordat ze naar L1 worden verzonden. Door de L1-datakosten over meer transacties te verdelen, kan het aandeel per gebruiker lager worden, terwijl data-intensieve acties een groter aandeel kunnen verbruiken. De details variëren afhankelijk van de rollup-architectuur, de compressiemethode en het sequencerbeleid. Een eenvoudige tokenoverdracht, een contractaanroep met aanzienlijke aanroepdata en een NFT-minting kunnen daarom zeer verschillende kosten opleveren op dezelfde L2-server.

Proto-danksharding heft deze afweging niet op. Het verlaagt de kosten van de data-beschikbaarheidslaag wanneer blobs worden gebruikt; het elimineert echter niet de L2-berekeningen, de complexiteit van smart contracts of de kosten van een schaarse databron tijdens congestie.

Wat proto-danksharding niet veranderde

• Het maakte niet direct elke transactie op het Mainnet goedkoper. De FAQ van Dencun stelt dat EIP-4844 zich primair richt op L2-kosten. Elk effect op de Mainnet-kosten is indirect en hangt af van de acceptatie en de vraag.
• Het maakte de blob-ruimte niet onbeperkt. De blob-capaciteit is beperkt en rollups kunnen calldata gebruiken wanneer er vraag is naar blob-ruimte of wanneer deze niet beschikbaar is tegen een acceptabele prijs.
• Het dwong niet elke L2-server om blobs op dezelfde manier te gebruiken. De sequencer- of rollup-operator beheert doorgaans de keuzes voor het plaatsen en bundelen van gegevens.
• Het heeft blobs niet omgezet in permanente opslag. De inhoud van blobs is tijdelijk; applicaties die duurzame data nodig hebben, moeten een geschikt opslagontwerp gebruiken.
• Het verwijderde geen kosten voor bridges, swaps, protocollen of wallets. Het weergegeven totaalbedrag kan meerdere kostenlagen bevatten bovenop de basiskosten voor de L2-transactie.

Waarom de routekaart na Dencun nog steeds van belang is: PeerDAS

Proto-danksharding was bewust bedoeld als een brug naar schaalbaardere beschikbaarheid van data, niet als de uiteindelijke vorm van sharding. EIP-4844 introduceerde het blob-transactieformaat en een aparte markt voor transactiekosten, terwijl de initiële capaciteit conservatief bleef. In december 2025 introduceerde Fusaka PeerDAS (EIP-7594), een ontwerp voor het bemonsteren van data-beschikbaarheid waarmee knooppunten de beschikbaarheid kunnen verifiëren door data te bemonsteren in plaats van dat elk knooppunt alle blob-data downloadt.

Dit is belangrijk omdat een hogere blob-doorvoer meer rollup-data kan verwerken zonder dat elk knooppunt de volledige last hoeft te dragen. Het verandert niets aan de basisregel voor de gebruiker: een L2-fee blijft dynamisch. De technische verbetering kan de capaciteit verhogen en de druk verlagen, maar het is geen garantie voor een vaste prijs. Zie de aankondiging van de Ethereum Foundation over het Fusaka-mainnet en het officiële PeerDAS-overzicht voor de bevestigde omvang van die upgrade.

Een praktische workflow voor tariefoptimalisatie voor L2-gebruikers

Bij een standaard wallettransactie kun je een blob niet rechtstreeks selecteren; de rollup bepaalt hoe batches worden verwerkt. Je kunt echter wel onnodige kosten verlagen en een route kiezen die het beste bij de transactie past.

1. Identificeer het daadwerkelijke netwerk. Bevestig of de app gebruikmaakt van het Ethereum Mainnet, een specifieke rollup of een andere blockchain. "Ethereum-compatibel" betekent niet dat de app profiteert van de Ethereum blob-ruimte.
2. Lees de kostenspecificatie zorgvuldig door voordat u de overeenkomst bevestigt. Maak onderscheid tussen de L2-netwerkkosten en eventuele applicatie-, bridge-, swap- of protocolkosten.
3. Vergelijk dezelfde actie op verschillende ondersteunde L2-servers. Gebruik alleen de officiële netwerkondersteuning van de app en de actuele koers van de wallet. Een lagere transactiekosten zijn alleen nuttig als de bestemming, liquiditeit, beveiligingsverwachtingen en opnameprocedure aansluiten bij uw gebruiksscenario.
4. Vermijd onnodige, data-intensieve aanroepen. Meerdere goedkeuringen, herhaalde pogingen en complexe contractuele interacties kunnen meer kosten dan een eenvoudige overdracht. Consolideer acties alleen als dit geen groter beveiligings- of uitvoeringsrisico met zich meebrengt.
5. Probeer het niet blindelings opnieuw na een vertraging. Controleer eerst de transactiestatus. Een vervangende of dubbele transactie kan een extra afschrijving of een onbedoelde tweede actie veroorzaken.
6. Houd een kleine buffer aan van het eigen gas op de L2-laag. Als het gas opraakt na het overbruggen of wisselen van gas, kan dit een extra overdracht noodzakelijk maken en de transactie vertragen.
7. Gebruik officiële verkenners en documentatie. Controleer contractadressen, bridge-stappen en netwerkinstellingen voordat u tekent. Een "goedkope" transactie die naar het verkeerde netwerk wordt gestuurd, is geen optimalisatie.

Wanneer een lager weergegeven tarief niet de betere keuze is.

Kostenoptimalisatie is voorwaardelijk. Een goedkope L2-server kan een goede keuze zijn voor een frequente, ondersteunde actie, zoals een applicatie-interactie die binnen dat ecosysteem blijft. Het is mogelijk een minder geschikte keuze als u direct weer een bridge nodig hebt, als de app het bestemmingsnetwerk niet ondersteunt, of als liquiditeits- en opnameregelingen meer kosten en risico's met zich meebrengen dan de initiële kostenbesparing.

Het verplaatsen van activa naar een L2-server met lage transactiekosten voor een kleine swap kan bijvoorbeeld inefficiënt zijn als de kosten voor de bridge, goedkeuringen en retourtransactie hoger zijn dan wanneer de transactie plaatsvindt waar de activa zich al bevinden. Omgekeerd kan een gebruiker die veel ondersteunde transacties uitvoert binnen één L2-ecosysteem meer baat hebben bij lage terugkerende uitvoerings- en datakosten. Vergelijk het volledige traject, niet alleen de eerste gasprijsopgave.

Hoe ontwikkelaars de wijziging moeten interpreteren

Voor rollup-teams verschuift de focus van blobs van "minimaliseer permanente gespreksdata ten koste van alles" naar "gebruik de beschikbare data efficiënt en beheer tegelijkertijd een aparte markt voor blob-kosten". Dit omvat compressie, batchvorming, terugvalgedrag bij stijgende blob-kosten en transparante kostenberekening voor gebruikers. Applicaties moeten vermijden om een ​​permanente kostenverlaging te claimen die uitsluitend gebaseerd is op EIP-4844, omdat de vraag, de implementatie van rollup en toekomstige protocolupgrades variabele factoren blijven.

Voor applicatieontwikkelaars op een L2-server blijft het ontwerp van transacties belangrijk. Het verminderen van onnodige schrijfbewerkingen naar de opslag, calldata, contractaanroepen en mislukte uitvoeringen kan het uitvoeringsgedeelte van de gebruikerskosten verlagen. Dit zijn complementaire optimalisaties: proto-danksharding vermindert met name het L1-dataposting-component van de rollup, terwijl efficiënte contracten het werk aanpakken dat op de L2-server zelf wordt uitgevoerd.

Kortom

Proto-danksharding veranderde de L2-economie door rollups een tijdelijke, apart geprijsde dataverbinding te geven. Daardoor konden veel blob-enabled rollups na Dencun een belangrijke kostenpost voor de afwikkeling verlagen. De latere komst van PeerDAS versterkte de capaciteitskant van dezelfde roadmap, maar geen van beide upgrades maakt de tarieven statisch of garandeert dat elke L2 goedkoper is dan het mainnet voor elke taak.

Voor gebruikers is de beste optimalisatie het kiezen van het juiste netwerk voor het volledige transactiepad, het lezen van de daadwerkelijke kostenopgave, het vermijden van overbodige contractaanroepen en het reserveren van voldoende native gas voor het gebruikte netwerk. Voor ontwikkelaars is de belangrijkste les dat blobbeschikbaarheid, blobkosten, batchverwerking en L2-uitvoering als gerelateerde, maar afzonderlijke onderdelen van het kostenmodel moeten worden beschouwd.