Die Zukunft des Staates Ethereum

Haftungsausschluss: Der folgende Blog ist ein Vorschlag des Stateless Consensus-Teams. Der Inhalt impliziert möglicherweise keine Konsensmeinungen, und die EF ist eine breite Organisation, die eine gesunde Meinungsvielfalt im gesamten Protokoll umfasst und darüber hinaus gemeinsam Ethereum stärkt. Besonderer Dank geht an Ladislaus von Daniels und Marius van der Wijden für die Durchsicht dieses Artikels.

Ethereum hat sich von einem kleinen experimentellen Netzwerk zu einem wichtigen Teil der globalen Infrastruktur entwickelt. Jeden Tag werden Milliardenbeträge abgewickelt, Tausende von Anwendungen koordiniert und ein ganzes Ökosystem von L2s verankert.

All dies hängt letztendlich von einer einzigen zugrunde liegenden Komponente ab: Zustand.

Was ist „Staat“ und warum ist er wichtig?

Das Guthaben eines Benutzers wird nicht in seinen Wallets gespeichert: Es befindet sich im Zustand von Ethereum. Der Staat kann grob als „alles, was Ethereum gerade weiß“ betrachtet werden:

• Konten
• Vertragsspeicherung (alle Datenverträge wurden geschrieben)
• Bytecode (die Logik, die ausgeführt wird, wenn Sie einen Smart Contract verwenden)

Der Staat liegt fast allem zugrunde:

• Wallets nutzen es, um Guthaben und vergangene Aktionen anzuzeigen.
• Dapps fragen es ab, um zu erfahren, welche Positionen, Aufträge oder Nachrichten vorhanden sind.
• Die Infrastruktur (Explorer, Bridges, Indexer usw.) liest sie ständig, um darüber hinaus Dienste bereitzustellen.

Wenn der Staat zu groß, zu zentralisiert oder zu schwierig zu bedienen ist, werden alle diese Schichten fragiler, teurer und schwerer zu dezentralisieren.

Die Skalierung von L1 hat Konsequenzen

Ethereum befindet sich auf einer mehrjährigen Reise zur Skalierung: L2s, EIP-4844, Erhöhungen der Gaslimits, Neupreise für Gas und die verankerte Trennung zwischen Antragsteller und Bauherrn (ePBS). Mit jedem Schritt kann das Netzwerk mehr Aktivitäten bewältigen, bringt aber auch mehr Herausforderungen mit sich.

Herausforderung Nr. 1 – Der Staat wächst weiter

Die Staatsgröße von Ethereum geht nur in eine Richtung: nach oben. Jeder neue Konto-, Speicher- und Bytecode-Schreibvorgang fügt Daten hinzu, die das Netzwerk für immer aufbewahren muss.

Das hat konkrete Kosten:

• Validatoren und vollständige Knoten müssen mehr Daten speichern. Dies führt zu zusätzlicher Arbeit in der Datenbank, die mit zunehmender Größe des Staates weniger effizient ist.
• RPC-Anbieter müssen den vollständigen Status verfügbar halten, damit jedes Konto oder jeder Speicher jederzeit abgefragt werden kann.
• Die Synchronisierung wird mit zunehmendem Zustand des Staates langsamer und fragiler.

Abbildung 1. Neuer Staat, der im vergangenen Jahr pro Woche hinzugefügt wurde (EIP-8037)

Erhöhungen des Gaslimits verstärken das Zustandswachstum, da sie mehr Schreibvorgänge pro Block ermöglichen. Andere Ketten kennen dieses Problem bereits. Angesichts der wachsenden Staatsgröße ist der Betrieb eines vollständigen Knotens für durchschnittliche Benutzer unrealistisch, wodurch der Staat in die Hände einiger weniger großer Anbieter gerät.

Auf Ethereum werden die meisten Blöcke bereits von erfahrenen Entwicklern erstellt. Eine Sorge besteht darin, wie viele unabhängige Parteien immer noch durchgängig Blöcke aufbauen können, wenn es darauf ankommt. Wenn nur eine winzige Gruppe von Akteuren den Gesamtstaat halten und ihm dienen kann, leiden Zensurresistenz und glaubwürdige Neutralität, weil weniger Parteien Blöcke aufbauen können, die zensierte Transaktionen beinhalten.

Als teilweiser Silberstreif am Horizont mögen Mechanismen FOCILL Und VOPS Ziel ist es, die Zensurresistenz auch in einer Welt mit spezialisierten Bauträgern aufrechtzuerhalten. Ihre Wirksamkeit hängt jedoch immer noch von einem gesunden Ökosystem von Knotenpunkten ab, die ohne übermäßige Kosten auf den Staat zugreifen, ihn halten und ihm dienen können. Die Kontrolle des Staatswachstums ist daher eine Voraussetzung und keine optionale Optimierung.

Um festzustellen, wann dies zu einem Problem werden würde, führen wir aktive Messungen und Stresstests durch:

• Wenn das Staatswachstum zum Skalierungsengpass wird.
• Wenn die Zustandsgröße es den Knoten erschwert, dem Kopf der Kette zu folgen.
• Wenn Client-Implementierungen bei extremer Zustandsgröße scheitern.

Weitere Details finden Sie unter bloatnet.info.

Herausforderung Nr. 2 – Wer hält und dient in einer staatenlosen Welt den Staat?

Selbst wenn Ethereum für immer beim heutigen Gaslimit bleiben würde, würden wir irgendwann auf staatliche Wachstumsprobleme stoßen. Gleichzeitig wünscht sich die Community eindeutig mehr Durchsatz.

Durch die Zustandslosigkeit wird eine große Einschränkung beseitigt: Validatoren müssen nicht mehr den vollständigen Status halten, um Blöcke zu validieren, sie können nur noch Beweise überprüfen. Dies ist ein großer Skalierbarkeitsgewinn, der es uns ermöglicht, die Nachfrage der Community nach höherem Durchsatz zu erfüllen, und es macht auch etwas deutlich, was früher implizit war: Die Zustandsspeicherung kann zu einer separaten, spezialisierteren Rolle werden, anstatt an jeden Validator gebunden zu sein.

Zu diesem Zeitpunkt werden die meisten Zustände wahrscheinlich nur gespeichert durch:

• Blockbauer
• RPC-Anbieter
• Andere spezialisierte Operatoren wie MEV-Sucher und Block-Explorer

Mit anderen Worten: Der Staat wird viel mehr zentralisiert.

Das hat mehrere Konsequenzen:

• Die Synchronisierung wird schwieriger: Zentralisierte Anbieter könnten damit beginnen, den Zugang zum Staat zu kontrollieren, was die Gründung neuer Anbieter erschwert.
• Der Zensurwiderstand lässt nach: Zensurresistenzmechanismen wie FOCIL könnten aufgrund der Nichtverfügbarkeit des zensierten Staates kastriert werden.
• Resilienz und Risikoerfassung: Wenn nur wenige Akteure den gesamten Zustand speichern und bedienen, können Ausfälle oder äußerer Druck auf sie schnell den Zugang zu großen Teilen des Ökosystems abschneiden.

Selbst wenn viele Entitäten den Status speichern, gibt es keine gute Möglichkeit zu beweisen, dass sie ihn tatsächlich bereitstellen, und es gibt nur wenige Anreize, dies zu tun. Die Snap-Synchronisierung wird weitgehend standardmäßig bereitgestellt, RPC jedoch nicht. Ohne die staatliche Bereitstellung billiger und allgemein attraktiver zu machen, liegt die Fähigkeit des Netzwerks, auf seinen eigenen Staat zuzugreifen, letztendlich in den Händen weniger Anbieter.

Dies betrifft auch L2s. Die Fähigkeit der Benutzer, die Einbindung ihrer Transaktionen zu erzwingen, hängt vom zuverlässigen Zugriff auf den Rollup-Vertragsstatus auf L1 ab. Wenn der Zugang zum L1-Staat fragil oder stark zentralisiert wird, wird es deutlich schwieriger, diese Sicherheitsventile in der Praxis einzusetzen.

Wir sehen drei große Richtungen

Staatsablauf

Nicht jeder Staat ist für immer gleich wichtig. In unserem aktuelle AnalyseWir haben gezeigt, dass etwa 80 % des Staates seit mehr als einem Jahr nicht berührt wurden. Allerdings tragen Knoten immer noch die Kosten für die dauerhafte Beibehaltung des Zustands.

Beim Zustandsablauf handelt es sich um die allgemeine Idee, den inaktiven Zustand vorübergehend aus dem „aktiven Satz“ zu entfernen und einen Beweis zu verlangen, um ihn bei Bedarf wiederherzustellen. Auf einer hohen Ebene können wir uns zwei große Kategorien vorstellen:

1. Markieren, ablaufen, wiederbeleben
Anstatt den gesamten Zustand als permanent aktiv zu behandeln, kann das Protokoll selten verwendete Zustände als inaktiv markieren, sodass er nicht mehr in der aktiven Menge verbleibt, die jeder Knoten verwaltet, und gleichzeitig eine spätere Wiederbelebung mit einem Nachweis ermöglicht, dass er zuvor existiert hat. Tatsächlich bleiben häufig verwendete Verträge und Guthaben weiterhin aktiv und günstig zugänglich, während längst vergessene Zustände nicht jeden Knoten belasten, aber dennoch wiederhergestellt werden können, wenn jemand sie erneut benötigt.

2. Ablauf mehrerer Epochen
Bei einem Design mit mehreren Epochen lassen wir einzelne Einträge nicht verfallen, sondern teilen den Staat regelmäßig in Epochen auf (z. B. eine Epoche = ein Jahr). Die aktuelle Ära ist klein und voll aktiv, ältere Epochen werden aus der Sicht der Live-Ausführung eingefroren und ein neuer Zustand wird in die aktuelle Ära geschrieben. Der alte Zustand kann nur wiederhergestellt werden, wenn Beweise dafür vorliegen, dass er in einer früheren Ära existiert hat.

Markieren-Ablaufen-Wiederbeleben ist tendenziell feinkörniger und macht die Wiederbelebung einfacher, aber für die Markierung müssen zusätzliche Metadaten gespeichert werden. Der Ablauf mehrerer Epochen ist konzeptionell einfacher und lässt sich natürlicher mit der Archivierung kombinieren, aber die Wiederbelebungsbeweise sind tendenziell komplexer und umfangreicher.

Letztendlich zielen beide Kategorien auf das gleiche Ziel ab – den aktiven Zustand klein zu halten, indem inaktive Teile vorübergehend entfernt werden und gleichzeitig Möglichkeiten zur Wiederbelebung bereitgestellt werden –, aber sie machen unterschiedliche Kompromisse in Bezug auf Komplexität, UX und wie viel Arbeit auf Clients und Infrastruktur verlagert wird.

Zusätzliche Lektüre:

Staatsarchiv

Das Staatsarchiv ist ein Ansatz, der heiße und kalte Teile des Staates trennt.

• Der Hot-State ist der Zustand, auf den das Netzwerk häufig zugreifen muss.
• Kalter Zustand ist alles, was für Geschichte und Nachweisbarkeit noch von Bedeutung ist, aber selten berührt wird.

In einem Zustandsarchivdesign speichern Knoten den aktuellen, häufig verwendeten Zustand explizit getrennt von älteren Daten. Selbst wenn der Gesamtzustand weiter wächst, kann der Teil, der einen schnellen Zugriff benötigt (der Hot Set), begrenzt bleiben. In der Praxis bedeutet dies, dass die Ausführungsleistung eines Knotens – insbesondere die E/A-Kosten für den Zugriff auf den Status – im Laufe der Zeit ungefähr stabil bleiben kann, anstatt sich mit zunehmendem Alter der Kette zu verschlechtern.

Macht es einfacher, den Staat zu halten und ihm zu dienen

Eine offensichtliche Frage ist: Können wir genug tun und dabei weniger Daten speichern? Mit anderen Worten: Können wir Knoten und Wallets entwerfen, die weiterhin nützliche Teilnehmer sind, ohne den vollständigen Zustand für immer zu speichern?

Eine vielversprechende Richtung ist die teilweise Staatenlosigkeit:

• Knoten speichern und bedienen nur eine Teilmenge des Zustands (z. B. die Teile, die für eine Gruppe von Benutzern oder Anwendungen relevant sind).
• Wallets und Light-Clients übernehmen eine aktivere Rolle bei der Speicherung und Zwischenspeicherung der für sie wichtigen Statuselemente, anstatt sich ausschließlich auf einige wenige große RPC-Anbieter zu verlassen. Wenn wir die Speicherung sicher über Wallets und „Nischen“-Knoten hinweg dezentralisieren können, verringert sich die Belastung für jeden einzelnen Betreiber und die Gruppe der Staatsinhaber wird vielfältiger.

Eine andere Richtung besteht darin, die Hürden für den Betrieb einer nützlichen Infrastruktur zu senken:

• Erleichtern Sie das Hochfahren von Knoten, die RPC für einen Teilzustand bereitstellen können.
• Entwerfen Sie Protokolle und Tools, damit Wallets und Apps mehrere Teilquellen erkennen und kombinieren können, anstatt von einem einzigen vollständigen RPC-Endpunkt abhängig zu sein.

Wir untersuchen diese Ideen detaillierter in:

Was kommt als nächstes?

Der Zustand von Ethereum steht stillschweigend im Mittelpunkt einiger der größten Fragen für die Zukunft des Protokolls:

• Wie groß kann der Staat wachsen, bevor er zum Hindernis für die Teilhabe wird?
• Wer wird es speichern, sobald Validatoren Blöcke ohne es sicher validieren können?
• Wer stellt es den Nutzern zur Verfügung und unter welchen Anreizen?

Einige dieser Fragen sind noch offen, aber die Richtung ist klar: Reduzieren Sie den Status als Leistungsengpass, Senken Sie die Kosten für die AufbewahrungUnd erleichtern das Servieren.

Unsere Prioritäten liegen heute darin, uns auf risikoarme, lohnende Arbeit zu konzentrieren, die hilft:

Archivlösungen
Wir experimentieren mit Lösungen außerhalb des Protokolls, um den aktiven Zustand begrenzt zu halten, während wir uns bei älteren Daten auf Archive verlassen. Es sollte uns reale Daten zu Leistung, UX und betrieblicher Komplexität liefern. Wenn es sich als erfolgreich erweist, können wir es bei Bedarf in eine protokollinterne Änderung umsetzen.

Teilweise zustandslose Knoten und RPC-Verbesserungen
Die meisten Benutzer und Apps interagieren mit Ethereum über zentralisierte RPC-Anbieter. Wir arbeiten an Verbesserungen, die:

• Machen Sie es einfacher und kostengünstiger, Knoten zu betreiben, auch wenn diese nicht jeden Zustand enthalten.
• Ermöglichen Sie die Zusammenarbeit mehrerer Knoten, um die gesamte Zustandsoberfläche zu bedienen.
• Erhöhen Sie die Vielfalt unter den RPC-Anbietern, damit kein einzelner Akteur zum Engpass wird.

Diese Projekte wurden bewusst ausgewählt, weil sie sofort nützlich und vorwärtskompatibel sind: Sie machen Ethereum heute gesünder und bereiten gleichzeitig den Boden für ehrgeizigere Protokolländerungen später.

Während wir iterieren, teilen wir weiterhin unsere Fortschritte und unsere offenen Fragen. Aber wir können das nicht isoliert lösen. Wenn Sie ein Client-Entwickler sind, einen Knoten betreiben, eine Infrastruktur betreiben, auf L2s aufbauen oder sich einfach nur um die langfristige Gesundheit von Ethereum kümmern, laden wir Sie ein, sich zu engagieren: Teilen Sie Feedback zu unseren Vorschlägen, nehmen Sie an der Diskussion in Foren und Anrufen teil und helfen Sie dabei, neue Ansätze in der Praxis zu testen.