Der Weg zur Verifizierbarkeit

Web3’s Kernvorteil besteht in der Überprüfbarkeit - Benutzer können überprüfen, wie Systeme tatsächlich funktionieren. Diese Funktion erklärt, warum viele innerhalb und außerhalb der Kryptoindustrie Web3 als Schritt zu einem transparenteren und überprüfbaren Internet beschreiben.

Im Gegensatz zu Web2-Plattformen wie Facebook oder Instagram, bei denen Algorithmen und Regeln auch dann undurchsichtig bleiben, wenn sie dokumentiert sind, sind Kryptoprotokolle für vollständige Nachvollziehbarkeit ausgelegt. Selbst wenn sie geteilt werden, fehlt Ihnen die Möglichkeit, zu überprüfen, ob die Plattform wie angegeben funktioniert. Dies ist das Gegenteil von Krypto, bei dem jedes Protokoll so auditiert wie möglich gestaltet ist oder zumindest erwartet wird.

Heute werden wir „The Verge“ erkunden, einen Abschnitt aus Vitaliks kürzlich veröffentlichtem Werk.Sechsteilige Serie über die Zukunft von Ethereum, um die Schritte zu analysieren, die Ethereum in Richtung Erreichung von Überprüfbarkeit, Nachhaltigkeit und Skalierbarkeit in der Zukunft unternimmt. Unter der Überschrift „The Verge“ werden wir diskutieren, wie Blockchain-Architekturen überprüfbarer gemacht werden können, welche Innovationen diese Änderungen auf Protokollebene mit sich bringen und wie sie den Benutzern ein sichereres Ökosystem bieten. Fangen wir an!

Was bedeutet „Überprüfbarkeit“?

Web2-Anwendungen funktionieren als „Black Boxes“ – Benutzer können nur ihre Eingaben und die resultierenden Ausgaben sehen, ohne Einblick in die tatsächliche Funktionsweise der Anwendung zu haben. Im Gegensatz dazu machen Kryptowährungsprotokolle in der Regel ihren Quellcode öffentlich verfügbar oder haben zumindest Pläne, dies zu tun. Diese Transparenz dient zwei Zwecken: Sie ermöglicht es den Benutzern, direkt mit dem Code des Protokolls zu interagieren, wenn sie dies wünschen, und hilft ihnen zu verstehen, wie das System genau funktioniert und welche Regeln es regieren.

„Dezentralisieren Sie, was Sie können, überprüfen Sie den Rest.“

Verifizierbarkeit stellt sicher, dass Systeme verantwortlich sind und in vielen Fällen garantiert, dass Protokolle wie beabsichtigt funktionieren. Dieses Prinzip betont die Bedeutung der Minimierung der Zentralisierung, da sie oft zu undurchsichtigen, nicht nachvollziehbaren Strukturen führt, in denen Benutzer Operationen nicht verifizieren können. Stattdessen sollten wir uns bemühen, so weit wie möglich zu dezentralisieren und die verbleibenden Elemente verifizierbar und verantwortlich zu machen, wo eine Dezentralisierung nicht möglich ist.

Die Ethereum-Community scheint sich dieser Perspektive anzuschließen, da die Roadmapumfasst einen Meilenstein (genannt “The Verge”), der darauf abzielt, Ethereum besser überprüfbar zu machen. Bevor wir uns jedoch mit The Verge befassen, müssen wir verstehen, welche Aspekte von Blockchains überprüft werden sollten und welche Teile aus Sicht der Benutzer entscheidend sind.

Blockchains funktionieren im Wesentlichen als globale Uhren. In einem verteilten Netzwerk mit rund 10.000 Computern kann es eine erhebliche Zeit dauern, bis eine Transaktion von dem Ursprungsknoten zu allen anderen Knoten weitergeleitet wird. Aus diesem Grund können Knoten im gesamten Netzwerk nicht die genaue Reihenfolge von Transaktionen bestimmen - ob eine vor oder nach einer anderen angekommen ist -, da sie nur ihre eigenen subjektiven Perspektiven haben.

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

Jenseits der Konsensschicht gibt es auch die Ausführungsschicht, die in jeder Blockchain existiert. Die Ausführungsschicht wird durch die Transaktionen geprägt, die Benutzer ausführen möchten.

Sobald Transaktionen erfolgreich durch Konsens angeordnet wurden, müssen diese auf der Ausführungsebene auf den aktuellen Zustand angewendet werden. Wenn Sie sich fragen, was der Zustand ist, haben Sie wahrscheinlich schon einmal Blockchain mit Datenbanken verglichen - genauer gesagt mit einer Bankdatenbank, da Blockchains wie Banken Aufzeichnungen über die Guthaben aller führen.

Wenn Sie $100 im Zustand haben, den wir „S“ nennen, und $10 an jemand anderen senden möchten, beträgt Ihr Guthaben im nächsten Zustand, „S+1“, $90. Dieser Prozess, bei dem Transaktionen angewendet werden, um von einem Zustand in einen anderen zu wechseln, wird als STF (State Transition Function) bezeichnet.

Bei Bitcoin ist das STF hauptsächlich auf Bilanzänderungen beschränkt, 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ührungsebene ist, die in der Lage ist, Code auszuführen.

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

1. Zustand: Sie möchten möglicherweise ein Stück Daten auf der Blockchain lesen, haben jedoch keinen Zugriff auf den Zustand, da Sie keinen betreiben.voller Knoten. Daher fordern Sie die Daten über einen RPC (Remote Procedure Call) -Provider wie Alchemy oder Infura an. Sie müssen jedoch überprüfen, ob die Daten vom RPC-Provider nicht manipuliert wurden.
2. Ausführung: Wie bereits erwähnt, verwenden Blockchains eine STF. Sie müssen überprüfen, ob der Zustandsübergang korrekt ausgeführt wurde - nicht auf der Ebene einzelner Transaktionen, sondern auf Blockebene.
3. Konsens: Dritte Parteien wie RPCs können Ihnen gültige Blöcke zur Verfügung stellen, die noch nicht in die Blockchain aufgenommen wurden. Sie müssen daher überprüfen, ob diese Blöcke durch Konsens akzeptiert und zur Blockchain hinzugefügt wurden.

Wenn dies verwirrend oder unklar erscheint, keine Sorge. Wir werden jeden dieser Aspekte im Detail durchgehen. Fangen wir damit an, wie man den Blockchain-Zustand überprüft!

Wie verifiziert man den Blockchain-Status?

Der „Zustand“ von Ethereum bezieht sich auf die Menge der Daten, die zu einem beliebigen Zeitpunkt in der Blockchain gespeichert sind. Dazu gehören Kontostände (Vertragskonten und extern kontrollierte Konten oder EOAs), Code von Smart Contracts, Vertragsspeicher und mehr. Ethereum ist eine zustandsbasierte Maschine, da Transaktionen, die in der Ethereum Virtual Machine (EVM) verarbeitet werden, den vorherigen Zustand verä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 und besteht aus einem 64-Zeichen-Hash.

Da jede neue Transaktion den Zustand ändert, wird der stateRoot, der im nachfolgenden Block aufgezeichnet ist, entsprechend aktualisiert. Zur Berechnung dieses Werts verwenden Ethereum-Validatoren eine Kombination aus der Keccak-Hash-Funktion und einer Datenstruktur namens die Merkle-Baumunterschiedliche Teile des Staates zu organisieren und zusammenzufassen.

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

1. Determinismus: Derselbe Input wird immer denselben Output erzeugen.
2. Feste Ausgabelänge: Unabhängig von der Eingabelänge ist die Ausgabelänge immer fest.
3. Einweg-Eigenschaft: Es ist praktisch unmöglich, die ursprüngliche Eingabe aus der Ausgabe abzuleiten.
4. Einzigartigkeit: Selbst eine kleine Änderung der Eingabe führt zu einem völlig anderen Ergebnis. Somit wird eine spezifische Eingabe praktisch auf ein einzigartiges Ergebnis abgebildet.

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 Zustand anwenden - und dann überprüfen, ob der im Block angegebene Zustand dem nach der STF erhaltenen Zustand entspricht. Dieser Prozess stellt sicher, dass der Vorschlagende des Blocks ehrlich gehandelt hat und ist somit eine der wichtigsten Verantwortlichkeiten der Validatoren.

Allerdings hashen Ethereum-Validatoren den gesamten Zustand nicht direkt, um seine Zusammenfassung zu finden. Aufgrund der Einweg-Natur von Hashfunktionen würde das direkte Hashen des Zustands die Überprüfbarkeit beseitigen, da der einzige Weg, den Hash zu reproduzieren, darin bestünde, den gesamten Zustand zu besitzen.

Da der Zustand von Ethereum Terabyte groß ist, ist es unpraktisch, den gesamten Zustand auf alltäglichen Geräten wie Telefonen oder Personalcomputern zu speichern. Aus diesem Grund verwendet Ethereum eine Merkle-Baumstruktur, um den stateRoot zu berechnen und die Überprüfbarkeit des Zustands so weit wie möglich zu erhalten.

A Merkle-Baumist eine kryptografische Datenstruktur, die zur sicheren und effizienten Überprüfung der Integrität und Richtigkeit von Daten verwendet wird. Merkle-Bäume werden auf Hash-Funktionen aufgebaut und organisieren die Hashes eines Datensatzes hierarchisch, was die Überprüfung der Integrität und Richtigkeit dieser Daten ermöglicht. Diese Baumstruktur besteht aus drei Arten von Knoten:

1. Blattknoten: Diese Knoten enthalten die Hashes einzelner Datenstücke und befinden sich auf der untersten Ebene des Baumes. Jeder Blattknoten repräsentiert den Hash eines bestimmten Datenstücks im Merkle-Baum.
2. Verzweigungsknoten: Diese Knoten enthalten die kombinierten Hashes ihrer Kindknoten. Im Falle eines binären Merkle-Baums (wobei N=2) werden die Hashes der beiden Kindknoten konkateniert und erneut gehasht, um den Hash eines Verzweigungsknotens auf einer höheren Ebene zu erzeugen.
3. Wurzelknoten: Der Wurzelknoten befindet sich auf der obersten Ebene des Merkle-Baums und repräsentiert die kryptografische Zusammenfassung des gesamten Baums. 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 konstruiert, sind nur zwei einfache Schritte erforderlich:

• Blattknotenerstellung: Jedes Datenstück wird durch eine Hash-Funktion verarbeitet und die resultierenden Hashes bilden die Blattknoten. Diese Knoten befinden sich auf der niedrigsten Ebene des Baumes und stellen die kryptografische Zusammenfassung der Daten dar.

• Kombinieren und hashen: Die Hashes der Blattnodes werden gruppiert (z. B. paarweise) und kombiniert, gefolgt von Hashing. Dieser Prozess erzeugt Zweigknoten auf der nächsten Ebene. Der gleiche Prozess wird für die Zweigknoten wiederholt, bis nur noch ein einzelner Hash übrig bleibt.

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

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

Merkle-Beweise ermöglichen es dem Überprüfer, spezifische Daten effizient zu validieren, indem sie eine Reihe von Hash-Werten bereitstellen, die einen Pfad von den Ziel-Daten (einem Blattknoten) bis zum im Blockheader gespeicherten Merkle-Wurzel bilden. Diese Kette von Zwischen-Hashes ermöglicht es dem Überprüfer, die Authentizität der Daten zu bestätigen, ohne den gesamten Zustand hashen zu müssen.

Ausgehend vom spezifischen Datenpunkt kombiniert der Verifier ihn mit jedem bereitgestellten „Geschwister“-Hash im Merkle-Beweis und hashet sie schrittweise den Baum hinauf. Dieser Prozess wird fortgesetzt, bis ein einzelner Hash erzeugt wird. Wenn dieser berechnete Hash mit dem gespeicherten Merkle-Root übereinstimmt, gilt die Daten als gültig. Andernfalls kann der Verifier feststellen, dass die Daten nicht dem behaupteten Zustand entsprechen.

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

Angenommen, wir haben Daten Nr. 4 von einem RPC empfangen und möchten seine Echtheit mithilfe eines Merkle-Beweises überprüfen. Dazu würde das RPC eine Reihe von Hash-Werten entlang des Pfads bereitstellen, die zum Erreichen der Merkle-Wurzel erforderlich sind. Für Daten 4 würden diese Geschwister-Hashes Hash Nr. 3, Hash Nr. 12 und Hash Nr. 5678 enthalten.

1. Beginnen Sie mit Daten 4: Zuerst hashen wir Daten Nr. 4, um Hash Nr. 4 zu erhalten.
2. Kombinieren mit Geschwistern: Wir kombinieren dann Hash #4 mit Hash #3 (seinem Geschwisterknoten auf Blattebene) und hashen sie zusammen, um Hash #34 zu erzeugen.
3. Bewege dich den Baum nach oben: Als Nächstes nehmen wir Hash #34 und kombinieren ihn mit Hash #12 (seinem Geschwisterknoten in der nächsthöheren Ebene) und hashen sie, um Hash #1234 zu erhalten.
4. Letzter Schritt: Abschließend 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 #4 tatsächlich innerhalb dieses Zustands gültig sind. Ist dies nicht der Fall, wissen wir, dass die Daten nicht zum beanspruchten Zustand gehören, was auf eine mögliche Manipulation hindeutet. Wie Sie sehen können, kann der Prover beweisen, dass Data #4 im Zustand existiert und während seiner Reise nicht verändert wurde, ohne die Hashes aller Daten bereitzustellen oder den Verifier zu benötigen, den gesamten Merkle-Baum von Grund auf neu zu rekonstruieren – mit nur drei Hashes. Dies ist der Hauptgrund, warum Merkle Proofs als effizient gelten.

Während Merkle Trees zweifellos effektiv sind, um eine sichere und effiziente Datenüberprüfung in großen Blockchain-Systemen wie Ethereum zu ermöglichen, sind sie wirklich effizient genug? Um diese Frage zu beantworten, müssen wir analysieren, wie sich die Leistung und Größe des Merkle-Baums auf die Prover-Verifier-Beziehung auswirkt.

Zwei Schlüsselfaktoren, die die Leistung des Merkle-Baums beeinflussen: ⌛

1. Verzweigungsfaktor: Die Anzahl der Kindknoten pro Zweig.
2. Gesamtgröße der Daten: Die Größe des Datensatzes, der im Baum dargestellt wird.

Die Wirkung des Verzweigungsfaktors:

Lassen Sie uns anhand eines Beispiels besser verstehen, wie sich dies auswirkt. Der Verzweigungsfaktor bestimmt, wie viele Zweige aus jedem Knoten im Baum entstehen.

• Kleiner Verzweigungsfaktor (z. B. binärer Merkle-Baum):
  Wenn ein binärer Merkle-Baum (Verzweigungsgrad 2) verwendet wird, ist die Nachweisgröße sehr klein, was den Verifizierungsprozess effizienter für den Verifizierer macht. Mit nur zwei Zweigen an jedem Knoten muss der Verifizierer nur einen Geschwisterhash pro Ebene verarbeiten. Dies beschleunigt die Verifizierung und reduziert die Rechenlast. Der reduzierte Verzweigungsgrad erhöht jedoch die Höhe des Baums, was während des Baumaufbaus zu mehr Hash-Operationen führt, was für die Validatoren belastend sein kann.
• Größerer Verzweigungsfaktor (z. B. 4):
  Ein größerer Verzweigungsfaktor (z. B. 4) verringert die Höhe des Baums und schafft 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 Geschwisterhashes, die sie auf jeder Ebene verarbeiten müssen, was zu einer größeren Beweisgröße führt. Mehr Hashes pro Verifikationsschritt bedeuten auch höhere Rechen- und Bandbreitenkosten für den Verifier und verlagern effektiv die Last von den Validatoren auf die Verifizierer.

Die Auswirkung der Gesamtgröße der Daten:

Mit jedem neuen Transaktion, Vertrag oder Benutzerinteraktion, wächst die Ethereum-Blockchain und damit auch der Merkle-Baum. Dieses Wachstum erhöht nicht nur die Größe des Baums, sondern beeinflusst auch die Größe des Nachweises und die Verifikationszeit.

• Full Nodes müssen regelmäßig den wachsenden Datensatz verarbeiten und aktualisieren, um den Merkle-Baum aufrechtzuerhalten.
• Die Verifier müssen ihrerseits längere und komplexere Beweise überprüfen, da der Datensatz wächst und dadurch zusätzliche Verarbeitungszeit und Bandbreite erforderlich ist.
  Diese wachsende Datengröße erhöht die Anforderungen an sowohl Full Nodes als auch Verifiers und erschwert eine effiziente Skalierung des Netzwerks.

Zusammenfassend bieten Merkle-Bäume zwar eine gewisse Effizienz, aber sie sind keine optimale Lösung für den kontinuierlich wachsenden Datensatz von Ethereum. Aus diesem Grund zielt Ethereum während der The Verge-Phase darauf ab, Merkle-Bäume durch eine effizientere Struktur namensVerkle TreesVerkle-Bäume haben das Potenzial, kleinere Nachweisgrößen zu liefern, während sie das gleiche Sicherheitsniveau aufrechterhalten, was den Verifizierungsprozess für sowohl Beweiser als auch Verifizierer nachhaltiger und skalierbarer macht.

Kapitel 2: Revolutionierung der Verifizierbarkeit in Ethereum - The Verge

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 überprüfen, und eine Struktur zu schaffen, in der die Beteiligung für alle ohne Zentralisierung offen ist. Die Zugänglichkeit dieses Verifizierungsprozesses ist eine der Hauptmerkmale, die 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 jedoch diese Gewissheit aufrechtzuerhalten, muss die Ausführung eines Validators für alle zugänglich sein – eine Herausforderung, die im aktuellen System aufgrund von Speicher- und Rechenanforderungen begrenzt ist.

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

1. Für die Sicherstellung von Konsens: Unterstützung der ordnungsgemäßen Funktion sowohl probabilistischer als auch deterministischer Konsensprotokolle und Anwendung des Gabelwahlalgorithmus.
2. Überprüfung der Blockgenauigkeit: Nach Ausführung der Transaktionen in einem Block wird überprüft, ob der Wurzelknoten des resultierenden Zustandsbaums mit dem vom Antragsteller angegebenen Zustands-Wurzelknoten übereinstimmt.

Um die zweite Verantwortung zu erfüllen, müssen Validatoren Zugriff auf den Zustand vor dem Block haben. Dadurch können sie die Transaktionen des Blocks ausführen und den anschließenden Zustand ableiten. Diese Anforderung stellt jedoch eine hohe Belastung für die Validatoren dar, da sie mit erheblichen Speicheranforderungen umgehen müssen. Während Ethereum so konzipiert ist, dass es machbar ist und die Speicherkosten weltweit gesunken sind, geht es weniger um die Kosten und mehr um die Abhängigkeit von spezialisierter Hardware für die Validatoren. The Verge zielt darauf ab, diese Herausforderung zu bewältigen, indem eine Infrastruktur geschaffen wird, in der eine vollständige Überprüfung auch auf Geräten mit begrenztem Speicherplatz wie Mobiltelefonen, Browser-Geldbörsen und sogar Smartwatches durchgeführt werden kann, sodass Validatoren auf diesen Geräten ausgeführt werden können.

Erster Schritt der Überprüfbarkeit: Zustand

Die Umstellung auf Verkle Trees ist ein wesentlicher Bestandteil dieses Prozesses. Anfangs konzentrierte sich The Verge darauf, Ethereums Merkle-Tree-Strukturen durch Verkle Trees zu ersetzen. Der Hauptgrund für die Verwendung von Verkle Trees besteht darin, 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 drastisch in Worst-Case-Szenarien.

Laut Vitaliks Berechnungen beträgt die durchschnittliche Beweisgröße etwa 4 KB, was machbar klingt. In den schlimmsten Szenarien kann die Beweisgröße jedoch auf 330 MB anschwellen. Ja, Sie haben das richtig gelesen - 330 MB.

Die extreme Ineffizienz der Merkle-Bäume von Ethereum in den Worst-Case-Szenarien hat zwei Hauptgründe:

1. Verwendung von Hexary-Bäumen: Ethereum verwendet derzeit Merkle-Bäume mit einem Verzweigungsgrad von 16. Dies bedeutet, dass zur Überprüfung eines einzelnen Knotens die verbleibenden 15 Hashes im Zweig bereitgestellt werden müssen. Angesichts der Größe des Ethereum-Zustands und der Anzahl der Zweige entsteht dadurch eine erhebliche Belastung in Worst-Case-Szenarien.

1. Nicht-Merkelisierung des Codes: Anstatt den Vertragscode in die Baumstruktur zu integrieren, hashen Ethereum einfach den Code und verwenden den resultierenden Wert als Knoten. Angesichts der maximalen Größe eines Vertrags von 24 KB stellt dieser Ansatz eine erhebliche Belastung für die vollständige Verifizierbarkeit dar.

Die Beweisgröße steht direkt im Verhältnis zum Verzweigungsfaktor. Eine Verringerung des Verzweigungsfaktors verringert die Beweisgröße. Um diese Probleme anzugehen und die schlechtesten Szenarien zu verbessern, könnte Ethereum von Hexary Trees auf Binary Merkle Trees umsteigen und Vertragscodes merklisieren. Wenn der Verzweigungsfaktor in Ethereum von 16 auf 2 reduziert und auch Vertragscodes merklisiert werden, könnte die maximale Beweisgröße auf 10 MB schrumpfen. Obwohl dies eine bedeutende Verbesserung ist, ist es wichtig zu beachten, dass diese Kosten nur für die Überprüfung eines einzigen Datums gelten. Selbst eine einfache Transaktion, die auf mehrere Daten zugreift, würde größere Beweise erfordern. Angesichts der Anzahl von Transaktionen pro Block und dem ständig wachsenden Zustand von Ethereum ist diese Lösung, obwohl sie besser ist, immer noch nicht ganz realisierbar.

Aus diesen Gründen hat die Ethereum-Community zwei unterschiedliche Lösungen vorgeschlagen, um das Problem anzugehen:

1. Verkle Trees
2. STARK Proofs + Binäre Merkle-Bäume

Verkle Trees & Vector Commitments

Verkle-Bäume sind, wie der Name schon sagt, baumartige Strukturen, die Merkle-Bäumen ähneln. Der wesentliche Unterschied liegt jedoch in der Effizienz, die sie bei Verifizierungsprozessen bieten. Bei Merkle-Bäumen muss, wenn ein Zweig 16 Datenstücke enthält und wir nur eines davon überprüfen möchten, auch eine Hash-Kette, die die anderen 15 Stücke abdeckt, bereitgestellt werden. Dies erhöht die Berechnungsbelastung der Verifizierung erheblich und führt zu großen Nachweisgrößen.

Im Gegensatz dazu verwenden Verkle-Bäume eine spezialisierte Struktur, die als „Elliptic Curve-based Vector Commitments“ bekannt ist, genauer gesagt ein Inner Product Argument (IPA)-basiertes Vektor-Commitment. Ein Vektor ist im Wesentlichen eine Liste von Datenelementen, die in einer spezifischen Sequenz organisiert sind. Der Zustand von Ethereum kann als Vektor betrachtet werden: 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 wichtige Rolle bei Zugriff und Überprüfung spielt.

Vektorverpflichtungen sind kryptografische Methoden, die zur Beweisführung und Überprüfung von Datenelementen in einem Datensatz verwendet werden. Diese Methoden ermöglichen die Überprüfung sowohl der Existenz als auch der Reihenfolge jedes Elements in einem Datensatz gleichzeitig. Beispielsweise können Merkle-Beweise, die in Merkle-Bäumen verwendet werden, auch als eine Form von Vektorverpflichtung betrachtet werden. Während Merkle-Bäume alle relevanten Hash-Ketten zur Überprüfung eines Elements erfordern, beweist die Struktur inhärent, dass alle Elemente eines Vektors in einer bestimmten Reihenfolge miteinander verbunden sind.

Im Gegensatz zu Merkle Trees verwenden Verkle Trees elliptische Kurven basierte Vektorverpflichtungen, die zwei wesentliche Vorteile bieten:

• Vektorverpflichtungen auf Basis elliptischer Kurven beseitigen die Notwendigkeit von Informationen über Elemente, die nicht die zu überprüfenden Daten sind. Bei Merkle-Bäumen mit einem Verzweigungsgrad von 16 erfordert die Überprüfung eines einzelnen Zweigs das Bereitstellen der anderen 15 Hashes. Angesichts der großen Größe des Ethereum-Status, der viele Zweige umfasst, entsteht dadurch eine erhebliche Ineffizienz. Vektorverpflichtungen auf Basis elliptischer Kurven beseitigen jedoch diese Komplexität und ermöglichen eine Überprüfung mit weniger Daten und Rechenaufwand.
• Durch Mehrfachbeweise können die von elliptischen Kurven basierten Vektorverpflichtungen generierten Beweise in einen einzigen, konstanten Beweis komprimiert werden. Der Zustand von Ethereum ist nicht nur groß, sondern wächst auch kontinuierlich, was bedeutet, dass die Anzahl der Zweige, die zur Überprüfung des Merkle-Wurzels zugreifen müssen, im Laufe der Zeit zunimmt. Mit Verkle-Bäumen können wir jedoch die Beweise für jeden Zweig mithilfe der in der Methode detaillierten Methode in einen einzigen konstanten Beweis „komprimieren“.Dankrad Feists Artikel. Dies ermöglicht es Verifiern, den gesamten Baum mit einem kleinen Nachweis zu validieren, anstatt jede Zweigstelle einzeln zu überprüfen. Dies bedeutet auch, dass Verkle-Bäume vom Wachstum des Ethereum-Status unberührt bleiben.

Diese Funktionen der elliptischen Kurven-basierten Vektorverpflichtungen reduzieren signifikant die Menge an Daten, die für die Überprüfung benötigt wird, und ermöglichen es Verkle Trees, auch in Worst-Case-Szenarien kleine, konstante Beweise zu liefern. Dies minimiert den Datenoverhead und die Überprüfungszeiten und verbessert die Effizienz von groß angelegten Netzwerken wie Ethereum. Die Verwendung von elliptischen Kurven-basierten Vektorverpflichtungen in Verkle Trees ermöglicht somit eine einfachere und effizientere Verwaltung des sich ausdehnenden Zustands von Ethereum.

Wie alle Innovationen haben Verkle-Bäume ihre Grenzen. Einer ihrer Hauptnachteile ist, dass sie auf elliptische Kurvenkryptographie angewiesen sind, die anfällig für Quantencomputer ist. Quantencomputer besitzen eine weit größere Rechenleistung als klassische Methoden und stellen eine erhebliche Bedrohung für elliptische Kurven-basierte kryptographische Protokolle dar. Quantenalgorithmen könnten diese kryptografischen Systeme potenziell brechen oder schwächen, was Bedenken hinsichtlich der langfristigen Sicherheit von Verkle-Bäumen aufwirft.

Aus diesem Grund bieten Verkle Trees zwar eine vielversprechende Lösung für die Staatenlosigkeit, sind aber nicht die ultimative Lösung. Dennoch haben Personen wie Dankrad Feist betont, dass bei der Integration quantenresistenter Kryptographie in Ethereum eine sorgfältige Abwägung erforderlich ist. Es ist jedoch erwähnenswert, dass die KZG-Verpflichtungen, die derzeit für Blobs in Ethereum verwendet werden, ebenfalls nicht quantenresistent sind. Somit können Verkle Trees als Übergangslösung dienen und dem Netzwerk zusätzliche Zeit geben, um robustere Alternativen zu entwickeln.

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

Verkle Trees bieten im Vergleich zu Merkle Trees kleinere Beweisgrößen und effiziente Verifizierungsprozesse, was es einfacher macht, den immer weiter wachsenden Zustand von Ethereum zu verwalten. Dank elliptisch-kurvebasierten Vektor-Verpflichtungen können groß angelegte Beweise mit wesentlich weniger Daten generiert werden. Trotz ihrer beeindruckenden Vorteile sind Verkle Trees jedoch anfällig für Quantencomputer und daher nur eine vorübergehende Lösung. Während die Ethereum-Community Verkle Trees als kurzfristiges Werkzeug betrachtet, um Zeit zu gewinnen, liegt der langfristige Fokus auf dem Übergang zu quantenresistenten Lösungen. Hier bieten STARK Proofs und Binary Merkle Trees eine starke Alternative für den Aufbau einer robusteren Verifizierungsinfrastruktur für die Zukunft.

Im Ethereum-Statusüberprüfungsprozess kann der Verzweigungsfaktor von Merkle-Bäumen (von 16 auf 2) durch die Verwendung von binären Merkle-Bäumen reduziert werden. Diese Änderung ist ein wichtiger Schritt, um die Größe der Nachweise zu reduzieren und die Überprüfungsprozesse effizienter zu gestalten. In extremen Fällen können die Beweisgrößen jedoch immer noch 10 MB erreichen, was erheblich 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 Beschränkungen beim Betrieb von Validatoren auf Leichtgewichtsclients oder Geräten mit begrenzter Hardware in Betracht zieht, insbesondere wenn man berücksichtigt, dass die durchschnittlichen globalen mobilen Download- und Upload-Geschwindigkeiten etwa 7,625 MB/s bzw. 1,5 MB/s betragen. Benutzer können Transaktionen mit kleinen, tragbaren Nachweisen verifizieren, ohne auf den vollständigen Zustand zugreifen zu müssen, und Validatoren können Blockverifizierungsaufgaben ohne Speicherung des gesamten Zustands durchführen.

Dieser Dual-Benefit-Ansatz reduziert sowohl den Bandbreiten- als auch den Speicherbedarf für Validatoren, beschleunigt gleichzeitig die Überprüfung und führt zu drei wichtigen Verbesserungen, die die Vision von Ethereum für Skalierbarkeit direkt unterstützen.

Hauptprobleme für STARK-Beweise:

1. Hohe Rechenlast für Beweiser: \
   Der Prozess der Generierung von STARK-Beweisen ist rechenintensiv, insbesondere auf Seiten des Beweisers, was die Betriebskosten erhöhen kann.
2. Ineffizienz bei kleinen Datenbeweisen:

Während STARK-Beweise bei der Verarbeitung großer Datensätze hervorragend sind, sind sie weniger effizient, wenn es darum geht, kleine Datenmengen nachzuweisen, was ihre Anwendung in bestimmten Szenarien behindern kann. Bei der Arbeit mit Programmen, die kleinere Schritte oder Datensätze beinhalten, kann die relativ große Beweisgröße von STARKs sie weniger praktisch oder kostengünstig machen.

Quantensicherheit hat ihren Preis: Prover-seitige Rechenlast

Ein Block-Merkle-Beweis kann etwa 330.000 Hashes enthalten, und in Extremfällen kann diese Zahl auf 660.000 steigen. In solchen Fällen müsste ein STARK-Beweis etwa 200.000 Hashes pro Sekunde verarbeiten.

Hier kommen zk-freundliche Hash-Funktionen wie Poseidon ins Spiel, die speziell für STARK-Beweise optimiert sind, um diese Last zu reduzieren. Poseidon ist so konzipiert, dass es im Vergleich zu traditionellen Hash-Algorithmen wie SHA256 und Keccak reibungsloser mit ZK-Proofs zusammenarbeitet. Der Hauptgrund für diese Kompatibilität liegt darin, wie traditionelle Hash-Algorithmen arbeiten: Sie verarbeiten Eingaben als binäre Daten (0 und 1). Auf der anderen Seite arbeiten ZK-Proofs mit Primfeldern, mathematischen Strukturen, die grundlegend anders sind. Diese Situation ist analog dazu, dass Computer im Binärsystem arbeiten, während Menschen im täglichen Leben ein dezimales System verwenden. Die Umwandlung von bitbasierten Daten in ZK-kompatible Formate erfordert erheblichen Rechenaufwand. Poseidon löst dieses Problem, indem es nativ in Primfeldern arbeitet und seine Integration mit ZK-Beweisen dramatisch beschleunigt.

Allerdings erfordert Poseidon aufgrund seiner relativen Neuheit als Hash-Funktion eine umfangreichere Sicherheitsanalyse, um das gleiche Vertrauensniveau wie traditionelle Hash-Funktionen wie SHA256 und Keccak zu gewährleisten. Zu diesem Zweck gibt es Initiativen wie die Poseidon Kryptanalyse-Initiativevom Ethereum Foundation gestartet, laden Experten dazu ein, Poseidons Sicherheit rigoros zu testen und zu analysieren, um sicherzustellen, dass es adversarischen Prüfungen standhalten kann und zu einem robusten Standard für kryptografische Anwendungen wird. Auf der anderen Seite wurden ältere Funktionen wie SHA256 und Keccak bereits umfangreich getestet und haben eine nachgewiesene Sicherheitsbilanz, sind jedoch nicht ZK-freundlich, was zu Leistungseinbußen führt, wenn sie mit STARK-Beweisen verwendet werden.

Beispielsweise können STARK-Nachweise 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 sich diese Durchsatzrate bald auf 100.000 bis 200.000 Hashes erhöhen könnte, was ihre Effizienz erheblich verbessern würde.

STARKs’ Ineffizienz bei der Beweisführung kleiner Daten

Während STARK-Beweise in Bezug auf Skalierbarkeit und Transparenz für große Datensätze hervorragend sind, zeigen sie Einschränkungen, wenn es um die Arbeit mit kleinen und zahlreichen Datenelementen geht. In diesen Szenarien ist die zu beweisende Datenmenge oft klein, aber der Bedarf an mehreren Beweisen bleibt unverändert. Beispiele sind:

1. Post-AA Transaktionsvalidierung: \
   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 damit verbundener Daten im Zustand, um die Transaktionsgültigkeit nachzuweisen.
2. Leichte Client-RPC-Aufrufe: \
   Leichte Clients können Statusdaten aus dem Netzwerk abfragen (z.B. während einer eth_call-Anfrage), ohne einen vollständigen Knoten auszuführen. Um die Richtigkeit dieses Status zu garantieren, müssen Beweise die abgefragten Daten unterstützen und bestätigen, dass sie dem aktuellen Status des Netzwerks entsprechen.
3. Inklusionslisten: \
   Kleinere Validatoren können Inklusionslistenmechanismen verwenden, um sicherzustellen, dass Transaktionen im nächsten Block enthalten sind und den Einfluss mächtiger Blockproduzenten begrenzen. Das Überprüfen der Einbeziehung dieser Transaktionen erfordert jedoch die Überprüfung ihrer Korrektheit.

In solchen Anwendungsfällen bieten STARK-Nachweise nur wenig Vorteile. STARKs, die Skalierbarkeit betonen (wie durch das „S“ in ihrem Namen hervorgehoben), funktionieren gut für große Datensätze, haben jedoch Probleme mit kleinen Datenszenarien. Im Gegensatz dazu sind SNARKs, die auf Kürze ausgelegt sind (wie durch das „S“ in ihrem Namen betont), darauf ausgerichtet, die Größe des Nachweises zu minimieren und bieten klare Vorteile in Umgebungen mit Bandbreiten- oder Speicherbeschränkungen.

STARK-Beweise sind in der Regel 40-50 KB groß, was etwa 175 Mal größer ist als SNARK-Beweise, die nur 288 Bytes groß sind. Dieser Größenunterschied erhöht sowohl die Überprüfungszeit als auch die Netzwerkkosten. Der Hauptgrund für die größeren STARK-Beweise liegt in ihrer Abhängigkeit von Transparenz und Polynomverpflichtungen, um Skalierbarkeit sicherzustellen, was in kleinen Datenszenarien zu Leistungseinbußen führt. In solchen Fällen können schnellere und platzsparendere Methoden wie Merkle-Beweise praktischer sein. Merkle-Beweise bieten geringe Rechenkosten und schnelle Updates, wodurch sie für diese Situationen geeignet sind.

Dennoch bleiben STARK-Beweise aufgrund ihrer quantensicheren Eigenschaften entscheidend für die zustandslose Zukunft von Ethereum.

Wie in der Tabelle zusammengefasst, hat Ethereum vier potenzielle Pfade zur Auswahl:

• Verkle Bäume
  1. Verkle Trees haben breite Unterstützung von der Ethereum-Community erhalten, mit zweiwöchentlichen Treffen, um ihre Entwicklung zu erleichtern. Dank dieser konsequenten Arbeit und Tests zeichnen sich Verkle Trees als die ausgereifteste und am besten erforschte Lösung unter den aktuellen Alternativen aus. Darüber hinaus entfällt aufgrund ihrer additiv homomorphen Eigenschaften die Notwendigkeit, jeden Zweig neu zu berechnen, um die Zustandswurzel zu aktualisieren, im Gegensatz zu Merkle-Bäumen, was Verkle-Bäume zu einer effizienteren Option macht. Im Vergleich zu anderen Lösungen legt Verkle Trees Wert auf Einfachheit und hält sich an technische Prinzipien wie “Keep it simple” oder “Simple is the Best”. Diese Einfachheit erleichtert sowohl die Integration in Ethereum als auch die Sicherheitsanalyse.
  2. Verkle Trees sind jedoch nicht quantensicher, was sie zu keiner langfristigen Lösung macht. Wenn sie in Ethereum integriert werden, müsste diese Technologie wahrscheinlich in Zukunft durch quantensichere Lösungen ersetzt werden. Selbst Vitalik betrachtet Verkle Trees als eine vorübergehende Maßnahme, um Zeit für die Reife von STARKs und anderen Technologien zu gewinnen. Darüber hinaus erfordern die elliptischen Kurven-basierten Vektorverpflichtungen, die in Verkle Trees verwendet werden, eine höhere Rechenlast im Vergleich zu einfachen Hash-Funktionen. Hash-basierte Ansätze können schnellere Synchronisierungszeiten für vollständige Knoten bieten. Darüber hinaus erschwert die Abhängigkeit von zahlreichen 256-Bit-Operationen die Verkleinerung von Verkle Trees mit SNARKs innerhalb moderner Beweissysteme, was zukünftige Bemühungen zur Reduzierung von Beweisgrößen kompliziert.

Dennoch ist es wichtig zu beachten, dass Verkle-Bäume aufgrund ihrer Unabhängigkeit von Hashing wesentlich überzeugender sind als Merkle-Bäume.

• STARKs + Konservative Hashfunktionen
  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 weit verbreitet verwendet und umfangreich getestet. Darüber hinaus verbessert 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 Rechenanforderungen dieser Hash-Funktionen führen zu einer hohen Prover-Latenz, wobei die Beweisgenerierung über 10 Sekunden dauert. Dies ist ein großer Nachteil, insbesondere in Szenarien wie der Blockvalidierung, die eine geringe Latenz erfordern. Obwohl Bemühungen wie multidimensionale Gasvorschläge versuchen, die Latenz im Worst-Case und Durchschnittsfall abzustimmen, 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 breiteren Skalierbarkeitszielen von STARKs. Die langen Berechnungszeiten herkömmlicher Hash-Funktionen verringern die praktische Effizienz und schränken ihre Anwendbarkeit ein.
• STARKs + Relative neue Hash-Funktionen
  1. STARKs kombiniert mit neuen STARK-freundlichen Hash-Funktionen der nächsten Generation (z.B. Poseidon) verbessern signifikant die Leistung dieser Technologie. Diese Hash-Funktionen sind darauf ausgelegt, nahtlos in STARK-Systeme zu integrieren und die Beweisverzögerung drastisch zu reduzieren. Im Gegensatz zu traditionellen Hash-Funktionen ermöglichen sie die Generierung von Beweisen in nur 1-2 Sekunden. Ihre Effizienz und geringer Rechenaufwand erhöhen das Skalierungspotenzial von STARKs erheblich und machen sie äußerst effektiv für die Verarbeitung großer Datensätze. Diese Fähigkeit macht sie besonders attraktiv für Anwendungen, die eine hohe Leistung erfordern.
  2. Die relative Neuheit dieser Hash-Funktionen erfordert umfangreiche Sicherheitsanalysen und Tests. Die mangelnde umfassende Testung birgt Risiken bei der Überlegung, sie in kritischen Ökosystemen wie Ethereum zu implementieren. Da diese Hash-Funktionen zudem noch nicht weit verbreitet sind, könnten die erforderlichen Test- und Validierungsprozesse die Verifizierungsziele 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 Verifizierungsambitionen 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 adressieren die Schwächen von Verkle-Bäumen und STARKs und gelten als vielversprechende langfristige Option. Mit ihrem gitterbasierten Design bieten sie eine starke Resistenz gegen Bedrohungen durch Quantencomputing und entsprechen Ethereums Fokus auf die Zukunftssicherung seines Ökosystems. Darüber hinaus sollen sie durch Beibehaltung der Aktualisierungsvorteile von Verkle-Bäumen eine verbesserte Sicherheit ohne Beeinträchtigung der Effizienz liefern.
  2. Allerdings befindet sich die Forschung zu gitterbasierten Merkle-Bäumen noch in einem frühen Stadium und ist größtenteils theoretischer Natur. Dies schafft erhebliche Unsicherheiten 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 validieren. Diese Unsicherheiten und infrastrukturellen Komplexitäten machen gitterbasierte Merkle-Bäume in naher Zukunft für Ethereum wahrscheinlich zu einer wenig realistischen Wahl, was möglicherweise den Fortschritt bei den Verifizierungszielen des Netzwerks verzögert.

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

Alles, was wir bisher besprochen haben, dreht sich darum, die Notwendigkeit für Validatoren zu entfernen, den vorherigen Zustand zu speichern, den sie verwenden, um vom einen Zustand zum nächsten zu wechseln. Das Ziel ist es, eine dezentralere Umgebung zu schaffen, in der Validatoren ihre Aufgaben ohne die Aufbewahrung von Terabytes von Zustandsdaten ausführen können. Selbst mit den genannten Lösungen müssten Validatoren nicht den gesamten Zustand speichern, da sie alle für die Ausführung erforderlichen Daten durch Zeugen erhalten würden, die mit dem Block mitgeliefert werden. Um jedoch zum nächsten Zustand überzugehen und damit den stateRoot auf dem Block zu verifizieren, müssen Validatoren immer noch die STF selbst ausführen. Diese Anforderung stellt wiederum eine weitere Herausforderung für die permissionless Natur und Dezentralisierung von Ethereum dar.

Ursprünglich wurde The Verge als Meilenstein konzipiert, der sich ausschließlich auf den Übergang des Ethereum-Zustandsbaums von Merkle-Bäumen zu Verkle-Bäumen konzentrierte, um die Zustandsüberprüfbarkeit zu verbessern. Im Laufe der Zeit hat es sich jedoch zu einer breiteren Initiative entwickelt, die darauf abzielt, die Überprüfbarkeit von Zustandsübergängen und Konsens zu verbessern. In einer Welt, in der das Trio aus Zustand, Ausführung und Konsens vollständig überprüfbar ist, könnten Ethereum-Validatoren auf praktisch jedem Gerät mit Internetverbindung arbeiten, das als Leichtclient kategorisiert werden kann. Dies würde Ethereum näher an die Verwirklichung seiner Vision von „wahrer Dezentralisierung“ bringen.

Was ist die Problemdefinition?

Wie bereits erwähnt, führen Validatoren alle 12 Sekunden eine Funktion namens STF (State Transition Function) aus. Diese Funktion nimmt den vorherigen Zustand und einen Block als Eingabe und erzeugt den nächsten Zustand 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 Zustand oben auf dem Block repräsentiert - allgemein als State Root bezeichnet - korrekt ist.

Die hohen Systemanforderungen für die Validierung resultieren hauptsächlich aus der Notwendigkeit, diesen Prozess effizient durchzuführen.

Wenn Sie einen Smart-Kühlschrank - ja, sogar einen Kühlschrank - mithilfe von installierter Software in einen Ethereum-Validierer verwandeln möchten, stehen Sie vor zwei großen Hindernissen:

1. Ihr Kühlschrank wird höchstwahrscheinlich kein ausreichend schnelles Internet haben, was bedeutet, dass er die für die Ausführung benötigten Daten und Nachweise selbst mit den bisher besprochenen Lösungen zur Zustandsüberprüfung nicht herunterladen kann.
2. Auch wenn es Zugriff auf die für STF erforderlichen Daten hätte, würde es nicht über die erforderliche Rechenleistung verfügen, um die Ausführung von Anfang bis Ende durchzuführen oder um einen neuen Zustandsbaum aufzubauen.

Um die Probleme zu lösen, die durch Light Clients verursacht werden, die keinen Zugriff auf den vorherigen Zustand oder den gesamten letzten Block haben, schlägt The Verge vor, dass der Vorschlagende die Ausführung durchführen und dann einen Beweis an den Block anhängen sollte. Dieser Beweis würde den Übergang vom vorherigen Zustands-Root zum nächsten Zustands-Root sowie den Hash des Blocks enthalten. Mithilfe von nur drei 32-Byte-Hashes können Light Clients den Zustandsübergang validieren, ohne einen zk-Beweis zu benötigen.

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

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

1. Der Block selbst muss gültig sein, und der Zustandsbeweis darin - ob ein Verkle-Beweis oder STARKs - muss die Daten, die den Block begleiten, genau überprüfen.
   Kurz gesagt: Validierung des Blocks und des dazugehörigen Zustandsnachweises.
2. Wenn der STF unter Verwendung der für die Ausführung erforderlichen Daten ausgeführt wird und im Block entsprechend zu H enthalten ist, 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 zuvor erwähnten Prover-Verifier-Analogie kann man im Allgemeinen sagen, dass es in der Regel ein rechnerisches Gleichgewicht zwischen den beiden Akteuren gibt. Während die Fähigkeit von Nachweisen, die benötigt werden, um das STF überprüfbar zu machen und gleichzeitig mehrere Dinge zu validieren, erhebliche Vorteile für den Verifier bietet, deutet dies auch darauf hin, dass es für den Prover relativ herausfordernd sein wird, solche Nachweise zu generieren, um die Ausführungskorrektur sicherzustellen. Mit der aktuellen Geschwindigkeit von Ethereum muss ein Ethereum-Block in weniger als 4 Sekunden nachgewiesen werden. Allerdings kann selbst der schnellste EVM Prover, den wir heute haben, im Durchschnitt nur einen Block in etwa 15 Sekunden nachweisen.[1]

Das gesagt, es gibt drei verschiedene Wege, die wir nehmen können, um diese große Herausforderung zu überwinden:

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

Während der Beweisgenerierung kann jedes kleine Stück des Ausführungsprozesses (z.B. Berechnungsschritte oder Datenzugriffe) einzeln nachgewiesen werden, und diese Nachweise können später in eine einzige Struktur aggregiert werden. Mit dem richtigen Mechanismus ermöglicht dieser Ansatz, dass die Beweise für einen Block schnell und dezentral von vielen verschiedenen Quellen (z.B. Hunderten von GPUs) generiert werden können. Dies steigert die Leistung und trägt gleichzeitig zum Ziel der Dezentralisierung bei, indem eine breitere Gruppe von Teilnehmern einbezogen wird.

1. Mit optimierten Beweissystemen arbeiten: Neue Generationen von Beweissystemen haben das Potenzial, die Rechenprozesse von Ethereum schneller und effizienter zu machen. Fortgeschrittene Systeme wie Orion, Binius, und GKRkann die Beweiszeit für allgemeine Berechnungen erheblich reduzieren. Diese Systeme zielen darauf ab, die Einschränkungen aktueller Technologien zu überwinden, die Verarbeitungsgeschwindigkeit zu erhöhen und dabei weniger Ressourcen zu verbrauchen. Für ein skalierungs- und effizienzorientiertes Netzwerk wie Ethereum bieten solche Optimierungen einen erheblichen Vorteil. Die vollständige Implementierung dieser neuen Systeme erfordert jedoch umfassende Tests und Kompatibilitätsbemühungen innerhalb des Ökosystems.
2. Änderungen der Gasgebühren: Historisch gesehen wurden die Gasgebühren für Operationen auf der Ethereum Virtual Machine (EVM) typischerweise auf der Grundlage ihrer Berechnungskosten bestimmt. Heute hat jedoch eine andere Metrik an Bedeutung gewonnen: die Komplexität des Beweises. Während einige Operationen relativ einfach zu beweisen sind, haben andere eine komplexere Struktur und benötigen mehr Zeit zur Überprüfung. Eine Anpassung der Gasgebühren nicht nur aufgrund des Berechnungsaufwands, sondern auch aufgrund der Schwierigkeit der Beweisführung von Operationen ist entscheidend für die Verbesserung der Sicherheit und Effizienz des Netzwerks.

Dieser Ansatz kann den Unterschied zwischen dem schlechtesten Fall und dem Durchschnittsfall minimieren und so eine konsistentere Leistung ermöglichen. Beispielsweise könnten Operationen, die schwerer zu beweisen sind, höhere Gaspreise haben, während solche, die einfacher zu beweisen sind, niedrigere Kosten haben könnten. Darüber hinaus könnte die Ersetzung 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, während seine Verifizierbarkeitsvision realistischer wird.

Die Bemühungen von Ethereum, Ausführungsnachweise zu ermöglichen, stellen eine bedeutende Chance dar, ihre Verifizierungsziele zu erreichen. Das Erreichen dieses Ziels erfordert jedoch nicht nur technische Innovationen, sondern auch erhöhte Engineering-Anstrengungen und kritische Entscheidungen innerhalb der Gemeinschaft. Die Verifizierung von Ausführungsprozessen auf Layer 1 muss ein Gleichgewicht zwischen der Zugänglichkeit für eine breite Benutzerbasis und der Erhaltung der Dezentralisierung und der Ausrichtung an die bestehende Infrastruktur finden. Die Herstellung dieses Gleichgewichts erhöht die Komplexität der zur Beweisführung während der Ausführung verwendeten Methoden und unterstreicht die Notwendigkeit von Fortschritten wie der parallelen Beweisgenerierung. Darüber hinaus erhöht die Infrastrukturanforderungen dieser Technologien (z. B. Suchtabellen) muss implementiert und operationalisiert werden, was noch umfangreiche Forschung und Entwicklung erfordert.

Auf der anderen Seite weisen spezialisierte Schaltkreise (z.B. ASICs, FPGAs, GPUs), die speziell für bestimmte Aufgaben entwickelt wurden, ein erhebliches Potenzial zur Beschleunigung des Proof-Generierungsprozesses auf. Diese Lösungen bieten im Vergleich zur traditionellen Hardware eine wesentlich höhere Effizienz und können die 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 wird erwartet, dass diese Lösungen in Layer 2-Systemen häufiger verwendet werden. Dennoch muss die Community auch einen Konsens über die Hardware-Anforderungen für die Proof-Generierung finden. Eine wichtige Designfrage stellt sich: Sollte die Proof-Generierung auf Consumer-Hardware wie High-End-Laptops oder auf industrielle Infrastruktur angewiesen sein? Die Antwort prägt die gesamte Architektur von Ethereum und ermöglicht eine aggressive Optimierung für Layer 2-Lösungen, während für Layer 1 konservativere Ansätze erforderlich sind.

Die Implementierung von Ausführungsnachweisen ist eng mit anderen Zielen des Ethereum-Roadmaps verbunden. Die Einführung von Gültigkeitsnachweisen würde nicht nur Konzepte wie Zustandslosigkeit unterstützen, sondern auch die Dezentralisierung von Ethereum verbessern, indem Bereiche wie Solo-Staking zugänglicher gemacht werden. Das Ziel ist es, Staking sogar auf den leistungsschwächsten Geräten zu ermöglichen. Darüber hinaus könnten eine Neustrukturierung der Gasgebühren auf der EVM basierend auf rechnerischer Schwierigkeit und Nachweisbarkeit die Kluft zwischen Durchschnitts- und Worst-Case-Szenarien minimieren. Solche Änderungen könnten jedoch die Abwärtskompatibilität mit dem aktuellen System beeinträchtigen und Entwickler dazu zwingen, ihren Code neu zu schreiben. Aus diesem Grund ist die Implementierung von Ausführungsnachweisen nicht nur eine technische Herausforderung, sondern auch eine Reise, die darauf ausgerichtet sein muss, die langfristigen Werte von Ethereum aufrechtzuerhalten.

Letzter Schritt zur wahren Vollständigkeitsprüfung: Konsens

Ethereums Konsensmechanismus strebt danach, ein einzigartiges Gleichgewicht zu schaffen, das Dezentralisierung und Zugänglichkeit bewahrt, während gleichzeitig Verifizierungsziele erreicht werden. In diesem Rahmen bieten probabilistische und deterministische Konsensmethoden unterschiedliche Vorteile und Herausforderungen.

Das probabilistische Konsensmodell basiert auf einem Klatsch-Kommunikationsmodell. In diesem Modell teilt ein Knoten anstelle der direkten Kommunikation mit allen Knoten, die das Netzwerk repräsentieren, Informationen mit einem zufällig ausgewählten Satz 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 werden sich diese Auswahl jedoch voraussichtlich mit einer Fehlerquote von 0% zum korrekten Blockkette hinbewegen, wenn die Blockkette fortschreitet.

Ein Vorteil der probabilistischen Struktur ist, dass jeder Knoten seine Kettenansicht nicht als separate Nachricht sendet, was die Kommunikationsüberlastung reduziert. Infolgedessen kann eine solche Struktur mit weit mehr permissionless, dezentralen Knoten mit geringeren Systemanforderungen arbeiten. Im Gegensatz dazu arbeitet der deterministische Konsens über ein Ein-zu-Alle-Kommunikationsmodell. Hier sendet ein Knoten seine Kettenansicht als Abstimmung an alle anderen Knoten. Dieser Ansatz erzeugt eine höhere Nachrichtenintensität, und mit zunehmender Anzahl von Knoten erreicht das System möglicherweise irgendwann seine Grenzen. Der größte Vorteil des deterministischen Konsenses besteht jedoch in der Verfügbarkeit konkreter Stimmen, die es Ihnen ermöglichen, genau zu wissen, welcher Knoten für welche Gabelung gestimmt hat. Dies gewährleistet eine schnelle und endgültige Kettenfinalität, wodurch sichergestellt wird, dass Blöcke nicht in ihrer Reihenfolge geändert werden können und sie überprüfbar sind.

Um einen überprüfbaren Konsensmechanismus zu gewährleisten und gleichzeitig Dezentralisierung und eine erlaubnisfreie Struktur zu erhalten, hat Ethereum einen Kompromiss zwischen Slots und Epochen gefunden. Slots stellen 12-Sekunden-Intervalle dar und sind die grundlegenden Einheiten, in denen ein Validator für die Produktion eines Blocks verantwortlich ist. Obwohl der probabilistische Konsens auf Slot-Ebene eine flexiblere und dezentralisierte Arbeitsweise der Chain ermöglicht, hat er Einschränkungen in Bezug auf die eindeutige Reihenfolge und Überprüfbarkeit.

Epochen, die 32 Slots umfassen, führen deterministischen Konsens ein. Auf dieser Ebene stimmen die Validatoren über die Finalisierung der Kettenreihenfolge ab, um Gewissheit zu gewährleisten und die Verifizierung der Kette zu ermöglichen. Allerdings kann diese deterministische Struktur, die durch konkrete Abstimmungen auf der Epochen-Ebene Verifizierbarkeit bietet, innerhalb der Epochen selbst keine vollständige Verifizierbarkeit bieten aufgrund der probabilistischen Struktur. Um diese Lücke zu schließen und die probabilistische Struktur innerhalb der Epochen zu stärken, hat Ethereum eine Lösung namens das Sync-Komitee entwickelt.

Altairs Light-Client-Protokoll: Sync-Komitee

Das Sync-Komitee ist ein Mechanismus, der mit dem Altair-Upgrade eingeführt wurde, um die Einschränkungen des probabilistischen Konsenses von Ethereum zu überwinden und die Überprüfbarkeit der Kette für leichte Clients zu verbessern. Das Komitee besteht aus 512 zufällig ausgewählten Validatoren, die für 256 Epochen (~27 Stunden) dienen. Diese Validatoren erzeugen eine Signatur, die den Kopf der Kette repräsentiert, und ermöglichen es leichten Clients, die Gültigkeit der Kette zu überprüfen, ohne historische Ketten-Daten herunterladen zu müssen. Der Betrieb des Sync-Komitees kann wie folgt zusammengefasst werden:

1. Bildung des Ausschusses:
   512 Validatoren werden zufällig aus allen Validatoren im Netzwerk ausgewählt. Diese Auswahl wird regelmäßig aktualisiert, um Dezentralisierung zu gewährleisten und von einer bestimmten Gruppe abhängig abzusehen.
2. Signaturerstellung:
   Die Ausschussmitglieder erstellen eine Signatur, die den neuesten Stand der Kette repräsentiert. Diese Signatur ist eine kollektive BLS-Signatur, die von den Mitgliedern erstellt wird und zur Überprüfung der Gültigkeit der Kette verwendet wird.
3. Light Client Verification:
   Leichte Clients können die Richtigkeit der Kette einfach überprüfen, indem sie die Signatur des Sync-Komitees überprüfen. Dies ermöglicht es ihnen, die Kette sicher zu verfolgen, ohne vergangene Ketten-Daten herunterzuladen.

Allerdings wurde das Sync-Komitee in einigen Bereichen kritisiert. Insbesondere fehlt es dem Protokoll an einem Mechanismus zum Kürzen von Validatoren bei bösartigem Verhalten, auch wenn die ausgewählten Validatoren absichtlich gegen das Protokoll handeln. Aus diesem Grund betrachten viele das Sync-Komitee als Sicherheitsrisiko und zögern, es vollständig als Light-Client-Protokoll zu klassifizieren. Dennoch wurde die Sicherheit des Sync-Komitees mathematisch bewiesen, und weitere Details finden sich in Dieser 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 Validator beobachtet. Selbst wenn die Mehrheit der Validator*innen eine bestimmte Gabelung als die schwerere meldet, können immer noch außergewöhnliche Validator*innen eine andere Gabelung als schwerer betrachten. Diese Unsicherheit erschwert den Nachweis böswilliger Absichten und macht es daher unmöglich, Fehlverhalten zu bestrafen.

In diesem Zusammenhang wäre es genauer, das Sync Committee als eine ineffiziente Lösung zu beschreiben, anstatt es als unsicher zu bezeichnen. Das Problem liegt nicht in der mechanischen Konstruktion oder dem Betrieb des Sync Committee, sondern in der inhärenten Natur des probabilistischen Konsenses. Da der probabilistische Konsens keine definitive Garantie dafür bieten kann, was 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 in Bezug auf die Gewährleistung der finalen Kette. Das Problem liegt nicht im 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 deterministische Endgültigkeit in kürzeren Zeiträumen bieten. Vorschläge wie Orbit-SSFund3SFZiel ist es, die Konsensstruktur von Ethereum von Grund auf neu zu gestalten, um ein effektiveres System zur Ersetzung des Wahrscheinlichkeitskonsenses zu schaffen. 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 setzt die aktive Entwicklung und Vorbereitung dieser Vorschläge für zukünftige Umsetzungen fort.

Snarkification des Konsenses

The Verge zielt darauf ab, die aktuellen und zukünftigen Konsensmechanismen von Ethereum zu verbessern, indem sie durch die zk-proof-Technologie verifizierbarer gemacht werden, anstatt sie vollständig zu ersetzen. Dieser Ansatz zielt darauf ab, die Konsensprozesse von Ethereum zu modernisieren, während seine Kernprinzipien der Dezentralisierung und Sicherheit erhalten bleiben. Die Optimierung aller historischen und aktuellen Konsensprozesse der Chain mit zk-Technologien spielt eine entscheidende Rolle bei der Erreichung der langfristigen Skalierbarkeits- und Effizienzziele von Ethereum. Die in der Konsensschicht von Ethereum verwendeten grundlegenden Operationen sind von großer Bedeutung bei dieser technologischen Transformation. Werfen wir einen genaueren Blick auf diese Operationen und die Herausforderungen, vor denen sie stehen.

• ECADDs:
  • Zweck: Diese Operation wird verwendet, um die öffentlichen Schlüssel von Validatoren zu aggregieren und ist entscheidend für die Genauigkeit und Effizienz der Kette. Dank der aggregierbaren Natur von BLS-Signaturen können mehrere Signaturen zu einer einzigen Struktur kombiniert werden. Dies reduziert die Kommunikationsüberlastung und macht die Verifizierungsprozesse in der Kette effizienter. Die Sicherstellung einer effektiveren Synchronisation großer Validatorengruppen macht diese Operation kritisch.
  • Herausforderungen: Wie bereits erwähnt, stimmen die Validatoren von Ethereum während der Epochen über die Reihenfolge der Kette ab. Heute ist Ethereum ein Netzwerk mit etwa 1,1 Millionen Validatoren. Wenn alle Validatoren versuchen würden, ihre Stimmen gleichzeitig zu verbreiten, würde dies eine erhebliche Belastung für das Netzwerk darstellen. Um dies zu vermeiden, ermöglicht Ethereum den Validatoren, slotweise während einer Epoche abzustimmen, bei dem nur 1/32 aller Validatoren pro Slot stimmen. Obwohl dieser Mechanismus den Overhead der Netzwerkkommunikation reduziert und den Konsens effizienter macht, stimmen bei der aktuellen Anzahl von Validatoren etwa 34.000 Validatoren in jedem Slot ab. Das bedeutet ungefähr 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 und daher extrem teuer, um mit zk-Proof-Technologie zu beweisen. Dies stellt eine große Herausforderung bei der Schaffung eines integrierten Verifikationsprozesses mit Zero-Knowledge-Technologien dar.
  • Herausforderungen: Pairing-Operationen in Ethereum sind auf maximal 128 Attestationen (aggregierte Signaturen) pro Slot begrenzt, was zu weniger Pairing-Operationen im Vergleich zu ECADDs führt. Die mangelnde ZK-Freundlichkeit bei diesen Operationen stellt jedoch eine erhebliche Herausforderung dar. Der Nachweis einer Pairing-Operation mit ZK-Beweisen 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 Konsens-Verifizierungsprozessen 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 der zk-Proof-basierten Verifizierung und stellt ein großes Hindernis für die zukünftigen Verifizierungsziele von Ethereum dar.
  • Herausforderungen: SHA256-Hashfunktionen werden häufig zum Lesen und Aktualisieren des Zustands der Kette verwendet. Ihre zk-Unfreundlichkeit steht jedoch im Konflikt mit den zk-basierten Verifikationszielen von Ethereum. Zum Beispiel führt jeder Validator zwischen zwei Epochen die STF des Ethereum Consensus Layer aus, um den Zustand anhand der Leistung des Validators während der Epoche mit Belohnungen und Strafen zu aktualisieren. Dieser Prozess basiert stark auf SHA256-Hashfunktionen und erhöht die Kosten in zk-proof-basierten Systemen erheblich. Dadurch entsteht eine erhebliche Hürde, um den Konsensmechanismus von Ethereum mit zk-Technologien in Einklang zu bringen.

Die in der aktuellen Konsensschicht verwendeten ECADD-, Pairing- und SHA256-Operationen spielen eine entscheidende Rolle bei den Verifizierungszielen von Ethereum. Ihre mangelnde zk-Freundlichkeit stellt jedoch erhebliche Herausforderungen auf dem Weg zur Erreichung dieser Ziele dar. ECADD-Operationen schaffen eine kostspielige Belastung aufgrund der hohen Anzahl von Validatorenstimmen, während Pairing-Operationen trotz ihrer geringeren Anzahl tausendmal teurer sind, um mit zk-Beweisen nachzuweisen. Darüber hinaus macht die zk-Unfreundlichkeit von SHA256-Hashfunktionen die Beweisführung des Zustandsübergangs der Beacon-Kette äußerst herausfordernd. Diese Probleme verdeutlichen die Notwendigkeit einer umfassenden Transformation, um die bestehende Infrastruktur von Ethereum mit Zero-Knowledge-Technologien in Einklang zu bringen.

Lösung “Beam Chain”: Neugestaltung der Konsensschicht von Ethereum

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 transformieren. Die Beacon Chain bildet seit fast fünf Jahren das Herzstück des Ethereum-Netzwerks. In dieser Zeit gab es jedoch keine größeren strukturellen Verä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 den letzten fünf Jahren in wichtigen Bereichen wie dem Verständnis von MEV, Durchbrüchen in der SNARK-Technologie und dem retrospektiven Bewusstsein für technologische Fehler bedeutende Lektionen gelernt hat. Die auf diesen neuen Erkenntnissen basierenden Entwürfe sind in drei Hauptpfeiler unterteilt: Blockproduktion, Staking und Kryptographie. Die folgende Visualisierung fasst diese Entwürfe und die vorgeschlagene Roadmap zusammen:

• Grüne und graue Boxen repräsentieren inkrementelle Entwicklungen, die jedes Jahr schrittweise umgesetzt werden können. Diese Arten von Verbesserungen können ähnlich wie frühere Upgrades schrittweise in die bestehende Architektur von Ethereum integriert werden, ohne diese zu stören.
• Rote Boxen hingegen bedeuten hohe Synergie, Großmaßstab und grundlegende Änderungen, die zusammen implementiert werden müssen. Nach Drake zielen diese Änderungen darauf ab, die Kapazität und Überprüfbarkeit von Ethereum in einem großen Sprung voranzutreiben.

In diesem Abschnitt haben wir die Consensus-, State- und Execution-Schritte von The Verge im Detail untersucht, und eines der herausragendsten Probleme, die während dieses Prozesses hervorgehoben wurden, ist die Verwendung der SHA256-Hashfunktion in Ethereums Beacon Chain. Während SHA256 eine zentrale Rolle bei der Gewährleistung der Sicherheit des Netzwerks und der Verarbeitung von Transaktionen spielt, stellt seine mangelnde zk-Freundlichkeit ein erhebliches Hindernis für die Erreichung der Verifizierungsziele von Ethereum dar. Seine hohe Rechenkosten und Inkompatibilität mit zk-Technologien machen es zu einem kritischen Problem, das in zukünftigen Entwicklungen von Ethereum angegangen werden muss.

Justin Drakes Roadmap, präsentiert während seines Devcon-Vortrags, 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, um sie verifizierbarer, effizienter und besser mit zk-proof-Technologien abzustimmen.

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

An diesem Punkt tauchen hashbasierte Signaturen als quantensichere Lösungen auf, die eine entscheidende Rolle bei der Unterstützung der Sicherheits- und Verifizierungsziele des Netzwerks spielen könnten. Die Lösung dieser Anforderung entfernt auch das zweite Hauptproblem bei der Herstellung der Beacon Chain verifizierbar: BLS-Signaturen. Einer der wichtigsten Schritte, die Ethereum unternehmen kann, um die Quantensicherheit zu gewährleisten, ist die Annahme von post-quanten Lösungen wie hashbasierten Signaturen und hashbasierten SNARKs.

Wie Justin Drake betont hat,seine Devcon-Präsentation, Hashfunktionen sind aufgrund ihrer Abhängigkeit von Pre-Image-Resistance inhärent resistent gegenüber Quantencomputern und gehören damit zu den grundlegenden Bausteinen der modernen Kryptographie. Diese Eigenschaft gewährleistet, dass selbst Quantencomputer den ursprünglichen Input nicht effizient aus einem gegebenen Hash rückwärts berechnen können und somit die Sicherheit erhalten bleibt. Hash-basierte Signatursysteme ermöglichen es Validatoren und Attestoren, Signaturen ausschließlich auf Basis von Hashfunktionen zu generieren, wodurch die Sicherheit nach dem Post-Quantum-Standard gewährleistet wird und gleichzeitig eine höhere Verifizierbarkeit im Netzwerk gewährleistet wird - insbesondere wenn eine SNARK-freundliche Hashfunktion verwendet wird. Dieser Ansatz verbessert nicht nur die Sicherheit des Netzwerks, sondern macht auch die langfristige Sicherheitsinfrastruktur von Ethereum robuster und zukunftssicher.

Dieses System basiert auf der Kombination von hashbasierten Signaturen und hashbasierten SNARKs (STARK-ähnlichen Beweisen), um aggregierbare Signaturschemata zu erstellen. Aggregierbare Signaturen komprimieren Tausende von Signaturen in eine einzige Struktur und reduzieren sie auf nur wenige hundert Kilobyte an Beweisen. Diese Komprimierung verringert die Datenlast im Netzwerk erheblich und beschleunigt die Verifizierungsprozesse erheblich. Zum Beispiel können die Tausende von Validator-Signaturen, die für einen einzigen Slot auf Ethereum erstellt werden, durch eine einzige aggregierte Signatur dargestellt werden, wodurch sowohl Speicherplatz als auch Rechenleistung gespart werden.

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

Abschließende Gedanken und Fazit

Der Weg von Ethereum zur Überprüfbarkeit stellt eine grundlegende Veränderung in der Blockchain-Technologie dar. Die Verge-Initiative behebt Kernineffizienzen durch Verkle-Bäume für die Zustandsüberprüfung und STARK-Proofs für skalierbare Übergänge.

Eines der ehrgeizigsten Projekte ist die Beam Chain, eine umfassende Neugestaltung der Konsensschicht von Ethereum. Durch die Bewältigung der Einschränkungen der Beacon Chain und die Integration von zk-freundlichen Alternativen zielt dieser Ansatz darauf ab, die Skalierbarkeit von Ethereum zu verbessern, während er seine Kernprinzipien der Dezentralisierung und Zugänglichkeit bewahrt. Die Transition verdeutlicht jedoch auch die Herausforderungen, denen sich Ethereum gegenübersieht, wenn es die Balance zwischen den Rechenaufgaben und dem Ziel, ein zugängliches und inklusives Netzwerk aufrechtzuerhalten, bewahren möchte.

Da das NIST plant, die derzeitige Elliptic Curve Cryptography bis 2035 auszuphasen, muss Ethereum quantensichere Lösungen wie hash-basierte Signaturen und Poseidon übernehmen. Diese Lösungen weisen ihre eigenen Effizienz-Kompromisse auf.

Die Verwendung von STARKs im Ethereum-Fahrplan betont die Skalierbarkeit und Überprüfbarkeit. Obwohl sie sich durch transparente und quantenresistente Beweise auszeichnen, führt ihre Integration zu Herausforderungen im Zusammenhang mit den rechnerseitigen Kosten des Beweisers und der Ineffizienz bei kleinen Datenmengen. Diese Hürden müssen angegangen werden, um die Vision von Ethereum für Zustandslosigkeit und effiziente Blockverifizierung vollständig zu verwirklichen und sicherzustellen, dass das Netzwerk robust bleibt angesichts der steigenden Nachfrage.

Trotz dieser Fortschritte bleiben wichtige Herausforderungen bestehen. Ethereum muss Probleme der zk-Freundlichkeit, der Skalierbarkeit des Konsenses und der Komplexität der Integration von quantenresistenter Kryptographie bewältigen. Darüber hinaus stellen die rückwärtskompatible Infrastruktur bestehende praktische Hürden dar, die sorgfältige technische Lösungen erfordern, um Störungen für Entwickler und Benutzer gleichermaßen zu verhindern.

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 vorne – ob durch Technologien wie Beam Chain, Verkle Trees oder STARK-Proofs – hängt von einer gemeinsamen Anstrengung von Entwicklern, Forschern und der breiteren Gemeinschaft ab. Diese Fortschritte zielen nicht darauf ab, über Nacht Perfektion zu erreichen, sondern eine Grundlage für ein transparentes, dezentralisiertes und überprüfbares Internet zu schaffen.

Ethereums Entwicklung verdeutlicht seine Rolle als ein entscheidender Akteur bei der Gestaltung des Web3-Zeitalters. Indem Ethereum sich den heutigen Herausforderungen mit praktischen Lösungen stellt, rückt es einer Zukunft näher, in der Verifizierbarkeit, Quantenresistenz und Skalierbarkeit zum Standard und nicht zur Ausnahme werden.

Haftungsausschluss:

1. Dieser Artikel wurde ausgedruckt von [[](https://research.2077.xyz/the-verge-making-ethereum-verifiable-and-sustainable#the-path-to-verifiability)[2077 Forschung](https://research.2077.xyz/)\]. Alle Urheberrechte liegen beim ursprünglichen Autor [Koray Akpinarr]. Wenn es Einwände gegen diesen Nachdruck gibt, wenden Sie sich bitte an die Gate LearnTeam und sie werden es schnell bearbeiten.
2. Haftungsausschluss: Die Ansichten und Meinungen, die in diesem Artikel zum Ausdruck gebracht werden, stammen ausschließlich vom Autor und stellen keine Anlageberatung dar.
3. Übersetzungen des Artikels in andere Sprachen werden vom Gate Learn Team durchgeführt. Sofern nicht anders angegeben, ist das Kopieren, Verteilen oder Plagiieren der übersetzten Artikel untersagt.