Zusammenfassung des letzten Treffens der Ethereum-Kernentwickler: Mainnet-Status- und Wachstumsdatenanalyse, Prager Upgrade-Vorschlag

Originaltitel: „Ethereum All Core Developers Execution Call #184 Writeup“
Originalautor: Christine Kim
Zusammengestellt von: Luccy, BlockBeats

.
Anmerkung des Herausgebers:

In der Ethereum-Community findet alle zwei Wochen der All Core Developers Consensus Call (ACDE) statt, um Verbesserungen am Ethereum Execution Layer (EL) zu diskutieren und auszuhandeln. Dies ist die 184. Telefonkonferenz von ACDE. Die Diskussion wird sich auf die Gründe für den Anstieg der Anzahl fehlerhafter Blöcke am 27. März sowie auf die neue Forschung des Paradigm-Teams zum Status und historischen Wachstum von Ethereum konzentrieren.

Entwickler diskutierten auf der Konferenz über Bloxroute-MEV-Relay-Probleme und zwei rückwirkende EIPs in Prag/Electra. Darüber hinaus wurden Entwicklungsupdates für EIP 7547 (Inclusion List), EIP 5920 (PAY Opcodes) und EIP 7545 (Verkle Proof Verification Precompilation) besprochen.

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 28. März 2024 berief die Ethereum-Entwicklungsgemeinschaft ein Zoom-Meeting für die All Core Developers ein Execution (ACDE)-Aufruf Nr. 184. Der ACDE-Aufruf ist eine zweiwöchentliche Reihe von Treffen, bei denen Entscheidungen im Zusammenhang mit der Entwicklung von Ethereum besprochen und koordiniert werden. Tim Beiko, der von der Ethereum Foundation unterstützte Hauptkoordinator, leitete die Diskussion und die Konsensbildung zu vorgeschlagenen Änderungen an den Ethereum Improvement Proposals (EIPs)

Diese Woche teilten Entwickler am 27. März Erkenntnisse darüber mit, was den Anstieg falscher Blöcke verursacht hat. Prysm-Entwickler Terence Tsao sagte, der Anstieg sei auf ein Problem mit dem Bloxroute MEV-Relay zurückzuführen, an dem das Bloxroute-Team arbeitet. Die Entwickler diskutierten auch wichtige Punkte aus neuen Forschungsarbeiten des Paradigm-Teams zum Zustand und historischen Wachstum von Ethereum. Die Entwickler stimmten der Aufnahme von zwei rückwirkenden Ethereum Improvement Proposals (EIPs) in Prag/Electra zu, EIPs 7610 und 7523.

Schließlich teilten sie Entwicklungsaktualisierungen zu anderen EIP-Kandidaten wie EIP 7547 (Einschlussliste), EIP 5920 (PAY-Opcodes) und EIP 7545 (Verkle Proof Verification Precompilation).

Mainnet-Ereignis zu fehlenden Blöcken

Am 27. März stieg die Anzahl der fehlenden Blöcke. Normalerweise werden bei Ethereum alle 30 Minuten 2 bis 4 % der Blöcke übersehen. In Zeiten, in denen im Netzwerk eine große Anzahl von Blob-Transaktionen stattfindet, steigt dieser Prozentsatz jedoch innerhalb weniger Stunden auf über 14 %. Die Blob-Preise stiegen in diesem Zeitraum um mehr als das Zehnfache. Tsao sagte, das Problem der fehlenden Blöcke sei sofort gelöst worden, nachdem das Bloxroute-Team sein MEV-Relais abgeschaltet habe. Die Details, die das Bloxroute-Relay-Problem verursachen, sind unklar, und das Bloxroute-Team arbeitet an einer Lösung, die es in den kommenden Tagen zusammen mit einer vollständigen Obduktion des Problems veröffentlichen wird.

"Die gestrigen verpassten Blöcke bedeuten also nicht, dass Kunden diese Art von Arbeitslast nicht bewältigen können, denn im Grunde werden alle verpassten Blöcke durch Bloxroute-Probleme verursacht. Aber es gibt immer noch ein grundlegendes Problem, dass unter dem gestrigen Verkehr passieren wird. „Ich vermute, dass Kunden möglicherweise Blöcke langsamer importieren als zuvor, aber dafür habe ich keine schlüssigen Beweise, das bleibt abzuwarten“, sagte Tsao. Als Reaktion auf den Vorfall mit fehlenden Blöcken veröffentlichte das Lighthouse-Kundenteam eine „Hotfix“-Version zur Verbesserung der Knotenleistung und -stabilität. Während die Untersuchung noch läuft, erklärte Uri Klarman, CEO von Bloxroute, außerdem:

Ethereum Foundation Developer Operations Engineer Parithosh Jayanthi fragte, ob der Vorfall Entwickler dazu veranlassen würde, die Bedingungen der Client-Leistungsschalter neu zu bewerten, was automatisch dazu führt, dass Validatorknoten auf die lokale Blockproduktion zurückgreifen. Bei den meisten Clients ist der Standardwert für den Zustand des Leistungsschalters ein Ereignis, bei dem fünf Steckplätze hintereinander fehlen. Tsao wies darauf hin, dass zu leicht ausgelöste Leistungsschalterzustände potenzielle Angriffsvektoren seien, die hochentwickelte MEV-Akteure ausnutzen könnten.

Prysm-Entwickler „Potuz“ sagte, dass dieser Vorfall seiner Meinung nach die mangelnde Implementierung der Client-Diversität in Relays sowie die mangelnde Kommunikation zwischen Relay- und Protokollentwicklern verdeutlicht. „Terence hat über eine Woche lang über diese Blobs gesprochen, und niemand hat es bemerkt, und sobald sie explodieren, sind nur ein paar Anrufe erforderlich, um die richtigen Relais dazu zu bringen, sich ihre Protokolle tatsächlich anzusehen. Das ist inakzeptabel“, sagt Portuzzi

Einige Entwickler empfehlen, beim nächsten Mal, wenn sie Netzwerkverstöße melden, schriftliche Beiträge zu erstellen, um die Sichtbarkeit des Ethereum-Ökosystems zu erhöhen. Um den Vorfall mit fehlenden Blöcken weiter zu diskutieren, ermutigte Alex Stokes, Forscher der Ethereum Foundation, Entwickler, am nächsten MEV-Boost-Community-Aufruf teilzunehmen.

Analyse von Status- und historischen Wachstumsdaten

Der Datenwissenschaftler und Ingenieur Storm Slivkoff von Paradigm hat eine neue Analyse des Status und des historischen Wachstums von Ethereum durchgeführt. Seinen Erkenntnissen zufolge ist das Staatswachstum nicht der Hauptengpass für die Skalierbarkeit von Ethereum. „Wir haben herausgefunden, dass bestehende Verbraucherhardware die aktuellen nationalen Wachstumsraten über einen langen Zeitraum, wahrscheinlich Jahrzehnte, aufrechterhalten kann. Beachten Sie, dass ich hier nur über Speicherkapazität und Speicherkapazität spreche diesen Rahmen. Seiner Ansicht nach ist der „stille Killer“ von Ethereum das historische Wachstum.

In einer schriftlichen Analyse erklärte das Paradigm-Forschungsteam: „State ist der Datensatz, der zum Erstellen und Überprüfen neuer Ethereum-Blöcke erforderlich ist. State besteht aus Vertrags-Bytecode, Vertragsspeicher, Kontostand und Konto-Nonce „Der Verlauf besteht aus Blöcken und Transaktionen, und der Verlauf ist ein sich nicht überschneidender Datensatz“, fügte Slivkoff hinzu. Die größten Anwendungsfälle für historisches Wachstum sind Rollups und andere Arten von Protokollen, die mit Ethereum verbunden werden müssen

Slivkoff empfahl Entwicklern, ernsthaft darüber nachzudenken, EIPs zu beschleunigen, die das historische Wachstum im nächsten Ethereum-Upgrade Prag/Electra berücksichtigen, wie z. B. EIP 4444 und EIP 7623. Er sagte auch, dass weitere Analysen durchgeführt werden, um andere Skalierungsengpässe bei Ethereum zu analysieren Wenden Sie diese Methoden an, um den Skalierungsengpass des Rollups zu analysieren. Als nächsten Schritt in der Forschung sagte Slivkoff, dass alle Daten Open Source sein werden. Im Anschluss an Slivkoffs Präsentation diskutierten die Entwickler verschiedene Möglichkeiten, um das historische Wachstum anzugehen Kurzfristig bauen Entwickler, wie bei ACDE #180 besprochen, ein robustes alternatives Netzwerk mit bestimmten historischen Daten für Zeiträume auf, beispielsweise vor einem Merge-Upgrade, auf das Benutzer auch dann zugreifen können, wenn die Daten nicht über Ethereum-Knoten zugänglich sind Für weitere Diskussionen zum historischen Ablauf und zu alternativen Optionen für die Bereitstellung historischer Daten empfehlen die Geth-Entwickler, weiterhin Gespräche auf dem Ethereum R&D Discord-Kanal in einem Unterkanal-Thema mit dem Titel „History Expiration“ zu führen.

Retrospektive EIP IP 7610 und 7523

Entwickler stimmen der Implementierung von EIP 7610 und 7523 zu. Hierbei handelt es sich um rückwirkende EIPs, die dem Ethereum-Protokoll Regeln hinzufügen, die rückwirkend vom Beginn des Netzwerks an angewendet werden können, um bestimmte Verhaltensweisen in der Kette weiter einzuschränken. Der Vorteil dieser EIPs besteht darin, dass sie Ethereum-Testfälle vereinfachen und den Umfang verschiedener Randfälle einschränken, beispielsweise den Randfall der Erstellung eines leeren Kontos. Zwei EIPs, die rückwirkend angewendet wurden, sind EIPIP2681 und 3607. Der Entwickler erklärte sich bereit, zwei zusätzliche rückwirkende EIPs in Prag/Electra zu aktivieren. Hintergrundinformationen zu den Aktionen, die diese EIPs regeln, finden Sie hier im vorherigen Anrufprotokoll.

EIP 2537, BLS vorkompiliert

Das Geth-Kundenteam hat einige Benchmarks durchgeführt, um die Gaskosten für den EIP 2537 BLS-Kurvenbetrieb abzuschätzen. Diese neuen Unternehmen werden im Zuge des Prag/Electra-Upgrades aktiviert, und die Entwickler wägen derzeit die Preise für diese Unternehmen ab. Ein Vertreter des Reth-Teams sagte, sein Team werde außerdem zusätzliche Benchmarks für BLS-Kurvenbetriebe durchführen, um bei der Ermittlung der Gaskosten dieser Betriebe zu helfen.

EIP 7547, Einschlussliste

Wie auf ACDC #130 besprochen, erwägen die Entwickler dringend, EIP 7547 in das Prague/Electra-Upgrade aufzunehmen. Diese Woche teilte Mike Neuder, Forscher der Ethereum Foundation, die neuesten Informationen darüber mit, wie EIP 7547 so geändert werden kann, dass es vorwärtskompatibel mit der Kontoabstraktion ist. Account Abstraction ist eine fortlaufende Initiative zur Einführung größerer Flexibilität und Programmierbarkeit für External Accounts (EOA), bei denen es sich um benutzergesteuerte Konten auf Ethereum handelt. Neuder schlug drei verschiedene Möglichkeiten vor, um Kompatibilitätsprobleme zwischen EIP 7547 und dem Account Abstraction EIP zu lösen. Zu diesen Lösungen sagte Neuder: „Es fühlt sich zwar wie die Komplexität von inklusivem Design an, aber ich denke, dass diese drei Optionen funktionieren, und ich glaube nicht, dass es ein Allheilmittel geben wird, um dieses Problem zu lösen. Das tue ich nicht.“ Ich denke, wir werden es tun.“ Finden Sie ein besseres Design, das diese Probleme angeht.

Beiko schlug vor, die Diskussion über andere EIP-Kandidaten für die Aufnahme in das Listendesign in einer separaten Breakout-Sitzung für begrenzte Zeit fortzusetzen.

Als nächstes durchsuchten die Entwickler. Eine Liste Zu den anderen EIP-Kandidaten für das Prague/Electra-Upgrade gehören:

EIP 5920 (PAY-Opcode): Der Forscher der Ethereum Foundation hat mit der Testarbeit für diesen Opcode

EIP 7609 (Reduzierung der TLOAD/TSTORE) begonnen ): Der Vyper-Compiler-Mitarbeiter Charles Cooper bekräftigte seine Ansicht, dass TLOAD- und TSTORE-Opcodes im EVM günstiger sein sollten

EIP 2935 und 7545 (Historische Block-Hashes in der Vorkompilierung der Zustands- und Verkle-Beweisüberprüfung beibehalten): Geth-Entwickler Guillaume Ballet hat diese beiden Vorschläge als Codeänderungen vorgeschlagen, die künftige Vorteile für die Verkle-Implementierung bieten und gleichzeitig dazu beitragen, die Allgemeinheit zu alarmieren Ethereum-Ökosystem des bevorstehenden Verkle-Upgrades.

Ethereum Object Format (EOF): Besu-Client-Maintainer Danno Ferrin sagte, dass das EOF EIP von mehreren Client-Teams implementiert wird und Referenztests für sie geschrieben werden. Er bat die Entwickler, für detailliertere Updates die EOF Readiness Matrix zu konsultieren.

EIP 7212 und EIP 3074 (secp256r1-Kurvenunterstützung und Vorkompilierung von AUTH/AUTHCALL-Opcodes): Besu-Entwickler Matt Nelson hebt diese beiden EIPs hervor, die im L2-Rollup implementiert werden. Er betonte, dass diese beiden EIPs in Prag übernommen werden sollten, um die Kompatibilität zwischen Ethereum und Rollups zu fördern.

EIP 7664 (Zugriffsschlüssel-Opcode): Der OPLabs-Entwickler „Protolambda“ hat einen Ersatzvorschlag für EIP 3074 vorgeschlagen, der Zugriffslisten nutzt, um die Funktionalität des AUTH/AUTHCALL-Opcodes zu verbessern.

EIP 6493 (SSZ Transaction Signature Scheme): Protolambda brachte außerdem seine Unterstützung für SSZ-bezogene Codeänderungen zum Ausdruck, um die Sicherheit und Effizienz der Überprüfung von Ethereum-Daten zu verbessern.

Die Entwickler haben keine Zeit zu diskutieren, welche EIPs auf dieser Liste für Prag Vorrang haben sollten. Beiko sagte, die Zeit sei blockiert, die Liste zu Beginn der nächsten ACDE-Telefonkonferenz in zwei Wochen noch einmal durchzugehen. „Wir sollten uns in den nächsten Wochen intensiver mit allen heute aufgeworfenen Fragen befassen und an einer Entscheidung arbeiten. Ich denke, das bedeutet, dass wir, wenn wir vorankommen wollen, in zwei Wochen alles klären müssen, was noch nicht vollständig geklärt ist.“ „Nichts darf diese Gabelung betreten“, sagte Beiko.

Das obige ist der detaillierte Inhalt vonZusammenfassung des letzten Treffens der Ethereum-Kernentwickler: Mainnet-Status- und Wachstumsdatenanalyse, Prager Upgrade-Vorschlag. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!