Zusammenfassung des letzten Treffens der Ethereum-Kernentwickler: Aktivierung von PeerDAS, Erhöhung des Blob-Gas-Limits

Originaltitel: „Ethereum All Core Developers Consensus Call #135 Writeup“

Anmerkung des Herausgebers: Der Ethereum All Core Developers Consensus Call (ACDC) findet alle zwei Wochen statt, hauptsächlich um den Konsens zu diskutieren und zu koordinieren zu Ethereum Änderungen an der Konsensschicht (CL). Dies ist die 135. ACDC-Telefonkonferenz. Diese Konferenz konzentriert sich hauptsächlich auf die Vorbereitung des Testnetzwerks von Pectra Devnet 1, PeerDAS Devnet 1 und Simple Serialize (SSZ) Ethereum Improvement Proposals (EIPs).

Entwickler führten ausführliche Diskussionen über die Wartung von Softwarepaketen, den EIP-Einbindungsprozess und die Benennung der neuen Runde des Ethereum-Konsensschicht-Upgrades. Darüber hinaus ging es in der Sitzung um den Implementierungsfortschritt gemäß der Electra-Spezifikation, die Auswirkungen von PeerDAS-Netzwerkänderungen auf die Art und Weise, wie Ethereum-Knoten Daten verarbeiten und validieren, sowie die komplexen technischen Probleme im Zusammenhang mit der Erhöhung der Blobgas-Grenzwerte.

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 13. Juni 2024 versammelten sich Ethereum-Entwickler auf Zoom, um am All Core Developers Consensus teilzunehmen (ACDC) Rufen Sie das Treffen Nr. 135 an. 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 diskutierten Entwickler die Vorbereitungen für Pectra Devnet 1, PeerDAS Devnet 1 und ein drittes dediziertes Testnetzwerk für Simple Serialize (SSZ) Ethereum Improvement Proposals (EIPs).

Ankündigungen

Die Entwickler starteten das Treffen mit zwei Ankündigungen. Der DevOps-Ingenieur der Ethereum Foundation, Parithosh Jayanthi, sagte, dass das ethPandaOps-Team, eine Gruppe von Ingenieuren, die im DevOps der Ethereum Foundation (EF DevOps) arbeiten, die Wartung und Entwicklung des Kurtosis-Moduls des Ethereum-Pakets übernehmen wird. Dieses Paket wurde in der Vergangenheit von Entwicklern verwendet, um Ethereum-Testnetzwerke und verwandte Tools zu starten, wie beispielsweise das Grafana-Daten-Dashboard zum Überwachen und Testen verschiedener Client-Implementierungen. Die Migration dieses Pakets vom technischen Team von Kurtosis zum ethPandaOps-Team kann sich auf Benutzer auswirken, da einige Links zu GitHub-Repositorys weiterleiten, die vom ethPandaOps-Team und nicht mehr vom Kurtosis-Team verwaltet werden. Jayanthi empfiehlt Benutzern, ihre Software-Links zu aktualisieren und nach neuen Versionen des ethPandaOps-Teams Ausschau zu halten.

Die zweite Ankündigung erfolgte durch Tim Beiko, Leiter Protokollunterstützung bei der Ethereum Foundation. Beiko sagte, er arbeite an der Einführung eines neuen Prozesses, um EIPs schrittweise in Ethereum-Upgrades einzubeziehen. Er hat einen EIP-Entwurf erstellt, der die Bezeichnungen „Zur Aufnahme vorgeschlagen“, „Zur Aufnahme in Betracht gezogen“ und „Zur Aufnahme geplant“ definiert. Er hofft, dass die Entwickler das Dokument überprüfen und Feedback geben. Er hoffte, das Dokument vor der nächsten ACD-Sitzung fertigzustellen.

Electra

Die Codespezifikation für die nächste große Electra-Version v1.5.0-alpha.3 ist fast vollständig. Die Entwickler einigten sich darauf, Pull Request (PR) #3768 im GitHub-Repository der Konsensspezifikation in die nächste Version zusammenzuführen. Der Pull-Request wurde vom Nimbus-Entwickler Etan Kissling erstellt, der darauf hinwies, dass das Feld „committee_bits“ am Ende der „Attestation“ und nicht in der Mitte der Daten angehängt werden sollte, um Probleme bei der Datenserialisierung zu vermeiden. Zusätzlich zu PR #3768 fragte Stokes, ob noch weitere offene Probleme bestehen, die gelöst werden müssen, bevor die nächste Hauptversion der Electra-Spezifikation veröffentlicht wird. Jayanthi erwähnte im Zoom-Chat, dass es einige offene Probleme bei der Integration von Validatoren gibt, die über die Ausführungsschicht (EL) ausgelöst werden. Stokes machte darauf aufmerksam, dass er nach dem Treffen den Status der EL-ausgelösten Validator-Integration weiterverfolgen werde.

Was den Implementierungsfortschritt der neuesten Electra-Spezifikation betrifft, gaben die meisten Client-Teams der Konsensschicht (CL) bei dem Treffen an, dass sie die neue Version innerhalb von ein bis zwei Wochen nach v1.5.0-alpha zum Testen bereit haben werden .3 ist abgeschlossen . Die Entwickler einigten sich darauf, den Zeitplan für das nächste Pectra-Entwicklungsnetzwerk, Pectra Devnet 1, in einigen Wochen zu überdenken.

PeerDAS

Als nächstes diskutierten die Entwickler den Implementierungsfortschritt von PeerDAS. PeerDAS ist eine Netzwerkverbesserung für Ethereum, die die Fähigkeit der Knoten verbessert, große Mengen beliebiger Daten zu verarbeiten und zu überprüfen, die von Benutzern über Blob-Transaktionen übermittelt werden. Stokes erinnerte an die Entscheidung beim letzten ACDC-Treffen, dass Entwickler PeerDAS parallel zu anderen Pectra-EIPs entwickeln würden, indem sie einen separaten Aktivierungszyklus für PeerDAS im Entwicklungsnetzwerk aktivieren.

Lodestar-Entwickler Gajinder Singh sagte, dass Entwickler PeerDAS zusätzlich zum Deneb-Upgrade und in einem von anderen Pectra-EIPs getrennten Entwicklungsnetzwerk aktivieren werden, basierend auf Diskussionen bei einer kürzlich durchgeführten Breakout-Sitzung zu PeerDAS. Teku-Entwickler Enrico Del Fante sagte, es sei für Entwickler einfacher, PeerDAS auf den stabilen Codespezifikationen aufzubauen, die bereits im vorherigen Ethereum-Upgrade Deneb festgelegt wurden, als auf den sich ständig ändernden Pectra-Codespezifikationen. Jayanthi stimmte zu, dass die Zusammenführung der PeerDAS-Implementierung mit anderen Pectra EIP-Implementierungen jetzt zu Komplikationen beim Testen führen könnte, insbesondere wenn versucht wird, die Fehlerquelle zu lokalisieren. Er schlug vor, die beiden Arbeitsabläufe getrennt zu halten und sie dann zusammenzuführen, sobald ihre Implementierungen stabiler sind. Stokes stimmte zu und sagte, dass Entwickler die Zusammenführung von PeerDAS und anderen Pectra-EIP-Implementierungen in etwa einem Monat erneut in Betracht ziehen könnten.

Was den Start von PeerDAS Devnet 1 betrifft, hat das Kundenteam keine klare Schätzung, wann das Testnetz zum Start bereit sein wird. Die individuellen Schätzungen bei Sitzungen lagen ungefähr zwischen 2 Wochen und 1 Monat. Stokes schlug vor, den Zeitplan für die Entwicklung des Netzwerks in ein paar Wochen zu überdenken, wenn das Kundenteam mehr Zeit hat, an der PeerDAS-Implementierung zu arbeiten.

Beiko wies dann darauf hin, dass es sich bei PeerDAS zwar um eine Netzwerkverbesserung und nicht um eine Änderung des Ethereum-Kernprotokolls handelt, er jedoch dennoch möchte, dass die Codeänderungen in das Meta-EIP für das Pectra-Upgrade aufgenommen werden. Das Meta-EIP-Dokument ist ein öffentliches Dokument, das alle im Ethereum-Upgrade enthaltenen Kernprotokolländerungen auflistet. Beiko wies darauf hin, dass PeerDAS das „größte Feature“ in Pectra ist und obwohl es keine Hard-Fork-Aktivierung erfordert, sollte es dennoch in die Dokumentation aufgenommen werden, um zu zeigen, dass Entwickler es ernst meinen, es rechtzeitig für die Pectra-Mainnet-Aktivierung bereit zu stellen. Dagegen ist nichts einzuwenden.

Erhöhtes Blob-Gas-Limit

PeerDAS verändert die Art und Weise, wie Knoten Daten über die Peer-to-Peer-Netzwerkschicht von Ethereum verarbeiten und verbreiten. Damit Benutzer, insbesondere Layer-2-Rollups, von diesen Änderungen profitieren können, müssen Entwickler das aktuelle Limit von sechs Blobs pro Block auf einen höheren Schwellenwert erhöhen, was einen höheren Blob-Durchsatz (beliebige Daten) ermöglicht. Eine Änderung des Blob-Limits würde Änderungen am Ethereum-Kernprotokoll erfordern, was, wie Entwickler diese Woche auf einer Konferenz diskutierten, möglicherweise komplexere technische Arbeiten erfordert als nur die Optimierung eines konstanten Werts im Protokollstapel.

Stokes schlug vor, die Abhängigkeiten zwischen der Ausführungsschicht (EL) und der Konsensschicht (CL) zu entkoppeln, wenn Blob-Gas-Grenzwerte geändert werden. Derzeit erfordern alle Änderungen der Blobgas-Grenzwerte Änderungen an den EL- und CL-Protokollen. Stokes schlug Möglichkeiten vor, diese Abhängigkeiten zu durchbrechen und es Entwicklern zu ermöglichen, fest codierte Blobgas-Grenzwerte sicher aus EL zu entfernen und sie vollständig dem CL zu überlassen. Der Forscher der Ethereum Foundation (EF), Dankrad Feist, wies darauf hin, dass neben dem Abhängigkeitsproblem zwischen EL und CL auch die Folgewirkung der Änderung des Blob-Gaslimits auf die Gasberechnung des Blocks wichtig ist. Feist sagte: „Der beste Weg ist, die Art und Weise der Berechnung zu ändern. Es ist wahrscheinlich ein Fehler, dass die Gaspreisberechnung in EL erfolgt. Das sollte in CL sein, aber es ist jetzt schwieriger zu ändern. ... Es ist nicht einfach.“ "

Die Entwickler haben vereinbart, weiterhin zu untersuchen, wie Änderungen an den Blob-Gasgrenzwerten und Gasberechnungen innerhalb von Blöcken am besten vorgenommen werden können. Die Entwickler einigten sich außerdem darauf, die Diskussionen darüber fortzusetzen, ob die Aktivierung von PeerDAS in Pectra mit einer Erhöhung des Blob-Gas-Limits einhergehen würde. Die Entwickler sind sich uneinig, ob die Änderungen gemeinsam ausgerollt oder in Phasen über mehrere Hard Forks hinweg implementiert werden sollen.

Jayanthi sagte, dass die Einbeziehung dieser Änderungen eine „riskante“ Entscheidung sei, da Entwickler nicht wissen, wie PeerDAS funktionieren wird, bis es im Mainnet aktiviert wird. Der DevOps-Ingenieur der Ethereum Foundation (EF), Barnabas Busa, fügte hinzu, dass der Umfang des Pectra-Hard-Forks bereits sehr groß sei und keine zusätzlichen Codeänderungen erforderlich sei. „Der Schlüssel ist, dass wir bereits viele EIPs haben und ich habe das Gefühl, dass wir immer mehr hinzufügen und es nie endet“, sagte Busa. „Also müssen wir irgendwo eine Grenze ziehen und dort enden wir. Ich denke, das wird der Fall sein.“ Es ist unmöglich, PeerDAS in den nächsten anderthalb Testjahren zu veröffentlichen und die Anzahl der Blobs zu erhöhen. Es kann PeerDAS entfernt werden, um „Pectras Risiko zu verringern“. Francesco fragte: „Was ist der Vorteil von Pectras PeerDAS, wenn es die Anzahl der Blobs nicht erhöht?“

Um die Schwierigkeit des PeerDAS-Tests weiter zu veranschaulichen, wies Jayanthi darauf hin, dass der Test von EIP 4844, der Blobs in Ethereum einführte, Blobs nicht vollständig simulierte auf die tatsächliche Leistung und Auswirkung des Ethereum-Mainnets. Jayanthi sagte: „Das Problem ist, dass das Testen des Netzwerks sehr schwierig ist. Wir hatten viele tolle Tests im Zusammenhang mit 4844, aber die Blobs zeigten im Mainnet nicht genau die gleiche Leistung wie in den Tests. Wir haben schwächere Knoten gesehen.“ Frage: Wir sehen zeitliche Herausforderungen und solche Dinge, weshalb wir zwar eine perfekte Situation im Entwicklungsnetzwerk simulieren können, in der PeerDAS und die Erhöhung der Anzahl der Blobs keine praktischen Auswirkungen auf das Mainnet haben Das heißt, das ist der Hauptgrund, warum ich denke, dass wir es Schritt für Schritt tun sollten, anstatt alles auf einmal zu tun.“

EF-Forscher Ansgar Dietrichs meinte, es sei ein Fehler, die Erhöhung der Blob-Anzahl mit PeerDAS in Verbindung zu bringen, da PeerDAS allein bereits von den Entwicklern verlangt, einen Wert für die Blob-Anzahl festzulegen. Während Entwickler die gleiche Nummer wie im Ethereum-Mainnet wählen können, muss eine Entscheidung darüber getroffen werden, welche Nummer PeerDAS verwenden soll. Der einzige Grund für die Wahl derselben Nummer besteht darin, dass die Entwickler die Komplexität von PeerDAS erhöht haben, um im Fehlerfall auf den Blob-Propagationsmechanismus der aktuellen Deneb-Spezifikation zurückgreifen zu können. Dietrichs fügte hinzu, dass Bedenken hinsichtlich der Testkomplexität seine Ansicht, dass Pectra über zwei Hard Forks und nicht über eine aktiviert werden sollte, weiter bestärken, aber das bedeutet nicht, dass er der Meinung ist, dass PeerDAS von Änderungen der Blob-Anzahl entkoppelt werden sollte.

SSZ-UPDATE

Kissling hat ein Fortschrittsupdate zu drei SSZ-bezogenen EIPs geteilt. Er wies darauf hin, dass die Implementierung dieser EIPs bereits bei mehreren Kunden im Gange sei, darunter Teku, Grandine und Lighthouse. Entwickler können mit der Diskussion über den Zeitplan des Entwicklungsnetzwerks für diese SSZ-EIPs beginnen und sie möglicherweise beim nächsten ACDC-Treffen in den Umfang des Pectra-Upgrades einbeziehen, sagte er.

F-Star Naming

Es gibt einen Beitrag auf Ethereum Magicians, in dem der Name des nächsten Ethereum Consensus Layer (CL)-Upgrades nach Electra diskutiert wird. Die Entwickler haben sich für einen Namen für das Executive Layer (EL)-Upgrade nach Prag entschieden: Osaka. Kandidaten für CL-Upgrades sind: Fulu, Felis, Formosa und Funi. Diese Namen folgen der Namenskonvention der großen Sterne, beginnend mit „F“ und eignen sich für das sechste netzwerkweite Upgrade der Beacon Chain. Stokes bat die Entwickler während des Anrufs, sich zu dem Thema im Magicians-Thread zu äußern.

Das obige ist der detaillierte Inhalt vonZusammenfassung des letzten Treffens der Ethereum-Kernentwickler: Aktivierung von PeerDAS, Erhöhung des Blob-Gas-Limits. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!