Ethereum-Kernentwickler streiten über den Prozess, Fusaka-Zeitplan

Das jüngste All Core Devs Meeting von Ethereum beschäftigte sich nicht nur mit dem Code, sondern auch mit dem Prozess: Es ging darum, ob das zuvor angekündigte 30-Tage-Fenster zwischen Client-Releases und dem ersten Testnet-Fork im Zuge des Fortschreitens des Fusaka-Upgrades eingehalten werden soll. Einige Teilnehmer drängten darauf, das Versprechen zu bekräftigen, damit Infrastruktur- und App-Teams genügend Zeit zur Anpassung haben; andere plädierten für Flexibilität, um Verzögerungen im Gesamtfahrplan zu vermeiden.

Die Debatte fand vor dem Hintergrund gemischter Devnet-Ergebnisse statt. Auf Devnet-3 dauerte eine geplante Non-Finality-Übung länger als erwartet, wie Barnabas Busa vom Dev Ops Team berichtete. „Wir wollten zunächst etwa zwei Tage durchführen, und jetzt sind wir am fünften Tag“, sagte er und wies darauf hin, dass die Teilnahme zunächst zurückging und dann wieder über 50% stieg. Für die Finalität ist erforderlich, dass mehr als zwei Drittel des gesamten effektiven Stakes zustimmen.

Im Gegensatz dazu erholte sich ein separates Testnet nach einem koordinierten Neustart schnell: „Die Chain hat sich, ich glaube, innerhalb von zwei Stunden erholt“, sagte Busa. Die Übung testet, wie Variablen in einem Live-Vorfall interagieren, was Ethereum in einer Krise helfen kann, sich zu erholen.

Mehr lesen: Das Fusaka-Upgrade von Ethereum könnte sich verzögern

Mit anstehenden Fixes in den kommenden Tagen besteht der kurzfristige Plan darin, Devnet-3 wieder vollständig funktionsfähig zu machen, den Test erneut durchzuführen und dann Devnet-5 zu starten.

Der größere Streitpunkt war jedoch die Disziplin bei der Terminplanung für öffentliche Netzwerke. Lightclient betonte das bestehende Versprechen: „Es steht geschrieben, 30 Tage vor dem ersten Testnet.“ Er warnte davor, die Zielvorgaben aus Bequemlichkeit zu verschieben, basierend auf der Einschätzung der Core Devs, wie viel Zeit andere Teams, die nicht am Call teilnehmen, benötigen.

Das praktische Anliegen ist, wie man die Kadenz von Hard Forks verbessern kann. Das Komprimieren der Abstände zwischen den Tests kann Forks beschleunigen, erhöht jedoch das Risiko, dass nachgelagerte Teams überstürzte Updates veröffentlichen. Das Gegenargument ist, dass verlängerte Pipelines alles andere in der Warteschlange verzögern, was der breiteren Ethereum-Community missfallen könnte.

„Ich denke nicht, dass wir Zeitpläne danach auswählen sollten, was die Community unbedingt will“, sagte Lightclient. „Diejenigen, die die Software ausliefern, haben gesagt, dass sie 30 Tage benötigen, um hochwertige Software zu liefern, die die Community nutzen wird.“

Trotzdem driftete der teils angespannte Austausch dahin, den schriftlich festgelegten Prozess einzuhalten, es sei denn, die Stakeholder fordern ausdrücklich eine Änderung.

Es gab auch Frustration darüber, dass dieselbe Frage in jedem Zyklus erneut aufgeworfen wird. „Ich denke einfach, es ist ein wirklich schlechtes Präzedenzfall, Entscheidungen ständig zu ändern“, sagte Lightclient und wies darauf hin, dass App-Entwickler und L2s normalerweise nicht an den Core Calls teilnehmen und auf vorhersehbare Zeitfenster angewiesen sind, um ihre eigenen Releases zu planen.

Derzeit besteht der Konsens darin, so vorzugehen, als ob das 30-Tage-Puffer weiterhin gilt, während gleichzeitig proaktiv neue Rückmeldungen eingeholt werden, sagte Koordinator Tim Beiko. „Wir sollten den Zeitplan gemäß dem [Prozess-]Dokument vorbereiten und parallel mit den betroffenen Stakeholdern Rücksprache halten.“ Wenn eine schnellere Vorgehensweise tatsächlich breite Unterstützung findet, würde die Gruppe dies schriftlich formalisieren.