Geschrieben von: Christine Kim
Zusammengestellt von: Luccy, BlockBeats
Anmerkung des Herausgebers: Der Ethereum All Core Developers Consensus Call (ACDC) findet alle zwei Wochen statt, um die Implementierung des Ethereum Consensus Layer (CL) zu besprechen und zu koordinieren ) Ändern. 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 Fragen der Aktivierungszeit und der gegenseitigen Abhängigkeit verschiedener EIPs wurden erörtert.
Galaxy Digital Vice President of Research Christine Kim hat die wichtigsten Punkte dieses Treffens ausführlich aufgezeichnet und BlockBeasts hat den Originaltext wie folgt zusammengestellt:
Am 30. Mai 2024 versammelten sich Ethereum-Entwickler auf Zoom, um am All Core Developers Consensus teilzunehmen (ACDC) rufen Sie das Treffen Nr. 134 an. Der ACDC-Aufruf ist eine zweiwöchentliche Reihe von Treffen, die vom Forscher der Ethereum Foundation, Alex Stokes, veranstaltet werden und bei denen 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 Änderungen des PeerDAS- und SSZ-Containercodes.
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 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-Staking-Merges in ein paar Wochen zu überprüfen, bevor sie entscheiden, ob es sich um EL- oder CL-Operationen handeln soll.
Die Entwickler diskutierten dann einige unbeantwortete Fragen zur endgültigen Bestätigung von Validator-Einzahlungen gemäß EIP 6110. Der Teku-Entwickler Mikhail Kalinin fasste die Anweisungen zur Behebung dieser Probleme in einem GitHub-Kommentar vor der Konferenz zusammen. Der Lighthouse-Entwickler „Sean“ stellte eine Frage zur Versionierung der „GetPayloadBodies“-Anfrage in der Engine-API. Stokes empfahl den Entwicklern, ihre Kommentare in einem für das Problem erstellten Pull-Request auf GitHub zu veröffentlichen.
Nimbus-Entwickler Etan Kissling schlug eine kleine Änderung an der EIP 7549-Implementierung 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 bestand darin, Anfragen und andere von EL ausgelöste Anfragen als Add-ons zum EL-Block 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.
Es gibt einige auf Konsensschicht (CL) fokussierte EIPs, die noch nicht offiziell im Pectra-Upgrade enthalten oder davon ausgeschlossen sind. 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, dass Entwickler eine frühe Iteration von PeerDAS in einem Entwicklungsnetzwerk gestartet haben. „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. Wenn wir uns vor einem oder anderthalb Jahren auf etwas festlegen könnten, weil wir ständig neue Ideen haben und sich die Prioritäten ändern und so weiter.“
Besprechen Sie weiterhin zwei Upgrade-Ideen, die Leuchtturmentwicklung Der Autor „Sean“ sagte, dass er keine großen Interdependenzen zwischen PeerDAS und der aktuellen Pectra EIP-Liste vorhergesehen habe. 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 bereit 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, allerdings nur unter der Bedingung, dass PeerDAS in unterschiedlichen Epochen im Entwicklungsnetzwerk und im Testnetzwerk aktiviert würde.
Wie oben erwähnt, haben die Entwickler vereinbart, die Diskussion darüber, ob EIP 7688 in Pectra aufgenommen wird, bis zum nächsten ACDC-Aufruf aufzuschieben.
Das obige ist der detaillierte Inhalt vonZusammenfassung des letzten Treffens der Ethereum-Kernentwickler: Das Pectra-Upgrade kann in zwei Hard Forks aufgeteilt werden. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!