Da Zcash die ZKSnarks-Implementierung anscheinend abgeschlossen hat (oder zumindest fast).
Und Versionen von JPMorgans Quorum waren mit ZKsnarks-Implementierungen erschienen, siehe: https://www.coindesk.com/jpmorgan-integrates-zcash-privacy-tech-enterprise-blockchain/
Wir alle wissen, dass die Überprüfungszeit der Snarks unabhängig von der Schaltung ist (nicht von der Anzahl der Gatter, das stimmt), aber die Überprüfungen der Knoten werden so viel schneller sein als jetzt, weil die Berechnungen nicht wären nicht mehr hingerichtet.
Die Möglichkeiten von zkSNARKs sind beeindruckend, Sie können die Korrektheit von Berechnungen überprüfen, ohne sie ausführen zu müssen, und Sie erfahren nicht einmal, was ausgeführt wurde – nur, dass es korrekt ausgeführt wurde.
Wie es im Ethereum-Blog heißt (vielleicht mit einem niedrigeren "mathematischen/theoretischen Niveau")
Ich kenne die LibSnark.cpp- Implementierung und andere, aber ich spreche nicht davon, all dies auf einen SmartContract zu übertragen, ich spreche von den gesamten Blockchain-Mechanismen, die die Snarks-Strukturen übernehmen, um mit vollständig verschlüsselten Blöcken und Transaktionen zu arbeiten , und ein Überprüfungsprozess der Knoten, der auch mit ZkSnarks-Verifizierung implementiert ist.
Wird es möglich sein, diese SNARKS auf Protokollebene zu implementieren, um die gesamte Ethereum-Blockchain zu verifizieren? Wenn nicht, warum?
Vielen Dank.
Haftungsausschluss : Ich bin weder Kryptograf noch Mathematiker noch ein Low-Level-Software-Ingenieur. Bitte korrigieren Sie mich, wenn die unten angegebenen Informationen falsch sind.
Sehr kurze Antwort: Ja
Kurze Antwort: Möglich, aber heute sehr schwierig.
Längere Antwort: Die größte Herausforderung bei Ethereum besteht darin, dass Sie, da Sie eine programmierbare Blockchain haben, effektiv eine virtuelle Maschine (z. B. EVM) als arithmetische Schaltung implementieren müssen, was heute möglich, aber überhaupt nicht trivial ist. Es ist viel einfacher, eine Schaltung zu haben, die auf eine bestimmte Funktion (z. B. das Übertragen von Vermögenswerten) spezialisiert ist, weshalb das Coda-Protokoll mit einer nicht programmierbaren Blockchain beginnt.
In Anbetracht dessen lautet die Frage nun: Was brauchen wir, um rekursive S(T|N)ARKs zu verwenden, um die Gültigkeit der gesamten Ethereum-Kette zu beweisen?
Sie müssen eine Schaltung bauen, die eine Random Access Machine (RAM) implementiert, dh eine CPU, die Zugriff auf Speicherregister hat. Glücklicherweise wurde ein solches Design in einem Artikel mit dem Titel Succinct Non-Interactive Zero Knowledge for a von Neumann Architecture vorgeschlagen . Mike Hearn hat 2016 einen fantastischen mittleren Beitrag veröffentlicht , in dem er auf einer höheren Ebene beschreibt, was diese kleine zk-snark von Neumann-Maschine ist. Insgesamt ist dies immer noch eine sehr komplizierte Schaltung, bei der es sehr teuer ist, Code auszuführen. Aber dank der Tatsache, dass SNARK-Beweise parallelisierbar sind (siehe z. B. DIZK), gibt es viel Raum für die Optimierung der parallelen Beweisgenerierung, sowohl zwischen Maschinen als auch innerhalb von Hardwarekomponenten wie GPUs oder SNARK-ASICs (von denen bis jetzt keine bekannt sind noch).
Sobald wir eine Schaltung haben, die beliebige Berechnungen ausführen kann, benötigen wir Sprachen, die sich zu diesem virtuellen Maschinencode kompilieren lassen. An diesem Punkt denke ich, dass wir die gesamte Ethereum-Blockchain-Geschichte kurz und bündig überprüfen können, indem wir „in-browser full nodes“ zulassen.
Da dies lange Zeit in Anspruch nehmen wird und viel Nacharbeit am Basisprotokoll erfordern wird, wäre es interessant, ein solches Verifizierungssystem als L2-Dienst zu erstellen. Grundsätzlich könnten Sie Leute bezahlen, um zu beweisen, dass eine bestimmte Kette seit der Entstehung gültig ist, was für Light-Clients unglaublich wertvoll wäre. Dies erfordert keine Hardfork und könnte sich als wertvolles Experiment für einen vollständigen Übergang zu einer SNARK-basierten Kette erweisen.
Das Problem ist hier nicht die Machbarkeit, das ist ziemlich bewiesen, sondern der enorme Rechenaufwand (in Bezug auf EVM-Anweisungen, nicht absolut).
Vitalik Buterin drängt die Community zur Übernahme der Technik. Vielleicht könnte dies helfen, wenn einige primitive Funktionen zum sogenannten „vorkompilierten Vertragssatz“ von Ethereum hinzugefügt werden, wo Sie elliptische Kalküle, grundlegende Hash-Funktionen und so weiter finden können.
Im Moment ist es nicht so einfach, in den von EVM und Ethereum angegebenen Rechengrenzen zu bleiben (ich spreche von Gaslimit und so weiter).
Wird es möglich sein, diese SNARKS auf Protokollebene zu implementieren, um die gesamte Ethereum-Blockchain zu verifizieren? Wenn nicht, warum?
Die Antwort auf diese Frage kann nur spekulativer Natur sein, aber los geht's, ich versuche es mal.
Eventuell ist es nicht notwendig, dies im Hauptnetz zu implementieren. Ignis Plasma kommt Ihren Vorstellungen sehr nahe. Schauen Sie sich " https://medium.com/plasma-ignis/presenting-ignis-plasma-of-fire-502fab5a6f17 " an. In Ignis verwenden sie ZK-SNARKs, um auf der Hauptkette zu beweisen, dass die Plasmakette den Code wie von den Teilnehmern vereinbart ausführt.
Im Allgemeinen ist die Anwendung von ZK-SNARKs dank Bibliotheken wie ZoKRates (und kürzlich hinzugefügter Unterstützung für sha256) auf Ethereum in Reichweite. Es gibt bereits PoCs zur Neuimplementierung von Zcash darauf. Siehe ZKDAI. Zwei Hauptprobleme bleiben jedoch bestehen: die ressourcenintensive Berechnung des Beweises (done offchain) und das vertrauenswürdige Setup und Giftmüll. Die Überprüfung der Kette ist O(1), die Gaskosten liegen jedoch über 1 Mio. Gas, was immer noch sehr teuer ist, aber als machbar angesehen werden könnte. Und wir können damit rechnen, dass die Grenzen in Zukunft verschoben werden.
CPerez19