EIP-2935: Ein Schritt zur zustandslosen Ausführung

Einführung

Was Blockchains beim Verarbeiten von Transaktionen speichern und darauf verweisen, wird als Zustand bezeichnet. Auf Ethereum ist der Zustand die Eigenschaft, die den Konsens der Knoten ermöglicht. Jeder Vollknoten muss diesen Zustand während jeder Periode gültiger Blöcke speichern und aktualisieren. Zustände, so wichtig sie auch für Blockchains sind, haben einen Nachteil: Sie wachsen mit der Zeit. Sie sind ein großes Problem in Blockchains wie Bitcoin und Ethereum, da die Zunahme der Größe mit einem gleichzeitigen Anstieg der Hardwareanforderungen für Knoten einhergeht. Die Speicherschwelle sorgt im Laufe der Zeit dafür, dass einige Knoten ausscheiden, was zu einer Zentralisierung führt.EIP-2935schlägt vor, die Zustandslosigkeit auf Ethereum zu bringen, um Knoten von der Last der Größe zu befreien. EIP-2935 ist ein Verbesserungsvorschlag, der versucht, die Zustandslosigkeit zu erreichen, indem die letzten 8192 Block-Hashes aus dem Zustand zur zustandslosen Ausführung in Ethereum gespeichert und bereitgestellt werden.

Kurzer Überblick über die aktuelle Struktur von Ethereum

Blöcke

Blöcke sind Chargen von Transaktionen mit einem Verweis (Hash) auf den vorherigen Block, der in die Kette aufgenommen ist. Hashes in jedem Block werden kryptografisch aus den Blockdaten selbst abgeleitet. Diese Einbeziehung verknüpft die Ketten miteinander mit Hashes, und die Batching impliziert, dass alle Teilnehmer im Netzwerk zustimmen und den Zustand gleichzeitig synchronisieren. Darüber hinaus signalisiert die Einigung über gebündelte Blöcke Ethereum, seinen globalen Zustand in jedem Teilnehmer im Netzwerk als Knoten zu aktualisieren.

Alt: Statusänderung in Ethereum

Sobald ein neuer Block von einem Validator im Netzwerk verarbeitet und übertragen wird, fügen die übrigen Teilnehmer ihn ihrem Speicher hinzu und aktualisieren ihren globalen Zustand. Der Validator jedes Blocks wird zufällig ausgewählt von Randomisierte Dezentralisierte Autonome Organisation (RANDAO)Der Blockaufbau ist streng geordnet, und die Blockerstellung und Konsensprozesse sind im Rahmen des Proof-of-Stake-Protokolls von Ethereum festgelegt.

Ein Block enthält mehrere Felder in seinem Header und Body. Zum Beispiel enthält der Blockheader Slot, Proposer_Index, Parent_Root, State_Root und Body-Felder. Der Blockkörper enthält Randao_Reveal, Eth1_Data, Graffiti, Proposer_Slashings, Attester_Slashings, Attestations, Einzahlungen, Freiwillige_Austritte, Sync_Aggregate und Execution_Payload. Jedes Feld hat unterschiedliche Parameter und erfüllt unterschiedliche Anforderungen.

Ethereums 12-SekundenDie Blockerstellungsperiode, auch "Slot" genannt, ergibt sich daraus, dass den Netzwerkteilnehmern genügend Zeit zur Synchronisierung mit neuen Blöcken und zur Einigung auf den Konsens eingeräumt wird. Während dieses Zeitraums:

1. Der Blockvorschlagende wählt zufällig einen Validator aus,
2. Der Validator bündelt die Transaktionen und führt sie aus, um einen neuen globalen Zustand zu bestimmen,
3. Sie inkludieren diese Informationen in einem neuen Block und verbreiten sie an den Rest des Validierungs-Sets über ein Gossip-Protokoll,
4. Andere Validatoren führen die Transaktionen erneut aus, um die Gültigkeit sicherzustellen und stimmen der globalen Zustandsänderung als Konsens zu.
5. Wenn der Validator den neuen Block als gültig überprüft, fügen sie ihn ihrem Speicher hinzu.

Eine Block- und Transaktionsendgültigkeit bedeutet, dass sie nicht ohne einen erheblichen ETH-Verbrauch in einem verteilten Netzwerk geändert werden kann. Ethereum verfolgt einen Ansatz mit "Checkpoint-Blöcken", um die Finalisierung zu verwalten. Der erste Block in jedem Zeitalter gilt als der Checkpoint dieses Slots. Validator:innen stimmen für diese Annahme, um sie zu einem gültigen Checkpunkt zu machen. Wenn zwei Drittel des gesamten gestakten ETH mit Validatorstimmen ein Paar von Checkpoints wählen, werden die Checkpoints aufgerüstet, um gerechtfertigt zu werden. Die zuvor gerechtfertigten Checkpoints werden nach der nächsten Checkpoints-Aufrüstung aufgerüstet und werden finalisiert. Wenn ein bösartiger Akteur einen finalisierten Block rückgängig machen möchte, muss er sich dazu verpflichten, mindestens ein Drittel des Gesamtangebots an gestaktem ETH zu verlieren. Obwohl ein Mechanismus namens Inaktivitätsleckexistiert, um Endgültigkeit wiederherzustellen, indem große Strafen für die Gelder der Validatoren verhängt und die Belohnungen für die Bezeuger im Falle eines dauerhaften Versagens einer großen Anzahl von Validatoren reduziert werden.

Beim Verarbeiten des Blocks wendet Ethereum eine Hashfunktion an, um die Daten der Blöcke zu nehmen und auf eindeutige Zeichenfolgen zu reduzieren. In der Hashfunktion erzeugt jede Eingabe eine eindeutige Ausgabe. Hashwerte in den Blöcken sind der einzige unveränderliche Teil. Es ist veränderbar mit einem Drittel der insgesamt eingesetzten ETH, die verbrannt werden. Diese Menge stammt jedoch von der Neuberechnung der Merkle-Baums Hashes bis zu einem Kontrollpunkt. Die Ausgabe des Hashvorgangs für jeden Block wird mit dem blockHash-Parameter zurückgegeben. Der blockHash-Parameter enthält alle Daten im Block.

Die Hashwerte der Blöcke und andere benötigte Parameter werden in Merkle-Bäumen gespeichert. Ethereum verwendet die Merkle-Trie-Architektur mit verschiedenen Versionen wie beispielsweise dem Merkle-Patricia-Trie.

Merkle und Merkle Patricia Tries

Trie-Strukturen, insbesondere Merkle-Tries, sind grundlegend für die Speicherung in der Blockchain. Ohne Merkle-Tries werden Blockchains zu einzelnen Blöcken, die jedes Mal schwer zu verarbeiten sind. Mit Merkle-Tries oder allgemein Trie-Architekturen erreichen Blockchains Vollständigkeit mit grundlegenden Shards. Dies ermöglicht ihnen, Netzwerkteilnehmer mit geringen Hardwareanforderungen zu werden.

Merkle-Tries sind eine strukturierte Methode, um große Mengen von Datenblöcken zu hashen und in Teile zu zerlegen. Mit der Merkelisierung wird die Daten in Paaren organisiert; jedes wird zusammen gehasht. Der Merkelisierungsprozess wiederholt sich, bis ein einzelner Merkle-Wurzel erhalten wird.

Ethereum bevorzugt Merkle-Patricia-Trie, eine duale Merkle-Trie-Struktur. Es verwendet binäre Trie für die grundlegende Datenverarbeitung, wie Transaktionsdaten, da dieser Ansatz für solche Situationen effizienter ist. Ethereum verwendet jedoch in komplexen Fällen wie der Zustandsverarbeitung die komplexeren Merkle-Patricia-Tries.

In einem Szenario zur Datenspeicherung im Zustandsbaum nutzt Ethereum eine Schlüssel-Wert-Zuordnung. Die Schlüssel repräsentieren Adressen und die Werte repräsentieren Kontodeklarationen. Zustandsbäume sind dynamischer als binäre Bäume. Daher können neue Konten häufig eingefügt und Schlüssel häufig eingefügt und gelöscht werden. Dieser Prozess erfordert eine schnell aktualisierbare Datenstruktur, die nicht erfordert, dass der gesamte Datensatz neu berechnet wird.

Die Wurzel des Trie hängt nur von den Daten ab, nicht von der Reihenfolge. Das Aktualisieren von Daten in verschiedenen Reihenfolgen ändert die Wurzel selbst nicht.

Alt: Binärer Merkle-Baum

Ethereum verwendet einen modifizierten Merkle-Patricia-Trie, der einige Funktionen von PATRICIA (Practical Algorithm to Retrieve Information Coded in Alphanumeric)und Merkle-Baum mit Modifikationen entlang davon. Diese Architektur ist deterministisch und kryptographisch überprüfbar. Der einzige Weg, um einen Zustandswurzel in dieser Struktur zu generieren, besteht darin, sie aus jedem einzelnen Zustückszustand zu berechnen. Zwei identische Zustände können leicht nachgewiesen werden, indem man den Wurzel-Hash und die Hashes vergleicht, die dazu geführt haben.

Letztendlich ist es unmöglich, den Zustand mit verschiedenen Werten zu ändern, da dies zu einem anderen Zustandshash führen würde. Alle Trie-Strukturen in der Ausführungsebene von Ethereum verwenden einen Merkle-Patricia-Trie. Das Netzwerk hat drei Tries: State Trie, Storage Trie und Transaction Trie. Darüber hinaus hat jeder Block seinen eigenen Receipts Trie. Obwohl Merkle-Patricia-Tries in vielerlei Hinsicht effizient sind, strebt Ethereum danach, sie durch Verkle-Tries zu ersetzen, um die Zustandslosigkeit zu erreichen.

Alt: Merkle Patricia Trie

Gas

Gas ist die für die Ausführung in der EVM benötigte Ressource. Da die EVM rechnerische Ressourcen zur Ausführung benötigt, wird die Rückkehr dieser Bemühungen mit Gas bezahlt, um die Sicherheit der EVM zu gewährleisten. Die Gasgebühr wird als die erforderliche Menge an Gas multipliziert mit den Kosten pro Einheit berechnet. Es handelt sich um einen dynamischen Wert und hängt von der Art der Operation ab.

Alt: https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf

EIP-1559Einführung einiger wesentlicher Änderungen am Transaktionsgebührenmechanismus. Das Bezahlen von Gas, um Transaktionen in den Blöcken zu erfassen, erfolgte in der Vergangenheit mit einer Auktionsmethode. Mit EIP-1559 gibt es eine Mindestgrenze namens Grundgebühr und ein Trinkgeld namens Prioritätsgebühr. Blöcke sollen von der Transaktion mit der höchsten Prioritätsgebühr ausgehen. Nach dem Blockprozess wird die Grundgebühr verbrannt und die Prioritätsgebühr wird verwendet, um die Validatoren zu incentivieren.

Zustand

Der Blockchain-Zustand kann als eine Reihe von Daten (oder Variablen) definiert werden, die ein bestimmtes System zu einem bestimmten Zeitpunkt beschreiben. Das Internet hat von Anfang an fast einen Zustand, aber er wurde auf einem einzigen Server gespeichert. Mit Web3 wurde ein globaler Zustand eingeführt, der auf einem offenen und verteilten Netzwerk gesichert ist. Jeder kann jederzeit den Zustand des verteilten Netzwerks einsehen und überprüfen.

Ethereum umfasst Konten, Guthaben, bereitgestellte Smart Contracts und zugehörigen Speicher im globalen Zustand. Der Zustand von Ethereum wächst mit den Ergänzungen und Änderungen dieser Parameter. Das Zustandswachstum wird problematisch, wenn die Hardwarekosten für das Hosting eines vollständigen Knotens prohibitiv werden. Angesichts dieser Herausforderungen, Vitalik Buterin eingeführtDas Konzept des zustandslosen Ethereum im Jahr 2017. Die vorgeschlagenen Methoden zur Behebung des Zustandswachstums in Ethereum umfassen Daten- und Zustandsablauf.

Unterschiede zwischen Datenablauf und Zustandsablauf

Datenablauf

Daten- oder Verlaufsauslauf bedeutet, dass nach Ablauf einer bestimmten Zeit überflüssige Daten von Clients entfernt werden. Mit den "schwachen Subjektivitätskontrollpunkten" könnten Clients ihren Weg finden, indem sie vom Ursprung aus synchronisieren und historische Abfalldaten entfernen.

Subjektivität bezieht sich auf die Knoten eines Netzwerks, die sich auf soziale Informationen verlassen, um zu einem Konsens über den aktuellen Zustand zu gelangen. In diesem Sinne bezieht sich schwache Subjektivität auf eine Kette, die objektiv voranschreiten kann, wenn einige anfängliche Informationen sozial abgerufen wurden. Schwache Subjektivitäts-Überprüfungspunkte bedeuten jedoch, dass alle Knoten im Netzwerk, die für den Konsens verantwortlich sind, in der kanonischen Kette enthalten sind. Schwache Subjektivitäts-Überprüfungspunkte helfen Ethereum PoS, den aktuellen Zustand (schwacher Subjektivitäts-Überprüfungspunkt) von einer vertrauenswürdigen Quelle zu haben, um sich zu synchronisieren.

EIP-4444bietet den praktischen Weg zu @hBXHLw_9Qq2va4pRtI4bIA/ryzBaf7fJx?ref=ghost-2077.arvensis.systems">achieve data expiry through weak-subjectivity. Der Vorschlag zielt nicht darauf ab, wie Ethereum-Knoten den Statusdaten umgehen; vielmehr modifiziert er den Zugriff auf historische Daten.

Ablaufdatum

Der Statusablauf zielt darauf ab, den Status von einzelnen Knoten zu eliminieren, wenn er nicht kürzlich abgerufen wurde. Ablauf kann durch Beendigung aufgrund von Miete oder Zeit implementiert werden. Ablauf durch Miete bedeutet, dass eine Gebühr für Konten erhoben wird, die den Status speichern. Andererseits bedeutet Ablauf durch Zeit, dass Konten inaktiv werden, wenn sie für einen bestimmten Zeitraum inaktiv bleiben.

Sowohl Daten als auch Zustandsablauf sind offene Forschungsbereiche. Aktuelle Ansätze, um diese vorgeschlagenen Status zu erreichen, beinhalten das Durchleiten durch zentralisierte Netzwerke/Anbieter. Bisher wurde eine schwache Zustandslosigkeit und Zustandsablauf teilweise in Ethereum erreicht.

Stateless Ethereum

Einführung in die Zustandslosigkeit und den zustandslosen Ethereum

Das Stateless Ethereum führt neue Konzepte in das Kernprotokoll ein. Idealerweise bedeutet Zustandslosigkeit nicht, dass kein Zustand existiert. Vielmehr können Clients den Zustand wählen, den sie beibehalten möchten. Wenn Clients validierte Blöcke erhalten, erhalten sie auch den entsprechenden Zeugen für diesen Block. Zeugen für jeden Block bestehen aus allen Daten, die zur Ausführung der in diesem Block enthaltenen Transaktionen erforderlich sind.

EIP-161führte den ersten zustandsreduzierenden Ansatz ein. Ethereum wurde Opfer eines DoS (Denial of Service)-Angriffs, und diese Schwachstelle ermöglichte es, leere Konten zu erstellen, die den globalen Zustand von Ethereum erhöhten. EIP-161 schlug vor, leere Konten mit einem Wert von null (0) an ihrem nonce zu entfernen, die aus diesem Angriff stammten, mit geringen Kosten. Der Vorschlag wurde umgesetzt, was zu einer Zustandsrücknahme führte.

Ein weiterer Versuch, die Staatenlosigkeit zu erreichen, wurde vorgeschlagen durch EIP-4788. Dieser Vorschlag zielte darauf ab, die Wurzeln der Beacon-Chain-Blöcke im EVM aufzudecken. Ähnlich dem Ansatz des Eth1-Eth2-BrückeDurch die Verbindung der Beacon-Kette (Konsensschicht) und der Ausführungsschicht ermöglicht dieser Vorschlag einen vertrauensminimierten Zugang zwischen EVM und der Konsensschicht.

Da jeder Ausführungsblock die Wurzel des übergeordneten Beacon-Blocks enthält, müssten verpasste Slot-Ereignisse nicht die vorherige Blockwurzel ändern. Daher reduzieren sich die Voraussetzungen für die Ausführung darauf, einen kleinen Platz für ein vertrauensminimiertes Orakel in jedem Ausführungsblock zu reservieren. Der Vorschlag schlägt vor, eine kleine Historie der Blockwurzeln in einem Root-Vertrag zu speichern, um die Effizienz des Orakels zu verbessern.

In Ethereum ist Staatenlosigkeit entweder als schwache oder starke Staatenlosigkeit möglich.

Schwache Staatenlosigkeit

Schwacher Zustandslosigkeit ist ein Zustand, der den Bedarf an Zustandsspeicherung in allen Knoten nicht beseitigt. Stattdessen unterscheidet es sich darin, wie Knoten die Änderungen am Ethereum-Zustand überprüfen. Es legt die Verantwortung für die Zustandsspeicherung bei den Blockvorschlägern und erfordert von anderen Knoten, die Blöcke zu überprüfen, ohne die vollständigen Zustandsdaten zu speichern.

Block-Proposers müssen vollständige Statusdaten speichern. Verifizierende Clients müssen jedoch keine Statusdaten im Netzwerk speichern. Stattdessen können sie den Zustandswurzel (einen Hash des gesamten Zustands) speichern. Schwache Zustandslosigkeit erfordert Trennung von Antragsteller und Bauherr (PBS)undVerkle versuchtImplementierung.

Vorschlagende erstellen Zeugen unter Verwendung der Zustandsdaten, um die Zustandsänderungen nachzuweisen, und Validatoren überprüfen die Beweise gegen den Zustands-Root-Hash.

Starke Zustandslosigkeit

Der starke Zustandslosigkeit beseitigt die Notwendigkeit, dass ein Knoten die Zustandsdaten speichert. Es funktioniert, indem gesendete Transaktionen und von Blockvorschlägern aggregierte Zeugen eingebunden werden. Blockvorschläger speichern nur den Zustand, an dem sie arbeiten, und erstellen Zeugen für relevante Konten. Der Vorschlag benötigt noch weitere Entwicklung und umfasst Anforderungen wie Zugriffslistenoder EIP-2930.

Allerdings können einige Änderungen und Eigenschaften genutzt werden, um Zustandslosigkeit zu erreichen. EIP-2935 schlägt vor, historische Block-Hashes aus dem Zustand zu liefern, um zustandslose Ausführung zu ermöglichen.

Einführung in EIP-2935

EIP-2935 zielt darauf ab, historische Block-Hashes im Zustand der Blockchain in speziellen Speicherslots namens HISTORY_STORAGE_ADDRESS zu speichern. Dieser Prozess ermöglicht eine zustandslose Ausführung, indem der einfache Zugriff auf die erforderlichen historischen Informationen in zustandslosen Clients erleichtert wird.

EIP-2935 schlägt vor, die letzten 8192 historischen Block-Hashes in einem Systemvertrag zu speichern, um sie als Teil der Blockverarbeitungslogik zu verwenden. Das Problem, das mit diesem Vorschlag gelöst werden soll, ist die Annahme der EVM, dass der Client den aktuellen Blockhash hat. Dieser Annahme-basierte Ansatz gilt nicht für zukünftige Ethereum und insbesondere für zustandslose Clients.

Das Einbeziehen der vorherigen Blockhashes in den Zustand ermöglicht es, diese Hashes mit Hashfunktionen im Blickfeld eines Zeugen zu bündeln. Ein Zeuge wird später dem zustandslosen Client zur Verfügung gestellt, um die Ausführung zu überprüfen und eine zustandslose Ausführung zu erreichen. Dieser Vorschlag wird als Vor-Verkle-Speziation bezeichnet, weil er implementiert werden kann, bevor die Anpassung an Verkle-Tries im Kernprotokoll erfolgt, und er die teilweise Zustandslosigkeit erleichtert.

Die Erweiterung des Bereichs von Blöcken, die von blockHash bedient werden, auf 8192 Blöcke ermöglicht einen sanften Übergang zu Ausführungsmethoden. Rollups können von diesem längeren Verlaufsfenster profitieren, indem sie direkt dieses Vertrags abfragen, da die blockHash-Daten in diesem Vertrag gespeichert sind. Darüber hinaus wird dieses EIP die Validierung von Beweisen im Zusammenhang mit der 8192-Blockmenge des HISTORY_SERVE_WINDOW gegen den aktuellen Zustand erleichtern.

Verständnis EIP-2935

EIP-2935 ermöglicht es Ethereum-Clients, insbesondere zustandslose Clients, einfach auf aktuelle Block-Hashes zuzugreifen. Um dies zu ermöglichen, führt es vier neue Parameter ein:

• BLOCKHASH_SERVE_WINDOW: Informiert die Clients darüber, wie viele vergangene Blockhashes sie behalten sollten. Der Standardwert beträgt 256.
• HISTORY_SERVE_WINDOW: Dieser Parameter definiert, wie viele Blockhashes gespeichert sind. Der Standardwert beträgt 8191.
• SYSTEM_ADDRESS: Eine spezielle Adresse (ursprünglich in EIP-4788 eingeführt), die als "Aufrufer" zum Schreiben von Block-Hashes in den Speicher fungiert.
• HISTORY_STORAGE_ADDRESS: Die Vertragsadresse, an der diese Block-Hashes gespeichert sind.

Die Spezifikationen des Vorschlags geben an, dass die letzten HISTORY_SERVE_WINDOW Block-Hashes in einem Ringpuffer-Speicher mit einer Länge von HISTORY_SERVE_WINDOW gespeichert werden sollen.

Ringpuffer

EIP-2935 verwendet eine zusätzliche Funktion namens Ringpuffer zur temporären Speicherung. Ein Ringpuffer ist eine Eigenschaft, die es einem Netzwerk ermöglicht, denselben Speicher für verschiedene Daten wiederzuverwenden. Der Speicher im Ringpuffer ist jedes Mal auf denselben Speicherort begrenzt. Der Ringpuffer auf EIP-2935 wird nur verwendet, um das erforderliche HISTORY_SERVE_WINDOW zu bedienen, da EIP-4788 und Beacon-State-Akkumulatoren einen Nachweis gegenüber jedem Vorfahren ermöglichen.

Regeln und Spezifikationen für die Fork-Auswahl

Nach der Gabelung, wenn das Netzwerk mit diesen EIP-Überlegungen startet, wird der HISTORY_STORAGE_ADDRESS-Parameter als SYSTEM_ADDRESS mit block.parent.hash-Eingabe (Standard 32 Byte), einem Gaslimit von 30.000.000 und einem Wert von 0 bezeichnet. Dieser Prozess wird die set()-Funktion des Historienvertrags auslösen.

Der Post-Vorschlag-Gabelprozess unterscheidet sich vom regulären Gabelprozess. Diese set() Operation ist eine allgemeine Systemoperation, aber der Aufruf folgt diesen Konventionen:

• Muss vollständig ausgeführt werden
• Zählt nicht gegen das Gaslimit des Blocks
• Folgt nicht dem EIP-1559-Verbrennungsmechanismus
• Wenn kein Code unter HISTORY_STORAGE_ADDRESS existiert, muss der Aufruf ohne schwerwiegende Fehler fehlschlagen.

Dieser Prozess muss den Blockzeitraum HISTORY_SERVE_WINDOW ausfüllen, um den Ringpufferauslösezeitraum zu erreichen. Der Verlaufskontrakt enthält nur den Elternhash des Gabelblocks, der als Referenzhash und neuer Hash-Startpunkt dient.

Ein Block-Hash-Verlaufvertrag wird zwei Operationen haben: get() und set(). Die set()-Operation wird aktiviert, wenn der Aufrufer des Vertrags in einer Transaktion gleich der SYSTEM_ADDRESS ist, die mit EIP-4788 eingeführt wurde. Wenn der Aufrufer und die SYSTEM_ADDRESS nicht gleich sind oder die Bedingungen nicht erfüllen, wird die get()-Operation aktiviert.

Die get()-Operation wird in der EVM verwendet, um Block-Hashes zu lokalisieren. Sie ermöglicht es Anrufern, die Blocknummer anzugeben, die sie abfragen, wenn der calldata-Eingang nicht 32 Bytes beträgt (was bedeutet, dass es ein gültiger block.parent.hash ist) und wenn die Anfrage außerhalb des Bereichs liegt ([block.number-HISTORY_SERVE_WINDOW, block.number-1]), wird die Transaktion zurückgesetzt.

set() nimmt input block.parent.hash als calldata, wenn ein Aufrufer den Vertrag mit einer Transaktion aufruft. Es setzt auch den Speicherwert als calldata[0:32] am block.number-1 % HISTORY_SERVE_WINDOW.

HISTORY_STORAGE_ADDRESS wird über EIP-4788 implementiert, das oben als die Möglichkeit bezeichnet wird, Block-Hashes direkt über die Konsensschicht am EVM abzurufen. HISTORY_STORAGE_ADDRESS wird den Nonce-Wert als 1 haben und von EIP-161's Null-Nonce-Bereinigungsstandard befreit sein.

BLOCKHASH Übergangslogik

Eine Sorge bezüglich dieses EIP ist, wie man die BLOCKHASH-Auflösungslogik nach der Gabelung am besten überführt. Zwei Hauptansätze werden in Betracht gezogen:

• Warten Sie auf HISTORY_SERVE_WINDOW Blöcke, damit die gesamte relevante Geschichte bestehen bleibt,
• Speichern Sie alle letzten HISTORY_SERVE_WINDOW Block-Hashes auf dem Fork-Block.

Entwickler wählen die erste Option. Es ist praktischer, weil es keine vorübergehenden Änderungen erfordert.

Was ist der Unterschied zwischen EIP-2935 und ähnlichen EIPs?

Ähnliche EIPs wurden zuvor vorgeschlagen, um einen zustandslosen Ablauf zu ermöglichen und zu erreichen. EIP-2935 unterscheidet sich von diesen früheren Vorschlägen, weil es sich auf die unten hervorgehobenen Komplexitäten konzentriert.

• Ansatz der Trie-Struktur: EIP-2935 verwendet keine Trie-ähnliche Struktur mit mehreren Ebenen und entscheidet sich stattdessen für eine einzige Liste. Im Gegensatz dazu schlug EIP-4444 vor, historische Daten in Ausführungsclients, die älter als ein Jahr sind, zu beschneiden. Andere EIPs mit ähnlichen Ambitionen haben Verkle-Tries als Anforderungen.
• Das Schreiben des EIP im EVM-Code: EIP-2935 erfordert keine Änderung im EVM.
• Serielles ungebundenes Speichern von Hashes: Das serielles ungebundene Hash-Speichern ist ineffizient. Dieses EIP überwindet dieses Problem, indem es die Hashes bündelt.

Sicherheitsüberlegungen

Da EIP-2935 intelligente Verträge verwendet, besteht das Risiko von Branch-Poisoning-Angriffen. Die Größe des Zustandsroots macht jedoch jeden Update-Versuch langsam und einen Poisoning-Angriff erheblich teurer.

Was könnte es bringen?

• Vertrauenslose Orakelsysteme schneller machen: Bei Uniswap v2-basierten Orakeln kann jeder mit Zugriff auf einen Ethereum-Knoten einen Nachweis über den Speicher von Uniswap generieren und zur Validierung auf der Blockchain einreichen. Der Durchschnittspreis wird zwischen dem aktuellen Block und dem Block des bereitgestellten Nachweises bestimmt, wobei der validierte Nachweis bis zu 256 Blöcke umfasst, da der blockhash bis zu 256 Blöcke unterstützt. Durch die Nutzung von EIP-2935 kann dieser Prozess verbessert werden, indem der Zugriff auf ältere Blockhashes ermöglicht wird, was bedeutet, dass Nachweise über einen längeren Zeitraum validiert werden können.
• Es wird Verträgen ermöglicht, vergangene Zustandsbehauptungen zu berücksichtigen, ohne Vertrauen: Die Verbesserung EIP-2935 schafft die Möglichkeit, blockchain-Daten innerhalb des EVM vertrauenslos zu betrachten. Ein Client kann die Historie abfragen, den Hash-Wert erhalten und mit anderen Knoten verifizieren. Die Lösung könnte leichte Clients effizient und einfach umsetzbar machen.
• Brückenbildung zwischen L1 <> L2: Um eine Nachricht von L2 zu überprüfen, muss L1 über L2-Zustellungsverweise und Block-Hashes Bescheid wissen. Allerdings kann L1 in seinem aktuellen Zustand keine beliebigen Block-Hashes abrufen aufgrund von Gaskontingenten und architektonischen Einschränkungen. EIP-2935 ermöglicht es L1, die beliebigen historischen Daten mit der Fähigkeit zur Prüfung von Einbeziehungsbelegen für alte Ereignisse zu überprüfen. Der Zugriff und die Verifizierungsleistung werden verbessert, und die Brückenleistung wird erhöht.

Fazit

EIP-2935 stellt einen entscheidenden Schritt zur Erreichung des langfristigen Ziels von Stateless Ethereum dar. Die Speicherung der letzten 8192 Block-Hashes in einem dedizierten Vertrag innerhalb der Statusadressen behebt eine grundlegende Einschränkung im aktuellen Design. Ethereums Annahme, dass Clients grundsätzlich Zugriff auf aktuelle Block-Hashes haben. Im Kontext der stateless Ausführung, in der Clients den vollständigen Status nicht mehr pflegen, wird diese Annahme veraltet. EIP-2935 löst dies, indem es einen leichten, effizienten und nicht intrusiven Mechanismus einführt, der es Stateless-Clients ermöglicht, auf notwendige historische Daten zuzugreifen, ohne den EVM zu ändern oder auf komplexe Datenstrukturen wie Verkle-Tries angewiesen zu sein.

Über die staatenlose Ausführung hinaus erschließt dieser Vorschlag weitreichende Vorteile im gesamten Ethereum-Ökosystem. Er verbessert die Fähigkeiten von vertrauenslosen Orakeln, erweitert die Nutzbarkeit von Leichtclients und stärkt die Interoperabilität zwischen Layer 1- und Layer 2-Lösungen, indem eine zuverlässige Überprüfung älterer Zustandsdaten ermöglicht wird. Seine Implementierung basiert auf einem sauberen und gaseffizienten Design, das Ringpufferspeicher und systemweite Verträge verwendet, die ein Festcodieren in die EVM überflüssig machen und sowohl Einfachheit als auch Skalierbarkeit bieten.

Während Ethereum weiterhin seine Entwicklung in Richtung größerer Dezentralisierung, Skalierbarkeit und Zugänglichkeit vorantreibt, dient EIP-2935 als grundlegende Verbesserung. Es überbrückt die Kluft zwischen der aktuellen zustandsbehafteten Architektur und der angestrebten zustandslosen Zukunft und legt den Grundstein für eine robustere, effizientere und zugriffsfreiere Infrastruktur im gesamten Blockchain-Ökosystem.

Haftungsausschluss:

1. Dieser Artikel wurde aus [ wiederveröffentlicht2077forschung]. Alle Urheberrechte gehören dem Originalautor [ Yiğit Yektin]. Wenn es Einwände gegen diesen Nachdruck gibt, kontaktieren Sie bitte die Gate LearnTeam, und sie werden es umgehend 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 den Artikel in andere Sprachen. Das Kopieren, Verteilen oder Plagiieren der übersetzten Artikel ist untersagt, es sei denn, es wird erwähnt.