Réinvention du calcul hors chaîne : explication détaillée des co-processeurs ZK et de leurs perspectives d'application dans la DeFi et les DAO
TechFlow SélectionTechFlow Sélection
Réinvention du calcul hors chaîne : explication détaillée des co-processeurs ZK et de leurs perspectives d'application dans la DeFi et les DAO
Cet article traite principalement des méthodes de mise en œuvre des coprocesseurs, de leurs diverses applications ainsi que des orientations futures de développement.
Dédié à des analyses Web3 approfondiesAuteur : Kernel Ventures Turbo Guo
Relecture : Kernel Ventures Mandy, Kernel Ventures Joshua
TL ; DR
Un coprocesseur ZK est une solution permettant aux dApps d'utiliser des ressources de calcul hors chaîne. Cet article traite principalement des méthodes de mise en œuvre du coprocesseur, de ses diverses applications et des orientations futures. Les points clés sont les suivants :
-
Le zkVM de RISC Zero est une solution de coprocesseur ZK qui permet à un contrat sur chaîne d'appeler un zkVM hors chaîne pour exécuter un code Rust spécifique, puis de renvoyer le résultat au contrat tout en fournissant une preuve à connaissance nulle (zkp) que ce dernier peut vérifier afin de s'assurer que le calcul a été effectué correctement.
-
Les coprocesseurs ZK peuvent être implémentés de différentes manières. Outre les zkVM, les utilisateurs peuvent concevoir eux-mêmes des circuits ZK personnalisés pour leurs programmes ou utiliser des frameworks prédéfinis pour écrire ces circuits, permettant ainsi aux contrats intelligents d'exploiter des ressources de calcul hors chaîne.
-
Les coprocesseurs ZK ont des applications dans DeFi, par exemple en déplaçant les calculs des AMM hors chaîne, permettant ainsi aux protocoles de capter une valeur similaire au MEV, ou en rendant possible l'exécution de logiques complexes nécessitant beaucoup de puissance de calcul. Ils permettent également aux protocoles de prêt de calculer en temps réel les taux d'intérêt et de rendre transparent le calcul des marges. Il existe deux façons d'implémenter un zkAMM : via un zkVM ou via un zkOracle.
-
Les coprocesseurs ZK ont d'autres usages potentiels, comme permettre aux portefeuilles d'effectuer la vérification d'identité hors chaîne, aux jeux sur chaîne d'exécuter des calculs plus complexes, ou de réduire les frais de gaz liés à la gouvernance des DAO.
-
L'écosystème des coprocesseurs ZK n'est pas encore stabilisé. Bien qu'il soit plus convivial pour les développeurs d'utiliser un projet comme interface pour accéder aux ressources hors chaîne plutôt que d'écrire eux-mêmes des circuits, la question du fournisseur de services de calcul utilisé en arrière-plan (cloud traditionnel, partage décentralisé de ressources, etc.) reste ouverte et mérite discussion.
1. Signification et applications du coprocesseur ZK
Le cœur du coprocesseur ZK consiste à déplacer les calculs sur chaîne vers des environnements hors chaîne, en utilisant des preuves à connaissance nulle (ZK) pour garantir la fiabilité du processus de calcul. Ainsi, les contrats intelligents peuvent traiter efficacement de grandes quantités de données tout en conservant la capacité de vérifier la validité des résultats. Cette approche rappelle celle des zkRollups, mais alors que les Rollups concernent l'utilisation des ressources hors chaîne par la couche protocole, les coprocesseurs ZK permettent aux dApps d'accéder à ces mêmes ressources.
Nous allons ici expliquer une méthode de mise en œuvre d’un coprocesseur ZK à travers RISC Zero, bien qu’il existe plusieurs autres approches que nous aborderons plus tard. RISC Zero a développé l’architecture Bonsai, dont le composant central est son zkVM. Grâce à ce zkVM, les développeurs peuvent générer des preuves ZK attestant qu’un morceau de code Rust donné a été correctement exécuté. Une fois le zkVM disponible, le processus d’exécution du coprocesseur ZK suit les étapes suivantes :
-
Le développeur envoie une requête au contrat relais de Bonsai, demandant l’exécution d’un programme spécifique dans le zkVM.
-
Le contrat relais transmet cette requête à un pool de requêtes hors chaîne.
-
Bonsai exécute la requête hors chaîne dans le zkVM, effectue des calculs intensifs, puis génère un reçu (receipt).
-
Ces preuves, appelées « reçus », sont publiées par Bonsai sur la chaîne via le contrat relais.
Dans Bonsai, les programmes dont on produit la preuve sont appelés « Guest Programs ». Le reçu atteste que le guest program a été correctement exécuté. Ce reçu comprend un journal (journal) et un sceau (seal). Le journal contient les sorties publiques de l’application zkVM, tandis que le sceau sert à prouver la validité du reçu — autrement dit, qu’il a été généré suite à une exécution correcte du guest program. Ce sceau est lui-même une zkSTARK générée par le prouveur. La vérification du reçu garantit que le journal a été construit conformément au circuit attendu.
Bonsai simplifie grandement pour les développeurs les étapes de compilation du code Rust en bytecode zkVM, de téléchargement du programme, d’exécution dans la machine virtuelle et de retour de la preuve, leur permettant ainsi de se concentrer davantage sur la conception logique du programme. Non seulement certaines parties de la logique du contrat peuvent être exécutées hors chaîne, mais toute la logique du contrat peut l’être. RISC Zero utilise aussi une technique appelée « continuations », qui divise la génération d'une grande preuve en plusieurs parties, chacune étant prouvée séparément. Cela permet de générer des preuves pour de gros programmes sans consommer trop de mémoire.Outre RISC Zero, d'autres projets comme IronMill, =nil; Foundation et Marlin proposent également des solutions générales similaires.
2. Applications des coprocesseurs ZK dans DeFi
2.1 AMM - avec Bonsai comme coprocesseur
zkUniswap est un AMM qui exploite les ressources de calcul hors chaîne, en particulier Bonsai. Son principe repose sur le déplacement hors chaîne d’une partie des calculs liés aux swaps. Lorsqu’un utilisateur lance une transaction de swap sur chaîne, le contrat relais de Bonsai récupère la requête, déclenche un calcul hors chaîne, puis renvoie le résultat et la preuve au callback du contrat EVM. Si la preuve est validée, le swap est exécuté.
Cependant, le processus n’est pas instantané : la requête et l’exécution ont lieu dans des transactions distinctes, ce qui comporte un risque. Entre le moment où la requête est envoyée et celui où le swap est finalisé, l’état du pool peut changer. En effet, la validation repose sur l’état du pool au moment de la requête. Si cet état change pendant que la requête est en attente, la preuve deviendra invalide.
Pour résoudre ce problème, les développeurs ont mis en place un système de verrouillage du pool. Dès qu’un utilisateur envoie une requête, toutes les opérations autres que le règlement du swap sont bloquées, jusqu’à ce que le swap soit déclenché avec succès sur chaîne ou qu’un délai prédéfini soit atteint. Ce délai limite le blocage, même en cas de panne du relais ou de problème avec la preuve. Ce délai pourrait être de quelques minutes.
zkUniswap intègre une conception originale concernant le MEV : elle vise à ce que le protocole capte lui-même la valeur du MEV. Théoriquement, les zkAMMs sont également sujets au MEV, car le premier à soumettre une transaction peut obtenir le verrou, incitant ainsi à la course au gaz, et les builders peuvent toujours ordonner les transactions. Mais dans zkUniswap, les revenus liés au MEV sont capturés directement par le protocole via un mécanisme appelé VRGDA (Variable Rate Gradual Dutch Auction).
Le protocole met en vente aux enchères le verrou à prix décroissant. Si le verrou se vend rapidement, cela indique une forte demande, et le protocole augmente automatiquement le prix ; si la vente ralentit, il baisse le prix. Ce mécanisme devient ainsi une nouvelle source de revenus. En somme, le protocole introduit un nouvel actif qui détermine l’ordre des transactions, et la concurrence autour de ce nouvel actif alimente directement les revenus du projet. C’est une idée pleine d’imagination.
2.2 AMM - avec zkOracle comme coprocesseur
Au lieu d’utiliser un zkVM, certains proposent d’utiliser un zkOracle pour exploiter les ressources de calcul hors chaîne, le zkOracle étant un oracle combinant entrées et sorties. Généralement, il existe deux types d’oracles : les oracles d’entrée, qui transfèrent des données hors chaîne vers la chaîne après traitement (calcul), et les oracles de sortie, qui exposent des données de la chaîne vers l’environnement hors chaîne après traitement. Un oracle I/O (entrée-sortie), ou zkOracle, fonctionne en deux temps : d’abord une sortie, puis une entrée, permettant ainsi à la chaîne d’utiliser les capacités de calcul hors chaîne.
Le zkOracle utilise des données de la chaîne comme source, tout en garantissant par ZK que les nœuds de l’oracle n’ont pas triché lors du calcul, assurant ainsi la fonction de coprocesseur. Ainsi, le calcul principal de l’AMM peut être réalisé dans le zkOracle, offrant non seulement les fonctionnalités classiques d’un AMM, mais aussi la possibilité d’opérations plus complexes et gourmandes en calcul.
2.3 Autres applications : calcul des taux d’intérêt, des marges, etc.
Indépendamment de la méthode utilisée, les coprocesseurs ZK permettent de nombreuses fonctionnalités.Par exemple, les protocoles de prêt peuvent ajuster dynamiquement les taux d’intérêt selon la situation réelle, plutôt que de fixer des paramètres prédéterminés. Par exemple, augmenter les taux lorsque la demande de prêt est élevée pour attirer plus d’offre, puis les réduire quand la demande diminue. Cela suppose que le protocole puisse accéder en temps réel aux données de la chaîne et effectuer de nombreux calculs pour déterminer les bons paramètres — une tâche qui nécessite du calcul hors chaîne (sauf si le coût sur chaîne devient négligeable).
Des calculs complexes comme ceux du solde de marge, des gains/pertes non réalisés ou des montants de liquidation peuvent également être déplacés vers un coprocesseur. L’avantage réside dans une plus grande transparence et vérifiabilité : la logique du moteur de marge n’est plus une boîte noire opaque. Même si les calculs ont lieu hors chaîne, les utilisateurs peuvent faire entièrement confiance à leur exactitude. Cette approche s’applique aussi bien aux options.
3. Autres applications des coprocesseurs ZK
3.1 Portefeuille - utilisation de Bonsai comme coprocesseur
Bonfire Wallet utilise un zkVM pour déporter hors chaîne le calcul de vérification d’identité. Ce portefeuille vise à permettre aux utilisateurs de créer des wallets jetables (burner wallets) via des informations biométriques (empreinte digitale) ou du matériel cryptographique comme une YubiKey.
Plus précisément, Bonfire Wallet s’appuie sur WebAuthn, un standard web universel d’authentification, permettant aux utilisateurs de s’authentifier sur des sites web sans mot de passe, uniquement via leur appareil. Dans Bonfire Wallet, l’utilisateur génère une clé publique via WebAuthn (non liée à la blockchain, destinée à WebAuthn) et l’utilise pour créer son portefeuille.
Chaque wallet burner dispose d’un contrat sur chaîne contenant la clé publique WebAuthn. Ce contrat doit vérifier la signature WebAuthn de l’utilisateur. Or, ce calcul est très coûteux, c’est pourquoi Bonsai est utilisé pour déporter ce calcul hors chaîne : un programme invité (guest program) dans le zkVM valide la signature hors chaîne et génère une zkp que le contrat sur chaîne peut vérifier.
3.2 Accès aux données sur chaîne - écriture directe de circuits ZK par l’utilisateur
Axiom est une application qui utilise une solution de coprocesseur ZK sans recourir à un zkVM. Présentons d’abord l’objectif d’Axiom : il cherche à permettre aux contrats intelligents d’accéder à des informations historiques de la chaîne. Or, il est difficile pour un contrat d’accéder à des données passées, car ils n’ont généralement accès qu’aux données en temps réel, et cela reste coûteux. Il est donc difficile pour un contrat d’obtenir des données historiques précieuses comme les soldes antérieurs d’un compte ou l’historique des transactions.
Les nœuds Axiom accèdent aux données nécessaires sur chaîne, effectuent les calculs requis hors chaîne, puis génèrent une preuve à connaissance nulle attestant que le résultat a été correctement obtenu à partir de données valides. Cette preuve est ensuite vérifiée sur chaîne, garantissant que le contrat peut faire confiance au résultat.
Pour générer une preuve ZK d’un calcul hors chaîne, il faut compiler le programme dans un circuit ZK. Comme mentionné précédemment, une option consiste à utiliser un zkVM. Toutefois, Axiom souligne qu’il existe plusieurs approches, chacune impliquant un compromis entre performance, souplesse et expérience de développement :
-
Circuits sur mesure : le développeur conçoit un circuit spécifique à son programme. Performances optimales, mais développement long.
-
eDSL/DSL : le développeur écrit toujours son propre circuit, mais avec des frameworks facilitant la gestion des aspects techniques liés au ZK, offrant un bon compromis entre performance et ergonomie.
-
zkVM : le développeur exécute directement son code dans une machine virtuelle ZK préexistante. Très pratique, mais selon Axiom, peu efficace.
Ainsi, Axiom a choisi la deuxième option et fournit aux utilisateurs une bibliothèque de modules ZK optimisés pour concevoir leurs propres circuits.
Des projets similaires à Axiom incluent Herodotus, qui vise à devenir un middleware pour le transfert d’informations inter-chaînes. Étant donné que le traitement des données se fait hors chaîne, il est logique que différentes blockchains puissent accéder aux données traitées. Un autre projet, Space and Time, utilise une architecture similaire pour l’indexation de données.
3.3 Autres applications : jeux sur chaîne, gouvernance DAO, etc.
En dehors de cela, les jeux sur chaîne et la gouvernance des DAO peuvent également tirer parti des coprocesseurs ZK. Selon RISC Zero, tout calcul nécessitant plus de 250k gas serait moins coûteux grâce à un coprocesseur ZK, bien que la méthode exacte de ce calcul reste à clarifier. La gouvernance DAO, souvent impliquant de multiples participants et contrats, est particulièrement gourmande en ressources de calcul. RISC Zero affirme que l’utilisation de Bonsai peut réduire les frais de gaz de 50 %.ZKML suit fondamentalement la même logique qu’un coprocesseur ZK ; des projets comme Modulus Labs et Giza s’inscrivent donc dans ce domaine, bien que le concept de coprocesseur ZK soit plus large.
En outre, le domaine des coprocesseurs ZK compte des projets auxiliaires, comme ezkl, qui fournit un compilateur pour circuits ZK, une suite d’outils pour le déploiement ZK, ou des outils pour déplacer les calculs de la chaîne vers l’extérieur.
4. Perspectives futures
Les coprocesseurs offrent aux applications sur chaîne un accès à des ressources de calcul externes comparables au « cloud », fournissant une puissance de calcul importante à moindre coût, tandis que la chaîne ne gère que les calculs essentiels. En pratique, un zkVM peut s’exécuter sur le cloud. Fondamentalement, le coprocesseur ZK est une architecture visant à déplacer les calculs de la chaîne vers l’extérieur, sans imposer de restriction quant au fournisseur de ressources hors chaîne.
En réalité, ces ressources peuvent provenir de grands fournisseurs traditionnels, de réseaux de calcul décentralisés, voire d’appareils locaux. Ces trois directions présentent des différences notables : les grands acteurs traditionnels offrent des solutions matures, tandis que les ressources de calcul décentralisées pourraient offrir une robustesse accrue à l’avenir. Le calcul local ouvre également des perspectives intéressantes. Pour l’instant, de nombreux projets de coprocesseurs ZK choisissent de rester fermés, car l’écosystème n’est pas encore structuré, empêchant une spécialisation fine des services. Deux scénarios possibles se dessinent à l’horizon :
-
Une multitude de projets compétitifs émergera à chaque niveau de la chaîne.
-
Un seul projet, offrant une excellente expérience utilisateur, dominera une grande partie du marché.
Du point de vue des développeurs, l’utilisation d’un coprocesseur ZK se fera probablement via un seul projet « interface », comme Amazon Web Services domine aujourd’hui le cloud. Les développeurs tendent à adopter une méthode de déploiement unique. Toutefois, la nature du fournisseur de calcul sous-jacent à cette interface — nuage traditionnel ou ressources partagées décentralisées — reste une question cruciale pour l’avenir du secteur.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
Kernel Ventures
