IOG entwickelt ZK Wrapper für die Verifizierung von RISC Zero und SP1 Proofs auf Cardano

nput Output Research has developed a prototype that converts widely used Groth16 proofs into a format Cardano can verify through Plutus. The Cardano Vision 2026 workshop also presented post-quantum experiments with Plonky3 and a Halo2 tool for estimating on-chain verification costs.

By SongMarketCap

Cardano News - IOG entwickelt ZK Wrapper für die Verifizierung von RISC Zero und SP1 Proofs auf Cardano

Input Output Research entwickelt einen Zero Knowledge Wrapper, der Cardano Anwendungen mit RISC Zero, SP1 und anderen Systemen verbinden soll, die Groth16 Proofs über der elliptischen Kurve BN254 erzeugen.

Der Prototyp schließt eine kryptografische Kompatibilitätslücke, die derzeit verhindert, dass Cardano Smart Contracts viele von etablierten ZK Tools erzeugte Proofs effizient verifizieren. Die Arbeit befindet sich noch in der Phase der technischen Machbarkeit, wobei ausgewählte Komponenten für eine mögliche technische Implementierung Anfang 2027 vorbereitet werden.

Groth16 Wrapper konvertiert BN254 Proofs für Cardano

Ein großer Teil der Zero Knowledge Infrastruktur im Blockchain Bereich nutzt Groth16 Proofs über BN254. Die Unterstützung dieser Kurve durch Ethereum hat Entwickler Frameworks, Anwendungen und ZK virtuelle Maschinen dazu ermutigt, denselben kryptografischen Standard zu übernehmen.

Cardano unterstützt dagegen Operationen über BLS12-381. Obwohl Groth16 mit beiden Kurven verwendet werden kann, lässt sich ein über BN254 erzeugter Proof auf Cardano nicht effizient verifizieren, ohne neue Protokollfunktionen oder rechnerisch aufwendige Arithmetik in einem Plutus Smart Contract.

Der Prototyp führt eine rekursive Wrapping Schicht zwischen den beiden Umgebungen ein. Sie nimmt einen gültigen Groth16 Proof über BN254 entgegen und erzeugt einen zweiten Proof über BLS12-381, sodass Cardano das Ergebnis mit kryptografischen Operationen verifizieren kann, die bereits vom Netzwerk unterstützt werden.

Für die Umwandlung müssen Nutzer der ausführenden Partei nicht vertrauen. Der äußere Proof bestätigt, dass für den angegebenen Verifikationsschlüssel und die öffentlichen Eingaben ein gültiger ursprünglicher Proof existiert. Cardano prüft diese Aussage, ohne die Berechnung hinter dem ursprünglichen Ergebnis zu wiederholen.

Das aktuelle Toolkit unterstützt RISC Zero und SP1, zwei Zero Knowledge virtuelle Maschinen, mit denen Entwickler allgemeine Programme ausführen und kompakte Proofs erzeugen können, die die korrekte Ausführung dieser Programme belegen.

Quellspezifische Plugins wandeln deren Ausgaben in ein gemeinsames Format um. Die Wrapping Engine reproduziert anschließend die Aussage über BLS12-381 und erzeugt Verifier Code, der in eine Cardano Anwendung integriert werden kann.

Input Output Research testete Groth16 und Plonk als äußere Beweissysteme. Groth16 schloss den Wrapping Prozess schneller ab und erzeugte kleinere Proofs, benötigt jedoch ein Trusted Setup für den Wrapper Circuit. Plonk vermeidet ein circuitspezifisches Setup, erfordert jedoch deutlich mehr Off chain Beweiszeit.

Beide Ansätze erzeugten finale Proofs, die in Cardanos On chain Verifizierungsbudget passen. Der wichtigste Trade off liegt daher in der Proof Erzeugung und den Setup Anforderungen statt in der finalen Verifizierung durch Plutus.

RISC Zero und SP1 könnten Cross Chain Verifizierung unterstützen

Die Kompatibilität mit RISC Zero und SP1 würde Cardano Entwicklern erlauben, bestehende ZK Programme und Bibliotheken zu nutzen, ohne jede Berechnung für Cardanos kryptografische Umgebung neu erstellen zu müssen.

Ein in der Forschung enthaltenes Beispiel weist den ERC-20 Kontostand eines Ethereum Kontos nach. RISC Zero führt die erforderliche Ethereum Logik aus, extrahiert das Guthaben aus dem festgeschriebenen Netzwerkzustand und erzeugt einen Proof. Der Wrapper wandelt diese Ausgabe anschließend in eine Form um, die ein Cardano Validator verifizieren kann.

Dieselbe Architektur könnte verwendet werden, um ausgewählte Ethereum oder Bitcoin Zustände zu bestätigen, externe Programmausführungen zu verifizieren oder kryptografische Nachweise zu liefern, dass eine Berechnung außerhalb von Cardano stattgefunden hat.

Im Workshop wurde außerdem eine mögliche SP1 basierte Implementierung von Helios, einem Ethereum Light Client, diskutiert. Ein solches System könnte die Ausführung des Ethereum Konsenses in einer Zero Knowledge Umgebung nachweisen und ein kompaktes Ergebnis zur Verifizierung durch eine Cardano Anwendung einreichen.

Diese Fähigkeiten könnten Light Clients, Bridges, Rollups und Cross Chain Protokolle unterstützen, die von verlässlichen Informationen einer anderen Blockchain abhängen. Der Wrapper transferiert keine Assets und fungiert nicht selbst als Bridge. Er stellt eine Verifizierungsschicht bereit, die andere Anwendungen in ihre eigene Architektur integrieren könnten.

Der Ansatz könnte auch doppelte Entwicklungsarbeit reduzieren. Anstatt jede Berechnung als Cardano natives ZK Circuit zu implementieren, könnten Teams unterstützte Software aus den RISC Zero oder SP1 Ökosystemen nutzen und den finalen Proof vor der On chain Verifizierung übersetzen.

Das Toolkit bleibt ein Prototyp für Experimente. Seine Beispiele decken die Proof Generierung, rekursives Wrapping und die Erstellung des entsprechenden Cardano Verifiers ab, während ein produktiver Einsatz weiterhin Engineering Arbeit, Sicherheitsprüfung und eine endgültige Entscheidung über das äußere Beweissystem erfordern würde.

Plonky3 und Halo2 definieren die verbleibende Verifizierungsarbeit

Der Workshop stellte außerdem eine Machbarkeitsstudie zur Verifizierung von Plonky3 Proofs über Cardano Smart Contracts vor.

Plonky3 ist ein modulares Framework für STARK basierte Beweissysteme. Es stützt sich primär auf Hashfunktionen und endliche Feldarithmetik statt auf die von vielen SNARK Systemen verwendeten elliptischen Kurvenoperationen, was es für Cardanos postquantische Forschung relevant macht.

Eine vorgeschlagene Anwendung ist die postquantische Signaturaggregation. Diese Signaturen können jeweils Dutzende Kilobyte benötigen, während ein ZK Proof mehrere Signaturen zu einem einzigen Ergebnis kombinieren und die Datenmenge verringern könnte, die On chain gespeichert oder verifiziert werden muss.

Eine weitere mögliche Nutzung betrifft Legacy UTXOs nach einer künftigen Abkehr von den aktuellen Signaturen über elliptische Kurven. Ein Inhaber könnte möglicherweise die Kenntnis des mit einer Adresse verbundenen Seeds nachweisen, ohne den Seed öffentlich offenzulegen.

Die Machbarkeitsstudie ergab, dass eine direkte Plonky3 Verifizierung weiterhin Cardanos Grenzen für Einzeltransaktionen überschreitet. Ein optimierter Test Proof maß ungefähr 186 Kilobyte und benötigte etwa 220 Millionen Speichereinheiten und 75 Milliarden CPU Einheiten.

Da einzelne Query Proofs separat geprüft werden können, schätzten die Forschenden, dass der gesamte Prozess auf ungefähr 23 Transaktionen aufgeteilt werden könnte. Hydra Ausführung und ein optimistisches Verifizierungsmodell, bei dem der vollständige Proof erst nach einer Challenge geprüft wird, wurden ebenfalls als mögliche Alternativen diskutiert.

Ein separates Halo2 Kostenabschätzungswerkzeug adressiert eine frühere Phase des Entwicklungsprozesses. Das Tool berechnet die erwartete Proof Größe, die Größe des Verifikationsschlüssels und die kryptografischen Operationen, die erforderlich sind, um einen vorgeschlagenen Circuit auf Cardano zu verifizieren.

Entwickler können einen Circuit modellieren oder Komponenten wie SHA-256 testen, bevor sie die vollständige Anwendung fertigstellen. Die Schätzungen ermöglichen es Teams, teure Komponenten zu identifizieren und das Design anzupassen, bevor sie den Prover und den Cardano Validator erstellen.

Der Groth16 Wrapper ist derzeit der direkteste Weg vom Forschungsprogramm zur praktischen Nutzung durch Entwickler. Wenn er in die technische Implementierung übergeht, könnten Cardano Anwendungen Ausgaben aus etablierten zkVM Ökosystemen verifizieren, ohne darauf zu warten, dass jedes externe System native BLS12-381 Unterstützung einführt. Plonky3 würde eine andere Architektur erfordern, bei der die Verifizierung über Transaktionen aufgeteilt, in Hydra verlagert oder durch ein Challenge basiertes Design aktiviert wird.