Vitaliks mögliche Zukunft für Ethereum (Teil 4): The Verge

Vorheriges Lesen: “Vitalik über die mögliche Zukunft von ETH (Teil 1): The Merge”, “Vitalik über die mögliche Zukunft von ETH (Teil 2): The Surge”, “Vitalik über die mögliche Zukunft von ETH (Teil 3): The Scourge”

Besonderer Dank geht 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 stärksten Funktionen der Block-Kette ist, dass jeder eine Node auf seinem eigenen Computer ausführen und die Richtigkeit der Block-Kette überprüfen kann. Selbst wenn 9596 Nodes, die die Konsensregeln (PoW, PoS) der Kette ausführen, sofort einer Regeländerung zustimmen und beginnen, Blöcke gemäß den neuen Regeln zu erzeugen, werden alle Personen, die eine vollständige Überprüfung der Nodes durchführen, die Kette ablehnen. Die Münzer, die nicht Teil dieser Verschwörungsgruppe sind, werden automatisch auf eine on-chain übergehen, die weiterhin den alten Regeln folgt und diese Kette weiter aufbaut, während die vollständig überprüften Benutzer dieser Kette folgen werden.

Dies ist der entscheidende Unterschied zwischen Blockchain und zentralisierten Systemen. Um diese Funktion jedoch zu realisieren, muss es für ausreichend viele Menschen möglich sein, einen vollständig validierten Node zu betreiben. Dies gilt sowohl für Staker (denn wenn Staker die Kette nicht validieren, tragen sie nicht zur Einhaltung der Protokollregeln bei) als auch für normale Benutzer. Heutzutage ist es möglich, einen Node auf einem Consumer-Notebook (einschließlich des Notebooks, das zum Zeitpunkt des Verfassens dieses Artikels verwendet wurde) auszuführen, aber es ist schwierig, dies zu erreichen. The Verge will diese Situation ändern und die Kosten für die Validierung einer vollständig validierten Kette senken, sodass jede Handy-Wallet, Browser-Wallet und sogar eine Smartwatch standardmäßig validiert wird.

Die Verge 2023 Roadmap

Ursprünglich bezeichnete “Verge” die Übertragung des ETH-Zustandspeichers auf den Verkle-Baum - eine baumartige Struktur, die kompaktere Nachweise ermöglicht und eine zustandslose Überprüfung der ETH-Blocke ermöglicht. Ein Node kann einen ETH-Block überprüfen, ohne den ETH-Zustand (Kontostand, Vertragscode, Speicherplatz usw.) auf seiner Festplatte speichern zu müssen, mit dem Aufwand, einige hundert KB an Nachweisdaten und einige hundert Millisekunden zusätzlicher Zeit für die Überprüfung eines Nachweises. Heute steht Verge für eine größere Vision, die sich auf die Maximierung der Ressourceneffizienz der ETH-Blockchain konzentriert, die nicht nur die zustandslose Überprüfungstechnologie umfasst, sondern auch die Verwendung von SNARK zur Überprüfung aller ETH-Transaktionen.

Neben der langfristigen Verfolgung der SNARK-Validierung der gesamten Kette gibt es eine weitere neue Frage, die sich auf die Frage bezieht, ob Verkle Trees die beste Technologie sind. Verkle Trees sind anfällig für Angriffe von Quantencomputern. Wenn wir also Verkle Trees in den aktuellen KECCAK Merkle Patricia Tree integrieren, müssen wir den Tree später erneut ersetzen. Eine alternative Methode zu Merkle Trees ist die direkte Verwendung von STARKs, die auf Merkle Branches verzichten und sie in einen binären Baum einfügen. Historisch gesehen galt diese Methode aufgrund von Kosten und technischer Komplexität als nicht machbar. Vor kurzem haben wir jedoch gesehen, dass Starkware auf einem Laptop mit ckcle STARKs 1,7 Millionen Poseidon Hashes pro Sekunde beweisen kann. Und durch die Entwicklung von Technologien wie GKB wird auch die Beweiszeit für weitere “traditionelle” Hashes rapide verkürzt. Daher ist “Verge” im letzten Jahr offener geworden und bietet mehrere Möglichkeiten.

The Verge: Schlüsselziele

· Statusloser Client: Der für die vollständige Validierung des Clients und die Markierung des Nodes erforderliche Speicherplatz sollte nicht mehrere GB überschreiten.

· (Langfristig) Überprüfen Sie die Kette (Konsens und Ausführung) vollständig auf der Smartwatch. Daten herunterladen, SNARK überprüfen und abschließen.

In diesem Kapitel

· Nicht zustandsbehafteter Client: Verkle oder STARKs

· EVM ausgeführter Gültigkeitsnachweis

· Konsens的Gültigkeitsnachweis

Stateless Verification: Verkle oder STARKs

Welches Problem wollen wir lösen?

Heutzutage muss der ETH-Client Hunderte von Gigabyte an Statusdaten speichern, um den Block zu validieren, und diese Menge wächst jedes Jahr. Die ursprünglichen Statusdaten wachsen jedes Jahr um etwa 30 GB, und jeder Client muss zusätzliche Daten speichern, um das Tripel effektiv zu aktualisieren.

Dies reduziert die Anzahl der Benutzer, die in der Lage sind, eine vollständig validierte Ethereum-Node auszuführen: Obwohl es möglich ist, eine große Festplatte zu haben, die ausreicht, um den gesamten Ethereum-Status und sogar viele Jahre an Historie zu speichern, kaufen die meisten Menschen standardmäßig Computer mit nur ein paar hundert Gigabyte Speicherplatz. Die Größe des Status stellt auch eine große Hürde bei der erstmaligen Einrichtung einer Node dar: Die Node muss den gesamten Status herunterladen, was Stunden oder sogar Tage dauern kann. Dies hat verschiedene Auswirkungen. 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 Unterbrechung durchzuführen - indem man einen neuen Client startet, auf dessen Synchronisation wartet, dann den alten Client schließt und den geheimen Schlüssel überträgt. In der Praxis ist dies jedoch technisch sehr komplex.

Wie funktioniert es?

Die statuslose Validierung ist eine Technologie, die es Nodes ermöglicht, Blöcke zu validieren, ohne den gesamten Status zu kennen. Stattdessen wird jedem Block ein Zeuge beigefügt, der Folgendes enthält: (i) Werte, Code, Guthaben und Speicher an bestimmten Positionen im Status, auf die dieser Block zugreifen wird, und (ii) eine Verschlüsselungsnachweis, der beweist, dass diese Werte korrekt sind.

Tatsächlich erfordert die Umsetzung der zustandslosen Überprüfung eine Änderung der Zustandsbaumstruktur von Ethereum. Dies liegt daran, dass der aktuelle Merkle-Patricia-Baum für die Implementierung eines beliebigen Verschlüsselungsnachweisschemas äußerst unfreundlich ist, insbesondere im schlimmsten Fall. Sowohl die ‘rohen’ Merkle-Zweige als auch die Möglichkeit, sie in STARK zu ‘verpacken’, haben diese Eigenschaft. Die Hauptprobleme resultieren aus einigen Schwächen des MPT:

1. Dies ist ein Hexbaum (d. h. jeder Node hat 16 Kindknoten). Das bedeutet, dass in einem Baum der Größe N ein Beweis im Durchschnitt 32*(16-1)*log16(N) = 120* log2(N) Bytes benötigt oder etwa 3840 Bytes in einem Baum mit 2^32 Elementen. Für einen Binärbaum werden nur 32*(2-1)*log2(N) = 32* log2(N) Bytes benötigt, oder etwa 1024 Bytes.

2. Der Code wurde nicht merklich gemacht. Dies bedeutet, dass für den Zugriff auf den Konto-Code jede Berechtigung nachgewiesen werden muss, indem der gesamte Code bereitgestellt wird, maximal 24000 Bytes.

Wir können den schlimmsten Fall wie folgt berechnen:

30000000 Gas / 2400 (Kontolösekosten) *（5 * 488 + 24000) = 330000000 Bytes

Die Zweigkosten sind leicht gesunken (5 * 480 statt 8 * 480), da der obere Teil wiederholt wird, wenn es viele Zweige gibt. Dennoch ist es unrealistisch, die Datenmenge in einem Zeitschlitz herunterzuladen. Wenn wir versuchen, es mit STARK einzupacken, stoßen wir auf zwei Probleme: (i) KECCAK ist relativ unfreundlich zu STARK; (ii) 330 MB Daten bedeuten, dass wir 5 Millionen Aufrufe der KECCAK-Rundenfunktion beweisen müssen, was für alle Hardware außer der leistungsstärksten Verbraucherhardware möglicherweise nicht möglich ist, selbst wenn wir STARK dazu bringen können, die Effizienz von KECCAK zu verbessern.

Wenn wir den Hexbaum direkt durch einen Binärbaum ersetzen und den Code zusätzlich merkleisieren, wird sich das Schlimmste ungefähr auf 30000000/2400*32*(32-14+8) = 10400000 Byte belaufen (14 ist die Subtraktion der Redundanzbits für 2^14 Zweige und 8 ist die Länge des Nachweises im Blatt des Codeblocks). Beachten Sie, dass dies die Gas-Kosten verändern wird, um auf jeden einzelnen Codeblock zuzugreifen; EIP-4762 tut dies. 10,4 MB Kapazität ist viel besser, aber für viele Knoten ist immer noch zu viel Daten, die in einem Zeitschlitz heruntergeladen werden müssen. Daher müssen wir leistungsfähigere Techniken einführen. In dieser Hinsicht gibt es zwei führende Lösungen: Verkle-Bäume und STARKed binäre Hash-Bäume.

Verkle Baum

Der Verkle-Baum verwendet vektorbasierte Verpflichtungen auf elliptischen Kurven für kürzere Beweise. Der entscheidende Punkt ist, dass jeder Beweisteil, der jedem Eltern-Kind-Verhältnis entspricht, nur 32 Bytes hat, unabhängig von der Breite des Baums. Die einzige Einschränkung bei der Breite des Beweisbaums ist, dass die Berechnungseffizienz des Beweises 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 Nachweis zu 32 - 1og256(N) = 4* log2(N) Byte. Daher beträgt die theoretische maximale Größe des Nachweises ungefähr 30000000 / 2400 *32* (32 -14 + 8) / 8 = 130000 Byte (aufgrund der ungleichmäßigen Verteilung der Statusblöcke weicht das tatsächliche Ergebnis geringfügig ab, aber als erster Näherungswert ist dies akzeptabel).

Es ist auch wichtig zu beachten, dass in all den obigen Beispielen dieser “Worst-Case” nicht der schlimmste Fall ist: Der schlimmere Fall ist, wenn ein Angreifer absichtlich zwei Adressen “abbaut”, die eine längere gemeinsame Präfix in dem Baum haben und Daten von einer dieser Adressen liest, was die Länge des schlimmsten Falls um das Doppelte verlängern könnte. Aber selbst in einem solchen Fall beträgt die Länge des schlimmsten Beweises für den Verklebaum 2,6 MB, was im Wesentlichen den derzeitigen schlimmsten Fall der Validierungsdaten entspricht.

Wir haben auch etwas anderes mit dieser Maßnahme gemacht: Wir haben die Kosten für den Zugriff auf “benachbarten” Speicherplatz sehr niedrig gehalten: entweder viele Codeblöcke desselben Vertrags oder benachbarte Speicherplätze. EIP - 4762 definiert die Nähe und erhebt nur 200 Gas für den Zugriff auf die Nähe. Im Falle eines benachbarten Zugriffs beträgt die maximale Beweisgröße immer noch ca. 30000000 / 200 * 32 - 4800800 Bytes, was immer noch innerhalb der Toleranz liegt. Wenn wir aus Sicherheitsgründen diesen Wert reduzieren möchten, können wir die Kosten für den benachbarten Zugriff leicht erhöhen.

STARKed Binärbaum

Das Prinzip dieser Technologie ist selbsterklärend: Sie müssen nur einen binären Baum erstellen, der einen Beweis mit einer Größe von bis zu 10,4 MB enthält, um den Wert im Block zu bestätigen, und dann den Beweis durch den STARK-Beweis ersetzen. Auf diese Weise enthält der Beweis selbst nur die zu beweisenden Daten sowie eine feste Overhead von 100-300 kB aus dem tatsächlichen STARK.

Die Hauptherausforderung hier besteht darin, die Zeit zu verifizieren. Wir können Berechnungen durchführen, die ähnlich wie die oben genannten sind, nur dass wir nicht die Anzahl der Bytes, sondern den Hash-Wert berechnen. Ein Block von 10,4 MB bedeutet 330.000 Hash-Werte. Wenn wir die Möglichkeit hinzufügen, dass ein Angreifer “Adress”-Bäume mit längeren gemeinsamen Präfixen abbaut, dann werden im schlimmsten Fall etwa 660.000 Hash-Werte erreicht. Daher haben wir kein Problem, wenn wir beweisen können, dass 200.000 Hash-Werte pro Sekunde erreicht werden können.

Auf Verbraucher-Notebooks, die die Poseidon-Hash-Funktion verwenden, werden diese Zahlen erreicht, während die Poseidon-Hash-Funktion speziell für die STARK-Freundlichkeit entwickelt wurde. Das Poseidon-System ist jedoch noch relativ unreif, daher vertrauen ihm viele Menschen nicht in Bezug auf die Sicherheit. Es gibt also zwei realistische Wege nach vorne:

1. Führen Sie eine umfangreiche Sicherheitsanalyse von Poseidon durch und machen Sie sich mit ihm vertraut, um ihn auf L1 bereitzustellen.

2. Verwenden Sie eine " konservativere " Hash-Funktion wie SHA256 oder BLAKE

Um die Konservativität der Hash-Funktion zu demonstrieren, kann der STARK-Kreis von Starkware zum Zeitpunkt der Abfassung dieses Artikels nur etwa 10-30k Hash-Werte pro Sekunde auf einem Consumer-Notebook nachweisen. Die STARK-Technologie entwickelt sich jedoch schnell weiter. Selbst heute zeigt die auf GKR basierende Technologie, dass diese Geschwindigkeit auf den Bereich 100-200k erhöht werden kann.

Zeugenverwendungsfälle außerhalb der Blocküberprüfung

Neben der Validierung des Blocks gibt es drei weitere Schlüsselanwendungsfälle, die eine effizientere zustandslose Validierung erfordern:

· Mempool: Wenn eine Transaktion im P2P-Netzwerk ausgestrahlt wird, muss der Node überprüfen, ob die Transaktion gültig ist, bevor sie erneut ausgestrahlt wird. Dies umfasst heute die Überprüfung der Signatur sowie das Überprüfen des Kontostands und des Präfixes. In der Zukunft (z. B. unter Verwendung der Kontoabstraktion, wie EIP-7701) könnte dies das Ausführen von EVM-Code beinhalten, der auf den Status zugreift. Wenn ein Node zustandslos ist, muss die Transaktion einen Beweis für den Statusobjekt enthalten.

· Inklusive Liste: Dies ist eine vorgeschlagene Funktion, die (möglicherweise kleinere und weniger komplexe) Beglaubigung von Proof of Stake-Prüfern erlaubt, den nächsten Block mit Transaktionen zu erzwingen, unabhängig vom Willen des (möglicherweise größeren und komplexeren) Block Builders. Dadurch wird die Fähigkeit der Machthaber geschwächt, die Blockchain durch Verzögerungstransaktionen zu manipulieren. Allerdings müssen die Prüfer einen Weg haben, die Gültigkeit der Transaktionen in der enthaltenen Liste 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 Light Client ausführen (wie Helios). Das Kernmodul von Helios stellt den Benutzern einen verifizierten Statusbaum bereit. Um jedoch eine vollständig vertrauenslose Erfahrung zu ermöglichen, müssen Benutzer für jeden RPC-Aufruf, den sie tätigen, einen Nachweis erbringen (z. B. für eine ETH-Netzwerkanforderung müssen Benutzer nachweisen, dass sie auf alle während des Aufrufs zugegriffenen Status zugreifen können).

Alle diese Anwendungsfälle haben eine gemeinsame Eigenschaft: Sie erfordern alle eine beträchtliche Menge an Nachweisen, aber jeder Nachweis ist sehr klein. Daher haben STARK-Nachweise für sie keine praktische Bedeutung; stattdessen ist es am realistischsten, direkt Merkle-Zweige zu verwenden. Ein weiterer Vorteil von Merkle-Zweigen ist deren Aktualisierbarkeit: Bei Erhalt eines Subblocks B2 und seines Zeugen kann der Nachweis für einen Zustandsobjekt X mit Block B als Wurzel aktualisiert werden. Verkle-Nachweise sind ebenfalls natürlich aktualisierbar.

Welche Verbindungen gibt es zu bestehenden Studien?

· Verkle-Bäume

· John Kuszmaul über das ursprüngliche Verkle-Baum-Papier

· Starkware

· Poseidon2 Papier

· Ajtai (Alternative schnelle Hash-Funktion basierend auf Gitterhärte)

· Verkle.info

Was kann ich sonst noch tun?

Die restliche Hauptarbeit besteht darin

1. Mehr Analyse über die Auswirkungen von EIP-4762 (Veränderungen der Gas-Kosten ohne Zustand)

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

3. Weitere Sicherheitsanalysen zu Poseidon, Ajtai und anderen “STARK-freundlichen” Hash-Funktionen

4. Zur weiteren Entwicklung des “konservativen” (oder “traditionellen”) Hash mit hoch effizienter STARK-Protokoll-Funktionalität, beispielsweise basierend auf Binius oder GKR.

Darüber hinaus werden wir bald eine Entscheidung treffen, eine der folgenden drei Optionen auszuwählen: (i) Verkle-Baum, (ii) STARK-freundliche Hash-Funktion und (iii) konservative Hash-Funktion. Ihre Eigenschaften können grob in der folgenden Tabelle zusammengefasst werden:

Neben diesen “Überschriftszahlen” gibt es noch einige andere wichtige Überlegungen:

· Heute ist der Verkle-Code bereits ziemlich ausgereift. Die Verwendung eines anderen Codes als Verkle würde die Bereitstellung verzögern und wahrscheinlich zu einer harten Aufspaltung führen. Das ist auch in Ordnung, insbesondere wenn wir zusätzliche Zeit für die Analyse von Hash-Funktionen oder die Implementierung von Validatoren benötigen oder wenn wir andere wichtige Funktionen früher in Ethereum integrieren möchten.

· Die Aktualisierung des Statuswurzels mit Hash-Werten ist schneller als mit Verkle-Bäumen. Dies bedeutet, dass die synchronisierungszeit für Full Nodes durch die Verwendung von hashbasierten Methoden verringert werden kann.

· Verkle-Baum hat interessante erneuerbare Eigenschaften - Verkle-Baumzeugnis ist erneuerbar. Diese Eigenschaft ist nützlich für den Mempool, die Enthaltungsliste und andere Anwendungsfälle und kann auch zur Verbesserung der Implementierungseffizienz beitragen: Wenn der Statusobjekt aktualisiert wird, kann das Zeugnis der vorletzten Ebene aktualisiert werden, ohne den Inhalt der letzten Ebene lesen zu müssen.

Verkle-Baum ist schwieriger zu SNARK-beweisen. Wenn wir den Beweis auf einige tausend Bytes verkleinern wollen, wird der Verkle-Beweis einige Schwierigkeiten mit sich bringen. Dies liegt daran, dass die Überprüfung des Verkle-Beweises eine große Anzahl von 256-Bit-Operationen erfordert, was wiederum entweder erhebliche Kosten oder eine spezielle interne Struktur des Beweissystems erfordert, die einen 256-Bit-Teil des Verkle-Beweises enthält. Das ist an sich kein Problem für den Zustand, aber es bringt weitere Schwierigkeiten mit sich.

Wenn wir Verkle-Zeugenaktualisierbarkeit auf quantensichere und effiziente Weise erreichen wollen, ist ein weiterer möglicher Ansatz ein Merkle-Baum auf der Basis von Gitter.

Wenn sich herausstellt, dass das System im schlimmsten Fall nicht effizient genug ist, können wir dies mit unerwarteten Werkzeugen wie multidimensionalem Gas ausgleichen: separate Gasbeschränkungen für (i) Calldata, (ii) Berechnungen, (iii) Zustandszugriff und mögliche andere Ressourcen. Multidimensionales Gas erhöht die Komplexität, aber es begrenzt das Verhältnis zwischen Durchschnitts- und Worst-Case-Szenario strenger. Mit multidimensionalem Gas könnte die theoretisch maximale Anzahl von zu beweisenden Verzweigungen von 12500 auf beispielsweise 3000 reduziert werden. Dadurch wäre BLAKE3 selbst heute gerade noch ausreichend (knapp).

Multidimensionales Gas ermöglicht eine Ressourcenbeschränkung des Blocks, die näher an der Ressourcenbeschränkung der zugrunde liegenden Hardware liegt.

Ein weiteres unerwartetes Werkzeug ist die Berechnung der Latenzzeit des Zustandsbaums bis zum Block. Auf diese Weise haben wir ganze 12 Sekunden Zeit, um den Zustandsbaum zu berechnen. Dies bedeutet, dass selbst unter extremsten Bedingungen nur 60000 Hashes pro Sekunde ausreichen, was uns wiederum zu dem Schluss führt, dass BLAKE3 nur knapp ausreicht.

Ein Nachteil dieser Methode ist, dass sie zu einer Latenzzeit des Light Clients führt, jedoch gibt es auch raffiniertere Techniken, um diese Latenzzeit auf die Generierung der Proofs zu reduzieren. Zum Beispiel können die Proofs sofort nach der Generierung durch einen beliebigen Node im Netzwerk übertragen werden, anstatt auf den nächsten Block zu warten.

Wie interagiert es mit anderen Teilen der Roadmap?

Die Lösung des Zustandslosigkeitsproblems erhöht erheblich die Schwierigkeit des Einzelzielens. Wenn es technisch möglich ist, das Minimum des Einzelzielens zu senken, wie z.B. mit der Orbit SSF oder der Anwendungs-Layer-Strategie für Teamzielungen, wird dies machbarer.

Wenn EOF gleichzeitig eingeführt wird, wird die multidimensionale Gas-Analyse einfacher. Dies liegt daran, dass die Hauptkomplexität der multidimensionalen Gasausführung darin besteht, mit Unterfunktionen umzugehen, die nicht den gesamten Gaswert des übergeordneten Aufrufs übertragen. EOF kann solche Unterfunktionen einfach als ungültig markieren und dieses Problem vernachlässigbar machen (und die lokale Kontenabstraktion bietet ein Protokollinternes alternatives Konzept für den aktuellen Hauptverwendungszweck von teilweisem Gas).

Zwischen der statuslosen Überprüfung und dem Verfall der Historie besteht auch eine wichtige Synergie. Heutzutage muss der Client fast 1 TB an Historiendaten speichern; diese Daten sind mehrfach so groß wie die Statusdaten. Selbst wenn der Client statuslos ist, wird der Traum von einem fast speicherlosen Client kaum verwirklicht werden können, solange wir nicht die Verantwortung des Clients zur Speicherung der Historiendaten aufheben können. Der erste Schritt in diese Richtung ist EIP-4444, was bedeutet, dass die Historiendaten in Torrents oder auf dem Portalnetzwerk Portal Network gespeichert werden.

Gültigkeitsnachweis der EVM-Ausführung

Welches Problem wollen wir lösen?

Das langfristige Ziel der Ether-Blockvalidierung ist klar definiert - Ether-Blöcke sollten auf folgende Weise validiert werden können: (i) Herunterladen des Blocks oder sogar nur eines kleinen Teils der Datenverfügbarkeit, die im Block abgetastet wurde; (ii) Überprüfung eines kleinen Nachweises für die Gültigkeit des Blocks. Dies wäre eine Ressourcen-sparende Operation, die auf einem mobilen Client, in einer Browser-Wallet oder sogar in einer anderen Kette durchgeführt werden kann (ohne Datenverfügbarkeitsteil).

Um dies zu erreichen, müssen die (i) Konsenschicht (d. h. der Nachweis des Aktienbesitzes) und (ii) Ausführungsschicht (d. h. das EVM) SNARK- oder STARK-Beweise erbringen. Ersteres ist an sich schon eine Herausforderung, die im Rahmen der kontinuierlichen Verbesserung der Konsenschicht gelöst werden sollte (z. B. durch die Berücksichtigung von Einzel-Slot-Endspielen). Letzteres erfordert einen EVM-Ausführungsnachweis.

Was ist das und wie funktioniert es?

Vom formalen Standpunkt aus wird die EVM in der ETH-Spezifikation als eine Zustandsübergangsfunktion definiert: Sie haben einen bestimmten vorherigen Zustand S, einen Block B, und Sie berechnen einen neuen Zustand S’ = STF(S, B). Wenn ein Benutzer den Light Client verwendet, besitzt er nicht den vollständigen vorherigen Zustand S und den neuen Zustand S’, oder sogar E; stattdessen besitzt er eine vorherige Zustandswurzel R, eine neue Zustandswurzel R’ und einen Block-Hashwert H.

Öffentliche Eingabe: Vorheriger Zustandsbaum R, Nachfolgender Zustandsbaum R’, Block-Hash H

· Private Eingabe: Objekte im Zustand, auf die der Programmblock B und der Programmblock Q zugreifen, dieselben Objekte nach Ausführung des Programmblocks Q’, Zustandsnachweis (z. B. Merkle-Zweig) 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 die internen Objekte von Q zu, (ii) sind die Datenblöcke gültig, (iii) ist das Ergebnis Q’

· Behauptung 3: Wenn Sie die Informationen von Q’ und P verwenden, um den neuen Zustand des Wurzels neu zu berechnen, erhalten Sie R’

Wenn es einen solchen Fall gibt, kann ein Leichtgewichtsclient implementiert werden, der die EVM-Ausführung von Ethereum vollständig validiert. Dies macht die Ressourcen des Clients bereits ziemlich gering. Um einen echten vollständig validierenden Ethereum-Client zu realisieren, muss auch in Bezug auf den Konsens die gleiche Arbeit geleistet werden.

Die Implementierung des Gültigkeitsnachweises für die EVM-Berechnung existiert bereits und wird von L2 in großem Umfang genutzt. Es gibt jedoch noch viel Arbeit zu tun, um den Gültigkeitsnachweis für die EVM auf L1 umsetzbar zu machen.

Welche Verbindungen gibt es zu bestehenden Forschungen?

· EFPSE ZK-EVM（由于存在更好的选择，现已停用）

· Zeth, dessen Funktionsweise darin besteht, die EVM in den RISC-0 ZK-VM zu kompilieren

· ZK-EVM Formale Verifizierung项目

Was kann ich sonst noch tun?

Der Gültigkeitsnachweis des elektronischen Buchungssystems weist derzeit zwei Schwachstellen auf: Sicherheit und Validierungszeit.

Ein sicherer Gültigkeitsnachweis muss sicherstellen, dass SNARK tatsächlich die Berechnung von EVM überprüft und keine Fehler vorhanden sind. Die beiden Haupttechnologien zur Verbesserung der Sicherheit sind Multiple Validators und formale Verifikation. Multiple Validators bezieht sich auf mehrere unabhängig voneinander geschriebene Implementierungen von Gültigkeitsnachweis, ähnlich wie bei mehreren Clients. Wenn ein Block von einem ausreichend großen Teil dieser Implementierungen nachgewiesen wird, akzeptiert der Client den Block. Formale Verifikation beinhaltet die Verwendung von Werkzeugen, die normalerweise zur Beweisführung mathematischer Theoreme verwendet werden, wie z.B. Lean4, um nachzuweisen, dass der Gültigkeitsnachweis nur korrekt ausgeführte unterliegende EVM-Spezifikationen akzeptiert (z.B. EVM K-Semantik oder die auf Python geschriebene Ethereum-Ausführungsschicht-Spezifikation (EELS)).

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 wir uns vor zwei Jahren vorgestellt haben. Um dieses Ziel zu erreichen, müssen wir in drei Richtungen Fortschritte erzielen:

· Parallelisierung - Der derzeit schnellste EVM-Prüfer kann im Durchschnitt innerhalb von 15 Sekunden einen Ethereum-Block nachweisen. Dies wird erreicht, indem die Arbeit über Hunderte von GPUs parallelisiert und am Ende zusammengeführt wird. Theoretisch wissen wir genau, wie man einen EVM-Prüfer herstellt, der Berechnungen in O(log(N)) Zeit nachweisen kann: Lassen Sie eine GPU jeden Schritt ausführen und erstellen Sie dann einen „Aggregationsbaum“: 01928374656574839201

Die Umsetzung dieser Idee birgt Herausforderungen. Selbst im schlechtesten Fall, wenn eine sehr große Transaktion den gesamten Block einnimmt, kann die Aufteilung der Berechnung nicht sequentiell erfolgen, sondern muss nach den Operation Codes (EVM oder RISC-V und anderen unteren Operation Codes der Virtuellen Maschine) erfolgen. Es ist eine wichtige Herausforderung während des Implementierungsprozesses sicherzustellen, dass der “Speicher” der Virtuellen Maschine zwischen verschiedenen Teilen des Nachweises konsistent ist. Wenn wir jedoch diesen rekursiven Beweis durchführen können, wissen wir, dass zumindest das Latenzproblem des Beweisers gelöst ist, selbst wenn in anderen Aspekten keine Verbesserungen vorgenommen wurden.

· Optimierung des Nachweissystems–Neue Nachweissysteme wie Orion, Binius, GRK und weitere Informationen könnten wahrscheinlich zu einer erheblichen Verkürzung der Validierungszeit für allgemeine Berechnungen führen.

· Weitere Veränderungen der EVM Gas-Kosten - Viele Dinge in der EVM können optimiert werden, um sie für die Verifizierenden vorteilhafter zu machen, insbesondere in den schlimmsten Fällen. Wenn ein Angreifer einen Block erstellen kann, der die Verifizierenden für zehn Minuten blockiert, reichen 4 Sekunden nicht aus, um einen gewöhnlichen ETH-Block zu verifizieren. Die erforderlichen EVM-Änderungen lassen sich grob in folgende Kategorien einteilen:

• Die Veränderung der Gas-Kosten - Wenn eine Operation lange dauert, um nachgewiesen zu werden, sollte selbst bei relativ schneller Berechnung eine hohe Gas-Kosten haben. EIP-7667 ist ein EIP, das zur Behandlung dieses schwerwiegendsten Problems vorgeschlagen wurde: Es erhöht erheblich die Gas-Kosten für (traditionelle) Hash-Funktionen, da die Opcodes und Precompiles dieser Funktionen relativ günstig sind. Um diesen Anstieg der Gas-Kosten auszugleichen, können wir die Gas-Kosten für EVM-Operationen senken, bei denen der Nachweis relativ kostengünstig ist, um die durchschnittliche Durchsatzrate konstant zu halten.

• Datenstrukturersetzung - Neben dem Austausch des Zustandsbaums durch eine STARK-freundlichere Methode müssen wir auch die Transaktionsliste, den Quittungsbaum und andere kostspielige Strukturen ersetzen. Die Verlagerung der Transaktions- und Quittungsstruktur auf SSZ durch Etan Kissling ist ein Schritt in diese Richtung.

Darüber hinaus können die beiden in dem vorherigen Abschnitt erwähnten Werkzeuge (multidimensionales Gas und Latenzzeit-Statuswurzel) ebenfalls in diesem Bereich hilfreich sein. Es ist jedoch zu beachten, dass im Gegensatz zur zustandslosen Überprüfung die Verwendung dieser beiden Werkzeuge bedeutet, dass wir bereits über genügend technische Fähigkeiten verfügen, um die derzeit erforderliche Arbeit zu erledigen, und selbst wenn diese Technologien verwendet werden, erfordert die vollständige ZK-EVM-Überprüfung zusätzliche Arbeit - nur eben weniger.

Ein Punkt, der im vorherigen Text nicht erwähnt wurde, ist die Hardware des Beweisers: Die Verwendung von GPU-, FPGA- und ASIC ist schneller bei der Generierung von Beweisen. 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 eine starke Dezentralisierung von L1 wünschen. Dies bedeutet, dass die Beweisgenerierung im vernünftigen Bereich der ETH-Nutzer erfolgen muss und nicht durch Engpässe in der Hardware eines einzelnen Unternehmens eingeschränkt werden sollte. L2 kann aktivere Abwägungen treffen.

In diesen Bereichen gibt es noch viel Arbeit zu tun:

· Die parallele Beweisanforderung bedeutet, dass verschiedene Teile des Beweissystems “gemeinsamen Speicher” (z.B. Suchtabellen) haben können. Wir kennen die Technologie dafür, aber es muss noch umgesetzt werden.

· Wir müssen mehr Analysen durchführen, um die ideale Gas-Kostenänderungssammlung zu finden, um die Validierungszeit im schlimmsten Fall maximal zu reduzieren.

· Wir müssen mehr Arbeit im Bereich des Nachweissystems leisten

Mögliche Kosten sind:

· Sicherheit und Validierungszeit: Wenn eine aggressivere Hash-Funktion, ein komplexeres Nachweissystem oder aggressivere Sicherheitsannahmen oder andere Designansätze gewählt werden, ist es möglicherweise möglich, die Validierungszeit zu verkürzen.

· Dezentralisierung und Proof-of-Stake: Die Gemeinschaft muss sich auf die ‘Spezifikationen’ der angestrebten Proof-of-Stake-Hardware einigen. Sollten die Validator-Knoten von massiven Einrichtungen betrieben werden? Sollen High-End-Laptops in der Lage sein, einen ETH-Block in 4 Sekunden zu validieren? Oder liegt die Wahrheit irgendwo dazwischen?

· Grad der Brechung der Abwärtskompatibilität: Andere Mängel können durch eine aktivere Änderung der Gas-Kosten ausgeglichen werden, dies könnte jedoch die Kosten einiger Anwendungen unverhältnismäßig erhöhen und Entwickler dazu zwingen, Code neu zu schreiben und erneut bereitzustellen, um die wirtschaftliche Machbarkeit aufrechtzuerhalten. Diese beiden Werkzeuge haben auch ihre eigene Komplexität und Nachteile.

Wie interagiert es mit anderen Teilen der Roadmap?

Die Kerntechnologie, die für den Gültigkeitsnachweis von L1 EVM erforderlich ist, ist in hohem Maße mit zwei anderen Bereichen gemeinsam:

· L2 的Gültigkeitsnachweis（即「ZK rollup」）

· Der STARK binäre Hash-Beweis ohne Zustand

Durch die erfolgreiche Implementierung von Gültigkeitsnachweis in L1 kann letztendlich ein problemloses Einzel-Staken’ erreicht werden: Selbst die schwächsten Computer (einschließlich Mobiltelefone oder Smartwatches) können Staken’. Dies erhöht weiterhin den Wert der Lösung anderer Beschränkungen für das Einzel-Staken’ (wie das Mindestlimit von 32ETH).

Darüber hinaus kann der EVM Gültigkeitsnachweis für L1 den Gas-Grenzwert erheblich erhöhen.

Konsens Gültigkeitsnachweis

Welches Problem wollen wir lösen?

Wenn wir einen ETH-Block mit SNARK vollständig überprüfen wollen, ist die Ausführung von EVM nicht der einzige Teil, den wir beglaubigen müssen. Wir müssen auch den Konsens beglaubigen, d.h. die Teile des Systems, die Einlagen, Abhebungen, Signaturen, die Aktualisierung der Validator-Guthaben und andere Elemente des Proof of Stake-Teils von ETH-Blöcken betreffen.

Konsens ist viel einfacher als EVM, aber die Herausforderung besteht darin, dass wir keine L2-EVM-Faltung haben, so dass die meiste Arbeit sowieso erledigt werden muss. Daher muss jede Implementierung des Beweis-ETH-Workshops Konsens “von Grund auf neu gestartet” werden, obwohl das Beweissystem selbst ein gemeinsames Werk ist, das darauf aufgebaut werden kann.

Was ist das und wie funktioniert es?

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

· ECADD (zur Überprüfung der BLS-Signatur)

· Pairing (zur Überprüfung der BLS-Signatur)

· SHA256-Hashwert (für das Lesen und Aktualisieren des Status)

In jedem Block müssen wir 1-16 BLS12-381 ECADDs für jeden Validator nachweisen (möglicherweise mehr als einen, da Signaturen in mehreren Sammlungen enthalten sein können). Dies kann durch Teilmengen-Vorberechnungstechniken kompensiert werden, so dass wir sagen können, dass jeder Prüfer nur einen BLS12-381 ECADD nachweisen muss. Derzeit gibt es 30.000 Validator-Signaturen pro Slot. In Zukunft könnte sich dies in zwei Richtungen ändern, wenn die Single-Slot-Finalität erreicht wird: Wenn wir den “Brute-Force”-Weg gehen, könnte sich die Anzahl der Prüfer pro Slot auf 1 Million erhöhen. Gleichzeitig wird die Zahl der Validatoren bei der Einführung von Orbit SSF bei 32.768 bleiben oder sogar auf 8.192 sinken.

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

In Bezug auf Pairing gibt es derzeit maximal 128 Proofs pro Slot, was bedeutet, dass 128 Pairings verifiziert werden müssen. Mit ElP-7549 und weiteren Anpassungen kann die Anzahl der Pairings pro Slot auf 16 reduziert werden. Die Anzahl der Pairings ist gering, aber die Kosten sind extrem hoch: Die Laufzeit (oder der Beweis) pro Paarung ist um ein Vielfaches länger als ECADD.

Eine der Hauptherausforderungen bei der Berechnung von BLS12-381 besteht darin, dass es keine bequemen Kurven gibt, deren Reihenfolge der Größe des BLS12-381-Feldes entspricht, was jedem Beweissystem erhebliche Kosten verursacht. Andererseits wurde für Ethereum die Verkle-Baumstruktur mit der Bandersnatch-Kurve entwickelt, wodurch BLS12-381 selbst zu einer Unter-Kurve für den Nachweis von Verkle-Zweigen in SNARK-Systemen wird. Eine einfachere Implementierung kann 100 G1-Additionen pro Sekunde nachweisen. Um eine ausreichend schnelle Beweisgeschwindigkeit zu erreichen, wird wahrscheinlich eine clevere Technik wie GKR benötigt.

Für den SHA256-Hashwert ist das schlimmste Szenario bisher der Epoch-Transition-Block, bei dem der gesamte Validator-Short-Balance-Tree und eine große Anzahl von ausgewogenen Validatoren aktualisiert werden. Der Short-Balance-Tree eines jeden Validators besteht nur aus einem Byte, daher werden 1 MB Daten erneut gehasht. Dies entspricht 32768 SHA256-Aufrufen. Wenn das Guthaben von tausend Prüfern höher oder niedriger als ein Schwellenwert ist, muss das gültige Guthaben in den Prüferdatensätzen aktualisiert werden, was tausend Merkle-Zweige erfordert und daher möglicherweise zehntausend Hashes erfordert. Der Shuffle-Mechanismus erfordert 90 Bit pro Validator (daher 11 MB Daten), kann jedoch zu jeder Zeit in einer Epoche berechnet werden. In dem Fall eines einzelnen Slot-Endes können sich diese Zahlen je nach den spezifischen Umständen ändern. Das Mischen wird unnötig, obwohl Orbit diese Notwendigkeit möglicherweise in gewissem Maße wiederherstellen kann.

Eine weitere Herausforderung besteht darin, dass der gesamte Validierungsstatus, einschließlich des Public Key, erneut abgerufen werden muss, um einen Block zu verifizieren. Für 1 Million Validatoren sind allein das Lesen des Public Key und die Merkle-Zweige erforderlich, was zu Millionen von Hashwerten pro Ära führt. Wenn wir die Gültigkeit von PoS nachweisen müssen, ist eine realistische Methode eine Form von inkrementeller verifizierbarer Berechnung: Speichern einer separaten Datenstruktur im Beweissystem, die optimiert ist, um effizient nachzuschlagen und die Aktualisierungen an dieser Struktur zu beweisen.

Insgesamt gibt es viele Herausforderungen. Um diesen Herausforderungen effektiv zu begegnen, ist es wahrscheinlich erforderlich, eine gründliche Neugestaltung der Beacon Chain vorzunehmen, möglicherweise gleichzeitig mit dem Übergang zum Single-Slot-Ende. Diese Neugestaltung könnte folgende Merkmale umfassen:

· Änderungen der Hash-Funktion: Es wird jetzt die vollständige SHA256-Hash-Funktion verwendet, daher muss bei jedem Aufruf zwei Mal auf die darunter liegende Komprimierungsfunktion zugegriffen werden, aufgrund der erforderlichen Polsterung. Wenn die SHA256-Komprimierungsfunktion verwendet wird, könnten wir mindestens das Doppelte an Gewinn erzielen. Wenn wir Poseidon verwenden, könnten wir möglicherweise einen Gewinn von 100-fach erzielen und damit alle unsere Probleme (zumindest in Bezug auf den Hash-Wert) vollständig lösen: Mit einer Geschwindigkeit von 1,7 Millionen Hash-Werten pro Sekunde (54 MB) könnten sogar eine Million Überprüfungsaufzeichnungen in wenigen Sekunden im Beweis „gelesen“ werden.

· Wenn es sich um Orbit handelt, speichern Sie einfach die geschüttelten Validator-Einträge: Wenn eine bestimmte Anzahl von Validatoren (wie 8192 oder 32768) als Kommission für einen gegebenen Steckplatz ausgewählt wird, werden sie direkt in den benachbarten Zustand eingefügt, sodass nur der minimale Hash erforderlich ist, um alle öffentlichen Schlüssel der Validatoren im Nachweis zu lesen. Auf diese Weise können auch alle Gleichgewichtsaktualisierungen effizient abgeschlossen werden.

· Signaturaggregation: Jedes hochleistungsfähige Signaturaggregationsverfahren beinhaltet einen gewissen Grad an rekursivem Nachweis, bei dem verschiedene Knoten im Netzwerk Zwischenbeweise für Teilmenge der Signaturen erbringen. Dadurch wird die Beweisarbeit natürlicherweise auf mehrere Knoten im Netzwerk verteilt und die Arbeitsbelastung für den „endgültigen Beweiser“ 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 Signaturschemas kann dieses Ergebnis weiterhin durch einen sehr kleinen Konstantenfaktor verbessert werden. Wenn wir Poseidon verwenden, kann dies innerhalb eines einzelnen Steckplatzes bewiesen werden. Tatsächlich ist die Verwendung eines rekursiven Aggregationsschemas jedoch schneller.

Welche Verbindungen gibt es zu bestehenden Forschungen?

· Konsensnachweis für das Ethereum-Netzwerk (nur für synchronisierte Ausschüsse)

· Helios in der Einfachheit SP1

· Kompilierte BLS12-381

· BLS-Sammlungssignaturüberprüfung basierend auf Halo2

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

Tatsächlich benötigen wir mehrere Jahre, um den Gültigkeitsnachweis für den Konsens von ETH-Konsens zu erhalten. Dies entspricht in etwa dem Zeitrahmen, den wir benötigen, um Single-Slot-Endgültigkeit, Orbit, Signatur-Algorithmus-Änderungen und Sicherheitsanalysen umzusetzen. Für Sicherheitsanalysen ist ausreichendes Vertrauen erforderlich, um Hash-Funktionen wie Poseidon zu verwenden. Daher ist es am klügsten, diese anderen Probleme zu lösen und dabei die Starks-Freundlichkeit im Auge zu behalten.

Die Hauptabwägung liegt wahrscheinlich in der Reihenfolge der Operationen, zwischen einem inkrementellen Ansatz zur Reform der Ethereum-Konsensebene und einem radikaleren Ansatz des “Viele-Änderungen-auf-einmal”. Für die EVM ist ein inkrementeller Ansatz vernünftig, da er die Störungen in der Abwärtskompatibilität auf ein Minimum reduzieren kann. Für die Konsensebene ist die Auswirkung auf die Abwärtskompatibilität geringer, und es ist auch vorteilhaft, die verschiedenen Details beim Aufbau der Beacon Chain umfassender neu zu überdenken, um die SNARK-Freundlichkeit optimal zu optimieren.

Wie interagiert es mit anderen Teilen der Roadmap?

Bei der langfristigen Neugestaltung von Ethereum PoS muss die STARK-Freundlichkeit eine oberste Priorität sein, insbesondere in Bezug auf Single-Slot-Finality, Orbit, Änderungen am Signaturschema und Signaturaggregation.

Original link