Zusammenfassung des letzten Treffens der Ethereum-Kernentwickler: endgültiger Fortschritt des Dencun-Upgrades und Diskussion des Pectra-Upgrade-Umfangs

Zusammengestellt von: Luccy, BlockBeats

Der Ethereum Core Developer Consensus Call (ACDC) wird regelmäßig abgehalten, um Anpassungen am Ethereum Consensus Layer (CL) zu besprechen und zu koordinieren. Der letzte ACDC-Aufruf war der 129., bei dem Entwickler die neuesten Fortschritte bei den Vorbereitungen für das Dencun-Upgrade teilten und den Umfang und die EIP von Pectra, dem nächsten Ethereum-Upgrade, diskutierten.

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 7. März 2024 versammelten sich Ethereum-Entwickler auf Zoom, um am All Core Developers Consensus teilzunehmen (ACDC) rufen Sie das Treffen Nr. 129 an. Der ACDC-Aufruf ist eine zweiwöchentliche Reihe von Treffen, die vom Forscher der Ethereum Foundation, Danny Ryan, veranstaltet werden und bei denen Entwickler Änderungen am Ethereum Consensus Layer (CL) diskutieren und koordinieren. Diese Woche haben Entwickler ein letztes Update zu den Vorbereitungen für das Dencun-Upgrade veröffentlicht, das am Mittwoch, dem 13. März, im Mainnet aktiviert werden soll. Sie diskutierten auch den Umfang des nächsten Ethereum-Upgrades, Pectra, sowie einige Forschungsthemen, darunter die Blockwertstandardisierung unter CL-Kunden.

Deneb

Ryan erinnerte alle zu Beginn der Telefonkonferenz daran, dass das Dencun-Upgrade in weniger als einer Woche auf Ethereum live gehen würde. Er erwähnte auch, dass es für viele Amerikaner dieses Wochenende am 10. März beginnen würde Da alle ACD-Konferenzgespräche und -Upgrades auf der Grundlage der koordinierten Weltzeit (UTC) ohne Einhaltung der Sommerzeit geplant sind, müssen Entwickler und Anrufteilnehmer außerhalb der USA ihre Zeitpläne entsprechend anpassen Das Team gab bekannt, dass es plant, in den kommenden Tagen zeitgleich mit dem Dencun-Upgrade eine aktualisierte Version der Software zu veröffentlichen. Die Teams Prysm, Lighthouse und Teku werden voraussichtlich bis Ende der Woche neue Versionen veröffentlichen. Obwohl es sich bei diesen aktualisierten Versionen nicht um obligatorische Upgrades handelt, stellte Tim Beiko von der Ethereum Foundation während des Zoom-Meetings fest, dass sie den Blog-Beitrag, der alle Dencun-kompatiblen Versionen zusammenfasst, nicht aktualisieren werden.

Chris Hager vom Flashbots-Team hat ein kurzes Update zur MEV-Boost-Softwarebereitschaft geteilt. Hager bestätigte, dass die letzte Woche veröffentlichte MEV-Boost-Version 1.7 stabil ist und von Validator-Knotenbetreibern verwendet werden kann. Die Flashbots-Builder-Software für Deneb befinde sich noch in der Entwicklung und werde voraussichtlich noch in dieser Woche fertiggestellt und zusammengeführt, sagte er. Bezüglich der Bereitschaft der Validatoren für das Upgrade äußerte Hager seine Besorgnis darüber, dass offenbar nicht genügend Validatoren ihre MEV-Boost-Software aktualisiert haben, um das Dencun-Upgrade zu unterstützen. Nach Überprüfung seiner Daten sagte Hager, dass etwa 50 % der mit Flashbots-Relays verbundenen Validatoren die neueste MEV-Boost-Version, v1.7, verwenden.

Beiko wies weiter darauf hin, dass seine Quellen, Metrika und Ethernets, zeigen, dass etwa die Hälfte der Ethereum-Knoten für ein Upgrade auf Dencun bereit sind. Er äußerte auch die Hoffnung auf ein Datentool, das die Bereitschaft von Validierungsknoten für Upgrades verfolgen kann, nicht nur aller Ethereum-Knoten.

Electra

Ethereum-Entwickler diskutierten vier Codeänderungen im Zusammenhang mit dem Pectra-Upgrade.

EIP 7459

Der erste ist Ethereum Improvement Proposal (EIP) 7549, der es CL-Kunden ermöglicht, Stimmen für Blöcke (auch Attestierungen genannt) effizienter zu sammeln. Die Entwickler stimmen früheren Empfehlungen zur Integration von EIP 7549 in Pectra zu. Teku-Entwickler Mikhail Kalinin teilte weitere Analysen zur Implementierung von EIP 7549 auf Ethereum mit und schlug einige Kompromisse oder „negative Auswirkungen“ vor, die durch die Codeänderung entstehen könnten. Ryan schlug vor, dass Kalinin seine vorgeschlagenen Änderungen an der CL-Spezifikation direkt auf GitHub zusammenfasst, um weiteres Feedback und eine Überprüfung zu erhalten.

Prysm-Entwickler Terence Tsao sagte, er sei mit der von Kalinin vorgeschlagenen EIP 7549-Implementierung einverstanden, empfiehlt jedoch weitere Dokumentation und Spezifikation für die Beacon-API-Änderungen, die mit dieser EIP notwendig sind. „Wenn Sie heute 10 Aggregatoren im selben Slot haben, müssen Sie 10 Bescheinigungen signieren. Mit dieser Änderung müssen Sie dann nur eine Nachricht senden, sodass Sie möglicherweise einige Änderungen an der Beacon-API vornehmen müssen“, sagte Tsao und fügte Dao hinzu „Ich denke, in diesem Teil muss möglicherweise mehr darüber nachgedacht werden, wie die Integration des Beacon-API-Validators geändert werden kann, um dieses Problem zu lösen.“ Als Hintergrund dient die Beacon-API als Spezifikation von CL, die es Knoten ermöglicht, das Netzwerk abzufragen und Informationen über den Status zu erhalten das Netzwerk.

Geringere Ausgabe

Dann teilte der EF-Forscher Ansgar Dietrichs ein kurzes Update zu seinem Vorschlag mit, die Einsatzprämien durch eine geringere Netzwerkausgabe zu reduzieren. Er sagte, es habe „gemischte Rückmeldungen aus der Community“ gegeben, seit der Vorschlag beim letzten ACDC-Aufruf vorgestellt wurde. Er bekräftigte, dass es sich bei dem Vorschlag um eine kleine Codeänderung handele, die in einem Last-Minute-Upgrade von Electra bis Juni oder Juli enthalten sein könnte, vorausgesetzt, das Mainnet erfährt im Oktober einen Hard Fork. Dietrichs sagte jedoch auch, dass die Gespräche „im Gange“ seien, was bedeutet, dass die Idee weiter diskutiert werden müsse, bevor eine Entscheidung getroffen werde.

EIP 7547

Drittens schlug EF-Forscher Mike Neuder EIP 7547 vor, das Listen zur weiteren Diskussion enthält. Er sagte, eine zweite Breakout-Sitzung zur Erörterung der „genauen Merkmale“ des EIP-Designs wäre nützlich und er erwäge, eine solche am kommenden Freitag, dem 15. März, zu organisieren. Er erwähnte auch, dass die EIP über einen speziellen Discord-Kanal namens „Inclusion List“ verfügt, den Personen nutzen sollten, die mehr über den Vorschlag erfahren oder Fragen stellen möchten. Tsao sagte auch, dass die Spezifikationen für den Vorschlag seit dem ersten Breakout-Meeting zur Aufnahmeliste am 16. Februar weitgehend konkretisiert worden seien. „Ich denke, die Spezifikation ist wahrscheinlich zu etwa 75 % vollständig“, sagte Tsao und fügte hinzu, dass es einige andere Komponenten der Spezifikation gebe, die verbessert werden müssten, wie etwa Änderungen an der Ausführungs-API und Spezifikationen rund um ehrliche Validatoren.

EIP 7251

Schließlich äußerte Lighthouse-Entwickler Mark Mackey seine Unterstützung für EIP 7251, das das maximal effektive Guthaben (maxEB) erhöht. „Wir haben in Lighthouse fast einen Prototypen erstellt. Es gibt noch einiges an Arbeit an der Spezifikation zu erledigen, aber es sieht nicht wirklich nach viel Arbeit aus, und wenn man die Größe des Validator-Sets bedenkt, ist es eine Art tickende Zeitbombe.“ „Wir haben vorgeschlagen, Optimierungsvorschläge zu veröffentlichen, Release-Änderungen sind immer umstritten, daher gibt es keine Garantie dafür, dass die Community es akzeptiert, und wenn es ihr nicht gefällt, können wir nur maxEB wirklich tun“, sagte Mackey. Ryan sagte, der größte Widerstand gegen die Integration von maxEB in Electra sei auf die Komplexität der Codeänderungen zurückzuführen, wie in früheren Anrufen mit dem Prysm-Team zum Ausdruck kam. „Potuz“, ein anonymer Entwickler im Prysm-Team, sagte in einem Zoom-Meeting-Chat, dass sein Team das EIP noch einmal überprüfen und die Komplexität des Vorschlags neu bewerten werde. Ryan forderte die Account-Teams auf, sich auf den nächsten ACDC-Anruf in zwei Wochen vorzubereiten, um eine „feste Entscheidung“ zu den EIPs 7547 und 7251 zu treffen.

Key Manager API-Standardisierung

EF Developer Operations (DevOps)-Ingenieur Barnabas Busa erklärte, dass alle CL-Clients offenbar leicht unterschiedliche Methoden zur Generierung von Validierungsschlüsseln haben, mit denen Validatoren betrieben und der erforderliche Verschlüsselungsschlüssel widerrufen werden. Es gibt APIs namens „Key Manager APIs“, die Validator-Knotenbetreibern bei der Schlüsselverwaltung und dem Beitreten und Verlassen von Validatoren helfen. Busa erklärte, dass subtile Unterschiede zwischen Clients bei der Rückgabe von Werten für diese API das Testen von API-Endpunkten erschweren. Er erwähnte auch, dass sein Team mit grundlegenden Tests von Hybrid-Validatoren begonnen hat, was bedeutet, dass die Betreiber von Validator-Knoten einen anderen Client für ihre Beacon-Knoten verwenden als der Validator-Client. Beacon-Knoten sind Clients, die den CL-Status beibehalten, aber nicht die Schlüsselpaare verwalten, die Validatoren für die Teilnahme am Konsens benötigen. Validator-Clients sind Clients, die Schlüsselpaare verwenden, um Blöcke zu generieren und Beweise in der Kette zu signieren. Ryan schlug Busa vor, eine Dokumentation oder Pull-Anfrage mit einem Vorschlag zur Standardisierung der Schlüsselmanager-API zu starten. Die Entwickler des Anrufs unterstützen auch weitere Tests, um sicherzustellen, dass der Hybrid-Validator auf allen CL-Client-Kombinationen funktioniert.

Block Value Beacon API-Standardisierung

Ein Nimbus-Entwickler mit dem Benutzernamen „Dustin“ äußerte auch Bedenken hinsichtlich der CL-Standardisierung der Beacon-API-Endpunkte „productBlockV3“ und „getBlockRewards“. Dustin erklärte, dass einige Bereiche der Beacon-API nicht klar definiert und bei Kunden „nicht allgemein implementiert“ seien. Insbesondere wenn es um Endpunkte geht, die Blockwerte zurückgeben sollen, sollte die Berechnung zumindest die Änderung der Validator-Salden vor und nach dem vorgeschlagenen Block umfassen. In der Spezifikation wird jedoch nicht detailliert dargelegt, ob Kunden Belohnungen und Strafen für Änderungen im Guthaben eines Prüfers aufgrund der Handlungen eines anderen Prüfers einbeziehen sollten. Dazu gehören beispielsweise gleichzeitige Zuweisungen oder Strafen für Ausschusspflichten, Selbstkürzungen des Antragstellers oder Zertifizierers sowie Whistleblower-Auszeichnungen. Ryan stimmt zu, dass der Beacon-API Anweisungen hinzugefügt werden sollten. Andere Entwickler im Gespräch, darunter Radosław Kapka und Potuz vom Prysm-Team, waren jedoch weniger zuversichtlich. Potuz äußerte seine Besorgnis darüber, dass die Anzahl der Personen, die diese Endpunkte verwenden, gering ist und in der Lage ist, ihre eigenen Tools zu verwenden, um Blockwerte von verschiedenen CL-Clients zu normalisieren. „Ich verstehe nicht einmal, warum wir einer Unterstützung zustimmen würden, wenn den Verbrauchern Beschränkungen auferlegt würden. Ich würde versuchen, diese Märkte zu untersuchen und herauszufinden, ob wir diese Arbeit tatsächlich an die Menschen senden können, die diese Endpunkte nutzen, anstatt an uns selbst“, sagte Potuz.

Nimbus-Entwickler Jacek Sieka widerlegte diese Ansicht und sagte, dass Entwickler aufgrund der Existenz des „productBlockV3“-Endpunkts Inkonsistenzen zwischen Clients beheben oder den Endpunkt zugunsten von „V4“ ablehnen müssten. Darüber hinaus fügte Sieka hinzu: „Ich denke, dieser Endpunkt ist nur eine sehr grundlegende Funktionalität. Wenn wir uns eine Zukunft vorstellen, in der wir mehrere Blockquellen haben und diese vergleichen müssen, dann macht das Sinn. So einfach ist das. Ryan hat Dustin geraten, einen Vorschlag zu erstellen.“ um V3 und den „getBlockRewards“-Endpunkt zu standardisieren. Sobald der Vorschlag erstellt ist, wird das Account-Team erneut prüfen, ob sie weiterhin unterstützt werden sollen.

Der Rest

Potuz hat zwei Projekte für weiteres Entwickler-Feedback und Diskussion markiert. Beim ersten geht es um das Client-Verhalten der Ausführungsschicht (EL) bei späten Blöcken, das derzeit nicht in der Engine-API angegeben ist, die die Kommunikation zwischen EL und CL spezifiziert. „Wenn dies in der Engine-API angegeben werden könnte, würde es uns die Neuorganisation späterer Blöcke erleichtern“, sagte Potuz. Der zweite Punkt, den Potuz erwähnte, betraf seine Analyse des Payload-Upgrades Proposer Builder Separation (ePBS), ein Upgrade, das die Notwendigkeit vertrauenswürdiger Relays auf Ethereum überflüssig machen würde. Potuz bat um zusätzliches Feedback zur Analyse und anderen Einschränkungen des ePBS-Designs.

Schließlich kündigte Pooja Ranjan von der Ethereum Cat Herder-Gruppe die Bildung einer neuen Arbeitsgruppe namens Women in the Ethereum Protocol (WiEP) an. WiEP ist eine neue Organisation der Ethereum Foundation, die sich der Förderung und Entwicklung weiterer weiblicher Ethereum-Protokollentwickler widmet. Ranjan sagte, die Gruppe werde am 8. März ein einstündiges Webinar veranstalten, um mit mehreren weiblichen Mitwirkenden des Ethereum-Protokolls zu diskutieren.

Ryan gab dann bekannt, dass er ab dem 1. April eine dreimonatige Pause einlegen wird. In seiner Abwesenheit wird EF Fellow Alex Stokes den ACDC-Aufruf moderieren.

Das obige ist der detaillierte Inhalt vonZusammenfassung des letzten Treffens der Ethereum-Kernentwickler: endgültiger Fortschritt des Dencun-Upgrades und Diskussion des Pectra-Upgrade-Umfangs. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!