Originaltitel: „Ethereum All Core Developers Consensus Call #138 Writeup“
Autorin: Christine Kim
Zusammengestellt von: Ladyfinger, BlockBeats
. Anmerkung des Herausgebers:
Ether Der All Core Developers Consensus Call (ACDC) findet alle zwei Wochen statt, um Änderungen am Ethereum Consensus Layer (CL) zu diskutieren und zu koordinieren. Dies ist die 138. ACDC-Telefonkonferenz. Diese Konferenz befasst sich mit der Einführung von Pectra Devnet 1, Änderungen am Beacon-Blockkörper und der Engine-API-Struktur sowie der Aufnahme stabiler Container-Ethereum-Verbesserungsvorschläge (EIPs) in Pectra, nämlich EIP 7688 und EIP 7495 und PeerDAS-Updates und andere Themen. Während des Treffens überprüften die Entwickler die Bereitschaft für Pectra-Upgrades und diskutierten einige offene Fragen und Vorschläge zur PeerDAS-Implementierung. Darüber hinaus teilte Nimbus-Entwickler Etan Kissling den Fortschritt der Implementierungsarbeiten von EIP 7688 und EIP 7495 mit und betonte die Bedeutung dieser Vorschläge zur Aktualisierung der Datenserialisierungsmethode von Ethereum. Christine Kim, Vizepräsidentin für Forschung bei Galaxy Digital, hat die wichtigsten Punkte dieses Treffens ausführlich aufgezeichnet und BlockBeats hat den Originaltext wie folgt zusammengestellt:
Am 25. Juli 2024 hielten Ethereum-Entwickler den 138. All-Core Developer Consensus (ACDC) ab ) über Zoom )Treffen. Die ACDC-Konferenz ist eine zweiwöchentliche Reihe von Treffen, bei denen Entwickler Änderungen am Ethereum Consensus Layer (CL), auch bekannt als Beacon Chain, diskutieren und koordinieren. Die Sitzung dieser Woche wurde vom Forscher der Ethereum Foundation (EF) Alex Stokes moderiert. Die Entwickler diskutierten Folgendes:
·Einführung von Pectra Devnet 1
·Änderungen am Beacon-Blockkörper und der Engine-API-Struktur
·Einbindung von Stable Container Ethereum Improvement Proposals (EIPs) in Pectra, bekannt als EIP 7688 und EIP 7495
· Aktualisierungen für PeerDAS und seinen Implementierungsplan im Mainnet
Pectra Devnet 1 Pectra
Devnet 1 ging am Dienstag, den 23. Juli, live. Allerdings ist das Netzwerk nicht stabil. Parithosh Jayanthi, ein DevOps-Ingenieur bei der Ethereum Foundation, sagte, der Erigon-Client sei kurz nach dem Start des Devnets auf Probleme gestoßen. Dann führte eine im Devnet übertragene EIP 7702-Transaktion dazu, dass sich das Netzwerk in drei Zustände aufteilte. Entwickler debuggen den Client und lösen Probleme mit der Kettenaufteilung.
Einführung von ExecutionPayloadEnvelope
Prysm-Entwickler Potuz schlug wesentliche Verbesserungen an der Ausführungslaststruktur des Beacon-Chain-Blocks sowie entsprechende Anpassungen an der Engine-API vor. Dieser Vorschlag zielt darauf ab, den Prozess der Speicherung und Verarbeitung von Zustandsübergangsdaten durch Consensus Layer (CL)-Clients zu vereinfachen. Mit der Implementierung des Pectra-Upgrades benötigen CL-Clients Zugriff auf bestimmte Teile der Ausführungslast, um Zustandsübergänge korrekt durchzuführen. Das bestehende Design führt jedoch dazu, dass diese Clients einige nicht wesentliche Informationen bei der Ausführungslast ignorieren.
Pectra-Upgrades erfordern, dass CL-Clients entweder die erforderlichen Zustandsübergangsdaten von der Ausführungsschicht (EL) anfordern oder kritische Teile der Blöcke lokal speichern. Um die Effizienz des CL-Clients nach dem Upgrade von Pectra zu verbessern, schlug Potuz die Einführung einer neuen Struktur namens „bind_execution_payload_envelope“ vor, um wichtige Informationen, die für Ausführungsstatusübergänge erforderlich sind, zentral zu speichern. Solche Verbesserungen werden die Geschwindigkeit und Effizienz von CL-Clients bei der Berechnung von Zustandsübergängen erheblich steigern. Er betonte außerdem, dass diese Anpassungen die Kompatibilität mit zukünftigen Netzwerk-Upgrades wie dem Simple Serialization (SSZ)-Format gewährleisten werden.
Mark Mackey, der Entwickler des Lighthouse-Projekts, warnte davor, dass die Leistung des CL-Clients im Pectra-Testnetz beeinträchtigt werden könnte, wenn diese Änderungen nicht umgesetzt würden. Mikhail Kalinin, ein Entwickler des Teku-Projekts, äußerte Vorsicht und fragte, ob Protokolländerungen wirklich notwendig seien, um der Komplexität der Implementierung von EIPs in Pectra zu begegnen. Potuz besteht darauf, dass es grundlegende Probleme mit dem bestehenden Protokolldesign gibt und korrigiert werden muss. Er wies darauf hin: „Das aktuelle Design ist konzeptionell fehlerhaft. Es vermischt Daten, die für CL-Zustandsübergänge von entscheidender Bedeutung sind, mit völlig unabhängigen Daten auf derselben Ebene und in derselben Nachricht. Daher halte ich das aktuelle Design für falsch. Wir arbeiten hart.“ um diesen Fehler zu beheben.“
Stokes ermutigt Entwickler, diesen Vorschlag weiterhin auf GitHub zu diskutieren.
Engine-API-Update für Devnet 2
Im Zusammenhang mit der obigen Diskussion schlug der Geth-Entwickler „Lightclient“ eine weitere Änderung an der Engine-API vor. Diese Änderung soll die Blockkonvertierung für EL-Clients einfacher machen. EL-Clients bestimmen die Blockversion durch Interpretation der Null- und Void-Felder im Block. Aufgrund des Prager EIP 7685 können EL-Clients jedoch ohne einen Fork-Zeitplan nicht in der Lage sein, Blockversionen basierend auf diesen Feldern zu unterscheiden. Um den Aufwand zu vermeiden, der mit der Bezugnahme auf einen Zeitplan vergangener Upgrades verbunden ist, schlägt Lightclient vor, alle Anfragen in einem einzigen Typ in der Engine-API zu vereinen, den EL zur Interpretation an CL übergeben kann.
Lightclient weist darauf hin, dass die Interpretation von Chunks zwischen EL und CL unterschiedlich ist und dass CL in diesem Fall besser geeignet ist, die Anforderungsdaten darzustellen. „Wenn wir uns mit den Blöcken selbst befassen, gibt es kein Konzept von ‚Das ist ein Bellatrix-Block‘ wie bei CL. Ich denke, ihr habt gute Arbeit bei der Unterscheidung zwischen verschiedenen Arten von gespaltenen Blöcken geleistet. Aber bei On EL Ich denke, so werden fast alle Clients implementiert, wir haben einen Block, der alle Blocktypen repräsentiert, und wir nutzen das Vorhandensein beispielsweise eines Nullwerts, um zu bestimmen, ob dieser [Fork] aktiv ist.“
Nimbus-Entwickler „Dustin „ lehnte diesen Vorschlag ab und sagte, dass der Vorschlag von Lightclient die Komplexität der Blockinterpretation auf EL und CL nicht vollständig berücksichtige. „Es verlagert nur die Komplexität und Verwirrung von der EL in die CL, und beide Orte sind machbar. Die Verlagerung in die CL löst das Problem nicht. ... Es verschiebt nur das Problem“, sagte Dustin.
Stokes behauptet, dass CL besser für die Interpretation von Anfragen geeignet sei und empfiehlt Entwicklern, sich die von Potuz und Lightclient auf GitHub vorgeschlagenen Engine-API-Änderungen genauer anzusehen.
EIP 7688 und 7495 in Pectra
Nimbus-Entwickler Etan Kissling drängt auf ein Update der Ethereum-Serialisierungsmethode auf SSZ. Für Pectras Zwecke identifizierte er zwei Zwischen-EIPs, 7688 und 7495, um Datenstrukturen einzuführen, auf die sich Smart-Contract-Entwickler verlassen können, um mit zukünftigen SSZ-bezogenen Änderungen kompatibel zu sein. Kissling wies darauf hin, dass er bereits Unterstützung von Liquid-Stake-Pools wie Rocketpool sowie anderen Kundenteams wie Teku und Lodestar habe.
Stokes warnt das CL-Kundenteam davor, neue EIPs in Pectra hinzuzufügen. „Pectra ist bereits sehr groß, insbesondere wenn wir am Ende PeerDAS in der Abzweigung haben. Irgendwann müssen wir sehr realistisch sein, was die Größe der Abzweigung und die damit verbundenen Risiken angeht. Auch hier stimme ich mit Etans Meinung überein. Dafür gibt es Gründe.“ „Diese Funktion ist im luftleeren Raum wertvoll, aber ich denke, dies ist einer der größten Hard Forks, die wir je gemacht haben, oder der größte, und das sollte nicht auf die leichte Schulter genommen werden“, sagte er.
Entwickler haben einige Bedenken geäußert, wann diese EIPs tatsächlich zum Pectra-Devnet hinzugefügt werden können, da Pectra-Devnets noch nicht viele EIPs wie PeerDAS und EOF integriert haben. In diesem Zusammenhang empfiehlt Jayanthi, zunächst klar zu entscheiden, ob Entwickler diese EIPs in Upgrades einbeziehen sollen. Jayanthi warnte außerdem davor, dass es einen Engpass gebe, wenn CL und EL EIP gemeinsam auf einem Devnet getestet würden. Er schrieb in einem Zoom-Chat: „Der gemeinsame Versand von 10 direkten EIPs würde es sehr kompliziert machen, Kombinationen zu forken und zu testen. Und wir haben nicht nur direkte EIPs, wie es das EigenLayer-Team von Anwendungsentwicklern versucht.“ Sie müssen herausfinden, was in Pectra aktiviert werden soll, und die anhaltende Unklarheit über diese beiden EIPs behindert ihre Bemühungen. Lighthouse-Entwickler Sean Anderson empfiehlt, mehr Input von Anwendungsentwicklern auf Ethereum zu diesen EIPs einzuholen, um festzustellen, wie wichtig sie für Anwendungen sind.
Stokes schlägt vor, diese Diskussion zu einem späteren Zeitpunkt erneut aufzugreifen, damit sich Entwickler auf die Lösung von Pectra Devnet 1-Problemen konzentrieren können.
PeerDAS-Update
Entwickler führten eine ausführliche Diskussion über die neuesten Fortschritte von PeerDAS. Anderson berichtet, dass das Consensus Layer (CL)-Kundenteam aktiv Probleme behebt, die in der vorherigen Runde des PeerDAS-Entwicklungsnetzes entdeckt wurden, und die Stabilität der Implementierung sicherstellt, bevor ein neues Entwicklungsnetz gestartet wird. Lodestar- und EthereumJS-Entwickler Gajinder Singh sagte, dass die Community basierend auf dem Feedback eines kürzlich durchgeführten Treffens der PeerDAS-Implementierer daran interessiert sei, PeerDAS in das nächste Pectra-Entwicklungsnetz zu integrieren.
Stokes schlug vor, dass basierend auf Diskussionen mit dem Forschungsteam der Ethereum Foundation (EF) und anderen Entwicklern die Sampling-Funktion bei der ersten Aktivierung von PeerDAS im Hauptnetzwerk möglicherweise weggelassen werden muss, um die Komplexität der Implementierung zu verringern. Er erklärte, dass die vollständige Implementierung von PeerDAS drei Schlüsselfunktionen umfasst: Verteilung, Probenahme und Rekonstruktion. „Derzeit deckt die PeerDAS-Spezifikation in Pectra diese drei Aufgaben ab. Meine Intuition sagt mir, dass die Sampling-Funktion wahrscheinlich der größte Komplexitätspunkt bei der Implementierung ist. Wenn Sampling tatsächlich eine unüberwindbare Herausforderung darstellt, könnten wir erwägen, sie in Pectra zu implementieren, um die Anzahl zu erhöhen.“ von Blobs bei gleichzeitiger Reduzierung oder Anpassung des Umfangs von PeerDAS“, erklärte Stokes.
Stokes versprach, einen formellen Vorschlag zu der Idee zu entwickeln und ihn mit der Entwicklergemeinschaft weiter zu prüfen. Singh unterstützt dies. Stokes empfahl außerdem, PeerDAS offiziell in das Pectra-Upgrade einzubeziehen. Als Antwort fragte Jayanthi, ob dies eine Neudefinition der PeerDAS-Spezifikation basierend auf der Pectra-Spezifikation bedeute, und wies darauf hin, dass die Zusammenführung von PeerDAS- und Pectra-Entwicklungsnetzwerken die Debugging-Bemühungen erschweren könnte, da beide instabil seien. Er schlug vor, die Unabhängigkeit der beiden Arbeitsabläufe beizubehalten, bis die Spezifikation stabil ist. Teku-Entwickler Enrico Del Fante stimmt Jayanthi zu.
Stokes stellte fest, dass viele Entwickler, die sich auf die PeerDAS-Implementierung konzentrierten, nicht an dem Treffen teilnehmen konnten. Er schlug vor, die weiteren Schritte für PeerDAS beim nächsten Treffen der PeerDAS-Implementierer weiter zu besprechen.
BeaconBlocksByRange V3 hinzugefügt
Der Entwickler des Lighthouse-Projekts „Dapplion“ hat einen Verbesserungsplan vorgeschlagen, um Kunden im Falle einer langfristigen Kettenteilung effektiver bei der Synchronisierung mit der Hauptkette zu unterstützen. Er wies darauf hin, dass das bestehende RPC-Protokoll [BeaconBlocksByRange V2] bestimmte Einschränkungen aufweist: „Wenn Sie einen Long-Fork-Block synchronisieren müssen und nicht sicher sind, welcher Zweig die Hauptkette ist, müssen Sie gemäß dem aktuellen Protokoll nur A übermitteln Im Slot-Bereich gibt der Knoten den Block zurück, den er für richtig hält. Dieser Vorgang ist jedoch asynchron und kann zu einigen Problemen führen Wenn in Zukunft ein ähnlicher Vorfall auftritt, wird dies ein Problem sein, das gelöst werden muss. Obwohl diese Verbesserungen nicht unmittelbar bevorstehen, ermutigte Stokes die anwesenden Entwickler, den Vorschlag sorgfältig zu prüfen und ihre Gedanken und Vorschläge auf GitHub zu teilen.
Das obige ist der detaillierte Inhalt vonZusammenfassung des letzten Treffens der Ethereum-Kernentwickler: Einführung des Pectra-Upgrades, Diskussion über den Fortschritt der PeerDAS-Implementierung. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
