Einleitung: Der Weg zur Verifizierbarkeit

Der Hauptvorteil von Web3 ist die Verifizierbarkeit – Benutzer können überprüfen, wie Systeme tatsächlich funktionieren. Diese Funktion erklärt, warum viele innerhalb und außerhalb der Kryptoindustrie Web3 als einen Schritt hin zu einem transparenteren und verifizierbareren Internet beschreiben.

Im Gegensatz zu Web2-Plattformen wie Facebook oder Instagram, bei denen Algorithmen und Regeln selbst dann undurchsichtig bleiben, wenn sie dokumentiert sind, sind Kryptoprotokolle auf vollständige Überprüfbarkeit ausgelegt. Selbst wenn sie freigegeben werden, können Sie nicht überprüfen, ob die Plattform wie angegeben funktioniert. Dies ist das Gegenteil von Krypto, wo jedes Protokoll so konzipiert ist, dass es so überprüfbar wie möglich ist – oder zumindest wird dies erwartet.

Heute werden wir „The Verge“ erkunden, einen Abschnitt aus Vitaliks kürzlich veröffentlichter sechsteiliger Serie über die Zukunft von Ethereum , um die Schritte zu analysieren, die Ethereum unternimmt, um in Zukunft Verifizierbarkeit, Nachhaltigkeit und Skalierbarkeit zu erreichen. Unter der Überschrift „The Verge“ werden wir diskutieren, wie Blockchain-Architekturen verifizierbarer gemacht werden können, welche Innovationen diese Änderungen auf Protokollebene mit sich bringen und wie sie den Benutzern ein sichereres Ökosystem bieten. Lasst uns beginnen!

Was bedeutet „Überprüfbarkeit“?

Web2-Anwendungen funktionieren wie „Black Boxes“ – Benutzer können nur ihre Eingaben und die daraus resultierenden Ausgaben sehen, haben aber keinen Einblick in die tatsächliche Funktionsweise der Anwendung. Im Gegensatz dazu machen Kryptowährungsprotokolle ihren Quellcode normalerweise öffentlich zugänglich oder haben zumindest Pläne, dies zu tun. Diese Transparenz dient zwei Zwecken: Sie ermöglicht es Benutzern, bei Bedarf direkt mit dem Code des Protokolls zu interagieren, und sie hilft ihnen, genau zu verstehen, wie das System funktioniert und welche Regeln es regelt.

„Dezentralisieren Sie, was Sie können, und verifizieren Sie den Rest.“

Durch Verifizierbarkeit wird sichergestellt, dass Systeme nachvollziehbar sind, und in vielen Fällen wird garantiert, dass Protokolle wie vorgesehen funktionieren. Dieses Prinzip unterstreicht, wie wichtig es ist, die Zentralisierung auf ein Minimum zu reduzieren, da sie häufig zu undurchsichtigen, nicht nachvollziehbaren Strukturen führt, in denen Benutzer Vorgänge nicht überprüfen können. Stattdessen sollten wir versuchen, so weit wie möglich zu dezentralisieren und die verbleibenden Elemente nachprüfbar und nachvollziehbar zu machen, wenn eine Dezentralisierung nicht möglich ist.

Die Ethereum-Community scheint diese Ansicht zu teilen, da die Roadmap einen Meilenstein (genannt „The Verge“) enthält, der darauf abzielt, Ethereum verifizierbarer zu machen. Bevor wir uns jedoch mit The Verge befassen, müssen wir verstehen, welche Aspekte von Blockchains verifiziert werden sollten und welche Teile aus Sicht der Benutzer entscheidend sind.

Blockchains fungieren im Wesentlichen als globale Uhren. In einem verteilten Netzwerk mit etwa 10.000 Computern kann es eine beträchtliche Zeit dauern, bis eine Transaktion vom ursprünglichen Knoten zu allen anderen Knoten gelangt. Aus diesem Grund können Knoten im gesamten Netzwerk die genaue Reihenfolge der Transaktionen nicht bestimmen – ob eine vor oder nach der anderen eintrifft –, da sie nur ihre eigenen subjektiven Perspektiven haben.

Da die Reihenfolge der Transaktionen wichtig ist, verwenden Blockchain-Netzwerke spezielle Methoden, sogenannte „ Konsensalgorithmen “, um sicherzustellen, dass die Knoten synchronisiert bleiben und die Transaktionssequenzen in derselben Reihenfolge verarbeiten. Obwohl die Knoten die Transaktionsreihenfolge nicht global bestimmen können, ermöglichen Konsensmechanismen allen Knoten, sich auf dieselbe Reihenfolge zu einigen, sodass das Netzwerk als ein einziger, zusammenhängender Computer funktionieren kann.

Neben der Konsensebene gibt es auch die Ausführungsebene, die in jeder Blockchain vorhanden ist. Die Ausführungsebene wird durch die Transaktionen geformt, die Benutzer ausführen möchten. Sobald Transaktionen erfolgreich per Konsens angeordnet wurden, muss jede Transaktion auf den aktuellen Status auf der Ausführungsebene angewendet werden. Wenn Sie sich fragen: „Wie ist der Status?“, haben Sie Blockchains wahrscheinlich schon mit Datenbanken verglichen – oder genauer gesagt mit der Datenbank einer Bank, da Blockchains, wie Banken, Aufzeichnungen über die Kontostände aller Personen führen.

Wenn Sie 100 $ im Status „S“ haben und 10 $ an jemand anderen senden möchten, beträgt Ihr Guthaben im nächsten Status „S+1“ 90 $. Diesen Prozess der Anwendung von Transaktionen zum Wechsel von einem Status in einen anderen nennen wir eine STF (State Transition Function) .

Bei Bitcoin beschränkt sich das STF hauptsächlich auf Änderungen des Kontostands, was es relativ einfach macht. Im Gegensatz zu Bitcoin ist das STF von Ethereum jedoch viel komplexer, da Ethereum eine vollständig programmierbare Blockchain mit einer Ausführungsschicht ist, die Code ausführen kann.

In einer Blockchain gibt es drei grundlegende Komponenten, die Sie überprüfen müssen oder können:

1. Status : Sie möchten möglicherweise Daten aus der Blockchain lesen, haben aber keinen Zugriff auf den Status, da Sie keinen vollständigen Knoten ausführen. Daher fordern Sie die Daten über einen RPC-Anbieter (Remote Procedure Call) wie Alchemy oder Infura an. Sie müssen jedoch überprüfen, ob die Daten vom RPC-Anbieter nicht manipuliert wurden.
2. Ausführung : Wie bereits erwähnt, verwenden Blockchains ein STF. Sie müssen überprüfen, ob der Statusübergang korrekt ausgeführt wurde – nicht für jede Transaktion, sondern für jeden Block einzeln.
3. Konsens : Drittanbieter wie RPCs können Ihnen gültige Blöcke bereitstellen, die noch nicht in die Blockchain aufgenommen wurden. Daher müssen Sie überprüfen, ob diese Blöcke durch Konsens akzeptiert und zur Blockchain hinzugefügt wurden.

ICH

Wenn Ihnen das verwirrend oder unklar erscheint, machen Sie sich keine Sorgen. Wir werden jeden dieser Aspekte im Detail durchgehen. Beginnen wir damit, wie Sie den Blockchain- Status überprüfen können!

Wie kann der Status der Blockchain überprüft werden?

Der „Zustand“ von Ethereum bezieht sich auf den Datensatz, der zu einem beliebigen Zeitpunkt in der Blockchain gespeichert ist. Dazu gehören Kontostände (Vertragskonten und extern gehaltene Konten oder EOAs), Smart-Contract-Code, Vertragsspeicher und mehr. Ethereum ist eine zustandsbasierte Maschine, da Transaktionen, die in der Ethereum Virtual Machine (EVM) verarbeitet werden, den vorherigen Zustand ändern und einen neuen Zustand erzeugen.

Jeder Ethereum-Block enthält einen Wert, der den aktuellen Zustand des Netzwerks nach diesem Block zusammenfasst: den stateRoot . Dieser Wert ist eine kompakte Darstellung des gesamten Ethereum-Zustands, bestehend aus einem 64-stelligen Hash.

Da jede neue Transaktion den Status ändert, wird der im nachfolgenden Block aufgezeichnete StateRoot entsprechend aktualisiert. Um diesen Wert zu berechnen, verwenden Ethereum-Validatoren eine Kombination aus der Keccak-Hash-Funktion und einer Datenstruktur namens Merkle Tree, um verschiedene Teile des Status zu organisieren und zusammenzufassen.

Hash-Funktionen sind Einwegfunktionen, die eine Eingabe in eine Ausgabe mit fester Länge umwandeln. In Ethereum werden Hash-Funktionen wie Keccak verwendet, um Zusammenfassungen von Daten zu generieren, die als eine Art Fingerabdruck für die Eingabe dienen. Hash-Funktionen haben vier grundlegende Eigenschaften:

1. Determinismus : Die gleiche Eingabe führt immer zur gleichen Ausgabe.
2. Feste Ausgabelänge : Unabhängig von der Länge der Eingabe ist die Ausgabelänge immer fest.
3. Einwegeigenschaft : Es ist praktisch unmöglich, aus der Ausgabe die ursprüngliche Eingabe abzuleiten.
4. Eindeutigkeit : Schon eine kleine Änderung der Eingabe erzeugt eine völlig andere Ausgabe. Somit wird einer bestimmten Eingabe eine praktisch eindeutige Ausgabe zugeordnet.

Dank dieser Eigenschaften können Ethereum-Validatoren die STF (State Transition Function) für jeden Block ausführen – alle Transaktionen im Block ausführen und auf den Status anwenden – und dann überprüfen, ob der im Block angegebene Status mit dem nach der STF erreichten Status übereinstimmt. Dieser Prozess stellt sicher, dass der Antragsteller des Blocks ehrlich gehandelt hat, und ist somit eine der Hauptaufgaben der Validatoren.

Ethereum-Validatoren hashen jedoch nicht den gesamten Status direkt, um eine Zusammenfassung zu erhalten. Aufgrund der Einwegnatur von Hash-Funktionen würde das direkte Hashen des Status die Verifizierbarkeit eliminieren, da die einzige Möglichkeit, den Hash zu reproduzieren, darin bestünde, den gesamten Status zu besitzen.

Da der Status von Ethereum mehrere Terabyte groß ist, ist es unpraktisch, den gesamten Status auf alltäglichen Geräten wie Telefonen oder PCs zu speichern. Aus diesem Grund verwendet Ethereum eine Merkle-Baumstruktur zur Berechnung des StateRoot, wodurch die Verifizierbarkeit des Status so weit wie möglich erhalten bleibt.

Ein Merkle-Baum ist eine kryptografische Datenstruktur, mit der die Integrität und Richtigkeit von Daten sicher und effizient überprüft werden kann. Merkle-Bäume basieren auf Hash-Funktionen und organisieren die Hashes eines Datensatzes hierarchisch, wodurch die Überprüfung der Integrität und Richtigkeit dieser Daten ermöglicht wird. Diese Baumstruktur besteht aus drei Knotentypen:

1. Blattknoten : Diese Knoten enthalten die Hashes einzelner Datenstücke und befinden sich auf der untersten Ebene des Baums. Jeder Blattknoten stellt den Hash eines bestimmten Datenstücks im Merkle-Baum dar.
2. Verzweigungsknoten : Diese Knoten enthalten die kombinierten Hashes ihrer untergeordneten Knoten. Beispielsweise werden in einem binären Merkle-Baum (wobei N = 2) die Hashes zweier untergeordneter Knoten verkettet und erneut gehasht, um den Hash eines Verzweigungsknotens auf einer höheren Ebene zu erzeugen.
3. Stammknoten : Der Stammknoten befindet sich auf der obersten Ebene des Merkle-Baums und stellt die kryptografische Zusammenfassung des gesamten Baums dar. Dieser Knoten wird verwendet, um die Integrität und Richtigkeit aller Daten innerhalb des Baums zu überprüfen.

Wenn Sie sich fragen, wie man einen solchen Baum erstellt, sind dazu nur zwei einfache Schritte nötig:

• Erstellung von Blattknoten : Jedes Datenelement wird durch eine Hash-Funktion verarbeitet und die resultierenden Hashes bilden die Blattknoten. Diese Knoten befinden sich auf der untersten Ebene des Baums und stellen die kryptografische Zusammenfassung der Daten dar.

• Kombinieren und hashen : Die Hashes der Blattknoten werden gruppiert (z. B. paarweise) und kombiniert, gefolgt vom Hashen. Dieser Vorgang erstellt Zweigknoten auf der nächsten Ebene. Derselbe Vorgang wird für die Zweigknoten wiederholt, bis nur noch ein einziger Hash übrig bleibt.

Der endgültige Hash, der oben im Baum erhalten wird, wird als Merkle-Wurzel bezeichnet. Die Merkle-Wurzel stellt die kryptografische Zusammenfassung des gesamten Baums dar und ermöglicht eine sichere Überprüfung der Datenintegrität.

Wie verwenden wir Merkle-Wurzeln, um den Status von Ethereum zu überprüfen?

Merkle -Beweise ermöglichen dem Verifier, bestimmte Daten effizient zu validieren, indem sie eine Reihe von Hash-Werten bereitstellen, die einen Pfad von den Zieldaten (einem Blattknoten) zur im Blockheader gespeicherten Merkle-Wurzel erstellen. Diese Kette von Zwischen-Hashes ermöglicht es dem Verifier, die Authentizität der Daten zu bestätigen, ohne den gesamten Status hashen zu müssen.

Ausgehend vom spezifischen Datenpunkt kombiniert der Verifier diesen mit jedem im Merkle Proof bereitgestellten „Geschwister“-Hash und hasht sie Schritt für Schritt den Baum hinauf. Dieser Prozess wird fortgesetzt, bis ein einzelner Hash erstellt ist. Wenn dieser berechnete Hash mit der gespeicherten Merkle-Wurzel übereinstimmt, gelten die Daten als gültig; andernfalls kann der Verifier feststellen, dass die Daten nicht dem behaupteten Zustand entsprechen.

Beispiel: Überprüfen eines Datenpunkts mit Merkle-Beweis

Nehmen wir an, wir haben Daten Nr. 4 von einem RPC erhalten und möchten deren Authentizität mithilfe eines Merkle-Beweises überprüfen. Dazu würde der RPC eine Reihe von Hash-Werten entlang des Pfads bereitstellen, der zum Erreichen der Merkle-Wurzel erforderlich ist. Für Daten 4 würden diese Geschwister-Hashes Hash Nr. 3, Hash Nr. 12 und Hash Nr. 5678 umfassen.

1. Beginnen Sie mit Daten 4 : Zuerst hashen wir Daten Nr. 4, um Hash Nr. 4 zu erhalten.
2. Mit Geschwistern kombinieren : Dann kombinieren wir Hash Nr. 4 mit Hash Nr. 3 (seinem Geschwister auf Blattebene) und hashen sie zusammen, um Hash Nr. 34 zu erzeugen.
3. Im Baum nach oben gehen : Als Nächstes nehmen wir Hash Nr. 34, kombinieren ihn mit Hash Nr. 12 (seinem Geschwister auf der nächsten Ebene) und hashen sie, um Hash Nr. 1234 zu erhalten.
4. Letzter Schritt : Zum Schluss kombinieren wir Hash #1234 mit Hash #5678 (dem letzten bereitgestellten Geschwister) und hashen sie zusammen. Der resultierende Hash sollte mit der im Blockheader gespeicherten Merkle-Wurzel (Hash #12345678) übereinstimmen.

Wenn die berechnete Merkle-Wurzel mit der Zustandswurzel im Block übereinstimmt, bestätigen wir, dass Daten Nr. 4 in diesem Zustand tatsächlich gültig sind. Wenn nicht, wissen wir, dass die Daten nicht zum beanspruchten Zustand gehören, was auf eine mögliche Manipulation hinweist. Wie Sie sehen, kann der Beweiser beweisen, dass Daten Nr. 4 im Zustand vorhanden sind und während ihrer Reise nicht verändert wurden, ohne die Hashes aller Daten bereitzustellen oder den Prüfer den gesamten Merkle-Baum von Grund auf neu erstellen zu müssen – und zwar mit nur drei Hashes. Dies ist der Hauptgrund, warum Merkle-Beweise als effizient gelten.

Merkle-Bäume sind zweifellos wirksam bei der sicheren und effizienten Datenüberprüfung in großen Blockchain-Systemen wie Ethereum, aber sind sie wirklich effizient genug? Um diese Frage zu beantworten, müssen wir analysieren, wie sich Leistung und Größe von Merkle-Bäumen auf die Beweiser-Verifizierer-Beziehung auswirken.

Zwei Schlüsselfaktoren, die die Leistung von Merkle-Bäumen beeinflussen

1. Verzweigungsfaktor : Die Anzahl der untergeordneten Knoten pro Zweig.
2. Gesamtdatengröße : Die Größe des Datensatzes, der im Baum dargestellt wird.

Die Wirkung des Verzweigungsfaktors:

Um die Auswirkungen besser zu verstehen, verwenden wir ein Beispiel. Der Verzweigungsfaktor bestimmt, wie viele Zweige von jedem Knoten im Baum ausgehen.

• Kleiner Verzweigungsfaktor (z. B. binärer Merkle-Baum) : Wenn ein binärer Merkle-Baum (Verzweigungsfaktor 2) verwendet wird, ist die Beweisgröße sehr klein, was den Verifizierungsprozess für den Verifizierer effizienter macht. Mit nur zwei Zweigen an jedem Knoten muss der Verifizierer nur einen Geschwister-Hash pro Ebene verarbeiten. Dies beschleunigt die Verifizierung und reduziert die Rechenlast. Der reduzierte Verzweigungsfaktor erhöht jedoch die Höhe des Baums, was mehr Hash-Operationen während der Baumkonstruktion erfordert, was für die Validierer eine Belastung darstellen kann.
• Größerer Verzweigungsfaktor (z. B. 4) : Ein größerer Verzweigungsfaktor (z. B. 4) reduziert die Höhe des Baums und erzeugt eine kürzere und breitere Struktur. Dadurch können Full Nodes den Baum schneller konstruieren, da weniger Hash-Operationen erforderlich sind. Für den Verifier erhöht dies jedoch die Anzahl der Geschwister-Hashes, die er auf jeder Ebene verarbeiten muss, was zu einer größeren Beweisgröße führt. Mehr Hashes pro Verifizierungsschritt bedeuten auch höhere Rechen- und Bandbreitenkosten für den Verifier, wodurch die Belastung effektiv von den Validierern auf die Verifier verlagert wird.

Der Effekt der Gesamtdatengröße

Da die Ethereum-Blockchain wächst und jede neue Transaktion, jeder neue Vertrag oder jede neue Benutzerinteraktion den Datensatz erweitert, muss auch der Merkle-Baum erweitert werden. Dieses Wachstum erhöht nicht nur die Größe des Baums, sondern wirkt sich auch auf die Beweisgröße und die Verifizierungszeit aus.

• Vollständige Knoten müssen den wachsenden Datensatz regelmäßig verarbeiten und aktualisieren, um den Merkle-Baum zu pflegen.
• Die Prüfer wiederum müssen mit zunehmender Datenmenge längere und komplexere Nachweise validieren, was zusätzliche Verarbeitungszeit und Bandbreite erfordert.

Diese wachsende Datenmenge erhöht die Anforderungen an Full Nodes und Verifier und erschwert eine effiziente Skalierung des Netzwerks. Zusammenfassend lässt sich sagen, dass Merkle Trees zwar ein gewisses Maß an Effizienz bieten, aber keine optimale Lösung für Ethereums kontinuierlich wachsenden Datensatz darstellen. Aus diesem Grund zielt Ethereum während der Phase „The Verge“ darauf ab, Merkle Trees durch eine effizientere Struktur namens Verkle Trees zu ersetzen. Verkle Trees haben das Potenzial, kleinere Beweisgrößen bei gleichbleibender Sicherheit zu liefern, wodurch der Verifizierungsprozess sowohl für Provers als auch für Verifier nachhaltiger und skalierbarer wird.

The Verge: Revolutionierung der Verifizierbarkeit in Ethereum

The Verge wurde als Meilenstein in Ethereums Roadmap entwickelt, um die Verifizierbarkeit zu verbessern, die dezentrale Struktur der Blockchain zu stärken und die Netzwerksicherheit zu erhöhen. Eines der Hauptziele des Ethereum-Netzwerks ist es, es jedem zu ermöglichen, einfach einen Validator auszuführen, um die Kette zu verifizieren. So entsteht eine Struktur, an der jeder teilnehmen kann, ohne dass es eine Zentralisierung gibt.

Die Zugänglichkeit dieses Verifizierungsprozesses ist eines der Hauptmerkmale, das Blockchains von zentralisierten Systemen unterscheidet. Während zentralisierte Systeme keine Verifizierungsmöglichkeiten bieten, liegt die Korrektheit einer Blockchain vollständig in den Händen ihrer Benutzer. Um diese Sicherheit jedoch aufrechtzuerhalten, muss die Ausführung eines Validators für alle zugänglich sein – eine Herausforderung, die unter dem aktuellen System aufgrund der Speicher- und Rechenanforderungen eingeschränkt ist.

Seit der Umstellung auf ein Proof-of-Stake -Konsensmodell mit The Merge haben Ethereum-Validatoren zwei Hauptaufgaben:

1. Sicherstellung des Konsenses : Unterstützung der ordnungsgemäßen Funktionsweise sowohl probabilistischer als auch deterministischer Konsensprotokolle und Anwendung des Fork-Choice-Algorithmus.
2. Überprüfen der Blockgenauigkeit : Nachdem die Transaktionen in einem Block ausgeführt wurden, wird überprüft, ob die Wurzel des resultierenden Zustandsbaums mit der vom Antragsteller deklarierten Zustandswurzel übereinstimmt.

Um die zweite Verantwortung zu erfüllen, müssen Validierer Zugriff auf den Status vor dem Block haben. Dadurch können sie die Transaktionen des Blocks ausführen und den nachfolgenden Status ableiten. Diese Anforderung stellt jedoch eine große Belastung für Validierer dar, da sie erhebliche Speicheranforderungen bewältigen müssen.

Obwohl Ethereum so konzipiert ist, dass es praktikabel ist und die Speicherkosten weltweit sinken, geht es weniger um die Kosten als vielmehr um die Abhängigkeit von spezieller Hardware für Validierer. The Verge möchte diese Herausforderung bewältigen, indem es eine Infrastruktur schafft, mit der eine vollständige Verifizierung auch auf Geräten mit begrenztem Speicher wie Mobiltelefonen, Browser-Wallets und sogar Smartwatches durchgeführt werden kann, sodass Validierer auf diesen Geräten ausgeführt werden können.

Erster Schritt zur Verifizierbarkeit: Effiziente Zustandsverifizierung

Der Übergang zu Verkle Trees ist ein wichtiger Teil dieses Prozesses. Zunächst konzentrierte sich The Verge darauf, die Merkle Tree-Strukturen von Ethereum durch Verkle Trees zu ersetzen. Der Hauptgrund für die Einführung von Verkle Trees ist, dass Merkle Trees ein erhebliches Hindernis für die Verifizierbarkeit von Ethereum darstellen. Während Merkle Trees und ihre Beweise in normalen Szenarien effizient funktionieren können, verschlechtert sich ihre Leistung im schlimmsten Fall drastisch.

Laut Vitaliks Berechnungen beträgt die durchschnittliche Proofgröße etwa 4 KB , was überschaubar klingt. Im schlimmsten Fall kann die Proofgröße jedoch auf 330 MB anwachsen. Ja, Sie haben richtig gelesen – 330 MB.

Die extreme Ineffizienz der Merkle Trees von Ethereum im schlimmsten Fall hat zwei Hauptgründe:

1. Verwendung von Hexary Trees : Ethereum verwendet derzeit Merkle Trees mit einem Verzweigungsfaktor von 16. Dies bedeutet, dass zur Überprüfung eines einzelnen Knotens die Bereitstellung der verbleibenden 15 Hashes im Zweig erforderlich ist. Angesichts der Größe des Ethereum-Zustands und der Anzahl der Zweige stellt dies im schlimmsten Fall eine erhebliche Belastung dar.

2. Nicht-Merkelisierung des Codes : Anstatt den Vertragscode in die Baumstruktur einzubinden, hasht Ethereum den Code einfach und verwendet den resultierenden Wert als Knoten. Wenn man bedenkt, dass die maximale Größe eines Vertrags 24 KB beträgt, stellt dieser Ansatz eine erhebliche Belastung für die Erreichung der vollständigen Verifizierbarkeit dar.

Die Beweisgröße ist direkt proportional zum Verzweigungsfaktor. Eine Reduzierung des Verzweigungsfaktors verringert die Beweisgröße. Um diese Probleme zu lösen und Worst-Case-Szenarien zu verbessern, könnte Ethereum von Hexary Trees zu Binary Merkle Trees wechseln und mit der Merklisierung von Vertragscodes beginnen. Wenn der Verzweigungsfaktor in Ethereum von 16 auf 2 reduziert und Vertragscodes ebenfalls merklisiert werden, könnte die maximale Beweisgröße auf 10 MB schrumpfen.

Obwohl dies eine erhebliche Verbesserung darstellt, ist es wichtig zu beachten, dass diese Kosten für die Überprüfung nur eines einzigen Datenelements anfallen. Selbst eine einfache Transaktion, die auf mehrere Datenelemente zugreift, würde umfangreichere Nachweise erfordern. Angesichts der Anzahl der Transaktionen pro Block und des kontinuierlich wachsenden Status von Ethereum ist diese Lösung zwar besser, aber immer noch nicht vollständig umsetzbar.

Aus diesen Gründen hat die Ethereum-Community zwei unterschiedliche Lösungen zur Lösung des Problems vorgeschlagen:

1. Verkle-Bäume
2. STARK-Beweise + binäre Merkle-Bäume

Verkle-Bäume und Vektorverpflichtungen

Verkle Trees sind, wie der Name schon sagt, Baumstrukturen, die Merkle Trees ähneln. Der größte Unterschied liegt jedoch in der Effizienz, die sie bei Verifizierungsprozessen bieten. Wenn bei Merkle Trees ein Zweig 16 Datenelemente enthält und wir nur eines davon verifizieren möchten, muss auch eine Hash-Kette bereitgestellt werden, die die anderen 15 Elemente abdeckt. Dies erhöht den Rechenaufwand bei der Verifizierung erheblich und führt zu großen Beweisgrößen.

Im Gegensatz dazu verwenden Verkle Trees eine spezielle Struktur, die als „ Elliptic Curve-based Vector Commitments “ bekannt ist, genauer gesagt ein auf dem Inner Product Argument (IPA) basierendes Vector Commitment. Ein Vektor ist im Wesentlichen eine Liste von Datenelementen, die in einer bestimmten Reihenfolge angeordnet sind. Man kann sich den Zustand von Ethereum als einen Vektor vorstellen: eine Struktur, in der zahlreiche Datenstücke in einer bestimmten Reihenfolge gespeichert sind, wobei jedes Element entscheidend ist. Dieser Zustand umfasst verschiedene Datenkomponenten wie Adressen, Vertragscodes und Speicherinformationen, wobei die Reihenfolge dieser Elemente eine entscheidende Rolle beim Zugriff und bei der Überprüfung spielt.

Vector Commitments sind kryptografische Methoden, die zum Nachweis und zur Verifizierung von Datenelementen in einem Datensatz verwendet werden. Diese Methoden ermöglichen die gleichzeitige Verifizierung der Existenz und Reihenfolge aller Elemente in einem Datensatz. Beispielsweise können Merkle-Beweise , die in Merkle-Bäumen verwendet werden, auch als eine Form von Vector Commitment betrachtet werden. Während Merkle-Bäume alle relevanten Hash-Ketten erfordern, um ein Element zu verifizieren, beweist die Struktur von Natur aus, dass alle Elemente eines Vektors in einer bestimmten Reihenfolge verbunden sind.

Im Gegensatz zu Merkle-Bäumen verwenden Verkle-Bäume auf elliptischen Kurven basierende Vektorverpflichtungen , die zwei wesentliche Vorteile bieten:

• Auf elliptischen Kurven basierende Vektorverpflichtungen machen Details anderer Elemente als die zu verifizierenden Daten überflüssig . In Merkle-Bäumen mit einem Verzweigungsfaktor von 16 erfordert die Verifizierung eines einzelnen Zweigs die Bereitstellung der anderen 15 Hashes. Angesichts der enormen Größe des Ethereum-Zustands, der viele Zweige umfasst, führt dies zu einer erheblichen Ineffizienz. Auf elliptischen Kurven basierende Vektorverpflichtungen beseitigen jedoch diese Komplexität und ermöglichen eine Verifizierung mit weniger Daten- und Rechenaufwand.
• Durch Mehrfachbeweise können die durch elliptische Kurven-basierte Vektorverpflichtungen generierten Beweise in einen einzigen Beweis konstanter Größe komprimiert werden . Der Zustand von Ethereum ist nicht nur groß, sondern wächst auch kontinuierlich, was bedeutet, dass die Anzahl der Zweige, die überprüft werden müssen, um auf die Merkle-Wurzel zuzugreifen, mit der Zeit zunimmt. Mit Verkle Trees können wir jedoch die Beweise für jeden Zweig in einen einzigen Beweis konstanter Größe „komprimieren“, indem wir die in Dankrad Feists Artikel beschriebene Methode verwenden. Dies ermöglicht es Verifizierern, den gesamten Baum mit einem kleinen Beweis zu validieren, anstatt jeden Zweig einzeln zu überprüfen. Dies bedeutet auch, dass Verkle Trees vom Wachstum des Zustands von Ethereum nicht betroffen sind.

Diese Merkmale der auf elliptischen Kurven basierenden Vektorverpflichtungen reduzieren die für die Verifizierung erforderliche Datenmenge erheblich, sodass Verkle Trees selbst im schlimmsten Fall kleine Beweise mit konstanter Größe erstellen kann. Dies minimiert den Datenaufwand und die Verifizierungszeiten und verbessert die Effizienz großer Netzwerke wie Ethereum. Infolgedessen ermöglicht die Verwendung von auf elliptischen Kurven basierenden Vektorverpflichtungen in Verkle Trees eine überschaubarere und effizientere Handhabung des expandierenden Zustands von Ethereum.

Wie alle Innovationen haben auch Verkle Trees ihre Grenzen. Einer ihrer Hauptnachteile ist, dass sie auf elliptischer Kurvenkryptographie basieren, die für Quantencomputer anfällig ist. Quantencomputer verfügen über eine weitaus höhere Rechenleistung als klassische Methoden und stellen daher eine erhebliche Bedrohung für auf elliptischen Kurven basierende kryptographische Protokolle dar. Quantenalgorithmen könnten diese kryptographischen Systeme möglicherweise zerstören oder schwächen, was Bedenken hinsichtlich der langfristigen Sicherheit von Verkle Trees aufkommen lässt.

Aus diesem Grund bieten Verkle Trees zwar eine vielversprechende Lösung für das Problem der Zustandslosigkeit, sind aber nicht die ultimative Lösung. Allerdings haben Persönlichkeiten wie Dankrad Feist betont, dass die Integration quantenresistenter Kryptografie in Ethereum zwar sorgfältig überlegt werden muss, es aber erwähnenswert ist, dass die derzeit für Blobs in Ethereum verwendeten KZG-Verpflichtungen ebenfalls nicht quantenresistent sind. Daher können Verkle Trees als Zwischenlösung dienen und dem Netzwerk zusätzliche Zeit geben, um robustere Alternativen zu entwickeln.

STARK-Beweise + Binäre Merkle-Bäume

Verkle Trees bieten im Vergleich zu Merkle Trees kleinere Beweisgrößen und effiziente Verifizierungsprozesse, wodurch es einfacher wird, den ständig wachsenden Zustand von Ethereum zu verwalten. Dank elliptischer kurvenbasierter Vektor-Commitments können groß angelegte Beweise mit deutlich weniger Daten generiert werden. Trotz ihrer beeindruckenden Vorteile sind Verkle Trees aufgrund ihrer Anfälligkeit gegenüber Quantencomputern jedoch nur eine vorübergehende Lösung.

Während die Ethereum-Community Verkle Trees als kurzfristiges Mittel zum Zeitgewinn betrachtet, liegt der langfristige Fokus auf dem Übergang zu quantenresistenten Lösungen . Hier stellen STARK Proof s und Binary Merkle Trees eine starke Alternative zum Aufbau einer robusteren Verifizierbarkeitsinfrastruktur für die Zukunft dar.

Im Zustandsüberprüfungsprozess von Ethereum kann der Verzweigungsfaktor von Merkle-Bäumen durch die Verwendung binärer Merkle-Bäume (von 16 auf 2) reduziert werden. Diese Änderung ist ein entscheidender Schritt, um die Beweisgröße zu reduzieren und die Überprüfungsprozesse effizienter zu gestalten. Selbst im schlimmsten Fall können die Beweisgrößen jedoch immer noch 10 MB erreichen, was beträchtlich ist. Hier kommen STARK-Beweise ins Spiel, die diese großen binären Merkle-Beweise auf nur 100-300 kB komprimieren.

Diese Optimierung ist besonders wichtig, wenn man die Einschränkungen beim Betrieb von Validatoren auf Light-Clients oder Geräten mit eingeschränkter Hardware berücksichtigt, insbesondere wenn man berücksichtigt, dass die durchschnittlichen globalen Download- und Upload-Geschwindigkeiten bei Mobilgeräten etwa 7,625 MB/s bzw. 1,5 MB/s betragen. Benutzer können Transaktionen mit kleinen, tragbaren Nachweisen verifizieren, ohne Zugriff auf den vollständigen Status zu benötigen, und Validatoren können Blockverifizierungsaufgaben durchführen, ohne den gesamten Status zu speichern.

Dieser Ansatz mit doppeltem Nutzen reduziert sowohl die Bandbreiten- als auch die Speicheranforderungen für Validierer und beschleunigt gleichzeitig die Verifizierung – drei wichtige Verbesserungen, die Ethereums Vision der Skalierbarkeit direkt unterstützen.

Zentrale Herausforderungen für STARK-Beweise

1. Hohe Rechenlast für Beweiser : Der Prozess der Generierung von STARK-Beweisen ist rechenintensiv, insbesondere auf der Beweiserseite, was die Betriebskosten erhöhen kann.
2. Ineffizienz bei Beweisen kleiner Datenmengen: STARK-Beweise eignen sich zwar hervorragend für die Verarbeitung großer Datensätze, sind jedoch weniger effizient beim Beweisen kleiner Datenmengen, was ihre Anwendung in bestimmten Szenarien behindern kann. Bei Programmen mit kleineren Schritten oder Datensätzen kann die relativ große Beweisgröße von STARKs sie weniger praktisch oder kosteneffizient machen.

Quantensicherheit hat ihren Preis: Rechenlast auf der Prover-Seite

Der Merkle-Proof eines Blocks kann etwa 330.000 Hashes enthalten, und im schlimmsten Fall kann diese Zahl auf 660.000 steigen. In solchen Fällen müsste ein STARK-Proof etwa 200.000 Hashes pro Sekunde verarbeiten. Hier kommen zk-freundliche Hash-Funktionen wie Poseidon ins Spiel, die speziell für STARK-Proofs optimiert sind, um diese Belastung zu reduzieren.

Poseidon ist so konzipiert, dass es im Vergleich zu herkömmlichen Hash-Algorithmen wie SHA256 und Keccak nahtloser mit ZK-Proofs funktioniert. Der Hauptgrund für diese Kompatibilität liegt in der Funktionsweise herkömmlicher Hash-Algorithmen: Sie verarbeiten Eingaben als Binärdaten (0 und 1).

Auf der anderen Seite arbeiten ZK-Beweise mit Primzahlen, also mathematischen Strukturen, die grundlegend unterschiedlich sind. Diese Situation ist analog zu Computern, die im Binärsystem arbeiten, während Menschen im Alltag ein Dezimalsystem verwenden. Die Übersetzung bitbasierter Daten in ZK-kompatible Formate ist mit einem erheblichen Rechenaufwand verbunden. Poseidon löst dieses Problem, indem es nativ innerhalb von Primzahlen arbeitet und so die Integration mit ZK-Beweisen dramatisch beschleunigt.

Da Poseidon jedoch eine relativ neue Hash-Funktion ist, erfordert sie eine umfassendere Sicherheitsanalyse, um das gleiche Vertrauensniveau wie traditionelle Hash-Funktionen wie SHA256 und Keccak zu erreichen. Zu diesem Zweck laden Initiativen wie die von der Ethereum Foundation ins Leben gerufene Poseidon Cryptanalysis Initiative Experten ein, die Sicherheit von Poseidon rigoros zu testen und zu analysieren, um sicherzustellen, dass es der Prüfung durch Gegner standhält und zu einem robusten Standard für kryptografische Anwendungen wird. Andererseits wurden ältere Funktionen wie SHA256 und Keccak bereits umfassend getestet und haben eine nachgewiesene Sicherheitsbilanz, sind jedoch nicht ZK-freundlich, was bei Verwendung mit STARK-Beweisen zu Leistungseinbußen führt.

Beispielsweise können STARK-Beweise mit diesen traditionellen Hash-Funktionen derzeit nur 10.000 bis 30.000 Hashes verarbeiten. Glücklicherweise deuten Fortschritte in der STARK-Technologie darauf hin, dass dieser Durchsatz bald auf 100.000 bis 200.000 Hashes steigen könnte, was ihre Effizienz deutlich verbessern würde.

Die Ineffizienz von STARKs beim Nachweis kleiner Datenmengen

Während STARK-Beweise bei großen Datensätzen durch Skalierbarkeit und Transparenz überzeugen, weisen sie bei der Arbeit mit kleinen und zahlreichen Datenelementen Einschränkungen auf. In diesen Szenarien sind die zu beweisenden Daten oft klein, aber die Notwendigkeit mehrerer Beweise bleibt unverändert. Beispiele:

1. Validierung von Transaktionen nach AA : Mit Account Abstraction (AA) können Wallets auf Vertragscode verweisen und Schritte wie Nonce und Signaturüberprüfung umgehen oder anpassen, die derzeit in Ethereum obligatorisch sind. Diese Flexibilität bei der Validierung erfordert jedoch die Überprüfung des Vertragscodes oder anderer zugehöriger Daten im Status, um die Gültigkeit der Transaktion nachzuweisen.
2. Light-Client-RPC-Aufrufe : Light-Clients fragen Statusdaten vom Netzwerk ab (z. B. während einer eth_call-Anforderung), ohne einen vollständigen Knoten auszuführen. Um die Richtigkeit dieses Status zu gewährleisten, müssen Beweise die abgefragten Daten unterstützen und bestätigen, dass sie mit dem aktuellen Status des Netzwerks übereinstimmen.
3. Inklusionslisten : Kleinere Validierer können Inklusionslistenmechanismen verwenden, um sicherzustellen, dass Transaktionen im nächsten Block enthalten sind, wodurch der Einfluss mächtiger Blockproduzenten eingeschränkt wird. Um die Aufnahme dieser Transaktionen zu validieren, muss jedoch ihre Richtigkeit überprüft werden.

In solchen Anwendungsfällen bieten STARK-Beweise kaum Vorteile. STARKs, die auf Skalierbarkeit abzielen (wie durch das „S“ in ihrem Namen hervorgehoben), funktionieren bei großen Datensätzen gut, haben aber Probleme mit kleinen Datenszenarien. Im Gegensatz dazu konzentrieren sich SNARKs , die auf Prägnanz ausgelegt sind (wie durch das „S“ in ihrem Namen hervorgehoben), auf die Minimierung der Beweisgröße und bieten klare Vorteile in Umgebungen mit Bandbreiten- oder Speicherbeschränkungen.

STARK-Beweise sind typischerweise 40–50 KB groß, also etwa 175-mal größer als SNARK-Beweise, die nur 288 Byte groß sind. Dieser Größenunterschied erhöht sowohl die Verifizierungszeit als auch die Netzwerkkosten. Der Hauptgrund für die größeren Beweise von STARK ist ihre Abhängigkeit von Transparenz und polynomischen Verpflichtungen, um Skalierbarkeit zu gewährleisten, was in Szenarien mit kleinen Datenmengen zu Leistungseinbußen führt. In solchen Fällen könnten schnellere und platzsparendere Methoden wie Merkle-Beweise praktischer sein. Merkle-Beweise bieten niedrige Rechenkosten und schnelle Aktualisierungen, was sie für diese Situationen geeignet macht.

Wie in der Tabelle zusammengefasst, stehen für Ethereum vier mögliche Pfade zur Auswahl:

Verkle-Bäume

1. Verkle Trees haben breite Unterstützung von der Ethereum-Community erhalten, und es finden alle zwei Wochen Treffen statt, um ihre Entwicklung voranzutreiben. Dank dieser konsequenten Arbeit und Tests heben sich Verkle Trees als die ausgereifteste und am besten erforschte Lösung unter den aktuellen Alternativen hervor. Darüber hinaus machen ihre additiv homomorphen Eigenschaften es im Gegensatz zu Merkle Trees überflüssig, jeden Zweig neu zu berechnen, um die Statuswurzel zu aktualisieren, was Verkle Trees zu einer effizienteren Option macht. Im Vergleich zu anderen Lösungen legen Verkle Trees Wert auf Einfachheit und halten sich an technische Prinzipien wie „keep it simple“ oder „simpel ist am besten“. Diese Einfachheit erleichtert sowohl die Integration in Ethereum als auch die Sicherheitsanalyse.

2. Allerdings sind Verkle Trees nicht quantensicher, was sie als langfristige Lösung ausschließt. Wenn diese Technologie in Ethereum integriert wird, müsste sie in Zukunft wahrscheinlich ersetzt werden, wenn quantenresistente Lösungen erforderlich sind. Selbst Vitalik betrachtet Verkle Trees als vorübergehende Maßnahme, um Zeit zu gewinnen, damit STARKs und andere Technologien ausgereift sind. Darüber hinaus verursachen die in Verkle Trees verwendeten elliptischen kurvenbasierten Vektorverpflichtungen eine höhere Rechenlast als einfache Hashfunktionen. Hashbasierte Ansätze bieten möglicherweise schnellere Synchronisierungszeiten für vollständige Knoten. Darüber hinaus erschwert die Abhängigkeit von zahlreichen 256-Bit-Operationen den Nachweis von Verkle Trees mit SNARKs in modernen Nachweissystemen, was zukünftige Bemühungen zur Reduzierung der Nachweisgrößen erschwert.

   
   

Dennoch ist es wichtig zu beachten, dass Verkle-Bäume aufgrund ihrer Unabhängigkeit von Hashing deutlich besser beweisbar sind als Merkle-Bäume.

STARKs + konservative Hash-Funktionen

1. Die Kombination von STARKs mit etablierten konservativen Hash-Funktionen wie SHA256 oder BLAKE bietet eine robuste Lösung, die die Sicherheitsinfrastruktur von Ethereum stärkt. Diese Hash-Funktionen wurden sowohl im akademischen als auch im praktischen Bereich weithin verwendet und ausgiebig getestet. Darüber hinaus erhöht ihre Quantenresistenz die Widerstandsfähigkeit von Ethereum gegen zukünftige Bedrohungen durch Quantencomputer. Für sicherheitskritische Szenarien bietet diese Kombination eine zuverlässige Grundlage.

2. Die Verwendung konservativer Hash-Funktionen in STARK-Systemen führt jedoch zu erheblichen Leistungseinschränkungen. Die Rechenleistungsanforderungen dieser Hash-Funktionen führen zu einer hohen Latenz des Beweisers , wobei die Beweisgenerierung über 10 Sekunden dauert. Dies ist ein großer Nachteil, insbesondere in Szenarien wie der Blockvalidierung, die eine geringe Latenz erfordern. Während Bemühungen wie mehrdimensionale Gasvorschläge versuchen, die Latenz im schlimmsten Fall und im durchschnittlichen Fall anzugleichen, sind die Ergebnisse begrenzt. Darüber hinaus können hashbasierte Ansätze zwar schnellere Synchronisierungszeiten ermöglichen, ihre Effizienz entspricht jedoch möglicherweise nicht den umfassenderen Skalierbarkeitszielen von STARK. Die langen Rechenzeiten herkömmlicher Hash-Funktionen verringern die praktische Effizienz und begrenzen ihre Anwendbarkeit.

   STARKs + Relativ neue Hash-Funktionen

• STARKs in Kombination mit STARK-freundlichen Hash-Funktionen der neuen Generation (z. B. Poseidon) verbessern die Leistung dieser Technologie erheblich. Diese Hash-Funktionen sind so konzipiert, dass sie sich nahtlos in STARK-Systeme integrieren lassen und die Latenz des Beweisers drastisch reduzieren. Im Gegensatz zu herkömmlichen Hash-Funktionen ermöglichen sie die Beweiserstellung in nur 1–2 Sekunden . Ihre Effizienz und der geringe Rechenaufwand steigern das Skalierbarkeitspotenzial von STARKs und machen sie für die Verarbeitung großer Datensätze äußerst effektiv. Diese Fähigkeit macht sie besonders attraktiv für Anwendungen, die eine hohe Leistung erfordern.

• Da diese Hash-Funktionen jedoch relativ neu sind, sind umfangreiche Sicherheitsanalysen und -tests erforderlich. Das Fehlen umfassender Tests bringt Risiken mit sich, wenn ihre Implementierung in kritischen Ökosystemen wie Ethereum in Betracht gezogen wird. Da diese Hash-Funktionen noch nicht weit verbreitet sind, könnten die erforderlichen Test- und Validierungsprozesse zudem die Verifizierbarkeitsziele von Ethereum verzögern . Die Zeit, die benötigt wird, um ihre Sicherheit vollständig zu gewährleisten, könnte diese Option kurzfristig weniger attraktiv machen und möglicherweise die Skalierbarkeits- und Verifizierbarkeitsambitionen von Ethereum verzögern.

  Gitterbasierte Merkle-Bäume

1. Gitterbasierte Merkle-Bäume bieten eine zukunftsweisende Lösung, die Quantensicherheit mit der Aktualisierungseffizienz von Verkle-Bäumen kombiniert. Diese Strukturen beheben die Schwächen sowohl von Verkle-Bäumen als auch von STARKs und gelten als vielversprechende langfristige Option. Mit ihrem gitterbasierten Design bieten sie starken Widerstand gegen Bedrohungen durch Quantencomputer und stehen im Einklang mit Ethereums Fokus auf die Zukunftssicherheit seines Ökosystems. Darüber hinaus zielen sie durch die Beibehaltung der Aktualisierungsvorteile von Verkle-Bäumen darauf ab, eine verbesserte Sicherheit zu bieten, ohne die Effizienz zu beeinträchtigen.
2. Die Forschung zu gitterbasierten Merkle-Bäumen befindet sich jedoch noch in einem frühen Stadium und ist weitgehend theoretisch. Dies führt zu erheblicher Unsicherheit hinsichtlich ihrer praktischen Umsetzung und Leistung. Die Integration einer solchen Lösung in Ethereum würde umfangreiche Forschung und Entwicklung sowie strenge Tests erfordern, um ihre potenziellen Vorteile zu bestätigen. Aufgrund dieser Unsicherheiten und infrastrukturellen Komplexitäten sind gitterbasierte Merkle-Bäume in naher Zukunft wahrscheinlich keine praktikable Wahl für Ethereum, was den Fortschritt bei der Verifizierbarkeitsziele des Netzwerks möglicherweise verzögert.

Was ist mit der Ausführung: Gültigkeitsnachweise der EVM-Ausführung

Alles, was wir bisher besprochen haben, dreht sich darum, die Notwendigkeit zu beseitigen, dass Validatoren den vorherigen Status speichern müssen, den sie für den Übergang von einem Status zum nächsten verwenden. Das Ziel besteht darin, eine dezentralere Umgebung zu schaffen, in der Validatoren ihre Aufgaben erfüllen können, ohne Terabyte an Statusdaten verwalten zu müssen.

Selbst mit den von uns genannten Lösungen müssten Validierer nicht den gesamten Status speichern, da sie alle für die Ausführung erforderlichen Daten durch im Block enthaltene Zeugen erhalten würden. Um jedoch zum nächsten Status zu wechseln – und damit den StateRoot über dem Block zu verifizieren – müssen Validierer den STF immer noch selbst ausführen. Diese Anforderung wiederum stellt eine weitere Herausforderung für Ethereums erlaubnisfreie Natur und Dezentralisierung dar.

Ursprünglich war The Verge als Meilenstein gedacht, der sich ausschließlich auf die Umstellung des Ethereum-Zustandsbaums von Merkle-Bäumen auf Verkle-Bäume konzentrierte, um die Verifizierbarkeit von Zuständen zu verbessern. Im Laufe der Zeit hat es sich jedoch zu einer breiteren Initiative entwickelt, die darauf abzielt, die Verifizierbarkeit von Zustandsübergängen und Konsens zu verbessern. In einer Welt, in der das Trio aus Zustand, Ausführung und Konsens vollständig verifizierbar ist, könnten Ethereum-Validatoren auf praktisch jedem Gerät mit einer Internetverbindung ausgeführt werden, das als Light Client kategorisiert werden kann. Dies würde Ethereum seiner Vision einer „echten Dezentralisierung“ näher bringen.

Wie ist noch mal die Problemdefinition?

Wie bereits erwähnt, führen Validatoren alle 12 Sekunden eine Funktion namens STF (State Transition Function) aus. Diese Funktion verwendet den vorherigen Status und einen Block als Eingaben und erzeugt den nächsten Status als Ausgabe. Validatoren müssen diese Funktion jedes Mal ausführen, wenn ein neuer Block vorgeschlagen wird, und überprüfen, ob der Hash, der den Status über dem Block darstellt – allgemein als Statuswurzel bezeichnet – korrekt ist.

Die hohen Systemanforderungen, um Validierer zu werden, ergeben sich vor allem aus der Notwendigkeit, diesen Prozess effizient durchführen zu müssen.

Wenn Sie einen intelligenten Kühlschrank – ja, sogar einen Kühlschrank – mithilfe der installierten Software in einen Ethereum-Validator verwandeln möchten, stehen Sie vor zwei großen Hindernissen :

1. Ihr Kühlschrank verfügt höchstwahrscheinlich nicht über einen ausreichend schnellen Internetzugang und kann daher selbst mit den bisher besprochenen staatlichen Verifizierlösungen die für die Durchführung notwendigen Daten und Nachweise nicht herunterladen.

2. Selbst wenn es Zugriff auf die für STF erforderlichen Daten hätte, stünde ihm die erforderliche Rechenleistung nicht zur Verfügung, um die Ausführung von Anfang bis Ende durchzuführen oder einen neuen Zustandsbaum zu erstellen.

   
   

Um die Probleme zu lösen, die dadurch entstehen, dass Light Clients weder auf den vorherigen Status noch auf den gesamten letzten Block zugreifen können, schlägt The Verge vor, dass der Antragsteller die Ausführung durchführt und dann einen Beweis an den Block anfügt. Dieser Beweis würde den Übergang von der vorherigen Statuswurzel zur nächsten Statuswurzel sowie den Hash des Blocks umfassen. Damit können Light Clients den Statusübergang mit nur drei 32-Byte -Hashes validieren, ohne dass ein zk-Beweis erforderlich ist.

Da dieser Beweis jedoch über Hashes funktioniert, wäre es falsch zu sagen, dass er nur den Zustandsübergang validiert. Im Gegenteil, der an den Block angehängte Beweis muss mehrere Dinge gleichzeitig validieren:

Zustandswurzel im vorherigen Block = S, Zustandswurzel im nächsten Block = S + 1, Block-Hash = H

1. Der Block selbst muss gültig sein und der darin enthaltene Zustandsnachweis – sei es ein Verkle Proof oder STARKs – muss die dem Block beiliegenden Daten genau verifizieren. Kurz gesagt: Validierung des Blocks und des zugehörigen Zustandsnachweises .
2. Wenn der STF mit den für die Ausführung erforderlichen und im Block H enthaltenen Daten ausgeführt wird, müssen die Daten, die sich im Zustand ändern sollen, korrekt aktualisiert werden. Kurz gesagt: Validierung des Zustandsübergangs .
3. Wenn ein neuer Zustandsbaum mit den korrekt aktualisierten Daten neu erstellt wird, muss sein Wurzelwert mit S + 1 übereinstimmen. Kurz gesagt: Validierung des Baumkonstruktionsprozesses .

In der Beweiser-Verifizierer-Analogie , auf die wir zuvor verwiesen haben, kann man im Allgemeinen sagen, dass zwischen den beiden Akteuren normalerweise ein rechnerisches Gleichgewicht besteht. Während die Fähigkeit der Beweise, die erforderlich sind, um den STF verifizierbar zu machen, um mehrere Dinge gleichzeitig zu validieren, erhebliche Vorteile für den Verifizierer bietet, zeigt dies auch, dass das Erzeugen solcher Beweise, um die Richtigkeit der Ausführung sicherzustellen, für den Beweiser relativ schwierig sein wird. Bei der aktuellen Geschwindigkeit von Ethereum muss ein Ethereum-Block in weniger als 4 Sekunden bewiesen werden. Allerdings kann selbst der schnellste EVM-Beweiser, den wir heute haben, einen durchschnittlichen Block nur in etwa 15 Sekunden beweisen.[1]

Dennoch gibt es drei verschiedene Wege , diese große Herausforderung zu meistern:

1. Parallelisierung bei Beweisen und Aggregation : Einer der wesentlichen Vorteile von ZK-Beweisen ist ihre Aggregatfähigkeit . Die Möglichkeit, mehrere Beweise zu einem einzigen, kompakten Beweis zu kombinieren, sorgt für erhebliche Effizienz hinsichtlich der Verarbeitungszeit. Dies reduziert nicht nur die Belastung des Netzwerks, sondern beschleunigt auch die Verifizierungsprozesse auf dezentrale Weise. Für ein großes Netzwerk wie Ethereum ermöglicht es die effizientere Generierung von Beweisen für jeden Block.

Während der Beweisgenerierung kann jedes kleine Stück des Ausführungsprozesses (z. B. Rechenschritte oder Datenzugriff) einzeln bewiesen werden, und diese Beweise können später in einer einzigen Struktur zusammengefasst werden. Mit dem richtigen Mechanismus ermöglicht dieser Ansatz die schnelle und dezentralisierte Generierung der Beweise eines Blocks durch viele verschiedene Quellen (z. B. Hunderte von GPUs). Dies steigert die Leistung und trägt gleichzeitig zum Dezentralisierungsziel bei, indem ein breiterer Teilnehmerkreis einbezogen wird.

2. Verwendung optimierter Beweissysteme : Beweissysteme der neuen Generation haben das Potenzial, die Rechenprozesse von Ethereum schneller und effizienter zu machen. Fortschrittliche Systeme wie Orion , Binius und GKR können die Beweiszeit für allgemeine Berechnungen erheblich verkürzen. Diese Systeme zielen darauf ab, die Einschränkungen aktueller Technologien zu überwinden, die Verarbeitungsgeschwindigkeit zu erhöhen und gleichzeitig weniger Ressourcen zu verbrauchen. Für ein auf Skalierbarkeit und Effizienz ausgerichtetes Netzwerk wie Ethereum bieten solche Optimierungen einen erheblichen Vorteil. Die vollständige Implementierung dieser neuen Systeme erfordert jedoch umfassende Tests und Kompatibilitätsanstrengungen innerhalb des Ökosystems.
3. Änderungen der Gaskosten : In der Vergangenheit wurden die Gaskosten für Vorgänge auf der Ethereum Virtual Machine (EVM) normalerweise anhand ihrer Rechenkosten bestimmt. Heute hat jedoch ein anderer Maßstab an Bedeutung gewonnen: die Komplexität des Beweisers . Während einige Vorgänge relativ einfach zu beweisen sind, haben andere eine komplexere Struktur und ihre Verifizierung dauert länger. Die Anpassung der Gaskosten nicht nur anhand des Rechenaufwands, sondern auch anhand der Schwierigkeit des Nachweises von Vorgängen ist entscheidend, um sowohl die Sicherheit als auch die Effizienz des Netzwerks zu verbessern.

Dieser Ansatz kann die Lücke zwischen Worst-Case- und Average-Case- Szenarien minimieren und so eine konsistentere Leistung ermöglichen. So könnten beispielsweise Operationen, die schwieriger zu beweisen sind, höhere Gaskosten verursachen, während Operationen, die einfacher zu beweisen sind, geringere Kosten verursachen könnten. Darüber hinaus könnte das Ersetzen der Datenstrukturen von Ethereum (wie dem Zustandsbaum oder der Transaktionsliste ) durch STARK-freundliche Alternativen die Beweisprozesse weiter beschleunigen. Solche Änderungen würden Ethereum helfen, seine Skalierbarkeits- und Sicherheitsziele zu erreichen und gleichzeitig seine Vision der Verifizierbarkeit realistischer zu gestalten.

Ethereums Bemühungen , Ausführungsnachweise zu ermöglichen, stellen eine bedeutende Chance dar, seine Verifizierbarkeitsziele zu erreichen. Um dieses Ziel zu erreichen, sind jedoch nicht nur technische Innovationen, sondern auch erhöhte Entwicklungsanstrengungen und kritische Entscheidungen innerhalb der Community erforderlich. Um Ausführungsprozesse auf Layer 1 verifizierbar zu machen, muss ein Gleichgewicht zwischen der Zugänglichkeit für eine breite Benutzerbasis, der Wahrung der Dezentralisierung und der Anpassung an die vorhandene Infrastruktur hergestellt werden.

Das Herstellen dieses Gleichgewichts erhöht die Komplexität der Methoden, die zum Nachweis von Operationen während der Ausführung verwendet werden, und unterstreicht die Notwendigkeit von Weiterentwicklungen wie der parallelen Beweisgenerierung . Darüber hinaus müssen die infrastrukturellen Anforderungen dieser Technologien (z. B. Nachschlagetabellen ) implementiert und operationalisiert werden, was noch erhebliche Forschungs- und Entwicklungsarbeit erfordert.

Andererseits bieten speziell für bestimmte Aufgaben entwickelte Spezialschaltkreise (z. B. ASICs, FPGAs, GPUs) ein erhebliches Potenzial zur Beschleunigung des Prozesses der Beweisgenerierung. Diese Lösungen bieten im Vergleich zu herkömmlicher Hardware eine viel höhere Effizienz und können Ausführungsprozesse beschleunigen.

Die Dezentralisierungsziele von Ethereum auf Layer-1-Ebene verhindern jedoch, dass solche Hardware nur einer ausgewählten Gruppe von Akteuren zugänglich ist. Daher ist zu erwarten, dass diese Lösungen in Layer-2-Systemen häufiger zum Einsatz kommen. Dennoch muss die Community auch einen Konsens über die Hardwareanforderungen für die Beweisgenerierung erzielen.

Es stellt sich eine zentrale Designfrage: Soll die Beweisgenerierung auf verbrauchertauglicher Hardware wie High-End-Laptops funktionieren oder eine industrielle Infrastruktur erfordern? Die Antwort prägt die gesamte Architektur von Ethereum – sie ermöglicht eine aggressive Optimierung für Layer-2-Lösungen, erfordert aber konservativere Ansätze für Layer 1.

Schließlich ist die Implementierung von Ausführungsnachweisen direkt mit den anderen Zielen der Ethereum-Roadmap verknüpft. Die Einführung von Gültigkeitsnachweisen würde nicht nur Konzepte wie Zustandslosigkeit unterstützen, sondern auch die Dezentralisierung von Ethereum verbessern, indem sie Bereiche wie Solo-Staking zugänglicher macht. Das Ziel ist, Staking auch auf Geräten mit den niedrigsten Spezifikationen zu ermöglichen. Darüber hinaus könnte eine Umstrukturierung der Gaskosten auf dem EVM auf der Grundlage der Rechenschwierigkeit und Beweisbarkeit die Lücke zwischen Durchschnitts- und Worst-Case -Szenarien minimieren.

Solche Änderungen könnten jedoch die Abwärtskompatibilität mit dem aktuellen System beeinträchtigen und Entwickler zwingen, ihren Code neu zu schreiben. Aus diesem Grund ist die Implementierung von Ausführungsnachweisen nicht nur eine technische Herausforderung – es ist ein Prozess, der so gestaltet werden muss, dass die langfristigen Werte von Ethereum gewahrt bleiben.

Letzter Schritt zur echten Vollverifizierbarkeit: Konsens

Der Konsensmechanismus von Ethereum strebt eine einzigartige Balance an, die Dezentralisierung und Zugänglichkeit bewahrt und gleichzeitig Verifizierbarkeitsziele erreicht. In diesem Rahmen bieten probabilistische und deterministische Konsensmethoden deutliche Vorteile und Herausforderungen.

Der probabilistische Konsens basiert auf einem Kommunikationsmodell mit Klatsch. In diesem Modell kommuniziert ein Knoten nicht direkt mit allen Knoten, die das Netzwerk repräsentieren, sondern teilt Informationen mit einer zufällig ausgewählten Gruppe von 64 oder 128 Knoten. Die Kettenauswahl eines Knotens basiert auf diesen begrenzten Informationen, was die Möglichkeit von Fehlern mit sich bringt. Im Laufe der Zeit, wenn die Blockchain fortschreitet, wird jedoch erwartet, dass diese Auswahlen mit einer Fehlerrate von 0 % zur richtigen Kette konvergieren.

Ein Vorteil der probabilistischen Struktur besteht darin, dass nicht jeder Knoten seine Kettenansicht als separate Nachricht sendet, wodurch der Kommunikationsaufwand reduziert wird. Folglich kann eine solche Struktur mit weitaus mehr erlaubnisfreien , dezentralen Knoten mit geringeren Systemanforderungen betrieben werden.

Im Gegensatz dazu funktioniert der deterministische Konsens über ein Einer-zu-allen -Kommunikationsmodell . Dabei sendet ein Knoten seine Kettenansicht als Abstimmung an alle anderen Knoten. Dieser Ansatz erzeugt eine höhere Nachrichtenintensität, und wenn die Anzahl der Knoten zunimmt, kann das System irgendwann an seine Grenzen stoßen.

Der größte Vorteil des deterministischen Konsenses ist jedoch die Verfügbarkeit konkreter Stimmen, sodass Sie genau wissen, welcher Knoten für welche Abzweigung gestimmt hat. Dies gewährleistet eine schnelle und endgültige Kettenendgültigkeit, garantiert, dass die Reihenfolge der Blöcke nicht geändert werden kann, und macht sie überprüfbar.

Um einen überprüfbaren Konsensmechanismus bereitzustellen und gleichzeitig die Dezentralisierung und eine erlaubnisfreie Struktur zu wahren, hat Ethereum ein Gleichgewicht zwischen Slots und Epochen gefunden. Slots, die 12-Sekunden-Intervalle darstellen, sind die Grundeinheiten, in denen ein Validierer für die Erstellung eines Blocks verantwortlich ist. Obwohl der auf Slot-Ebene verwendete probabilistische Konsens es der Kette ermöglicht, flexibler und dezentralisierter zu arbeiten, weist er Einschränkungen hinsichtlich der endgültigen Reihenfolge und Überprüfbarkeit auf.

Epochen, die 32 Slots umfassen, führen einen deterministischen Konsens ein. Auf dieser Ebene stimmen die Validierer ab, um die Reihenfolge der Kette festzulegen, wodurch Sicherheit gewährleistet und die Kette verifizierbar wird. Diese deterministische Struktur bietet zwar Verifizierbarkeit durch konkrete Abstimmungen auf Epochenebene, kann jedoch aufgrund der probabilistischen Struktur keine vollständige Verifizierbarkeit innerhalb der Epochen selbst bieten. Um diese Lücke zu schließen und die probabilistische Struktur innerhalb der Epochen zu stärken, hat Ethereum eine Lösung entwickelt, die als Sync Committee bekannt ist.

Altairs Light Client-Protokoll: Sync-Komitee

Das Sync Committee ist ein Mechanismus, der mit dem Altair-Upgrade eingeführt wurde, um die Einschränkungen des probabilistischen Konsenses von Ethereum zu überwinden und die Verifizierbarkeit der Kette für Light-Clients zu verbessern. Das Komitee besteht aus 512 zufällig ausgewählten Validierern, die 256 Epochen (~27 Stunden) im Einsatz sind. Diese Validierer erstellen eine Signatur, die den Kopf der Kette darstellt, sodass Light-Clients die Gültigkeit der Kette überprüfen können, ohne historische Kettendaten herunterladen zu müssen. Die Funktionsweise des Sync Committee kann wie folgt zusammengefasst werden:

1. Bildung des Komitees : 512 Validierer werden nach dem Zufallsprinzip aus allen Validierern im Netzwerk ausgewählt. Diese Auswahl wird regelmäßig aktualisiert, um die Dezentralisierung aufrechtzuerhalten und die Abhängigkeit von einer bestimmten Gruppe zu verhindern.
2. Signaturgenerierung : Die Ausschussmitglieder erstellen eine Signatur, die den neuesten Stand der Kette darstellt. Diese Signatur ist eine von den Mitgliedern erstellte kollektive BLS-Signatur und wird zur Überprüfung der Gültigkeit der Kette verwendet.
3. Light-Client-Verifizierung : Light-Clients können die Korrektheit der Kette verifizieren, indem sie einfach die Signatur des Sync-Komitees prüfen. Dadurch können sie die Kette sicher verfolgen, ohne frühere Kettendaten herunterladen zu müssen.

Das Sync Committee ist jedoch in einigen Bereichen Kritik ausgesetzt. Insbesondere fehlt dem Protokoll ein Mechanismus, um Validierer für böswilliges Verhalten zu kürzen , selbst wenn die ausgewählten Validierer absichtlich gegen das Protokoll handeln. Daher betrachten viele das Sync Committee als Sicherheitsrisiko und sehen davon ab, es vollständig als Light Client Protocol zu klassifizieren. Dennoch wurde die Sicherheit des Sync Committee mathematisch bewiesen , und weitere Einzelheiten finden Sie in diesem Artikel über Sync Committee Slashings .

Das Fehlen eines Slashing-Mechanismus im Protokoll ist keine Designentscheidung, sondern eine Notwendigkeit, die sich aus der Natur des probabilistischen Konsenses ergibt. Der probabilistische Konsens bietet keine absoluten Garantien dafür, was ein Validierer beobachtet. Selbst wenn die Mehrheit der Validierer einen bestimmten Fork als den schwereren meldet, kann es immer noch außergewöhnliche Validierer geben, die einen anderen Fork als schwerer beobachten. Diese Unsicherheit macht es schwierig, böswillige Absichten nachzuweisen und somit unmöglich, Fehlverhalten zu bestrafen.

In diesem Zusammenhang wäre es genauer, das Sync Committee als ineffiziente Lösung zu bezeichnen, anstatt es als unsicher zu bezeichnen. Das Problem liegt nicht im mechanischen Design oder Betrieb des Sync Committee, sondern in der inhärenten Natur des probabilistischen Konsenses. Da der probabilistische Konsens keine definitiven Garantien dafür bieten kann, was die Knoten beobachten, ist das Sync Committee eine der besten Lösungen, die innerhalb eines solchen Modells entwickelt werden können. Dies beseitigt jedoch nicht die Schwächen des probabilistischen Konsenses bei der Gewährleistung der Kettenendgültigkeit. Das Problem liegt nicht beim Mechanismus, sondern in der aktuellen Konsensstruktur von Ethereum.

Aufgrund dieser Einschränkungen gibt es im Ethereum-Ökosystem laufende Bemühungen, den Konsensmechanismus neu zu gestalten und Lösungen zu implementieren, die in kürzeren Zeiträumen deterministische Endgültigkeit gewährleisten. Vorschläge wie Orbit-SSF und 3SF zielen darauf ab, die Konsensstruktur von Ethereum von Grund auf neu zu gestalten und ein effektiveres System zu schaffen, das den probabilistischen Konsens ersetzt. Solche Ansätze zielen nicht nur darauf ab, die Endgültigkeitszeit der Kette zu verkürzen, sondern auch eine effizientere und überprüfbare Netzwerkstruktur bereitzustellen. Die Ethereum-Community entwickelt diese Vorschläge weiterhin aktiv weiter und bereitet sie für die zukünftige Umsetzung vor.

Snarkifizierung des Konsenses

The Verge zielt darauf ab, die aktuellen und zukünftigen Konsensmechanismen von Ethereum zu verbessern, indem sie durch zk-proof-Technologie verifizierbarer gemacht werden, anstatt sie vollständig zu ersetzen. Dieser Ansatz zielt darauf ab, die Konsensprozesse von Ethereum zu modernisieren und gleichzeitig seine Kernprinzipien der Dezentralisierung und Sicherheit zu bewahren. Die Optimierung aller historischen und aktuellen Konsensprozesse der Kette mit zk-Technologien spielt eine entscheidende Rolle bei der Erreichung der langfristigen Skalierbarkeits- und Effizienzziele von Ethereum. Die grundlegenden Operationen, die in der Konsensschicht von Ethereum verwendet werden, sind bei dieser technologischen Transformation von großer Bedeutung. Schauen wir uns diese Operationen und die damit verbundenen Herausforderungen genauer an.

• ECADDs :
• Zweck : Dieser Vorgang wird zum Aggregieren der öffentlichen Schlüssel der Validierer verwendet und ist für die Gewährleistung der Genauigkeit und Effizienz der Kette von entscheidender Bedeutung. Dank der aggregierbaren Natur von BLS-Signaturen können mehrere Signaturen zu einer einzigen Struktur kombiniert werden. Dies reduziert den Kommunikationsaufwand und macht die Verifizierungsprozesse in der Kette effizienter. Um die Synchronisierung zwischen großen Validierergruppen effektiver zu gewährleisten, ist dieser Vorgang von entscheidender Bedeutung.
• Herausforderungen : Wie bereits erwähnt, stimmen die Validierer von Ethereum während der Epochen über die Reihenfolge der Kette ab. Heute ist Ethereum ein Netzwerk mit etwa 1,1 Millionen Validierern . Wenn alle Validierer versuchen würden, ihre Stimmen gleichzeitig zu verbreiten, würde dies das Netzwerk erheblich belasten. Um dies zu vermeiden, ermöglicht Ethereum den Validierern, während einer Epoche auf Slot-Basis abzustimmen, wobei nur 1/32 aller Validierer pro Slot abstimmen. Dieser Mechanismus reduziert zwar den Netzwerkkommunikationsaufwand und macht den Konsens effizienter, aber bei der heutigen Validiererzahl stimmen etwa 34.000 Validierer in jedem Slot ab. Dies entspricht etwa 34.000 ECADD-Operationen pro Slot .
• Paarungen :
• Zweck : Pairing-Operationen werden zur Überprüfung von BLS-Signaturen verwendet, um die Gültigkeit von Epochen in der Kette sicherzustellen. Diese Operation ermöglicht die Stapelüberprüfung von Signaturen. Sie ist jedoch nicht zk-freundlich , was den Nachweis mithilfe der zk-Proof-Technologie extrem kostspielig macht. Dies stellt eine große Herausforderung bei der Erstellung eines integrierten Überprüfungsprozesses mit Zero-Knowledge-Technologien dar.
• Herausforderungen : Pairing-Operationen in Ethereum sind auf maximal 128 Attestierungen (aggregierte Signaturen) pro Slot beschränkt, was zu weniger Pairing-Operationen im Vergleich zu ECADDs führt. Die mangelnde ZK-Freundlichkeit dieser Operationen stellt jedoch eine erhebliche Herausforderung dar. Der Nachweis einer Pairing-Operation mit ZK-Proofs ist tausendmal teurer als der Nachweis einer ECADD-Operation [2]. Dies macht die Anpassung von Pairing-Operationen für Zero-Knowledge-Technologien zu einem der größten Hindernisse in den Konsensverifizierungsprozessen von Ethereum.
• SHA256-Hashes :
• Zweck : SHA256-Hash-Funktionen werden verwendet, um den Zustand der Kette zu lesen und zu aktualisieren und so die Integrität der Daten der Kette sicherzustellen. Ihre mangelnde ZK-Freundlichkeit führt jedoch zu Ineffizienzen bei zk-proof-basierten Verifizierungsprozessen und stellt ein großes Hindernis für die zukünftigen Verifizierbarkeitsziele von Ethereum dar.
• Herausforderungen : SHA256-Hash-Funktionen werden häufig zum Lesen und Aktualisieren des Zustands der Kette verwendet. Ihre ZK-Unfreundlichkeit steht jedoch im Widerspruch zu den auf ZK-Proof basierenden Verifizierungszielen von Ethereum. Beispielsweise führt jeder Validierer zwischen zwei Epochen die STF der Konsensschicht von Ethereum aus, um den Zustand mit Belohnungen und Strafen basierend auf der Leistung des Validierers während der Epoche zu aktualisieren. Dieser Prozess stützt sich stark auf SHA256-Hash-Funktionen, was die Kosten in auf ZK-Proof basierenden Systemen erheblich erhöht. Dies stellt ein erhebliches Hindernis für die Anpassung des Konsensmechanismus von Ethereum an ZK-Technologien dar.

Die in der aktuellen Konsensschicht verwendeten ECADD-, Pairing- und SHA256-Operationen spielen eine entscheidende Rolle für die Verifizierbarkeitsziele von Ethereum. Ihre mangelnde ZK-Freundlichkeit stellt jedoch erhebliche Herausforderungen auf dem Weg zur Erreichung dieser Ziele dar. ECADD-Operationen stellen aufgrund der hohen Anzahl an Validator-Stimmen eine kostspielige Belastung dar, während Pairing-Operationen trotz ihrer geringeren Anzahl tausendmal teurer zu beweisen sind, wenn sie mit ZK-Proofs nachgewiesen werden.

Darüber hinaus macht die ZK-Unfreundlichkeit der SHA256-Hash-Funktionen den Nachweis des Zustandsübergangs der Beacon-Kette äußerst schwierig. Diese Probleme unterstreichen die Notwendigkeit einer umfassenden Transformation, um die bestehende Infrastruktur von Ethereum mit Zero-Knowledge-Technologien auszurichten.

Lösung „Beam Chain“: Ethereums Konsensschicht neu denken

Am 12. November 2024 stellte Justin Drake während seiner Präsentation auf der Devcon einen Vorschlag namens „Beam Chain “ vor, der darauf abzielt, die Konsensschicht von Ethereum grundlegend und umfassend zu verändern. Die Beacon Chain bildet seit fast fünf Jahren den Kern des Ethereum-Netzwerks. In dieser Zeit gab es jedoch keine größeren strukturellen Änderungen an der Beacon Chain. Im Gegensatz dazu haben sich die technologischen Fortschritte schnell entwickelt und die statische Natur der Beacon Chain weit übertroffen.

In seiner Präsentation betonte Justin Drake, dass Ethereum in diesen fünf Jahren in kritischen Bereichen wie MEV-Verständnis , Durchbrüchen bei SNARK-Technologien und rückblickender Wahrnehmung technologischer Fehler wichtige Lektionen gelernt hat. Die auf diesen neuen Erkenntnissen basierenden Designs lassen sich in drei Hauptsäulen unterteilen: Blockproduktion , Staking und Kryptografie . Die folgende Abbildung fasst diese Designs und die vorgeschlagene Roadmap zusammen:

• Grüne und graue Kästen stellen inkrementelle Entwicklungen dar, die jedes Jahr einzeln implementiert werden können. Diese Art von Verbesserungen können, ähnlich wie frühere Upgrades, schrittweise integriert werden, ohne die bestehende Architektur von Ethereum zu beeinträchtigen.

• Rote Kästen hingegen stehen für hochsynergische , groß angelegte und grundlegende Änderungen , die gemeinsam umgesetzt werden müssen. Laut Drake zielen diese Änderungen darauf ab, die Kapazität und Verifizierbarkeit von Ethereum in einem großen Schritt zu verbessern.

  
  

In diesem Abschnitt haben wir die Schritte „Konsens“, „Status“ und „Ausführung“ von The Verge im Detail untersucht. Eines der wichtigsten Probleme, die dabei hervorgehoben wurden, ist die Verwendung der Hashfunktion SHA256 in der Beacon Chain von Ethereum. Obwohl SHA256 eine zentrale Rolle bei der Gewährleistung der Netzwerksicherheit und der Verarbeitung von Transaktionen spielt, stellt seine mangelnde ZK-Freundlichkeit ein erhebliches Hindernis für das Erreichen der Verifizierbarkeitsziele von Ethereum dar. Seine hohen Rechenkosten und seine Inkompatibilität mit ZK-Technologien machen es zu einem kritischen Problem, das bei zukünftigen Entwicklungen von Ethereum angegangen werden muss.

Justin Drakes Roadmap, die er während seines Devcon-Vortrags vorstellte, sieht vor, SHA256 in der Beacon Chain durch zk-freundliche Hash-Funktionen wie Poseidon zu ersetzen. Dieser Vorschlag zielt darauf ab, die Konsensschicht von Ethereum zu modernisieren, sie überprüfbarer und effizienter zu machen und sie an zk-sichere Technologien anzupassen.

In diesem Zusammenhang sehen wir, dass Ethereum nicht nur mit zk-unfreundlichen Hash-Funktionen vor Herausforderungen steht, sondern auch die in seiner Konsensschicht verwendeten digitalen Signaturen für langfristige Sicherheit neu bewerten muss. Mit der Weiterentwicklung des Quantencomputings könnten derzeit verwendete digitale Signaturalgorithmen wie ECDSA erheblichen Bedrohungen ausgesetzt sein. Wie in den von NIST veröffentlichten Richtlinien erwähnt, werden Varianten von ECDSA mit einem Sicherheitsniveau von 112 Bit bis 2030 veraltet und bis 2035 vollständig verboten sein . Dies erfordert für Ethereum und ähnliche Netzwerke in Zukunft einen Übergang zu widerstandsfähigeren Alternativen wie quantensicheren Signaturen .

An diesem Punkt erweisen sich Hash-basierte Signaturen als quantenresistente Lösungen, die eine entscheidende Rolle bei der Unterstützung der Sicherheits- und Verifizierbarkeitsziele des Netzwerks spielen könnten. Die Erfüllung dieses Bedarfs beseitigt auch das zweite große Hindernis für die Verifizierbarkeit der Beacon Chain: BLS-Signaturen . Einer der wichtigsten Schritte, die Ethereum zur Gewährleistung der Quantensicherheit unternehmen kann, ist die Einführung postquantenbasierter Lösungen wie Hash-basierter Signaturen und Hash-basierter SNARKs .

Wie Justin Drake in seiner Devcon-Präsentation betonte, sind Hash-Funktionen aufgrund ihrer Abhängigkeit von Pre-Image-Resistenz von Natur aus resistent gegenüber Quantencomputern, was sie zu einem der grundlegenden Bausteine der modernen Kryptographie macht. Diese Eigenschaft stellt sicher, dass selbst Quantencomputer den ursprünglichen Input aus einem gegebenen Hash nicht effizient zurückentwickeln können, wodurch ihre Sicherheit gewahrt bleibt.

Hash-basierte Signatursysteme ermöglichen es Validierern und Attestierern, Signaturen vollständig auf der Grundlage von Hash-Funktionen zu generieren. Dies gewährleistet Post-Quanten-Sicherheit und bietet gleichzeitig ein höheres Maß an Verifizierbarkeit im gesamten Netzwerk – insbesondere, wenn eine SNARK-freundliche Hash-Funktion verwendet wird. Dieser Ansatz erhöht nicht nur die Sicherheit des Netzwerks, sondern macht auch die langfristige Sicherheitsinfrastruktur von Ethereum robuster und zukunftssicherer.

Dieses System basiert auf der Kombination von hashbasierten Signaturen und hashbasierten SNARKs (STARK-ähnliche Beweise), um aggregierbare Signaturschemata zu erstellen. Aggregierbare Signaturen komprimieren Tausende von Signaturen in eine einzige Struktur und reduzieren sie auf nur wenige hundert Kilobyte Beweis. Diese Komprimierung verringert die Datenlast im Netzwerk erheblich und beschleunigt gleichzeitig die Verifizierungsprozesse erheblich. Beispielsweise können die Tausenden von Validatorsignaturen, die für einen einzigen Slot auf Ethereum erstellt werden, durch eine einzige aggregierte Signatur dargestellt werden, was sowohl Speicherplatz als auch Rechenleistung spart.

Das bemerkenswerteste Merkmal dieses Schemas ist jedoch seine unendlich rekursive Aggregation . Das heißt, eine Gruppe von Signaturen kann unter einer anderen Gruppe weiter kombiniert werden, und dieser Prozess kann über die gesamte Kette hinweg fortgesetzt werden. Mit diesem Mechanismus und unter Berücksichtigung zukünftiger technologischer Fortschritte kann man mit Fug und Recht behaupten, dass dies Möglichkeiten eröffnet, die derzeit mit BLS nicht erreichbar sind.

Abschluss

Ethereums Weg zur Verifizierbarkeit stellt einen grundlegenden Wandel in der Blockchain-Technologie dar. Die Verge-Initiative behebt zentrale Ineffizienzen durch Verkle Trees zur Statusverifizierung und STARK-Beweise für skalierbare Übergänge.

Einer der ehrgeizigsten Vorschläge ist die Beam Chain , eine umfassende Neugestaltung der Konsensschicht von Ethereum. Durch die Behebung der Einschränkungen der Beacon Chain und die Einbeziehung zk-freundlicher Alternativen soll dieser Ansatz die Skalierbarkeit von Ethereum verbessern und gleichzeitig seine Kernprinzipien der Dezentralisierung und Zugänglichkeit bewahren. Der Übergang unterstreicht jedoch auch die Herausforderungen, denen sich Ethereum gegenübersieht, wenn es darum geht, die Rechenleistungsanforderungen mit seinem Ziel in Einklang zu bringen, ein erlaubnisfreies, inklusives Netzwerk aufrechtzuerhalten.

Da NIST plant, die derzeitige elliptische Kurvenkryptographie bis 2035 auslaufen zu lassen, muss Ethereum quantenresistente Lösungen wie Hash-basierte Signaturen und Poseidon übernehmen. Diese Lösungen bringen ihre eigenen Effizienzkompromisse mit sich.

Die Verwendung von STARKs in der Roadmap von Ethereum betont Skalierbarkeit und Verifizierbarkeit noch stärker. Während sie sich durch die Bereitstellung transparenter und quantenresistenter Beweise auszeichnen, bringt ihre Integration Herausforderungen in Bezug auf Rechenkosten auf der Beweiserseite und Ineffizienzen bei kleinen Datenmengen mit sich. Diese Hürden müssen überwunden werden, um Ethereums Vision von Zustandslosigkeit und effizienter Blockverifizierung vollständig umzusetzen und sicherzustellen, dass das Netzwerk angesichts der steigenden Nachfrage robust bleibt.

Trotz dieser Fortschritte bleiben wichtige Herausforderungen bestehen. Ethereum muss Probleme der ZK-Freundlichkeit , Konsensskalierbarkeit und der Komplexität der Integration quantenresistenter Kryptografie bewältigen. Darüber hinaus stellt die Abwärtskompatibilität der vorhandenen Infrastruktur praktische Hürden dar, die sorgfältige technische Lösungen erfordern, um Störungen für Entwickler und Benutzer gleichermaßen zu vermeiden.

Was Ethereum auszeichnet, sind nicht nur seine technischen Innovationen, sondern auch sein iterativer Ansatz zur Lösung einiger der schwierigsten Probleme in der Blockchain. Der Weg nach vorn – sei es durch Technologien wie Beam Chain , Verkle Trees oder STARK-Proofs – hängt von der Zusammenarbeit von Entwicklern, Forschern und der breiteren Community ab. Bei diesen Fortschritten geht es nicht darum, über Nacht Perfektion zu erreichen, sondern darum, eine Grundlage für ein transparentes , dezentrales und überprüfbares Internet zu schaffen.

Die Entwicklung von Ethereum unterstreicht seine Rolle als entscheidender Akteur bei der Gestaltung der Web3-Ära. Indem Ethereum die heutigen Herausforderungen mit praktischen Lösungen angeht, kommt es einer Zukunft näher, in der Verifizierbarkeit , Quantenresistenz und Skalierbarkeit zum Standard und nicht zur Ausnahme werden.