Zusammenfassung des letzten Treffens der Ethereum-Kernentwickler: Vorbereitung auf die Implementierung von EIP 3074, Rollup-Roadmap

Originaltitel: „Ethereum All Core Developers Execution Call #186 Writeup“

Originalautorin: Christine Kim

Originalzusammenstellung: Frost, BlockBeats

Anmerkung des Herausgebers:

Der All Core Ethereum Developers Consensus Call (ACDE) findet alle zwei Wochen statt, um Änderungen am Ethereum Execution Layer (EL) zu besprechen und zu koordinieren. Während der 186. Telefonkonferenz von ACDE diskutierten Entwickler die Vorbereitungen für die Implementierung von Pectra Devnet 0 und EIP 3074. Sie erläuterten detailliert die Fortschritte verschiedener Kundenteams bei der Vorbereitung auf Pectra Devnet 0 und diskutierten vorgeschlagene Änderungen an der EIP 3074-Spezifikation und den damit verbundenen Testfortschritt.

Darüber hinaus geht dieser Artikel auch auf andere wichtige Themen ein, beispielsweise eine Diskussion anderer Codeänderungen, die möglicherweise im Pectra-Upgrade enthalten sind, und eine Diskussion darüber, wie Änderungen am Ethereum EIP-Prozess durch den L2/RIP-Prozess beeinflusst werden . Christine Kim, Vizepräsidentin für Forschung bei Galaxy Digital, hat die wichtigsten Punkte dieses Treffens ausführlich aufgezeichnet und BlockBeasts hat den Originaltext wie folgt zusammengestellt:

Am 25. April 2024 versammelten sich Ethereum-Entwickler auf Zoom, um an der All Core Developers teilzunehmen Ausführungsaufruf (ACDE) Nr. 186 Sitzungen. Die ACDE-Telefonkonferenz ist eine zweiwöchentliche Reihe von Treffen, die von Tim Beiko, Leiter Protokollunterstützung bei der Ethereum Foundation, veranstaltet werden und bei denen Entwickler Änderungen an der Ethereum Execution Layer (EL) diskutieren und koordinieren. Diese Woche diskutierten Entwickler über die Vorbereitungen für die Implementierung von Pectra Devnet 0 und EIP 3074. Sie diskutierten auch, welche anderen EIPs für die Einbeziehung in Pectra-Upgrades in Betracht gezogen werden sollten, sowie umfassendere Überlegungen zu Governance-Änderungen angesichts der „Rollup-zentrierten Roadmap“ von Ethereum.

Neueste Fortschritte bei Pectra Devnet 0

Beiko hat das Account-Team gebeten, während der Telefonkonferenz die neuesten Fortschritte bei Pectra Devnet 0 mitzuteilen. Marek Moraczyński vom Nethermind-Team sagte, dass Nethermind alle Pectra-EIPs implementiert habe und sie teste. Justin Florentine vom Besu-Team sagte, dass Besu das Pectra EIP implementiert und mit ihnen zusammenarbeitet, um sich auf die Einführung von Devnet 0 vorzubereiten. Andrew Ashikhmin vom Erigon-Team sagte: „Ich bin mir nicht sicher, ob Erigon für die Anzahl der EIPs für die gesamte Suite von Devnet 0 bereit ist, teilweise weil sich die Spezifikationen für diese EIPs noch ändern und der Erigon-Client auf die neue umsteigt.“ Hauptversion Erigon 3. Dies nimmt die Ressourcen und die Zeit des Teams in Anspruch, da Erigon 3 und Pectra EIP gemeinsam fertiggestellt und in den Erigon-Client integriert werden.“ Der „Lightclient“ des Geth-Teams sagte, dass Geth „nur noch wenige Tage“ davon entfernt ist, für Devnet 0 bereit zu sein. Gajinder Singh vom Ethereum JS-Team sagte, dass Ethereum JS auch „bereit“ für Devnet 0 sein wird.

EIP -7685

Lightclient führt EIP 7685 zusammen, wodurch ein gemeinsames Framework für die Speicherung von EL-ausgelösten Anfragen an den Consensus Layer (CL) und seine Auswirkungen auf EIP 6110 und 7002 entsteht. Beiko sagte, Entwickler sollten dieses EIP in ihre Devnet 0-Versionen aufnehmen und das Pectra EIP weiter verbessern.

Was die Tests angeht, sagte Mario Vega vom EF-Testteam, dass die Tests von EIP 6110 und 2537 abgeschlossen seien und die Tests von EIP 7002 und EIP 2935 diese oder nächste Woche abgeschlossen werden. Der Test von EIP 3074 ist für Devnet 0 noch nicht bereit. EF-Forscher Antonio Sanso sagte, dass die EIP 2537-Spezifikation aktualisiert und neue Testvektoren zum GitHub-Repository hinzugefügt wurden, und er empfiehlt jedem, sich das auf GitHub anzusehen. Der EF-Forscher Hsiao Wei Wang wies auf einen Fehler im Testvektor der CL-Spezifikation hin, der schnell behoben und eine neue Version veröffentlicht wurde.

Aktualisierungen für EIP -3074

Der ACDE-Aufruf dieser Woche für die EIP 3074-Spezifikation schlägt mehrere Änderungen vor. Ahmad Mazen Bitar schlug vor, das Verhalten von EIP 3074 zu ändern, um DELEGATECALL vor AUTH CALL zuzulassen, was die Anwendungsfälle von EIP erweitern würde. Derek Jiang, Gründer und CEO des Blockchain-Wallet-Betriebssystems ZeroDev, schlug die Schaffung eines „Noncemanagers“ vor, um bei Bedarf den globalen Widerruf von AUTH-Nachrichten und andere Änderungen zu erleichtern. Einige Entwickler waren der Meinung, dass Änderungen an EIP 3074 verzögert werden sollten, da sie die Implementierung erheblich erschweren würden.

Beiko empfiehlt Entwicklern, vorgeschlagene Änderungen an EIP 3074 in separaten Breakout-Sitzungen zu besprechen. Er wies darauf hin, dass Entwickler versuchen sollten, die Spezifikationen „in den nächsten ein bis zwei Monaten“ fertigzustellen, um genügend Zeit für die Implementierung von EIP 3074 in Pectra zu haben. Lightclient erklärt sich bereit, eine EIP 3074-Breakout-Sitzung zu organisieren. Für Devnet 0 bestätigte Beiko, dass Kundenteams EIP 3074 ohne Änderungen implementieren sollten, auch wenn Entwickler möglicherweise entscheiden, dass zukünftige Devnets EIP anders implementieren oder es vollständig aus Upgrades entfernen.

Zusätzlich zu den Implementierungsdetails von EIP 3074 diskutierten die Entwickler auch ernsthaft darüber, ob EIP über ausreichende Community-Unterstützung verfügt. Ein Entwickler, dessen Pseudonym „Siri“ ist, äußerte während des Anrufs Bedenken, dass „EIP 3074 grundsätzlich schlecht ist und unsere Fähigkeit, eine vollständige Kontoabstraktion zu erreichen, verlangsamen wird.“ Beiko antwortete, dass das Account-Team auf der Grundlage der Gesprächsrunden zwischen Ethereum Magician und ACD offenbar EIP 3074 gegenüber anderen Vorschlägen im Zusammenhang mit Account Abstraction (AA) unterstützt. Beiko sagte: „Dies scheint kurzfristig der größte Konsensvorschlag zu sein, und wir können den Status von EOA im nächsten Fork tatsächlich verbessern.“ In dieser Hinsicht ist Siri der Ansicht, dass das Kundenteam diese Entscheidung nicht isoliert treffen sollte. „Wir sollten anderen Stakeholdern zuhören“, sagte Siri und fügte hinzu: „Wir wollen nicht in den Bereich der Schaffung umstrittener Hard Forks geraten … Ich denke, es wäre gut zu verstehen, was andere Stakeholder sagen und wie sie das sehen.“ . Vorschlag. „

Beiko und Siri diskutierten auch darüber, wie ein breiterer Konsens für EIP über den ACD-Aufruf hinaus erzielt werden kann. Chiang schlug vor, zunächst ein EIP 3074-Breakout-Meeting abzuhalten, um die technischen Spezifikationen des EIP eingehend zu besprechen und dann zu entscheiden, ob es im Pectra-Upgrade verbleiben sollte. EF-Forscher Ansgar Dietrichs sagte: „Wir sollten verstehen, dass EIP 3074 zurückgezogen wird, wenn wir nicht genügend Fortschritte machen.“

Ethereum-Mitbegründer Vitalik Buterin fügte hinzu: „Die Funktionalität von Benutzerkonten wird sich in den nächsten Jahren ändern.“ Externally Owned Accounts (EOA). Aktivierungskontoabstraktionsbezogene EIPs, wie EIP 3074 usw.

Andere Pectra-Vorschläge

Entwickler diskutieren weiterhin, welche anderen Codeänderungen für die Aufnahme in das Pectra-Upgrade in Betracht gezogen werden sollten. Geth-Entwickler Marius van der Wijden sagte, es sollte davon abhängen, ob EIPs mit höherer Komplexität wie EOF ihren Weg zu Pectra finden. „Wenn wir EOF einbeziehen würden, würde das zu einer Gabelsättigung führen. Wenn wir EOF nicht einbeziehen würden, könnten wir vielleicht mehr einbeziehen“, sagte van der Wijden.

Siri äußerte Bedenken hinsichtlich der Aufnahme von EIP 3074 in Pectra ohne Sicherheitsüberprüfung. Beiko schlug vor, diese Diskussion auf Eis zu legen, bis die Spezifikationen für EIP 3074 fertiggestellt sind.

Bitar sagte, er würde gerne sehen, dass EIP 7212 zu Pectra hinzugefügt wird. EIP 7212 erstellt eine neue Vorkompilierung, die die Signaturüberprüfung in elliptischen Kurven von secp256 r1 durchführt. Dies kann mit Hardwaregeräten verwendet werden, die Benutzerbiometrie unterstützen. Bitar sagte, dass die Unterstützung biometrischer Daten zum Signieren von Ethereum-Transaktionen eine wesentliche Verbesserung des Benutzererlebnisses darstellen würde. Ashihemin sagte, er unterstütze den Vorschlag ebenfalls. Dietrichs wies darauf hin, dass dies die einzige Lösung sei, die für die Implementierung durch Layer-2-Rollups im Rahmen des „Rollup Improvement Proposal“ (RIP)-Prozesses zugelassen sei.

Andere Entwickler, darunter Dietrichs, van der Wijden und Moraczyński, haben ihre Unterstützung für EIP 7623 zum Ausdruck gebracht, was die Kosten für Anrufdaten erhöhen und somit die maximale Blockgröße begrenzen würde. Beiko empfiehlt, EIP 7623 und EIP 7212 als „zur Prüfung“ oder CFI in Pectra zu markieren und die Bandbreite des Kundenteams erneut zu prüfen, um diese beiden Verbesserungsvorschläge nach der Einführung von Devnet 0 zu unterstützen.

In Bezug auf das EIP-Paket im Zusammenhang mit der Aktualisierung der EL-Serialisierungsmethode auf SSZ äußerte van der Wijden Bedenken, dass diese in Pectra zu schwer zu transportieren sein würden. Sein Kollege im Geth-Team, Guillaume Ballet, stimmt dieser Einschätzung zu. Buterin mischte sich ein und sagte, dass zumindest eine Serialisierungsmethode zur Aktualisierung von Transaktionsbelegen einen „erheblichen Wert“ über Ethereum selbst hinaus hätte, da sie den zusätzlichen Sicherheitsüberprüfungsaufwand von auf Ethereum aufbauenden Layer-2-Rollups eliminiere. “. Der Hauptunterstützer des SSZ-bezogenen EIP, Etan Kissling vom Nimbus-Team, war bei dem Anruf nicht anwesend, schrieb jedoch auf GitHub eine ausführliche Erklärung darüber, warum diese Codeänderungen wichtig sind und für die Aufnahme in Pectra in Betracht gezogen werden sollten.

Die Entwickler haben auch EOF erneut aufgegriffen. Danno Ferrin, ein unabhängiger Ethereum-Protokollentwickler, sagte, dass das EOF-Team EL-Spezifikationstests zu Codeänderungen durchführt. EVMOne und Reth sind zwei EL-Kundenteams, die Berichten zufolge EOF-Implementierungen abgeschlossen haben. Ferrin sagte, das Geth-Team habe bei der Umsetzung „gute Fortschritte“ gemacht. Ferrin fügte hinzu, dass Ballet mit „Daniel“ vom Solidity-Team zusammenarbeitet, um Bedenken hinsichtlich der EOF- und Verkle-Kompatibilität auszuräumen.

Ballet wies darauf hin, dass es aufgrund seiner Gespräche mit anderen Entwicklern wie Daniel und Dietrichs schwierig sein würde, den Umfang von EOF einzuschränken, ohne seinen Zweck zu verfehlen und mehr Möglichkeiten für Entwickler zu schaffen, eine weitere Reihe von EOF-ähnlichen Codeänderungen zu implementieren die Zukunft.

Ein Entwickler mit dem Pseudonym „Charles C“ schlug vor, nach einer Möglichkeit zu suchen, EOF einfach iterativ über einen Side-Car-Mechanismus (wie er für Blob-Transaktionen verwendet wird) zu implementieren, anstatt zwischen kleinen oder großen EOF-Upgrades zu wechseln. Treffen Sie Ihre Auswahl . Dietrichs fragte im Chat, ob Account-Teams mehr Interesse an Pectra hätten, wenn dessen EOF-Komplexität reduziert würde. Das Ipsilon-Team stellte fest, dass die Codeänderungen, die die höchste Komplexität in EOF verursachten (z. B. „TX create“), behoben wurden und dass das Entfernen spezifischer Anforderungen für Funktionen wie „EOF create“ die Gesamtkomplexität von EOF nicht wesentlich verringern wird. Zum Vergleich: Ipsilon ist der Name des EF-finanzierten EVM-Forschungs- und Entwicklungsteams. Beiko empfiehlt den Entwicklern, EOF-Implementierungen in den wiederkehrenden EOF-Breakout-Sitzungen weiterhin zu diskutieren.

ACD/EIP und L2/RIP

Als letztes in ACDE #186 diskutiertes Thema diskutierten die Entwickler Änderungen am Ethereum EIP-Prozess, um den neuen RIP-Prozess zu berücksichtigen. Dietrichs bemerkte, dass es sechs Monate her sei, seit die Entwickler eine Besprechungsreihe zu Rollup-Koordination, RollCall- und RIP-Prozessen gestartet hätten. Es gibt noch einige offene Fragen dazu, wie sich diese Prozesse auf den Ethereum EIP-Prozess auswirken werden und sollten. Dietrichs sagte, dass eine laufende Forschungsfrage in L2 sei, ob eine langfristige Äquivalenz zur Ethereum Virtual Machine (EVM) für Rollup wünschenswert sei. Er fügte außerdem hinzu, dass eine offene Frage sei, inwieweit sich die auf L2 implementierten Änderungen letztendlich auf Protokollentscheidungen auf der Schicht 1 von Ethereum auswirken werden.

Der Geth-Entwickler Péter Szilágyi gab an, dass einige auf L2 verfügbare Funktionen möglicherweise nicht für die Bereitstellung auf L1 geeignet sind. In einigen Fällen kann es trotz der auf L2 verfügbaren Funktionen zu Unterschieden zwischen L2 kommen, was zu Verwirrung führen kann Entwickler des Ethereum-Protokolls. EF-Forscher Carl Beekhuizen wies darauf hin, dass der RollCalls- und RIP-Prozess von den Entwicklern des Ethereum-Protokolls nicht verlangt, irgendwelche Funktionen auf L2 zu veröffentlichen, sondern vielmehr die Kommunikation zwischen Rollups und Ethereum-Entwicklern verbessert, um verwirrende Situationen wie die von Szilágyi beschriebene zu vermeiden. Van der Wijden äußerte seine Besorgnis darüber, dass Protokollentwickler Zeit damit verschwenden, auf L2 implementierte Änderungen zu unterstützen, die irgendwann obsolet oder unnötig werden, wenn L2 selbst heruntergefahren oder nicht mehr verwendet wird.

Zu diesen Bedenken sagte Dietrichs: „Ich denke, die Leute haben immer gedacht, dass Layer 2 experimentieren und noch verrückter werden kann. Ich denke, was wir in der Praxis sehen, ist, dass die meisten von ihnen sich dagegen entscheiden, sogar oder zumindest wahrscheinlich damit begonnen haben.“ Das und mit der Zeit haben die meisten Leute damit aufgehört, und jetzt folgen sie tatsächlich hauptsächlich der ersten Tier-Spezifikation, zumindest angesichts der Rollup-zentrierten Roadmap, oder das ist, was wir alle für den besten Weg halten Damit sich das Ökosystem weiterentwickeln kann, sind wir zumindest einer klaren Führung und Kommunikation seitens Layer 2 schuldig, wie hier der beste Weg nach vorne ist.“

Das obige ist der detaillierte Inhalt vonZusammenfassung des letzten Treffens der Ethereum-Kernentwickler: Vorbereitung auf die Implementierung von EIP 3074, Rollup-Roadmap. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!