Hegotá EIP umfassende Analyse: Wohin führt die nächste Hard Fork von Ethereum?

Ethlabs erläutert die Logik hinter den verschiedenen EIP-Entscheidungen.

Verfasser: Ethlabs

Übersetzung: Chopper, Foresight News

Die Entwicklungsrichtung von Ethereum betrifft alle, die Anwendungen aufbauen, das Netzwerk nutzen, ETH halten und an das zukünftige Potenzial von Ethereum glauben. Die langfristige Richtung von Ethereum wird letztendlich von den Teilnehmern bestimmt, die täglich Produkte, Anwendungen und Gemeinschaften darauf aufbauen. Netzwerk-Upgrades sind das zentrale Mittel zur Iteration des Protokolls und zur Anpassung an die Bedürfnisse der Benutzer. Hegotá ist das nächste geplante Netzwerk-Upgrade von Ethereum nach Glamsterdam. Dieser Artikel wird die Richtung und die Gründe darlegen, die Ethlabs für die bevorstehenden Upgrades von Ethereum als wichtig erachtet.

Der Umfang des Hegotá-Upgrades wird derzeit durch den öffentlichen technischen Prozess von Ethereum vorläufig festgelegt. Die im Folgenden genannten Vorschläge sind das Ergebnis zahlreicher Entwickler, Forschungsteams und Client-Teams. Dieser Artikel präsentiert klar die Richtungen, die Ethlabs vorschlägt, sowie die Standpunkte, zu denen wir noch keine endgültige Meinung gebildet haben. Wir begrüßen die Bewertung, Infragestellung und Verbesserung dieser Vorschläge aus der Branche; in den kommenden Tagen und Wochen werden wir unsere Ansichten im Zuge fortlaufender Diskussionen und Informationsaktualisierungen weiterentwickeln.

Für das Hegotá-Upgrade halten wir, unter Berücksichtigung aller vorgeschlagenen EIPs, die folgenden Bereiche für die wichtigsten Aufgaben von Ethereum:

• Stärkere Zensurresistenz: Jeder, unabhängig von Identität oder Zweck, sollte in der Lage sein, Transaktionen in Blöcke aufnehmen zu lassen;
• Schnellere Ethereum-Transaktionen: Schnellere Blockzeiten bedeuten schnellere Transaktionsbestätigungen, Echtzeit-Preise und kürzere endgültige Bestätigungszeiten;
• Native Kontenabstraktion: Konten unterstützen Schlüssel, Transaktionssponsoring, Token-Zahlungen für Gas, Batch-Transaktionen und stärkeren Datenschutz, mit einem reservierten Upgrade-Pfad für post-quanten Schlüssel;
• Kontinuierliche L1-Skalierung: Selbst in Zeiten hoher Nachfrage sollten Anwendungen eine stabile und erschwingliche Netzwerk-Kapazität erhalten.

Vorabinformation: Wie funktioniert der EIP-Vorankommensprozess?

Bevor wir die Vorschläge offiziell interpretieren, klären wir den entscheidenden Hintergrund: Der Umfang des Hegotá-Upgrades hat gerade die zweite Phase gestartet. In der ersten Phase wurde FOCIL als Kernvorschlag für das Hegotá-Upgrade festgelegt. Die Frist für nicht-kern EIP-Vorschläge war der 6. August, danach wird die ACD-Sitzung den gesamten Plan für das Hegotá-Upgrade umfassend bewerten.

Alle folgenden EIPs befinden sich derzeit in der PFI (Proposal for Inclusion)-Phase. Das Einreichen von EIPs für das Upgrade erfordert keine Genehmigung, aber die überwiegende Mehrheit der Vorschläge wird letztendlich nicht in das offizielle Upgrade aufgenommen.

Mit dem Fortschritt der Entwicklung werden die Vorschläge mehreren Bewertungsrunden unterzogen, wobei die Phasen schrittweise angehoben werden und die Umsetzbarkeit kontinuierlich steigt:

PFI (Vorschlag zur Aufnahme): Der Vorschlag wird für dieses Upgrade eingereicht. Diese Phase hat keine Zugangsvoraussetzungen, bedeutet keine Unterstützung durch Clients und garantiert nicht die endgültige Implementierung;

CFI (Überlegung zur Aufnahme): Die Client-Teams haben die Überprüfung abgeschlossen und planen, Prototypen zu entwickeln und zu testen;

SFI (Bestätigung zur Aufnahme): Die Parteien sind sich weitgehend einig, dass der Vorschlag aufgenommen wird, vorausgesetzt, die Entwicklung und das Testen verlaufen reibungslos.

Um den vollständigen Prozess zu verstehen, empfehlen wir, das Erklärvideo von Tim Beiko anzusehen. (https://www.youtube.com/watch?v=-S4blFZl28g)

Leserführung

Dieser Artikel verwendet den Forkcast-Klassifizierungsstandard, um Ethlabs' Prioritätsbewertung für die verschiedenen EIPs von Hegotá auszudrücken. Um die Entscheidungsfindung zu vereinfachen, werden alle zur Bewertung herangezogenen Vorschläge in fünf Kategorien unterteilt:

• 【S-Klasse】 Dringend empfohlen zur Aufnahme
• 【A-Klasse】 Sollte aufgenommen werden, wenn Entwicklungsprobleme, Auswirkungen auf die Bewertung, ökologische Umsetzung usw. gelöst werden
• 【B-Klasse】 Hat Wert, aber die Aufnahme in dieses Upgrade ist schwierig
• 【D-Klasse】 Unter den aktuellen Bedingungen nicht empfohlen für Hegotá
• 【Meinung in Entwicklung】 Wir sind noch dabei, zu diesem EIP eine Meinung zu bilden

⚠️ Hinweis: Dies sind lediglich die Empfehlungen von Ethlabs. Wir bewerten hauptsächlich basierend auf den Zielen der Vorschläge, technischen Spezifikationen und geschätzten Entwicklungsaufwänden; für Projekte mit tiefgreifender Beteiligung (z. B. Frames, Quick Slots) haben wir umfassendere Informationen. In Zukunft werden wir unsere Ansichten in Verbindung mit ethPandaOps, Testteams und Rückmeldungen von Clients kontinuierlich aktualisieren. Die Kennzeichnung 【CL】 steht für Einfluss auf die Konsensschicht-Clients; 【EL】 steht für Einfluss auf die Ausführungsschicht-Clients.

Darüber hinaus hat Ethlabs an mehreren EIPs mitgeschrieben (einschließlich FOCIL, Frame Transactions, Quick Slots). Wir streben eine objektive Bewertung aller Vorschläge an, die nicht von unserem eigenen Engagement beeinflusst wird, aber Leser sollten diesen Hintergrund bei der Berücksichtigung unserer Ansichten beachten.

CL-Prioritätenliste

EL-Prioritätenliste

Lange Rede, kurzer Sinn, hier sind die vollständigen Ansichten von Ethlabs zum Hegotá-Upgrade in der aktuellen Phase.

Hegotá vier zentrale Richtungen

FOCIL: Stärkung der Zensurresistenz

EIP-7805 FOCIL hat bereits die SFI-Phase erreicht und wurde offiziell als Kernvorschlag für Hegotá festgelegt. Drei Mitglieder von Ethlabs (Francesco, Barnabé, Julian) sind Mitautoren dieses Vorschlags, und wir unterstützen seine Umsetzung voll und ganz. Da der Plan festgelegt ist, wird hier nur kurz erläutert: Nur eine Blockchain, die für alle neutral bleibt, kann die Grundlage des Vertrauens für alle sein. Dies ist das Fundament für die Skalierung von Ethereum und das Wachstum zu einer echten Abrechnungsschicht der globalen Wirtschaft, die jedem Teilnehmer dient.

Quick Slots: Schnellere Ethereum-Transaktionen

Die aktuellen 12-Sekunden-Intervalle von Ethereum führen zu hohen Verzögerungen und beeinträchtigen die Benutzererfahrung. Daher empfehlen wir dringend, dass Hegotá 【CL】EIP-8198 Quick Slots【S-Klasse】 aufnimmt, aus vier zentralen Gründen:

• Erhöhung der Bestätigungsgeschwindigkeit von L1-Nutzertransaktionen, Verbesserung der Erfahrung;
• L1-On-Chain-Märkte erhalten aktualisierte Preisdaten, Verbesserung der Spreads und der Erträge von Liquiditätsanbietern;
• Endgültige Bestätigung, schnelle Bestätigungsregeln und Intervallzeiten sind gebunden, schnellere Blöcke werden die Interoperabilität von Ethereum über Ketten hinweg verbessern;
• Erhöhung der Anzahl der Blockvorschlagenden pro Sekunde, Stärkung der Zensurresistenz, einschließlich wirtschaftlicher Zensurresistenz: Um Zensur durch kontinuierliches Leeren von Blöcken durchzuführen, müssen höhere Kosten aufgebracht werden.

Die Verkürzung der Blockzeiten unter Beibehaltung der Dezentralisierung von Ethereum kann den Wert des Ethereum-Blockraums erhöhen, wobei die Erträge an das Netzwerk und ETH selbst zurückfließen. Jede Verzögerung, die verringert wird, schafft direkten Wert für die Benutzer. Gleichzeitig ist die Beschleunigung auch eine der am häufigsten geforderten Verbesserungen von Anwendungsentwicklern.

Derzeit ist der Start der Umgestaltung sinnvoll, da eine Anpassung der Intervallzeiten nicht sofort möglich ist. In Übereinstimmung mit den Skalierungsansätzen wird die iterative Optimierung durch praktische Tests weitaus mehr Sicherheit für Anwendungsentwickler bieten als bloße Roadmap-Versprechen. Das Erreichen von Intervallen unter 6 Sekunden ist ein langfristiges Ziel, das in zwei Schritten erreicht werden soll:

• Einmalige Umstrukturierung: Ermöglichen, dass Normen und Client-Code flexible Anpassungen der Intervallzeiten unterstützen;
• In Hegotá die erste Verkürzung durchführen, gefolgt von weiteren Hard Forks zur kontinuierlichen Senkung und Ansammlung sicherer Betriebsdaten.

Hegotá ist der geeignete Zeitpunkt, um die einmaligen Umstrukturierungskosten zu tragen. Die ePBS-Logik des Glamsterdam-Upgrades wurde bereits umstrukturiert; die Änderungen auf der Konsensschicht dieses Upgrades sind relativ kontrollierbar. Sobald das Fenster für die Entkopplung des Konsens-Updates erreicht ist, werden die Ressourcen für die Entwicklung der Konsensschicht stark angespannt sein, und es wird in Zukunft schwierig sein, solche Fenster für mehrere Hard Forks zu finden.

Einfach ausgedrückt, entweder halten wir in den nächsten zwei Jahren mindestens 12-Sekunden-Intervalle aufrecht, oder wir erreichen in einem Jahr mit dem Hegotá-Upgrade 10-Sekunden-Intervalle und haben die Möglichkeit, in der nächsten Runde weiter auf unter 10 Sekunden zu komprimieren. Diese beiden Beschleunigungen sind keine theoretischen Optimierungen, sondern können den Benutzerwert direkt steigern und das wirtschaftliche Modell des Netzwerks optimieren. Wir glauben, dass der Zeitpunkt reif ist.

Antwort auf die Hauptbedenken

Wir haben vier Hauptbedenken zusammengestellt, die in den ersten Gesprächen mit den Client-Entwicklungsteams und dem Ethereum Foundation-Protokollteam aufgetreten sind:

【Zusammenfassung (reiner Text, kann leer sein)】：

• Entwicklungsaufwand. Die Millisekunden-zeitliche Logik wurde bereits durch ePBS in die Konsensnorm integriert; die Entwurfsspezifikationen für EIP-8198 Konsens- und Ausführungsebene sind abgeschlossen, die Grundgebühren, Gasobergrenzen und Blob-Planung sind vollständig umgerechnet, um eine stabile Netzwerkaktivität pro Sekunde zu gewährleisten. Der verbleibende Arbeitsaufwand konzentriert sich auf die Anpassung verschiedener Client-Tools an die Annahme fester Zeitfenster und Tests von Grenzszenarien. Nach dieser einmaligen Umstrukturierung müssen zukünftige Anpassungen der Zeitfenster nur noch durch Parameteränderungen erfolgen.
• zkEVM-Beweisdruck. Es gibt zwei Hauptsorgen: relative Beweisdauer und feste Beweisaufwendungen. 1) Relative Beweisdauer: Der Anteil der Zeit innerhalb des Zeitfensters, der für den Beweis verwendet werden kann. Der aktuelle Blockbauer kann mit dem Bau beginnen, sobald er die Last des vorherigen Blocks erhält; der Beacon-Block bestätigt die Last des aktuellen Zeitfensters. Der Beweis muss vor der Veröffentlichung des Blocks durch den nächsten Beacon-Vorschlag abgeschlossen sein. Die kürzeste verfügbare Beweiszeit beträgt etwa ein Zeitfenster minus die Übertragungsverzögerung des Beacon-Blocks. Die Übertragungsverzögerung ist schwer zu komprimieren, aber der Wert selbst ist relativ gering und wird in der aktuellen Phase kein zentrales Nadelöhr darstellen. Optimierte Blockbauer können den Beweis parallel zur Lastenmontage durchführen, ohne auf die Bestätigung durch den Beacon-Block warten zu müssen. 2) zkEVM-Beweisaufwand: Die Beweisdauer ist im Großen und Ganzen linear mit der Blockgröße verbunden, weist jedoch feste Aufwendungen auf. Schnellere Blockerstellung bedeutet, dass die Frequenz der festen Aufwendungen steigt, was bei gleicher Durchsatzrate zu einer erhöhten Verzögerung führt. Bei festem Verzögerungsbudget muss sichergestellt werden, dass der Durchsatz nicht erheblich beeinträchtigt wird. In der Branche gibt es zwei Wege zur Verbesserung: Ingenieuriteration zur kontinuierlichen Senkung der festen Betriebskosten; EIP-7862 zur Verzögerung der Berechnung des Statuswurzel, wodurch ein Großteil der Beweisarbeit aus dem kritischen Pfad entfernt wird. Die gleichzeitige Verfolgung beider Richtungen bedeutet, dass schnellere Zeitfenster das zukünftige Wachstum des Durchsatzes nicht behindern werden.
• Post-Quanten-Upgrade-Roadmap. Das Entkoppeln des Konsensplans hat genügend Unterstützung erhalten und wird zur stabilen Richtung der zukünftigen Konsensarchitektur. Entkoppeln bedeutet, dass die endgültige Bestätigungsabstimmung aus dem kritischen Pfad der Blockproduktion entfernt wird. Großflächige Aggregation von post-quanten Signaturen und rekursiven STARK-Logiken werden ebenfalls vom kritischen Pfad entkoppelt. Die Regeln für die Blockproduktion und die Gabelauswahl hängen nur von einer Gruppe von voraussichtlich 512 (die auf 256 reduziert werden könnte) Validatoren ab. Post-Quanten-Signaturen sind zwar größer, können jedoch innerhalb des geplanten Zeitfensters von 10 Sekunden (das in Zukunft weiter verkürzt werden könnte) problemlos übertragen werden.
• Anpassung von Smart Contracts und Infrastruktur. Das Team führt umfassende Untersuchungen zu Szenarien durch, in denen Smart Contracts stark an die Zeitfensterlänge gekoppelt sind. Wir analysieren alle verifizierten Verträge in Zusammenarbeit mit Sourcify; gleichzeitig bewerten wir die Auswirkungen von Zeitfensteränderungen auf EIP-4788 (historische Beacon-Blockwurzeln im EVM). Auf der Infrastrukturebene gibt Etherscan an, dass Zeitfensteranpassungen wahrscheinlich die Serverlast erhöhen, aber die Infrastruktur während der PoW-Ära bereits auf variable Blockzeiten ausgelegt war, sodass die Änderungen kontrollierbar sind.

Kontenabstraktion: Optimierung von Erfahrung, Sicherheit und Privatsphäre

Das Ethereum-Ökosystem benötigt seit langem eine native Kontenabstraktion (AA), um die Benutzererfahrung durch Schlüssel-Wallets, Transaktionssponsoring, ERC20-Gaszahlungen, Batch-Transaktionen usw. zu verbessern. Der Weg zur Umsetzung der nativen Kontenabstraktion war jedoch äußerst holprig: AA berührt den gesamten Ethereum-Stack, einschließlich Clients, L2, Wallets, RPC und Entwicklungstools, und erfordert eine Zusammenarbeit vieler Parteien. Dies hat nicht nur dazu geführt, dass die entsprechenden EIPs schwer durch den Konsensprozess voranzutreiben sind, sondern auch nach der Einführung mit Herausforderungen bei der Implementierung im Ökosystem konfrontiert sind.

Daher haben wir den Hegotá-Vorschlag zur nativen AA, Frame Transactions, als Kategorie A eingestuft. Dies liegt nicht daran, dass die technischen Anforderungen nicht das Niveau S erreichen, sondern weil die ökologischen Risiken einer großflächigen Implementierung ausreichend berücksichtigt werden müssen, was einen enormen Koordinationsaufwand erfordert. Basierend auf den Erfahrungen des Teams im Bereich Kontenabstraktion plant Ethlabs, die Umsetzung von Frame Transactions intensiv voranzutreiben und mit L2, Wallets und anderen Beteiligten zusammenzuarbeiten, um die erfolgreiche Einführung der nativen AA zu gewährleisten.

Jetzt werfen wir einen Blick auf die Vorschläge zur Kontenabstraktion von Hegotá.

【EL】EIP-8141 Frame Transactions【Kategorie A】

Wir betrachten Frame Transactions als die optimale Lösung für die native Kontenabstraktion von Ethereum. Im Vergleich zu anderen nativen AA-Lösungen entsprechen mehrere Merkmale den Entwicklungsrichtlinien von Ethereum CROPS:

• Genehmigungsfreie Kontoinnovation: Die Validierungslogik wird durch EVM-Code ausgeführt, Entwickler können beliebige Validierungsregeln anpassen; einige AA-Lösungen zwingen eine Whitelist-Validierungslogik, was die Flexibilität einschränkt;
• Native Anpassung an Datenschutzprotokolle: Basierend auf dem vorherigen Punkt können Datenschutzlösungen wie Railgun die Validierungslogik von Frame-Transaktionen tragen, sodass Benutzer private Transaktionen ohne Abhängigkeit von zentralisierten Relais senden können, was die Privatsphäre und die Widerstandsfähigkeit gegen Zensur erheblich verbessert;
• Design für post-quanten Sicherheit: Von Anfang an auf die post-quanten Roadmap von Ethereum abgestimmt. Unterstützt die Signaturaggregation, selbst wenn die Kosten für die Validierung einzelner post-quanten Signaturen hoch sind, kann die Aggregation dennoch zu geringen Gasaufwendungen führen.

Der größte Nachteil von Frame Transactions ergibt sich ebenfalls aus ihrer Flexibilität: Die Validierungslogik wird durch EVM-Code ausgeführt, die Validierungskosten schwanken dynamisch, was für L2, die hohe TPS anstreben, eine Herausforderung darstellt.

Wir sind optimistisch, dass dies durch begleitende EIP/ERC-Standards gelöst werden kann (z. B. EIP-7819), die die Validierungslogik statisch deklarieren, sodass der Sortierer die Validierungsprozesse mit nativen Codes optimieren kann. Gleichzeitig werden wir zusammen mit L2 und der Ethereum Foundation Benchmark-Tests durchführen, um Leistungsengpässe zu identifizieren und zu beheben.

【CL】【EL】Zusatzkomponenten für Frame Transactions

Es gibt viele EIPs, die als Erweiterungen von Frame Transactions betrachtet werden können und deren Funktionalität erweitern.

【EL】EIP-8250 Schlüssel-Zufallszahlen für Frame-Transaktionen【Kategorie A】

Wir betrachten diesen Vorschlag als organischen Bestandteil von EIP-8141 und empfehlen, ihn gleichzeitig einzuführen. Einführung eines zweidimensionalen Nonce, sodass Konten mehrere Transaktionen parallel an den Transaktionsspeicherpool senden können; Datenschutzprotokolle können auch Nullwerte im zweidimensionalen Nonce speichern. Die Kosten für das Lesen und Schreiben des zweidimensionalen Nonce sind extrem niedrig, im Vergleich zu den aktuellen Modellen, die Nullwerte in den normalen Speicher schreiben, können private Transaktionen erheblich Gas sparen. Dies ist besonders wichtig vor dem Hintergrund der Erhöhung der Speicherkosten für Gas in Glamsterdam (EIP-8037).

【EL】EIP-8272 neueste Wurzel für Frame-Transaktionen【Kategorie B】

Optimierung der Nutzung von Frame-Transaktionen durch Datenschutzprotokolle. Der Validierungsprozess von Datenschutzprotokollen muss die neueste Verpflichtungswurzel lesen; wenn sie im normalen Speicher abgelegt wird, sind die Kosten nicht nur hoch, sondern es kommt auch zu Konflikten mit den Regeln des öffentlichen Transaktionspools von Frame. Dieser Vorschlag speichert die Wurzel-Daten im Ringpuffer des Systemvertrags und bereinigt automatisch alte Daten. Die Einstufung als Kategorie B erfolgt, weil dies die Komplexität von Frame für ein einzelnes Anwendungsszenario erheblich erhöht, und wir sind uns nicht sicher, ob es eine allgemeinere und einfachere Implementierung gibt.

【CL】EIP-8369 VOPS-Konfigurationsdatei für FOCIL-Berechtigungen【Kategorie B】

Lösung der Interaktion zwischen Frame und VOPS (nur Validität ohne Zustand). Das VOPS-Modell erlaubt es den Knoten im Speicherpool, nur die minimalen Zustandsvalidierungs-Transaktionen zu speichern, um die Zensurresistenz des Speichers im zukünftigen zkEVM ohne Zustand zu gewährleisten. Die Einstufung als Kategorie B erfolgt, weil dieses Modell stark an einen Satz von noch nicht konsensierten Zustandslösungen gebunden ist.

【EL】EIP-7906 Transaktionsbehauptungen durch Statusdifferenz-Opcode【Kategorie B】

Verbesserung der statischen Auditierbarkeit der Transaktionsergebnisse. Benutzer können derzeit positive Ergebnisse behaupten, können jedoch nicht einschränken, dass "keine anderen Statusänderungen vorhanden sind". Um zu beweisen, dass keine zusätzlichen Statusänderungen vorgenommen wurden, muss ein neuer Opcode hinzugefügt werden. Positive Behauptungen (z. B. WETH-Balance erhöht sich um mindestens 1,5) in Kombination mit negativen Behauptungen (keine anderen Statusänderungen) ermöglichen es, die gesamten Auswirkungen der Transaktion ohne Simulation zu erfassen, wobei Hardware-Wallets die Hauptnutznießer sind. Dieser Vorschlag hat eine hohe Komplexität, und die Einbeziehung in einen Hard Fork sollte sorgfältig abgewogen werden. Es wird empfohlen, zwei Bedingungen zu erfüllen, bevor er vorangetrieben wird: ① Das Client-Team versteht alle Details und Kettenwirkungen vollständig; ② Der Testumfang und die Bewertung potenzieller Risiken sind vollständig.

【EL】EOA-Migration【Kategorie B】

EIP-7851 und EIP-8151 sollten gemeinsam betrachtet werden und bilden zusammen das intelligente Konten-Migrationsschema für externe Konten. Der Weg ist wie folgt: EOA wird zunächst über EIP-7702 an ein intelligentes Konto delegiert; EIP-7851 fügt einen Opcode hinzu, der die Delegationsbeziehung dauerhaft festlegt und den ursprünglichen ECDSA-Schlüssel deaktiviert; EIP-8151 lässt ecRecover erkennen, dass der Schlüssel deaktiviert wurde, um zu verhindern, dass alte Schlüssel Vermögenswerte durch Transaktionen wie Permit stehlen. Die Einstufung als Kategorie B erfolgt, weil dies nur eine von mehreren EOA-Migrationslösungen ist, die noch nicht umfassend bewertet und von der Branche akzeptiert wurden. Das größte Risiko besteht in der Multi-Chain-Kompatibilität: Benutzer müssen die Migration auf jeder L2 wiederholen, einschließlich noch nicht entstandener Chains, was die Benutzererfahrung beeinträchtigt. Wir hoffen auf eine Lösung, die auf L1 als Vertrauensbasis beruht und mit einem einzigen Vorgang auf allen EVM-Chains anwendbar ist; nur solche Lösungen haben die Chance, auf Kategorie A/S hochgestuft zu werden.

【EL】Post-Quanten-Signaturstandard【Kategorie A】

Hegotá sollte einen klaren Weg zur Implementierung von post-quanten Signaturen festlegen, muss jedoch den optimalen Mechanismus festlegen, bevor die offizielle Einführung erfolgt. EIP-8355 fügt einen ML-DSA-Vorabkompilierungsvertrag hinzu: In Kombination mit Frame-Transaktionen wird die Sicherheit von post-quanten Konten gewährleistet. Alternativen: Vorabregistrierung zur Unterstützung post-quanten Signaturen, aber vorübergehend nicht aktivieren, oder Definition eines Formats zur Ableitung von kompatiblen post-quanten Schlüsseln.

【EL】EIP-7819 SETDELEGATE-Befehl【Kategorie A】

Sobald die native AA in Hegotá implementiert ist, ist es entscheidend, die Kosten für die Bereitstellung intelligenter Konten zu senken. Aber EIP-8037 in Glamsterdam wird die Kosten für die Erstellung von Konten erhöhen. EIP-7819 erlaubt es neuen Konten, leichtgewichtige Delegationszeiger zu verwenden, um Proxy-Verträge zu ersetzen, wodurch die neuen Statusspeicher erheblich reduziert und die Bereitstellungskosten gesenkt werden. Die Einstufung als Kategorie A erfolgt, weil niedrigere Kosten für die Bereitstellung von Konten die Eintrittsbarriere für die AA erheblich senken können.

Leistungsoptimierung: Fortlaufende L1-Erweiterung

Glamsterdam markiert einen Wandel in der Denkweise der Ethereum-Entwicklung: Leistung wird zur zentralen Einschränkung bei der Protokollgestaltung und Client-Entwicklung. Verzögerte Ausführung, Anpassungen der Ressourcenpreise und großflächige Client-Optimierungen haben die Netzwerkfähigkeit innerhalb von zwei Jahren von 30 Millionen Gas auf mindestens 200 Millionen Gas erhöht. Leistungsoptimierungen bieten Wahlmöglichkeiten; die freigesetzten Leistungsreserven können zur Erweiterung, zur Verkürzung der Zeitfenster, zur Senkung der Hardwareanforderungen für Knoten oder zur gleichzeitigen Verwirklichung mehrerer Ziele genutzt werden.

Der Bedarf an Erweiterung bleibt dringend. Bei der Standortwahl für Projekte sollte nicht nur der aktuelle Gaspreis berücksichtigt werden, sondern auch, ob Ethereum weiterhin stabil in der Lage ist, das Angebot an Blockraum zu erweitern. Die kontinuierliche Umsetzung von Erweiterungs-Upgrades gibt Entwicklern mehr Vertrauen als eine theoretische Roadmap. Das Hauptnetz hat noch eine Lücke, um den Verkehrsspitzen stabil gerecht zu werden: Am 11. Jahrestag von Ethereum lag der Median-Gaspreis bei nur etwa 0,1 gwei, während eine NFT-Prägungsaktion den Gaspreis auf den Bereich von 10 gwei erhöhte, was die Transaktionskosten über 1 Dollar steigen ließ. Der Erweiterungstrend, der mit Glamsterdam begonnen hat, muss bis Hegotá fortgesetzt werden.

Zusammenfassend lässt sich sagen, dass die folgenden EIPs den Expansionstrend von Glamsterdam fortsetzen und gleichzeitig die breiteren Prinzipien dahinter stärken: Leistung sollte sowohl in der Client-Arbeit als auch im Protokolldesign stets oberste Priorität haben.

【EL】EIP-8131 & EIP-8279【S-Stufe】

Der Vorschlag zur Datenpreisgestaltung nach dem Glamsterdam-Upgrade hat den Kernengpass des Netzwerks in die Blocklastverbreitung verwandelt. Die Ursache liegt in den unterschiedlichen Berechnungsstandards für Gasressourcen, die nicht einheitlich sind, und teilweise sogar nicht berechnet werden. EIP-8131 vereinheitlicht die Mindestgebührenregel für Transaktionen: Es wird die bestehende Regel für die niedrigste Gebühr auf Daten ausgeweitet, die vor der Ausführung bestätigt werden können; EIP-8279 legt die Mindestgebühren für die Byte-Anzahl in der Blockzugriffs-Liste fest: Gebühren für die dynamisch generierte Zugriffslisten-Byte während des Ausführungsprozesses.

Der dynamische Gebührenmechanismus macht EIP-8279 komplexer, aber beide sollten zusammen betrachtet werden. Das Kombinationsschema ermöglicht eine einheitliche Berechnung der mit Transaktionen verbundenen Bytes und begrenzt die schlimmsten Fälle der Blocklast, während die meisten normalen, datenarmen Transaktionen nicht betroffen sind. Es schließt die Lücken in der Ressourcenberechnung und räumt Hindernisse für eine zukünftige Erhöhung der Gasobergrenze aus dem Weg.

【CL】【EL】EIP-8146 【A-Stufe】

EIP-8146 verbessert den kritischen Pfad selbst, indem es BAL und die Nutzlast separat verbreitet, wodurch der Neupreisungsmechanismus optimiert wird. Dies erhöht nicht nur die Verbreitungseffizienz, sondern verschafft dem Ausführungs-Client auch einen Vorteil bei der Statusvorabholung und der Berechnung nach dem Statusstamm. Wir halten dies für eine unverzichtbare Optimierung mit niedriger Einstiegshürde. Die Umsetzung basiert hauptsächlich auf dem vertrauten CL-Gossip-Mechanismus, daher ist dies ein EIP mit geringem Aufwand und hohem Wert, insbesondere in einem EL-Zweig mit großem Codevolumen.

Weitere Vorschläge zur Skalierung

【EL】CPSB-Neukalibrierung【A-Stufe】

Die Änderungen sind einfach. Wir empfehlen, den Prozess fortzusetzen, basierend auf der geplanten Erhöhung der Gasobergrenze, dem On-Chain-Status und der Nutzung von Ausführungs-Gas, um einen der Vorschläge aufzunehmen. EIP-8368 passt die CPSB-Kalibrierung an die neue Gasobergrenze an: eine nachfolgende Unterstützung für EIP-8037. Die Kosten für Statusbytes werden von einer dynamischen Anpassung an die Gasobergrenze auf einen festen Wert umgestellt, was die Entwicklung und Tests vereinfacht. Der aktuelle CPSB basiert auf einer Schätzung von 150 Millionen Gas, und nach der Erhöhung der Gasobergrenze wird Hegotá wahrscheinlich eine Neukalibrierung benötigen. EIP-8372 standardisiert die Status-Gasobergrenze: gehört zum Erweiterungsschema von EIP-8368, die Anpassungsstufen sind feiner, um auf die Ziele des Statuswachstums und die Abweichungen von den regulären Gaszielen zu reagieren.

【EL】EIP-7862 verzögerter Statusstamm【B-Stufe】

Die Norm selbst ist sehr einfach, aber soweit wir wissen, wurde die Komplexität der Implementierung durch den Client noch nicht vollständig verstanden. Der Statusstamm ist in den Codebasen weit verbreitet. Kurzfristige Gewinne sind begrenzt, der Kernwert konzentriert sich auf langfristige (Verlängerung der Verfügbarkeit des Statusstammnachweises). Der Druck auf die Änderungen in der Ausführungsebene von Hegotá ist bereits hoch.

【CL】EIP-8341 teilweise Ausführungsnutzlastverpflichtungen【D-Stufe】

Wir empfehlen, dies nicht aufzunehmen. Die Gewinne sind begrenzt (geringe Verzögerung der Berechnung des Statusstamms), die Nachfrage ist nicht dringend, und EIP-7862 kann stärkere Effekte erzielen und kann direkt ersetzt werden.

Diskussion über die Klassifizierung der verbleibenden EIPs

Als nächstes werden die verbleibenden Vorschläge thematisch gruppiert. Bei einigen Vorschlägen sind unsere Meinungen noch in der Entwicklung, und wir werden in Zukunft weiterhin mit den Client-Teams und Autoren kommunizieren und aktualisieren.

Hegotá wird voraussichtlich ein Hard Fork mit Schwerpunkt auf Änderungen in der Ausführungsebene sein, und wir sollten die Zugangsschwelle für EIPs in der Ausführungsebene streng kontrollieren. Abgesehen von FOCIL und Quick Slots sollten wir den Umfang der Änderungen in der Konsensschicht so weit wie möglich einschränken: den Umfang des Upgrades verkleinern und dem Client-Team ausreichend Zeit lassen, um auf zukünftige große architektonische Transformationen zu reagieren.

【CL】Veröffentlichungsmechanismus

Wir setzen EIP-8363 zur schrittweisen Veröffentlichung und Zerstörung nicht auf die Prioritätenliste. Die Inflationspolitik sollte nicht einseitig von den Kernentwicklern entschieden werden, die Prioritätenliste ist gleichbedeutend mit einer klaren Empfehlung an die Kernentwickler. Die meisten EIPs neigen zu technischen Entscheidungen, die Gemeinschaft überträgt die Entscheidungsgewalt an das Kernentwicklungsteam; aber der Veröffentlichungsmechanismus gehört zur Geldpolitik, die eine breite Einigung in der Gemeinschaft erfordert. Die Meinungen der Kernentwickler dienen nur als öffentliche Diskussionsreferenz. Wenn wir dies mit normalen EIPs gleichstellen, wäre das gleichbedeutend mit einer regulären ACD-Technikentscheidung.

Aus technischer Sicht hat EIP-8363 Wert. Mit dem Anstieg der Gesamtmenge an gestaktem ETH sinkt die Glaubwürdigkeit des Bestrafungsmechanismus; die neuen Belohnungen bei hoher Staking-Rate gleichen oft die Inflation aus; der Skaleneffekt vergrößert weiterhin die Kluft zwischen großen Betreibern und unabhängigen Stakern. Aber die Änderungen bringen auch Risiken mit sich: Die Verteilung des Stakings ist unsicher, und der Prozess der Festlegung der Geldpolitik wird neu gestartet. Der Diskussionsbeitrag von Ansgar listet die Pro- und Kontra-Argumente vollständig auf und stimmt mit unserer Position überein. Einige Mitglieder des Teams haben zuvor eine Anpassung des Veröffentlichungsmechanismus unterstützt, halten jedoch weiterhin an dieser Einschätzung fest.

Wir empfehlen, die Diskussion über Anpassungen des Veröffentlichungsmechanismus zu führen, nachdem alle anderen Bereiche von Hegotá festgelegt sind. Geben Sie der Gemeinschaft ausreichend Zeit zur Diskussion, um zu vermeiden, dass die Hauptlinie der Festlegung des Upgrade-Umfangs gestört wird.

【CL】Optimierung der Staking-Funktion

Die Verbesserungen im Staking haben Wert, aber die Priorität sollte auf der Optimierung für Endbenutzer liegen; grundlegende Infrastrukturänderungen sollten, wenn nicht notwendig, verschoben werden.

【CL】EIP-8015 Entfernen von Einzahlungs- und eth1data-Feldern【A-Stufe】

Leichte Bereinigung historischer technischer Schulden. Basierend auf EIP-7688 zur Rückwärtskompatibilität der Konsensdatenstruktur sind irrelevante Felder von Merkle-Nachweisen nicht betroffen und beeinträchtigen nicht die Datenleser auf der Blockchain.

【EL】【CL】EIP-8237 Unabhängige Synchronisation von Konsens- und Ausführungsschicht【B-Stufe】

Aufbauend auf der Trennung von ePBS zwischen Beacon-Blocks und Lasten ermöglicht es CL und EL, unabhängig zu synchronisieren, was die komplexe Logik des Clients vereinfachen könnte.

【CL】EIP-8205 Vorregistrierung von Abhebungsnachweisen【D-Stufe】

Wir empfehlen, dies nicht aufzunehmen. Obwohl es das echte Problem des delegierten Stakings löst, kann das bestehende Einzahlungs-Vorverfahren bereits damit umgehen; die Komplexität des neuen Protokollmechanismus ist in der aktuellen Phase schwer mit den Erträgen abzugleichen.

【CL】EIP-8148 Benutzerdefinierte Liquidationsschwellen für Validatoren【D-Stufe】

Wir empfehlen, dies nicht aufzunehmen. Der Mechanismus ist komplex (neue Systemverträge, Ausführungsanfragen, Logik der Konsensschicht), die Erträge sind begrenzt und fördern nur geringfügig die Integration von Retail-Stakern. Angesichts der aktuellen Verteilung des Stakings ist es schwierig, die Tendenz zur Zentralisierung der Validatoren im gesamten Netzwerk signifikant zu verändern.

【CL】EIP-8372 Zwangszerstörung von ePBS-Ausführungsbelohnungen【D-Stufe】

Wir empfehlen, dies nicht aufzunehmen. Es wird wahrscheinlich nur zu mehr Off-Chain-Kanälen führen. Die jahrelangen Diskussionen über die Zerstörung von MEV haben keinen weit verbreiteten Konsens hervorgebracht.

【CL】EIP-7716 Strafen für gegenläufige Beweise【D-Stufe】

Wir empfehlen, dies nicht aufzunehmen. Es fehlen ausreichende Beweise, um eine erhebliche Anpassung des Anreizmechanismus für das Staking zu unterstützen, und die Entkopplung des Konsens-Upgrades wird das Anreizsystem für das Staking neu gestalten.

【CL】EIP-8333 Ausrichtung von Checkpoint-Ära-Grenzblöcken【D-Stufe】

Wir empfehlen, dies nicht aufzunehmen. Es gehört zu den Optimierungs- und Bereinigungsarbeiten und kann auf einen späteren Zeitpunkt verschoben werden, um mit größeren Entkopplungs-Upgrades voranzukommen.

【CL】EIP-8359 Berichtsfelder für Beacon-Blocks【Meinung in Entwicklung】

【CL】Vorbereitungsarbeiten für das Post-Quanten-Upgrade

Die folgenden Vorschläge reduzieren die Abhängigkeit von BLS-Signaturen und ebnen den Weg für den zukünftigen Übergang zu Post-Quanten.

【CL】EIP-8365 Abschaffung von BLS-Abhebungsnachweisen【A-Stufe】

Abschaffung der alten Abhebungsnachweise, Vereinfachung des Protokolls und Vorbereitung auf den zukünftigen Übergang zu Post-Quanten. Die Änderungen sind einfach und eignen sich für die aktuelle Umsetzung.

【CL】EIP-8367 Abschaffung des BLS-Mechanismus zur Verfall von Validatoren-Bilanzen【D-Stufe】

Wir empfehlen, dies nicht aufzunehmen. Die meisten 0x0-Zertifikate von Validatoren werden vor und nach dem Start von EIP-8365 die Zertifikatsmigration abschließen, Gelder abheben oder weiterhin staken. Es ist nicht erforderlich, einen speziellen neuen Mechanismus zur Behandlung des verbleibenden Bestands einzuführen; zunächst sollte EIP-8365 umgesetzt werden, um die tatsächliche Situation zu beobachten.

【CL】EIP-8321 Hash-Chain RANDAO【D-Stufe】

Wir empfehlen, dies nicht aufzunehmen. Die bloße Implementierung von RANDAO hat nach dem Quanten-Sicherheitsaspekt nur begrenzte Bedeutung, da die BLS-Schlüssel der Validatoren weiterhin Risiken bergen; gleichzeitig erhöht jeder Validator 32 Byte Daten, was neue Schlüsselverwaltungslogik erfordert und nur einen begrenzten Nutzen hat. Ein vollständiges Post-Quanten-Konsensschema wurde noch nicht umgesetzt. Wir unterstützen iterative Upgrades, aber der erste Schritt sollte einem einheitlichen Fahrplan folgen, um zu vermeiden, dass das Schema durch den endgültigen Standard ersetzt wird.

【EL】【CL】Optimierung der zkEVM-Anpassung

Die meisten vorzeitigen Optimierungen der zkEVM haben kurzfristig begrenzte Vorteile und erleichtern nur bestimmten Gruppen den Betrieb vollständiger Knoten, während sie Entwicklungsressourcen beanspruchen und möglicherweise die Betriebskosten von EVM erhöhen. Nur Vorschläge, deren langfristiger Wert deutlich über den kurzfristigen Kosten liegt, sind geeignet für die Aufnahme.

【CL】EIP-8025 Optionale Ausführungsnachweise【D-Stufe】

Dieses Upgrade sollte nicht aufgenommen werden. Der Vorschlag selbst zwingt nicht zu einem Hard Fork; die Bindung an Hegotá ist nur eine Prioritätsforderung, der wir nicht zustimmen. Vor der Einführung optionaler Nachweise sollte die langfristige endgültige Form klar definiert werden, um schrittweise voranzukommen und nicht hastig zu starten, bevor die Validatoren / das Statusmodell festgelegt sind. Zentrale zu klärende Fragen: Sollten Validatoren einen Teil des Status behalten und speichern oder vollständig zustandslos sein? Validatoren sind eine wichtige Gruppe von Knoten, die über Hardware- und Netzwerkressourcen verfügen, und Änderungen, die ihre Rolle schwächen, erfordern höhere Zugangskriterien.

【EL】EIP-7666 Identitätsvorabkompilierung in EVM【A-Stufe】

Die Änderungen sind klein und haben praktischen Wert.

【EL】EIP-8200 Vorabkompilierung in EVM【B-Stufe】

Verwendung von EVM-Bytecode zur Ersetzung von drei Arten von nativen Vorabkompilierungen. Zwei Arten haben eine geringe Nutzung, die Migrationsschwierigkeiten sind gering; die dritte Art wird häufig für SNARK-Nachweise verwendet. Es ist erforderlich, eine Auswirkungenseinschätzung durchzuführen, um sicherzustellen, dass die Migrationskosten kontrollierbar sind, oder die dritte Art aus dem Umfang zu entfernen, bevor wir sie auf die A-Stufe erhöhen.

【EL】EIP-7709 Lesen von BLOCKHASH aus dem Speicher und Anpassen von Gas【D-Stufe】

Die Erhöhung des Gas ist erheblich, die Störung ist offensichtlich, die Nachfrage ist nicht dringend. Um das Risiko zu senken, kann eine Auswirkungenseinschätzung durchgeführt werden oder die Einführung kann zusammen mit einem Blockvorwärmmechanismus verschoben werden.

【EL】EIP-8268 Einbeziehung der Blockzugriffslisten in den Speicherstamm【B-Stufe】

Es ist erforderlich, die tatsächlichen Auswirkungen auf das Volumen der Zugriffslisten und die Transaktions-Gas-Kosten zu bewerten (EIP-8279 wird Gebühren für die Byte-Anzahl in der Zugriffslisten berechnen), jeder Zugriffs-Konto-Eintrag bringt zusätzlich den Speicher-Merkle-Stamm mit sich.

【EL】EVM-native Funktionen

Hegotá wird weiterhin einige EVM-Verbesserungen umsetzen. Wir glauben, dass Ethereum nach diesem Upgrade eine langfristige Entwicklungsroadmap für das gesamte EVM-Ökosystem erstellen sollte, und Ethlabs wird an der gemeinsamen Entwicklung teilnehmen.

【EL】EIP-5920 PAY Opcode【A-Stufe】

Die Logik ist einfach und stellt eine wertvolle Grundlage für EVM dar. Es muss jedoch weiter geklärt werden, in welchen realen Anwendungsszenarien es eingesetzt werden kann.

【EL】EIP-8163 Reservierter EXTENSION (0xae) Opcode【A-Stufe】

Hochgradig nützlich für L2, nahezu kostenneutral für L1, dient nur als reservierte Kennzeichnung.

【EL】Wiederverwendung von Vertragscode【B-Stufe】

EIP-8058 zur Reduzierung von Vertragsbytecode und EIP-8298 SETCODEFROM zur Wiederverwendung von Codeanweisungen basieren auf dem Speichermodell des Clients: Vertragscode wird unabhängig gespeichert, Konten verweisen nur über den Code-Hash auf den Code. Beide Vorschläge ermöglichen es, denselben Code nur einmal zu speichern, was die Bereitstellungskosten senkt. Die Idee ist attraktiv, muss jedoch hinsichtlich der Vorwärtskompatibilität mit der Binärbaum-Speicherstruktur bewertet werden. Derzeit gibt es keine klare Präferenz für beide Vorschläge.

【EL】Preisanpassung für Speicher【B-Stufe】

Wir haben noch nicht entschieden, ob eine Speicherreform in Hegotá sinnvoll ist. Unser Verständnis des Designraums ist derzeit unzureichend.

EIP-7686 lineare EVM-Speicherobergrenze: geringe Änderungen, Streichung der Kosten für die zweite Speichererweiterung;

EIP-7923 basierte lineare Speicherpreisgestaltung: Rekonstruktion der grundlegenden Regeln, umfassender, aber komplexer.

【EL】EIP-8219 arithmetische Operationen mit Überlaufprüfung【B-Stufe】

Die Hinzufügung sicherer Berechnungsfunktionen für EVM hat Wert. Benchmark-Tests sind erforderlich, um die Preisgestaltung zu bestätigen; nach Abschluss der Auswirkungen (Transaktionsvolumen, Compiler-Anpassung) könnte eine Hochstufung auf A-Stufe möglich sein.

【EL】EIP-8360 TCREATE Opcode【B-Stufe】

Unterstützt die Erstellung temporärer Verträge während des Lebenszyklus von Transaktionen, allgemeine grundlegende Primitiven. Die Komplexität des Vorschlags ist jedoch hoch, eine Neubewertung nach Abschluss der Entwicklung und Testbewertung ist erforderlich.

【EL】EIP-7645 ORIGIN Alias zeigt auf SENDER【D-Stufe】

Es wird empfohlen, dies nicht zu berücksichtigen. Es handelt sich um eine destruktive Änderung, die die Semantik von ORIGIN missbraucht.

【EL】EIP-8182 native private ETH und ERC20 Übertragungen【D-Stufe】

Es wird empfohlen, dies nicht zu berücksichtigen. Die Änderungen sind erheblich und führen zu einer Abhängigkeit von ZK. Sollte es in Zukunft umgesetzt werden, sollte es als zentrales Upgrade-Vorschlag betrachtet werden.

【EL】EIP-2488 Deaktivierung des CALLCODE Opcodes【Meinung in Entwicklung】

【EL】EIP-4758 Deaktivierung von SELFDESTRUCT【Meinung in Entwicklung】

【EL】EIP-7979 EVM Aufruf- und Rückgabeopcodes【Meinung in Entwicklung】

【EL】EIP-8173 EVM Kontrollflussgrundlagen【Meinung in Entwicklung】

【EL】EIP-8253 Null Nonce Speicherung von Konten Nonce Inkrementierung【Meinung in Entwicklung】

【EL】EIP-8030 Unterstützung des neuen P256 Algorithmus【Meinung in Entwicklung】

【EL】EVM Preismechanismus

Glamsterdam hat die Gaspreise für Operationen, die die Durchsatzrate einschränken, zu niedrig angesetzt. Die Preisanpassungsvorschläge für Hegotá sind gegenteilig: Senkung der derzeit zu hohen Kosten für Operationen, die die Anwendungseinhaltung einschränken, jedoch mit begrenztem Beitrag zur Netzwerkausweitung, was als Optimierung betrachtet werden kann. Wir unterstützen gezielte Preisanpassungen, jedoch müssen Vorschläge für neue Abrechnungsmodelle gut durchdacht sein und von entschlossenen Vorantreibern umfassend auf Risiken getestet werden, bevor sie in Betracht gezogen werden können.

【EL】EIP-8358 Netto-Gasabrechnung für Kontowechsel【B-Stufe】

Die Erträge sind fraglich. Eine Stichprobe von 900 Hauptnetzblöcken und 400.000 Transaktionen zeigt: Nur 2,07 % der Transaktionen sparen Gas, die Gesamtersparnis an Blockgas macht nur 1,14 % aus.

【EL】EIP-7973 Abrechnung für heiße Kontowrite【Meinung in Entwicklung】

【EL】EIP-7609 Senkung der TLOAD/TSTORE Grundgaspreise【Meinung in Entwicklung】

【EL】EIP-7971 temporäre Speicherobergrenze【Meinung in Entwicklung】

【EL】EIP-3298 Streichung der Gasrückerstattung【Meinung in Entwicklung】

【EL】EIP-8374 Beibehaltung heißer Zugriffsgruppen nach Rollback【Meinung in Entwicklung】

【EL】EIP-8115 Batch-Abrechnung von Prioritätsgebühren am Blockende【Meinung in Entwicklung】

【EL】EIP-8188 Aufzeichnung des neuesten Schreibblocks für Konten und Speicherplätze【Meinung in Entwicklung】

【EL】【CL】Ausführungsdaten und Indizes

【EL】【CL】EIP-7668 Entfernung des Bloom-Filters【Meinung in Entwicklung】

【EL】【CL】EIP-7807 SSZ-Format Ausführungsblock【Meinung in Entwicklung】

【EL】EIP-8116 Vereinfachung der kumulierten Empfangsfelder【Meinung in Entwicklung】

【EL】EIP-8304 Vertrauenslose Protokolle für Logs und Transaktionsindizes【Meinung in Entwicklung】

【EL】【CL】Netzwerkschicht

Das Ethereum P2P-Netzwerk hat weiterhin gezielte Optimierungsmöglichkeiten, insbesondere in Bezug auf Transaktionen, Blob und den Mechanismus zur Verbreitung von Nachweisnachrichten.

【CL】EIP-8371 RowDAS verteilte Blob-Rekonstruktion【A-Stufe】

Vermeidet vollständige Rekonstruktionen, die vollständige Knotenverwaltung zu einem Flaschenhals bei der Blob-Erweiterung machen. Langfristig wird ein verteiltes Rekonstruktionsmechanismus notwendig sein, um die Anforderungen an die Validierung von Blob zu lösen. Es muss jedoch die Komplexität der Umsetzung weiter bewertet werden.

【CL】EIP-8142 Blob eingebettete Blöcke BiB【D-Stufe】

Der Zeitpunkt ist nicht reif, es gibt nicht genügend Dringlichkeit und viele ungelöste Probleme (ob KZG verwendet werden soll, neue Broadcast-Themen). Wir möchten nicht, dass der KZG-Mechanismus in den kritischen Pfad der Blockproduktion eingeführt wird, und alternative Lösungen sind noch unklar.

【CL】EIP-8243 Quellbatch-Broadcast-Nachweis【D-Stufe】

Es kann nicht klar gewährleistet werden, dass die endgültige Bestätigungszeit verkürzt wird, die Lastgrenze ist unklar; die DoS-Abwehrfähigkeit des Mechanismus muss noch validiert werden.

【EL】EIP-8077 eth/XX basierte Nonce-Broadcast-Transaktionen【Meinung in Entwicklung】

【EL】EIP-8094 eth/vhash unterstützt Blob-Protokolle für Transaktionspools【Meinung in Entwicklung】

【CL】EIP-8334 Batch-Broadcast von Nachweisen【Meinung in Entwicklung】

Schlussfolgerung

Die Risiken eines Ethereum-Upgrades sind sehr hoch, daher ist Komplexität unvermeidlich. Tausende von Knoten weltweit müssen zur gleichen Zeit die Regeln synchronisieren, ohne dass der Netzwerkbetrieb unterbrochen wird. Diese Sorgfalt unterstützt die reibungslosen Upgrades von Ethereum und ermöglicht ein dezentrales Netzwerk, das seit 11 Jahren ohne Ausfallzeiten funktioniert.

Dies sind die aktuellen Einschätzungen von Ethlabs zu Hegotá. Mit dem Fortschritt der Entwicklung und vertieften Diskussionen werden wir unsere Ansichten weiterhin aktualisieren, sobald neue Beweise auftauchen. Einige EIPs werden von Mitgliedern von Ethlabs vorangetrieben, während andere Vorschläge von einer Vielzahl hervorragender Forscher, Client-Entwickler und unabhängiger Mitwirkender aus der Ethereum-Community stammen. Aber alle Vorschläge, die umgesetzt werden sollen, sind auf die Zusammenarbeit von Client-Teams, Wallets, Anwendungen, L2, Infrastruktur-Anbietern, Institutionen, Knotenbetreibern und Endbenutzern angewiesen. Ethereum gehört der ganzen Welt, und bedeutende Fortschritte im Netzwerk sind nie das Ergebnis einer einzigen Organisation.