Zum Hauptinhalt springen

Zustandslosigkeit, Zustandsablauf und Historienverfall

Die Fähigkeit, Ethereum-Knoten auf bescheidener Hardware auszuführen, ist entscheidend für echte Dezentralisierung. Das liegt daran, dass der Betrieb eines Knotens den Benutzern die Möglichkeit gibt, Informationen durch unabhängige kryptographische Prüfungen zu verifizieren, anstatt darauf zu vertrauen, dass eine dritte Partei ihnen Daten liefert. Der Betrieb eines Knotens ermöglicht es Benutzern, Transaktionen direkt an das Peer-to-Peer-Netzwerk von Ethereum zu senden, anstatt einem Vermittler vertrauen zu müssen. Dezentralisierung ist nicht möglich, wenn diese Vorteile nur Benutzern mit teurer Hardware zur Verfügung stehen. Stattdessen sollten Knoten mit extrem geringen Anforderungen an Rechenleistung und Speicher laufen können, sodass sie auf Mobiltelefonen, Mikrocomputern oder unbemerkt auf einem Heimcomputer ausgeführt werden können.

Heute sind hohe Speicherplatzanforderungen das Haupthindernis, das einen universellen Zugang zu Knoten verhindert. Dies liegt in erster Linie an der Notwendigkeit, große Teile der Zustandsdaten von Ethereum zu speichern. Diese Zustandsdaten enthalten kritische Informationen, die erforderlich sind, um neue Blöcke und Transaktionen korrekt zu verarbeiten. Zum Zeitpunkt des Schreibens wird eine schnelle 2-TB-SSD für den Betrieb eines vollständigen Ethereum-Knotens empfohlen. Für einen Knoten, der keine älteren Daten bereinigt, wächst der Speicherbedarf um etwa 14 GB/Woche, und Archivknoten, die alle Daten seit dem Genesis-Block speichern, nähern sich 12 TB (zum Zeitpunkt des Schreibens im Februar 2023).

Günstigere Festplatten können verwendet werden, um ältere Daten zu speichern, aber diese sind zu langsam, um mit eingehenden Blöcken Schritt zu halten. Die Beibehaltung der aktuellen Speichermodelle für Clients, während Daten billiger und einfacher zu speichern gemacht werden, ist nur eine vorübergehende und teilweise Lösung für das Problem, da das Zustandswachstum von Ethereum 'unbegrenzt' ist, was bedeutet, dass die Speicheranforderungen immer nur steigen können und technologische Verbesserungen immer mit dem kontinuierlichen Zustandswachstum Schritt halten müssen. Stattdessen müssen Clients neue Wege finden, um Blöcke und Transaktionen zu verifizieren, die nicht darauf angewiesen sind, Daten in lokalen Datenbanken nachzuschlagen.

Reduzierung des Speicherplatzes für Knoten

Es gibt mehrere Möglichkeiten, die Datenmenge zu reduzieren, die jeder Knoten speichern muss, wobei jede eine Aktualisierung des Kernprotokolls von Ethereum in unterschiedlichem Ausmaß erfordert:

  • Historienverfall: Ermöglicht es Knoten, Zustandsdaten zu verwerfen, die älter als X Blöcke sind, ändert aber nicht, wie Ethereum-Clients mit Zustandsdaten umgehen.
  • Zustandsablauf: Ermöglicht es, dass Zustandsdaten, die nicht häufig verwendet werden, inaktiv werden. Inaktive Daten können von Clients ignoriert werden, bis sie wiederhergestellt werden.
  • Schwache Zustandslosigkeit: Nur Blockproduzenten benötigen Zugriff auf vollständige Zustandsdaten, andere Knoten können Blöcke ohne eine lokale Zustandsdatenbank verifizieren.
  • Starke Zustandslosigkeit: Keine Knoten benötigen Zugriff auf die vollständigen Zustandsdaten.

Datenablauf

Historienverfall

Historienverfall bezieht sich darauf, dass Clients ältere Daten bereinigen, die sie wahrscheinlich nicht benötigen, sodass sie nur eine kleine Menge historischer Daten speichern und ältere Daten verwerfen, wenn neue Daten eintreffen. Es gibt zwei Gründe, warum Clients historische Daten benötigen: Synchronisierung und die Beantwortung von Datenanfragen. Ursprünglich mussten Clients vom Genesis-Block an synchronisieren und überprüfen, ob jeder nachfolgende Block bis zur Spitze der Chain korrekt ist. Heute verwenden Clients „Checkpoints für schwache Subjektivität“, um sich den Weg zur Spitze der Chain zu bahnen. Diese Checkpoints sind vertrauenswürdige Startpunkte, als hätte man einen Genesis-Block nahe der Gegenwart anstatt ganz am Anfang von Ethereum. Das bedeutet, dass Clients alle Informationen vor dem jüngsten Checkpoint für schwache Subjektivität verwerfen können, ohne die Fähigkeit zur Synchronisierung mit der Spitze der Chain zu verlieren. Clients bedienen derzeit Anfragen (die über JSON-RPC eintreffen) nach historischen Daten, indem sie diese aus ihren lokalen Datenbanken abrufen. Mit dem Historienverfall wird dies jedoch nicht möglich sein, wenn die angeforderten Daten bereinigt wurden. Für die Bereitstellung dieser historischen Daten sind einige innovative Lösungen erforderlich.

Eine Möglichkeit ist, dass Clients historische Daten von Peers über eine Lösung wie das Portal-Netzwerk anfordern. Das Portal-Netzwerk ist ein in der Entwicklung befindliches Peer-to-Peer-Netzwerk zur Bereitstellung historischer Daten, bei dem jeder Knoten einen kleinen Teil der Geschichte von Ethereum speichert, sodass die gesamte Geschichte verteilt über das Netzwerk existiert. Anfragen werden bedient, indem Peers gesucht werden, die die relevanten Daten speichern, und diese von ihnen angefordert werden. Da es in der Regel Apps sind, die Zugriff auf historische Daten benötigen, kann es alternativ zu ihrer Verantwortung werden, diese zu speichern. Es könnte auch genügend altruistische Akteure im Ethereum-Raum geben, die bereit wären, historische Archive zu pflegen. Es könnte eine DAO sein, die gegründet wird, um die Speicherung historischer Daten zu verwalten, oder idealerweise wird es eine Kombination all dieser Optionen sein. Diese Anbieter könnten die Daten auf viele Arten bereitstellen, z. B. über einen Torrent, FTP, Filecoin oder IPFS.

Der Historienverfall ist etwas umstritten, da Ethereum bisher immer implizit die Verfügbarkeit jeglicher historischer Daten garantiert hat. Eine vollständige Synchronisierung ab dem Genesis-Block war standardmäßig immer möglich, auch wenn sie darauf angewiesen ist, einige ältere Daten aus Snapshots wiederherzustellen. Der Historienverfall verlagert die Verantwortung für die Bereitstellung dieser Garantie aus dem Ethereum-Kernprotokoll heraus. Dies könnte neue Zensurrisiken mit sich bringen, wenn letztendlich zentralisierte Organisationen einspringen, um historische Daten bereitzustellen.

EIP-4444 ist noch nicht bereit für die Veröffentlichung, wird aber aktiv diskutiert. Interessanterweise sind die Herausforderungen bei EIP-4444 weniger technischer Natur, sondern betreffen hauptsächlich das Community-Management. Damit dies veröffentlicht werden kann, bedarf es der Zustimmung der Community, die nicht nur eine Einigung, sondern auch Verpflichtungen zur Speicherung und Bereitstellung historischer Daten durch vertrauenswürdige Entitäten umfasst.

Dieses Upgrade ändert nicht grundlegend, wie Ethereum-Knoten mit Zustandsdaten umgehen, es ändert nur, wie auf historische Daten zugegriffen wird.

Zustandsablauf

Zustandsablauf bezieht sich auf das Entfernen des Zustands von einzelnen Knoten, wenn in letzter Zeit nicht darauf zugegriffen wurde. Es gibt mehrere Möglichkeiten, wie dies implementiert werden könnte, darunter:

  • Ablauf durch Miete: Erhebung einer „Miete“ für Konten und deren Ablauf, wenn ihre Miete null erreicht
  • Ablauf durch Zeit: Inaktivierung von Konten, wenn für eine bestimmte Zeit keine Lese-/Schreibvorgänge auf diesem Konto stattfinden

Der Ablauf durch Miete könnte eine direkte Miete sein, die Konten in Rechnung gestellt wird, um sie in der aktiven Zustandsdatenbank zu halten. Der Ablauf durch Zeit könnte durch einen Countdown ab der letzten Kontointeraktion erfolgen, oder es könnte ein periodischer Ablauf aller Konten sein. Es könnte auch Mechanismen geben, die Elemente sowohl des zeit- als auch des mietbasierten Modells kombinieren, zum Beispiel bleiben einzelne Konten im aktiven Zustand, wenn sie vor dem zeitbasierten Ablauf eine kleine Gebühr zahlen. Beim Zustandsablauf ist es wichtig zu beachten, dass der inaktive Zustand nicht gelöscht wird, sondern lediglich getrennt vom aktiven Zustand gespeichert wird. Der inaktive Zustand kann wieder in den aktiven Zustand überführt werden.

Die Art und Weise, wie dies funktionieren würde, besteht wahrscheinlich darin, einen Zustandsbaum für bestimmte Zeiträume (vielleicht ~1 Jahr) zu haben. Wann immer eine neue Periode beginnt, beginnt auch ein völlig neuer Zustandsbaum. Nur der aktuelle Zustandsbaum kann geändert werden, alle anderen sind unveränderlich. Von Ethereum-Knoten wird nur erwartet, dass sie den aktuellen Zustandsbaum und den nächstjüngeren halten. Dies erfordert eine Möglichkeit, eine Adresse mit der Periode, in der sie existiert, mit einem Zeitstempel zu versehen. Es gibt mehrere mögliche Wege (opens in a new tab), dies zu tun, aber die führende Option erfordert, dass Adressen verlängert werden (opens in a new tab), um die zusätzlichen Informationen aufzunehmen, mit dem zusätzlichen Vorteil, dass längere Adressen viel sicherer sind. Der Roadmap-Punkt, der dies umsetzt, wird Adressraumerweiterung (opens in a new tab) genannt.

Ähnlich wie beim Historienverfall wird beim Zustandsablauf die Verantwortung für die Speicherung alter Zustandsdaten von einzelnen Benutzern genommen und auf andere Entitäten wie zentralisierte Anbieter, altruistische Community-Mitglieder oder futuristischere dezentrale Lösungen wie das Portal-Netzwerk verlagert.

Der Zustandsablauf befindet sich noch in der Forschungsphase und ist noch nicht bereit für die Veröffentlichung. Der Zustandsablauf könnte durchaus später erfolgen als zustandslose Clients und der Historienverfall, da diese Upgrades große Zustandsgrößen für die Mehrheit der Validatoren leicht handhabbar machen.

Zustandslosigkeit

Zustandslosigkeit ist ein wenig irreführend, da es nicht bedeutet, dass das Konzept des „Zustands“ eliminiert wird, aber es beinhaltet Änderungen daran, wie Ethereum-Knoten mit Zustandsdaten umgehen. Zustandslosigkeit selbst gibt es in zwei Varianten: schwache Zustandslosigkeit und starke Zustandslosigkeit. Schwache Zustandslosigkeit ermöglicht es den meisten Knoten, zustandslos zu werden, indem die Verantwortung für die Zustandsspeicherung auf einige wenige übertragen wird. Starke Zustandslosigkeit beseitigt vollständig die Notwendigkeit für jeden Knoten, die vollständigen Zustandsdaten zu speichern. Sowohl schwache als auch starke Zustandslosigkeit bieten normalen Validatoren die folgenden Vorteile:

  • nahezu sofortige Synchronisierung
  • Fähigkeit, Blöcke in beliebiger Reihenfolge (out-of-order) zu validieren
  • Knoten können mit sehr geringen Hardwareanforderungen ausgeführt werden (z. B. auf Telefonen)
  • Knoten können auf billigen Festplatten laufen, da keine Lese-/Schreibvorgänge auf der Festplatte erforderlich sind
  • kompatibel mit zukünftigen Upgrades der Kryptographie von Ethereum

Schwache Zustandslosigkeit

Schwache Zustandslosigkeit beinhaltet zwar Änderungen an der Art und Weise, wie Ethereum-Knoten Zustandsänderungen verifizieren, beseitigt jedoch nicht vollständig die Notwendigkeit der Zustandsspeicherung in allen Knoten im Netzwerk. Stattdessen überträgt die schwache Zustandslosigkeit die Verantwortung für die Zustandsspeicherung auf Block-Proposer, während alle anderen Knoten im Netzwerk Blöcke verifizieren, ohne die vollständigen Zustandsdaten zu speichern.

Bei schwacher Zustandslosigkeit erfordert das Vorschlagen von Blöcken Zugriff auf vollständige Zustandsdaten, aber das Verifizieren von Blöcken erfordert keine Zustandsdaten

Damit dies geschehen kann, müssen Verkle-Bäume bereits in Ethereum-Clients implementiert worden sein. Verkle-Bäume sind eine Ersatz-Datenstruktur zur Speicherung von Ethereum-Zustandsdaten, die es ermöglichen, kleine „Zeugen“ fester Größe für die Daten zwischen Peers weiterzugeben und zur Verifizierung von Blöcken zu verwenden, anstatt Blöcke gegen lokale Datenbanken zu verifizieren. Die Proposer-Builder-Trennung (PBS) ist ebenfalls erforderlich, da dies ermöglicht, dass Block-Builder spezialisierte Knoten mit leistungsfähigerer Hardware sind, und diese sind diejenigen, die Zugriff auf die vollständigen Zustandsdaten benötigen.

Zustandslosigkeit beruht darauf, dass Block-Builder eine Kopie der vollständigen Zustandsdaten pflegen, damit sie Zeugen generieren können, die zur Verifizierung des Blocks verwendet werden können. Andere Knoten benötigen keinen Zugriff auf die Zustandsdaten, alle zur Verifizierung des Blocks erforderlichen Informationen sind im Zeugen verfügbar. Dies schafft eine Situation, in der das Vorschlagen eines Blocks teuer ist, das Verifizieren des Blocks jedoch billig, was impliziert, dass weniger Betreiber einen Knoten zum Vorschlagen von Blöcken betreiben werden. Die Dezentralisierung von Block-Proposern ist jedoch nicht kritisch, solange so viele Teilnehmer wie möglich unabhängig verifizieren können, dass die von ihnen vorgeschlagenen Blöcke gültig sind.

Lesen Sie mehr in Dankrads Notizen (opens in a new tab)

Block-Proposer verwenden die Zustandsdaten, um „Zeugen“ zu erstellen – den minimalen Datensatz, der die Werte des Zustands beweist, die durch die Transaktionen in einem Block geändert werden. Andere Validatoren halten den Zustand nicht, sie speichern nur die Zustands-Root (einen Hash des gesamten Zustands). Sie empfangen einen Block und einen Zeugen und verwenden diese, um ihre Zustands-Root zu aktualisieren. Dies macht einen validierenden Knoten extrem leichtgewichtig.

Die schwache Zustandslosigkeit befindet sich in einem fortgeschrittenen Forschungsstadium, beruht jedoch darauf, dass die Proposer-Builder-Trennung und Verkle-Bäume implementiert wurden, sodass kleine Zeugen zwischen Peers weitergegeben werden können. Das bedeutet, dass die schwache Zustandslosigkeit wahrscheinlich noch einige Jahre vom Ethereum Mainnet entfernt ist.

zkEVM für die L1-Verifizierung ist eine ergänzende Technologie, die die zustandslose Verifizierung weiter verbessern könnte. Anstatt nur Zeugen zu überprüfen, könnten Validatoren einen Zero-Knowledge-Beweis verifizieren, dass der gesamte Block korrekt ausgeführt wurde – was kryptographische Gewissheit bietet, ohne Transaktionen erneut auszuführen.

Starke Zustandslosigkeit

Starke Zustandslosigkeit beseitigt die Notwendigkeit für jeden Knoten, Zustandsdaten zu speichern. Stattdessen werden Transaktionen mit Zeugen gesendet, die von Blockproduzenten aggregiert werden können. Die Blockproduzenten sind dann dafür verantwortlich, nur den Zustand zu speichern, der für die Generierung von Zeugen für relevante Konten benötigt wird. Die Verantwortung für den Zustand wird fast vollständig auf die Benutzer verlagert, da sie Zeugen und „Zugriffslisten“ senden, um zu deklarieren, mit welchen Konten und Speicherschlüsseln sie interagieren. Dies würde extrem leichtgewichtige Knoten ermöglichen, aber es gibt Kompromisse, einschließlich der Tatsache, dass es schwieriger wird, mit Smart Contracts zu interagieren.

Starke Zustandslosigkeit wurde von Forschern untersucht, wird aber derzeit voraussichtlich nicht Teil der Roadmap von Ethereum sein – es ist wahrscheinlicher, dass schwache Zustandslosigkeit für die Skalierungsanforderungen von Ethereum ausreicht.

Aktueller Fortschritt

Schwache Zustandslosigkeit, Historienverfall und Zustandsablauf befinden sich alle in der Forschungsphase und werden voraussichtlich erst in einigen Jahren veröffentlicht. Es gibt keine Garantie, dass alle diese Vorschläge implementiert werden; wenn beispielsweise der Zustandsablauf zuerst implementiert wird, besteht möglicherweise keine Notwendigkeit, auch den Historienverfall zu implementieren. Es gibt auch andere Roadmap-Punkte, wie Verkle-Bäume und die Proposer-Builder-Trennung (PBS), die zuerst abgeschlossen werden müssen.

Weiterführende Literatur