Vitalik Buterin gesteht seinen größten Design-Fehler seit 2017 – ist Ihr Ethereum in Gefahr?

Vitalik Buterin sagte, er stimme seinem Tweet von 2017 nicht mehr zu, der die Notwendigkeit für Nutzer, Ethereum End-to-End persönlich zu verifizieren, heruntergespielt hatte.

Diese Woche argumentierte er, dass das Netzwerk selbst gehostete Verifizierung als nicht verhandelbare Ausstiegsmöglichkeit behandeln sollte, während seine Architektur leichter und modularer wird.

Buterins ursprüngliche Position entstand aus einer Design-Debatte darüber, ob eine Blockchain den Zustand on-chain festlegen oder den Zustand als „impliziert" behandeln sollte, rekonstruierbar nur durch Wiedergabe geordneter Transaktionen.

Ethereums Ansatz, einen State-Root in jeden Block-Header zu setzen und Merkle-Baum-Beweise zu unterstützen, ermöglicht es einem Nutzer, ein bestimmtes Guthaben, Contract Code oder Storage Value zu beweisen, ohne die gesamte Historie neu auszuführen, solange der Nutzer die Konsens-Gültigkeit der Chain unter einer ehrlichen Mehrheitsannahme akzeptiert.

In seinem neuen Beitrag formulierte Buterin diesen Tradeoff als in der Praxis unvollständig, da er Nutzer immer noch dazu zwingen kann, zwischen der Wiedergabe der vollständigen Chain oder dem Vertrauen auf einen Vermittler wie einen RPC-Operator, einen archivalen Daten-Host oder einen Proof-Service zu wählen.

Vitaliks Kehrtwende bei der persönlichen Verifizierung der Blockchain-Historie

Er verankerte die Änderung in zwei Verschiebungen: Machbarkeit und Fragilität.

Zur Machbarkeit schrieb Buterin, dass Zero-Knolwedge-Beweis nun einen Weg bieten, Korrektheit zu überprüfen, ohne „buchstäblich jede Transaktion erneut auszuführen".

2017 argumentierte er, dies hätte Ethereum zu geringerer Kapazität gedrängt, um die Verifizierung erreichbar zu halten.

Die Verschiebung ist wichtig, weil Ethereums öffentliche Roadmap ZK zunehmend als Verifizierbarkeits-Primitiv behandelt, wobei ethereum.org Zero-Knolwedge-Beweis als Möglichkeit darstellt, Sicherheitseigenschaften zu bewahren und gleichzeitig zu reduzieren, was ein Verifizierer berechnen muss.

Arbeiten an „ZK-Light-Client"-Richtungen deuten auch auf ein Modell hin, bei dem ein Gerät mit kompakten Beweisen synchronisieren kann, anstatt einem ständig online befindlichen Gateway zu vertrauen.

Zur Fragilität listete Buterin Ausfallmodi auf, die außerhalb sauberer Bedrohungsmodelle liegen: verschlechterte P2P-Vernetzung, langlebige Services, die heruntergefahren werden, Validator-Konzentration, die die praktische Bedeutung von „ehrlicher Mehrheit" verändert, und informeller Governance-Druck, der „Ruf die Entwickler an" zur Notlösung macht.

Er nannte Zensurdruck rund um Tornado Cash als Beispiel dafür, wie Vermittler den Zugang einschränken können, und argumentierte, dass die letzte Option eines Nutzers sein sollte, „die Chain direkt zu nutzen".

Diese Rahmung folgt einer breiteren Diskussion über die Härtung der Ethereum-Basisebene und die Begrenzung von Veränderungen, inmitten eines Drangs zur Protokoll-„Ossifikation".

In Buterins Darstellung ist die „Berghütte" kein Standard-Lebensstil.

Es ist eine glaubwürdige Rückfalloption, die Anreize verändert, weil das Wissen, dass Nutzer aussteigen können, den Einfluss jeder einzelnen Service-Ebene reduziert.

Dieses Argument kommt, während Ethereum reduziert, was gewöhnliche Nodes speichern sollen, während die Verifizierungsgeschichte des Netzwerks Schritt halten muss.

Ethereum-Client-Nutzung und -Historie

Execution-Clients bewegen sich in Richtung partieller Historie-Ablauf, und die Ethereum Foundation sagte, Nutzer können die Festplattennutzung um etwa 300–500 GB reduzieren, indem sie Pre-Merge-Blockdaten entfernen, wodurch ein Node auf einer 2-TB-Festplatte erreichbar wird.

Gleichzeitig spiegeln Light Clients bereits ein formalisiertes Vertrauensmodell wider, das für ressourcenarme Geräte optimiert ist und sich auf ein Sync-Komitee von 512 Validatoren stützt, die etwa alle 1,1 Tage ausgewählt werden.

Diese Parameter machen Light-Client-Verifizierung im großen Maßstab praktikabel.

Sie konzentrieren jedoch auch die Benutzererfahrung auf die Verfügbarkeit korrekter Daten und gut funktionierende Relays, wenn sich die Bedingungen verschlechtern.

Ethereums längerfristige „Statelessness"-Arbeit zielt darauf ab, die Notwendigkeit für Nodes zu reduzieren, große Zustandsdaten zu halten, während die Blockvalidierung intakt bleibt.

Ethereum.org warnt, dass „Statelessness" eine falsche Bezeichnung ist und schwächere Formen von stärkeren Designs unterscheidet, die Forschung bleiben, einschließlich State Expiry.

Verkle-Bäume sind Teil dieses Plans, weil sie Beweisgrößen reduzieren und als wichtiger Ermöglichungsschritt zur Validierung ohne lokale Speicherung großer Zustände positioniert sind.

Während sich mehr von der Speicherlast nach außen verlagert, entweder zu spezialisierten Historie-Hosts oder anderen Datennetzwerken, wird die Sicherheitsgeschichte weniger darüber, wer alles speichern kann, und mehr darüber, wer unabhängig Korrektheit prüfen und abrufen kann, was benötigt wird, wenn ein Standardpfad fehlschlägt.

Was dies künftig bedeutet

In den nächsten 12–36 Monaten ist die praktische Frage, ob sich die Verifizierung nach außen verbreitet, während Ethereum mehr Speicherlasten externalisiert, oder ob sich Vertrauen um neue Service-Engpässe sammelt.

Ein Weg ist, dass Wallets und Infrastruktur von „Vertraue dem RPC" zu „Verifiziere den Beweis" wechseln, während die Proof-Produktion sich auf eine kleine Gruppe optimierter Stacks konsolidiert, die schwer zu replizieren sind, wodurch die Abhängigkeit von einer Anbieterklasse zu einer anderen verschoben wird.

Ein anderer Weg ist, dass beweisbasierte Verifizierung gewöhnlich wird, mit redundanten Proving-Implementierungen und Tools, die es Nutzern ermöglichen, Anbieter zu wechseln oder lokal zu verifizieren, wenn ein Endpunkt zensiert, sich verschlechtert oder verschwindet, was mit Bemühungen um leichtgewichtige Verifizierungsabläufe übereinstimmt.

Ein dritter Weg ist, dass Pruning und Modularität schneller voranschreiten als Verifizierungs-UX, wodurch Nutzer bei Ausfällen oder Zensurereignissen weniger praktikable Optionen haben.

Das würde die „Berghütte" operativ nur für einen schmalen Teil des Netzwerks real machen.

Buterin rahmte die Hütte als Ethereums BATNA, selten genutzt, aber immer verfügbar, weil die Existenz einer selbstständigen Option die von Vermittlern auferlegten Bedingungen einschränkt.

Er schloss mit dem Argument, dass die Aufrechterhaltung dieser Rückfalloption Teil der Aufrechterhaltung von Ethereum selbst ist.

Der Beitrag Vitalik Buterin gibt seinen größten Designfehler seit 2017 zu – ist Ihr Ethereum also gefährdet? erschien zuerst auf CryptoSlate.