Besonderer Dank an Fede, Danno Ferrin, Justin Drake, Ladislaus und Tim Beiko für ihr Feedback und ihre Überprüfung.

Das Ziel von Ethereum ist es, ein globales Hauptbuch zu werden - eine Plattform, die menschliche Vermögenswerte und Aufzeichnungen trägt und die zugrunde liegende Schicht für Anwendungen wie Finanzen, Governance und die Verifizierung von Daten mit hohem Wert bildet. Um dieses Ziel zu erreichen, muss es sowohl Skalierbarkeit als auch Widerstandsfähigkeit haben. Der Fusaka-Hardfork-Plan wird den L2-Datenverfügbarkeitsraum um das 10-fache erhöhen, währendDer vorgeschlagene Fahrplan 2026Beinhaltet auch eine ähnliche Skala der L1-Datenerweiterung. 'The Merge' hat Ethereum inzwischen auf einen Proof of Stake (PoS) Konsensmechanismus aktualisiert,Die Vielfalt der Kunden nimmt schnell zu, ZK (Zero-Knowledge Proof) Verifizierbarkeit und Widerstand gegen Quantenangriffe machen ebenfalls stetige Fortschritte, und das Anwendungssystem wird zunehmendReif und robust.

Das Ziel dieses Artikels ist es, ein ebenso kritisches, aber oft unterschätztesWiderstandsfähigkeit (und letztlich Skalierbarkeit)Elemente:
Einfachheit des Protokolls.

Eines der am meisten gelobten Aspekte von Bitcoin ist sein Protokolldesign, das äußerst elegant und einfach ist:

Das System ist eine Blockchain, bestehend aus einer Reihe von Blöcken. Jeder Block ist durch einen Hash mit dem vorherigen verbunden. Die Gültigkeit jedes Blocks wird durch den Proof of Work (PoW) überprüft, was bedeutet... Sie müssen nur überprüfen, ob die führenden Ziffern seines Hashs Nullen sind. Jeder Block enthält Transaktionen, die entweder die Münzen aus dem Mining ausgeben oder die Münzen aus vorherigen Transaktionen ausgeben. Das ist im Grunde genommen alles.
Selbst ein intelligenter Gymnasiast hat die Fähigkeit, die Betriebsprinzipien des Bitcoin-Protokolls vollständig zu verstehen. Und ein Programmierer kann sogar als Hobbyprojekt einen Bitcoin-Client entwickeln.

Die Beibehaltung des einfachen Protokolls bringt eine Reihe von wichtigen Vorteilen mit sich, die Bitcoin und Ethereum möglicherweiseVertraute NeutralitätDie grundlegende Schicht des globalen Vertrauens:

• Machen Sie die Protokolllogik einfacher zu verstehen, erweitern Sie die Gruppe, die an der Protokollforschung, -entwicklung und -verwaltung teilnehmen kann, senken Sie die technischen Hürden und vermeiden Sie die Dominanz einer 'technologischen Bürokratenklasse' im Protokoll.
• Signifikante Reduzierung der Entwicklungskosten für neue Infrastrukturen, die in Protokolle integriert sind (wie neue Clients, neue Verifizierer, neue Protokollierungstools usw.).
• Reduzieren Sie die langfristigen Wartungskosten des Protokolls.
• Die Reduzierung des Risikos katastrophaler Schwachstellen, sei es in Protokollspezifikationen oder Implementierungscodes; erleichtert es auch zu überprüfen, dass das Protokoll solche Schwachstellen nicht enthält.
• Reduzieren Sie die Angriffsfläche für soziale Angriffe: Je weniger Komponenten, desto weniger Orte, die von bestimmten Stakeholdern ausgenutzt und kontrolliert werden können.

In der Vergangenheit hat Ethereum in dieser Hinsicht nicht gut abgeschnitten (manchmal sogar wegen meiner persönlichen Entscheidungen), was zu unseren übermäßigen Entwicklungskosten geführt hat,@vbuterin/selfdestruct”>Verschiedene Sicherheitsrisiken und die geschlossene Natur der F&E-Kultur, und diese Bemühungen bringen oft nur illusorische Renditen.
Dieser Artikel wird erläutern, wie Ethereum in fünf Jahren ein Maß an Einfachheit erreichen könnte, das Bitcoin nahekommt.

Vereinfachte Konsensschicht

3-Slot-Finalität (3槽终结性) Simulationsdiagramm —3sf-mini

Das neue Konsensschicht-Design (früher als 'Beam Chain' bekannt) zielt darauf ab, die Erfahrungen zu integrieren, die wir in den Bereichen Konsenstheorie, ZK-SNARK-Entwicklung, Staking-Ökonomie und anderen Bereichen in den letzten zehn Jahren gesammelt haben, um eine langfristig optimale Ethereum-Konsensschicht zu schaffen. Diese neue Konsensschicht soll im Vergleich zur bestehenden Beacon Chain eine höhere Einfachheit erreichen. Dies zeigt sich insbesondere in:

• 3-Slot-Finalitätsstruktur
  Dieses Design beseitigt die Unterscheidung zwischen 'Slot' und 'Epoch', das Ausschütteln des Ausschusses und andere protokollspezifische Details im Zusammenhang mit diesen Mechanismen (wie synchrone Ausschüsse). Eine grundlegende Version von 3-Slot-Finalität,Es werden nur etwa 200 Zeilen Code benötigtEs kann erreicht werden. Im Vergleich zum aktuellen Gasper-Protokoll bietet die 3-Slot-Endgültigkeit auch eine nahezu optimale Sicherheit.
• Die Anzahl der aktiven Validatoren ist gesunken
  Macht es sicherer und machbarer, eine einfachere Gabelwahlregel zu übernehmen.
• Aggregationsprotokoll basierend auf STARK
  Bedeutet, dass jeder Aggregator werden kann, ohne sich um das Vertrauen in den Aggregator, übermäßige Gebühren für wiederholte Bitfelder usw. sorgen zu müssen. Obwohl die Aggregationsverschlüsselung selbst eine gewisse Komplexität aufweist, gilt dasHochgradig verkapselte KomplexitätDas gesamte systematische Risiko des Protokolls ist deutlich geringer.
• Die beiden oben genannten Punkte unterstützen wahrscheinlich auch eine einfachere und robustere Peer-to-Peer (P2P) Architektur.
• Wir haben die Möglichkeit, die Mechanismen des Validatoreintritts, des Austritts, des Abzugs, des Schlüsselwechsels, der Trägheitsstrafe usw. neu zu überdenken und zu vereinfachen. Dies bedeutet nicht nur eine Reduzierung der Anzahl der Codezeilen (LoC), sondern auch klarere Mechanismusgarantien, wie beispielsweise eine explizitere 'schwache Subjektivitäts'-Frist.

Der Vorteil der Konsensschicht besteht darin, dass sie relativ entkoppelt von der EVM-Ausführung ist, sodass wir viel Spielraum haben, um diese Verbesserungen weiter voranzutreiben.
Noch herausfordernder ist: wie man dieselbe Vereinfachung auf der Ausführungsebene erreicht.

Vereinfachen Ausführungsschicht

Die Komplexität der Ethereum Virtual Machine (EVM) nimmt kontinuierlich zu, und ein Großteil dieser Komplexität hat sich als unnötig erwiesen (oft auch im Zusammenhang mit meinen persönlichen Entscheidungen): Wir haben eine 256-Bit-Virtual Machine, die übermäßig für sehr spezifische kryptografische Formen optimiert ist, die jetzt allmählich an Bedeutung verlieren; und einige vorab kompilierte Verträge konzentrieren sich übermäßig auf sehr wenige Einzelfälle.

Der Versuch, diese praktischen Probleme allmählich zu beheben, ist nicht machbar.Entfernen @vbuterinDie SELFDESTRUCT-Anweisung verbraucht eine enorme Menge an Energie, aber die Ergebnisse sind begrenzt. Die jüngste Debatte über EOF (EVM-Objektformat) zeigt weiterhin die Schwierigkeit auf, ähnliche Änderungen am Virtuellen Rechner vorzunehmen.

Daher habe ich kürzlich einen radikaleren Vorschlag gemacht: Anstatt inkrementelle (aber dennoch zerstörerische) Änderungen für eine Verbesserung um das 1,5-fache vorzunehmen, ist es besser, direkt zu einer brandneuen, weit überlegenen und einfacheren virtuellen Maschine zu migrieren und eine Rendite von 100x anzustreben. Ähnlich wie bei 'The Merge' reduzieren wir die Anzahl der Transformationen, aber jede einzelne ist signifikant. Konkret schlage ich vor, die vorhandene EVM durch RISC-V (oder eine andere virtuelle Maschine, die vom ZK-Beweiser von Ethereum verwendet wird) zu ersetzen. Auf diese Weise werden wir erreichen:

• Bedeutende Effizienzverbesserung: Da Smart Contracts direkt im Beweiser ohne den Overhead eines Interpreters ausgeführt werden können. Knappe Daten zeigen, dass die Leistung in vielen Szenarien um über 100 Mal verbessert werden kann.
• Ultimative Einfachheit: im Vergleich zur EVM, RISC-V SpezifikationExtrem einfach. Andere alternative Lösungen (wie Kairo) sind ebenso prägnant.
• Die erwarteten Vorteile von EOF werden vererbt: wie Code-Segmentierung, freundlichere statische Analyse, größere Code-Kapazitätsgrenze usw.
• Entwickler haben mehr Auswahlmöglichkeiten: Solidity und Vyper können in das neue virtuelle Maschinen-Backend kompiliert werden. Wenn RISC-V gewählt wird, können auch Entwickler von Mainstream-Sprachen ihren Code problemlos übertragen.
• Deutlich reduzieren Sie die Notwendigkeit der Vorkompilierung: möglicherweise bleiben nur noch einige hochoptimierte elliptische Kurvenoperationen erhalten (obwohl diese nicht mehr existieren werden, sobald Quantencomputer populär werden).

Der Hauptnachteil dieses Ansatzes besteht darin, dass im Gegensatz zu EOF (sofort einsatzbereit) die neue virtuelle Maschine länger braucht, um Entwicklern zugute zu kommen. Um dies zu mildern, können wir kurzfristig einige kleine, aber hochwertige EVM-Verbesserungen einführen.Erhöhen Sie das VertragscodierungsgrößenlimitErhöhen Sie DUP/SWAP17-32 Anweisungen usw.

Letztendlich wird uns das eine stark vereinfachte virtuelle Maschine geben. Aber die größte Frage ist: was ist mit der bestehenden EVM?

VM Übergangs-Rückwärtskompatibilitätsstrategie

Wenn man einen Teil der Ethereum Virtual Machine (EVM) bedeutungsvoll vereinfacht (oder sogar verbessert, ohne Komplexität hinzuzufügen), ist die größte Herausforderung: wie man die Abwärtskompatibilität mit bestehenden Anwendungen aufrechterhält, während man das Ziel erreicht.

Zunächst einmal sollte klar sein, dass es keine einheitliche Möglichkeit gibt, den Umfang der „Ethereum-Codebasis“ zu definieren (selbst innerhalb desselben Clients).

Das Ziel ist es, den Umfang des grünen Bereichs so weit wie möglich zu minimieren: das heißt, die Logik, die Knoten ausführen müssen, um am Ethereum-Konsens teilzunehmen, einschließlich der Berechnung des aktuellen Zustands, des Nachweises, der Validierung, des FOCIL (First-Order Consensus Integrity Layer), des grundlegenden Blockaufbaus usw.

Der orangefarbene Bereich kann nicht reduziert werden: Wenn ein bestimmtes Ausführungsschicht-Feature (ob es sich um eine virtuelle Maschine, Vorcompilierung oder einen anderen Mechanismus handelt) aus der Protokollspezifikation entfernt oder seine Funktionalität geändert wird, muss der Client, der mit der Verarbeitung historischer Blöcke befasst ist, ihn dennoch behalten - aber neue Clients (wie ZK-EVMs oder formale Verifizierer) können den orangefarbenen Bereich vollständig ignorieren.

Die neue Kategorie ist der gelbe Bereich: Diese Art von Code ist sehr wichtig für das Verständnis und die Analyse des aktuellen Zustands der Kette und für den Aufbau der besten Blöcke, aber sie gehört nicht zum Konsens. Ein Beispiel ist Etherscan(Und einigeBlock Builder) Unterstützung für Benutzeroperationen von ERC-4337. Wenn wir die On-Chain-RISC-V-Implementierung verwenden, um bestimmte große Funktionen von Ethereum zu ersetzen (wie EOA-Konten und deren Unterstützung für verschiedene alte Transaktionstypen), dann könnten trotz der erheblichen Vereinfachung des Konsenscodes einige professionelle Knoten weiterhin den Originalcode verwenden, um diese Funktionen zu analysieren.

Es ist wichtig, dass die orangefarbenen und gelben Bereiche zu "Gate" gehörenVerkapselungskomplexitätJeder, der das Protokoll verstehen möchte, kann sie überspringen; Ethereum-Clients können sich auch entscheiden, sie nicht zu implementieren, und Fehler in diesen Bereichen stellen kein Konsensrisiko dar. Dies bedeutet, dass die Codekomplexität und der negative Einfluss, die durch die orangefarbenen und gelben Bereiche verursacht werden, viel geringer sind als der grüne Bereich.

Übertragen Sie den Code von der grünen Zone in die gelbe Zone, dieser Ansatz ist ähnlich wie bei Apple Inc.Übersetzen Sie über die Rosetta-ÜbersetzungsschichtUm langfristige Kompatibilität zu gewährleisten.

Ich schlug vor (entliehen von@ipsilon/eof-ethereums-gateway-to-risc-v”> Das folgende Prozess der virtuellen Maschinenmigration (unter Verwendung der EVM-Migration nach RISC-V als Beispiel, aber auch anwendbar auf die EVM-Migration nach Cairo und sogar zukünftige Migration zu einer optimaleren VM):

1. Alle neuen Vorkompilierungen müssen in der standardmäßigen On-Chain-RISC-V-Implementierung verfasst werden, damit das Ökosystem beginnen kann, sich mit RISC-V vertraut zu machen und es als virtuelle Maschine zu nutzen.
2. Vorstellung von RISC-V als Option für Vertragsentwicklung parallel zu EVM für Entwickler. Das Protokoll unterstützt nativ sowohl RISC-V als auch EVM und ermöglicht Verträge, die in beiden Sprachen verfasst sind, frei miteinander zu interagieren.
3. Ersetzen Sie alle Precompiles (außer elliptische Kurvenoperationen und KECCAK) durch eine RISC-V-Implementierung. Wir entfernen diese Precompiles durch einen Hard Fork und ändern gleichzeitig den Code an der entsprechenden Adresse (DAO-Fork-Stil) zu einer RISC-V-Implementierung. Da die RISC-V-VM äußerst prägnant ist, vereinfacht allein dies die Gesamtstruktur.
4. Implementieren Sie einen EVM-Interpreter, der in RISC-V geschrieben ist, und implementieren Sie ihn als Smart Contract auf der Chain. Nach mehreren Jahren der Erstveröffentlichung werden bestehende EVM-Verträge durch diesen Interpreter verarbeitet.

Nach Abschluss von Schritt 4 werden weiterhin viele 'EVM-Implementierungen' verwendet, um den Blockaufbau, Entwicklungstools und die On-Chain-Analyse zu optimieren, aber sie werden nicht mehr Teil der wichtigsten Konsensspezifikationen sein. Zu diesem Zeitpunkt wird der Ethereum-Konsens 'natürlich' nur noch RISC-V verstehen.

Vereinfachen, indem Protokollkomponenten geteilt werden

Die dritte und vielleicht am meisten unterschätzte Vereinfachungsmethode besteht darin, einen einheitlichen Standard über verschiedene Teile des Protokollstapels hinweg so weit wie möglich zu teilen. In der Regel gibt es keinen Grund, in verschiedenen Szenarien unterschiedliche Protokolle für denselben Zweck zu verwenden, aber diese Situation tritt in der Realität immer noch häufig auf, hauptsächlich aufgrund mangelnder Kommunikation zwischen verschiedenen Teilen des Protokollfahrplans. Hier sind einige konkrete Beispiele zur Vereinfachung von Ethereum durch 'Maximierung der Komponentenfreigabe':

Einheitlicher Löschcode

Wir müssen den Löschcode in drei Szenarien korrigieren:

• Datenverfügbarkeitsprüfung - Der Client überprüft, ob der Block veröffentlicht wurde
• Schnellere P2P-Übertragung - Knoten können Blöcke akzeptieren, nachdem sie n/2 von n Blöcken empfangen haben, wodurch das optimale Gleichgewicht zwischen Latenzreduzierung und Redundanz hergestellt wird.
• Verteilte Historienspeicherung - Jedes Stück Geschichte von Ethereum wird in vielen Blöcken gespeichert, so dass (i) diese Blöcke unabhängig verifiziert werden können und (ii) die Hälfte der Blöcke in jeder Gruppe die verbleibende Hälfte wiederherstellen kann, was das Risiko eines einzelnen Blockverlusts erheblich reduziert.

Wenn wir denselben Löschcode (ob es sich um Reed-Solomon, zufälligen linearen Code oder andere handelt) in drei Anwendungsfällen verwenden, werden wir einige wichtige Vorteile erlangen:

1. Minimieren Sie die Gesamtanzahl der Codezeilen
2. Verbessern Sie die Effizienz, denn wenn jeder Knoten verschiedene Teile eines Blocks für einen Anwendungsfall herunterladen muss (anstelle des gesamten Blocks), können die Daten für einen anderen Anwendungsfall verwendet werden.
3. Stellen Sie sicher, dass die Verifizierbarkeit gegeben ist: Alle drei Blöcke im Kontext können anhand des Wurzelelements verifiziert werden

Wenn tatsächlich unterschiedliche Fehlerkorrekturcodes erforderlich sind, sollte zumindest 'Kompatibilität' gewährleistet sein: Zum Beispiel wird im DAS-Szenario Reed-Solomon horizontal und zufälliger linearer Code vertikal verwendet, aber beide basieren auf demselben mathematischen Feld.

Ein einheitliches Serialisierungsformat

Derzeit ist das Serialisierungsformat von Ethereum streng genommen nur "halbstandardisiert", da Daten in beliebigem Format neu serialisiert und übertragen werden können. Die einzige Ausnahme ist der Transaktionssignatur-Hash, bei dem ein standardisiertes Format für die Hash-Berechnung erforderlich ist.
Aber die Standardisierung zukünftiger Serialisierungsformate wird aus zwei Gründen weiter verbessert werden:

• Umfassende Kontenabstraktion (EIP-7701): Die virtuelle Maschine wird in der Lage sein, den vollständigen Transaktionsinhalt zu sehen
• Gaslimit-Erhöhung: Ausführungsblockdaten müssen in Blob verpackt werden

Zu diesem Zeitpunkt haben wir die Möglichkeit, die für die aktuellen drei Aspekte erforderlichen Serialisierungslösungen zu vereinheitlichen: 1) Ausführungsschicht; 2) Konsensschicht; 3) Smart Contract-Aufruf-ABI.

Ich schlage vor, SSZ(Simple Serialize), weil SSZ folgende Vorteile hat:

• Leicht zu entschlüsseln: einschließlich innerhalb von Smart Contracts (basierend auf dem 4-Byte-Design, wenige Grenzfälle)
• Weit verbreitet in Konsens
• Hochgradig ähnlich zum bestehenden ABI: niedrige Werkzeugmigrationskosten

Derzeit wurden weitere Komponenten hinzugefügtMigrationZu SSZArbeitenBei der Planung zukünftiger Upgrades sollten wir diese Entwicklungen vollständig berücksichtigen und nutzen.

Eine einheitliche Baumstruktur

Sobald wir von EVM zu RISC-V (oder einem anderen minimalistischen VM) migrieren, wird der hexadezimale Merkle-Patricia-Baum selbst in durchschnittlichen Szenarien zum größten Engpass für den Nachweis der Blockausführung. Die Migration zu einer HashfunktionBinärbaum, wird die Effizienz des Verifizierers erheblich verbessern und die Datenkosten von Leichtknoten und anderen Szenarien reduzieren.

Beim Abschluss der Migration der Baumstruktur sollten wir auch sicherstellen, dass die Konsensschicht dieselbe Baumstruktur verwendet, um sicherzustellen, dass das gesamte Ethereum - sowohl die Konsens- als auch die Ausführungsschichten - mithilfe desselben Code-Sets aufgerufen und analysiert werden kann.

Von jetzt an die Zukunft

Vereinfachung und Dezentralisierung haben viele Ähnlichkeiten. Beide sind vorgelagerte Anforderungen, die notwendig sind, um das höhere Ziel der Systemresilienz zu erreichen. Die Betonung der Vereinfachung erfordert explizit einen kulturellen Wandel. Die Vorteile der Vereinfachung sind oft schwer zu erkennen in den frühen Stadien, aber die Opportunitätskosten und die zusätzliche Arbeitsbelastung durch die Ablehnung dieser 'glänzenden neuen Funktionen' sind sofort ersichtlich. Im Laufe der Zeit jedoch wird der langfristige Wert der Vereinfachung zunehmend offensichtlich - Bitcoin selbst ist ein ausgezeichnetes Beispiel.

Ich schlage vor, dass wirLernen Sie vom Ansatz des tinygradUm ein klares Code-Zeilenlimitziel für die langfristige Spezifikation von Ethereum festzulegen, ist das Ziel, den konsenskritischen Code von Ethereum so nah wie möglich an den minimalistischen Stil von Bitcoin heranzuführen. Der Code, der sich mit den historischen Regeln von Ethereum befasst, wird weiterhin existieren, sollte jedoch vom konsenskritischen Pfad isoliert werden. Gleichzeitig sollten wir ein universelles Designprinzip bilden: Wählen Sie einfachere Lösungen, wann immer möglich, priorisieren Sie eingekapselte Komplexität über systemische Komplexität und neigen Sie zu Designentscheidungen, die klare überprüfbare Eigenschaften und Garantien bieten.

Haftungsausschluss:

1. Dieser Artikel wurde von [vitalik] nachgedruckt. Alle Urheberrechte gehören dem Originalautor [vitalikAlle. Wenn Sie Einwände gegen diesen Nachdruck haben, wenden Sie sich bitte anGate LearnDas Team wird es zeitnah bearbeiten.
2. Haftungsausschluss: Die Ansichten und Meinungen, die in diesem Artikel zum Ausdruck gebracht werden, sind ausschließlich die des Autors und stellen keine Anlageberatung dar.
3. Das Gate Learn-Team übersetzt Artikel in andere Sprachen. Das Kopieren, Verteilen oder Plagiieren von übersetzten Artikeln ist untersagt, sofern nicht anders angegeben.