jakiro
Autor: Justin Thaler Quelle: A16Z Übersetzung: Shan Oppa, Bitchain Vision
Virtuelle Maschinen mit Zero-Knowledge (ZKVMS)Ziel ist es, Snarks zu populär, damit auch Menschen ohne Snark -Expertise nachweisen können, dass sie ein Programm für einen bestimmten Input (oder Zeugen) korrekt durchführen.Der Kernvorteil liegt in der Entwicklererfahrung, aber derzeit sind ZKVMsSicherheitUndLeistungEs gibt immer noch große Herausforderungen.Wenn ZKVMs ihre Versprechen einhalten wollen, müssen Designer diese Hindernisse überwinden.In diesem Artikel werden die möglichen Phasen der ZKVM -Entwicklung untersucht, und der gesamte Prozess kann erforderlich seinJahreNur dann kann es getan werden – glauben Sie nicht, dass jemand sagt, dass dies schnell erreicht werden kann.
Herausforderungen
existierenSicherheitEinerseits sind ZKVMs hochkomplexe Softwareprojekte, die immer noch voller Schwachstellen sind.
existierenLeistungEs kann langsamer sein zu beweisen, dass ein Programm korrekt ausgeführt wird als nativ.Hunderttausende Maledie meisten Anwendungen, die in der realen Welt eingesetzt werdenVorerst nicht machbar.
Trotzdem fördern viele Stimmen in der Blockchain -Industrie immer noch ZKVMsKann sofort eingesetzt werdenund sogar einige Projekte zahlen bereits hohe Rechenkosten, um Null-Wissen-Beweise für On-Chain-Aktivitäten zu generieren.Da es jedoch noch viele Schwachstellen in ZKVMs gibt, ist dieser Ansatz tatsächlich gerechtEine teure Verkleidungdas System so aussehen, als wäre es durch Snark geschützt, wenn es tatsächlich entweder abhängtBerechtigungskontrolle, oder schlimmer-Exposition gegenüber Angriffsrisiko.
Die Realität ist, dass wir noch Jahre davon entfernt sind, ein wirklich sicheres und effizientes ZKVM aufzubauen.Dieser Artikel schlägt eine Reihe von vorSpezifisch und schrittweiseDas Ziel, uns zu helfen, den echten Fortschritt in ZKVM zu verfolgen, den Hype zu schwächen und die Community dazu zu führen, sich auf reale technologische Durchbrüche zu konzentrieren.
Sicherheitsentwicklungsphase
Hintergrund
bezogen aufSnarkvonZKVMSEs enthält normalerweise zwei Kernkomponenten:
1.Polynominteraktiver Orakelproof (PIOP): Ein interaktives Beweisrahmen zur Beweisung von Polynomen (oder Einschränkungen, die aus Polynomen abgeleitet).
2.Polynomiktival (PCS): Stellen Sie sicher, dass der Prover die polynomialen Bewertungsergebnisse nicht schmieden kann, ohne nachgewiesen zu werden.
ZKVM PassCodieren gültige Ausführungs -Trajektorien in EinschränkungssystemeStellen Sie die virtuelle Maschine sicher,registrierenUndErinnerungUnd dann verwenden Sie Snark, um die Zufriedenheit dieser Einschränkungen zu beweisen.
In einem so komplexen System ist der einzige Weg, um sicherzustellen, dass ZKVM anfällig istFormelle Überprüfung.Im Folgenden sind die verschiedenen Phasen der ZKVM -Sicherheit aufgeführt, woDie erste Phase konzentriert sich auf die Richtigkeit der VereinbarungAnwesendDie zweite und dritte Phase konzentrieren sich auf die Erreichung der Korrektheit.
Sicherheitsphase 1: Das richtige Protokoll
-
Formelle Überprüfung der PIOP -Zuverlässigkeit;
-
PCS ist ein verbindlicher Beweis für die formale Überprüfung unter bestimmten Verschlüsselungsannahmen oder idealen Modellen.
-
Wenn Fiat-Shamir verwendet wird, ist das prägnante Argument, das durch Kombinieren von PIOP und PCs erhalten wird, ein formaler Sicherheitsnachweis im zufälligen Orakelmodell (nach Bedarf mit anderen Verschlüsselungsannahmen).
-
Das von PIOP angewendete Einschränkungssystem entspricht dem formalen Überprüfungsnachweis für die Semantik von VMs.
-
Alle diese Abschnitte werden vollständig in einen einzigen, formell nachgewiesenen sicheren Snark -Beweis für das Ausführen eines vom VM -Bytecode angegebenen Programms „aufgenommen“.Wenn das Protokoll beabsichtigt, Null -Wissen zu implementieren, muss dieses Attribut auch formell überprüft werden, um sicherzustellen, dass vertrauliche Informationen über den Zeugen nicht offengelegt werden.
Wenn ZKVM verwendet wirdRekursiondann diePIOP, Verpflichtungsprogramme und EinschränkungssystemeAlle müssen verifiziert werdenAndernfalls kann diese Unterbühne nicht als vollständig angesehen werden.
Sicherheitsphase 2: Richtige Überprüfungsimplementierung
Diese Phase erfordert ZKVMÜberprüfungDie tatsächliche Implementierung (wie Rost, Solidität usw.) wird durchgeführtFormelle ÜberprüfungStellen Sie sicher, dass es den in der ersten Phase verifizierten Protokollen entspricht.Vervollständige diese Phase bedeutet ZKVMserreichenUndTheoretisches DesignEs ist konsequent, nicht nur einsSicherheitsvereinbarung auf Papier, oder eine ineffiziente Spezifikation in einer Sprache wie Lean.
WarumKonzentrieren Sie sich nur auf den Validator, nicht auf den BeweisEs gibt zwei Hauptgründe: Erstens,Stellen Sie sicher, dass der Validator korrekt ist. Sie können die Vollständigkeit des ZKVM -Proof -Systems sicherstellen(d. h.: Stellen Sie sicher, dass der Validator nicht gefälscht ist, um einen falschen Beweis zu akzeptieren).Zweite,Die Überprüfungsimplementierung von ZKVM ist mehr als eine Größenordnung einfacher als die Implementierung des ProversDie Richtigkeit des Verifizierers ist kurzfristig leichter zu garantiert.
Sicherheitsphase 3: Die korrekte Implementierung des Provers
Diese Phase erfordert ZKVMNachweisenDie tatsächliche Umsetzung vonFormelle ÜberprüfungStellen Sie sicher, dass es kannRichtig erzeugtBeweis des Beweissystems, der im ersten und zweiten Stadium überprüft wurde.Das Ziel dieser Phase istVollständigkeit, d. H. Jedes System, das ZKVM verwendet, kann keine rechtliche Erklärung nachweisen.Bleib fest.Wenn ZKVM Null-Wissen-Attribute haben muss, muss eine formelle Überprüfung vorgesehen werden, um sicherzustellen, dass der Nachweis keine Informationen über den Zeugen offenlegt.
Geschätzter Zeitplan
Phase 1 Fortschritt: Wir können uns im nächsten Jahr auf einige Fortschritte freuen (zum Beispiel,ZklibDas ist eine Anstrengung).Aber kein ZKVM kann die Anforderungen von Phase 1 innerhalb mindestens zwei Jahre vollständig erfüllen.
Stufen 2 und 3: Diese Phasen können gleichzeitig mit bestimmten Aspekten von Phase 1 vorgebracht werden.Beispielsweise haben einige Teams gezeigt, dass die Implementierung des Plonk -Validators dem Protokoll in der Arbeit übereinstimmt (obwohl das Protokoll selbst möglicherweise nicht vollständig überprüft wird).Trotzdem erwarte ich nicht, dass ZKVM in weniger als vier Jahren Phase 3 erreicht – vielleicht sogar länger.
Schlüsselnotizen: Fiat-Shamir Security vs. Verifizierter Byte-Code
Ein wichtiges Komplexitätsproblem ist dasEs gibt immer noch ungelöste Forschungsfragen zur Sicherheit der Fiat-Shamir-Transformation.Alle drei Sicherheitsphasen behandeln Fiat-Shamir und zufällige Orakel als absolut sicher, aber in Wirklichkeit kann es im gesamten Paradigma Schwachstellen geben.Dies liegt anEs gibt einen Unterschied zwischen dem idealisierten Modell eines zufälligen Orakels und der tatsächlich verwendeten Hash -Funktion.
Im schlimmsten Fall hat man erreichtSicherheitsphase 2Das System kannAufgrund von Fiat-Shamir-Problemen völlig unsicher gefunden.Dies verdient unsere hohe Aufmerksamkeit und kontinuierliche Forschung.Wir brauchen vielleichtÄndern Sie die Fiat-Shamir-Transformation selbst, um sich besser gegen solche Schwachstellen zu verteidigen.
Systeme, die keine Rekursion verwenden, sind theoretisch sicherer, weil einige bekannte Angriffe Schaltungen beinhalten, die denen ähneln, die in rekursiven Beweisen verwendet werden.Aber dieses Risiko ist immer noch einUngelöste grundlegende Probleme.
Ein weiteres zu beachtenKorrekt durchführen, aber wennDer Bytecode selbst hat Mängeldann der Wert dieses BeweisesExtrem begrenzt.Daher hängt die Praktikabilität von ZKVM in hohem Maße von abSo generieren Sie offiziell verifizierte Bytecodeund diese HerausforderungExtrem groß,UndJenseits des Rahmens dieses Artikels.
Über Quantensicherheit
Quantencomputer stellen mindestens 5 Jahre (oder mehr) keine ernsthafte Bedrohung dar, während Software -Schwachstellen eine Frage von Leben oder Tod darstellen.Daher sollte die derzeitige Priorität darin bestehen, die in diesem Artikel vorgeschlagenen Sicherheits- und Leistungsziele zu erreichen.Wenn nicht quantische Säure diese Ziele schneller erreichen können, sollten wir sie priorisieren.Überlegen Sie, ob quantenresistente Schnuppen aufholen oder wenn Anzeichen dafür vorkommen, dass Quantencomputer mit tatsächlichen Bedrohungen auftauchen.
Spezifische Sicherheitsstufe
100-Bit klassische SicherheitIst jeder Snark zum Schutz wertvoller VermögenswerteMindeststandard(Aber es gibt noch einige SystemeDiesen niedrigen Standard nicht erfüllen).Trotzdem ist das nochSollte nicht akzeptiert werdenDie Standard -Kryptographie -Praxis erfordert normalerweise128-Bit-Sicherheit und höher.Wenn die Leistung von Snark wirklich dem Standard entspricht, sollten wir die Sicherheit nicht reduzieren, um die Leistung zu verbessern.
Leistungsphase
Aktuelle Situation
Derzeit ZKVMNachweisenDer Berechnungsaufwand ist ungefähr1 Million -mal native Ausführung.Mit anderen Worten, wenn die native Ausführung eines Programms erfordertX CPU -Zyklen,AlsoErstellen Sie den Nachweis der korrekten AusführungUngefähr benötigtX × 1.000.000 CPU -Zyklen.Diese Situation istDas war also vor einem Jahr, und noch heute ist dies heute(Obwohl es einige Missverständnisse gibt).
Einige beliebte Aussagen in der Branche können heute irreführend sein, wie z. B.:
1.„Die Kosten für die Erstellung von Beweisen für das gesamte Ethereum -Mainnet betragen weniger als 1 Million US -Dollar pro Jahr.“
2.„Wir haben fast die Erzeugung von Ethereum-Blöcken in Echtzeit implementiert und nur Dutzende von GPUs erfordern.“
3.„Unser letztes ZKVM ist 1000 -mal schneller als frühere Generationen.“
Diese Behauptungen können jedoch ohne Kontext irreführend sein:
•1000 -mal schneller als ältere ZKVM und kann immer noch sehr langsam seindas ist aussagekräftigerWie schlecht war die Vergangenheit, nicht wie gut ist jetzt gut.
•Das Rechenvolumen des Ethereum -Hauptnetzes kann in Zukunft um das 10 -fache zunehmen, was die aktuelle Leistung von ZKVM weitaus weniger wahrscheinlich mit der Nachfrage Schritt halten wird.
• Die sogenannte „fast Echtzeit“ -Kerstellung steht immer noch unter den Bedürfnissen vieler Blockchain-AnwendungenZu langsam(Zum BeispielOptimismus hat eine Blockzeit von 2 Sekunden, viel schneller als die 12 Sekunden von Ethereum).
•„Läuft von GPUs für lange Zeit rund um die Uhr“Nicht verfügbarGenug Aktivität garantiert.
• DieseDie Erzeugungszeit von Proof dient normalerweise für Beweisgrößen über 1 MBund das ist für viele AnwendungenZu groß.
•„Kosten weniger als 1 Million US -Dollar pro Jahr“Nur weilEthereum Full Node führt nur Berechnungen von etwa 25 USD pro Jahr durch.
Für Anwendungsszenarien außerhalb von Blockchain ist dieser Computeraufwand offensichtlich zu hoch.Unabhängig davon, wie viele parallele Computer- oder Engineering -Optimierungen sind, kann es nicht so riesiges Computeraufwand ausgleichen.
Das grundlegende Ziel, das wir festlegen sollten, ist: Leistungsaufwand ist nicht mehr als das 100.000 -fache der nativen Ausführung.Trotzdem ist dies immer noch der erste Schritt.Wenn wir wirklich große Mainstream-Anwendungen implementieren möchten, müssen wir möglicherweise den Overhead auf 10.000 Mal oder weniger native Ausführung reduzieren.
Leistungsmessung
Die Snark -Leistung hat drei Hauptkomponenten:
1.Die inhärente Effizienz des zugrunde liegenden bewährten Systems.
2.Optimierung für bestimmte Anwendungen(z. B. vorkompiliert).
3.Engineering- und Hardwarebeschleunigung(z. B. GPU, FPGA oder Multi-Core-CPU).
Während (2) und (3) für die tatsächliche Bereitstellung von entscheidender Bedeutung sind, sind sie also für jedes Proof -System geeignet.Verbesserungen, die möglicherweise nicht unbedingt den grundlegenden Overhead widerspiegeln.Beispielsweise kann das Hinzufügen von GPU -Beschleunigung und Vorkompilierung zu ZKEVM die Geschwindigkeit leicht um das 50 -mal schnellere verbessern, als sich ausschließlich auf CPUs zu verlassen. Dies kann ein von Natur aus weniger effizientes System besser aussehen als ein anderer, der nicht gleich optimiert wurde.
Daher konzentriert sich dieser Artikel auf die MessungGrundlegende Leistung von Snark ohne dedizierte Hardware und Vorkompilierung.Dies unterscheidet sich von dem aktuellen Benchmarking -Ansatz, der typischerweise alle drei Faktoren zu einem „populären Wert“ kombiniert.Es ist wieRichter Diamanten durch Polierzeit, anstatt ihre inhärente Klarheit zu bewerten.
Unser Ziel istDer inhärente Overhead der Isolierung universeller Proof -Systeme, senkenBeweisen Sie den wirklichen Fortschritt im Systemdesign.
Leistungsphase
Hier sind die Meilensteine für die fünf Leistungsphasen, die ich vorgeschlagen habe.Erstens müssen wir den Prover -Overhead in der CPU erheblich reduzieren, bevor wir uns weiter auf Hardware verlassen können, um den Gemeinkosten zu reduzieren.Gleichzeitig muss auch die Speicherverwendung verbessert werden.
In allen Phasen,Entwickler sollten den Code für die Leistung von ZKVM nicht anpassen.Entwicklererfahrung ist der Kernvorteil von ZKVM.Wenn Devex geopfert wird, um Leistungsbenchmarks zu erfüllen, verliert dies nicht nur die Bedeutung des Benchmarking, sondern verletzt auch die ursprüngliche Absicht von ZKVM.
Diese Indikatoren konzentrieren sich hauptsächlich aufBeweis für die Kosten.Wenn der Validator jedoch erlaubt istUnbegrenztes Kostenwachstum(d. h.Daher müssen die Anforderungen der folgenden Phasen erfüllt werden.Die maximale Beweisgröße und die maximale Überprüfungszeit müssen gleichzeitig definiert werden.
Phase 1 Anforderungen: „Rationale nicht triviale Überprüfungskosten“
•Beweisgröße: Muss kleiner sein als die Zeugengröße.
•Überprüfungszeit: Die Geschwindigkeit des Überprüfungsnachweises darf nicht langsamer sein als die native Ausführung des Programms (d. H. Es darf nicht langsamer sein als die direkte Ausführung der Berechnung).
Diese sindMinimale Einfachheit,stellen Sie sicherDie Beweisgröße und die Überprüfungszeit sind nicht schlechter, als einen Zeugen direkt an den Validator zu senden und ihn direkt zu überprüfen.
Stufe 2 und höher
•Maximale Beweisgröße: 256 kb.
•Maximale Überprüfungszeit: 16 Millisekunden.
Diese Obergrenzen sind absichtlich lockerer, um neuartige schnelle Proof -Technologien aufzunehmen, selbst wenn sie möglicherweise höhere Überprüfungskosten bringen.Gleichzeitig schließen diese oberen Grenzwerte den Beweis aus, der so teuer ist, dass nur wenige Projekte bereit sind, auf der Blockchain zu verwenden.
Geschwindigkeitsstufe 1
Einer Thread-Beweis darf nicht mehr als 100.000-mal langsamer sein als die native Ausführung(Gilt für mehrere Anwendungen, nicht nur für den Blocknachweis von Ethereum) und dürfen sich nicht auf Vorkompilierung verlassen.
SpeziellNehmen wir an, dass der RISC-V-Prozessor auf einem modernen Laptop über ungefähr liegt.3 Milliarden Zyklen pro Sekundeund dann Stufe 1 zu erreichen bedeutet, dass das Notizbuch kann30.000 RISC-V-Zyklen/SekundeBeweis für die Geschwindigkeitserzeugung (einzelner Thread).
Die Validatorkosten müssen den zuvor definierten „angemessenen nicht trivialen Überprüfungskosten“ erfüllen.
Geschwindigkeitsphase 2
Einer Thread-Beweis darf nicht mehr als 10.000-mal langsamer sein als die native Ausführung.
oderDa einige vielversprechende Snark -Methoden (insbesondere Binärdomänen -Snark) durch die aktuelle CPU und die GPU begrenzt sind, kann diese Phase durch FPGAs (oder sogar ASICs) erfüllt werden:
1. Berechnen Sie die Anzahl der RISC-V-Kerne, die die FPGA mit nativer Geschwindigkeit simuliert.
2. Berechnen Sie die Anzahl der FPGAs, die zur Simulation und Nachweis von RISC-V-Ausführung (nahezu Echtzeit) erforderlich sind.
3.. Wenn (2) MengeNicht mehr als 10.000 Mal (1)dann ist Stufe 2 zufrieden.
•Beweisgröße: Maximal 256 kb.
•Überprüfungszeit: Maximal 16 Millisekunden auf Standard -CPU.
Geschwindigkeitsstufe 3
In erreichenGeschwindigkeitsphase 2Basierend auf demNachweis der Beweiskosten innerhalb von 1000 ×(Anwendbar für mehrere Anwendungen) und muss verwendet werdenVorverdichtung der automatischen Synthese und formale Überprüfung.Im Wesentlichen,Passen Sie den Befehlssatz jedes Programms dynamisch an, um die Beweiserzeugung zu beschleunigen, aber es muss garantiert werdenBenutzerfreundlichkeit und formelle Überprüfung.(umWarum ist ein zweischneidiges Schwert vorkompiliert?und warum „handgeschriebene“ Vorkompilierung kein nachhaltiger Ansatz ist, siehe den nächsten Abschnitt.)
Speicherphase 1
Im Falle von weniger als 2 GB SpeichererreichenGeschwindigkeitsstufe 1und zufriedenNull Wissensanforderungen.Diese Phase fürMobiles Gerät oder BrowserEs ist entscheidend undEine große Anzahl von Client -ZKVM -AnwendungsfällenÖffnete die Tür.Zum Beispiel wird ein Smartphone verwendetStandort Privatsphäre, Identitätsanmeldeinformationen usw..Wenn die Beweisgenerierung mehr als 1-2 GB Speicher benötigt, funktionieren die meisten mobilen Geräte nicht.
Zwei wichtige Anmerkungen:
1. Auch für groß angelegte Computing (für das Billionen von CPU-Zyklen der nativen Ausführung erforderlich ist) muss das Proof-System eine 2-GB-Speicherkappe beibehalten, andernfalls ist die Anwendbarkeit begrenzt.
2. Wenn der Beweis extrem langsam ist, ist es einfach, eine 2 -GB -Speicherkappe aufrechtzuerhalten.Damit der Speicherstufe 1 sinnvoll ist, muss die Geschwindigkeitsstufe 1 innerhalb der 2 -GB -Speichergrenze erreicht werden.
Speicherphase 2
In weniger als 200 MB GedächtniserreichenGeschwindigkeitsstufe 1(10 -mal schneller als Speicherstufe 1).
Warum es auf 200 MB reduzieren?Betrachten Sie aNicht-Blockchain-Szenarien: Wenn Sie eine HTTPS -Website besuchen, werden Authentifizierungs- und Verschlüsselungszertifikate heruntergeladen.Wenn die Website stattdessen ZK -Proofs für diese Zertifikate sendet, müssen möglicherweise große Websites jede Sekunde generierenMillionen von Beweisen.Wenn pro Beweis 2 GB Speicher benötigt wird, wird die Anforderung für Computerressourcen erfülltPb -Leveloffensichtlich nicht machbar.Daher reduzieren Sie daher den Speicherverbrauch weiterNicht-Blockchain-AnwendungenEs ist entscheidend.
Vorkompiliert: letzte Meile oder Krücken?
VorkompiliertBezieht sich aufSnark Constraint -System optimiert speziell für bestimmte Funktionen (z. B. Hashing, elliptische Kurvensignaturen).In Ethereum kann die Vorkompilierung den Overhead von Merkle Hashing und Signature-Überprüfung verringern, aber die Überkompilierung der Vorkompilation kann die Kerneffizienz des Snarks nicht wirklich verbessern.
Vorkompilierungsprobleme
1. immer noch zu langsam: Auch wenn ZKVM mit Hash und Signaturen vorkompiliert ist, hat ZKVM immer noch das Ineffizienzproblem von Kernproofsystemen innerhalb und außerhalb der Blockchain.
2. Sicherheitslücken: Wenn handgeschriebene Vorkompilierung nicht offiziell verifiziert wird, gibt es fast bestimmte Schwachstellen, die zu einem katastrophalen Sicherheitsfehler führen können.
3.. Schlechte Entwicklererfahrung: Derzeit brauchen viele ZKVMs EntwicklerHandschriftenbeschränkungssystemÄhnlich wie die Programmiermethode in den 1960er Jahren, die die Entwicklungserfahrung ernsthaft beeinflusst.
4. Benchmark irreführend: Wenn Benchmarks auf die Optimierung spezifischer Vorkompilationen angewiesen sind, kann es die Menschen irreführen, sich auf die Optimierung der manuellen Einschränkungssysteme zu konzentrieren, anstatt das Snark -Design selbst zu verbessern.
5. E/A-Overhead und RAM-freier ZugriffWährend Vorkompetenzen die Leistung bei schweren Kryptoaufgaben verbessern kann, bieten sie möglicherweise keine aussagekräftige Beschleunigung für vielfältigere Arbeitsbelastungen, da sie beim Übergeben von Input/Output erhebliche Overheads aufnehmen und RAM nicht verwenden können.
Selbst in einer Blockchain-Umgebung, solange Sie über ein einzelnes L1 wie Ethereum hinausgehen (zum Beispiel möchten Sie eine Reihe von Brücken mit Kreuzketten erstellen), werden Sie unterschiedliche Hash-Funktionen und Signaturschemata ausgesetzt sein.Die kontinuierliche Vorkompilierung zur Lösung dieses Problems ist weder skalierbar noch ein großes Sicherheitsrisiko darstellt.
Ich glaube, dass die Vorkompilierung auf lange Sicht immer noch von entscheidender Bedeutung ist, aber es wird nur geschehen, wenn sie automatisch synthetisiert und offiziell validiert werden.Auf diese Weise können wir die Entwicklererfahrungsvorteile von ZKVM beibehalten und gleichzeitig katastrophale Sicherheitsrisiken vermeiden.Diese Ansicht spiegelt sich in Phase 3 wider.
Erwarteter Zeitplan
Ich erwarte, dass ein paar ZKVMs später in diesem Jahr erreicht werdenGeschwindigkeitsstufe 1UndSpeicherphase 1.Ich denke, wir können dies in den nächsten zwei Jahren erreichen.Geschwindigkeitsphase 2Es ist jedoch nicht klar, ob dieses Ziel ohne neue Forschungsideen erreicht werden kann.
Ich erwarte den Rest der Stufen (Geschwindigkeitsstufe 3UndSpeicherphase 2) Es wird Jahre dauern, bis es erreicht ist.
Obwohl dieser Artikel die Sicherheits- und Leistungsphasen von ZKVM auflistet, sind die beiden nicht völlig unabhängig.Da Schwachstellen in ZKVM weiterhin entdeckt werden, erwarte ich, dass die Behebung einiger dieser Schwachstellen unweigerlich zu einem erheblichen Leistungsrückgang führen wird.Daher wird es in ZKVM erreichtSicherheitsphase 2Zuvor sollten die Leistungstestergebnisse als vorläufige Daten betrachtet werden.
ZKVM hat ein großes Potenzial, dass sich Null-Wissen als wirklich beliebt erwiesen hat, aber es befindet sich immer noch in den frühen Stadien-voller Sicherheitsherausforderungen und schwerwiegender Leistungsengpässe.Markthype- und Marketing -Werbung erschweren den echten Fortschritt.Mit klaren Meilensteinen für Sicherheits- und Leistungsmeilen hoffe ich, eine Roadmap bereitzustellen, die den Nebel beseitigt.Wir werden schließlich unser Ziel erreichen, aber es wird Zeit und kontinuierliche Anstrengungen in Bezug auf Forschung und Ingenieurwesen dauern.
