Fusaka, l’última actualització d’Ethereum, està operativa a la xarxa des del 3 de desembre. Amb ell, aquest ecosistema va rebre el seu segon forquilla dura (forquilla dura) de l’any, després de Pectra al maig.
Segons informa CriptoNoticias, la proposta coneguda com PeerDAS és la millora més rellevant de Fusaka i va portar a la xarxa quelcom que el mateix Vitalik Buterin esperava des del 2015.
PeerDAS introdueix un sistema per verificar la disponibilitat de dades fent mostres entre nodes. En lloc de que cada node hagi de descarregar tots els fitxers taques complete (espai on les xarxes de segona capa emmagatzemen informació), ara només sol·licita petites mostres aleatòries de diferents companys.
El gràfic següent, fet hores després del llançament de Fusaka, reflecteix PeerDAS funcionant com es pretén:
A la imatge, un node situat a Finlàndia (“tysm”) demana a la xarxa algunes columnes de dades corresponent a taques utilitzat per Base i Arbitrum.
Aquest node en particular no té aquestes mostres emmagatzemades, de manera que apareix el missatge “MISSING”. Això és normal a PeerDAS: els nodes ja no necessiten desar totes les dades per comprovar-ne la disponibilitat.
En canvi, el node consulta altres companys (en aquest cas, un node a Taiwan). Aquests companys tenen aquestes columnes i les envien en menys de mig segon.
D’aquesta manera, la xarxa confirma que les dades associades estan disponiblesfins i tot quan no es reprodueixen completament a cada node.
Aquest comportament reflecteix exactament l’objectiu de PeerDAS a Ethereum: reduir la càrrega de l’emmagatzematge individual alhora que garanteix que la informació segueixi sent accessible per a aquells que la necessitin.
Les xarxes de segona capa d’Ethereum publiquen més dades en forma de taques
El següent gràfic «Recompte mitjà de blobs per bloc» (mitjana de taques per bloc) mostra el evolució del nombre mitjà de taques per bloc.
La línia negra puja des d’un “4” (eix esquerre) fins a acostar-se a l’objectiu marcat “6” taques per bloc (horitzó horitzontal).
Això indica que, després de Fusaka, la xarxa va començar a utilitzar més espai taques en els blocs, apropant-se a l’objectiu definit per a aquest paràmetre.
En termes senzills: Els L2 van començar a publicar més dades en forma de taquesi PeerDAS comença a exercir el seu paper de comprovar aquest augment del trànsit.
Per què és útil per a L2? Perquè repartint i distribuint la càrrega entre molts nodes, el sistema permet que les capes dues publiquin més dades sense dependre de cada node d’Ethereum per descarregar-ho i verificar-ho completament.
Això redueix els costos operatius, millora la velocitat amb què es processen els lots i permet L2 continua escalant sense imposar una càrrega creixent a la xarxa base.
A més, el que mostra aquest gràfic és només el començament d’una seqüència planificada d’expansions, així que aquest efecte augmentarà en el futur.
Partint de la proposta EIP-7892, que proposa una sèrie d’actualitzacions graduals que ajusten exclusivament el límit de taques, El 9 de desembre, a forquilla què augmentarà l’objectiu actual de taques de 6 a 10i el 7 de gener de l’any vinent un altre forquilla Et portarà de 10 a 14 hores.
Taxa taques: el pic i la correcció després de Fusaka
Hores abans de l’arribada de Fusaka, la xarxa va gravar a pic abrupte al tarifes de blobs les tarifes que paguen els L2 per publicar les seves dades a Ethereum mitjançant el taques.
Segons el gràfic següent, aquesta tarifa va assolir uns 1.463 gwei (unitat mínima d’èter utilitzada per expressar tarifes a Ethereum), equivalent a uns 0,0047 dòlars actualment:
Fins a la integració de Fusaka, el pis de la tarifes de blobs Era pràcticament simbòlic. El mínim possible es va establir en 0,000000001 Gwei i es va mantenir allà mentre no hi hagués congestió.
Aquest pis estàtic conduïa al L2 publicarà dades a Ethereum gairebé gratuïtament el 99% del tempsfins i tot quan la seva activitat generava un cost real per a la xarxa.
Amb l’activació de Fusaka i, en particular, de l’EIP-7918, aquest “piso” tarifari de la taques Es va deixar d’arreglar i Es va passar a un sistema dinàmic vinculat al cost real d’operació a L1.
La paraula de les comissions de la taques es va quedar al voltant de la a setze (1/16) de la tarifa base d’Ethereumsegons el text de l’EIP-7918.
Això és el que el pis dinàmic de la tarifes de blobs tras Fusaka:
Tenint en compte els nivells habituals d’ús d’Ethereum, el sistema establert per EIP-7918 situa el mínim de tarifes de blobs en valors que solen estar entre 0,01 i 0,5 gwei (és a dir, entre desenes i centenars de milions de vegades més amunt a partir de l’antic mínim d’1 wei). A diferència de l’esquema anterior, ja no pot baixar a zero.
A més, aquesta nova tarifa mínima té un efecte directe sobre l’economia d’Ethereum: cobrant un mínim realista per taquesla xarxa deixa de subvencionar la seva verificació i Comença a generar més ingressos per comissions.
D’altra banda, i per a l’usuari final, l’impacte és gairebé imperceptible: les comissions en L2 encara són molt baixes, perquè aquests costos es dilueixen entre milions de transaccions.
Límit de gas per bloc: més capacitat de dades
A partir de l’EIP-7935, després de Fusaka, els clients d’Ethereum funcionen per defecte amb un límit de gas per bloc de 60 milions. Això implica un creixement del 100% respecte als 30 milions que utilitzaven la xarxa a principis del 2025.
El “límit de gas” defineix quant treball computacional o espai de transacció es pot incloure en un bloc. A banda de Fusaka, el límit de gas és una mesura pactada pels validadors, que es pot augmentar o baixar.
El fet d’elevar-lo a 60 milions permet mantenir més transaccions per bloc, cosa que facilita que la xarxa admeti una càrrega més gran sense congestió immediata.
El programari de consens Ethereum es va estavellar després de Fusaka
Finalment, hores després de la posada en marxa de Fusaka, el client de consens Prysm (un dels programes utilitzats pels nodes per coordinar la cadena) va patir un error. Ell mateix va marxar temporalment fora de joc sobre 23% de la xarxa.
Pel que van comunicar des de Prysm, no hi ha indicis que el fracàs va ser causat per Fusaka.
L’equip de Prysm va identificar el problema i va publicar una solució senzilla que qualsevol operador podia implementar en qüestió de minuts afegint una línia de codi al seu node, sense necessitat de descarregar una nova versió.
Gràcies a això, la xarxa va continuar funcionant sense grans conseqüències.
