Qu’est-ce qu’un coprocesseur ZK et son rôle dans DeFi

Qu’est-ce qu’un coprocesseur ZK ?

Un coprocesseur ZK est un système qui effectue des calculs en dehors d’une blockchain, puis produit une preuve que ces calculs ont été réalisés correctement. ZK signifie zero-knowledge, une famille de techniques cryptographiques qui peuvent prouver une affirmation sans révéler toutes les informations utilisées pour l’établir. Dans de nombreuses conceptions de coprocesseurs, la propriété utile n’est pas seulement la confidentialité. C’est la vérifiabilité.

Imaginez qu’un smart contract demande : ce wallet faisait-il partie des principaux utilisateurs d’un protocole au bloc N ? Un compte détenait-il au moins un certain solde pendant une période passée ? Un pool est-il resté sous un seuil de risque sur des milliers de blocs ? Un contrat classique peut ne pas être en mesure de répondre à ces questions à faible coût, car les blockchains sont conçues pour exécuter des transitions d’état actuelles, pas pour analyser à répétition l’intégralité de leur historique.

Un coprocesseur ZK lit ou reçoit des données historiques de blockchain, effectue le calcul demandé hors chaîne et renvoie un résultat accompagné d’une preuve. Un contrat vérificateur contrôle cette preuve à l’aide de règles cryptographiques. Si la preuve est valide, le contrat peut agir sur le résultat sans accepter une simple affirmation venant de l’opérateur d’un serveur.

Il est préférable de le comprendre comme un ordinateur externalisé vérifiable pour les données de blockchain. Il ne rend pas un contrat omniscient, et il ne rend pas automatiquement une application privée, décentralisée ou bon marché. Ces propriétés dépendent de la source de données, du circuit ou de la machine virtuelle, du système de preuve, du vérificateur et de la conception économique autour du service.

Les principaux risques et modes de défaillance

Le mot preuve peut sembler plus absolu qu’il ne l’est. Une preuve valide établit généralement qu’un calcul défini a été effectué correctement sur des entrées définies, dans le cadre d’un système de preuve défini. Elle ne prouve pas que le développeur a choisi la bonne question, récupéré la bonne chaîne, interprété correctement un contrat ou construit une application sûre autour de la réponse.

L’hypothèse technique centrale est la solidité du système de preuve. La solidité est la propriété qui rend irréalisable la création d’une preuve semblant valide pour une affirmation fausse. Si la cryptographie, l’implémentation, le circuit, le contrat vérificateur ou la configuration de confiance présente une faille grave, un attaquant peut être capable de soumettre un résultat incorrect que le contrat accepte. L’étiquette zero-knowledge ne remplace pas l’audit de ces composants.

Il existe aussi des risques d’infrastructure ordinaires. Un prouveur peut devenir indisponible, un fournisseur de données peut renvoyer un historique incomplet, un service peut ne prendre en charge que certaines chaînes, ou un contrat peut dépendre d’un coordinateur pour soumettre les preuves. Certains systèmes réduisent la confiance accordée à une multisig tout en dépendant encore d’opérateurs pour la disponibilité, l’accès aux données, le paiement des frais ou les mises à jour logicielles. Les clés de gouvernance et les autorisations de mise à niveau méritent le même examen que le système de preuve.

Le mode de défaillance financier est particulièrement important dans la DeFi. Un calcul historique défectueux pourrait mal évaluer un collatéral, distribuer des récompenses aux mauvais comptes, déclencher des liquidations ou approuver un mauvais prêt. Une preuve peut montrer que le code s’est exécuté comme prévu, tandis que le code lui-même contient une erreur économique. Les utilisateurs devraient donc examiner les audits, les adresses des vérificateurs, les contrôles de mise à niveau, les sources de données prises en charge et les procédures d’urgence avant de considérer qu’une application adossée à un coprocesseur est plus sûre qu’une application classique.

Comment il prouve les données historiques de la chaîne

Le fonctionnement de base comporte plusieurs étapes. D’abord, une application définit une requête et les données dont elle a besoin. La requête peut porter sur des soldes, des swaps, des positions de liquidité, une activité de prêt ou des engagements d’état enregistrés dans des blocs Ethereum antérieurs. Le système obtient ensuite les en-têtes de blocs, les données de transaction, les reçus et les informations d’état pertinents, selon ce que le calcul exige.

Ensuite, un travailleur hors chaîne exécute le programme demandé. Ce programme peut être un circuit spécialisé ou une machine virtuelle à connaissance zéro à usage général, souvent appelée zkVM. Une zkVM permet aux développeurs d’exprimer la logique dans un environnement de programmation plus familier, tandis que le système convertit l’exécution dans une forme pouvant être prouvée. Le résultat comprend à la fois une réponse et une preuve liées aux données d’entrée et au programme.

Le vérificateur sur chaîne ne rejoue généralement pas chaque transaction historique. Il vérifie une preuve compacte à l’aide d’une clé de vérification et d’entrées publiques comme un identifiant de bloc, un engagement de données, les paramètres de la requête et le résultat revendiqué. Si la preuve est acceptée, un contrat peut stocker le résultat ou l’utiliser immédiatement. Le contrat doit tout de même valider que le bloc et l’engagement d’état signifient bien ce que l’application attend.

L’accès aux données historiques est plus compliqué que le simple fait de demander un nombre à un nœud. Un solde peut dépendre du stockage d’un contrat à un bloc précis. Une métrique pondérée dans le temps peut nécessiter de nombreux instantanés d’état. Un résultat fondé sur des logs peut manquer des informations qui n’ont pas été émises sous forme d’événement. Le système doit définir s’il prouve des données de nœud d’archive, une représentation indexée, un engagement de bloc ou une autre source. Ces choix influencent à la fois l’exactitude et la confiance.

Ce qu’une preuve affirme réellement

Supposons qu’un contrat reçoive une affirmation selon laquelle une adresse a fourni de la liquidité pendant au moins 100 jours avant un bloc choisi. La preuve peut établir qu’un programme spécifié a examiné des entrées spécifiées et a abouti à ce résultat. Elle n’établit pas indépendamment que la question est une mesure utile de fidélité, que l’adresse est contrôlée par une seule personne ou que l’application devrait verser une récompense.

C’est pourquoi les requêtes reproductibles et les engagements d’entrée transparents sont importants. Les développeurs devraient pouvoir identifier la chaîne, la plage de blocs, les adresses de contrats, la version du programme et les hypothèses derrière un résultat. Sans ce contexte, une preuve peut être mathématiquement valide, mais difficile à interpréter pour les utilisateurs.

Coprocesseur ou rollup

Un rollup est un système de mise à l’échelle qui exécute des lots de transactions en dehors de la chaîne principale et publie suffisamment de données ou d’engagements pour que la chaîne de base puisse vérifier ou reconstruire l’état résultant. Son rôle principal est de fournir un espace où les utilisateurs peuvent effectuer des transactions, le rollup maintenant son propre état de comptes et d’applications. Un ZK rollup utilise des preuves de validité pour montrer que sa transition d’état a été exécutée conformément à ses règles.

Un coprocessor a une mission différente. Il ne maintient généralement pas l’état canonique des comptes pour un nouvel environnement de transaction, et il n’est pas principalement un lieu où les utilisateurs déposent des actifs et exécutent des appels d’application ordinaires. Il effectue des calculs sélectionnés sur des données qui existent déjà sur une blockchain, puis renvoie un résultat et une preuve à un contrat sur cette chaîne.

La frontière peut devenir floue. Un rollup peut utiliser un service de type coprocessor pour l’analyse, et un coprocessor peut utiliser une infrastructure de preuve de type rollup ou une zkVM. La question pratique n’est pas de savoir quelle étiquette apparaît dans une présentation commerciale. Il faut plutôt se demander si le système est responsable de l’ordonnancement et du règlement des transactions des utilisateurs dans son propre environnement d’exécution, ou s’il répond à des requêtes vérifiables sur l’historique d’une autre chaîne.

Pour les utilisateurs, cette différence modifie la surface de risque. Un rollup soulève des questions sur la garde des bridges, la disponibilité des données, le comportement du séquenceur, les retraits et l’exactitude de l’état. Un coprocessor soulève des questions sur les entrées de requête, la solidité de la preuve, la couverture des données historiques, la disponibilité du prouveur et la capacité du contrat de destination à traiter le résultat en toute sécurité. Aucune des deux catégories n’élimine toute confiance ni tout risque opérationnel.

En quoi il diffère d’un oracle

Un oracle fournit à un smart contract des informations que le contrat ne peut pas obtenir directement. Les flux de prix en sont l’exemple familier. Un réseau d’oracles peut agréger les prix de ETH provenant d’exchanges et publier une valeur pour les marchés de prêt. Le contrat fait confiance à la conception de l’oracle, aux rapporteurs participants, à la méthode d’agrégation et aux protections contre la manipulation.

Un ZK coprocessor prouve généralement un calcul à partir de données blockchain spécifiées. Il peut prouver qu’une adresse a interagi avec un protocole, que l’exposition historique d’un coffre a franchi un seuil ou qu’un ensemble de transactions respecte une règle. La preuve répond à la question de savoir si un calcul a correctement suivi ses entrées. Elle ne prouve pas automatiquement qu’un prix de marché externe, une identité réelle ou un fait juridique est vrai.

Les deux systèmes peuvent fonctionner ensemble. Un oracle peut fournir une entrée de prix signée ou autrement authentifiée, et un coprocessor peut prouver un calcul de risque qui utilise cette entrée avec des positions historiques sur chaîne. Dans cette conception, la preuve peut protéger le calcul, tandis que l’oracle reste un point de confiance pour les données du monde extérieur.

Il existe aussi un avertissement utile à propos de l’expression trustless. Une preuve peut réduire la dépendance à un multisig ou à un serveur unique pour le calcul, mais elle ne peut pas prouver des faits qui n’ont jamais été représentés dans ses entrées. Si une application a besoin d’un justificatif du monde réel, d’un prix d’exchange actuel ou d’une revendication juridique, elle a toujours besoin d’un mécanisme d’attestation ou d’oracle approprié.

Que peuvent construire les développeurs avec un tel outil ?

L’avantage le plus immédiat est un calcul moins coûteux ou plus expressif. Les contrats Ethereum paient l’exécution avec du gas, et parcourir de longs historiques ou traiter de grands ensembles de données directement sur chaîne peut être impraticable. Un coprocessor déplace le travail lourd hors chaîne tout en conservant une étape de vérification compacte sur chaîne. Le coût total inclut tout de même la preuve, la récupération des données, la soumission de la preuve et parfois des frais de service, donc moins cher ne signifie pas gratuit.

Moteurs de risque DeFi

Un protocole de prêt pourrait utiliser des positions historiques pour estimer la concentration, le comportement de liquidation ou la relation d’un emprunteur avec d’autres marchés. Un coffre pourrait vérifier une fenêtre de risque plus longue que ce que son code sur chaîne peut traiter efficacement. Un système de récompenses pourrait calculer la participation sur de nombreux blocs sans stocker chaque valeur intermédiaire sur chaîne.

Ces usages sont précieux parce que les applications DeFi ont souvent besoin de contexte plutôt que d’un seul nombre actuel. Mais les modèles de risque ne deviennent pas corrects parce qu’ils sont prouvés. Les développeurs doivent toujours choisir des hypothèses robustes, tenir compte des données manquantes et du comportement lié aux flash-loans, et définir la réaction du protocole lorsqu’une preuve est retardée ou indisponible.

Identité privée et éligibilité

Un utilisateur pourrait prouver une affirmation limitée concernant un justificatif plus large sans révéler le justificatif lui-même. Par exemple, une application pourrait vérifier qu’une personne respecte une exigence d’âge ou de juridiction, ou qu’un wallet satisfait une règle de participation, tout en limitant les informations exposées au contrat. Le caractère réellement privé dépend de l’émetteur du justificatif, du wallet, des métadonnées, du processus de révocation et de ce que l’application enregistre publiquement.

L’activité sur chaîne est souvent corrélable même lorsqu’une preuve masque certaines entrées. Une preuve privée ne garantit pas des transactions privées, un réseau anonyme ni une protection contre toute forme d’analyse. Les systèmes d’identité se heurtent aussi au problème consistant à prouver qu’une personne ne contrôle qu’une seule identité éligible, ce que la cryptographie seule ne résout pas.

Calcul peu coûteux et requêtes complexes

Le calcul général est une autre cible. Un développeur peut vouloir exécuter une logique de réputation, des analyses de portefeuille, des calculs de gouvernance ou des règles de jeu sur l’historique de la blockchain. Un système à usage général peut réduire la difficulté d’expression de ces tâches par rapport à l’écriture de chaque opération sous forme de contrat sur chaîne.

Axiom se concentre sur les requêtes vérifiables portant sur les données blockchain. RISC Zero propose une approche zkVM à usage général capable de prouver des programmes exécutés dans un environnement RISC-V. Succinct développe une infrastructure et des outils de preuve, notamment sa zkVM SP1. Ces projets illustrent un vaste espace de conception plutôt qu’un produit standardisé unique. Leurs performances, entrées prises en charge, modèles de déploiement et garanties de production peuvent différer considérablement, donc le nom d’un projet ne constitue pas à lui seul la preuve qu’une intégration particulière est sûre ou mature.

Limites actuelles : coût de preuve, latence et adoption

Le calcul des preuves est gourmand en ressources. Une requête peu coûteuse pour un serveur classique peut exiger beaucoup de matériel, de mémoire et de travail d’ingénierie lorsque chaque étape pertinente doit être représentée dans une preuve. Des plages historiques plus larges, des programmes complexes, des opérations cryptographiques et de nombreux utilisateurs simultanés peuvent augmenter le temps de génération des preuves et les coûts d’exploitation.

La latence compte également. Un appel de contrat qui nécessite une réponse immédiate peut ne pas être compatible avec une preuve qui prend plusieurs minutes, voire plus, à générer. Certaines applications peuvent tolérer des mises à jour asynchrones. D’autres ont besoin d’une solution de repli, d’un résultat mis en cache, d’une période optimiste ou d’une action conservatrice pendant qu’une preuve est en attente. Ces contournements introduisent de nouveaux choix de conception et parfois de nouvelles hypothèses de confiance.

La disponibilité des données et l’indexation restent des goulots d’étranglement pratiques. Un prouveur peut avoir besoin d’un accès à des archives, d’index spécialisés ou d’engagements prétraités. Si une chaîne se réorganise, modifie un format de données ou présente une couverture historique incomplète, l’application a besoin d’une politique claire. La preuve n’est utile que dans la mesure où les données que le programme a réellement pu consommer le sont.

L’expérience développeur s’améliore, mais l’écriture de circuits ou de programmes zkVM exige encore des connaissances spécialisées. Des bugs peuvent provenir du code applicatif, de la traduction sous une forme prouvable, de la gestion des entrées publiques et privées, ou de l’intégration du vérificateur. Les audits aident, mais ils ne sont pas des garanties. Le code open source, les builds reproductibles, la vérification indépendante, les bug bounties et des limites conservatrices sont des signaux importants à examiner.

Ce que cela signifie pour les utilisateurs et les builders

Pour les builders, commencez par l’affirmation exacte que le contrat doit vérifier. Définissez le bloc, la chaîne, les engagements de données, la version du programme, la fraîcheur acceptable et le comportement à adopter si la preuve ne peut pas être produite. Comparez ensuite un coprocesseur avec des options plus simples, comme le stockage d’un agrégat glissant, l’utilisation d’un oracle établi ou l’exécution du calcul directement on-chain. L’architecture la plus avancée n’est pas automatiquement la meilleure.

Pour les utilisateurs, ne vous arrêtez pas à l’expression ZK-powered. Cherchez à savoir si le produit a une véritable utilisation sur mainnet ou s’il s’agit principalement d’une démonstration. Vérifiez quelles parties sont open source, qui peut mettre à niveau le vérificateur, si un coordinateur peut censurer ou retarder les preuves, comment les données historiques sont sourcées et ce qui se passe après un résultat incorrect. Si un protocole accepte des dépôts importants, examinez les audits et l’historique des incidents plutôt que de vous fier à une image de marque cryptographique.

Il est également utile de distinguer trois questions. Le système peut-il calculer le résultat demandé ? Peut-il prouver ce résultat de manière fiable ? L’application utilisera-t-elle ce résultat en toute sécurité dans des conditions adverses ? Une réponse convaincante à la première question ne règle pas les deux autres.

En tant que lecteur avancé, vous pouvez aussi comparer ce sujet avec le fonctionnement du scaling d’Ethereum et ce que sont les preuves zero-knowledge. Ces concepts expliquent pourquoi la génération de preuves peut réduire le travail de vérification on-chain tout en exigeant des choix prudents concernant les données, le calcul et la confiance.

Lisez les affirmations sur les coprocesseurs ZK avec esprit critique

Les coprocesseurs ZK évoluent vite, et les affirmations à leur sujet évoluent souvent encore plus vite. Suivre manuellement les publications techniques, les intégrations et l’actualité de la sécurité est difficile. Zippfeed met en avant les titres pertinents avec une notation de sentiment bullish, neutral ou bearish et une note d’importance, afin de vous aider à distinguer un déploiement réel en production d’un prototype, d’une annonce de partenariat ou d’un risque non résolu. Utilisez ce contexte pour suivre la technologie sans considérer la couverture comme une recommandation d’acheter ou d’utiliser un projet.