-
Els clients de la capa d’execució van ometre incloure l’adreça correcta del contracte de dipòsit.
-
Horesky ha estat inactiu durant almenys 7 hores.
La xarxa de proves d’Ethereum Holsky La xarxa no va arribar a l’Estat de la Finalitat “en què les transaccions es consoliden com a immutables i irreversibles a la xarxa.
En el moment d’aquest article, Horsky porta Almenys set hores inactives i sense blocs de processamentcom es veu a la imatge següent:
L’experiència en aquesta xarxa de proves d’Ethereum reforça la importància d’aquestes fases experimentals, permetent que es detectin i corregeixin els fracassos Sense comprometre l’estabilitat de la cadena principal.
Què va ser la Falla a la xarxa de proves Ethereum?
Georgios Konstantopoulos, CTO de paradigma, va explicar que la fallada es va originar en un error dins d’alguns clients de la capa d’execució (Capa d’execució, EL)). Segons les seves declaracions, aquests clients Van ometre incloure la direcció correcta del contracte de dipòsitun component que pren rellevància amb la PEIN pel seu impacte en el càlcul del hash de les aplicacions.
Aquest hash és essencial per processar operacions com ara dipòsits i retirades, funcions que l’actualització transfereix de la capa de consens (Cl) a la capa d’execució.
Konstantopoulos va dir que, tot i que l’error era senzill de detectar, va afectar el rendiment d’alguns clients a Horsky. Tot i això, va subratllar que equips com Reth i Eregon, dues implementacions dels clients, van treballar correctament durant la prova.
Ethereum té una estructura composta per diferents capes, a més de: Capa de consens (Capa de consens), Capa d’aplicació (Capa d’aplicació), Capa de disponibilitat de dades (Capa de disponibilitat de dades), Capa de xarxa (Gorra vermella) e Capa d’infraestructura (Capa d’infraestructura).
Aquesta arquitectura multicapa permet distribuir les funcions clau de la xarxa en diferents estrats, optimitzant el seu rendiment general sense comprometre la seva integritat.
Els clients han de gestionar el contracte de dipòsit
En una resposta que complementa aquesta explicació, Timbeiko.eth, un destacat desenvolupador de l’ecosistema Ethereum, va aprofundir en el context tècnic del problema.
Abans de Pein, els clients d’execució no necessitaven reconèixer la rellevància especial del contracte de dipòsit, ja que la capa de consens era responsable de llegir -lo directament. Això va canviar amb Sirty: Ara, els dipòsits es poden iniciar per la capa d’execució sense el retard de 2048 blocs implementats en l’època pre-menys per mitigar les reorganitzacions de la prova de treball (POW).
Com a resultat, el Els clients han de gestionar directament el contracte de dipòsitque exigeix que la vostra adreça estigui configurada correctament.
La sentència a Horsky, segons Timbeiko.eth, es va desencadenar perquè les adreces del contracte de dipòsit en aquesta xarxa de proves, així com a Sepolia, difereixen dels que s’utilitzen a la xarxa principal d’Ethereum. Alguns clients no van actualitzar aquesta adreça per reflectir les especificitats de Horesky, cosa que va provocar incoherències en les verificacions de hash i, per tant, va evitar que la xarxa arribés a la finalitat.
Tot i que Timbeiko.eth va admetre no saber per què les adreces són diferents entre les xarxes, va subratllar que aquest tipus de discrepàncies formen part dels reptes que es plantegen quan es tracta de les actualitzacions en entorns controlats.
L’ecosistema Ethereum espera Sirty
L’actualització de PECTRA introdueix canvis importants, com en l’establiment, en la interacció dels EOA (comptes controlats externament) i els comptes de contracte intel·ligents i la possibilitat de activeu els dipòsits directament des de la capa d’execucióa part d’altres millores. Tanmateix, la seva implementació requereix que tots els clients estiguin alineats amb noves especificacions, cosa que no va passar uniformement en aquesta ocasió.
La diferència en les indicacions del contracte de dipòsit entre la xarxa principal i els testNets, combinada amb una configuració inadequada en alguns clients, va presentar una vulnerabilitat que ara s’està abordant.
El següent pas per als desenvolupadors serà ajustar aquests errors abans de la següent prova programada a Sepolia, prevista per al 5 de març de 2025 i més endavant a la xarxa principal d’Ethereum, el 8 d’abril.
