1/ 💡 Ethereum-aktivert BPO2! Denne parameter-only endringen økte blobs datakapasitet per blokk: ▫️ Blob-mål 10→14 ▫️ blob max 15→21 Denne oppgraderingen påvirker kostnader for datatilgjengelighet og gebyrvolatilitet ved å øke blobspace-headroom og redusere overbelastningsdrevne topper. 🧵 Les videre for hva som har endret seg og hvorfor det er viktig

2/ Denne oppgraderingen legger til mer blobspace per blokk → mindre press på blob fee-markedet. Med mer blobspace er det mindre sjanse for kø i blob fee-markedet, noe som reduserer kraftige prisstigninger. Det er ikke automatisk billigere, men mindre sannsynlig å oppleve mangel, noe som resulterer i lavere gjennomsnittskostnader og mindre volatilitet når sammenrullinger konkurrerer om dataplass.

3/ Rask definisjon: blobs er datapakker introdusert med EIP-4844 (proto-danksharding) for tilgjengelighet av sammenrullede data. ​ De er ikke EVM-samtaledata; De opererer i en egen datakanal med eget gebyrmarked.

4/ Hvorfor blob eksisterer: rollups må publisere batches til Ethereum for å arve L1-sikkerhet/verifisering. ​ Blobs gjør den publiseringen billigere/mer effektiv enn å presse alt gjennom calldata.

5/ BPO2 økte blobkapasiteten fra 10 → 14 og grensen fra 15 → 21, og muliggjorde: ✅ Reduserer sjansen for at blobspace når per-blokk-taket → færre gebyrtopper ved toppetterspørsel ✅ Gjør batchpublisering mer forutsigbar (bedre timing + kostnadsprognoser) ✅ Øker tilgjengelig DA-gjennomstrømning, slik at L2-er kan publisere mer data når det trengs ✅ Reduserer «rollups som konkurrerer om samme rør» under aktivitetsutbrudd ✅ Flytter de første onchain-signalene å følge med på: blob base fee, utilization vs target, og prosentblokker som når blob-maks

6/ På samme etterspørselsnivå er det vanskeligere å nå blobspace-overbelastning, så blob base fee-topper bør være mindre hyppige/mindre ekstreme. ​ Det forbedrer forutsigbarheten for sammenrullinger som planlegger batch-publisering.

7/ BPO2 er en nøkkelkomponent i Ethereums skaleringsveikart, i tråd med planen etter Fusaka om å øke blob-gjennomstrømningen gjennom planlagte BPO-parametersteg. Dette bekrefter retningen som tidligere oppgraderinger har etablert mot å oppnå full danksharding. ​ Hvis du driver L2-infrastruktur, ble DA-kostnadsprognoser og batchstrategi nettopp mer følsomme for blob-parametere.