Vielen Dank an Kevaundray Wedderburn, Alex Stokes, Tim Beiko, Mary Maller, Alexander Hicks, George Kadianakis, Dankrad Feist und Justin Drake für Feedback und Bewertung.
Ethereum geht auf ZK. Schließlich erwarten wir, auf allen Stapelebenen ZK -Proofs zu verwenden, von der Signaturaggregation der Konsensschicht bis hin zur Privatsphäre der Kunden mit dem Protest von Client Side, und Aktualisieren Sie das Protokoll, um einfacher und zk-freundlicher zu sein. Aber der erste Schritt wird ein L1 Zkevm sein.
Wie wir in weniger als einem Jahr einen L1 Zkevm versenden können
Der schnellste und sicherste Weg, um einen L1 ZKEVM zu versenden, besteht darin, den Validatoren die Möglichkeit zu geben, Clients auszuführen, die die Nutzlast von Ausführungen nicht erneut ausführen, und die von verschiedenen ZKVMS erzeugten staatsfreundlichen (wir sagen drei) Proofs, die jeweils unterschiedliche EVM-Implementierungen beweisen. Da die Beweisüberprüfung so schnell und so genau ist, ist das Herunterladen und Überprüfen mehrerer Beweise sehr vernünftig und ermöglicht es uns, die gleiche Verteidigung in der Tiefe wie vorhandene Kundenvielfalt auf ZKVMS anzuwenden.
Damit dieser Plan zunächst Ausführungsnachweise überprüft, müssen wir nur aus dem Protokoll in Glamsterdam eine Pipelination in Glamsterdam benötigen, um mehr Nachweiszeit zu ermöglichen.
Zunächst erwarten wir, dass nur wenige Validatoren ZK -Kunden betreiben. Im Laufe der Zeit wird ihre Sicherheit in der Produktion demonstriert. Mit dem EF auch Ressourcen in formale Überprüfung, Spezifikationsschreiben, Audits und Bug -Bounties; Wir gehen davon aus, dass die Adoption langsam zunehmen wird.
Wenn eine Supermajorität des Anteils bequem mit ZK-Clients bequem ist, können wir das Gaslimit auf ein Niveau erhöhen, bei dem Validatoren angemessene Hardware ausführen müssen, um die Beweise zu überprüfen, anstatt Blöcke erneut auszuführen. Sobald alle Validatoren Ausführungsnachweise überprüfen, können dieselben Beweise auch von einem verwendet werden Vorkompilen ausführen Für native ZK-Rollups.
Definieren von Echtzeitbeweisen für den L1
Unser größter Vorteil bei der Ausführung dieses Plans ist die Fähigkeit, die gesamte ZKVM -Branche zu nutzen, um Ethereum bei weitem die größte ZK -Anwendung der Welt zu machen. Viele ZKVMs beweisen bereits, dass Ethereum -Blöcke wöchentlich bekannt gegeben werden.
Um die Sicherheits-, Lebend- und Zensurresistenzeigenschaften der L1 aufrechtzuerhalten, schlägt die Ethereum Foundation eine standardisierte Definition von Echtzeit vor, auf die ZKVM-Teams hinarbeiten können.
Auf der Seite des Proof-Systems sollte ZKVMS auf Echtzeit-Beweise auf 128 Sicherheitsbits abzielen, die wir für das richtige langfristige Ziel für Ethereum L1 betrachten. Wir sind jedoch bereit, in den ersten Monaten des Einsatzes mindestens 100 Sicherheitsbits zu akzeptieren, um kurzfristige technische Herausforderungen bei der Erreichung von 128 Bits zuzuordnen. Die Beweisgröße sollte unter 300 kib bleiben und dürfen sich nicht auf rekursive Wrapper verlassen, die vertrauenswürdige Setups verwenden. Wir erwarten, dass Proof-Systeme bis zum Zeitpunkt der Produktion von ZK-Kunden auf 128-Bit-Sicherheit wechseln und die Sicherheitsanforderungen (z. B. in Bezug auf Vermutungen) weiter verschärfen.
Mit der aktuellen Slot -Zeit von 12 Sekunden und der maximalen Zeit, um Daten über das Netzwerk von ~ 1,5 Sekunden zu verbreiten, bedeutet Echtzeit 10 Sekunden oder weniger. Wir gehen davon aus, dass ZKVMs in diesem Fenster mindestens 99% der Hauptnetzblockaden beweisen können, wobei das Heck -Ende (sowie die synthetischen Dosvektoren) in zukünftigen Hardgabeln gemindert werden.
Um das höchste Maß an Lebendigkeit und Zensurresistenz aufrechtzuerhalten, zielt unsere Definition von Echtzeit nach, um „Zuhause nachzuweisen“, mit der Idee, dass einige der Solo-Staker, die derzeit Validatoren von zu Hause aus betreiben, sich für den Nachweis entscheiden werden. Obwohl wir erwarten, den Widerstand des Zensurheiges durch zu verhärten erzwungene Transaktioneinbeziehung Vor der Überprüfung von ZK -Proofs ist ein wichtiger Abschluss für das Haus zu Hause.
Da das Beweisen in der Cloud mit Multi-GPU-Spot-Instanzen bereits ziemlich billig ist, wird der Schwerpunkt für ZKVM-Teams, die auf Echtzeit-Beweise abzielen, weitgehend optimiert, wenn die Provers vor dem Voraus rechnen, wenn die Spezifikationen viel eingeschränkter sind. In der Echtzeit-Beweise vor dem PREM sollte ein maximaler Investitionsausgaben von 100.000 USD erforderlich sein (zum Zeitpunkt des Schreibens müssen ~ 80.000 US-Dollar für den Durchführen eines Validators erforderlich sind). Wir gehen davon aus, dass dies im Laufe der Zeit sinkt, auch wenn die Gasgrenze erhöht wird.
Mehr als die Hardwarekosten, die wichtigste Einschränkung für den Haushaltsbeweis für GPUs ist der Energieverbrauch. Die meisten Wohnhäuser haben mindestens 10 kW von der Straße von der Straße ein und einige werden Schaltkreise für Elektrogeräte oder Ladung von Elektrofahrzeugen mit einer Kapazität von 10 kW vorgesehen. Daher muss die Echtzeit -Beweise für Hardware möglich sein, die um 10 kW oder weniger ausgeführt werden.
Dies bringt uns zu unserer funktionierenden Definition von Echtzeitbeweisen:
- Latenz: <= 10s für P99 von Mainnet -Blöcken
- On-Prem Capex: <= 100K USD
- On-Prem-Kraft: <= 10 kW
- Code: vollständig Open Source
- Sicherheit:> = 128 Bit
- Beweisgröße: <= 300 kib ohne vertrauenswürdige Setups
Das Rennen um Echtzeit
Bis zu DevConnect Argentinien hoffen wir, dass ZKVM -Teams weiterhin innovativ für Echtzeit -Hausbeweise und die führenden ZKVMS werden, um zukünftige Kerninfrastrukturen für Ethereum zu werden.
