Ethereum Entwickler haben den Zeitplan für die anstehenden Netzwerk-Upgrades finalisiert. Wichtige Änderungen werden am 24. Februar, 5. März und 8. April in Kraft treten. Die wichtigsten Entscheidungen wurden während des kürzlich abgehaltenen ACDE-Calls 205 (All Core Developers Execution) am 13. Februar 2025 getroffen.
Die zweiwöchentlichen Zoom-Meetings wurden geleitet Ethereum . Die Entwickler bestätigten, dass das Pectra-Upgrade am 24. Februar im Holesky-Testnetz aktiviert wird. Anschließend wird das Sepolia-Testnetz am 5. März in Betrieb genommen.
Wenn beide Rollouts reibungslos verlaufen, wird das Ethereum-Mainnet das Upgrade um den 8. April erhalten.
Beiko sagte, er werde sich mit den Teams abstimmen, um einen Freiwilligen für die Bereitstellung der Pectra-tracin beiden Testnetzen zu finden.
Debatten über zukünftige Ethereum Forks und die Upgrade-Geschwindigkeit
Darüber hinaus besprach das Entwicklerteam das nächste geplante Upgrade nach Pectra und Fusaka. Beiko schlug vor, den Umfang von Fusaka bis zum Start von Pectra im Hauptnetz festzulegen.
Der Zeitplan ermöglicht es den Entwicklern, mit der Arbeit an Fusaka zu beginnen und gleichzeitig den nachfolgenden Hardfork Glamsterdam zu planen.
Das Geth-Entwicklungsteam lehnt diesen Zeitplan ab. Es argumentiert, dass die Festlegung des Umfangs von Fusaka verfrüht gewesen sei. Die Einbeziehung des Ethereum Improvement Proposal (EIP) EOF in Fusaka hat erhebliche Diskussionen ausgelöst. Ein Teil der Entwickler plädiert für dessen Ausschluss aus dem bevorstehenden Upgrade.
EOF (Ethereum Object Format) ist ein Upgrade , das darauf abzielt, dietracStrukturierung und Ausführung von Smart Contracts auf der Ethereum Blockchain zu verbessern.
Der Geth-Entwickler Lightclient sprach sich gegen eine Beschleunigung des Fusaka-Scope-Freezes aus. Er argumentiert, dass Ethereumin den nächsten zwei Jahren verschieben könnten. Er wies darauf hin, dass Entwickler zwar sechsmonatige Upgrade-Zyklen anstreben, Verzögerungen in der Praxis diese jedoch auf acht Monate oder länger ausdehnen könnten. Dies bedeutet, dass wichtige Verbesserungen möglicherweise erst nach Jahren implementiert werden.
Lightclient äußerte Bedenken hinsichtlich der Integration von EOF und hob die rasante Entwicklung der Zero-Knowledge-Rollup-Technologie (zkEVMs) von Ethereumhervor. Entwickler tappen weiterhin im Dunkeln, was das Zusammenspiel dieser Änderungen mit der virtuellen Maschine betrifft.
Im Verlauf der Diskussion listete Geth-Entwickler Marius van der Wijden seinen bevorzugten Umfang für Fusaka auf, der PeerDAS, FOCIL, EOF und Obergrenzen für modexp umfasste. EF-Entwickler und Betriebsingenieur Parithosh Jayanthi widersprach und erklärte, dass FOCIL noch nicht so weit für die Implementierung bereit sei wie PeerDAS und EOF.
Pectra Software-Testnetz-Upgrades und Community-Feedback
Die Entwickler legten ihre Meinungsverschiedenheiten bezüglich Fusaka bei und zeigten sich zuversichtlich hinsichtlich der laufenden Pectra-Implementierung. Parithosh Jayanthi, Entwicklungs- und Betriebsingenieur bei EF, berichtete, dass Pectra Devnet 6 gut funktioniere und eine nahezu perfekte Beteiligung der Validatoren aufweise.
Darüber hinaus aktivierte das Ephemery-Testnetz von Ethereumwenige Stunden nach dem ACDE-Aufruf das Pectra-Upgrade, wodurch die Entwickler weitere Tests durchführen konnten.
in die „Letzte-Aufruf“-Phase zu verschieben GitHub. Dies markiert die letzten Schritte vor der Implementierung im Mainnet. Er berücksichtigte auch das Feedback der Ethereum Community. Dabei stellte er fest, dass die häufigste Forderung die Beschleunigung der Upgrade-Zyklen war.
Als Antwort darauf schlug er vor, dass Ethereum Entwickler den Umfang jedes Upgrades so bald wie möglich festlegen sollten, sobald das vorherige im Hauptnetz live geht.
Beikos vorgeschlagener Zeitplan für die Festlegung des Fusaka-Umfangs sieht vor, dass Entwickler bis zum 13. März EIPs (Engineering Improvement Plans) für das Upgrade vorschlagen müssen. Zwei Wochen später, am 27. März, teilen die Kundenteams ihre Präferenzen bezüglich der für Fusaka zu berücksichtigenden EIPs mit. Bis zum 10. April wird der Umfang des Upgrades schließlich finalisiert.
EF-Forscher Ansgar Dietrichs fügte jedoch eine Ausnahme bezüglich des Zeitplans hinzu. Er merkte an, dass die Codeverbesserungen von PeerDAS, ein kritischer Bestandteil des Pectra-Upgrades, nach ihrer Fertigstellung umgehend in das Ethereum Mainnet hochgeladen werden sollten. Niemand erhob Einspruch gegen diese Forderung.
Bedenken hinsichtlich der EELS- und EIP-Prüfstandards
Ein weiterer Kritikpunkt während der ACDE-Konferenz war ein Vorschlag von EF-Testingenieur Mario Vega. Dieser bezog sich auf das Testframework der Ethereum Ausführungsschicht. Vega schlug vor, EELS (Ethereum Execution Layer Specifications) und EEST (Ethereum Execution Specification Test Cases) für alle EIPs, die in einen Hard Fork einbezogen werden, verpflichtend zu machen.
Er schlug vor, dass dies den Testablauf verbessern und die Art und Weise, wie EIPs vor ihrer Einführung bewertet werden, standardisieren würde.
Mehrere Entwickler sprachen sich jedoch gegen den Vorschlag aus. Der Grund? Die Anforderung könnte den Aktualisierungsprozess verlangsamen. Van der Wijden argumentierte, dass die EELS-Maintainer dadurch faktisch zu den Gatekeepern für die EIP-Aufnahme werden könnten. Warum? Nicht alle Entwickler sind in der Lage, Python-basierte Implementierungen ihrer Vorschläge zu schreiben.
Wijden schlug einen alternativen Ansatz vor. Die ETH sollte EELS-Implementierungen , die als nicht zusammengeführte Pull-Requests eingereicht werden können. Dadurch wird verhindert, dass das EELS-Team die endgültige Genehmigung von Aktualisierungen erhält.
Justin Florentine vom Ethereum Client Besu empfahl der Community, die Entwicklung einer zusätzlichen Skriptsprache in Erwägung zu ziehen. Dies würde klären, ob ein EIP ohne EELS- oder EEST-Testfälle eingebunden werden kann.
