IOG développe un wrapper ZK pour la vérification de preuves RISC Zero et SP1 sur Cardano

Input Output Research a développé un prototype qui convertit les preuves Groth16 largement utilisées en un format que Cardano peut vérifier via Plutus. L’atelier Cardano Vision 2026 a également présenté des expériences postquantiques avec Plonky3 et un outil Halo2 pour estimer les coûts de vérification sur chaîne.

By SongMarketCap

Cardano News - IOG développe un wrapper ZK pour la vérification de preuves RISC Zero et SP1 sur Cardano

Input Output Research développe un wrapper à connaissance nulle conçu pour relier les applications Cardano à RISC Zero, SP1 et à d’autres systèmes qui génèrent des preuves Groth16 sur la courbe elliptique BN254.

Le prototype traite un déficit de compatibilité cryptographique qui empêche actuellement les contrats intelligents Cardano de vérifier efficacement de nombreuses preuves produites par des outils ZK établis. Les travaux en sont encore au stade de faisabilité technique, certains composants étant préparés en vue d’une éventuelle mise en œuvre d’ingénierie au début de 2027.

Le wrapper Groth16 convertit des preuves BN254 pour Cardano

Une grande part de l’infrastructure à connaissance nulle des blockchains utilise des preuves Groth16 sur BN254. La prise en charge de cette courbe par Ethereum a encouragé les frameworks de développement, les applications et les machines virtuelles ZK à adopter le même standard cryptographique.

Cardano prend en charge à la place les opérations BLS12-381. Bien que Groth16 puisse être utilisé avec les deux courbes, une preuve créée sur BN254 ne peut pas être vérifiée efficacement sur Cardano sans de nouvelles fonctions de protocole ou une arithmétique coûteuse en calcul à l’intérieur d’un contrat intelligent Plutus.

Le prototype introduit une couche d’empaquetage récursive entre les deux environnements. Il reçoit une preuve Groth16 valide sur BN254 et génère une seconde preuve sur BLS12-381, permettant à Cardano de vérifier le résultat en utilisant des opérations cryptographiques déjà prises en charge par le réseau.

La conversion ne requiert pas que les utilisateurs fassent confiance à la partie qui l’effectue. La preuve externe confirme qu’une preuve originale valide existe pour la clé de vérification et les entrées publiques spécifiées. Cardano vérifie cette affirmation sans répéter le calcul à l’origine du résultat initial.

L’ensemble d’outils actuel prend en charge RISC Zero et SP1, deux machines virtuelles à connaissance nulle qui permettent aux développeurs d’exécuter des programmes généraux et de générer des preuves compactes attestant que ces programmes se sont exécutés correctement.

Des plugins spécifiques à la source convertissent leurs sorties dans un format commun. Le moteur d’empaquetage reproduit ensuite l’assertion sur BLS12-381 et génère du code de vérificateur qui peut être intégré à une application Cardano.

Input Output Research a testé Groth16 et Plonk comme systèmes de preuve externes. Groth16 a achevé le processus d’empaquetage plus rapidement et a produit des preuves plus petites, mais nécessite une configuration de confiance pour le circuit du wrapper. Plonk évite une configuration spécifique au circuit tout en exigeant nettement plus de temps de preuve hors chaîne.

Les deux approches ont produit des preuves finales capables de tenir dans le budget de vérification sur chaîne de Cardano. Le principal compromis réside donc dans la génération des preuves et les exigences de configuration plutôt que dans la vérification finale via Plutus.

RISC Zero et SP1 pourraient prendre en charge la vérification interchaîne

La compatibilité avec RISC Zero et SP1 permettrait aux développeurs Cardano d’utiliser des programmes et bibliothèques ZK existants sans reconstruire chaque calcul pour l’environnement cryptographique de Cardano.

Un exemple inclus dans la recherche prouve le solde ERC-20 d’un compte Ethereum. RISC Zero exécute la logique Ethereum requise, extrait le solde à partir de l’état du réseau engagé et génère une preuve. Le wrapper convertit ensuite cette sortie en une forme qu’un validateur Cardano peut vérifier.

La même architecture pourrait être utilisée pour confirmer un état sélectionné d’Ethereum ou de Bitcoin, vérifier l’exécution d’un programme externe ou fournir une preuve cryptographique qu’un calcul s’est produit en dehors de Cardano.

L’atelier a également discuté d’une implémentation potentielle de Helios basée sur SP1, un client léger Ethereum. Un tel système pourrait prouver l’exécution du consensus Ethereum dans un environnement à connaissance nulle et soumettre un résultat compact pour vérification par une application Cardano.

Ces capacités pourraient prendre en charge des clients légers, des ponts, des rollups et des protocoles interchaîne qui dépendent d’informations fiables provenant d’une autre blockchain. Le wrapper ne transfère pas d’actifs et n’opère pas comme un pont à lui seul. Il fournit une couche de vérification que d’autres applications pourraient intégrer dans leur propre architecture.

L’approche pourrait aussi réduire le travail de développement dupliqué. Au lieu d’implémenter chaque calcul comme un circuit ZK natif à Cardano, les équipes pourraient utiliser des logiciels pris en charge dans les écosystèmes RISC Zero ou SP1 et traduire la preuve finale avant la vérification sur chaîne.

L’outil reste un prototype pour l’expérimentation. Ses exemples couvrent la génération de preuves, l’empaquetage récursif et la création du vérificateur Cardano correspondant, tandis que le déploiement en production nécessiterait encore du travail d’ingénierie, une revue de sécurité et une décision finale concernant le système de preuve externe.

Plonky3 et Halo2 définissent le travail de vérification restant

L’atelier a également présenté une étude de faisabilité pour la vérification de preuves Plonky3 via des contrats intelligents Cardano.

Plonky3 est un framework modulaire pour des systèmes de preuve basés sur STARK. Il s’appuie principalement sur des fonctions de hachage et une arithmétique sur des corps finis plutôt que sur les opérations de courbe elliptique utilisées par de nombreux systèmes SNARK, ce qui le rend pertinent pour la recherche postquantique de Cardano.

Une application proposée est l’agrégation de signatures postquantiques. Ces signatures peuvent nécessiter des dizaines de kilooctets chacune, tandis qu’une preuve ZK pourrait combiner plusieurs signatures en un seul résultat et réduire la quantité de données qui doivent être stockées ou vérifiées sur chaîne.

Un autre usage possible concerne les UTXO hérités après une future migration au-delà des signatures actuelles à courbe elliptique. Un détenteur pourrait potentiellement prouver la connaissance de la graine liée à une adresse sans révéler publiquement cette graine.

L’étude de faisabilité a constaté que la vérification directe Plonky3 dépasse encore les limites de transaction unique de Cardano. Une preuve de test optimisée mesurait environ 186 kilooctets et nécessitait environ 220 millions d’unités mémoire et 75 milliards d’unités CPU.

Comme les preuves de requêtes individuelles peuvent être vérifiées séparément, les chercheurs ont estimé que le processus complet pourrait être réparti sur environ 23 transactions. L’exécution via Hydra et un modèle de vérification optimiste, dans lequel la preuve complète n’est vérifiée qu’après un défi, ont également été discutés comme alternatives possibles.

Un estimateur de coûts Halo2 distinct traite une étape plus précoce du processus de développement. L’outil calcule la taille prévue de la preuve, la taille de la clé de vérification et les opérations cryptographiques nécessaires pour vérifier un circuit proposé sur Cardano.

Les développeurs peuvent modéliser un circuit ou tester des composants tels que SHA-256 avant d’achever l’application complète. Les estimations permettent aux équipes d’identifier les composants coûteux et d’ajuster la conception avant de construire le prouveur et le validateur Cardano.

Le wrapper Groth16 est actuellement la voie la plus directe entre le programme de recherche et un usage pratique par les développeurs. S’il progresse vers une mise en œuvre d’ingénierie, les applications Cardano pourraient vérifier des sorties provenant d’écosystèmes zkVM établis sans attendre que chaque système externe introduise une prise en charge native de BLS12-381. Plonky3 nécessiterait une architecture différente, avec une vérification répartie sur des transactions, déplacée dans Hydra ou activée via une conception basée sur un défi.