Autorin: Christine Kim
Zusammengestellt von: Luccy, BlockBeats
Anmerkung des Herausgebers: Der All Core Developers Consensus Call (ACDC) von Ethereum findet alle zwei Wochen statt, um Änderungen am Ethereum Consensus Layer (CL) zu diskutieren und zu koordinieren. Dies ist die 134. ACDC-Telefonkonferenz. Auf dieser Konferenz diskutierten Entwickler die Implementierungsdetails und technischen Herausforderungen mehrerer wichtiger EIPs, darunter EIP 7549, EIP 7251, EIP 6110, EIP 7688 usw.
Darüber hinaus diskutierten die Entwickler ausführlich über die Implementierung von PeerDAS, einer Datenverfügbarkeits-Sampling-Technologie, von der erwartet wird, dass sie die Fähigkeit des Ethereum-Netzwerks, Rollups und ihre Datenverfügbarkeitsanforderungen zu unterstützen, erheblich verbessern wird. Während des Treffens wurde vorgeschlagen, Pectra zur Aufrüstung in zwei Hard Forks aufzuteilen, und es wurden Fragen der Aktivierungszeit und der gegenseitigen Abhängigkeiten verschiedener EIPs erörtert.
Christine Kim, Vizepräsidentin für Forschung bei Galaxy Digital, hat die wichtigsten Punkte dieses Treffens im Detail aufgezeichnet und den Originaltext wie folgt zusammengestellt:
Am 30. Mai 2024 trafen sich Ethereum-Entwickler auf Zoom zum Treffen Nr. 134 des All Core Developers Consensus (ACDC). Der ACDC-Aufruf ist eine zweiwöchentliche Reihe, die vom Forscher der Ethereum Foundation, Alex Stokes, moderiert wird und in der Entwickler Änderungen am Ethereum Consensus Layer (CL, auch bekannt als Beacon Chain) diskutieren und koordinieren. Diese Woche diskutieren Entwickler Erfahrungen und offene Probleme seit dem Start von Pectra Devnet 0. Sie diskutierten auch über die Machbarkeit einer Ausweitung des Umfangs des Pectra-Upgrades auf PeerDAS- und SSZ-Containercodeänderungen.
Devnet 0 Rezension
Angesichts der Einführung von Pectra auf Devnet 0 hat das Kundenteam zugestimmt, das von EIP 7549 betroffene Validierungsverhalten während der Hard-Fork-Aktivierung unverändert zu lassen. Bei einem früheren ACDC-Treffen erwogen die Entwickler verschiedene Optionen, um sicherzustellen, dass die Auswirkungen von EIP 7549 nicht zu einer großen Anzahl ungültiger Überprüfungen während der Abspaltung führen würden. Um Upgrades nicht noch komplizierter zu machen, beschloss das Kundenteam, EIP 7549 in derselben Epoche wie andere Pectra-EIPs zu aktivieren, ohne das Validierungsverhalten vor und nach der Abzweigung zu ändern.
In Bezug auf EIP 7251 sind sich die Entwickler immer noch nicht sicher, ob Zusammenführungen von abgesteckten ETH von der Ausführungsschicht (EL) aus ausgelöst werden dürfen. Dies wäre eine ideale Funktion für Stake-Pools wie Lido, sodass die Zusammenführung von Stakes nicht auf Knotenbetreiber angewiesen ist, sondern durch intelligente Verträge erfolgen kann. Stokes empfahl, den Fortschritt der Kunden bei der Implementierung von Validator-Stake-Merges in ein paar Wochen zu überprüfen, bevor sie entscheiden, ob es sich um EL- oder CL-Operationen handeln soll.
Anschließend diskutierten die Entwickler einige unbeantwortete Fragen zur endgültigen Bestätigung von Validator-Einzahlungen gemäß EIP 6110. Teku-Entwickler Mikhail Kalinin fasste vor der Konferenz in einem GitHub-Kommentar die Lösungsansätze für diese Probleme zusammen. Der Lighthouse-Entwickler „Sean“ stellte eine Frage zur Versionierung der „GetPayloadBodies“-Anfrage in der Engine-API. Stokes empfahl den Entwicklern, ihre Meinung in einem Pull-Request zu äußern, der für dieses Problem auf GitHub erstellt wurde.
EIP 7549 ändert sich
Nimbus-Entwickler Etan Kissling schlug eine kleine Änderung an der Implementierung von EIP 7549 vor. „Hier geht es um die Stabilität des verallgemeinerten Index. Wenn wir ein neues Feld in der Mitte des Containers hinzufügen, wird den nachfolgenden Feldern ein neuer Index zugewiesen, wodurch der auf EIP 4788 basierende Beweis auf der Ausführungsebene (EL) gebrochen wird. und einige Irreführungen. … Daher empfehle ich, das neue Feld ans Ende zu verschieben, um beide Probleme zu vermeiden“, erklärte Kissling. Gegen diese Änderung gab es keine Einwände. Stokes empfiehlt Entwicklern, Kisslings Pull-Request auf GitHub zu überprüfen.
Eine weitere auf dem Treffen vorgeschlagene Änderung an EIP 7549 würde darin bestehen, Anfragen und andere von EL ausgelöste Anfragen als Add-ons zu EL-Blöcken zu gestalten. Zu dieser Änderung sagte Kalinin: „Meiner Meinung nach ist dies eine sehr gute Designlösung, sie vereinfacht EL … und ist im Grunde eine Alternative zu generalisierten Anforderungen im Ausführungsschichtblock. Es wird empfohlen, dieses Thema zu behandeln.“ Beim nächsten CL-Meeting erneut besprochen, damit Entwickler mehr Zeit haben, den Vorschlag auf GitHub zu prüfen.
Diskussion über das Pectra-Zielfernrohr
Es gibt einige auf die Konsensschicht (CL) fokussierte EIPs, die nicht offiziell in das Pectra-Upgrade aufgenommen oder davon ausgeschlossen wurden. Beim Treffen dieser Woche diskutierten die Entwickler darüber, ob EIP 7688 und PeerDAS zu Pectra hinzugefügt werden sollten. EIP 7688 übernimmt einen Teil der SSZ-Datenstruktur „StableContainer“, um die Vorwärtskompatibilität der Attestierungsänderungen von EIP 7549 sicherzustellen. Als Hintergrundeinführung: SSZ ist eine in CL verwendete Datenstruktur, und Entwickler möchten sie auch in der Ausführungsschicht (EL) verwenden. Weitere Informationen zum SSZ-Übergang finden Sie im Protokoll früherer Sitzungen. PeerDAS ist eine Implementierung des Datenverfügbarkeits-Samplings auf Ethereum, von der erwartet wird, dass sie die Fähigkeit des Netzwerks, Rollups zu unterstützen, und seine Datenverfügbarkeitsanforderungen erheblich verbessern wird. In der Praxis wird erwartet, dass PeerDAS die Anzahl der Blob-Transaktionen, die Validatoren an einen Block anhängen können, von 3 auf 64 oder mehr pro Block erhöht.
Barnabas Busa, Developer Operations Engineer bei der Ethereum Foundation, sagte, Entwickler hätten eine frühe Iteration von PeerDAS in einem Entwicklungsnetzwerk gestartet. „Ich denke, viele Kunden haben viele Probleme entdeckt, und wenn wir erhebliche Fortschritte machen, können wir jederzeit ein neues Entwicklungsnetzwerk starten“, sagte Busa. Stokes fragte die Entwickler, ob sie bereit wären, PeerDAS zu Pectra hinzuzufügen, ohne dass es zu Verzögerungen beim Upgrade kommt.
Ein Entwickler mit dem Spitznamen „Nishant“ hat den Vorschlag wiederbelebt, die PeerDAS-Aktivierung von der Aktivierung anderer EIPs in Pectra zu trennen. Obwohl dies machbar ist, betonte ein anderer Entwickler mit dem Spitznamen „atd“, dass Benutzer ihre Software immer noch gleichzeitig aktualisieren müssen, wenn Entwickler planen, diese Upgrades in kurzer Zeit nacheinander zu aktivieren. atd sagte: „Ich finde es ein bisschen verrückt, zwei Monate nach einem weiteren Upgrade einen Fork zu machen. Wenn wir alle koordinieren, um den Client zu aktualisieren, wollen wir nicht, dass alle den Client zwei Monate später aktualisieren. Das wäre so.“ , nicht einmal ein Release-Zyklus reicht aus.“
atd fügte hinzu, dass PeerDAS seiner Meinung nach die „interessanteste“ Codeänderung im EIP sei, die in Pectra enthalten und diskutiert sei. Stokes sagte, er hoffe, PeerDAS in Pectra integrieren zu können, auch wenn dies zu Verzögerungen beim Upgrade führen würde. Der Grandine-Client-Entwickler Saulius Grigaitis schlug vor, EIP 7549 und EIP 7688 von Pectra zugunsten von PeerDAS zu entfernen. Dies löste eine Diskussion über die Implementierungsdetails von EIP 7688 aus. Die Entwickler konnten sich nicht auf die Codeänderungen einigen und der Vorschlag wird beim nächsten ACDC-Treffen erneut geprüft.
Beim Thema PeerDAS erwägen Entwickler weiterhin die Idee, Pectra in zwei Hard Forks aufzuteilen. Der Entwickleroptionen-Ingenieur der Ethereum Foundation, Parithosh Jayanthi, warnte, dass Entwickler, wenn sie Pectra in zwei Upgrades aufteilen, darauf achten müssen, in zukünftigem Pectra Teil 2 keine weiteren EIPs hinzuzufügen. Jayanthi sagte: „Eine Sache, die ich erwähnen möchte, ist, dass wir, wenn wir eine Aufteilung in zwei Forks in Betracht ziehen, sehr vorsichtig sein müssen, um im nächsten Fork keine weiteren neuen EIPs hinzuzufügen. Ich weiß nicht, ob wir das schaffen werden.“ Bis zu diesem Punkt können wir uns vor einem oder anderthalb Jahren auf etwas festlegen, weil wir ständig neue Ideen haben und sich die Prioritäten ändern und so weiter.“
Als Fortsetzung der Diskussion der beiden Upgrade-Ideen sagte Lighthouse-Entwickler „Sean“, dass er nicht viele gegenseitige Abhängigkeiten zwischen PeerDAS und der aktuellen Pectra-EIP-Liste vorhersehe. Daher können die beiden getrennt durchgeführt und später problemlos zusammengeführt werden, wenn der Entwickler mehr Vertrauen in die Implementierung hat. Atd stimmte zu und argumentierte, dass die Zusammenführung von Pectra EIP, PeerDAS und EIP 7688 nach getrennter Entwicklung und Prüfung kein großes Risiko darstellen würde.
Busa empfiehlt, Pectra EIP und PeerDAS weiterhin zu testen, den Code jedoch so zu gestalten, dass PeerDAS eine Epoche später als Pectra EIP in den Entwicklungs- und Testnetzwerken aktiviert wird. Er wies darauf hin, dass das Testen von Pectra EIP und PeerDAS bereits auf Devnet 0 erfolgt. „Es gibt wirklich nichts, was geändert werden muss“, sagte Busa und fügte hinzu, dass Entwickler diese Codeänderung aus dem Upgrade entfernen können, wenn PeerDAS nicht bereit ist, wenn die anderen Pectra-EIPs es sind. Dies wirft mehrere Fragen darüber auf, wie sich unterschiedliche Aktivierungsepochen von PeerDAS auf die Arbeit von Kundenteams auswirken. Am Ende einigten sich die Entwickler darauf, PeerDAS und Pectra EIP weiterzuentwickeln, gingen jedoch davon aus, dass PeerDAS in unterschiedlichen Epochen im Entwicklungsnetzwerk und im Testnetzwerk aktiviert würde.
Wie bereits erwähnt, einigten sich die Entwickler darauf, die Diskussion darüber, ob EIP 7688 in Pectra aufgenommen wird, bis zum nächsten ACDC-Aufruf aufzuschieben.
