Els desenvolupadors d’Ethereum han finalitzat la programació per a les properes actualitzacions de xarxa. Es preveu que es produeixin canvis importants el 24 de febrer, el 5 de març i el 8 d’abril. Les decisions clau es van finalitzar durant la recent trucada de tots els desenvolupadors de Core Developers (ACDE), celebrada el 13 de febrer de 2025.
La reunió de zoom bi-setmanal discussió van ser dirigits pel protocol del protocol de la Fundació Ethereum (EF) Tim Beiko. Els desenvolupadors van confirmar que l’actualització de Pectra s’activaria al Testnet Horsky el 24 de febrer. Després el Testnet de Sepolia augmentarà el 5 de març.
Si els dos llançaments procedeixen sense problemes, el mainnet d’Ethereum rebrà l’actualització cap al 8 d’abril.
Beiko va dir que es coordinaria amb els equips per trobar un voluntari per desplegar contractes del sistema PECTRA a les dues proves.
Debats sobre les futures forquilles Ethereum i la velocitat d’actualització
A més, l’equip de desenvolupadors va discutir la propera actualització prevista després de Pectra i Fusaka. Beiko proposat La congelació de l’abast de Fusaka quan Pectra es llança a la mainnet.
La línia de temps permet als desenvolupadors començar a treballar a Fusaka mentre també planifiquen el posterior glamsterdam de Hardfork.
L’equip de desenvolupament de Geth no vol treballar amb aquest calendari. Argumenten que era prematur cimentar l’abast de Fusaka. La inclusió de la proposta de millora de Ethereum (EIP) a Fusaka ha provocat un debat considerable. Una facció de desenvolupadors defensa la seva exclusió de la propera actualització.
EOF (format d’objecte Ethereum) és un actualització Té com a objectiu millorar la forma en què s’estructuren i s’executen els contractes intel·ligents a la blockchain Ethereum.
El desenvolupador de Geth LightClient es va oposar a la velocitat de la congelació de l’abast de Fusaka. El desenvolupador argumenta que les prioritats d’Ethereum podrien canviar durant els pròxims dos anys. Va assenyalar que, mentre que els desenvolupadors apunten a cicles d’actualització de sis mesos, els retards del món real podrien estirar-los a vuit mesos o més. Això significa que es podrien implementar millores importants durant anys.
LightClient va plantejar les preocupacions sobre la incorporació de EOF, destacant el ràpid progrés de la tecnologia de rotlle de coneixement zero de Ethereum (ZKEVMS). Els desenvolupadors es mantenen a les fosques pel que fa a la interacció d’aquests canvis amb la màquina virtual.
Durant la discussió, el desenvolupador de Geth, Marius Van Der Wijden, va enumerar el seu àmbit preferit per a Fusaka, que incloïa Peerdas, Focil, EOF i límits superiors per a ModExP. L’enginyer d’operacions del desenvolupador d’EF, Parithosh Jayanthi, va tornar a declarar que Focil no estava tan preparat per a la seva implementació com Peerdas i EOF.
PECTRA Software TestNet actualitzacions i comentaris de la comunitat
Els Devs van passar per davant dels seus desacords sobre Fusaka per expressar confiança en el continu Desplegament de Pectra. L’enginyer de desenvolupament i operacions d’EF, Parithosh Jayanthi, va informar que Pectra Devnet 6 estava bé, amb taxes de participació del validador gairebé perfectes.
Addicionalment, el Testnet d’efemiry d’Ethereum va activar l’actualització de Pectra poques hores després de la trucada ACDE, permetent als desenvolupadors realitzar proves posteriors.
Beiko va demanar als autors de Pectra EIP que traslladessin les seves propostes a la fase de “darrera trucada” Girub. Això indica els passos finals abans de la implementació de Mainnet. També va estudiar els comentaris de la comunitat Ethereum. Amb aquesta finalitat, va assenyalar que la sol·licitud més comuna era accelerar els cicles d’actualització.
Com a resposta, va suggerir que els desenvolupadors d’Ethereum haurien de finalitzar l’abast de cada actualització tan aviat com l’anterior es posi en directe a la mainnet.
El calendari proposat per Beiko per finalitzar l’àmbit de Fusaka afirma que, el 13 de març, els desenvolupadors han de proposar EIP per a la seva inclusió en l’actualització. Dues setmanes després, el 27 de març, els equips de clients compartiran les seves preferències sobre les quals s’haurien de considerar EIPS per a Fusaka. Finalment, el 10 d’abril es finalitzarà l’abast de l’actualització.
Tot i això, l’investigador EF Ansgar Dietrichs va afegir una excepció al calendari. Va assenyalar que les millores del codi de Peerdas, un component crític de l’actualització de Pectra, s’hauria de penjar a l’Ethereum Mainnet tan aviat com estiguin complets. Ningú no es va oposar a aquest requisit.
Preocupacions sobre els estàndards de proves de les anguiles i EIP
Un altre punt de preocupació durant la trucada ACDE va ser una proposta de l’enginyer de proves d’EF Mario Vega. Això va arribar al marc de proves de capa d’execució Ethereum. VEGA va suggerir que es fes que les EELs (especificacions de la capa d’execució d’Ethereum) i els casos de prova de l’especificació d’execució d’ETHEREUM) siguin obligatoris per a qualsevol EIP inclòs en una forquilla dura.
Va suggerir que això millorarà el flux de treball de prova i normalitzaria com s’avaluen els EIP abans de l’adopció.
Tot i això, diversos desenvolupadors van estar en contra de la proposta. El motiu? El requisit podria alentir el procés d’actualització. Van der Wijden va argumentar que els mantenidors de les anguiles podrien convertir -se en els porters de facto de la inclusió de l’EIP. Per què? No tots els desenvolupadors són capaços d’escriure implementacions basades en Python de les seves propostes.
Wijden va suggerir un enfocament alternatiu. ETH hauria de tenir Implementacions de les anguiles Es podria presentar com a sol·licituds de tirada no fixa. D’aquesta manera s’evita que l’equip de les EEL tingui el poder d’aprovació final de les actualitzacions.
Justin Florentine amb el client Ethereum Besu va aconsellar a la comunitat que es plantegi crear un llenguatge addicional de script. Això aclariria si es pot incloure un EIP sense casos de prova de licucions o EEST.
