NEUESTE NACHRICHTEN
FÜR SIE AUSGEWÄHLT
WÖCHENTLICH
BLEIBEN SIE AN DER SPITZE

Die besten Krypto-Einblicke direkt in Ihren Posteingang.

Ethereum ACDE-Call 205: Wichtige Ethereum Upgrades am 24. Februar, 5. März und 8. April

VonFlorence MuchaiFlorence Muchai
3 Minuten Lesezeit
 Ethereum ACDE-Call 205: Wichtige Ethereum Upgrades am 24. Februar, 5. März und 8. April
  • Das Pectra-Upgrade von Ethereumist für den 24. Februar im Holesky-Testnetz geplant, die Einführung im Hauptnetz wird bis zum 8. April 2025 erwartet.
  • Es wurden Meinungsverschiedenheiten über den Zeitplan für das Fusaka-Upgrade und die Einbeziehung von EIP EOF diskutiert, wobei die Geth-Entwickler mehr Flexibilität forderten.
  • Es wurden Bedenken hinsichtlich der obligatorischen EELS- und EEST-Tests für EIPs geäußert, da einige Entwickler Verzögerungen im Upgrade-Prozess befürchteten.

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.

Beiko forderte die Autoren des Pectra EIP auf, ihre Vorschläge auf GitHub in die „Letzte-Aufruf“-Phase zu verschieben . 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. 

Wenn Sie das hier lesen, sind Sie schon einen Schritt voraus. Bleiben Sie mit unserem Newsletter auf dem Laufenden.

Diesen Artikel teilen

Haftungsausschluss. Die bereitgestellten Informationen stellen keine Anlageberatung dar. Cryptopolitan/ übernimmt keine Haftung für Investitionen, die auf Grundlage der Informationen auf dieser Seite getätigt werden. Wirtronempfehlen dringend, vor jeder Anlageentscheidung eigene Recherchen durchzuführendent oder einen qualifizierten Fachmann zu konsultieren

Florence Muchai

Florence Muchai

Florence berichtet seit sechs Jahren über Krypto, Gaming, Technologie und KI. Ihr Informatikstudium an der Meru University of Science and Technology sowie ihr Studium des Katastrophenmanagements und der internationalen Diplomatie an der MMUST haben ihr fundierte Sprachkenntnisse, Beobachtungsgabe und technisches Know-how vermittelt. Florence arbeitete bereits für die VAP Group und als Redakteurin für verschiedene Krypto-Medien.

MEHR … NACHRICHTEN
DEEP CRYPTO
CRASH-KURS