Den andre Blob Parameters Only (BPO)-forgreningen skjedde i dag. BPO #2 var neste planlagte steg i Fusakas oppgraderingssyklus for å skalere Ethereums datakapasitet. Her er det du trenger å vite om BPO #2, og hvorfor disse parameterjusteringene er viktige.

0/ Hva er en BPO-fork? "Kun blob-parametere"-forgreininger er en ny mekanisme introdusert i den siste Fusaka-oppgraderingen. I stedet for å vente på en stor årlig oppgradering for å justere nettverkskapasiteten, lar BPO-forks Ethereum tune spesifikke parametere (som blob-mål) uavhengig og effektivt.

1/ Hva endret seg med BPO-gaffelen? BPO #2 justerte blob-grensene for å støtte mer datagjennomstrømning: ↗ Målklumper: økt til 14 (fra 10) ↗ Maks blobs: økt til 21 (fra 15) Denne gradvise opptrappingen gjør det mulig for nettverket å trygt teste økt belastning steg for steg. BPO #2 er den siste av BPO-forkene som var planlagt som en del av Ethereums Fusaka-oppgradering. Med mål om å fortsette å øke nettverkets kapasitet, vil BPO-forks fortsatt bli brukt som et verktøy for løpende, datadrevet skalering.

2/ Hvorfor BPO-forken er viktig Flere blobs = mer datatilgjengelighet for lag 2-nettverk. Ved å øke grensene for blob per blokk gradvis, reduserer Ethereum datakostnadene for sammenrullinger. Dette bidrar til å holde transaksjonsgebyrene på L2-er lave selv når aktiviteten øker, og sikrer at nettverket skalerer bærekraftig med etterspørselen.

3/ For nodeoperatører Kunder som er klare for Fusaka bør ha disse BPO-planene innebygd i huset. Det er alltid god praksis å dobbeltsjekke utgivelsesnotatene dine.