Vitalik: Die mögliche Zukunft des Ethereum -Protokolls – die Säuberung

Autor: Vitalik, Gründer von Ethereum;

Hinweis: Dieser Artikel ist der fünfte Teil der Artikelreihe, die kürzlich von Vitalik, Gründer von Ethereum, veröffentlicht wurde.Mögliche Futures des Ethereum -Protokolls, Teil 5: Die Spülung„, Siehe den vierten Teil“Vitalik: Der Rand von Ethereum„. Sehen „Vitalik: Hauptziele des Ethereum Die Geißelphase„, Siehe den zweiten Teil“Vitalik: Wie sollte sich das Ethereum -Protokoll im Surge -Stadium entwickeln?„, Siehe den ersten Teil“Was kann bei Ethereum POS noch verbessert werden”.

---

Eine der Herausforderungen für Ethereum besteht darin, dass standardmäßig das Aufblähen und die Komplexität eines Blockchain -Protokolls im Laufe der Zeit zunehmen werden.Dies geschieht auf zwei Arten:

• Historische Daten:Jede Transaktion und jedes Konto, das in jedem historischen Moment erstellt wurde, muss dauerhaft von allen Clients gespeichert und von jedem neuen Client heruntergeladen werden, der vollständig mit dem Netzwerk synchronisiert ist.Dies führt dazu, dass die Last und die Synchronisierungszeit im Laufe der Zeit zugenommen werden, auch wenn die Kapazität der Kette gleich bleibt.

• Protokollfunktionen:Das Hinzufügen neuer Funktionen ist viel einfacher als das Entfernen alter Funktionen, was dazu führt, dass die Codekomplexität im Laufe der Zeit zunimmt.

Damit Ethereum lange hält, müssen wir beide Trends intensiviert werden, wodurch die Komplexität verringert und im Laufe der Zeit aufblähen muss.Aber gleichzeitig, ichWir müssen eines der wichtigsten Attribute der Blockchain beibehalten: Persistenz.Sie können NFTs, Liebesbriefe in Transaktionsanrufdaten oder intelligente Verträge mit einer Million Dollar in der Kette einstellen, zehn Jahre lang eine Höhle eingeben und feststellen, dass sie immer noch darauf warten, dass Sie lesen und interagieren.Damit Dapps vollständig dezentralisiert sind und Upgrade -Tasten mit Zuversicht entfernen müssen, müssen sie sicher sein, dass ihre Abhängigkeiten nicht auf eine Weise verbessert werden, die sie bricht – insbesondere L1 selbst.

Die Säuberung, 2023 Roadmap.

Wenn wir uns auf diese beiden Bedürfnisse konzentrieren und ausgleichen, ist es absolut möglich, Expansion, Komplexität und Rezession zu minimieren oder umzukehren.Organismen können dies tun: Während die meisten Organismen im Laufe der Zeit altern, altern Sie zum Glück einige Organismen nicht.Sogar soziale Systeme können eine extrem lange Lebensdauer haben.In einigen Fällen war Ethereum erfolgreich: Der Arbeitsnachweis ist verschwunden, der OPCODE SELTERSTRUKTE ist im Grunde genommen verschwunden und der Beacon Chain -Knoten hat bis zu sechs Monate alte Daten gespeichert.Das Finden dieses Weges für Ethereum in allgemeinerer Weise und sich auf ein langfristiges stabiles Endergebnis zu bewegen, ist die endgültige Herausforderung für die langfristige Skalierbarkeit von Ethereum, die technologische Nachhaltigkeit und sogar die Sicherheit.

Die Säuberung: Hauptziele

• Reduzieren Sie die Speicheranforderungen des Kunden, indem Sie die Notwendigkeit reduzieren oder beseitigen, dass jeder Knoten die gesamte Geschichte dauerhaft speichert, und kann ihn sogar abschließen

• Reduzieren Sie die Protokollkomplexität, indem Sie unerwünschte Merkmale beseitigen

Historische Daten sind abgelaufen

Welche Probleme lösen es?

Zum jetzigen Zeitpunkt benötigt ein vollständig synchronisierter Ethereum -Knoten ungefähr 1,1 TB Speicherplatz, um den Client auszuführen, und einige hundert GB Platz für den Konsenskunden.Die meisten von ihnen sind historische Daten: Daten zu historischen Blöcken, Transaktionen und Einnahmen, von denen die meisten vor Jahren stammen.Dies bedeutet, dass selbst wenn die Gasgrenze überhaupt nicht zunimmt, die Größe des Knotens um Hunderte von GB pro Jahr steigt.

Was ist das?Wie funktioniert es?

Ein wichtiges vereinfachtes Merkmal des historischen Speicherproblems besteht darin, dass jeder Block durch Hash -Verbindungen (und andere Strukturen) auf den vorherigen Block verweist, dass es ausreicht, einen Konsens über den Strom zu erzielen, um einen Konsens über die Geschichte zu erzielen.Solange das Netzwerk auf den neuesten Block zustimmt, kann jeder historische Block, jede Transaktion oder jeden Status (Kontostand, Zufallsnummer, Code, Speicher) von jedem einzelnen Teilnehmer mit Merkle -Proof bereitgestellt werden, und der Beweis kann jedem anderen überprüfen ist korrekter Sex.Obwohl der Konsens das N/2-of-N-Vertrauensmodell ist, ist die Geschichte das 1-von-N-Vertrauensmodell.

Dies eröffnet viele Möglichkeiten, wie wir die Geschichte speichern.Eine natürliche Wahl ist ein Netzwerk, in dem jeder Knoten nur einen kleinen Teil der Daten speichert.Auf diese Weise funktioniert das Torrent -Netzwerk seit Jahrzehnten: Während das Netzwerk Millionen von Dateien insgesamt speichert und verteilt, speichert und verteilt jeder Teilnehmer nur einige davon.Vielleicht reduziert dieser Ansatz möglicherweise nicht einmal die Robustheit der Daten.Wenn wir ein Netzwerk von 100.000 Knoten implementieren können, indem wir die Kosten des Knotenbetriebs reduzieren, wobei jeder Knoten zufällig 10% der Geschichte speichert, wird jedes Datenstück 10.000 -mal kopiert – mit 10.000 des in dem Knoten gespeicherten Inhalts des Replikationsfaktors jedes Knotennetzes ist genau das gleiche.

Heute hat Ethereum begonnen, das Modell loszuwerden, in dem alle Knoten die gesamte Geschichte dauerhaft speichern.Der Konsensblock (d. H. Der Abschnitt im Zusammenhang mit dem Beweis für den Stakelkonsens) wird nur etwa 6 Monate lang gespeichert.Blobs werden nur etwa 18 Tage aufbewahrt.EIP-4444 ist so konzipiert, dass er einen einjährigen Speicherraum für historische Blöcke und Quittungen einführen soll.Das langfristige Ziel ist es, eine koordinierte Zeit (wahrscheinlich ungefähr 18 Tage) zu haben, in der jeder Knoten für die Speicherung von allem verantwortlich ist, und dann gibt es ein Peer-to-Peer-Netzwerk von Ethereum-Knoten, die alte Daten auf verteilte Weise speichern .

Das Löschen der Codierung kann verwendet werden, um die Robustheit zu verbessern und gleichzeitig den Replikationsfaktor unverändert zu halten.Zur Unterstützung der Datenverfügbarkeitsabtastung haben Blobs Löschcodes angewendet.Die einfachste Lösung könnte darin bestehen, diesen Löschcode wiederzuverwenden und die Ausführungs- und Konsensblockdaten auch in den Blob zu setzen.

Welche Forschung gibt es?

EIP-4444:https://eips.ethereum.org/eips/eip-4444

Torrents und EIP-4444:https://ethresear.ch/t/torrents-and-eip-4444/19788

Portalnetzwerk:https://ethereum.org/en/developers/docs/networking-layer/portal-network/

Portalnetzwerk und EIP-4444:Verteilte Speicher und Abruf von SSZ -Objekten im Portal:https://ethresear.ch/t/distributed-storage-and-cryptographicy-secured-retrieval-of-sz-objects-for-portal-network/19575

So erhöhen Sie die Gasgrenze (Parameter):https://www.paradigm.xyz/2024/05/how-to-raise-the-gas-limit-2

Was sind der Rest und welche Kompromisse gibt es?

Die verbleibende Hauptarbeit besteht darin, eine konkrete verteilte Lösung zu bauen und zu integrieren, um die Geschichte zu speichern – im kleinsten Ausführungsgeschichte, aber letztendlich auch Konsens und Blobs.Die einfachste Lösung ist (i) einfach die vorhandene Torrent -Bibliothek und (ii) eine native Lösung von Ethereum namens Portal Network.Sobald eine davon eingeführt wird, können wir EIP-4444 aktivieren.EIP-4444 selbst erfordert keine harte Gabel, aber eine neue Version des Netzwerkprotokolls.Daher ist es wertvoll, es für alle Kunden gleichzeitig zu aktivieren, da die Kunden ansonsten möglicherweise versagen, weil sie eine Verbindung zu anderen Knoten herstellen, die erwarten, die vollständige Geschichte herunterzuladen, aber nicht tatsächlich implementiert.

Der Hauptabschluss besteht darin, wie wir arbeiten, um „vorherige“ historische Daten zur Verfügung zu stellen.Die einfachste Lösung besteht darin, morgen frühere Daten einzustellen und sich auf vorhandene Archivknoten und verschiedene zentralisierte Anbieter zur Replikation zu verlassen.Dies ist einfach, aber es schwächt die Position von Ethereum als Aufzeichnung dauerhafter Daten.Ein schwierigerer, aber sichererer Ansatz ist es, zuerst ein Torrent -Netzwerk zu bauen und zu integrieren, um die Geschichte auf verteilte Weise zu speichern.Hier gibt es zwei Dimensionen:

• Wie viel Aufwand müssen wir sicherstellen, dass die maximale Anzahl von Knoten alle Daten speichert?

• Wie tief integrieren wir historische Speicherung mit Protokollen?

Für (1) würde der strengste Ansatz einen Sorgerechtsnachweis beinhalten: Tatsächlich ist jeder Nachweis des Pfahlbeurteilers erforderlich, um einen bestimmten Prozentsatz der Geschichte zu speichern und regelmäßig zu überprüfen, ob sie dies durch Verschlüsselung tun.Ein bescheidenerer Ansatz besteht darin, einen freiwilligen Standard für den Prozentsatz der pro Kunden gespeicherten Geschichte festzulegen.

Für (2) beinhaltet die grundlegende Implementierung nur das, was heute getan wurde: Portal hat eine ERA -Datei mit der gesamten Ethereum -Geschichte gespeichert.Eine gründlichere Implementierung würde das tatsächlich mit dem Synchronisationsprozess verbinden, sodass jemand, wenn jemand den vollständigen Verlaufspeicherknoten oder den Archivknoten synchronisieren möchte, auch wenn keine anderen Archivknoten online sind, dies tun können, indem sie direkt aus dem Portalnetzwerk synchronisiert werden.

Wie interagiert es mit dem Rest der Roadmap?

Wenn wir den Knoten mit extrem einfacher oder starten, können die historischen Speicheranforderungen wohl wichtiger sein als Staatelos: Der vom Knoten geforderte 1,1 TB ist der Zustand, und der verbleibende rund 800 GB ist die Geschichte.Die Vision des Ethereum-Knotens, das in einer Smartwatch und in nur wenigen Minuten eingestellt wird, wird nur dann erreicht, wenn gleichzeitig ein Stauro und EIP-4444 erreicht werden.

Durch die Begrenzung der historischen Speicherung wird auch neuere Ethereum -Knoten -Implementierungen möglich, nur die neuesten Versionen des Protokolls zu unterstützen, was sie viel einfacher macht.Da beispielsweise alle leeren Speicherschlitze, die während des DOS -Angriffs 2016 erstellt wurden, gelöscht wurden, können viele Codezeilen sicher gelöscht werden.Nachdem der Verlauf des Anteils zu einem Anteil des Einsatzes gewechselt ist, kann der Client alle Code im Zusammenhang mit dem Arbeitsnachweis sicher löschen.

Statusdaten sind abgelaufen

Welche Probleme lösen es?

Selbst wenn wir die Notwendigkeit des Kundenspeicherverlaufs beseitigen, wird die Kundenspeichernachfrage weiter wachsen, etwa 50 GB pro Jahr, da der Staat weiter wächst: Kontos und Zufallszahlen, Vertragscodes und Auftragspeicher.Benutzer können eine einmalige Gebühr zahlen, die die aktuellen und zukünftigen Ethereum-Kunden immer belastet.

Der Zustand ist schwieriger zu „abirat“ als die Geschichte, da die grundlegende Design -Annahme von EVM darin besteht, dass ein staatliches Objekt für immer existiert und jederzeit durch jede Transaktion gelesen wird.Wenn wir Staatenlose einführen, glauben einige Leute, dass dieses Problem möglicherweise nicht so schlecht ist: Nur eine Klasse spezialisierter Blockbauer erfordert die tatsächliche Speicherung des Zustands, und alle anderen Knoten (auch einschließlich der Listengenerierung!) Können sie staatenlos ausgeführt werden.Einige Leute glauben jedoch, dass wir uns nicht zu sehr auf Staatenlosigkeit verlassen wollen, und schließlich möchten wir, dass der Staat aussieht, um Ethereum dezentralisiert zu halten.

Was ist das?Wie funktioniert es?

Wenn Sie heute ein neues staatliches Objekt erstellen (kann auf eine von drei Arten durchgeführt werden: (i) Senden Sie ETH an ein neues Konto, (ii) ein neues Konto mit dem Code erstellen und (iii) zuvor unberührtes Speicher einrichten). Das Staatsobjekt wird immer in diesem Zustand sein.Stattdessen wollen wir, dass das Objekt im Laufe der Zeit automatisch abläuft.Die wichtigste Herausforderung besteht darin, dies auf eine Weise zu tun, die drei Ziele erreicht:

• Effizienz:Um den Ablaufprozess durchzuführen, ist keine große Menge an zusätzlicher Berechnung erforderlich.

• Benutzerfreundlichkeit:Wenn jemand fünf Jahre in die Höhle zurückkommt, sollte er keinen Zugang zu seinen ETH-, ERC20-, NFT-, CDP -Positionen verlieren …

• Entwickler Freundlichkeit:Entwickler müssen nicht zu völlig unbekannten Denkmodellen wechseln.Darüber hinaus sollten Anwendungen, die jetzt starr und nicht geplant sind, weiterhin angemessen laufen.

Ohne diese Ziele zu erreichen, ist das Problem leicht zu lösen.Zum Beispiel können Sie jedes Staatsobjekt auch einen Zähler speichern lassen, um sein Ablaufdatum (die durch die Zerstörung der ETH zu erweitern ist, die beim Lesen oder Schreiben automatisch auftreten kann) und eine Schleife durch den Staat zu haben, um den Ablaufzustand zu löschen Prozess des Objekts.Dies führt jedoch zu zusätzlichen Berechnung (sogar Speicheranforderungen) und erfüllt die Benutzerfreundlichkeitsanforderungen sicherlich nicht.Für Entwickler ist es auch schwierig, über extreme Fälle zu argumentieren, bei denen gespeicherte Werte manchmal auf Null zurückgesetzt werden.Wenn Sie den Ablauf -Timer innerhalb des Vertragsumfangs einstellen, erleichtert dies technisch die Arbeit von Entwicklern, aber die Wirtschaft noch schwieriger: Entwickler müssen darüber nachdenken, wie sie die laufenden Lagerkosten für ihre Benutzer „weitergeben“.

Dies sind Themen, die die Ethereum Core Development Community seit Jahren schwer zu lösen hat, einschließlich Vorschlägen wie „Blockchain -Miete“ und „Regeneration“.Letztendlich kombinieren wir die besten Teile des Vorschlags und konzentrieren uns auf zwei Kategorien „Die am wenigsten bekannten Lösungen“:

• Einige staatliche Ablauflösungen.

• Vorschläge des Zustands nach Ablauf des Adresszyklus.

Ein gewisser Status ist abgelaufen

Einige Vorschläge für die staatlichen Ablauf folgen den gleichen Prinzipien.Wir teilen den Staat in Stücke.Jeder speichert die „Karte der obersten Ebene“ dauerhaft und welche Blöcke leer oder nicht leer sind.Die Daten in jedem Block werden nur dann gespeichert, wenn sie kürzlich besucht wurden.Es gibt einen „Resurrection“ -Mechanismus, bei dem jeder, wenn ein Block mehr gespeichert ist, jeder diese Daten wiederherstellen kann, indem er den Nachweis dafür vorlegt, was er ist.

Die Hauptunterschiede zwischen diesen Vorschlägen sind: (i) Wie definieren wir „in letzter Zeit“ und (ii) wie definieren wir „Blöcke“?Ein spezifischer Vorschlag ist EIP-7736, das auf dem für Perla-Bäume eingeführten „Stamm- und Blatt“ -Ergänge aufbaut (obwohl sie mit jeder Form von Staatenlosenbäumen wie binären Bäumen kompatibel ist).In diesem Design werden Header, Codes und Speicherplätze nebeneinander unter demselben „Stamm“ gespeichert.Daten, die unter dem Stamm gespeichert sind, können bis zu 256 * 31 = 7.936 Bytes betragen.In vielen Fällen werden der gesamte Titel und Code des Kontos sowie viele wichtige Speicherplätze unter demselben Rückgrat gespeichert.Wenn die Daten unter einem bestimmten Rückgrat nicht innerhalb von 6 Monaten gelesen oder geschrieben werden, werden die Daten nicht mehr gespeichert, sondern nur die 32-Byte-Verpflichtung für die Daten („Stub“).Zukünftige Transaktionen, die auf diese Daten zugreifen, müssen die Daten „wiederbeleben“ und den Nachweis der Überprüfung mit dem Stub „wiederholen“.

Es gibt andere Möglichkeiten, ähnliche Ideen zu implementieren.Wenn das Kontointervall beispielsweise nicht ausreicht, können wir einen Plan entwickeln, bei dem jeder Teil des Baumes durch einen ähnlichen Stamm- und Blattmechanismus gesteuert wird.

Dies ist aufgrund von Motivationsfaktoren noch schwieriger: Ein Angreifer kann den Baum „aktualisieren“, indem er eine große Menge an Daten in einen einzelnen Unterbaum einbringt und jedes Jahr eine einzige Transaktion sendet, was den Kunden dazu zwingt, dauerhaft eine große Menge an Zustand zu speichern.Wenn Sie die Aktualisierungskosten proportional zur Baumgröße (oder der Aktualisierungsdauer umgekehrt proportional zur Baumgröße) vornehmen, kann jemand einen anderen Benutzer verletzen, indem sie viele Daten in denselben Unterbaum wie sie einbringt.Sie können versuchen, diese beiden Probleme zu begrenzen, indem Sie Kontointervalle basierend auf der Größe des Unterbaums dynamisch regulieren: Beispielsweise kann jeweils 2^16 = 65536 Zustandsobjekte als „Gruppe“ behandelt werden.Diese Ideen sind jedoch komplexer.

Vorschläge des Zustands nach Ablauf des Adresszyklus basieren auf dem Adresszyklus

Was ist, wenn wir ein dauerhaftes staatliches Wachstum ganz vermeiden wollen, selbst einen 32-Byte-Stub?Hier ist ein Puzzle: Was ist, wenn das Zustandsobjekt gelöscht wird und später die EVM -Ausführung ein anderes Statusobjekt in die gleiche Position bringt, aber dann die Person, die sich um das ursprüngliche Zustandsobjekt kümmert, zurückkommt und versucht, es wiederherzustellen?Für einige staatliche Ablauf verhindert der Stub, dass neue Daten erstellt werden.Für den vollständigen Statusablauf können wir nicht einmal Stubs speichern.

Adresszyklus-basierte Design ist der beste Weg, um dieses Problem zu lösen.Anstatt den gesamten Staat mit einem Staatsbaum zu speichern, haben wir eine wachsende Liste staatlicher Bäume, und im neuesten Staatsbaum werden gelesene oder schriftliche Staaten gerettet.Fügen Sie in jedem Zyklus einen neuen leeren Staatsbaum hinzu (denken Sie: 1 Jahr).Ältere Staatsbäume sind festgelegt.Der volle Knoten muss nur die beiden engsten Bäume speichern.Wenn das Zustandsobjekt nicht innerhalb von zwei Zyklen berührt wird und daher in den abgelaufenen Baum fällt, kann es weiterhin gelesen oder geschrieben werden. Die Transaktion muss jedoch beweisen, dass es Merkle -Proof beweist. Wenn die Kopie nach der Fertigstellung erneut gespeichert wird .

Eine wichtige Idee, um dies nur benutzer- und entwicklerfreundlich zu machen, ist das Konzept der Adresszyklen.Der Adresszyklus ist eine Nummer, die Teil der Adresse ist.Eine Schlüsselregel ist, dass Adressen mit einem Adresszeitraum N nur während oder nach Zeitraum n gelesen oder geschrieben werden können (d. H. Wenn die Statusbaumliste Länge n erreicht).Wenn Sie ein neues staatliches Objekt speichern möchten (z. B. einen neuen Vertrag oder ein neues ERC20-Saldo), können Sie es speichern, wenn Sie sicherstellen, dass das Staatsobjekt mit einer Adresszeit von N oder N-1 in einen Vertrag gesteckt wird Sofort ohne es zu liefern, keinen Beweis für etwas vorher.Auf der anderen Seite erfordert jede staatliche Ergänzung oder Bearbeitung im alten Adresszyklus Beweise.

Dieses Design behält die meisten aktuellen Eigenschaften von Ethereum bei, wobei sehr kleine zusätzliche Berechnungen geschrieben werden können, sobald sie jetzt so sind (ERC20 Periode n) und löste das Problem, dass „Benutzer fünf Jahre lang in die Höhle eintreten“.Es hat jedoch ein großes Problem:Die Adresse muss auf mehr als 20 Bytes erweitert werden, um den Adresszyklus anzupassen.

Adressraumverlängerung

Ein Vorschlag besteht darin, ein neues 32-Byte-Adressformat einzuführen, das die Versionsnummer, die Adressperiodennummer und den erweiterten Hash-Wert enthält.

0x01000000000157AE408398DF7E5F4552091A69125D5DFCB7B8C2659029395BDF

Rot ist die Versionsnummer.Hier repräsentieren die vier orangefarbenen Nullen leere Räume und können in Zukunft Shard -Nummern aufnehmen.Grün ist die Adressperiodennummer.Blue ist ein 26-Byte-Hash.

Die wichtigste Herausforderung hier ist die Rückwärtskompatibilität.Bestehende Verträge werden um 20-Byte-Adressen konzipiert und werden häufig mit engen Byte-Verpackungstechniken verwendet, sodass die Adresse genau 20-Byte-Long beträgt.Eine Idee, um dieses Problem zu lösen, besteht darin, ein Transformationsdiagramm zu verwenden, bei dem ein alter Vertrag, der mit einer neuen Adresse in neuer Art interagiert, mit einem 20-Byte-Hash der neuen Adresse in der neuen Art von Art.Es erfordert jedoch erhebliche Anstrengungen, um seine Sicherheit zu gewährleisten.

Raumkontraktion ansprechen

Umgekehrt: Wir deaktivieren sofort einige Adressstuben der Größe 2128 (z.

0xFFFFFFFF000169125D5DFCB7B8C2659029395BDF

Das Hauptopfer dieses Ansatzes besteht darin, dass er Sicherheitsrisiken für kontrafaktische Adressen einführt: Adressen, die Vermögenswerte oder Berechtigungen enthalten, deren Code jedoch nicht in der Kette veröffentlicht wurde.Das Risiko betrifft jemand, der eine Adresse erstellt, die behauptet, einen (noch nicht veröffentlichten) Code zu haben, aber es gibt einen weiteren gültigen Code mit dem Hash -Wert, der auf dieselbe Adresse zeigt.Durch die Berechnung solcher Kollisionen sind 280 Hashes erforderlich.

Der kritische Risikobereich, nicht die kontrafaktische Adresse einer Brieftasche, die von einem einzelnen Besitzer gehalten wird, ist heute eine relativ seltene Situation, aber wenn wir in die Multi-L2-Welt eintreten, kann diese Situation häufiger werden.Die einzige Lösung besteht darin, dieses Risiko einfach zu akzeptieren, aber alle häufigen Anwendungsfälle zu identifizieren, in denen Probleme auftreten können, und wirksame Lösungen finden.

Welche Forschung gibt es?

Frühe Vorschläge

Blockchain -Mietgebühr:https://github.com/ethereum/eips/issues/35

Regenese:https://ethresear.ch/t/regenesis-resetting-ethereum-toce-the-burden-of-large-blockchain-state/7582

Theorie der Ethereum State Größenmanagement:https://hackmd.io/@vbuterin/state_size_management

Mehrere mögliche Wege für den Verfallsdauer von Staaten und zum Zustand:https://hackmd.io/@vbuterin/state_expiry_paths

Einige Statusabfallsvorschläge

EIP-7736:https://eips.ethereum.org/eips/eip-7736

Adressraum erweitertes Dokument

Originalvorschlag:https://ethereum-magices.org/t/increassing-address-Size-from-20-to-32-bytes/5485

Ipsilon kommentiert:https://notes.ethereum.org/@ipsilon/address-space-eutsion- exploration

Blog -Beitrag Kommentare:https://medium.com/@chaisomsri96/stationessneless-series-part2-ase-address-space-eutsion-60626544b8e6

Was passiert, wenn wir den Widerstand gegen Kollision verlieren:https://ethresear.ch/t/what-would-break-fe-we-lose-address-collision-resistant/11356

Was bleibt noch zu tun?Was wiegen zu wiegen?

Ich denke, es gibt in Zukunft vier tragfähige Wege:

• Wir praktizieren Staatenlosigkeit und führen niemals den staatlichen Ablauf ein.Der Staat wächst (obwohl langsamer: Wir sehen es in Jahrzehnten möglicherweise nicht über 8 TB), muss aber nur von relativ professionellen Benutzerkategorien gehalten werden: Selbst POS -Validatoren benötigen keinen Zustand.

  Eine Funktion, die Zugriff auf einen Teilstaat erfordertImplementieren Sie dies auf dezentrale Weise:Jeder Benutzer ist für die Aufrechterhaltung des Statusbaumteils verantwortlich, der sein eigenes Konto enthält.Wenn sie Transaktionen ausstrahlen, übertragen sie den während des Überprüfungsschritts zugegriffenen Statusobjekte Beweise (dies gilt für EOA- und ERC-4337-Konten).Der Staatelo Validator kann diese Beweise dann in den gesamten Beweis kombinieren, der die Liste enthält.

• Wir umsetzen einen teilweisen staatlichen Ablauf und akzeptieren eine viel niedrigere, aber dennoch nicht null dauerhafte staatliche Größenwachstumsrate.Dieses Ergebnis kann einem historischen Ablaufvorschlag mit Peer-to-Peer-Netzwerken ähnlich sein, der eine dauerhafte historische Speicherwachstumsrate akzeptiert, die jeder Kunde einen niedrigeren, aber festen Prozentsatz der historischen Daten speichern muss, aber viel niedriger ist, aber immer noch nicht Null.

• Wir deklarieren das Ablaufdatum und erweitern den Adressraum.Dies beinhaltet ein mehrjähriges Verfahren, um sicherzustellen, dass die Anmeldungsformatversorgungsmethoden effektiv und sicher sind, einschließlich für vorhandene Anwendungen.

• Wir haben das Ablaufdatum deklariert und den Adressraum verkleinert.Dies beinhaltet ein mehrjähriges Verfahren, um sicherzustellen, dass alle Sicherheitsrisiken, die Konflikte, einschließlich kreuzkettiger Situationen, angehen, behandelt werden.

Ein wichtiger Punkt ist, ob ein staatliches Ablaufschema, das auf Änderungen des Adressformates beruht oder nicht, implementiert wird, das Problem der Adressraumerweiterung und -schrumpfung letztendlich gelöst werden muss.Heutzutage sind etwa 2^80 Hashes erforderlich, um Adresskonflikte zu erzeugen, und diese Rechenlast ist bereits für extrem ressourcenreiche Teilnehmer möglich: Die GPU kann ungefähr 2^27 Hashes tun, sodass sie ein Jahr lang betrieben werden kann werden berechnet, sodass etwa 2^30 GPUs der Welt Konflikte in etwa 1/4 des Jahres berechnen können, und FPGAs und ASICs können diesen Prozess weiter beschleunigen.In Zukunft werden solche Angriffe immer mehr Menschen offen sein.Daher sind die tatsächlichen Kosten für die Implementierung eines vollständigen staatlichen Ablaufs möglicherweise nicht so hoch, wie es scheint, da wir dieses sehr herausfordernde Adressproblem trotzdem lösen müssen.

Wie interagiert es mit dem Rest der Roadmap?

Durch die Ausführung des Verfalls der Staatsstaat kann die Umwandlung von einem Zustandsbaumformat in ein anderes einfacher gestellt werden, da der Konvertierungsprozess nicht erforderlich ist: Sie können einfach einen neuen Baum mit einem neuen Format erstellen und ihn später aushärten, um den alten Baum zu konvertieren.Während der Zustand des Staates komplex ist, hilft es, andere Aspekte der Roadmap zu vereinfachen.

Funktionsreinigung

Welche Probleme lösen es?

Eine der wichtigsten Voraussetzungen für Sicherheit, Zugänglichkeit und Vertrauenswürdigkeit ist Einfachheit.Wenn das Protokoll schön und einfach ist, wird die Möglichkeit von Fehlern verringert.Es erhöht die Wahrscheinlichkeit, dass neue Entwickler jeden Teil davon beitreten und verwenden können.Es ist wahrscheinlicher, dass es fair ist und eher besonderen Interessen widerspricht.Leider werden Protokolle wie jedes soziale System im Laufe der Zeit standardmäßig komplexer.Wenn wir Ethereum nicht in ein immer komplexeres Schwarzes Loch bringen wollen, müssen wir eines von zwei Dingen tun:(i) Hören Sie auf, Änderungen vorzunehmen und das Protokoll zu starren, (ii) in der Lage sein, Merkmale tatsächlich zu entfernen und die Komplexität zu verringern.Zwischenrouten, d. H. weniger Änderungen des Protokolls vornehmen und gleichzeitig im Laufe der Zeit mindestens ein wenig Komplexität beseitigen, sind ebenfalls möglich.In diesem Abschnitt wird erläutert, wie die Komplexität reduziert oder beseitigt werden kann.

Was ist das?Wie funktioniert es?

Es gibt keine große Einzelfixe, die die Protokollkomplexität reduziert.

Ein im Grunde genommen ein Beispiel, das als Blaupause verwendet werden kann, um mit anderen Problemen umzugehen, nämlich das Löschen des OPCODE des Selbstentwicklung.Der Opcode für Selbstentwicklung ist der einzige Opcode, der eine unbegrenzte Anzahl von Speicherplatz in einem einzelnen Block ändern kann, was eine größere Komplexität von Clients erfordert, um DOS -Angriffe zu vermeiden.Der ursprüngliche Zweck dieses Opcode besteht darin, eine freiwillige Zustandslöschung zu erreichen, sodass die Zustandsgröße im Laufe der Zeit abnimmt.Tatsächlich benutzen nur wenige Menschen es.Dieser Opcode wird geschwächt und ermöglicht nur Selbstzerstörungskonten, die in derselben Transaktion in der Hardgabel von Dencun erstellt wurden.Dies löst DOS -Probleme und ermöglicht eine erhebliche Vereinfachung des Client -Code.In Zukunft könnte es sinnvoll sein, den Opcode schließlich vollständig zu entfernen.

Einige wichtige Beispiele für die bisher identifizierten Protokollvereinfachungsmöglichkeiten umfassen die folgenden.Erstens sind einige Beispiele außerhalb von EVM;

• RLP → SSZ -Konvertierung:Anfangs wurden Ethereum -Objekte unter Verwendung einer Codierung namens RLP serialisiert.Heutzutage verwenden Beacon Chains SSZ, was in vielerlei Hinsicht erheblich besser ist, einschließlich der Unterstützung der Serialisierung, sondern auch der Hashing.Letztendlich möchten wir RLP vollständig beseitigen und alle Datentypen in die SSZ -Struktur verschieben, was wiederum das Upgrade leichter ausmacht.Zu den derzeit vorgeschlagenen EIPs gehören [1] [2] [3].

• Alte Transaktionstypen löschen:Es gibt heute zu viele Arten von Transaktionen, und viele von ihnen können gelöscht werden.Eine bescheidenere Alternative zum vollständig gelöschten Löschen ist die Funktion zur Abstraktion von Konto, über die intelligente Konten Codes enthalten können, um Legacy -Transaktionen zu verarbeiten und zu überprüfen (falls dies wünscht).

• Protokollreform:Protokolle erzeugen Bloom -Filter und andere Logik und verleihen dem Protokoll Komplexität, aber weil es zu langsam ist, verwendet der Client es nicht tatsächlich.Wir können diese Funktionen entfernen und stattdessen unsere Energie Alternativen widmen, z.

• Schließlich wird der Mechanismus des Beacon Chain -Synchronisierungsausschusses annulliert:Der Mechanismus des Synchronisierungsausschusses wurde ursprünglich eingeführt, um die Authentifizierung der leichten Client für Ethereum zu ermöglichen.Es fügt jedoch die Komplexität des Protokolls hinzu.Letztendlich können wir Snark verwenden, um die Ethereum Consensus -Schicht direkt zu überprüfen, wodurch ein dediziertes Light -Client -Verifizierungsprotokoll erforderlich ist.Durch Erstellen eines „nativen“ leichten Client -Client -Protokolls, das die Validierung von Signaturen aus einer zufälligen Untergruppe des Ethereum -Konsens -Validators umfasst.

• Datenformatkoordination:Heute wird der Ausführungsstatus im Merkle Patricia Tree gespeichert, der Konsensstaat wird im SSZ -Baum gespeichert und Blobs werden als KZG -Versprechen eingereicht.In Zukunft ist es sinnvoll, ein einzelnes einheitliches Format für Blockdaten und Status zu erstellen.Diese Formate decken alle wichtigen Bedürfnisse ab: (i) Einfacher Nachweis für staatenloser Clients, (ii) Serialisierung und Löschcodierung von Daten und (iii) standardisierte Datenstrukturen.

• Löschen von Beacon Chain Committee:Dieser Mechanismus wurde zunächst eingeführt, um bestimmte Versionen der Ausführungsscharfe zu unterstützen.Stattdessen schütteln wir durch L2 und Blob.Daher ist das Komitee unnötig und arbeitet daran, es zu entfernen.

• Löschen Sie gemischte Byte -Bestellung:EVM ist eine Big-Endian-Byte-Ordnung, und die Konsensschicht ist eine Byte-Byte-Ordnung.Es könnte sinnvoll sein, alles zu koordinieren und alles Big-Endian Endian (wahrscheinlich Big-Endian Endian zu machen, da EVM schwieriger ist, sich zu ändern).

Nun einige Beispiele in EVM:

• Vereinfachen Sie den Gasmechanismus:Die aktuellen Gasregeln waren noch nicht gut optimiert, und es ist unmöglich, die Anzahl der zur Überprüfung des Blocks erforderlichen Ressourcen explizit einzuschränken.Zu den wichtigsten Beispielen hier die EVM.Zu den empfohlenen Korrekturen gehören Änderungen des Staatlosen Gaskosten, die Einhaltung aller Speicherkosten in eine einfache Formel und Speicherpreisempfehlungen.

• Vorkompilierung entfernen:Viele der Vorkompilationen, die Ethereum heute hat, sind sowohl unnötig als auch relativ unbenutzt und machen einen großen Teil der Konsensfehlerrisiken aus, werden jedoch von keiner Anwendung verwendet.Zwei Möglichkeiten, um mit diesem Problem umzugehen, sind (i) die Vorkompilierung direkt entfernen und (ii) sie durch EVM -Code (und unweigerlich teurer) ersetzen, der dieselbe Logik implementiert.Dieser EIP -Entwurf empfiehlt, dies zuerst für die Identitätsvorkompilierung zu tun.

• Gasbeobachtbarkeit entfernen:Macht die EVM -Ausführung nicht mehr in der Lage, zu sehen, wie viel Gas es übrig ist.Dies bricht einige Anwendungen (am offensichtlichsten gesponserte Angebote) aus, kann jedoch in Zukunft leichter aktualisiert werden (z. B. für fortschrittlichere mehrdimensionale Gasversionen).Die EOF -Spezifikation hat das Gas nicht beobachtbar gemacht, aber um die Protokollvereinbarung zu erleichtern, muss EOF obligatorisch sein.

• Verbesserungen der statischen Analyse:Der heutige EVM -Code ist schwierig, eine statische Analyse durchzuführen, zumal Sprünge dynamisch sein können.Dies macht es auch schwieriger, eine optimierte EVM -Implementierung (Precompile EVM -Code in andere Sprachen) zu erstellen.Wir können dieses Problem lösen, indem wir dynamische Sprünge beseitigen (oder sie teurer machen, beispielsweise die Gaskosten hängen linear mit der Gesamtzahl der Sprungverträge im Vertrag zusammen).Dies ist, was EOF tut, aber die Vorteile der Protokollvereinfachung daraus zu erhalten, muss EOF obligatorisch machen.

Welche Forschung gibt es?

Nächste Schritte für die Säuberung:https://notes.ethereum.org/i_aihysjttcyau_adoy2ta

Selbstdestruktur:https://hackmd.io/@vbuterin/selfDestruct

SSZ-IFIFT-EIPS: [1] [2] [3]

Änderungen des Staatlosen Gaskosten:https://eips.ethereum.org/eips/eip-4762

Lineare Speicherpreise:https://notes.ethereum.org/ljptsqbgr2Knssu0yurwxw

Vorkompiliert und gelöscht:https://notes.ethereum.org/iwtx22ymqde1k_fz9psXig

Entfernen von Blütenfilter:https://eips.ethereum.org/eips/eip-7668

Eine Methode für das Abrufen des sicheren Protokolls außerhalb der Kette unter Verwendung inkrementeller überprüfbarer Berechnungen (lesen: rekursive Stark):https://notes.ethereum.org/xzuqy8znt3Keg1pkzpefxw

Was soll ich sonst noch tun und welche Kompromisse gibt es?

Der Hauptkompromiss für eine solche funktionale Vereinfachung ist (i) der Grad und die Geschwindigkeit unserer Vereinfachung mit (ii) Rückwärtskompatibilität.Der Wert von Ethereum als Kette ist, dass es sich um eine Plattform handelt, auf der Sie Anwendungen bereitstellen und sicherstellen können, dass sie nach vielen Jahren noch ordnungsgemäß funktioniert.Gleichzeitig ist es auch möglich, dieses Ideal in den Worten von William Jennings Brian zu weit zu bringen, „Nagel Ethereum am Kreuz von Rückwärtskompatibilität“.Wenn nur zwei Apps im gesamten Ethereum eine Funktion verwenden, von denen einer jahrelang keine Benutzer hat und der andere fast keine Nutzung hat und insgesamt 57 US -Dollar im Wert von 57 US Ihrer eigenen Tasche an das Opfer.

Das breitere soziale Problem besteht darin, eine standardisierte Pipeline für nicht drückende Rückwärtskompatibilität störende Änderungen zu erstellen.Eine Möglichkeit, dieses Problem zu lösen, besteht darin, vorhandene Präzedenzfälle wie den Self -Cestruct -Prozess zu überprüfen und zu erweitern.Die Pfeife sieht so aus:

• Schritt 1:Diskutieren Sie die Löschfunktion X.

• Schritt 2:Führen Sie eine Analyse durch, um zu bestimmen, wie destruktiv die Anwendung durch Löschen von x durchgeführt werden soll, (i) die Idee aufgeben, (ii) wie geplant vorgehen oder (iii) eine modifizierte „minimale destruktive“ Löschen von X -Methoden und -Löschen und -Methode und bestimmen weitermachen.

• Schritt 3:Erstellen Sie einen formalen EIP, um X zu verabreichen.Stellen Sie sicher, dass beliebte fortschrittliche Infrastrukturen (z. B. Programmiersprachen, Brieftaschen) dies respektieren und die Verwendung der Funktion einstellen.

• Schritt 4:Schließlich löschen Sie X.

Es sollte ein jahrelanger Prozess zwischen den Schritten 1 und 4 geben und deutlich angeben, welche Projekte in welchem ​​Schritt sind.Zu diesem Zeitpunkt besteht ein Kompromiss zwischen Stärke und Geschwindigkeit des Merkmalsentfernungsprozesses und der konservativeren und anderen Bereiche, in denen mehr Ressourcen in die Protokollentwicklung investiert werden, aber wir sind immer noch weit von der Spitze von Pareto entfernt.

Eof

Eine der für EVM vorgeschlagenen Hauptänderungen ist das EVM -Objektformat (EOF).EOF führt viele Änderungen ein, z. B. die Verbotsgasbeobachtbarkeit, die Beobachtbarkeit der Code (d. H. Keine Codekopie) und nur statische Sprünge zulassen.Ziel ist es, EVMs zu ermöglichen, mehr Upgrades durchzuführen, um leistungsfähigere Eigenschaften zu haben und gleichzeitig die Rückwärtskompatibilität aufrechtzuerhalten (da EVMs vor EOF noch existieren).

Der Vorteil davon ist, dass es einen natürlichen Weg schafft, um neue EVM -Funktionen hinzuzufügen und die Migration in strengere EVMs mit stärkeren Garantien zu fördern.Sein Nachteil ist, dass es die Komplexität des Protokolls erheblich erhöht, es sei denn, wir können Wege finden, um letztendlich alte EVMs zu zerlegen und zu löschen.Ein großes Problem ist:Welche Rolle spielt EOF bei EVM -Vereinfachungsvorschlägen, insbesondere wenn das Ziel darin besteht, die Komplexität des gesamten EVM zu verringern?

Wie interagiert es mit dem Rest der Roadmap?

Viele der Vorschläge für „Verbesserungen“ im Rest der Roadmap sind auch Möglichkeiten zur Vereinfachung der alten Merkmale.Wiederholen Sie einige Beispiele oben:

• Durch die Umstellung auf Single-Slot-Endgültigkeit die Möglichkeit, Ausschüsse zu stornieren, die Wirtschaft neu zu entwickeln und andere Vereinfachungen im Zusammenhang mit dem Nachweis des Anteils zu machen.

• Durch die vollständige Implementierung der Kontoabstraktion können wir viele vorhandene Transaktionsverarbeitungslogik löschen, indem wir sie in einen „Standardkonto EVM -Code“ verschieben, mit dem alle EOAs ersetzt werden können.

• Wenn wir den Ethereum -Zustand in den binären Hash -Baum verschieben, kann dies mit der neuen Version von SSZ koordiniert werden, damit alle Ethereum -Datenstrukturen auf die gleiche Weise gehasht werden können.

Ein radikalerer Ansatz: Umwandeln Sie den größten Teil des Protokolls in den Vertragscode

Eine radikalere Strategie zur Vereinfachung von Ethereum besteht darin, das Protokoll so zu halten, aber um einen Großteil des Protokolls von der Protokollfunktionalität in den Vertragscode zu verwandeln.

Die extremste Version besteht darin, Ethereum L1 „technisch“ nur Beacon-Ketten zu machen und ein minimales VM (wie RISC-V, Kairo oder einfachere VMs, die speziell verwendet werden, um das System zu beweisen), die es jemandem ermöglichen, sich eine Zusammenfassung zu erstellen.Dann wird das EVM der erste dieser Zusammenfassungen sein.Ironischerweise ist dies genau das gleiche Ergebnis wie der Vorschlag für Implementierungsumgebungen 2019-20, obwohl Snark es machbarer macht, tatsächlich umzusetzen.

Ein bescheidenerer Ansatz besteht darin, die Beziehung zwischen der Beacon-Kette und der aktuellen Ethereum-Ausführungsumgebung unverändert zu halten, aber EVMs eintauschen.Wir können RISC-V, Kairo oder andere VMs als neue „offizielle Ethereum vm“ wählen und dann alle EVM-Verträge in einen neuen VM-Code geben, der die ursprüngliche Codelogik interpretiert (durch Kompilierung oder Interpretation).Theoretisch ist es sogar möglich, dies mit der „Ziel -VM“ als EOF -Version zu tun.

Besonderer Dank geht an Justin Drake, Tim Beiko, Matt Garnett, Piper Merriam, Marius van der Wijden und Tomasz Stanczak für ihr Feedback und Kommentare.