Vitalik: Die mögliche Zukunft des Ethereum -Protokolls – der Verge

Autor: Vitalik, Gründer von Ethereum;

Hinweis: Dieser Artikel ist der vierte Teil der Artikelreihe, die kürzlich von Vitalik, Gründer von Ethereum, veröffentlicht wurde.Mögliche Futures des Ethereum -Protokolls, Teil 4: Der Verge„. Sehen „Vitalik: Hauptziele des Ethereum Die Geißelphase„, Siehe den zweiten Teil“Vitalik: Wie sollte sich das Ethereum -Protokoll im Surge -Stadium entwickeln?„, Siehe den ersten Teil“Was kann bei Ethereum POS noch verbessert werden”.

---

Besonderer Dank geht an Justin Drake, Hsiao-Wei Wang, Guillaume Ballet, Ignacio, Josh Rudolf, Lev Soukhanov, Ryan Sean Adams und Uma Roy für ihr Feedback und die Bewertung.

Eines der leistungsstärksten Merkmale von Blockchain ist, dass jeder Knoten auf seinen eigenen Computern ausführen und überprüfen kann, ob die Kette korrekt ist.Selbst wenn 95% der Knoten auf dem Kettenkonsens (POW, POS …) sofort zustimmen, die Regeln zu ändern und Blöcke gemäß den neuen Regeln zu produzieren, wird jeder, der einen vollständig validierten Knoten ausführt, die Annahme der Kette ablehnen.Stakeholder, die nicht zu solchen Gruppen angehören, werden automatisch konvergieren und weiterhin eine Kette erstellen, die weiterhin den alten Regeln befolgt, und die Benutzer werden die Kette vollständig verifiziert.

Dies ist der Hauptunterschied zwischen Blockchain- und zentralisierten Systemen.Um diese Funktion aufrechtzuerhalten, muss jedoch für eine kritische Anzahl von Personen die voll validierten Knoten tatsächlich möglich sein.Dies gilt für beide Staker (als hätten die Staker keine Überprüfungskette, sie tragen nicht zur Durchsetzung von Protokollregeln bei) und für normale Benutzer bei.Heute können Knoten auf Verbraucherlaptops betrieben werden, einschließlich derjenigen, die diesen Artikel geschrieben haben, aber es ist schwierig, dies zu tun.Das Verge zielt darauf ab, dies zu ändern und die Rechenkosten einer vollständigen Überprüfungskette so niedrig zu gestalten, dass jede mobile Brieftasche, jede Browser -Brieftasche und sogar Smartwatch dies standardmäßig tun.

Der Verge, 2023 Roadmap.

Anfänglich bezieht sich „Verge“ auf die Idee, die Speicherung von Ethereum State auf Leerzeichen zu übertragen – eine Baumstruktur, die kompaktere Beweise ermöglicht, die die aufsichtslose Überprüfung von Ethereum -Blöcken ermöglichen.Knoten können Ethereum -Blöcke ohne Ethereum -Staat (Kontostand, Vertragscode, Speicher …) auf ihrer Festplatte überprüfen, jedoch auf Kosten der Ausgabe von Hunderten von Kilobyten von Beweisdaten und Hunderten von Millisekunden mit zusätzlicher Zeit, um den Beweis zu überprüfen.Heutzutage stellt Verge eine größere Vision dar, die sich auf die Erreichung der maximalen Überprüfung der Ressourceneffizienz der Ethereum -Kette konzentriert, die nicht nur eine staatenlose Überprüfungstechnologie umfasst, sondern auch alle Ethereum -Ausführungen mithilfe von Snark validiert.

Zusätzlich zum langfristigen Fokus auf die Snark-Validierung der gesamten Kette bezieht sich eine weitere neue Frage damit, ob Leerzeichen die beste Technologie sind.VERKLE -Bäume sind anfällig für Quantencomputer. Wenn wir also die aktuellen Keckak Merkle Patricia -Bäume durch Perkle -Bäume ersetzen, müssen wir diese Bäume später erneut ersetzen.Eine natürliche Alternative zu Merkle -Bäumen besteht darin, direkt zur Verwendung des Stark Merkle -Zweigs im Binärbaum zu springen.In der Vergangenheit wurde dies aufgrund von Gemeinkosten und technischer Komplexität als unmittelbar angesehen.In jüngster Zeit haben Starkware bei Laptops mit Kreis Stark 1,7 Millionen Poseidon -Hashs pro Sekunde erwiesen, und die Beweiszeit für „traditionelle“ Hashs ist auch aufgrund von Technologien wie GKR schnell schrumpfen.

Im vergangenen Jahr ist Verge offener geworden und es gibt mehrere Möglichkeiten.

Der Verge: Hauptziele

• Staateless Client: Überprüfen Sie, ob der Client und der festgelegte Knoten nicht mehr als nur wenige GB Speicherplatz benötigen.

• (Langfristige) umfassende Überprüfungskette (Konsens und Ausführung) für Smartwatches.Laden Sie einige Daten herunter, überprüfen Sie Snark und beenden Sie.

In diesem Artikel wird der folgende Inhalt hervorgehoben:

• Staatenlose Überprüfung: Kene oder Starks

• Nachweis der Gültigkeit der EVM -Ausführung

• Nachweis der Gültigkeit des Konsenses

Staatenlose Überprüfung: Kene oder Starks

Welche Probleme wollen wir lösen?

Heute müssen Ethereum -Kunden Hunderte von GB staatlichen Daten speichern, um Blöcke zu überprüfen, und diese Zahl erhöht sich jedes Jahr weiter.Die Daten der Rohstaaten erhöhen sich um etwa 30 GB pro Jahr, und persönliche Kunden müssen zusätzliche Daten speichern und die Versuche effektiv aktualisieren können.

Dies reduziert die Anzahl der Benutzer, die die Ethereum -Knoten vollständig verifiziert haben: Obwohl die Festplatte groß genug ist, um den gesamten Ethereum -Staat und sogar jahrelange Geschichte zu speichern, haben Computer, die die Menschen standardmäßig kaufen, nur wenige hundert Gigabyte Speicherplatz.Die Zustandsgröße kann auch beim ersten Einrichten eines Knotens zum ersten Mal große Probleme verursachen: Der Knoten muss den gesamten Zustand herunterladen, der Stunden oder Tage dauern kann.Dies führt zu verschiedenen Kettenreaktionen.Dies macht es den Stakern beispielsweise schwieriger, ihre Beteiligungseinstellungen zu verbessern.Technisch gesehen kann dies ohne Ausfallzeit erfolgen – einen neuen Kunden zu starten, darauf zu synchronisieren, dann den alten Kunden zu schließen und den Schlüssel zu übertragen -, aber in Wirklichkeit ist dies technisch komplex.

Was ist es und wie funktioniert es?

Die staatenlose Überprüfung ist eine Technik, mit der Knoten Blöcke ohne vollständigen Zustand überprüfen können.Stattdessen wird jeder Block mit einem Zeugen geliefert, der (i) Werte an einem bestimmten Ort im Zustand enthält korrekt von.

Die tatsächliche Umsetzung der staatenlosen Überprüfung erfordert die Änderung der Struktur der Ethereum State Tree.Dies liegt daran, dass der aktuelle Merkle Patricia Tree äußerst unfreundlich ist, um einen Nachweis des Passwortschemas zu implementieren, insbesondere im schlimmsten Fall.Dies gilt für den „ursprünglichen“ Merkle -Zweig und die Möglichkeit, den Merkle -Zweig in Stark zu „einwickeln“.Die Hauptschwierigkeiten sind zwei Schwächen in MPT:

• Es ist ein Hexagramm (d. H. Jeder Knoten hat 16 untergeordnete Knoten).Dies bedeutet, dass der Beweis in einem Baum mit Größe n im Durchschnitt 32*(16-1)*log16 (n) = 120*log2 (n) Bytes oder etwa 3840 Bytes in einem 232-Punkte-Baum hat.Für binäre Bäume werden nur 32*(2-1)*log2 (n) = 32*log2 (n) Bytes benötigt, d. H. Etwa 1024 Bytes.

• Dieser Code ist nicht merkelisiert.Dies bedeutet, dass jeder Zugriff auf den Kontocode erforderlich ist, um den vollständigen Code mit einer maximalen Länge von 24.000 Bytes bereitzustellen.

Wir können den schlimmsten Fall wie folgt berechnen:

30.000.000 Gas / 2.400 („Kalt“ -Konto -Lesekosten) * (5 * 480 + 24.000) = 330.000.000 Bytes

Die Zweigkosten sind geringfügig niedriger (5*480 anstelle von 8*480), denn wenn es viele Zweige gibt, wird die Oberseite des Zweigs wiederholt.Trotzdem ist die Menge der in einem Steckplatz heruntergeladenen Daten völlig unrealistisch.Wenn wir versuchen, es in Stark zu wickeln, haben wir zwei Probleme: (i) Keccak ist im Vergleich zu Stark nicht freundlich, (ii) 330 MB Daten bedeutet, dass wir 5 Millionen Anrufe an die Keccak -Rundfunktion nachweisen müssen, die es ein Weg ist Auch wenn wir Stark Keccak effizienter beweisen können, gibt es neben der leistungsstärksten Verbraucherhardware noch viel mehr Dinge, die auf der gesamten Hardware nicht nachgewiesen werden können.

Wenn wir das Hexagramm nur durch einen Binärbaum ersetzen und den Merkelize -Code hinzufügen, beträgt der schlimmste Fall etwa 30.000.000 / 2.400 * 32 * (32 – 14 + 8) = 10.400.000 Bytes ~ 214 Zweige, von denen 8 der Eingang des Längens beweisen ein Blatt).Beachten Sie, dass dies erforderlich ist, um die Gaskosten für den Zugriff auf jeden einzelnen Codeblock zu ändern.10.4 MB ist viel besser, aber für viele Knoten gibt es immer noch zu viele Daten, um in einem Slot herunterzuladen.Wir müssen also einige leistungsfähigere Technologien einführen.Dazu gibt es zwei Hauptlösungen: den Perkle -Baum und den krassen Binärbaum.

VERKLE TREE

Vektorbäume verwenden Vektorverpflichtungen, die auf elliptischen Kurven basieren, um kürzere Beweise zu machen.Der Schlüssel ist, dass das entsprechende Beweisfragment für jede Eltern-Kind-Beziehung unabhängig von der Breite des Baumes nur 32 Bytes beträgt.Die einzige Einschränkung der Baumbreite ist, dass, wenn der Baum zu breit ist, die Recheneffizienz des Beweises reduziert wird.Die empfohlene Implementierungsbreite von Ethereum beträgt 256.

Daher beträgt die Größe eines einzelnen Asts im Beweis 32*log256 (n) = 4*log2 (n) Bytes.Theoretisch beträgt die maximale Beweisgröße etwa 30.000.000/2.400*32*(32-14+8)/8 = 1.300.000 Bytes (mathematische Berechnungen unterscheiden sich in der Praxis aufgrund der ungleichmäßigen Verteilung der Zustandsblöcke, aber dies ist die erste sehr gut) .

Beachten Sie als zusätzliche Warnung, dass dieser „schlimmste Fall“ in allen obigen Beispielen nicht der schlimmste Fall ist: Der schlimmere Fall ist, dass der Angreifer absichtlich zwei Adressen „Minen“ „absichtlich“ ein langes öffentliches Publikum im Baumpräfix „aus“ Minen „aus“ abgelesen „ist und von Einer von ihnen kann die schlimmste Niederlasslänge um etwa das 2-fache verlängern.Aber selbst bei einer solchen Warnung gibt uns der Leerzeichen ungefähr 2,6 MB Worst-Case-Proofs, was in etwa dem heutigen schlimmsten Case-Anrufdaten übereinstimmt.

Wir verwenden diese Warnung auch, um eine andere Sache zu machen: Wir ermöglichen den Zugriff auf „benachbarte“ Speicher sehr günstig: Viele Codeblöcke desselben Vertrags oder angrenzende Speicherplätze.EIP-4762 liefert die Definition von Adjazenz, und der Adjazenzzugang wird nur eine Gasgebühr von 200 aufgeladen.Für den benachbarten Zugang beträgt die schlimmste Beweisgröße 30.000.000/200*32 = 4.800.800 Bytes, was noch ungefähr im Toleranzbereich liegt.Wenn wir diesen Sicherheitswert verringern möchten, können wir die Kosten des benachbarten Zugangs leicht erhöhen.

Sterner binärer Haschbaum

Die Technik hier ist sehr selbsterklärend: Sie machen einen binären Baum, nehmen den MAX-10,4-MB-Beweis, dass Sie den Wert in einem Block nachweisen und den Beweis durch den Stark dieses Beweises ersetzen müssen.Dies lässt uns feststellen, dass der Beweis selbst nur die nachgewiesenen Daten sowie den festen Aufwand des tatsächlichen Starks enthält.

Die größte Herausforderung hier ist es, Zeit zu beweisen.Wir können im Grunde die gleiche Berechnung wie oben tun, außer dass wir die Bytes nicht berechnen, sondern den Hash -Wert berechnen.Ein 10,4 MB -Block bedeutet 330.000 Hashes.Wenn wir die Möglichkeit hinzufügen, dass ein Angreifer die Adresse mit einem langen öffentlichen Präfix im Baum „Minen“ „Minen“ „“ Minen „“ „, wird der wirklich schlimmste Fall etwa 660.000 Hashes werden.Wenn wir also etwa 200.000 Hashes pro Sekunde beweisen können, ist das in Ordnung.

Diese Zahlen wurden bei Verbraucherlaptops mit einer Poseidon -Hash -Funktion erreicht, die speziell für starke Freundlichkeit entwickelt wurde.Poseidon ist jedoch relativ unreif, so dass viele Menschen seiner Sicherheit immer noch nicht vertrauen.Daher gibt es zwei realistische Wege:

• Führen Sie schnell eine Menge Sicherheitsanalyse auf Poseidon durch und kenne es damit, es auf L1 bereitzustellen

• Verwenden Sie eine „konservativere“ Hash -Funktion wie SHA256 oder Blake

Zum Zeitpunkt des Schreibens kann Starkware’s Stark Prover nur etwa 10 bis 30.000 Hash pro Sekunde auf einem Verbraucher-Laptop nachweisen, wenn er eine konservative Hash-Funktion beweisen möchte.Die Stark -Technologie geht jedoch rasant voran.Noch heute zeigt die GKR-basierte Technologie das Potenzial, sie auf den Bereich von ungefähr 100 bis 200.000 zu erhöhen.

Zeugen -Anwendungsfälle anderer Verifizierungsblöcke

Zusätzlich zum Überprüfungsblock gibt es drei weitere wichtige Anwendungsfälle, die eine effizientere aufsichtslose Überprüfung ermöglichen:

• Speicherpool:Wenn eine Transaktion ausgestrahlt wird, müssen Knoten im P2P -Netzwerk überprüfen, ob die Transaktion vor der Wiederholung gültig ist.Heute umfasst die Überprüfung nicht nur die Validierung der Signatur, sondern auch die Überprüfung, ob das Gleichgewicht ausreicht und dass die Zufallszahl korrekt ist.In Zukunft (beispielsweise mit nativen Kontoabstraktionen wie EIP-7701) kann dies dazu führen, dass ein EVM-Code ausgeführt wird, der einen staatlichen Zugriff ausführt.Wenn der Knoten staatslos ist, erfordert die Transaktion einen Nachweis mit einem Nachweis des Statusobjekts.

• Liste einschließen:Dies ist eine vorgeschlagene Funktion, mit der (möglicherweise kleine und unkomplizierte) Proof-of-Stake-Validatoren den nächsten Block dazu zwingen können, Transaktionen unabhängig von den Wünschen (möglicherweise großer und komplexer) Blockbauer zu enthalten.Dies verringert die Fähigkeit mächtiger Teilnehmer, Blockchains durch Verzögerung von Transaktionen zu manipulieren.Dies erfordert jedoch, dass Validatoren eine Möglichkeit haben, die Gültigkeit von Transaktionen in der enthaltenen Liste zu überprüfen.

• Leichter Client:Wenn wir möchten, dass Benutzer über Brieftaschen (z. B. Metamaske, Rainbow, Rabby …) auf die Kette zugreifen, ohne zentralisierte Teilnehmer zu vertrauen, müssen sie einen leichten Kunden (z. B. Helios) betreiben.Das Core Helios -Modul bietet Benutzern ein validiertes Statusroot.Um jedoch eine vollständig vertrauenslose Erfahrung zu sammeln, müssen Benutzer jedoch einen Nachweis für jeden einzelnen RPC -Anruf vorlegen (z. B. für eine ETH_CALL -Anforderung, Benutzer benötigen den Nachweis aller während des Anrufs zugegriffenen Staaten).

Eine Sache, die all diese Anwendungsfälle häufig sind, ist, dass sie viele Beweise benötigen, aber jeder Beweis ist klein.Daher beweist Stark, dass es für sie nicht sinnvoll ist.Ein weiterer Vorteil von Merkle -Zweigen ist, dass sie aktualisiert werden: Bei einem in Block B verwurzelten Nachweis des Zustands.Auch der Kegelproof selbst ist auf dem neuesten Stand.

Was sind die Verbindungen zur vorhandenen Forschung?

VERKLE TREE:https://vitalik.eth.limo/general/2021/06/18/verkle.html

John Kuszmauls ursprüngliches Querbaumpapier:Starkware Proof -Daten:https://x.com/starkwareltd/status/1807776563188162562

Poseidon2 Papier:https://eprint.iacr.org/2023/323

AJTAI (alternative schnelle Hash -Funktion basierend auf Gitterhärte):https://www.wisdom.weizmann.ac.il/~oded/col/cfh.pdf

Wandle.info:https://verkle.info/

Was muss noch getan werden und welche Kompromisse müssen abgewogen werden?

Die verbleibenden Hauptaufgaben sind:

• Weitere Analyse der Konsequenzen von EIP-4762 (Änderungen des Staatlosengaskosten)

• Weitere Arbeitsverfahren für Arbeiten und Testen von Übergang

• Weitere Sicherheitsanalyse von Poseidon, Ajtai und anderen „starken“ Hash-Funktionen

• Entwickeln Sie extra effiziente Stark-Protokolle für „konservative“ (oder „traditionelle“ Hash-Funktionen (oder „traditionelle“ Hash-Funktionen, wie die Idee, die auf Binius oder GKR basiert.

Wir werden bald einen Entscheidungspunkt machen, um zu wählen, welche der folgenden drei Optionen: (i) VERKLE TREE, (II) Stark-freundliche Hash-Funktion und (iii) konservative Hash-Funktion.Ihre Eigenschaften können ungefähr wie folgt zusammengefasst werden:

Zusätzlich zu diesen „Titelnummern“ gibt es einige andere wichtige Überlegungen:

• Jetzt,Der Kegelbaumcode ist ziemlich ausgereift.Die Verwendung von etwas anderem als Verkle verzögert den Bereitstellungsverhältnis, höchstwahrscheinlich durch harte Gabeln.Dies kann in Ordnung sein, insbesondere wenn wir zusätzliche Zeit benötigen, um eine Hash -Funktionsanalyse oder eine Republikum -Implementierung durchzuführen, und wenn wir andere wichtige Funktionen haben, die wir so bald wie möglich in Ethereum aufnehmen möchten.

• Aktualisieren Sie das Statusroot mit Hash schneller als die Verwendung von VERKLE -Bäumen.Dies bedeutet, dass der Hash-basierte Ansatz die Synchronisationszeit des vollständigen Knotens verkürzen kann.

• VDer Erkle Tree hat interessante Eigenschaften von Zeugenaktualisierungen– Der Zeuge des VERKLE Tree aktualisiert.Diese Eigenschaft ist nützlich für Speicherpools, umfasst Listen und andere Anwendungsfälle und kann auch dazu beitragen, Effizienz zu erreichen: Wenn Sie das staatliche Objekt aktualisieren, können Sie den Zeugen auf der vorletzten Ebene aktualisieren, ohne die letzte Ebene zu lesen.

• VERKLE -Bäume sind durch Snark schwerer zu beweisen.Wenn wir die Proof -Größe bis auf einige Kilobyten reduzieren möchten, können Leerzeichen einige Schwierigkeiten bringen.Dies liegt daran, dass die Überprüfung der Leerverifikation eine große Anzahl von 256-Bit-Vorgängen einführt, was erfordert, dass das Proof-System entweder viel Overhead hat oder sich selbst eine benutzerdefinierte interne Struktur aufweist, die den 256-Bit-Teil für perkle-Proof enthält.

Ein weiterer möglicher Ansatz ist der Mesh-basierte Merkle-Baum, wenn die Aktualisierbarkeit von Quantum und ziemlich effizienter Weise von Verkle beobachtet wird.

Wenn nachgewiesen wird, dass das System im schlimmsten Fall nicht effektiv genug ist, können wir diesen Manko mit einem anderen „Kaninchen im Hut“ ausgleichen, das ist mehrdimensionales Gas: Zugriff auf (i) Calldata, (ii) Computing (((ii). iii) Staat und möglicherweise andere verschiedene Ressourcen haben separate Gasbeschränkungen.Mehrdimensionales Gas erhöht Komplexität, begrenzt jedoch im Austausch das Verhältnis zwischen dem Durchschnitt und dem Worst-Case-Szenario.Bei mehrdimensionalem Gas kann die theoretische maximale Anzahl von Zweigen zu beweisen, die nachweisen, von 30.000.000 / 2400 = 12.500 auf 3000 reduziert werden.Dies wird Blake3 (kaum) bis heute ohne weitere Nachweisverbesserungen ausreichen.

Mehrdimensionales Gas ermöglicht es Blockressourcenbeschränkungen, die zugrunde liegenden Hardware -Ressourcenbeschränkungen näher an den Ressourcenbeschränkungen zu replizieren.

Ein weiterer „Atem, der auftaucht“ ist der Vorschlag, die Berechnung der Zustandswurzel bis nach dem Block zu verzögern.Dies gibt uns volle 12 Sekunden Zeit, um die Zustandswurzel zu berechnen, was bedeutet, dass selbst in den extremsten Fällen nur etwa 60.000 Hash/Second Proof Time genug sind, was uns wieder in Blake3 im Gebrauchsbereich kaum genug bringt.

Der Nachteil dieses Ansatzes ist, dass er die leichte Kundenlatenz um einen Zeitraum erhöht, obwohl es intelligenteren Versionen der Technologie gibt, die diese Latenz auf die Latenz der Beweise der Beweise reduzieren können.Solange jeder Knoten einen Beweis generiert, kann der Beweis im Netzwerk übertragen werden, anstatt auf den nächsten Block zu warten.

Wie interagiert es mit dem Rest der Roadmap?

Das Lösen des Staatlosen Problems erhöht die Bequemlichkeit getrennter Versprechen erheblich.Dies wird wertvoller, wenn Technologien, die das Mindestbilanz einzelner Einsätze wie Umlauf-SSF oder Anwendungsschichtrichtlinien wie Kader-Einsätze reduzieren können, zur Verfügung stehen.

Mehrdimensionales Gas ist einfacher, wenn EOF gleichzeitig eingeführt wird.Dies liegt daran Gas-Sub-Call-Protokollalternativen für Hauptanwendungsfälle).

Eine weitere wichtige Synergie ist die Synergie zwischen der Verifizierung der Staatenlosen und des historischen Ablaufs.Heute müssen Kunden fast terabyte historischer Daten speichern.Auch wenn der Kunde staatsfreundlich ist, kann der Traum des Kunden von fast keinem Speicher realisiert werden, es sei denn, wir können auch die Verantwortung für die Speicherhistorie des Kunden lindern.Der erste Schritt in dieser Hinsicht ist EIP-4444, was auch bedeutet, historische Daten in einem Torrent- oder Portalnetz zu speichern.

Nachweis der Gültigkeit der EVM -Ausführung

Welche Probleme wollen wir lösen?

Das langfristige Ziel der Ethereum-Blocküberprüfung ist klar: Sie sollten in der Lage sein, einen Ethereum-Block zu überprüfen, indem Sie den Block herunterladen, möglicherweise sogar nur einen kleinen Teil des Blocks und der Abtastdatenverfügbarkeit, und (ii) verifizieren a Kleiner Teil, um zu beweisen, dass der Block gültig ist.Dies ist ein Betrieb mit minimalem Ressourcenverbrauch, der in einer anderen Kette auf dem mobilen Client, innerhalb der Browser -Brieftasche oder sogar (ohne Datenverfügbarkeitsabschnitt) durchgeführt werden kann.

Um dies zu erreichen, sind mit (i) Konsensschicht (d. H. Nachweis des Einsatzes) und (ii) Ausführungsschicht (d. H. EVM) Snark- oder starke Beweise erforderlich.Ersteres ist eine Herausforderung für sich und sollte im Prozess der weiteren Verbesserung der Konsensschicht (z. B. Finalität mit einer Slot) angegangen werden.Letzteres erfordert einen Nachweis der EVM -Ausführung.

Was ist es und wie funktioniert es?

In der Ethereum-Spezifikation ist EVM formell als Zustandsübergangsfunktion definiert: Sie haben einige Vorstate, einen Block B, und Sie berechnen einen Post-State S ‚= STF (s, B).Wenn der Benutzer einen leichten Client verwendet, haben er weder S und S ‚oder sogar voll B.Die vollständige Aussage, die nachgewiesen werden muss, ist ungefähr:

• Öffentliche Eingabe:Die vorherige Zustandswurzel r, die letztere Zustandswurzel R ‚und der Block Hash H.

• Private Eingabe:Block B, Objekte im Status, auf den Block Q zugegriffen wird, wurde nach Block Q ‚derselbe Objekt nach Ausführung des Zustands (z. B. Merkle Branch) P.

• Satz 1:P ist ein gültiger Beweis dafür, dass Q einige Teile des Staates enthält, die von R. dargestellt werden

• Satz 2:Wenn Sie STF auf q ausführen, (i) nur Zugriffsobjekte in q ausführen, (ii) der Block ist gültig, und (iii) das Ergebnis ist Q ‚.

• Aussage 3:Wenn Sie das neue Zustandswurzel mit den Informationen in Q ‚und P neu berechnen, erhalten Sie R‘.

Wenn es existiert, können Sie einen leichten Client haben, der die Ausführung von Ethereum EVM vollständig überprüfen kann.Dies macht die Ressourcen des Kunden ziemlich gering.Um einen wirklich vollständig validierten Ethereum -Kunden zu erhalten, müssen Sie auch für die Konsenspartei dasselbe tun.

Die Implementierung des Validitätsnachweises für das EVM -Computing besteht bereits und wird von L2 häufig verwendet.Es ist jedoch noch viel zu tun, um die für L1 geltende EVM -Gültigkeitsnachweis zu beweisen.

Was sind die Verbindungen zu bestehenden Forschung?

EC PSE ZK-EVM (jetzt veraltet, weil es bessere Optionen gibt):https://github.com/privacy-scaling- explorations/zkevm- circuits

Zeth, das EVM zu RISC-0 ZK-VM zusammenstellt:https://github.com/risc0/zeth

ZK-EVM Formale Überprüfungsprojekt:https://verified-zkevm.org/

Was muss noch getan werden und welche Kompromisse müssen abgewogen werden?

Jetzt,Der Gültigkeitsnachweis von EVM reicht in zwei Aspekten nicht aus: Sicherheits- und Nachweiszeit.

Der Nachweis der Sicherheitseffizienz muss sicherstellen, dass Snark die EVM -Berechnungen überprüft und dass es keine Fehler gibt.Die beiden Haupttechniken zur Verbesserung der Sicherheit sind mehrere Sprichwörter und formelle Überprüfung.Multi-Proven bedeutet, dass mehr als mehrere Kunden unabhängig schriftliche Nachweise für Gültigkeiten implementiert werden, und wenn eine ausreichend ausreichende Teilmenge dieser Implementierungen einen Block beweist, akzeptiert der Kunde diesen Block.Die formale Validierung umfasst die Verwendung von Tools, die üblicherweise verwendet werden, um mathematische Theoreme (z. B. Lean4) zu beweisen, um zu beweisen, dass Gültigkeitsnachweise nur die Eingabe akzeptieren, die durch die zugrunde liegende EVM -Spezifikation in Python korrekt ausgeführt wird.

Schnell genug Nachweis bedeutet, dass ein Ethereum -Block in weniger als 4 Sekunden nachgewiesen werden kann.Heute sind wir noch weit von diesem Ziel entfernt, obwohl wir viel näher sind als vor zwei Jahren.Um dies zu erreichen, müssen wir in drei Aspekten voranschreiten:

• Parallelisierung – Der schnellste EVM -Prover von heute kann den durchschnittlichen Ethereum -Block in etwa 15 Sekunden nachweisen.Dies geschieht, indem Hunderte von GPUs parallelisiert und schließlich ihre Arbeit zusammengestellt werden.Theoretisch wissen wir genau, wie man einen EVM -Prover erstellt, der die Berechnung in O (log (n)) nachweisen kann: Lassen Sie eine GPU jeden Schritt ausführen und dann den „Aggregationsbaum“ ausführen:

Es gibt Herausforderungen bei der Implementierung.Selbst im schlimmsten Fall (d. H. Sehr große Transaktionen belegen den gesamten Block) kann die berechnete Spaltung nicht durch Transaktion durchgeführt werden.Eine wichtige Herausforderung für die Implementierung, die dies nicht vollständig trivial macht, ist die Notwendigkeit, sicherzustellen, dass das „Speicher“ des VM über verschiedene Teile des Beweises konsistent ist.Wenn wir dies jedoch rekursive Beweise ausführen können, wissen wir, dass zumindest das Problem der Prover -Verzögerung gelöst wurde, auch wenn sich keine andere Achse verbessert.

• Proof -Systemoptimierung –Neue Proof-Systeme wie Orion, Binius und GKR können zu einer signifikanten Verringerung der Nachweiszeit für allgemeine Comput führen.

• Das EVM -Gas verbraucht andere Änderungen –Viele Dinge in EVM können optimiert werden, um sie zu wildefreundlicher zu machen, insbesondere im schlimmsten Fall.Wenn ein Angreifer einen Block bauen kann, der für den Prover zehn Minuten dauert, reicht es nicht aus, einen durchschnittlichen Ethereum -Block in 4 Sekunden zu beweisen.Die erforderlichen EVM -Änderungen können in zwei Kategorien unterteilt werden:

• Änderungen der Gaskosten –Wenn eine Operation lange dauert, um nachzuweisen, sollte sie höhere Gaskosten haben, selbst wenn die Berechnung relativ schnell ist.EIP-7667 ist ein vorgeschlagener EIP, um das schwerwiegendste Problem zu bewältigen: Es erhöht die Gaskosten erheblich als relativ billige Opcodes und vorkompeten exponierte (traditionelle) Hash-Funktionen.Um diese erhöhten Gaskosten zu kompensieren, können wir die Gaskosten für den Nachweis relativ billiger EVM -Opcodes senken und so den durchschnittlichen Durchsatz gleich halten.

• Datenstrukturersatz –Zusätzlich zum Ersetzen des Staatsbaums durch eine Alternative, die besser für Stark geeignet ist, müssen wir auch Transaktionslisten, Quittungsbäume und andere Strukturen ersetzen, die sich als teuer erweisen.Ethan Kisslings EIP bewegt die Transaktion und die Quittungsstruktur auf SSZ ([1] [2] [3]), einen Schritt in diese Richtung.

Darüber hinaus können die beiden im vorherigen Abschnitt (mehrdimensionalen Gas und verzögerten Zustandswurzeln) erwähnten „Kaninchen aus dem Hut) helfen.Es ist jedoch erwähnenswert, dass im Gegensatz zur staatenlosen Überprüfung die zu staatenlose Überprüfung über genügend Technologie verfügt, um das zu tun, was wir heute brauchen, und selbst mit diesen Technologien erfordert eine vollständige ZK-EVM-Überprüfung mehr Arbeit-es erfordert nur weniger Arbeit.

Eine Sache, die oben nicht erwähnt wurde, ist die Proof -Hardware: Erstellen Sie schneller Beweise mit GPUs, FPGAs und ASICs.Fabric Cryptography, Cysic und AccSeal sind die Förderer dieser drei Unternehmen.Dies ist für Tier 2 sehr wertvoll, aber es ist unwahrscheinlich, dass Tier 1 entscheidend ist .Ethereum -Benutzer sollten in der Hardware eines einzelnen Unternehmens keine Engpässe aufnehmen.Layer 2 ermöglicht radikalere Kompromisse.

In diesen Bereichen gibt es noch mehr Arbeit:

• Paralleler Beweis erfordert ein Proof -System, bei dem verschiedene Teile des Beweises „gemeinsamer Speicher“ sein können (z. B. Suchtabellen).Wir kennen die Techniken, um dies zu tun, aber sie müssen implementiert werden.

• Wir benötigen mehr Analyse, um die idealen Satz von Gaskostenschwankungen zu finden, um die schlechteste Beweiszeit zu minimieren.

• Wir müssen mehr über das Proof -System tun

Mögliche Kompromisse hier umfassen:

• Sicherheit und Proverzeit:Aktive Auswahlmöglichkeiten mit Hash -Funktionen, Proofsystemen mit komplexeren oder aktiveren Sicherheitsannahmen oder anderen Entwurfsauswahl können die Prover -Zeit verkürzen.

• Dezentrale und Proverzeit:Die Community muss sich auf die „normative“ Hardware für Zielprover einverstanden einigen.Ist es in Ordnung, den Beweis zu bitten, eine große Einheit zu sein?Hoffen wir, dass High-End-Verbraucher-Laptops den Ethereum-Block in 4 Sekunden beweisen können?Etwas dazwischen?

• Der Grad, in dem rückständige Kompatibilität gebrochen ist:Unzulänglichkeiten in anderen Bereichen können durch aggressivere Änderungen der Gaskosten kompensiert werden. Dies erhöht jedoch eher die Kosten bestimmter Anwendungen überproportional und zwingen Entwickler, den Code umzuschreiben und neu einzustellen, um sie wirtschaftlich rentabel zu halten.In ähnlicher Weise hat das „Kaninchen im Hut“ auch seine eigene Komplexität und Nachteile.

Wie interagiert es mit dem Rest der Roadmap?

Die Kerntechnologien, die für die Implementierung von EVM -Gültigkeitsbeweis in Schicht 1 erforderlich sind, werden mit zwei weiteren Bereichen weit verbreitet:

• Nachweis der Gültigkeit von Schicht 2 (d. H. „ZK Rollups“)

• „Stark Binary Hash Proof“ Stauroses Methode

Eine erfolgreiche Implementierung der Gültigkeit bei Tier 1 beweist, dass letztendlich einfaches separates Einstellen: selbst die schwächsten Computer, einschließlich Mobiltelefone oder Smartwatches, abhalten können.Dies erhöht den Wert der Bekämpfung anderer Einschränkungen für das einzelne Absetzen (z. B. minimal 32 ETH).

Darüber hinaus erwies sich die EVM -Validität von L1, die die Gasgrenze von L1 signifikant erhöhte.

Nachweis der Gültigkeit des Konsenses

Welche Probleme wollen wir lösen?

Wenn wir in der Lage sein wollen, Ethereum -Blöcke mit Snark vollständig zu überprüfen, ist die EVM -Ausführung nicht der einzige Teil, den wir beweisen müssen.Wir müssen auch den Konsens nachweisen: die Teile des Systems, die Einlagen, Abhebungen, Unterschriften, Aktualisierungen des Validator -Gleichgewichts und andere Elemente des Abschnitts Ethereum Proof of Stake verarbeiten.

Der Konsens ist viel einfacher als EVM, aber die Herausforderung besteht darin, dass wir keine EVM -Zusammenfassung von Layer 2 haben, weshalb die meisten Arbeiten ohnehin erledigt werden müssen.Daher muss eine Implementierung des Beweises Ethereum -Konsens „von Grund auf“ durchgeführt werden, obwohl das Proof -System selbst eine gemeinsame Arbeit ist, die darauf aufgebaut werden kann.

Was ist es und wie funktioniert es?

Eine Beacon -Kette ist wie eine EVM als eine Zustandsübergangsfunktion definiert.Die Zustandsübertragungsfunktion wird durch drei Faktoren bestimmt:

• ECADD (zur Überprüfung von BLS -Unterschriften)

• Paarung (zur Überprüfung der BLS -Signaturen)

• SHA256 Hash (zum Lesen und Aktualisieren des Status)

In jedem Block müssen wir 1-16 BLS12-381-ECADDS für jeden Validator nachweisen (wahrscheinlich mehr als eins, da die Signatur in mehreren Aggregaten enthalten sein kann).Dies kann durch Vorkomputentechniken von Untergruppen kompensiert werden, sodass wir sagen können, dass jeder Validator ein BLS12-381 ECADD ist.Heute gibt es etwa 30.000 Validatoren -Unterschriften pro Zeitraum.In Zukunft kann sich dies für Single -Slot -Endgültigkeit in beide Richtungen ändern(Siehe Anweisungen hier): Wenn wir die „starke“ Route nehmen, kann jeder Slot auf 1 Million Validatoren steigen.In der Zwischenzeit bleibt es mit Orbit SSF bei 32.768 oder sogar auf 8,1.

Wie die BLS -Aggregation funktioniert.Die Überprüfung der Gesamtsignatur erfordert nur ECADD für jeden Teilnehmer, nicht für ECMUL.Bei 30.000 Ecadds gibt es jedoch noch viel zu beweisen.

Für die Paarung gibt es derzeit bis zu 128 Proofs pro Schlitz, was bedeutet, dass 128 Paare überprüft werden müssen.Mit EIP-7549 und weiteren Änderungen kann dies auf 16 pro Steckplatz reduziert werden.Die Anzahl der Paare ist gering, aber die Kosten sind extrem hoch: Jedes Paar läuft (oder beweist) tausend Male länger als Ecadd.

Eine große Herausforderung in der Operation von BLS12-381 ist der Mangel an bequemen Kurven, deren Kurvenreihenfolge der Feldgröße von BLS12-381 entspricht und zu jedem Beweissystem erheblichen Overhead verleiht.Andererseits wird der für Ethereum vorgeschlagene Leerkle-Baum mit Bandersnatch-Kurven gebaut, wodurch BLS12-381 selbst zu einer natürlichen Kurve im Snark-System verwendet wird, um Kenezweige zu beweisen.Eine ziemlich einfache Implementierung kann etwa 100 G1 -Ergänzungen pro Sekunde liefern.

Für SHA256 Hash ist das Worst -Case -Szenario der Epoch Conversion Block, bei dem der gesamte Validator Short Balance Tree und eine große Anzahl von Validator -Guthaben aktualisiert werden.Validator Short Balance Tree Es gibt nur ein Byte pro Validator, daher werden etwa 1 MB Daten erneut aufgeweckt.Dies entspricht 32.768 SHA256 -Anrufen.Wenn der Restbetrag von eintausend Validatoren über oder unter dem Schwellenwert liegt, muss der gültige Gleichgewicht im Validator -Datensatz aktualisiert werden, was den tausend Merkle -Zweigen entspricht, sodass es zehntausend Hashes gibt.Der Mischungsmechanismus erfordert 90 Bit pro Validator (und daher 11 MB Daten), dies kann jedoch jederzeit in einem Epochenprozess berechnet werden.Für die Endgültigkeit der einzelnen Steckplätze können diese Zahlen entsprechend den Details wieder erhöhen oder verringern.Ein Shuffle wird unnötig, obwohl die Strecke möglicherweise die Notwendigkeit eines Shuffle wiederherstellt.

Eine weitere Herausforderung besteht darin, dass Sie alle Validatorstaaten (einschließlich öffentlicher Schlüssel) lesen müssen, um den Block zu überprüfen.Für 1 Million Validatoren sowie die Merkle -Filiale müssen allein 48 Millionen Bytes den öffentlichen Schlüssel lesen.Dies erfordert Millionen von Hashes pro Epoche.Wenn wir heute einen Nachweis für die Pfahlüberprüfung nachweisen müssen, ist ein realistischer Ansatz eine Form von inkrementellem überprüfbarem Computer: Eine separate Datenstruktur wird in dem Proof -System gespeichert, das für effiziente Suchuntersuchungen optimiert ist und die Aktualisierungen dieser Struktur bereitstellt.

Alles in allem gibt es viele Herausforderungen.

Die effizienteste Lösung für diese Herausforderungen ist wahrscheinlich, dass die Beacon-Kette eine tiefe Neugestaltung der Beacon-Kette erfordern, die gleichzeitig mit dem Umschalten auf Single-Slot-Endgültigkeit auftreten kann.Die Funktionen dieser Neugestaltung können umfassen:

• Hash -Funktion ändert sich:Heute wird die „vollständige“ SHA256 -Hash -Funktion verwendet. Aufgrund der Polsterung entspricht jeder Aufruf zwei zugrunde liegenden komprimierten Funktionsaufrufen.Zumindest können wir 2x -Verstärkung erzielen, indem wir zur SHA256 -Komprimierungsfunktion wechseln.Wenn wir stattdessen Poseidon verwenden, können wir einen Gewinn von etwa 100x erzielen, was alle unsere Probleme (zumindest für Hashes) vollständig löst: 1,7 Millionen Hashes pro Sekunde (54 MB) und sogar „eine Million“ Verifierrekorde „können es beweisen“ können es beweisen in Sekunden.

• Wenn es sich um Orbit handelt, wird der gestörte Verifier -Datensatz direkt gespeichert:Wenn Sie eine bestimmte Anzahl von Validatoren (z. B. 8.192 oder 32.768) als Ausschuss für einen bestimmten Slot auswählen, setzen Sie sie direkt in den Staat nebeneinander, damit der Mindesthash alle validatorischen öffentlichen Schlüssel in den Beweis einleiten muss.Auf diese Weise können alle Gleichgewichtsaktualisierungen effizient abgeschlossen werden.

• Signaturaggregation:Jedes Hochleistungs-Signatur-Aggregationsschema beinhaltet tatsächlich eine Art rekursiver Beweis, bei dem der Zwischennachweis der Untergruppe der Signaturen von einzelnen Knoten im Netzwerk durchgeführt wird.Dies verteilt natürlich die Proof -Last über viele Knoten im Netzwerk, wodurch der „endgültige Prover“ viel weniger funktioniert.

• Andere Signaturschemata:Für Lamport+Merkle -Signaturen benötigen wir 256+32 Hashes, um die Signatur zu überprüfen.Die Optimierung des Signaturschemas kann durch einen kleinen konstanten Faktor weiter verbessert werden.Wenn wir Poseidon verwenden, liegt dies im Rahmen des Beweises innerhalb eines einzelnen Schlitzes.Aber in Wirklichkeit wird dies mit einem rekursiven Aggregationsschema schneller.

Was sind die Verbindungen zu bestehenden Forschung?

Prägnant, Ethereum Konsensnachweis (nur Synchronausschuss):https://github.com/succinctlabs/eth-proof-of-consensus

Einfach, Helios in SP1:https://github.com/succinctlabs/sp1-helios

Präzise BLS12-381 vorkompiliert:https://blog.succinct.xyz/succinctshipSprecompiles/

HALO2-basierte BLS-Aggregationssignaturüberprüfung:https://ethresear.ch/t/zkpos-with-halo2-pairing-for-verificing-aggregate-bls–signatures/14671

Was muss noch getan werden und welche Kompromisse müssen abgewogen werden?

Tatsächlich wird es Jahre dauern, bis die Gültigkeit des Ethereum -Konsens eingeht.Dies ist ungefähr die gleiche Zeitleiste, wie wir eine Single-Slot-Finalität, Tracks, Änderungen an Signaturalgorithmen und potenzielle Sicherheitsanalysen implementieren müssen, um genügend Vertrauen zu haben, um eine „radikale“ Hash-Funktion wie Poseidon zu verwenden.Daher ist es am sinnvollsten, diese anderen Probleme zu lösen und bei diesen Aufgaben stark freundlich zu sein.

Der Hauptverfahren dürfte in der Reihenfolge der Operationen liegen, zwischen einem fortschrittlicheren Ansatz zur Reform der Ethereum-Konsensschicht und einem radikaleren Ansatz, um „viele Änderungen gleichzeitig vorzunehmen“.Für EVM ist der inkrementelle Ansatz sinnvoll, da er die Beschädigung der Rückwärtskompatibilität minimiert.Für die Konsensschicht sind Probleme mit Rückwärtskompatibilität weniger problematisch und „voll“, um die verschiedenen Details darüber zu überdenken, wie Beacon -Ketten gebaut werden, um die Freundlichkeit der Snark am besten zu optimieren.

Wie interagiert es mit dem Rest der Roadmap?

Starkfreundlich muss der Schwerpunkt der langfristigen Neugestaltung von Ethereum Proof-of-Stake-Konsens, insbesondere der Endgügung von Einzelschläfen, einem Umlaufbahn, Änderungen des Signaturschemas und der Signaturaggregation stehen.