Comment fonctionnent les coprocesseurs ZK

Architecture de base : moteur de preuve, contrat de vérification, zkVM

Un coprocesseur ZK est conçu pour décharger le calcul de la blockchain tout en maintenant la vérifiabilité. Au cœur de l'architecture se trouvent trois composants principaux : le moteur de preuve, le contrat de vérification et la machine virtuelle (zkVM ou exécution de circuit).

Le moteur de preuve est responsable de l'exécution de la computation hors chaîne et de la génération d'une preuve cryptographique que la computation a été effectuée correctement. Ce moteur prend des données d'entrée, les fait passer par une logique ou un programme défini, et produit une preuve succincte à divulgation nulle de connaissance. Le processus de preuve est généralement lourd, nécessitant des ressources de calcul telles que des CPU ou des GPU, en fonction du type de système de preuve utilisé.

Le contrat de vérification est déployé sur la chaîne et est léger par conception. Son seul but est de valider l'exactitude de la preuve soumise. Il détient la clé de vérification, qui est mathématiquement dérivée de la même logique utilisée par le prouveur. Lorsque le contrat intelligent reçoit une preuve, il la vérifie par rapport à la clé et confirme si le résultat est valide. Ce processus est rapide et peu coûteux par rapport à l'exécution du calcul complet sur la chaîne.

Le zkVM ou circuit arithmétique définit la logique du programme. Il agit comme l'environnement d'exécution pour le prouveur. Dans certains systèmes, il s'agit d'un circuit personnalisé écrit dans un DSL bas niveau, tandis que d'autres utilisent des machines virtuelles complètes qui peuvent interpréter le code dans des langages de haut niveau. Ensemble, ces composants permettent une exécution hors chaîne sans confiance et une vérification succincte sur chaîne.

Circom, Noir, Risc Zero, SP1 : Langages et machines virtuelles

Plusieurs outils et frameworks ont émergé pour soutenir le développement de coprocesseurs ZK. Circom est l'un des langages de circuits les plus anciens et les plus utilisés. Il permet aux développeurs de définir des circuits arithmétiques en utilisant une syntaxe déclarative. Ces circuits sont ensuite compilés en systèmes de preuve tels que Groth16 ou PLONK. Circom est connu pour sa flexibilité mais présente une courbe d'apprentissage abrupte et nécessite une conception manuelle des circuits.

Noir est un langage plus récent conçu pour rendre le développement ZK accessible. Développé par Aztec, Noir est un langage similaire à Rust qui abstrait une grande partie de la complexité des systèmes de contraintes. Il se compile automatiquement en circuits zéro-knowledge, facilitant l'écriture de programmes privés avec une syntaxe lisible.

Au-delà des langues, les zkVM attirent l'attention pour leur capacité à exécuter du code à usage général dans un environnement compatible avec les ZK. Risc Zero propose l'une des implémentations de zkVM les plus avancées. Il émule l'ensemble d'instructions RISC-V et permet aux développeurs d'exécuter n'importe quel programme écrit en Rust ou en C sous forme de preuve à connaissance nulle. SP1, développé par Succinct, adopte une approche similaire mais vise à optimiser les performances et la portabilité à travers les systèmes de preuve.

Ces environnements sont cruciaux car ils déterminent à quel point les coprocesseurs ZK peuvent être expressifs, efficaces et composables. Bien que les circuits de bas niveau restent utiles pour les applications critiques en termes de performance, les zkVM permettent une adoption plus large par les développeurs et une itération plus rapide.

Flux d'exemple : Comment Axiom ou Bonsai exécute la logique ZK

Pour comprendre comment fonctionne un coprocesseur ZK en pratique, considérons le flux d'exécution d'un système comme Axiom ou Bonsai de Risc Zero.

Dans le modèle d'Axiom, un développeur définit une requête sur les données historiques d'Ethereum — par exemple, vérifier si un utilisateur avait un solde spécifique à un bloc passé. Cette requête est envoyée au coprocesseur hors chaîne d'Axiom. Le coprocesseur récupère les données on-chain pertinentes, traite la requête et exécute la logique en utilisant un zkVM. Une fois le calcul terminé, le coprocesseur génère une preuve à divulgation nulle de connaissance qui atteste de la justesse du résultat. Cette preuve est soumise on-chain à un contrat de vérification, qui la valide et permet à un contrat intelligent d'utiliser le résultat en toute confiance.

Bonsai de Risc Zero suit une structure similaire mais généralise le processus. Les développeurs écrivent leur logique d'application dans un langage de haut niveau comme Rust. Ce code est compilé en une image zkVM et exécuté hors chaîne à l'aide de l'infrastructure de Bonsai. Après l'exécution, une preuve est générée et peut être renvoyée à n'importe quelle blockchain via un vérificateur en chaîne.

Cette architecture permet aux développeurs de créer une logique puissante et minimisée en matière de confiance sans surcharger la blockchain. Elle permet également des preuves réutilisables et composables qui peuvent servir plusieurs contrats ou applications.

Qu'est-ce qui rend les preuves sans confiance et vérifiables

La force d'un coprocesseur ZK réside dans le modèle de confiance qu'il permet. Contrairement aux oracles centralisés ou aux fournisseurs de calcul hors chaîne, les coprocesseurs ZK ne nécessitent pas que les utilisateurs fassent confiance à l'entité effectuant le calcul. Au lieu de cela, la confiance est transférée aux mathématiques.

Le cœur de cette confiance repose sur la structure des preuves à divulgation nulle de connaissance. Ces preuves sont conçues de telle manière qu'un calcul invalide, même un seul bit incorrect, entraînera un échec de la vérification. Le contrat de vérification ne peut pas être trompé pour accepter un résultat faux, à condition que les hypothèses cryptographiques soient respectées.

De plus, puisque le vérificateur n'a besoin que des entrées publiques, de la preuve et de la clé de vérification, il n'y a pas de dépendance à l'identité ou au comportement du prouveur. N'importe quel tiers peut générer la preuve, et tant qu'elle passe la vérification, elle est acceptée. Cela signifie que les prouveurs peuvent être décentralisés, sans autorisation et même incités, ce qui est une caractéristique explorée plus en détail dans les réseaux de preuve.

En combinant des garanties cryptographiques avec la finalité de la blockchain, les coprocesseurs ZK permettent une nouvelle couche d'exécution sans confiance qui ne repose pas sur des services centralisés, la réputation ou le consensus multisig.

Rôle dans les écosystèmes DeFi, inter-chaînes et L2

Les coprocesseurs ZK trouvent un véritable élan dans des domaines où le calcul doit être minimisé en termes de confiance, rentable ou privé. Dans la DeFi, ils peuvent calculer des prix moyens pondérés par le temps, des actifs détenus au fil du temps, ou des modèles de risque personnalisés sans stocker toutes les données sur la chaîne. Cela permet des contrats financiers plus intelligents sans augmenter les coûts de gaz ou alourdir la blockchain.

Dans les applications inter-chaînes, les coprocesseurs ZK peuvent servir de clients légers. Au lieu d'exécuter des nœuds complets pour chaque chaîne, les applications peuvent vérifier une preuve succincte de l'état d'une autre chaîne. Cela simplifie considérablement les ponts et les protocoles de messagerie, améliorant à la fois la sécurité et l'interopérabilité.

Les écosystèmes de couche 2 adoptent également des coprocesseurs ZK comme moyen d'optimiser la logique de rollup. Plutôt que d'exécuter chaque interaction à l'intérieur du circuit de rollup, les rollups peuvent déléguer des tâches spécifiques, comme la détection de fraude, la vérification d'oracles ou la logique définie par l'utilisateur, à des coprocesseurs ZK externes. Cela réduit les coûts de preuve et rend les rollups plus modulaires.

Les coprocesseurs ZK émergent donc en tant que composants d'infrastructure essentiels. Ils étendent ce que les blockchains peuvent faire sans compromettre la décentralisation ou les performances. À mesure que les outils et les environnements d'exécution mûrissent, ils devraient devenir des options par défaut dans la pile de développement pour toute application décentralisée avancée.