Vitalik新文：ETH坊可能的未来，The Verge

Ursprünglicher Titel: „Mögliche Zukünfte des Ethereum-Protokolls, Teil 4: The Verge“

Original author: Vitalik Buterin

原文编译：Mensh，ChainCatcher

Vielen Dank an Justin Drake, Hsia-wei Wanp, Guillaume Ballet, Icinacio, Rosh Rudolf, Lev Soukhanoy, Ryan Sean Adams und Uma Roy für ihr Feedback und ihre Überprüfung.

Einer der mächtigsten Funktionen von Block ist, dass jeder eine Node auf seinem eigenen Computer ausführen und die Richtigkeit der Block-Chain überprüfen kann. Selbst wenn 9596 Nodes, die die Konsensregeln (PoW, PoS) der Chain ausführen, sofort einer Regeländerung zustimmen und beginnen, Blocks gemäß den neuen Regeln zu produzieren, wird jeder, der eine vollständig überprüfte Node betreibt, die Chain ablehnen. Die Münzpräger, die nicht Teil dieser Verschwörungsgruppe sind, werden automatisch zu einer on-chain wechseln, die weiterhin den alten Regeln folgt, und diese Chain weiter aufbauen, während vollständig überprüfte Benutzer dieser Chain folgen werden.

Dies ist der entscheidende Unterschied zwischen Blockchain und zentralisierten Systemen. Um diese Eigenschaft jedoch wahr werden zu lassen, muss es praktikabel sein, dass eine vollständig verifizierte Node von genügend vielen Personen betrieben wird. Dies gilt sowohl für Staker (da sie ohne Überprüfung der Kette keinen Beitrag zur Einhaltung der Protokollregeln leisten) als auch für normale Benutzer. Heutzutage ist es möglich, eine Node auf Consumer-Laptops (einschließlich des Laptops, den ich zum Schreiben dieses Artikels verwende) auszuführen, aber es ist schwierig, dies zu erreichen. The Verge will diese Situation ändern, indem die Berechnungskosten für eine vollständig verifizierte Kette gesenkt werden, sodass jeder Mobil-Wallet, Browser-Wallet und sogar Smartwatch standardmäßig verifiziert werden kann.

Die Verge 2023 Roadmap

Ursprünglich bezog sich “Verge” auf den Transfer des Ethereum-Statusspeichers auf einen Verkle-Baum - eine baumartige Struktur, die kompaktere Beweise ermöglicht und die zustandslose Verifizierung von Ethereum-Blöcken ermöglicht. Ein Node kann einen Ethereum-Block verifizieren, ohne den Ethereum-Status (Kontostand, Vertragscode, Speicherplatz usw.) auf seiner Festplatte speichern zu müssen, jedoch auf Kosten von einigen hundert KB an Beweisdaten und einigen hundert Millisekunden zusätzlicher Zeit für die Verifizierung eines Beweises. Heutzutage steht Verge für eine größere Vision, die sich auf die Maximierung der Ressourceneffizienz der Ethereum-Blockchain konzentriert, einschließlich nicht nur der zustandslosen Verifizierungstechnologie, sondern auch der Verwendung von SNARK zur Verifizierung aller Ethereum-Transaktionen.

Neben der langfristigen Folgen für die Überprüfung der gesamten SNARK-Kette gibt es ein weiteres neues Problem, das mit der Frage zusammenhängt, ob Verkle Trees die beste Technologie sind. Verkle Trees sind anfällig für Angriffe von Quantencomputern. Wenn wir also Verkle Trees im derzeitigen KECCAK Merkle Patricia Tree verwenden, müssen wir den Baum später erneut ersetzen. Der Selbstersetzungsansatz von Merkle Trees besteht darin, STARKs zu überspringen, die Merkle-Verzweigungen verwenden, und sie in den binären Baum einfügen. Historisch gesehen wurde diese Methode aufgrund der Kosten und der technischen Komplexität als nicht praktikabel angesehen. In letzter Zeit haben wir jedoch gesehen, dass Starkware auf einem Laptop ckcle STARKs verwendet hat, um 1,7 Millionen Poseidon Hashes pro Sekunde zu beweisen. Durch die Einführung von GKB und anderen Technologien verkürzt sich auch die Beweiszeit für mehr “traditionelle” Hash-Werte. Daher ist “Verge” im letzten Jahr offener geworden und es gibt mehrere Möglichkeiten.

The Verge: Schlüsselziel

• Stateless-Client: Der Speicherplatz, der für die vollständige Validierung des Clients und die Markierung des erforderlichen Nodes benötigt wird, sollte nicht mehrere GB betragen. *(Langfristig) Validierung von Konsens und Ausführung der Kette auf der Smartwatch. Einige Daten herunterladen, SNARK verifizieren und abschließen.

In diesem Kapitel

• Statuslose Clients: Verkle oder STARKs
• EVM durchgeführter Gültigkeitsnachweis
• Konsens的Gültigkeitsnachweis

Zustandslose Überprüfung: Verkle oder STARKs

Welches Problem wollen wir lösen?

Heutzutage muss der ETH-Client Hunderte von Gigabytes an Statusdaten speichern, um Blocks zu überprüfen, und diese Menge nimmt jedes Jahr zu. Die ursprünglichen Statusdaten wachsen jedes Jahr um etwa 30 GB, und jeder einzelne Client muss einige zusätzliche Daten speichern, um das Tripel effektiv zu aktualisieren.

Dies reduziert die Anzahl der Benutzer, die einen vollständig validierenden Ethereum-Node betreiben können: Obwohl Festplatten, die groß genug sind, um den gesamten Ethereum-Zustand und sogar mehrere Jahre Geschichte zu speichern, allgegenwärtig sind, verfügen die von Menschen standardmäßig gekauften Computer oft nur über einige hundert Gigabyte oder Terabyte Speicherplatz. Die Zustandsgröße führt auch zu erheblichen Reibungsverlusten beim ersten Aufbau eines Nodes: Der Node muss den gesamten Zustand herunterladen, was Stunden oder sogar Tage dauern kann. Dies hat verschiedene Kettenreaktionen zur Folge. Zum Beispiel erhöht es erheblich die Schwierigkeit für Node-Betreiber, ihre Node-Einstellungen zu aktualisieren. Technisch gesehen ist es möglich, ein Upgrade ohne Ausfallzeit durchzuführen - indem ein neuer Client gestartet wird, auf dessen Synchronisierung gewartet wird, dann der alte Client geschlossen wird und der geheime Schlüssel übertragen wird - aber in der Praxis ist dies äußerst komplex.

Wie funktioniert es?

Die zustandslose Überprüfung ist eine Technologie, die es Nodes ermöglicht, Blöcke zu überprüfen, ohne den gesamten Zustand zu kennen. Stattdessen ist jeder Block mit einem Zeugen versehen, der Folgendes enthält: (i) den Wert, den Code, das Guthaben und die Speicherung an bestimmten Stellen im Zustand, auf die dieser Block zugreifen wird; (ii) Verschlüsselungsbeweise, die belegen, dass diese Werte korrekt sind.

Tatsächlich erfordert die Implementierung der zustandslosen Verifizierung eine Änderung der Statusbaumstruktur von Ethereum. Dies liegt daran, dass der aktuelle Merkle Patricia-Baum extrem unfreundlich für die Implementierung von Verschlüsselungsnachweisschemata ist, insbesondere im schlimmsten Fall. Sowohl die “rohen” Merblk-Äste als auch die Möglichkeit, sie als STARK zu “verpacken”, sind so. Die Hauptprobleme resultieren aus einigen Schwächen von MPT:

1. Dies ist ein Baum mit sechs Gabelungen (d. h. jeder Knoten hat 16 Unter-Knoten). Das bedeutet, dass ein Beweis in einem Baum der Größe N im Durchschnitt etwa 32 * (16-1) * log 16(N) = 120 * log 2(N) Bytes benötigt, oder etwa 3840 Bytes in einem Baum mit 2 ^ 32 Elementen. Für einen binären Baum werden nur 32 * (2-1) * log 2(N) = 32 * log 2(N) Bytes benötigt, oder etwa 1024 Bytes.

2. Der Code wurde nicht merkleisiert. Das bedeutet, dass für jeden Zugriff auf den Konto-Code der gesamte Code, der maximal 24000 Bytes beträgt, vorgelegt werden muss.

Wir können den schlimmsten Fall wie folgt berechnen:

30000000 Gas / 2400 (冷Konto阅读成本) * （5 * 488 + 24000) = 330000000 字节

Die Zweigstelle Kosten sind leicht gesunken (ersetzt 5480 durch 8480), da der obere Teil bei vielen Zweigen wiederholt wird. Aber selbst dann ist es völlig unrealistisch, die Datenmenge innerhalb eines Zeitschlitzes herunterzuladen. Wenn wir versuchen, es mit STARK zu verpacken, stoßen wir auf zwei Probleme: (i) KECCAK ist relativ unfreundlich gegenüber STARK; (ii) 330 MB Daten bedeuten, dass wir 5 Millionen Aufrufe der KECCAK-Rundenfunktion nachweisen müssen, was für alle Hardware außer den leistungsstärksten Consumer-Hardware möglicherweise nicht nachgewiesen werden kann, selbst wenn wir STARK effizienter machen können, um KECCAK nachzuweisen.

Wenn wir den hexadezimalen Baum direkt durch einen Binärbaum ersetzen und den Code zusätzlich merkleisieren, wird der schlimmste Fall etwa 30000000/2400* 32*( 32-14+ 8) = 10400000 Bytes betragen (14 ist die Subtraktion der redundante Bits für 2 ^ 14 Zweige und 8 ist die Länge des Nachweises in den Blöcken des Codes). Es ist zu beachten, dass dies die Gas-Kosten ändern würde, um auf jeden einzelnen Codeblock zuzugreifen; EIP-4762 tut dies. Eine Kapazität von 10,4 MB ist viel besser, aber immer noch zu viel Daten für viele Knoten in einem Zeitschlitz zum Herunterladen. Daher müssen wir leistungsstärkere Technologien einführen. In dieser Hinsicht gibt es zwei führende Lösungen: Verkle-Bäume und STARKed binäre Hash-Bäume.

Verkle Baum

Verkle Tree verwendet elliptische Kurvenbasierte vektorielle Commitments für kürzere Nachweise. Der entscheidende Punkt ist, dass jeder Beweisteil für jede Eltern-Kind-Beziehung nur 32 Bytes beträgt, unabhängig von der Breite des Baums. Die einzige Begrenzung für die Breite des Beweisbaums besteht darin, dass die Effizienz der Berechnung der Nachweise abnimmt, wenn der Beweisbaum zu breit wird. Die Implementierung für Ethereum hat eine Breite von 256.

Daher wird die Größe eines einzelnen Zweigs im Beweis auf 32-1 OG 256(N) = 4 * log 2(N) Byte erhöht. Somit beträgt die theoretisch maximale Beweisgröße etwa 130.000 Byte (aufgrund der ungleichmäßigen Verteilung der Statusblöcke gibt es geringfügige Abweichungen vom tatsächlichen Berechnungsergebnis, aber es ist eine gute Annäherung).

Zu beachten ist, dass in allen obigen Beispielen der „worst case“ nicht der schlimmste Fall ist: Der schlimmere Fall ist, wenn ein Angreifer absichtlich zwei Adressen „abbaut“, sodass sie in einem Baum eine längere gemeinsame Präfixlänge haben und von einer Adresse Daten gelesen werden, was die Länge des Zweigs im schlimmsten Fall um das Doppelte verlängern könnte. Selbst in einem solchen Fall beträgt die Länge des schlimmsten Falles des Verkle- Baums 2,6 MB, was im Wesentlichen mit den derzeitigen Überprüfungsdaten im schlimmsten Fall übereinstimmt.

Wir haben auch etwas mit dieser Anmerkung gemacht: Wir haben die Kosten für den Zugriff auf ‘angrenzenden’ Speicherplatz sehr niedrig gemacht, entweder durch viele Codeblöcke des gleichen Vertrags oder durch benachbarte Speicherslots. EIP-4762 definiert die Nachbarschaft und erhebt nur 200 Gas für den Zugriff auf Nachbarschaften. Bei benachbartem Zugriff beträgt die maximale Größe des Nachweises immer noch etwa 30000000 / 200 * 32 - 4800800 Byte, was immer noch im Toleranzbereich liegt. Wenn wir aus Sicherheitsgründen diesen Wert weiter reduzieren möchten, können wir die Kosten für den benachbarten Zugriff leicht erhöhen.

STARKed 二进制哈希树

Das Prinzip dieser Technologie ist offensichtlich: Sie benötigen lediglich einen Binärbaum, um den Nachweis für den Wert im Block zu erbringen und einen maximalen Nachweis von 10,4 MB zu erhalten. Dann wird der Nachweis durch den STARK ersetzt. Der Nachweis selbst enthält nur die zu beweisenden Daten sowie eine feste Overhead-Größe von 100-300 kB aus dem tatsächlichen STARK.

Die Hauptherausforderung hier besteht darin, die Zeit zu verifizieren. Wir können die gleichen Berechnungen wie oben durchführen, nur dass wir keine Byte-Anzahl, sondern einen Hash-Wert berechnen. Ein Block von 10,4 MB bedeutet 330.000 Hash-Werte. Wenn wir die Möglichkeit eines Angreifers hinzufügen, in dem ‘Adresse’ Baum einen längeren gemeinsamen Präfix zu ‘minen’, dann könnten wir im schlimmsten Fall etwa 660.000 Hash-Werte erreichen. Daher ist es kein Problem, wenn wir nachweisen können, dass die Anzahl der Hash-Werte pro Sekunde 200.000 beträgt.

Auf Verbraucher-Laptops, die die Poseidon-Hash-Funktion verwenden, wurden diese Zahlen erreicht, wobei die Poseidon-Hash-Funktion speziell für die STARK-Freundlichkeit entwickelt wurde. Das Poseidon-System ist jedoch noch relativ unreif, so dass viele Menschen ihm noch nicht vertrauen. Es gibt daher zwei realistische Wege nach vorne:

1. Führen Sie eine umfangreiche Sicherheitsanalyse von Poseidon durch und machen Sie sich damit vertraut, um es auf L1 zu implementieren.
2. Verwenden Sie eine “konservativere” Hash-Funktion wie SHA 256 oder BLAKE

Um die Konservativität der Hash-Funktion zu beweisen, kann der STARK-Ring von Starkware zum Zeitpunkt der Abfassung dieses Artikels nur 10-30 k Hashwerte pro Sekunde auf einem Consumer-Notebook nachweisen. Allerdings verbessert sich die STARK-Technologie rasant. Selbst heute zeigt die GKR-basierte Technologie das Potenzial, diese Geschwindigkeit auf den Bereich von 100-2 O 0 k zu erhöhen.

Anwendungsfälle für Zeugen außerhalb der Blockverifizierung

Neben der Validierung von Block gibt es drei weitere wichtige Anwendungsfälle, die eine effizientere zustandslose Validierung erfordern:

• Memory Pool: Wenn eine Transaktion verbreitet wird, müssen die Knoten im P2P-Netzwerk die Transaktion auf ihre Gültigkeit überprüfen, bevor sie sie erneut verbreiten. Die Überprüfung umfasst heute das Überprüfen der Signatur sowie das Überprüfen des Kontostands und des korrekten Präfixes. In Zukunft (zum Beispiel unter Verwendung einer nativen Kontoabstraktion wie EIP-7701) könnte dies das Ausführen von EVM-Code beinhalten, der auf einige Zustandszugriffe zugreift. Wenn der Knoten zustandslos ist, muss die Transaktion einen Nachweis für den Zustandsobjekt enthalten.
• Liste der Einschlüsse: Dies ist eine vorgeschlagene Funktion, die es (möglicherweise in kleinem Umfang und nicht komplex) ermöglicht, dass der nächste Block unter Zwang des Proof of Stake Prüfers Transaktionen enthält, unabhängig vom Willen des Blockerstellers (möglicherweise in großem Umfang und komplex). Dies schwächt die Fähigkeit der Machthaber, die Blockchain durch Latenzzeitanpassungen zu manipulieren. Allerdings muss der Prüfer eine Möglichkeit haben, die Gültigkeit der in der Liste der Einschlüsse enthaltenen Transaktionen zu überprüfen.
• Light Client’: Wenn wir möchten, dass Benutzer über eine Brieftasche auf die Kette zugreifen (wie Metamask, Rainbow, Rabby usw.), müssen sie einen leichten Client ausführen (wie Helios). Das Kernmodul von Helios stellt den Benutzern einen überprüften Zustandsstamm zur Verfügung. Um jedoch ein vollständig vertrauensloses Erlebnis zu bieten, müssen Benutzer für jeden ihrer RPC-Aufrufe einen Nachweis erbringen (z. B. für einen ETH-Netzaufruf (Benutzer müssen nachweisen, dass auf alle Zustände zugegriffen wurde, auf die im Aufrufprozess zugegriffen wurde).

Alle diese Anwendungsfälle haben etwas gemeinsam: Sie benötigen alle viele Beweise, aber jeder Beweis ist klein. Daher haben STARK-Beweise für sie keine praktische Bedeutung; stattdessen ist es am realistischsten, direkt Merkle-Verzweigungen zu verwenden. Ein weiterer Vorteil von Merkle-Verzweigungen ist, dass sie aktualisierbar sind: Mit einem Beweis für einen Zustandsobjekt X mit dem Block B als Wurzel kann der Beweis aktualisiert werden, wenn ein Unterblock B 2 und sein Zeuge empfangen werden, um ihn auf den Block B 2 als Wurzel zu aktualisieren. Verkle-Beweise sind ebenfalls nativ aktualisierbar.

Welche Verbindungen gibt es zu bestehenden Forschungen:

• Verkle-Bäume
• John Kuszmaul 关于 Verkle tree 的原始论文
• Starkware
• Poseidon 2 Papier
• Ajtai (Alternative schnelle Hash-Funktion basierend auf Gitterhärte)
• Verkle.info

Was kann noch getan werden?

Die verbleibende Hauptaufgabe ist

1. Weitere Analyse der Auswirkungen von EIP-4762 (Änderungen der kostenfreien Gaspreise)

2. Mehr Arbeit zur Fertigstellung und Prüfung des Übergangsprogramms, dies ist ein wesentlicher Teil der Komplexität eines jeden staatenlosen Umsetzungsplans

3. Weitere Sicherheitsanalyse von Poseidon, Ajtai und anderen “STARK-freundlichen” Hash-Funktionen

4. Entwicklung eines extrem effizienten STARK-Protokollfunktionen für die “konservative” (oder “traditionelle”) Hash-Weiterentwicklung, z.B. basierend auf Binius oder GKR-Ansätzen.

Wir werden bald eine Entscheidung aus den folgenden drei Optionen treffen: (i) Verkle-Tree, (ii) STARK-freundliche Hash-Funktion und (iii) konservative Hash-Funktion. Ihre Eigenschaften können grob in der folgenden Tabelle zusammengefasst werden:

Abgesehen von diesen “Titelzahlen” gibt es noch einige andere wichtige Überlegungen:

• Heutzutage ist der Verkle-Baumcode ziemlich ausgereift. Die Verwendung von Code, der nicht Verkle ist, würde die Bereitstellung verzögern und wahrscheinlich zu einer Aufspaltung der Hardfork führen. Das ist auch in Ordnung, insbesondere wenn wir zusätzliche Zeit für die Analyse der Hashfunktion oder die Implementierung des Validierers benötigen oder wenn wir andere wichtige Funktionen haben, die wir früher in Ethereum integrieren möchten.
• Das Aktualisieren des Zustandsbaums mit Hash-Werten ist schneller als mit Verkle-Bäumen. Dies bedeutet, dass die synchronisierte Zeit für Full Nodes durch die Verwendung von hashbasierten Methoden verkürzt werden kann.
• Verkle-Baum hat interessante aktualisierbare Zeugeneigenschaften - Verkle-Baumzeugen sind aktualisierbar. Diese Eigenschaft ist nützlich für den Mempool, die Transaktionsliste und andere Anwendungsfälle und kann auch dazu beitragen, die Implementierungseffizienz zu verbessern: Wenn der Statusobjekt aktualisiert wird, kann das Zeugnis der vorletzten Schicht aktualisiert werden, ohne den Inhalt der letzten Schicht lesen zu müssen.
• Verkle-Bäume sind schwieriger mit SNARKs zu beweisen. Wenn wir den Beweis auf ein paar tausend Bytes reduzieren wollen, wird die Verkle-Proof einige Schwierigkeiten mit sich bringen. Dies liegt daran, dass die Überprüfung des Verkle-Proofs viele 256-Bit-Operationen erfordert, was entweder zu hohen Kosten oder zu einer benutzerdefinierten internen Struktur des Beweissystems führt, die den 256-Bit-Teil des Verkle-Proofs enthält. Dies ist kein Problem für Statelessness selbst, aber es bringt mehr Schwierigkeiten mit sich.

Eine andere mögliche Methode, um die Verkle Zeugenschaftsaktualisierbarkeit auf eine quantensichere und effiziente Weise zu erreichen, besteht darin, einen Merkle-Baum auf der Grundlage eines Lattices zu verwenden.

Wenn im schlimmsten Fall nachgewiesen wird, dass die Effizienz des Systems nicht ausreicht, können wir unerwartete Werkzeuge wie Multidimensionales Gas nutzen, um diesen Mangel auszugleichen: separate Gasgrenzen für (i) Calldaten; (ii) Berechnung; (iii) Zustandszugriff und möglicherweise andere verschiedene Ressourcen. Multidimensionales Gas erhöht die Komplexität, aber im Gegenzug beschränkt es das Verhältnis zwischen durchschnittlichen und schlechtesten Fällen strenger. Mit Multidimensionalem Gas könnte die theoretisch maximale Anzahl von Zweigen von 12500 auf beispielsweise 3000 reduziert werden. Dies würde BLAKE 3 selbst heute (gerade noch) ausreichend machen.

Multi-dimensionales Gas ermöglicht eine Block-Ressourcenbegrenzung, die näher an der Ressourcenbegrenzung der zugrunde liegenden Hardware liegt.

Ein weiteres unerwartetes Werkzeug ist die Berechnung der Latenzzeit des Zustandswurzels nach dem Block. Dadurch haben wir volle 12 Sekunden Zeit, um den Zustandswurzel zu berechnen. Das bedeutet, dass selbst in extremsten Fällen nur 60000 Hashes pro Sekunde ausreichend sind, was uns erneut zu der Annahme veranlasst, dass BLAKE 3 nur knapp ausreicht, um die Anforderungen zu erfüllen.

Ein Nachteil dieser Methode ist, dass sie die Latenzzeit eines Light Clients’ erhöht, jedoch gibt es auch raffiniertere Techniken, um diese Latenzzeit auf die Generierung der Nachweise zu reduzieren. Zum Beispiel können die Nachweise sofort nach der Generierung in einem beliebigen Node im Netzwerk ausgestrahlt werden, anstatt auf den nächsten Block zu warten.

Wie interagiert es mit anderen Teilen des Roadmaps?

Die Lösung des Zustandslosigkeitsproblems erhöht die Schwierigkeit erheblich, einzelne Standorte zu treffen. Wenn es Techniken gibt, um das Mindestgleichgewicht für einzelne Standorte zu senken, wie Orbit SSF oder Anwendungs-Layer-Strategien wie Team-Standorte, würde dies praktikabler werden.

Wenn gleichzeitig EOF eingeführt wird, wird die multidimensionale Gasanalyse viel einfacher. Dies liegt daran, dass die Hauptausführungskomplexität des multidimensionalen Gases darin besteht, mit den Unteranrufen umzugehen, die nicht das gesamte Gas des übergeordneten Aufrufs übertragen, während EOF einfach solche Unteranrufe als ungültig markieren muss, um dieses Problem unbedeutend zu machen (und eine Alternative innerhalb des Protokolls für einen Teil der aktuellen Hauptgasnutzung des nativen Kontos bereitzustellen.

Zwischen der zustandslosen Validierung und dem historischen Ablauf besteht auch eine wichtige Synergie. Heutzutage muss der Client fast 1 TB historische Daten speichern; diese Daten sind das Vielfache der Zustandsdaten. Selbst wenn der Client zustandslos ist, wird der Traum eines nahezu speicherlosen Clients kaum Realität, es sei denn, wir können ihn von der Verantwortung entbinden, historische Daten zu speichern. Der erste Schritt in diese Richtung ist EIP-4444, was auch bedeutet, dass historische Daten in Torrents oder im Portal Network gespeichert werden.

Gültigkeitsnachweis der EVM-Ausführung

Welches Problem wollen wir lösen?

Das langfristige Ziel der Ethereum-Blockverifizierung ist klar definiert - Ethereum-Blöcke sollten auf folgende Weise verifiziert werden können: (i) Herunterladen des Blocks oder sogar nur eines kleinen Teils des Blocks, der Datenverfügbarkeitsstichproben enthält; (ii) Verifizieren eines kleinen Nachweises für die Gültigkeit des Blocks. Dies ist eine ressourcenschonende Operation, die in einer mobilen App, einer Browser-Wallet oder sogar in einer anderen Chain durchgeführt werden kann (ohne den Datenverfügbarkeitsteil).

Um dies zu erreichen, müssen (i) die Konsensebene (d. h. Proof of Stake) und (ii) die Ausführungsebene (d. h. EVM) mit SNARK oder STARK nachgewiesen werden. Ersteres ist an sich schon eine Herausforderung, die im weiteren Verbesserungsprozess der Konsensebene angegangen werden sollte (z. B. im Hinblick auf die endgültige Abwicklung eines einzelnen Slots). Letzteres erfordert einen Nachweis der EVM-Ausführung.

Was ist das und wie funktioniert es?

Vom formalen Standpunkt aus betrachtet wird EVM in der ETH-Blockspezifikation als Zustandsübergangsfunktion definiert: Sie haben einen Ausgangszustand S, einen Block B und Sie berechnen einen neuen Zustand S’ = STF(S, B). Wenn der Benutzer den Light-Client verwendet, besitzt er nicht vollständig S und S’, oder sogar E; stattdessen hat er eine vorherige Zustandswurzel R, eine neue Zustandswurzel R’ und einen Block-Hash-Wert H.

• Öffentlicher Input: Vorheriger Zustandswurzel R, Nachfolgender Zustandswurzel R’, BlockHash H
• Private input: The same objects in the state accessed by program block B and program block Q, the same objects after executing program block Q’, and the state proof (such as Merkle branches) P.
• Behauptung 1: P ist ein gültiger Beweis dafür, dass Q Teile des Zustands enthält, die durch R repräsentiert werden.
• Behauptung 2: Wenn STF auf Q ausgeführt wird, (i) greift der Ausführungsprozess nur auf interne Objekte von Q zu, (ii) sind die Datenblöcke gültig, (iii) ist das Ergebnis Q’.
• Behauptung 3: Wenn der Zustandswurzel mit den Informationen von Q’ und P neu berechnet wird, erhält man R’.

Wenn diese Situation vorliegt, kann ein leichter Client erstellt werden, der die vollständige Überprüfung der ETH-Blockkette und der EVM-Ausführung durchführt. Dies bedeutet, dass die Ressourcen des Clients bereits ziemlich gering sind. Um einen vollständig verifizierten ETH-Blockketten-Client zu implementieren, muss auch in Bezug auf Konsensarbeit geleistet werden.

Die Implementierung des Gültigkeitsnachweises für die EVM-Berechnung existiert bereits und wird von L2 häufig verwendet. Es gibt jedoch noch viel Arbeit zu tun, um den EVM-Gültigkeitsnachweis auf L1 praktikabel zu machen.

Welche Verbindungen gibt es zu bestehenden Studien?

• EFPSE ZK-EVM (Aufgrund besserer Alternativen nicht mehr in Gebrauch)
• Zeth, dessen Funktionsweise darin besteht, den EVM in den RISC-0 ZK-VM zu kompilieren
• ZK-EVM Formale Verifizierung-Projekt

Was kann noch getan werden?

Heutzutage weist das elektronische Buchführungssystem in zwei Aspekten Mängel auf: Sicherheit und Überprüfungszeit.

Ein sicherer Gültigkeitsnachweis gewährleistet, dass SNARK tatsächlich die Berechnung des EVM überprüft und keine Schwachstellen aufweist. Zwei Haupttechniken zur Verbesserung der Sicherheit sind Multi-Validator und formale Verifikation. Unter Multi-Validator versteht man mehrere unabhängig voneinander entwickelte Implementierungen von Gültigkeitsnachweis, ähnlich wie mehrere Clients. Wenn ein Block von einer ausreichend großen Teilmenge dieser Implementierungen nachgewiesen wird, akzeptiert der Client den Block. Die formale Verifikation beinhaltet die Verwendung von Tools, die normalerweise zur Beweisführung mathematischer Theoreme verwendet werden, wie z.B. Lean 4, um zu beweisen, dass der Gültigkeitsnachweis nur korrekt ausgeführte zugrunde liegende EVM-Spezifikationen akzeptiert (z.B. EVM K-Semantik oder die mit Python geschriebene EELS-Eth-Schichtspezifikation).

Eine ausreichend schnelle Bestätigungszeit bedeutet, dass jeder Ether-Block in weniger als 4 Sekunden bestätigt werden kann. Heute sind wir noch weit von diesem Ziel entfernt, obwohl wir viel näher dran sind als vor zwei Jahren vorgestellt. Um dieses Ziel zu erreichen, müssen wir in drei Bereichen Fortschritte erzielen:

• Parallelisierung - Derzeit kann der schnellste EVM-Validator durchschnittlich in 15 Sekunden einen Ethereum-Block nachweisen. Dies wird durch Parallelisierung über Hunderte von GPUs erreicht, die am Ende ihre Arbeit zusammenführen. Theoretisch wissen wir genau, wie man einen EVM-Validator herstellt, der die Berechnung in O(log(N)) Zeit nachweisen kann: Lassen Sie eine GPU jeden Schritt ausführen und erstellen Sie dann einen “Aggregationsbaum”: 01928374656574839201

Die Umsetzung dieses Vorhabens birgt Herausforderungen. Selbst im ungünstigsten Fall, wenn eine sehr große Transaktion den gesamten Block einnimmt, darf die Berechnung nicht sequenziell erfolgen, sondern muss anhand der Opcodes (Opcodes der zugrunde liegenden Virtuellen Maschine wie EVM oder RISC-V) erfolgen. Die Gewährleistung der Konsistenz des “Speichers” der Virtuellen Maschine zwischen den verschiedenen Teilen des Nachweises ist eine entscheidende Herausforderung bei der Umsetzung. Wenn wir jedoch diesen rekursiven Nachweis erbringen können, wissen wir, dass zumindest das Latenzproblem des Beweisers gelöst ist, selbst wenn in anderen Bereichen keine Verbesserungen vorgenommen wurden.

• Optimierung des Nachweissystems - Ein neues Nachweissystem wie Orion, Binius, GRK und weitere Informationen könnten sehr wahrscheinlich zu einer erheblichen Verkürzung der Bestätigungszeit für allgemeine Berechnungen führen.
• Weitere Änderungen der EVM-Gas-Kosten - Viele Dinge in der EVM können optimiert werden, um sie für den Beweiser vorteilhafter zu machen, insbesondere im schlimmsten Fall. Wenn ein Angreifer einen Block konstruieren kann, der den Beweiser zehn Minuten lang blockiert, reicht es nicht aus, einen gewöhnlichen ETH-Block in 4 Sekunden zu beweisen. Die erforderlichen Änderungen an der EVM können grob in folgende Kategorien eingeteilt werden:

• Die Veränderung der Gas-Kosten - Wenn eine Operation lange dauert, um nachzuweisen, sollte selbst wenn ihre Berechnungsgeschwindigkeit relativ hoch ist, die Gas-Kosten sehr hoch sein. EIP-7667 ist ein EIP, das für die Behandlung dieses schwerwiegendsten Problems vorgeschlagen wurde: Es erhöht erheblich die Gas-Kosten von (traditionellen) Hash-Funktionen, da die Operationen und Precompiles dieser Funktionen relativ günstig sind. Um diese erhöhten Gas-Kosten auszugleichen, können wir die Gas-Kosten der EVM-Operationen senken, die günstig zu beweisen sind, und damit die durchschnittliche Durchsatzrate aufrechterhalten.

• Datenaustausch: Neben dem Austausch des Statusbaums durch eine STARK-freundlichere Methode müssen wir auch Transaktionslisten, Quittungsbäume und andere kostspielige Strukturen ersetzen. Etan Kissling hat mit der Verschiebung der Transaktions- und Quittungsstruktur zu SSZ einen Schritt in diese Richtung gemacht.

Darüber hinaus können die beiden in der vorherigen Sektion erwähnten Tools (Multidimensionale Gas und Latenzzeit-Status-Root) ebenfalls hilfreich sein. Es ist jedoch zu beachten, dass im Gegensatz zur Zustandslosen Überprüfung die Verwendung dieser beiden Tools bedeutet, dass wir bereits genügend Technologie besitzen, um die derzeit erforderliche Arbeit zu erledigen, und selbst bei Verwendung dieser Technologien erfordert die vollständige ZK-EVM-Überprüfung jedoch mehr Arbeit - es wird nur weniger davon benötigt.

Ein Punkt, der im obigen Text nicht erwähnt wurde, sind die Nachweiserhardwares: GPUs, FPGAs und ASICs werden verwendet, um Nachweise schneller zu generieren. Fabric Cryptography, Cysic und Accseal sind drei Unternehmen, die in diesem Bereich Fortschritte gemacht haben. Dies ist für L2 sehr wertvoll, aber wahrscheinlich kein entscheidender Faktor für L1, da die Menschen darauf bestehen, dass L1 stark dezentralisiert bleibt. Das bedeutet, dass die Nachweisgenerierung im vernünftigen Bereich der ETH-Community bleiben muss und nicht durch Engpässe einzelner Unternehmenshardware eingeschränkt werden sollte. L2 kann aktivere Kompromisse eingehen.

In diesen Bereichen gibt es noch viel mehr Arbeit zu tun:

• Proof-of-Parallelism requires proving that different parts of the system can “share memory” (such as lookup tables). We know the technology to do this, but it needs to be implemented.
• Wir müssen weitere Analysen durchführen, um das ideale Gas-Kostenänderungsset zu finden, um die Validierungszeit im schlimmsten Fall zu minimieren.
• Wir müssen mehr in Bezug auf das Nachweissystem tun

Mögliche Kosten sind:

• Sicherheit und Validatorzeit: Durch die Auswahl einer aggressiveren Hash-Funktion, eines komplexeren Nachweissystems oder aggressiveren Sicherheitsannahmen oder anderer Designoptionen kann die Validatorzeit verkürzt werden.
• Dezentralisierung und Proof-of-Time: Die Community muss sich auf die ‘Spezifikationen’ der Hardwares für den Proof-of-Time einigen, auf die sie abzielt. Kann der Proof-of-Time von großen Entitäten durchgeführt werden? Wünschen wir uns, dass High-End-Consumer-Notebooks in der Lage sind, einen ETH-Block in 4 Sekunden zu beweisen? Liegt der Bedarf irgendwo dazwischen?
• Das Ausmaß der Beeinträchtigung der Abwärtskompatibilität: Andere Mängel können durch eine aktivere Anpassung der Gas-Kosten ausgeglichen werden, aber dies könnte die Kosten einiger Anwendungen unverhältnismäßig erhöhen und die Entwickler dazu zwingen, den Code neu zu schreiben und neu bereitzustellen, um die Wirtschaftlichkeit zu gewährleisten. Ebenso haben diese beiden Werkzeuge ihre eigene Komplexität und Nachteile.

Wie interagiert es mit anderen Teilen der Roadmap?

Die Kerntechnologie, die für die Erfüllung des L1 EVM Gültigkeitsnachweises erforderlich ist, wird weitgehend mit den beiden anderen Bereichen geteilt:

• L2的Gültigkeitsnachweis（即 “ZK rollup”）
• Der zustandslose “STARK binäre Hash-Beweis”-Ansatz

Eine erfolgreiche Implementierung des Gültigkeitsnachweises in L1 wird endlich zu einem einfachen Ein-Spieler-Staken führen: Selbst die schwächsten Computer (einschließlich Mobiltelefone oder Smartwatches) können eingesetzt werden. Dies erhöht den Wert der Auseinandersetzung mit den anderen Einschränkungen von Solo-Stakes, wie z. B. dem Minimum von 32 ETH.

Zusätzlich kann der EVM Gültigkeitsnachweis von L1 die Gasgrenze von L1 erheblich erhöhen.

Konsens的Gültigkeitsnachweis

Welches Problem wollen wir lösen?

Wenn wir einen ETH-Block vollständig mit SNARK überprüfen möchten, ist die Ausführung der EVM nicht der einzige Teil, den wir nachweisen müssen. Wir müssen auch den Konsens nachweisen, d.h. den Teil des Systems, der Einzahlungen, Abhebungen, das Signieren, das Aktualisieren des Validator-Guthabens und andere Elemente des Proof-of-Stake-Teils von ETH-Block bewältigt.

Konsens ist viel einfacher als EVM, aber die Herausforderung besteht darin, dass wir kein L2 EVM-Modul haben, sodass die meiste Arbeit so oder so erledigt werden muss. Daher erfordert die Implementierung eines Konsensmechanismus für die Ethereum-Blockchain ein ‘von Grund auf’ Vorgehen, obwohl das Beweissystem selbst eine gemeinsame Arbeit darstellen kann.

Was ist das und wie funktioniert es?

beacon chain wird als Statusübergangsfunktion definiert, ähnlich wie die EVM. Die Statusübergangsfunktion besteht hauptsächlich aus drei Teilen:

• ECADD（用于验证 BLS 签名）
• Paarung (zur Überprüfung der BLS-Signatur)
• SHA 256-Hashwert (zur Lese- und Aktualisierungsstatus)

In jedem Block müssen wir für jeden Prüfer 1-16 BLS 12-381 ECADD nachweisen (möglicherweise mehr als einen, da die Signatur in mehreren Sammlungen enthalten sein kann). Dies kann durch die Technik der Vorab-Berechnung von Teilmengen ausgeglichen werden, so dass wir sagen können, dass jeder Prüfer nur einen BLS 12-381 ECADD nachweisen muss. Derzeit gibt es 30.000 Prüfersignaturen pro Slot. In Zukunft könnte sich dies mit der Implementierung der finalen Eindeutigkeit eines einzelnen Slots in zwei Richtungen ändern: Wenn wir den “Brute-Force”-Ansatz verfolgen, könnte die Anzahl der Prüfer pro Slot auf 1 Million steigen. Gleichzeitig würde bei Verwendung von Orbit SSF die Anzahl der Prüfer bei 32.768 bleiben oder sogar auf 8192 abnehmen.

Wie funktioniert die BLS-Aggregation: Die Überprüfung der Gesamtunterschrift erfordert nur eine ECADD pro Teilnehmer, anstelle von ECMUL. Aber 30000 ECADD ist immer noch eine große Menge an Nachweisen.

In Bezug auf Paarungen gibt es derzeit maximal 128 Nachweise pro Steckplatz, was bedeutet, dass 128 Paarungen überprüft werden müssen. Mit ElP-7549 und weiteren Änderungen kann die Anzahl der Nachweise pro Steckplatz auf 16 reduziert werden. Die Anzahl der Paarungen ist gering, aber die Kosten sind extrem hoch: Die Laufzeit (oder der Nachweis) für jede Paarung dauert mehrere tausend Mal länger als ECADD.

Eine der Hauptherausforderungen bei der Berechnung von BLS 12-381 ist, dass es keine bequemen Kurven gibt, deren Ordnung der Feldgröße von BLS 12-381 entspricht, was jedem Beweissystem erhebliche Kosten verursacht. Andererseits wurde für Ethereum die Verkle-Baumstruktur mit der Bandersnatch-Kurve konstruiert, wodurch BLS 12-381 selbst zu einer Selbstkurve für den Nachweis von Verkle-Verzweigungen in SNARK-Systemen wird. Eine recht einfache Implementierung kann 100 G1-Additionen pro Sekunde nachweisen; um die Nachweisgeschwindigkeit ausreichend schnell zu machen, ist fast sicher eine clevere Technik wie GKR erforderlich.

Für den SHA 256-Hashwert ist die momentan schlechteste Situation die Ära-Konvertierungsblöcke, bei denen der gesamte Prüfer-Saldo-Baum und eine große Anzahl von Prüfer-Salden aktualisiert werden. Jeder Prüfer-Saldo-Baum hat nur ein Byte, sodass 1 MB Daten erneut gehasht werden. Dies entspricht 32768 SHA 256-Aufrufen. Wenn tausend Prüfer-Salden über oder unter einem Schwellenwert liegen, müssen die gültigen Salden in den Prüfer-Records aktualisiert werden, was tausend Merkle-Zweige entspricht und daher möglicherweise zehntausend Hash-Werte erfordert. Das Mischen erfordert 90 Bit pro Prüfer (daher 11 MB Daten), kann jedoch zu jeder Zeit in einer Ära berechnet werden. In bestimmten Fällen können diese Zahlen je nach den spezifischen Umständen bei Einzelschlussterminen variieren. Das Mischen wird überflüssig, obwohl Orbit möglicherweise in gewissem Maße diese Anforderung wiederherstellt.

Eine weitere Herausforderung besteht darin, dass alle Validator-Status, einschließlich des öffentlichen Schlüssels, erneut abgerufen werden müssen, um einen Block zu validieren. Für eine Million Validator bedeutet dies allein das Lesen des öffentlichen Schlüssels 48 Millionen Bytes, zusammen mit dem Merkle-Zweig. Dies erfordert Millionen von Hash-Werten für jede Epoche. Wenn wir die Gültigkeit des PoS nachweisen müssen, ist eine praktikable Methode eine Form von inkrementeller verifizierbarer Berechnung: Speichern einer separaten Datenstruktur im Beweissystem, die optimiert ist, um effizient zu suchen und Updates für diese Struktur nachzuweisen.

Insgesamt gibt es viele Herausforderungen. Um diesen Herausforderungen am effektivsten zu begegnen, ist es wahrscheinlich erforderlich, eine gründliche Neugestaltung der Beacon Chain vorzunehmen, möglicherweise zusammen mit dem Übergang zum Single-Slot-Ende. Die Merkmale dieser Neugestaltung könnten Folgendes umfassen:

• Die Veränderung der Hash-Funktion: Jetzt wird die “vollständige” SHA 256-Hash-Funktion verwendet, daher muss bei jedem Aufruf aufgrund der Füllung zweimal auf den unterliegenden Komprimierungsfunktionen aufgerufen werden. Wenn wir die SHA 256-Komprimierungsfunktion verwenden, könnten wir mindestens das doppelte Einkommen erzielen. Wenn wir auf Poseidon umstellen, könnten wir möglicherweise das Hundertfache an Gewinn erzielen und damit alle unsere Probleme (zumindest hinsichtlich des Hash-Werts) vollständig lösen: mit 1,7 Millionen Hash-Werten pro Sekunde (54 MB), könnten selbst eine Million Überprüfungsdatensätze innerhalb von wenigen Sekunden “gelesen” werden.
• Wenn es sich um Orbit handelt, werden die validierten Aufzeichnungen nach dem Mischen direkt gespeichert: Wenn eine bestimmte Anzahl von Validatoren (z. B. 8192 oder 32768) als Komitee für einen bestimmten Slot ausgewählt wird, werden sie direkt in den benachbarten Status eingefügt, so dass nur minimaler Hash erforderlich ist, um alle Public Keys der Validatoren in den Nachweis zu laden. Auf diese Weise können auch alle Bilanzaktualisierungen effizient abgeschlossen werden.
• Aggregierte Signaturen: Jedes leistungsstarke Aggregationsverfahren für Signaturen beinhaltet einen gewissen Grad an rekursivem Nachweis, bei dem verschiedene Nodes im Netzwerk einen Zwischennachweis für Teilmengen von Signaturen erbringen. Dadurch wird die Nachweisarbeit natürlich auf mehrere Nodes im Netzwerk verteilt, was die Arbeitslast für den “endgültigen Nachweiser” erheblich reduziert.
• Andere Signaturlösungen: Für Lamport+Merkle-Signaturen benötigen wir 256 + 32 Hashwerte zur Überprüfung der Signatur; multipliziert mit 32768 Unterzeichnern ergibt das 9437184 Hashwerte. Durch Optimierung des Signaturverfahrens kann dieses Ergebnis weiterhin durch einen sehr kleinen Konstantenfaktor verbessert werden. Wenn wir Poseidon verwenden, kann dies innerhalb eines einzelnen Slots nachgewiesen werden. In der Praxis ist jedoch die Verwendung eines rekursiven Aggregationsverfahrens schneller.

Welche Verbindungen gibt es zu bestehenden Studien?

• Einfacher Ethereum-Konsensnachweis (nur für Synchronisationskomitee)
• Helios in SP 1 of Concise
• Kompiliertes BLS 12-381
• BLS-Sammlungs-Signaturüberprüfung basierend auf Halo 2

Welche anderen Aufgaben gibt es noch und wie soll man sich entscheiden:

Tatsächlich benötigen wir mehrere Jahre, um den Gültigkeitsnachweis für den ETH-Konsens zu erhalten. Dies entspricht in etwa der Zeit, die wir benötigen, um Single-Slot-Endgültigkeit, Orbit, Signatur-Algorithmus-Änderungen und Sicherheitsanalysen umzusetzen. Sicherheitsanalysen erfordern jedoch genügend Vertrauen, um Hash-Funktionen wie Poseidon “aggressiv” zu verwenden. Daher ist es am klügsten, diese anderen Probleme zu lösen und dabei die Freundlichkeit von STARK zu berücksichtigen.

Die wichtigste Abwägung liegt wahrscheinlich in der Reihenfolge der Operationen, zwischen einem schrittweisen Ansatz zur Reform der Ethereum-Konsensschicht und einem aggressiveren Ansatz einer “one-time-change-many”. Für die EVM ist ein schrittweiser Ansatz sinnvoll, da er die Störungen der Abwärtskompatibilität minimiert. Für die Konsensschicht ist die Auswirkung auf die Abwärtskompatibilität geringer und es gibt auch Vorteile, die verschiedenen Details der Beacon Chain-Konstruktion umfassend zu überdenken, um die SNARK-Freundlichkeit optimal zu optimieren.

Wie interagiert es mit anderen Teilen des Roadmaps?

Bei der langfristigen Neugestaltung von ETH PoS muss die Freundlichkeit von STARK, insbesondere Einzel-Slot-Finalität, Orbit, Änderung des Signaturverfahrens und Signaturaggregation, an erster Stelle stehen.