jakiro
Autor: Wei Han Ng, Carlos Pérez, staatenloses Konsensforschungsteam; Übersetzung: @bitchainvisionxiaozou
Ethereum hat sich von einem kleinen, experimentellen Netzwerk zu einem wichtigen Bestandteil der globalen Infrastruktur entwickelt. Es rechnet täglich Milliarden von Dollar ab, koordiniert Tausende von Anwendungen und unterstützt das gesamte Ökosystem des Layer-2-Netzwerks (L2).
Letztendlich hängt alles von einer zentralen zugrunde liegenden Komponente ab: dem Zustand (Staat).
1, was ist„Status„und seine Bedeutung
Das Guthaben eines Benutzers wird nicht in seiner Wallet gespeichert, sondern im Zustand von Ethereum.Der Zustand kann grob verstanden werden als „alles, was Ethereum derzeit weiß“: Konten, Vertragsspeicher (alle durch den Vertrag geschriebenen Daten), Bytecode (die Logik, die bei der Verwendung von Smart Contracts abläuft).
Der Zustand ist die Grundlage für fast alle Funktionen:
Wallets nutzen es, um Salden und vergangene Betriebsaufzeichnungen anzuzeigen;
Dezentrale Anwendungen (Dapps) fragen es ab, um mehr über bestehende Positionen, Aufträge oder Nachrichten zu erfahren;
Die Infrastruktur (Block-Explorer, Cross-Chain-Brücken, Indexer usw.) liest kontinuierlich den Status, um darüber hinaus Dienste bereitzustellen.
Wenn der Staat zu groß, zu zentralisiert oder schwer zu bedienen wird, werden alle oben genannten Schichten fragiler, teurer und schwieriger zu dezentralisieren.
2,L1Expansion hat Konsequenzen
Ethereum arbeitet seit vielen Jahren weiter an der Netzwerkerweiterung: durch das Second-Layer-Netzwerk EIP-4844, die Erhöhung des Gaslimits, die Neufestsetzung der Gasgebühren und den integrierten Mechanismus zur Trennung von Antragstellern und Bauherren.Jeder Schritt hat die Netzwerkverarbeitungsfähigkeiten verbessert, aber auch neue Herausforderungen mit sich gebracht.
Herausforderung 1: Der Status wächst weiter
Die Staatsgröße von Ethereum nimmt weiter zu. Jedes neue Konto, jeder neue Speichervorgang und jedes neue Bytecode-Schreiben erhöht dauerhaft die Datenmenge, die das Netzwerk speichern muss.
Dadurch entstehen konkrete Kosten:
Validatoren und vollständige Knoten müssen mehr Daten speichern.Mit zunehmender Zustandsgröße muss die Datenbank zusätzliche Arbeitslast bewältigen und die Effizienz nimmt ab.
Der RPC-Dienstleister muss vollständig erreichbar bleiben und sicherstellen, dass alle Konten oder gespeicherten Daten jederzeit abgefragt werden können.
Das Anwachsen des Status führt zu einer langsameren Knotensynchronisierung und verringerter Stabilität.
Eine Erhöhung des Gaslimits erhöht die Zustandsaufblähung, da jeder Block mehr Schreibvorgänge aufnehmen kann. Dieses Problem ist bereits in anderen öffentlichen Ketten aufgetreten.Mit zunehmender Staatsskala wird es für normale Benutzer schwierig, vollständige Knoten zu betreiben, was dazu führt, dass sich die Staatsdaten in den Händen einiger weniger großer Dienstanbieter konzentrieren.
In Ethereum wurden die meisten Blöcke von professionellen Bauherren hergestellt.Die Hauptfrage besteht darin, wie viele unabhängige Einheiten im kritischen Moment noch den gesamten Blockbau abschließen können.Wenn nur eine sehr kleine Anzahl von Teilnehmern den vollständigen Status speichern und bereitstellen kann, werden die Zensurresistenz und die vertrauenswürdige Neutralität beeinträchtigt, da weniger Auftraggeber in der Lage sind, Blöcke mit zensierten Transaktionen zu erstellen.
Ein Teil des positiven Faktors besteht darin, dass Mechanismen wie FOCIL und VOPS darauf ausgelegt sind, Zensurresistenz im professionellen Bauunternehmer-Ökosystem sicherzustellen.Seine Wirksamkeit hängt jedoch immer noch von einem gesunden Ökosystem von Knoten ab, die zu erschwinglichen Kosten auf Zustandsdaten zugreifen, diese speichern und bereitstellen können.Daher ist die Kontrolle des Zustandswachstums eine notwendige Voraussetzung und keine optionale Optimierung.
Um den kritischen Punkt des Problems zu ermitteln, führen wir aktiv Stresstests durch:
Wann wird das Staatswachstum zum Skalierungsengpass?
Wann ist es aufgrund der Größe des Staates für Knoten schwierig, dem Kettenkopf zu folgen?
Wenn Client-Implementierungen bei extremen Zustandsskalen fehlschlagen.
Herausforderung 2: Wer ist in einer zustandslosen Architektur für die Speicherung und Bereitstellung des Zustands verantwortlich?
Selbst wenn Ethereum die derzeitige Tankobergrenze dauerhaft beibehält, werden wir irgendwann auf das staatliche Inflationsproblem stoßen. Gleichzeitig erwartet die Community eindeutig einen höheren Durchsatz.
Zustandslose Schemata beseitigen eine wesentliche Einschränkung: Validatoren müssen nicht den vollständigen Status besitzen, um Blöcke zu validieren, sondern nur Beweise.Dies ist ein wichtiger Durchbruch bei der Skalierbarkeit, der sowohl dem Bedürfnis der Community nach höherem Durchsatz gerecht wird als auch eine einst verborgene Tatsache enthüllt, dass sich die Zustandsspeicherung zu einer unabhängigen und spezialisierteren Funktion entwickeln kann, anstatt an jeden Validator gebunden zu sein.
Zu diesem Zeitpunkt kann der größte Teil des Status nur gespeichert werden durch:
Blockbauer;
RPC-Dienstleister;
Andere professionelle Betreiber (z. B. MEV-Sucher und Block-Explorer).
Mit anderen Worten: Der Staat wird stärker zentralisiert.
Dies hat mehrere Konsequenzen:
Erhöhte Schwierigkeiten bei der Synchronisierung: Zentralisierte Dienstanbieter können beginnen, den Zugriff auf den Status einzuschränken, was den Start neuer Dienstanbieter erschwert.
Geschwächte Zensurresistenz: Wenn zensierte Statusdaten nicht erhalten werden können, können Anti-Zensur-Mechanismen wie FOCIL versagen;
Risiko der Systemstabilität: Wenn nur wenige Einheiten den vollständigen Status speichern und bereitstellen, wird ihre Dienstunterbrechung oder externer Druck den Zugriff auf die meisten Komponenten des Ökosystems schnell unterbrechen.
Obwohl viele Unternehmen den Status speichern, gibt es keine wirksame Möglichkeit, zu überprüfen, ob sie tatsächlich Dienstleistungen erbringen, und die bestehenden Anreize sind unzureichend. Die Snapshot-Synchronisierung wird standardmäßig weitgehend unterstützt, RPC-Dienste jedoch nicht.Ohne die Kosten staatlicher Dienste zu senken und ihre allgemeine Attraktivität zu erhöhen, wird die Fähigkeit des Netzwerks, auf seinen eigenen Staat zuzugreifen, auf eine kleine Anzahl von Dienstanbietern beschränkt.
Dieses Problem betrifft auch Layer-2-Netzwerke.Die Fähigkeit von Benutzern, Pakettransaktionen zu erzwingen, hängt vom zuverlässigen Zugriff auf den Rollup-Vertragsstatus auf L1 ab.Wenn der Zugang zum L1-Zustand fragil oder stark zentralisiert wird, wird es schwierig, diese Sicherheitsventilmechanismen in praktischen Anwendungen zu bedienen.
3, die drei Hauptrichtungen, die wir sehen
(1) Gültigkeitsdauer des Status
Nicht alle Staatsdaten sind von gleichbleibender Bedeutung. Unsere aktuelle Analyse zeigt, dass auf etwa 80 % der Staatsdaten seit mehr als einem Jahr nicht zugegriffen wurde.Allerdings tragen die Knoten weiterhin die Kosten für die dauerhafte Speicherung dieses Zustands.
Die Kernidee des Zustandsvaliditätsmechanismus besteht darin, den inaktiven Zustand vorübergehend aus der „aktiven Menge“ zu entfernen und ihn dann bei Bedarf durch irgendeine Form von Beweisen wiederherzustellen.Im Großen und Ganzen lassen sie sich in zwei Hauptkategorien einteilen:
Kategorie 1: Mal, Ungültigmachung, Auferstehung
Anstatt alle Zustände als dauerhaft aktiv zu behandeln, markiert das Protokoll selten verwendete Zustände als inaktiv, sodass sie nicht länger in der von jedem Knoten verwalteten aktiven Menge bestehen bleiben, während sie gleichzeitig durch einen historischen Existenznachweis in der Zukunft wiederhergestellt werden können.Der praktische Effekt besteht darin, dass häufig verwendete Verträge und Guthaben aktiv bleiben und geringe Zugriffskosten verursachen, während längst vergessene Zustände nicht ständig von jedem Knoten übertragen werden müssen und immer noch abgerufen werden können, wenn jemand sie erneut benötigt.
Kategorie 2: Mehrzyklus-Fehlermechanismus
Bei einem Design mit mehreren Perioden entwerten wir nicht einzelne Einträge, sondern unterteilen den Zustand periodisch in Perioden (z. B. eine Periode = ein Jahr). Der aktuelle Zyklus ist kleiner und vollständig aktiv, der alte Zyklus ist aus Sicht der Echtzeitausführung eingefroren und der neue Status wird in den aktuellen Zyklus geschrieben.Der alte Zustand kann nur durch den Nachweis seiner Existenz im vorherigen Zyklus wiederhergestellt werden.
Der Mark-Invalidate-Resurrection-Mechanismus ist in der Regel ausgefeilter und der Resurrection-Prozess einfacher, aber der Marking-Prozess erfordert die Speicherung zusätzlicher Metadaten.Mehrzyklusfehler sind konzeptionell einfacher und natürlicher in Archivierungsmechanismen integriert, Wiederauferstehungsbeweise sind jedoch tendenziell komplexer und umfangreicher.
Letztendlich verfolgen diese beiden Ansätze das gleiche Ziel: den aktiven Zustand schlank zu halten, indem inaktive Teile vorübergehend entfernt werden, und gleichzeitig einen Weg zur Wiederbelebung zu schaffen. Allerdings gehen sie unterschiedliche Kompromisse in Bezug auf Komplexität, Benutzererfahrung und Arbeitsverteilung auf Clients und Infrastruktur ein.
(2) Statusarchiv
Das Statusarchiv unterteilt den Status in Kalt- und Heißstatus.
Hot States sind Teile des Netzwerks, die häufigen Zugriff erfordern;
Der Kaltzustand ist der Teil, der für die Geschichte und Überprüfbarkeit immer noch wichtig ist, aber selten berührt wird.
Im Zustandsarchiv-Design speichern Knoten explizit kürzlich häufig verwendete Hot-States und historische Daten separat.Auch wenn der Gesamtzustand weiter wächst, kann die Größe der Teile, auf die schnell zugegriffen werden muss (heiße Datensätze), begrenzt bleiben.In der Praxis bedeutet dies, dass die Ausführungsleistung des Knotens – insbesondere die I/O-Kosten für den Zugriff auf den Status – über die Zeit grundsätzlich stabil bleiben kann, ohne mit zunehmendem Alter der Kette abzunehmen.
(3) Senken Sie den Schwellenwert für staatliche Speicherung und Dienste
Eine offensichtliche Frage ist: Können wir unsere Ziele erreichen, während wir weniger Daten haben?Mit anderen Worten: Können Knoten und Wallets entworfen werden, die keine permanente Speicherung des vollständigen Zustands erfordern und dennoch als gültige Teilnehmer fungieren?
Eine vielversprechende Richtung sind teilweise zustandslose Lösungen:
Knoten speichern und stellen nur Teilzustände bereit (z. B. Daten, die sich auf einen bestimmten Benutzer oder eine bestimmte Anwendung beziehen).
Wallets und Light-Clients übernehmen eine aktivere Rolle bei der Speicherung und Zwischenspeicherung erforderlicher Statusfragmente, anstatt sich ausschließlich auf einige wenige große RPC-Dienstanbieter zu verlassen.Wenn der Speicher sicher auf Wallets und „Nischen“-Knoten verteilt werden kann, wird die Belastung für einzelne Betreiber verringert und die Gruppe der staatlichen Inhaber wird vielfältiger.
Eine andere Richtung besteht darin, die Hürden für den Betrieb nützlicher Infrastruktur abzubauen:
Vereinfachen Sie den Prozess der Bereitstellung von RPC-Knoten, die nur einen Teil des Staates bedienen.
Entwerfen Sie Protokolle und Tools, die es Wallets und Anwendungen ermöglichen, mehrere lokale Datenquellen zu erkennen und zu integrieren, anstatt sich auf einen einzigen vollständigen RPC-Endpunkt zu verlassen.
4, zukünftige Richtung
Der Zustand von Ethereum wird still und leise zum Schlüssel für mehrere Kernthemen für die Zukunft des Protokolls:
Inwieweit stellt die Vergrößerung des Staates ein Hindernis für die Teilnahme dar?
Wenn Validatoren Blöcke sicher validieren können, ohne dass ein Status erforderlich ist, wer speichert den Status?
Wer stellt den Benutzern Statusdienste zur Verfügung? Was ist der Anreiz?
Einige Probleme müssen noch geklärt werden, aber die Richtung ist klar: Reduzieren Sie die Leistungsbeschränkungen des Staates, reduzieren Sie die Speicherkosten und verbessern Sie die Zugänglichkeit der Dienste.
Unser aktueller Fokus liegt auf der Förderung risikoarmer und ertragreicher Arbeit:
Archivierungsschema
Wir testen Lösungen außerhalb des Protokolls, um die Größe des aktiven Zustands zu steuern, und verlassen uns gleichzeitig auf Archivierungslösungen zur Speicherung historischer Daten.Dadurch werden reale Daten zu Leistung, Benutzererfahrung und betrieblicher Komplexität bereitgestellt.Wenn die Überprüfung gültig ist, kann sie bei Bedarf zu einem protokollinternen Upgrade hochgestuft werden.
Einige zustandslose Knoten und RPC-Verbesserungen
Die meisten Benutzer und Anwendungen interagieren mit Ethereum über zentralisierte RPC-Dienstanbieter.Wir arbeiten an folgenden Verbesserungen:
Reduzieren Sie die Schwierigkeit und die Kosten für den Betrieb von Knoten, auch wenn die Knoten nicht alle Zustände speichern.
Ermöglichen Sie die Zusammenarbeit mehrerer Knoten, um vollständige staatliche Dienste bereitzustellen.
Erhöhen Sie die Vielfalt der RPC-Dienstanbieter und vermeiden Sie Single-Point-Engpässe.
Diese Projekte wurden sorgfältig aufgrund ihres unmittelbaren Nutzens und ihrer zukunftsweisenden Kompatibilität ausgewählt: Sie werden sowohl den aktuellen Zustand von Ethereum verbessern als auch den Grundstein für tiefgreifendere Protokoll-Upgrades in der Zukunft legen.
