Einblicke in Ethereum-Upgrades: Hegotá

Was Ethlabs für Hegotá priorisiert und warum.

Die Richtung von Ethereum ist für alle wichtig, die darauf aufbauen, es nutzen, ETH halten oder einfach an das glauben, was es werden kann. Auch wenn diese Zukunft letztlich von den Menschen, Anwendungen und Communities bestimmt wird, die täglich auf Ethereum aufbauen, sind Netzwerk-Upgrades einer der wichtigsten Wege, wie sich das Protokoll weiterentwickelt, um ihren Bedürfnissen gerecht zu werden. Hegotá ist das nächste geplante Ethereum-Netzwerk-Upgrade nach Glamsterdam, und dieses Dokument teilt die Ansicht von Ethlabs darüber, was wir glauben, dass Ethereum dafür priorisieren sollte, und warum.

Ethlabs ist ein 8 Wochen altes gemeinnütziges F&E-Labor für Ethereum und ETH und unsere Mission ist es, Ethereum zur Abwicklungsschicht der globalen Wirtschaft zu machen. Wir sitzen zwischen der realen Ethereum-Nutzung und der Protokollentwicklung und verbringen unsere Zeit damit, Nutzern, Wallets, Anwendungen, Rollups, Institutionen, ETH-Inhabern, Forschern und Client-Teams zuzuhören. Manchmal bauen wir sogar onchain, denn man kann keine Arena bauen, ohne daran teilzunehmen! Wir glauben, dass großartiges Protokoll-Engineering großartige Produkte ermöglichen sollte und großartige Produkte dazu beitragen sollten, die zukünftige Richtung des Protokolls zu bestimmen.

Der Umfang von Hegotá befindet sich derzeit in der frühen Phase der Formgebung durch den offenen technischen Prozess von Ethereum, und die folgenden Vorschläge spiegeln die Arbeit vieler Einzelpersonen sowie Forschungs- und Client-Teams wider. Dieses Dokument ist ein transparenter Bericht darüber, was wir empfehlen zu priorisieren und wo sich unsere Ansichten noch formen. Dies sind Positionen, die wir gerne von anderen evaluieren, hinterfragen und verbessern lassen würden, und wir werden sie im Laufe der nächsten Tage und Wochen weiterentwickeln, während wir diskutieren und mehr lernen.

Für das Hegotá-Upgrade sind dies, angesichts aller vorgeschlagenen EIPs, die Bereiche, die wir als höchste Priorität für Ethereum ansehen:

1. Stärkere Zensurresistenz: Jeder sollte in der Lage sein, eine Transaktion aufnehmen zu lassen, unabhängig davon, wer er ist oder wofür er Ethereum nutzt.
2. Schnelleres Ethereum: Schnellere Blöcke bedeuten schnellere Bestätigungen, frischere Onchain-Preise und schnellere Endgültigkeit.
3. Native Account-Abstraktion: Konten sollten Passkeys, gesponserte Transaktionen, Gaszahlungen in Token, Batching und stärkere Privatsphäre unterstützen, mit einem Weg zu Post-Quanten-Schlüsseln.
4. Fortgesetzte L1-Skalierung: Anwendungen benötigen Kapazität, die erschwinglich und vorhersehbar bleibt, auch wenn die Nachfrage steigt.

Transparent zu arbeiten ist ein Kernziel von Ethlabs, weshalb wir wöchentliche Updates schreiben und, bei Gelegenheiten wie dieser, sehr lange technische Beiträge veröffentlichen, um unsere Gedanken zu teilen 😅. Wir werden in den kommenden Wochen auch mehr mundgerechte Inhalte für diejenigen veröffentlichen, die nur die Highlights wollen. Dieser nächste Teil wird lang und technisch. Für diejenigen unter euch, die alles lesen: viel Glück!

Das Wichtigste zuerst: Wie funktioniert der EIP-Prozess überhaupt?

Bevor wir in die Vorschläge selbst eintauchen, ein wichtiger Punkt: Die zweite Phase des Scoping-Prozesses für Hegotá hat gerade erst begonnen. Die erste Phase hat FOCIL als Headliner von Hegotá ausgewählt. Am 6. August gab es eine Frist für die Einreichung von Nicht-Headliner-EIPs, und der ACD-Prozess wird nun dazu übergehen, das Hegotá-Upgrade in seiner Gesamtheit zu bewerten.

Alle unten aufgeführten EIPs befinden sich derzeit im PFI (Proposed for Inclusion) -Stadium, mit Ausnahme der EIPs, die den Headliner-Prozess durchlaufen haben. Ein EIP zur Aufnahme vorzuschlagen ist erlaubnisfrei, und die meisten schaffen es nie in das endgültige Upgrade.

Konkret durchlaufen Vorschläge mit fortschreitender Implementierungsarbeit progressiv stärkere Phasen der Überprüfung und Sicherheit, dass sie letztendlich ausgeliefert werden:

• PFI (Proposed for Inclusion): Eine Idee wurde für das Upgrade vorgeschlagen. Diese Phase ist erlaubnisfrei und impliziert keine Client-Unterstützung oder endgültige Aufnahme.
• CFI (Considered for Inclusion): Client-Teams haben den Vorschlag geprüft und beabsichtigen, ihn zu prototypisieren und zu testen.
• SFI (Scheduled for Inclusion): Es besteht eine breite Absicht, ihn aufzunehmen, vorausgesetzt, Implementierung und Tests verlaufen weiterhin gut.

Um mehr darüber zu erfahren, wie dieser Prozess funktioniert, empfehlen wir, sich Tim Beikos kurze Erklärung hier anzusehen.

Hausordnung: Wie man diesen Artikel navigiert

Wir folgen dem Forkcast-Tier-Ranking, um unsere Sicht auf die EIP-Priorisierung für Hegotá auszudrücken. Um die Entscheidung zu minimieren, ordnen wir alle überprüften EIPs in vier Stufen mit den folgenden Interpretationen ein:

• [S-Stufe] starke Empfehlung für Aufnahme.
• [A-Stufe] Empfehlung für Aufnahme, wenn verbleibende Hindernisse wie Implementierungskomplexität, Auswirkungsanalyse oder Adoption gelöst sind.
• [B-Stufe] lohnenswert, aber eine Dehnung für dieses Upgrade.
• [D-Stufe] keine Empfehlung für Aufnahme in Hegotá in seiner aktuellen Form.
• [Meinung bildet sich] Wir bilden uns noch unsere Meinung zu diesem EIP.

Bitte beachten Sie, dass dies \Empfehlungen\ von Ethlabs sind. Wir bewerten jeden Vorschlag hauptsächlich hinsichtlich Zweck, Spezifikation und unserem Verständnis der plausiblen Implementierungskomplexität, außer wenn wir mehr Sicherheit oder direkte Beteiligung haben (z.B. Frames und Quick Slots), und werden unsere Ansicht basierend auf Bewertungen von ethPandaOps, Testteams und Clients aktualisieren, während wir im Prozess voranschreiten.

[CL] bedeutet, dass ein EIP Consensus-Layer-Clients betrifft, und [EL] bedeutet, dass er Execution-Layer-Clients betrifft.

Beachten Sie, dass wir Co-Autoren sind und an mehreren EIPs beteiligt sind (einschließlich FOCIL, Frame Transactions und Quick Slots). Obwohl wir uns bemühen, alle EIPs unabhängig von unserer Beteiligung oder Nichtbeteiligung zu bewerten, bitten wir Sie, dies bei der Bewertung unserer Position zu berücksichtigen.

tl;dr

CL-Ranking

Sie können dieses spezifische [CL]-Ranking auf Forkcaster hier durchspielen.

EL-Ranking

Sie können dieses spezifische [EL]-Ranking auf Forkcaster hier durchspielen.

Nun, ohne weitere Umschweife, hier unsere Ansichten zum Hegota-Upgrade, wie sie heute stehen, in ihrer Gesamtheit:

Themen für Hegotá

0. FOCIL: Zensurresistenz stärken

EIP-7805: FOCIL ist bereits SFI'd und als Headliner von Hegotá bestätigt. Drei Mitglieder des Ethlabs-Teams (Francesco, Barnabé und Julian) gehören zu seinen Co-Autoren, und wir unterstützen seine Aufnahme nachdrücklich. Da die Entscheidung bereits feststeht, halten wir es kurz. Nur eine Kette, die gegenüber allen neutral ist, kann zur Vertrauenswurzel für alle werden. Das ist es, was Ethereum ermöglicht, zur wahren Abwicklungsschicht für die globale Wirtschaft zu werden, und für jeden einzelnen Menschen darin.

1. Quick Slots: Schnelleres Ethereum

Ethereums 12-Sekunden-Slot ist ein Latenzkostenfaktor, der den Benutzerwert verschlechtert. Daher empfehlen wir dringend, [CL] EIP-8198: Quick Slots [S-Stufe] in Hegotá aufzunehmen, und zwar aus vier Gründen:

1. Verbesserte UX auf L1 mit schnellerer Transaktionsbestätigung.
2. Onchain-Märkte auf L1 arbeiten mit frischeren Preisen, was Spreads und LP-Ökonomie verbessert.
3. Endgültigkeit und die Schnellbestätigungsregel erben die Slot-Zeit, sodass beide mit schnelleren Blöcken schneller werden, was die Interoperabilität mit Ethereum verbessert.
4. Mehr Block-Proposer pro Sekunde bedeutet erhöhte Zensurresistenz, einschließlich wirtschaftlicher Zensurresistenz: der Betrag, den Sie zahlen müssen, um Blöcke für einen bestimmten Zeitraum leer zu halten.

Schneller zu werden, während Ethereums einzigartige Dezentralisierung erhalten bleibt, macht Ethereum-Blockspace wertvoller, und dieser Wert kommt dem Netzwerk und ETH zugute. Jede Verringerung ist ein sofortiger Mehrwert für unsere Nutzer. Schließlich stehen schnellere Blöcke als eine der am meisten nachgefragten Änderungen von Anwendungsentwicklern.

Das Argument, jetzt zu beginnen, ist, dass eine Slot-Zeit-Reduzierung niemals eine einmalige Änderung sein wird. Wie bei der Skalierung geben gelieferte Reduzierungen den Anwendungen mehr Sicherheit als Roadmap-Verpflichtungen. Der Weg zu Sub-6-Sekunden-Slots beginnt damit, die Slot-Zeit änderbar zu machen und sie dann iterativ zu ändern. EIP-8198 teilt die Arbeit in zwei Teile:

• Ein einmaliges Refactoring, das die Aktualisierung der Slot-Zeit in Spezifikationen und Client-Code erleichtert.
• Eine erste Verringerung in Hegotá, gefolgt von weiteren Verringerungen in nachfolgenden Forks, während die Roadmap fortschreitet und empirische Belege für die Sicherheit gewonnen werden.

Hegotá ist der richtige Fork, um die einmaligen Kosten zu tragen. ePBS in Glamsterdam restrukturiert bereits den Slot. Hegotá ist dann ein vergleichsweise leichter Fork für die Consensus-Layer, ein Fenster, das sich mit entkoppeltem Konsens in I* schließt, sodass die CL-Bandbreite für das einmalige Refactoring jetzt verfügbar ist, und zwar in einer Weise, wie sie es für mehrere Forks nicht wieder sein wird.

Bedeutung: Entweder wir verpflichten uns, für mindestens die nächsten zwei Jahre bei 12 Sekunden zu bleiben, oder wir landen in ~einem Jahr in Hegotá bei 10 Sekunden und möglicherweise im Jahr darauf bei weniger als 10 Sekunden. Diese beiden Verringerungen sind keine theoretischen Verbesserungen. Sie führen direkt zu erhöhtem Benutzerwert und verbesserten Netzwerkökonomien. Wir denken, es ist Zeit, anzufangen.

Die häufigsten Gegenargumente

Wir diskutieren hier 4 wichtige Punkte, die während der vorläufigen Diskussionen mit Client-Entwicklern und dem EF-Protokoll aufkamen:

1. Implementierungskomplexität: Millisekunden-genaues Slot-Timing ist bereits durch die ePBS-Arbeit in die Consensus-Spezifikationen eingeflossen, und es existieren Entwürfe für CL und EL Spezifikationen für EIP-8198, mit neu skalierten Basisgebühren, Gaslimits und Blob-Zeitplänen, um das Pro-Sekunde-Verhalten zu erhalten. Die verbleibenden Kosten sind ein Schwanz von Randfällen in Clients und Tooling, die eine feste Slot-Zeit annehmen, plus Tests. Das einmalige Refactoring verlagert genau diese Arbeit nach vorne. Danach ist jede Verringerung eine Parameteränderung.

2. zkEVM-Beweis: Die beiden Hauptprobleme sind die relative Beweiszeit und der konstante Beweis-Overhead.

2.1 Die relative Beweiszeit misst den Anteil der Slot-Zeit, der für das Beweisen aufgewendet wird, und wie sich dieser Anteil ändert, wenn sich die Slot-Zeit ändert. Hier ist eine kurze Beschreibung der relevanten Momente im Slot. Aktuelle Builder beobachten die Freigabe des vorherigen Payloads und können sofort mit dem Bauen beginnen. Der aktuelle Beacon-Block verpflichtet sich dann zum Payload des aktuellen Slots. Dieser Payload muss bewiesen werden, bevor der nächste Beacon-Proposer-Block freigegeben wird.

Für das Beweisen ist die minimale relative Zeit ein voller Slot, abzüglich der Latenz einer Beacon-Block-Freigabe. Die Latenz der Beacon-Block-Freigabe ist nicht komprimierbar, aber konstruktionsbedingt kurz und schränkt uns daher in diesem Stadium nicht grundlegend ein. Es besteht auch die Möglichkeit, dass optimierte Builder den Payload während des Bauens mitbeweisen, sodass sie mit dem Beweisen beginnen können, bevor der Gewinner-Payload vom Beacon-Block-Proposer bestätigt wird.

2.2 zkEVM-Beweis skaliert meist linear mit der Blockgröße, mit Ausnahme eines gewissen festen Overheads. Schnellere Slots bedeuten, dass der feste Overhead häufiger bezahlt wird, was für denselben Durchsatz mehr Latenz hinzufügt. Bei einem gegebenen festen Latenzbudget muss man dann sicherstellen, dass immer noch ein guter Durchsatz erzielt werden kann. Hier sehen wir zwei Möglichkeiten: Erstens wird der technische Fortschritt die Latenz dieser festen Operationen weiter senken. Zweitens verschiebt die Verzögerung der State-Root-Berechnung, wie in EIP-7862 beschrieben, mehr vom Beweisen außerhalb des kritischen Pfades, was bedeutet, dass wir unser Latenzbudget für nicht komprimierbare Operationen erhöhen können. Die Konvergenz dieser beiden Möglichkeiten sagt uns, dass schnellere Slots reichliche Durchsatzsteigerungen in der Zukunft nicht behindern werden.

3. Post-Quanten-Übergang: Der entkoppelte Konsensansatz hat genügend Unterstützung erhalten, um als stabil in Bezug auf die zukünftige Konsensarchitektur angesehen zu werden. Entkopplung bedeutet, die Finalitätsabstimmung außerhalb des kritischen Pfades der Blockproduktion zu bewegen. Insbesondere die groß angelegte Aggregation von PQ-Signaturen und die gesamte damit verbundene rekursive STARK-Mechanik werden außerhalb des kritischen Pfades liegen. Was für die Produktion von Blöcken und die Erlangung einer Fork-Choice-Regel zur Verfolgung des Kopfes der resultierenden Kette übrig bleibt, ist ein Unterausschuss, der derzeit voraussichtlich 512 Validatoren umfasst, möglicherweise 256. Post-Quanten-Signaturgrößen sind größer, aber innerhalb der vorgeschlagenen Slot-Zeit von 10 s und wahrscheinlich weniger in der Zukunft komfortabel zu propagieren.

4. Smart Contracts und Infrastruktur: Die Abhängigkeit von der Slot-Zeit in Smart Contracts und Infrastruktur wird derzeit untersucht. Für Smart Contracts haben wir eine Partnerschaft mit Sourcify geschlossen, um eine Analyse aller verifizierten Verträge durchzuführen. Wir untersuchen die Auswirkungen einer Slot-Zeit-Aktualisierung auf historische Beacon-Block-Roots, wie sie gemäß EIP-4788: Beacon block root in the EVM gespeichert werden. In Bezug auf die Infrastruktur erwähnte Etherscan anekdotisch, dass eine Slot-Zeit-Änderung wahrscheinlich zu mehr Last führen würde, die Infrastruktur jedoch zur Zeit variabler Slot-Zeiten im Proof-of-Work aufgebaut wurde und daher keine großen Änderungen erforderte.

2. Account-Abstraktion: UX, Sicherheit und Privatsphäre verbessern

Ethereum und sein breiteres Ökosystem haben eine native AA schon lange verdient, die UX-Vorteile wie Passkey-Wallets, gesponserte Transaktionen, ERC20-Gaszahlungen, Transaktions-Batching und mehr mit sich bringen wird.

Der Weg zur nativen AA war jedoch besonders holprig, da AA jeden Teil des Ethereum-Stacks berührt, einschließlich Clients, L2s, Wallets, RPCs, Entwickler-Toolings usw., was die Zustimmung einer Vielzahl von Interessengruppen erfordert. Dies macht es für jedes AA-EIP schwierig, sich durch Ethereums konsensgetriebenen Entwicklungsprozess zu drängen, aber auch, nachdem das EIP ausgeliefert wurde, eine praktische Adoption zu erreichen.

Daher stufen wir den nativen AA-Vorschlag für Hegotá, Frame Transactions, in die A-Stufe ein, nicht weil er technisch gesehen nicht gut genug für S ist, sondern weil wir praktische Adoptionsrisiken berücksichtigen wollen, deren Lösung einen enormen Koordinationsaufwand erfordern wird. Angesichts des Hintergrunds unseres Teams in AA beabsichtigt Ethlabs, eine wichtige Rolle bei der Markteinführung von Frame Transactions zu spielen, indem es mit Interessengruppen wie L2s und Wallets zusammenarbeitet, um eine erfolgreiche Einführung für native AA zu liefern.

Nun zu den spezifischen AA-Vorschlägen für Hegotá.

[EL] EIP-8141: Frame Transactions [A-Stufe]

Wir glauben, dass EIP-8141: Frame Transactions der beste Kandidat für Ethereums natives AA-System ist. Im Vergleich zu anderen nativen AA-Vorschlägen hat Frames eine Reihe wünschenswerter Eigenschaften, die es einzigartig mit Ethereums CROPS-Mandat in Einklang bringen:

• Erlaubnisfreie Konteninnovation: Die Validierungslogik wird von EVM-Code verarbeitet, sodass Entwickler frei jede gewünschte Validierungslogik entwickeln können, im Gegensatz zu einigen anderen AA-Ansätzen, die eine Whitelist von Validierungslogiken vorschreiben.
• Erstklassige Unterstützung für Datenschutzprotokolle: Als Korollar des ersten Punktes kann ein Datenschutzprotokoll wie Railgun die Validierungslogik von Frame-Transaktionen verarbeiten, sodass Benutzer private Transaktionen senden können, ohne sich auf zentralisierte Relayer zu verlassen, wie sie es heute tun. Dies macht Datenschutzprotokolle erheblich privater und zensurresistenter.
• Post-Quanten-Sicherheit: Frame-Transaktionen wurden mit Blick auf Ethereums breitere PQ-Roadmap entwickelt. Beispielsweise sind Frame-Transaktionen explizit so konzipiert, dass Signaturen aggregiert werden können, sodass Ethereum schließlich niedrige Gasgebühren für PQ-Signaturen verlangen kann, obwohl jede einzelne Signatur einzeln sehr teuer zu validieren sein kann.

Die Hauptschwäche von Frame Transactions rührt auch von seiner größten Stärke her: Da die Validierung von EVM-Code verarbeitet wird, verursacht die Validierung nun dynamische statt feste Kosten, was für Hoch-TPS-Ketten wie L2s eine Herausforderung darstellen kann. Wir sind optimistisch, dass dieses Problem durch weitere EIPs oder ERCs auf Basis von Frame-Transaktionen wie EIP-7819 gelöst werden kann, bei denen Transaktionen ihre Validierungslogik statisch angeben können, sodass Sequenzer die Validierung bei Bedarf mit nativem Code „abkürzen" können. Wir beabsichtigen auch, mit L2s und dem EF zusammenzuarbeiten, um Benchmarks für Frame-Transaktionen durchzuführen, damit wir Leistungsengpässe identifizieren und beheben können.

[CL][EL] Frame Transactions Add-ons

Es gibt eine Reihe von EIPs, die als Erweiterung von Frame-Transaktionen angesehen werden können und auf deren Fähigkeiten aufbauen.

[EL] EIP-8250: Keyed Nonces for Frame Transactions [A-Stufe]

• Wir betrachten dieses EIP konzeptionell als Teil von EIP-8141: Frame Transactions und glauben, dass es damit ausgeliefert werden sollte.
• Dieses EIP führt 2D-Nonces für Frame-Transaktionen ein. 2D-Nonces ermöglichen es Konten, parallele Transaktionen an den Mempool zu senden, und erlauben es Datenschutzprotokollen, Nullifier als 2D-Nonces zu speichern. Dies ist wichtig, da 2D-Nonces ein spezieller Speicher sind, der sehr wenig kostet, um gelesen und gespeichert zu werden, sodass Datenschutztransaktionen im Vergleich zur Speicherung von Nullifiern im regulären dynamischen Speicher wie heute erheblich Gas sparen können. Dies ist besonders wichtig im Kontext von Glamstams Speicher-Neupreisgestaltung (EIP-8037: State Creation Gas Cost Increase).

[EL] EIP-8272: Recent Roots for Frame Transactions [B-Stufe]

• Dies ist ein weiteres EIP, das die Erfahrung bei der Verwendung von Datenschutzprotokollen mit Frame-Transaktionen verbessert. Datenschutzprotokolle benötigen während der Validierung Zugriff auf aktuelle Commitment-Roots, was bei Speicherung im regulären Speicher nicht nur teuer sein kann, sondern auch mit den öffentlichen Mempool-Regeln von Frames kollidieren kann. EIP-8272 löst diese Probleme, indem es einen Systemvertrag zur Speicherung dieser Roots in einem Ringpuffer bereitstellt, der alte Roots automatisch löscht.
• Wir stufen es in die B-Stufe ein, da dieses EIP für einen spezifischen Anwendungsfall erhebliche Komplexität zu Frames hinzufügt und wir uns nicht sicher sind, ob es einen allgemeineren/eleganteren Weg gibt, dasselbe Ziel zu erreichen.

[CL] EIP-8369: VOPS Profiles for FOCIL Eligibility [B-Stufe]

• Dieses EIP adressiert die Interaktion zwischen Frames und VOPS (Validity-Only Partial Statelessness), einem Vorschlag, der es Mempool-Knoten ermöglicht, gerade genug Zustand zu speichern, um Transaktionen zu validieren, sodass der Mempool auch in einer Welt der Zustandslosigkeit (aufgrund von zkEVM) zensurresistent bleiben kann.
• Wir stufen es in die B-Stufe ein, da dieses EIP stark an eine bestimmte Vision von Zustandslosigkeit gebunden ist, auf die sich die Community noch nicht vollständig geeinigt hat.

[EL] EIP-7906: Transaction Assertions via State Diff Opcode [B-Stufe]

• Dieses EIP verbessert die statische Prüfbarkeit von Transaktionsergebnissen. Benutzer können bereits behaupten, was passieren soll, aber nicht, dass nichts anderes passiert ist. Der Nachweis des Fehlens von Zustandsänderungen erfordert einen neuen Opcode. Die Kombination von positiven Behauptungen (z.B. WETH-Guthaben um mindestens 1,5 erhöht) mit einer negativen Behauptung (kein anderer Zustand geändert) ermöglicht es Benutzern, die vollständigen Auswirkungen einer Transaktion konstruktionsbedingt ohne Simulation zu begrenzen, wobei Hardware-Wallets ein klarer Nutznießer sind.
• Angesichts der Komplexität wäre die Aufnahme in den Hard Fork eine sehr verbindliche Entscheidung. Wir schlagen vor, dies nur zu tun, wenn (a) die Client-Teams die Nuancen und Implikationen dieses spezifischen EIP wirklich verstehen und (b) die Testoberfläche und -komplexität sehr gut verstanden sind.

[EL] EOA-Migration [B-Stufe]

[EL] EIP-7851: Code-Controlled EOA Delegation [B-Stufe] und [EL] EIP-8151: Account Code Restricted ecRecover [B-Stufe] werden am besten als gepaarte Standards betrachtet, die zusammen eine Geschichte dafür erzählen, wie EOAs zu Smart Accounts übergehen können. In dieser Geschichte würde ein EOA zunächst über EIP-7702 an einen Smart Account delegieren. Dann würde der Opcode, den EIP-7851 einführt, die 7702-Delegierung dauerhaft machen und den Root-ECDSA-Schlüssel deaktivieren. Andererseits würde EIP-8151 ecrecover über die Deaktivierung informieren, sodass der alte Schlüssel keine Gelder über Permit-artige Abläufe abziehen kann.

Wir bewerten dieses Paar in der B-Stufe, da es nur einer von vielen Ansätzen zur Migration von EOAs zu Smart Accounts ist und dieser spezielle Ansatz keine breite Überprüfung oder Zustimmung erhalten hat. Insbesondere sind wir besorgt, dass dieser Ansatz die Multi-Chain-Frage nicht beantwortet: Wie migriert dieselbe EOA auf L2s? Der Benutzer müsste dieselbe Aktion auf ALLEN Chains durchführen, einschließlich Chains, die noch nicht existieren, was zu einer schlechten UX führen wird. Wir vermuten, dass es einen besseren Ansatz geben könnte, bei dem L2s die L1 als „Vertrauenswurzel" für die EOA-Migration nutzen können, daher reservieren wir die A/S-Stufen für Ansätze, die es Benutzern ermöglichen würden, einmal für alle EVM-Chains zu migrieren.

[EL] PQ-Signaturschema [A-Stufe]

Hegotá sollte einen glaubwürdigen Weg zu Post-Quanten-Signaturen etablieren, aber wir sollten den richtigen Mechanismus bestätigen, bevor wir uns festlegen.

• EIP-8355: Add ML-DSA verification Precompiles, die Post-Quanten-Kontosicherheit zusammen mit Frame Transactions konkretisieren.
• Alternative: PQ-Unterstützung vorregistrieren, ohne sie zu aktivieren, oder ein Ableitungsformat definieren, das später PQ-Schlüssel aufnehmen kann.

[EL] EIP-7819: SETDELEGATE instruction [A-Stufe]

• Da native AA wahrscheinlich in Hegota landen wird, ist es wichtig, dass die Kosten für die Bereitstellung neuer Smart Accounts niedrig sind, aber die Bereitstellung von Konten wird in Glamsterdam aufgrund von EIP-8037 tatsächlich teurer werden. Mit EIP-7819 würden neue Konten einfache Delegationszeiger anstelle von Proxy-Verträgen verwenden, was die Menge an neuem Zustand, der erstellt werden muss, erheblich reduziert und dadurch die Bereitstellungskosten senkt.
• Wir stufen dieses EIP in die A-Stufe ein, da wir glauben, dass niedrigere Kontobereitstellungskosten die Reibung für die Einführung von AA erheblich verringern würden.

3. Performance-Engineering: Fortgesetzte L1-Skalierung

Glamsterdam hat einen Wandel in der Art und Weise markiert, wie Ethereum an F&E herangeht, wobei Leistung als erstklassige F&E-Einschränkung behandelt wird, sowohl im Protokolldesign als auch in der Client-Arbeit. Verzögerte Ausführung, Ressourcen-Neupreisgestaltungen und viel Client-Optimierungsarbeit ermöglichen eine Skalierung von 30 M auf (mindestens) 200 M in den letzten zwei Jahren. Im Allgemeinen gibt uns Leistungsarbeit Optionalität: Der gewonnene Spielraum kann für Skalierung, zur Verkürzung von Slots, zur Senkung der Knotenanforderungen oder für alles oben Genannte genutzt werden.

Heute sehen wir die fortgesetzte Skalierung immer noch als Notwendigkeit. Anwendungen entscheiden, wo sie aufbauen, nicht nur basierend auf aktuellen Preisen, sondern auch darauf, ob Ethereum das Blockspace-Angebot im Laufe der Zeit vorhersagbar erweitern kann. Konsistente Steigerungen zu liefern, bietet mehr Sicherheit als Roadmap-Verpflichtungen allein. Die Mainnet-Kapazität ist auch noch weit davon entfernt, Nachfragespitzen bewältigen zu können: Am elften Geburtstag von Ethereum lag die tägliche mediane Basisgebühr bei nur ~0,1 gwei, dennoch trieb ein NFT-Mint sie für einige Zeit auf über 10 gwei, wobei die medianen Transaktionskosten etwa 1 $ und das 90. Perzentil mehr als 5 $ erreichten. Glamstams Skalierungsvorstoß sollte daher in Hegotá fortgesetzt werden.

Zusammengenommen setzen die folgenden EIPs Glamstams Skalierungsdynamik fort, während sie das zugrunde liegende Prinzip dahinter verstärken: Leistung sollte sowohl in der Client-Arbeit als auch im Protokolldesign ein erstklassiges Anliegen bleiben.

[EL] EIP-8131 & EIP-8279 [S-Stufe]: Daten-Neupreisgestaltungs-Bündel

Nach Glamsterdam ist die nächste bindende Einschränkung die Payload-Propagation, teilweise weil verschiedene Quellen von Payload-Bytes inkonsistent oder gar nicht in der Gas-Abrechnung berücksichtigt werden. EIP-8131: Unified Transaction Content Floor erweitert die bestehende Transaktionsuntergrenze auf Inhalte, die vor der Ausführung bekannt sind, während EIP-8279: Block Access List Byte Floor die BAL-Bytes abdeckt, die dynamisch während der Ausführung erstellt werden.

Diese dynamische Messung macht EIP-8279 eindeutig zum komplexeren der beiden. Wir schlagen jedoch vor, sie als ein Paket zu betrachten. Zusammen etablieren sie eine konsistente Abrechnung für die mit einer Transaktion verbundenen Bytes, begrenzen den Worst-Case-Payload und lassen die meisten gewöhnlichen, nicht datenintensiven Transaktionen unberührt. Dies schließt die zugrunde liegende Lücke in der Ressourcenabrechnung und ebnet den Weg für weitere Gas-Limit-Erhöhungen.

[CL][EL] EIP-8146: Block Access List Sidecars [A-Tier]

EIP-8146 ergänzt die Neubepreisungen, indem es den kritischen Pfad selbst verbessert, indem BALs getrennt vom Payload propagiert werden, was die Propagation verbessert und den Execution Clients einen Vorsprung beim State-Prefetching und der Post-State-Root-Berechnung verschafft. Wir sehen dies als eine Art von naheliegender Optimierung, die wir nicht ungenutzt lassen sollten. Die Implementierungsarbeit besteht hauptsächlich aus vertrauter CL-Gossip-Mechanik, was dies zu einem einfachen, aber wertvollen EIP macht, besonders in einem Fork, der sich als sehr EL-lastig abzeichnet.

Andere verwandte EIPs

[EL] CPSB-Neukalibrierung [A-Tier]

• Sehr einfache Änderungen, wir empfehlen, sie im Pipeline zu behalten und eine der beiden einzubeziehen, falls dies basierend auf geplanten Gas-Limit-Erhöhungen und der beobachteten Nutzung von State und Execution Gas für notwendig erachtet wird.
• EIP-8368: CPSB Recalibration for New Gas Limit: Geplante Nachfolge von EIP-8037, die kompensiert, dass die Kosten pro State-Byte (CPSB) statisch und nicht mehr eine Funktion des Gas-Limits sind, rein als Vereinfachung von Implementierung und Tests. Die Idee war, die blockweise Anpassung durch einmalige Anpassungen bei Forks zu ersetzen, falls nötig, um das State-Wachstum bei steigendem Gas-Limit im Zielbereich zu halten. Da die aktuelle CPSB auf einem Gas-Limit von 150M kalibriert wurde, ist eine Anpassung in Hegotá wahrscheinlich gerechtfertigt.
• EIP-8372: Normalized state gas limit: Noch eine ziemlich minimale Obermenge von EIP-8368, die eine feinere Anpassung als nur die CPSB ermöglicht und entweder das State-Wachstumsziel oder das reguläre Gas-Ziel kompensiert, falls diese aufgrund relativer Fehlbepreisung unterschritten werden.

[EL] EIP-7862: Delayed State Root [B-Tier]

• Einfach zu spezifizieren, aber die Komplexität der Client-Implementierungen ist unseres Wissens nach nicht sehr gut verstanden. Der State Root ist in den Codebasen allgegenwärtig.
• Während es einen gewissen Vorteil bietet, die Hürde für den Zugang zu wettbewerbsfähigem Building (schnelle State-Root-Berechnung) zu senken, liegt der wesentlichste Vorteil des EIPs unserer Meinung nach in der Zukunft (mehr Zeit, um die State-Root-Berechnung zu beweisen).
• EL ist bereits die schwere Seite von Hegotá.

[CL] EIP-8341: Partial Execution Payload Commitments [D-Tier]

• Wir empfehlen eine Ablehnung: geringer Nutzen (die State-Root-Berechnung wird leicht verzögert), nicht dringend und wird durch EIP-7862: Delayed State Root (das viel mehr Zeit dafür gibt) ersetzt.

Andere EIPs

Wir behandeln nun die restlichen EIPs, lose nach Themen gruppiert. Zu einigen EIPs bilden wir uns noch eine Meinung. Wir werden dieses Dokument aktualisieren, sobald wir in den kommenden Tagen und Wochen mehr von den Client-Teams und EIP-Autoren erfahren.

Da Hegotá sich als ein EL-lastiger Hard Fork abzeichnet, schlagen wir vor, diszipliniert zu bleiben und eine hohe Hürde für jedes EL-seitige EIP zu setzen. Wir denken, dass es wünschenswert ist, Hegotá relativ CL-leicht zu halten, abgesehen von FOCIL und Quick Slots: Ein engerer Umfang bewahrt Bandbreite, um den Client-Teams Raum zu geben, sich auf den größeren architektonischen Übergang vorzubereiten.

[CL] Emission

Wir ordnen EIP-8363: Tapered Issuance Burn bewusst keinem Tier zu. Wir glauben, dass die Emission keine Entscheidung ist, die Core-Devs alleine treffen sollten, und eine Tier-Liste ist eine explizite Empfehlung an die Core-Devs. Für die meisten EIPs funktioniert der ACD-Prozess gut, weil die Entscheidungen hauptsächlich technischer Natur sind und die Community sie effektiv an die Core-Devs delegiert hat. Die Emission ist insofern anders, als es sich um eine geldpolitische Frage handelt, bei der die Community selbst einen groben Konsens erzielen muss. Die Meinungen der Core-Devs sind wichtig, aber als Input für diese öffentliche Diskussion. Die Einstufung von EIP-8363 neben den anderen EIPs würde es als normale ACD-Entscheidung behandeln, was es unserer Meinung nach nicht sein sollte.

Technisch sehen wir Vorteile darin, die Emission gemäß EIP-8363 zu ändern. Die Probleme, die es adressiert, sind real: Die Glaubwürdigkeit von Slashing erodiert, je mehr ETH gestaked wird, hohe Staking-Quoten bedeuten, dass Belohnungen die Verwässerung größtenteils ausgleichen, und Skaleneffekte vergrößern weiter die Kluft zwischen großen Betreibern und Solo-Stakern. Eine Änderung birgt auch Risiken, von der Unsicherheit über die Auswirkungen auf die Stake-Verteilung bis hin zum Zurücksetzen der Uhr für die geldpolitische Verfestigung. Ansgars Thread legt beide Seiten dar und spiegelt unsere Position wider. Einige von uns haben sich in der Vergangenheit für Emissionsänderungen ausgesprochen und sind weiterhin von diesem Weg überzeugt.

Wir empfehlen, die Entscheidung über die Emission zu treffen, nachdem alle anderen Entscheidungen zum Umfang von Hegotá getroffen wurden. Dies gibt der Community-Diskussion die nötige Zeit und vermeidet Ablenkungen vom Scoping-Prozess selbst.

[CL] Staking-Funktionen

Staking-Verbesserungen können wertvoll sein, aber nutzerseitige Vorteile sollten Vorrang vor reinen Infrastrukturänderungen haben, es sei denn, diese sind unbedingt erforderlich.

[CL] EIP-8015: Remove deposit and eth1data fields [A-Tier]

• Sehr einfache Bereinigung von technischen Schulden. Dank EIP-7688: Forward compatible consensus data structures sind Merkle-Proofs nicht verwandter Felder nicht betroffen, also keine Auswirkungen auf Chain-Consumer.

[EL][CL] EIP-8237: Independent CL/EL Sync [B-Tier]

• Baut auf der Trennung von Beacon Block und Payload auf, die durch ePBS eingeführt wurde, um EL und CL unabhängig voneinander synchronisieren zu lassen. Wir glauben, dass dies das Potenzial hat, einen komplexen Teil der Ethereum-Clients zu vereinfachen.

[CL] EIP-8205: Withdrawal credentials preregistration [D-Tier]

• Wir empfehlen eine Ablehnung. Während das EIP eine protokollinterne Lösung für ein reales Problem beim delegierten Staking bietet, denken wir, dass die bestehende Pre-Deposit-Lösung ausreichend ist und die Komplexität der hinzugefügten Mechanismen derzeit nicht gerechtfertigt ist.

[CL] EIP-8148: Custom sweep threshold for validators [D-Tier]

• Wir empfehlen eine Ablehnung. Wir denken, das EIP ist zu komplex (neuer Systemvertrag, neue Execution Request, CL-Mechanik) für seinen Nutzen, den wir hauptsächlich darin sehen, eine gewisse marginale zusätzliche Konsolidierung aus dem Pool der Heimbetreiber zu fördern. Wir glauben nicht, dass dies angesichts der Verteilung des Stakes einen großen Effekt auf die gesamte Validatoren-Konsolidierung haben wird.

[CL] EIP-8375: ePBS Mandatory Burn of Execution Rewards [D-Tier]

• Wir empfehlen eine Ablehnung. Wir denken, dies wird wahrscheinlich nur zu mehr Side-Channeling führen. Darüber hinaus haben jahrelange Diskussionen über MEV-Burn-Strategien zu keinem Vorschlag geführt, der einen breiten Forschungskonsens erreicht hat.

[CL] EIP-7716: Anti-correlation attestation penalties [D-Tier]

• Wir empfehlen eine Ablehnung. Wir glauben nicht, dass es genügend klare Beweise dafür gibt, dass eine so große Änderung der Staking-Anreize gerechtfertigt ist. Darüber hinaus werden die Staking-Anreize wahrscheinlich im Rahmen des entkoppelten Konsenses überarbeitet.

[CL] EIP-8333: Align Checkpoint with Epoch Boundary Block [D-Tier]

• Wir empfehlen eine Ablehnung. Obwohl es eine nette Bereinigung ist, denken wir, dass es sich lohnt, es auf den großen bevorstehenden Übergang zum entkoppelten Konsens zu verschieben.

[CL] EIP-8359: Beacon Block Reporting Field [Meinungsbildung]

[CL] Weitere PQ-Vorbereitung

Diese Vorschläge reduzieren verbleibende BLS-Abhängigkeiten im Vorfeld eines zukünftigen Post-Quanten-Übergangs.

[CL] EIP-8365: BLS withdrawal credential retirement [A-Tier]

• Entfernt eine veraltete Withdrawal Credential, bereitet den Boden für Protokollvereinfachungen und vereinfacht den zukünftigen PQ-Übergang.
• Da es so einfach ist, denken wir, dass es sich lohnt, es jetzt aufzunehmen.

[CL] EIP-8367: Balance sunset for retired BLS validators [D-Tier]

• Wir empfehlen eine Ablehnung. Wir denken, es ist wahrscheinlich, dass die meisten 0x0-Validatoren vor oder nach der Aktivierung von EIP-8365: BLS withdrawal credential retirement einen Credential-Wechsel (BLSToExecutionChange) durchführen werden, entweder um ihre Gelder abzuheben oder um weiter staken zu können. Wir sehen keine große Dringlichkeit, einen Mechanismus für den Umgang mit dem verbleibenden 0x0-Stake einzuführen. Wir empfehlen, einfach EIP-8365 aufzunehmen und das Ergebnis abzuwarten, bevor über die nächsten Schritte entschieden wird.

[CL] EIP-8321: Hash-Chain RANDAO [D-Tier]

• Wir empfehlen eine Ablehnung. Die Isolierung von RANDAO gegen Post-Quanten-Angriffe bietet wenig protokollweite Sicherheit, solange die BLS-Schlüssel der Validatoren angreifbar bleiben, fügt aber etwa 32 Bytes pro Validator, neue Secret-Management-Mechanik und einen weitgehend zweckgebundenen Mechanismus hinzu. Das breitere PQ-Konsensdesign ist noch nicht abgeschlossen. Wir unterstützen einen iterativen Übergang, aber sein erster Schritt sollte einer vereinbarten Roadmap folgen, anstatt zu riskieren, durch das endgültige Design ersetzt zu werden.

[EL][CL] zkEVM-Vorbereitung

Die meisten zkEVM-Vorbereitungen bieten nur begrenzte kurzfristige Vorteile, abgesehen davon, dass sie den Betrieb eines Full Nodes für eine kleine Gruppe von Benutzern erleichtern, während sie Implementierungsbandbreite verbrauchen und das EVM möglicherweise teurer machen. Wir sollten nur Änderungen aufnehmen, deren langfristiger Wert diese unmittelbaren Kosten klar rechtfertigt.

[CL] EIP-8025: Optional Execution Proofs [D-Tier]

• Das EIP erfordert keinen Hard Fork. Der Vorschlag, es mit Hegota zu bündeln, ist ein reiner Ausdruck von Priorisierung, und wir stimmen mit dieser Wahl nicht überein. Wir denken, dass die Arbeit daran fortgesetzt werden sollte, aber Hegotá sollte nicht dadurch blockiert werden.
• Bevor wir optionale Proofs ausliefern, sollten wir zuerst daran arbeiten, den Endzustand zu definieren, und dann darauf hinarbeiten, anstatt optionale Proofs auszuliefern, bevor eine klare Vorstellung vom langfristigen Validator-/State-Modell besteht.
• Die zentrale offene Frage ist, welche Rolle Validatoren in Bezug auf den State haben sollten: ob sie weiterhin einen Teil davon bedienen oder halten sollten, anstatt vollständig staatenlos zu werden. Da Validatoren eine zentrale Node-Kohorte mit echtem Hardware- und Netzwerkwert sind, sollten Änderungen, die diese Rolle schwächen, eine höhere Hürde nehmen.

[EL] EIP-7666: EVM-ify the identity precompile [A-Tier]

• Nützliche, kleine Änderung

[EL] EIP-8200: EVMification [B-Tier]

• EIP-8200 ersetzt drei native Precompiles durch äquivalenten EVM-Bytecode. Zwei werden wenig genutzt und erscheinen einfach zu migrieren. Der dritte wird häufig in der SNARK-Verifikation verwendet, daher würden wir eine Folgenabschätzung wünschen, bevor wir seine Entfernung unterstützen.
• Wenn die Folgenabschätzung geringe Migrationskosten für die betroffenen Benutzer ergibt oder der dritte Precompile aus dem Umfang genommen wird, würden wir EIP-8200 auf [A-Tier] verschieben.

[EL] EIP-7709: Read BLOCKHASH from Storage and Update Cost [D-Tier]

• Ziemlich disruptiv aufgrund der sehr großen Gas-Kostenerhöhung, nicht dringend
• Eine Risikominderung könnte eine Folgenabschätzung beinhalten oder die spätere Durchführung mit einer Form von Block-Level-Warming (oder Ad-hoc-Warming dieser Werte), um die Auswirkungen zu reduzieren.

[EL] EIP-8268: Storage Roots in Block Access Lists [B-Tier]

• Könnte eine Analyse der konkreten Auswirkungen auf BAL-Größen und der damit verbundenen Auswirkungen auf die Transaktionskosten erfordern (EIP-8279 schlägt vor, für BAL-Bytes zu berechnen), da der BAL-Eintrag für jedes berührte Konto eine zusätzliche Storage-Trie-Root erhält.

[EL] EVM-Funktionen

Hegotá wird dennoch einige Ad-hoc-EVM-Entscheidungen erfordern. Wir glauben, dass Ethereum nach Hegotá auf eine langfristige EVM-Roadmap hinarbeiten sollte, die vom breiteren EVM-Ökosystem geprägt wird. Ethlabs wird dazu beitragen.

[EL] EIP-5920: PAY opcode [A-Tier]

• Sehr einfach, und wir denken, es ist ein gutes Primitive für das EVM
• Es wäre wichtig, konkrete Anwendungsfälle besser zu verstehen

[EL] EIP-8163: Reserve EXTENSION (0xae) opcode [A-Tier]

• Sehr nützlich für L2s, keine echten Kosten für L1 (nur informativ)

[EL] Code-Wiederverwendung / Deduplizierung [B-Tier]

• EIP-8058: Contract Bytecode Deduplication Discount und EIP-8298: SETCODEFROM Code Reuse Instruction versuchen beide, die Tatsache zu nutzen, dass Vertragscode bei Clients getrennt vom entsprechenden Konto gespeichert wird, wobei der Code-Hash als Zeiger zwischen ihnen dient. So kann identischer gemeinsam genutzter Code dedupliziert gespeichert werden. Beide EIPs ermöglichen eine kostengünstige Möglichkeit, den Account-Codehash auf den Hash eines anderweitig existierenden Codes zu setzen.
• Wir halten dies für eine attraktive allgemeine Idee, aber es wäre wichtig, die Auswirkungen und die Vorwärtskompatibilität mit binären Bäumen zu verstehen. Derzeit keine Präferenz zwischen den beiden.

[EL] Memory-Preisreform [B-Tier]

• Wir müssen entscheiden, ob wir überhaupt eine Memory-Reform in Hegota durchführen wollen. Es ist uns nicht klar, ob wir derzeit ein ausreichendes Verständnis des Designraums haben, um diese Bewertung vorzunehmen.

EIP-7686: Linear EVM memory limits

• Kleinere Änderung, beseitigt nur die quadratischen Memory-Erweiterungskosten.

EIP-7923: Linear, Page-Based Memory Costing

• Tiefgreifendere, prinzipientreuere Überarbeitung, aber komplexer.

[EL] EIP-8219: Checked Arithmetic Opcodes [B-Tier]

• Insgesamt scheint das Hinzufügen von sicherer Mathematik zum EVM nützlich.
• Die Preisgestaltung müsste mit Benchmarks bestätigt werden, wie komplex ist das?
• Mit Benchmarks und einer Folgenabschätzung (wie viele Txs könnten profitieren, wie stark, welche Compiler würden Unterstützung hinzufügen?) könnte es A-Tier sein.

[EL] EIP-8360: TCREATE Opcode [B-Tier]

• Das EIP führt die Möglichkeit ein, transaktionsbezogene temporäre Verträge zu erstellen. Dies ist ein nettes Primitive im Allgemeinen.
• Das EIP fügt erhebliche Komplexität hinzu. Mit einer gründlicheren Bewertung der Implementierungs- und Testkomplexität könnte es A-Tier sein.

[EL] EIP-7645: Alias ORIGIN to SENDER [D-Tier]

• Wir empfehlen eine Ablehnung: Brechende Änderung, unsachgemäße Verwendung von ORIGIN.

[EL] EIP-8182: Private ETH and ERC-20 Transfers [D-Tier]

• Wir empfehlen eine Ablehnung: Riesige Änderung, fügt zk-Abhängigkeiten hinzu. Falls jemals eingeführt, denken wir, dass es ein Headliner sein sollte.

[EL] EIP-2488: Deprecate the CALLCODE opcode [Meinungsbildung]

[EL] EIP-4758: Deactivate SELFDESTRUCT [Meinungsbildung]

[EL] EIP-7979: Call and Return Opcodes for the EVM [Meinungsbildung]

[EL] EIP-8173: Foundations of EVM Control Flow [Meinungsbildung]

[EL] EIP-8253: Bump nonce of zero-nonce storage accounts [Meinungsbildung]

[EL] EIP-8030: P256 algorithm support [Meinungsbildung]

[EL] EVM-Preisgestaltung

Glamsterdam hat die Preise für unterbewertete Operationen erhöht, die den Gesamtdurchsatz einschränkten. Die EVM-Preisvorschläge von Hegotá adressieren hauptsächlich die andere Seite: die Senkung der Preise für einzelne Operationen, deren aktuelle Kosten ihre Nutzung einschränken, aber nicht die Netzwerkskalierbarkeit. Dies sind daher Nice-to-haves mit geringeren Auswirkungen pro EIP. Wir sind offen für gezielte Neubepreisungen, aber Vorschläge, die neue Messmechanismen einführen, sollten nur aufgenommen werden, wenn ihr Design solide und durch einen engagierten Champion ausreichend risikominimiert ist.

[EL] EIP-8358: Net Gas Metering for Account Changes [B-Tier]

• Nicht von den Auswirkungen überzeugt. In 900 gesampelten Mainnet-Blöcken, ~400k Txs: 2,07 % aller Transaktionen würden Gas sparen & 1,14 % des Block-Gases würde gespart.

[EL] EIP-7973: Warm Account Write Metering [Meinungsbildung]

[EL] EIP-7609: Decrease base cost of TLOAD/TSTORE [Meinungsbildung]

[EL] EIP-7971: Hard Limits for Transient Storage [Meinungsbildung]

[EL] EIP-3298: Removal of refunds [Meinungsbildung]

[EL] EIP-8374: Persist Warm Access Sets Across Reverts [Meinungsbildung]

[EL] EIP-8115: Batch priority fees at end of block [Meinungsbildung]

[EL] EIP-8188: Last-Written Block for Accounts and Slots [Meinungsbildung]

[EL][CL] Ausführungsdaten und Indizierung

[EL][CL] EIP-7668: Remove bloom filters [Meinungsbildung]

[EL][CL] EIP-7807: SSZ execution blocks [Meinungsbildung]

[EL] EIP-8116: Replace cumulative receipt fields [Meinungsbildung]

[EL] EIP-8304: Trustless log and transaction index [Meinungsbildung]

[EL][CL] Vernetzung

Die P2P-Schicht von Ethereum hat Raum für gezielte Verbesserungen, insbesondere bei der Verbreitung von Transaktionen, Blobs und Attestierungen im Netzwerk.

[CL] EIP-8371: RowDAS - Distributed Blob Reconstruction [A-Tier]

• Verhindert im Allgemeinen, dass die vollständige Rekonstruktion und die Leistung von Full-Custody-Nodes zu einem Engpass für die Skalierung der Blob-Anzahl werden.
• Wertvoll, irgendwann sollte definitiv eine Form der verteilten Rekonstruktion in das Protokoll aufgenommen werden. Dies könnte es uns ermöglichen, die Validator-Custody zu entfernen.
• Wir müssen die Komplexität besser verstehen.

[CL] EIP-8142: Block-in-Blobs (BiB) [D-Tier]

• Verfrüht, keine starke Dringlichkeit, ziemlich kurzfristig, viele offene Fragen (KZG oder nicht? Neue Gossip-Themen oder nicht?).
• Wir wollen KZG nicht in den kritischen Pfad der Blockproduktion einführen, Alternativen sind unklar und würden weitere Komplexität hinzufügen.

[CL] EIP-8243: Batching Attestations at Source [D-Tier]

• Unklar, ob wir uns darauf verlassen können, um die Time-to-Finality zu verkürzen, setzt keine klare Grenze für die Last.
• Die DoS-Resistenz des Mechanismus ist nicht vollständig klar.

[EL] EIP-8077: eth/XX - announce transactions with nonce [Meinungsbildung]

[EL] EIP-8094: eth/vhash - Blob-Aware Mempool [Meinungsbildung]

[CL] EIP-8334: Bundled Attestation Propagation [Meinungsbildung]

Falls Sie uns noch immer folgen, vielen Dank, dass Sie bis zum Ende gelesen haben. Zögern Sie nicht, mit Fragen zu antworten, und wir werden uns bemühen, Ihnen zu antworten! Falls Sie übersprungen und einfach hierher gescrollt haben, weil das Durchforsten einer gigantischen Textwand nicht Ihre Vorstellung von der Gestaltung Ihres Sonntags war, werden Sie erfreut sein zu erfahren, dass dieser nächste Teil kurz ist.

Noch ein (paar) Worte...

Ethereum-Upgrades sind komplex, weil die Einsätze hoch sind. Tausende von Nodes auf der ganzen Welt wechseln im selben Slot zu neuen Regeln, und das Netzwerk pausiert dabei keine einzige Sekunde. Diese Strenge hat jedes Upgrade getragen, das Ethereum ausgeliefert hat, und resultierte in einem dezentralen Netzwerk, das 11 Jahre 100%ige Betriebszeit feiert.

Unsere Positionen zu Hegotá sind unsere derzeit besten Einschätzungen, aber wir werden unsere Überlegungen aktualisieren, sobald neue Erkenntnisse aus Diskussionen oder Implementierungsarbeiten unsere Sichtweise ändern.

Einige dieser EIPs wurden von Mitgliedern von Ethlabs verfasst oder vorangetrieben, andere stammen von den unglaublich breiten, talentierten und wohlmeinenden Forschern, Client-Entwicklern und einzelnen Mitwirkenden im gesamten Ethereum-Ökosystem. Jedoch erfordern alle von ihnen die Zusammenarbeit zwischen Client-Teams, Wallets, Anwendungen, L2s, Infrastrukturanbietern, Institutionen, Node-Betreibern und letztendlich den Benutzern, um erfolgreich zu sein. Ethereum ist das gemeinsame Projekt der Welt, und sinnvoller Netzwerkfortschritt ist niemals die Arbeit einer einzelnen Organisation.

Wir sind dankbar, ein kleiner Teil dieses Ökosystems zu sein, und wir freuen uns darauf, Ethereum dabei zu helfen, sein Potenzial zu verwirklichen.

– Ethlabs