Vitaliks Vorschlag zur Spaltung des Ethereum-Staates: Der „One-Bit“-Paradigmenwechsel

Vitalik Buterin veröffentlichte kürzlich:

"Hyperskalierender Ethereum-Staat durch die Schaffung neuer Staatsformen"

Die Ausführung hat glaubwürdige 1000-fache Wege.
Die Datenverfügbarkeit verfügt über glaubwürdige 1000-fache Pfade.

Der Staat tut das nicht – es sei denn, wir ändern was "Zustand" eigentlich bedeutet.

Warum der Staat grundlegend anders ist

State ist die Live-Datenbank, die jeder Validator vollständig speichern muss, um sie lesen und aktualisieren zu können, um Transaktionen auszuführen:

• Konten
• Vertragscode
• Lagerplätze
• ERC-20-Waagen
• NFTs
• DeFi-Positionen

Mit zunehmender Nutzung wächst auch diese Datenbank. Standardmäßig wird es nie verkleinert.

Die Ausführung kann parallelisiert und nachgewiesen werden. Daten können abgetastet werden, indem sie in umgewandelt werden "Kleckse" und auf Shards verteilt, wobei jeder Validator nur einen Teil speichert.

Nach dem heutigen Modell verlangt der Staat von den Validatoren, dass sie einen ständig wachsenden Arbeitssatz online halten.

Das bedeutet größere Festplatten, mehr RAM, mehr I/O und längere Synchronisierungszeiten.
Das ist struktureller Zentralisierungsdruck.

Wenn die Ausführung und die Datenskala, der Zustand aber die Anforderungen an die Validatoren immer weiter in die Höhe treibt, lässt die Dezentralisierung mit der Zeit nach.

Der Kernwandel: Zwei Staatsformen

Anstatt zuzulassen, dass ein einzelner monolithischer Zustandsbaum unbegrenzt wächst, führt der Vorschlag Folgendes ein: eine zweite Staatsform mit einem anderen Dauerhaftigkeits- und Kostenmodell.

1. Permanenter Live-Status

Dies ist die derzeitige Staatsstruktur, die nach Vitaliks Vorschlag weiterhin bestehen würde.

Aufgrund seines Designs eignet es sich für hochwertige gemeinsame Objekte, die die Benutzerbasis vollständig aktiv halten muss:

• Benutzerkonten
• Kernvertragscode
• Kritische gemeinsame Logik

Das Ziel besteht darin, diesen Arbeitssatz oder alten Zustandstyp absichtlich begrenzt zu halten, da er den Zentralisierungsdruck dauerhaft erhöht.

2. Günstiger, restriktiver Staat (UTXO-ähnlich)

Die meisten benutzerspezifischen Objekte – Guthaben, NFTs, einzelne Positionen – werden in eine andere Struktur verschoben.

Diese Objekte müssen nicht dauerhaft im Validatorspeicher verbleiben.

Sie werden nicht gelöscht. Sie werden beweisbar und wiederbelebbar.

Die architektonische Entriegelung: Daten vom Status trennen

Der Vorschlag nutzt eine starke Idee:

Validatoren müssen nicht die vollständigen Objektdaten speichern – sie müssen lediglich den Gültigkeitsstatus verfolgen.

Das System funktioniert wie folgt:

1. Objekte werden in kryptografische Bäume (Merkle-Strukturen) eingebunden.
2. Die Baumwurzeln sind im Konsens verankert.
3. Validatoren bewahren die vollständigen Objektdaten nicht auf unbestimmte Zeit auf.

Welche Validatoren Tun keep ist minimal:

A einzelnes Bit pro Objekt gibt an, ob dies der Fall ist "ausgegeben" oder "nicht ausgegeben."

Wenn ein Benutzer mit einem Objekt interagieren möchte:

• Ihr Wallet liefert die Objektdaten.
• Das Wallet liefert einen Merkle-Beweis, dass das Objekt zu einem bekannten Commitment-Root gehört.
• Validatoren prüfen:
  • Der Beweis stimmt mit der Wurzel überein.
  • Das Bit des Objekts ist still "nicht ausgegeben."

Wenn beide Prüfungen erfolgreich sind: – Die Transaktion wird ausgeführt. – Das Bit wechselt zu "ausgegeben."

Das ist ausreichend.

Der Validator benötigt niemals die vollständige globale Datenbank aller Benutzerguthaben. Es benötigt nur: – Die Commitment-Wurzel. – Das Bitfeld zur Verfolgung der Ausgaben.

Die Verifizierungskosten werden in der historischen Datengröße logarithmisch und im gesamten Live-Status nicht linear.

Warum das radikal anders ist

Unter dem heutigen Kontomodell:

Validatoren müssen den gesamten Kontostatus speichern und aktualisieren, um Änderungen verarbeiten zu können.

Unter diesem Modell:

Validatoren prüfen kryptografische Beweise und drehen ein Bit um.

Die umfangreichen Daten können lokal bereinigt werden.
Benutzer bringen es nur bei Bedarf zurück.

Das entkoppelt:

Gesamtes historisches Staatswachstum

aus
Größe des Validator-Arbeitssatzes

Die gesamten Benutzerdaten können um Größenordnungen ansteigen.
Die Anforderungen an die Validator-Hardware müssen nicht proportional wachsen.

Warum dies für die Dezentralisierung wichtig ist

Das meiste Zustandswachstum kommt heute von Objekten pro Benutzer, die nicht dauerhaft aktiv bleiben müssen.

Wenn die Hardwareanforderungen stetig steigen: – Weniger Leute betreiben Knoten. – Die Beteiligung nimmt ab. – Die Dezentralisierung schwächt sich ab.

Bei der Ausführungsskalierung handelt es sich um eine Technik, die durch effizientere ZK-Prüfalgorithmen erfolgt.
Bei der Datenskalierung handelt es sich um eine Technik durch effizientere Datenerfassungs- und Sharding-Protokolle.

Die Zustandsskalierung unterliegt architektonischen Einschränkungen, da sie nicht bereinbar, nicht skalierbar und nicht komprimierbar ist.

Dieser Vorschlag gestaltet die Architektur neu, sodass das Zustandswachstum nicht länger die Zentralisierung des Validators durch Zustandsbildung erzwingt beschneidbarund in gewissem Sinne fragmentierbar, über Benutzer hinweg, die die Daten für ihre eigenen nicht ausgegebenen UTXOs speichern.

Der Weg voraus

Zur Umsetzung dieser architektonischen Änderung ist ein erheblicher Entwicklungsaufwand erforderlich:

• Neue Transaktionsformate.
• Proof-Generierung auf Wallet-Ebene.
• Zuverlässiger Zugriff auf historische Daten.
• Erhöhte Kundenkomplexität.

Die Beweisverfügbarkeit muss robust sein.
Die Auferstehung muss nahtlos erfolgen.
Die Tools müssen dies vom Benutzer abstrahieren.

Die Komplexität muss in die Softwareebene verlagert werden – nicht in die Anforderungen an die Validator-Hardware.

Fazit

Dies ist keine inkrementelle Optimierung.

Es ist eine Neudefinition dessen, was zählt "Live-Zustand".

Durch die Trennung vollständiger Objektdaten von einem Ein-Bit-Gültigkeitsflag erhält Ethereum einen plausiblen Weg zur Skalierung der Aktivität um Größenordnungen, ohne die Kosten für die Verifizierung stetig zu erhöhen.

Derzeit gibt es für die Ausführung und die Daten einen klaren Lösungsplan, der Staat jedoch nicht, sodass die Skalierung von Ethereum irgendwann auf ein Hindernis stoßen wird.

Dieser Vorschlag zielt direkt auf die stärkste Einschränkung ab.