ABCDE Rapport de recherche : Analyse approfondie des coprocesseurs et des solutions proposées par différents acteurs
TechFlow SélectionTechFlow Sélection
ABCDE Rapport de recherche : Analyse approfondie des coprocesseurs et des solutions proposées par différents acteurs
Présenter de manière systématique une comparaison des solutions techniques proposées par plusieurs acteurs du marché dans le domaine des processeurs secondaires (coprocesseurs), dans l'objectif d'offrir au marché et aux utilisateurs une compréhension plus claire de ce secteur.
Dédié à des analyses Web3 approfondiesRédaction : Kris & Laobai ABCDE / Mo Dong Celer Network
Ces derniers mois, le concept de coprocesseur a connu un fort engouement, attirant une attention croissante autour de ce nouveau cas d’usage des ZK.
Pourtant, nous constatons que la plupart des personnes restent encore peu familières avec cette notion, notamment quant à sa définition précise — ce qu’est et ce que n’est pas un coprocesseur. En outre, aucune synthèse systématique n’a encore été réalisée concernant les différentes solutions techniques proposées par les acteurs du secteur. Cet article vise donc à offrir au marché et aux utilisateurs une compréhension plus claire de l’écosystème des coprocesseurs.
I. Qu'est-ce qu’un coprocesseur (co-processor), et qu’est-ce qu’il n’est pas ?
Si vous deviez expliquer ce qu’est un coprocesseur en une seule phrase à une personne non technique, comment vous y prendriez-vous ?
La formulation du Dr Dong Mo s’en rapproche probablement beaucoup : « Un coprocesseur, c’est simplement donner aux contrats intelligents les capacités de Dune Analytics. »
Comment décomposer cette affirmation ?
Imaginez votre utilisation typique de Dune : vous souhaitez devenir fournisseur de liquidités (LP) sur Uniswap V3 pour gagner des frais de transaction. Vous ouvrez alors Dune pour consulter récemment les volumes d’échanges sur divers paires, les APR (taux annuels) des frais sur 7 jours, les fourchettes de fluctuation des principales paires, etc.
Ou bien, lorsque StepN était en vogue, vous spéculiez sur les chaussures, mais hésitiez sur le moment opportun pour vendre. Chaque jour, vous surveilliez donc les données StepN sur Dune : volume quotidien des transactions, nombre d’utilisateurs nouveaux, prix plancher des chaussures… attendant le moindre signe de ralentissement ou de baisse pour fuir rapidement.
Bien entendu, ces données ne sont pas uniquement observées par vous ; les équipes de développement d’Uniswap et de StepN y prêtent également une grande attention.
Ces données ont une grande valeur — elles permettent non seulement d’anticiper les tendances, mais aussi d’imaginer de nouvelles fonctionnalités, à l’instar des grandes entreprises Internet qui exploitent massivement le « big data ».
Par exemple, recommander automatiquement des chaussures similaires selon les styles et prix habituellement achetés par un utilisateur.
Ou encore, mettre en place un programme de fidélité basé sur la durée de détention d’une chaussure « génèse », en attribuant davantage d’airdrops ou d’avantages aux utilisateurs loyaux.
Ou bien concevoir un système VIP similaire à ceux des CEX, en réduisant les frais de transaction pour les traders ou en augmentant la part des frais perçus par les LP, en fonction du TVL apporté ou du volume d’échanges.
Mais voilà : dans le Web2, ces usages de big data + IA reposent sur des « boîtes noires ». Personne ne voit ce qui se passe à l’intérieur, et cela importe peu aux utilisateurs.
Dans le monde Web3, en revanche, la transparence et la confiance minimale sont des principes fondamentaux. Nous rejetons catégoriquement les boîtes noires !
Ainsi, quand vous tentez de réaliser ces scénarios, vous êtes confronté à un dilemme : soit utiliser une méthode centralisée, en récupérant manuellement via Dune les données indexées, puis en les appliquant via backend ; soit écrire un contrat intelligent capable de récupérer automatiquement ces données directement sur la blockchain, de calculer, puis de distribuer.
La première option pose un problème de confiance — elle est politiquement incorrecte dans le Web3.
La seconde entraînerait des frais de gaz astronomiques, incompatibles avec toute viabilité économique, même pour une équipe projet.
C’est précisément là qu’intervient le coprocesseur : combiner ces deux approches tout en remplaçant l’étape « manuelle » par une preuve technique vérifiable. Autrement dit, utiliser la technologie ZK pour prouver de manière irréfutable l’intégrité de l’indexation et du calcul hors chaîne, puis transmettre ce résultat au contrat intelligent. Ainsi, le problème de confiance disparaît, tout comme les frais de gaz exorbitants. Parfait !
Pourquoi parler de « coprocesseur » ? Ce terme provient de l’histoire du Web2.0, avec l’apparition du GPU. Celui-ci a été introduit comme composant de calcul distinct du CPU, car son architecture permettait de traiter efficacement des tâches que le CPU ne pouvait gérer efficacement — telles que les calculs massivement parallèles ou le rendu graphique. Grâce à cette architecture de coprocesseur, nous avons pu bénéficier de films d’animation spectaculaires, de jeux vidéo immersifs, de modèles d’IA performants, etc. Cette avancée a marqué une rupture majeure dans l’architecture informatique. Les équipes de coprocesseurs aujourd’hui souhaitent reproduire ce schéma dans le Web3.0 : ici, la blockchain joue le rôle du CPU. Que ce soit L1 ou L2, elles sont structurellement mal adaptées aux tâches exigeantes en données et en logique de calcul complexe. Le coprocesseur intervient donc comme une unité spécialisée, étendant ainsi considérablement les possibilités applicatives de la blockchain.
En résumé, un coprocesseur accomplit deux tâches essentielles :
-
Extraire des données depuis la blockchain, puis générer une preuve ZK attestant que ces données sont authentiques et non falsifiées ;
-
Effectuer des calculs à partir de ces données, puis produire une nouvelle preuve ZK garantissant que le résultat du calcul est exact et non manipulé, permettant ainsi aux contrats intelligents d’utiliser ce résultat de manière « peu coûteuse et sans confiance ».
Il y a quelque temps, Starkware a popularisé un concept appelé « Storage Proof » (preuve de stockage), aussi nommé « State Proof ». Ce concept correspond essentiellement à l’étape 1 décrite ci-dessus. Des projets comme Herodotus ou Lagrange en sont des exemples représentatifs. De nombreux ponts cross-chain basés sur la technologie ZK mettent également l’accent sur cette étape 1.
Le coprocesseur ajoute simplement une étape 2 à cela : après avoir extrait les données de façon fiable, il effectue un calcul lui aussi vérifiable sans confiance.
Ainsi, pour être plus technique, on peut dire que le coprocesseur est un sur-ensemble du Storage Proof / State Proof, et un sous-ensemble du calcul vérifiable (Verifiable Computation).
Il est important de noter qu’un coprocesseur n’est pas un Rollup.
D’un point de vue technique, la preuve ZK d’un Rollup ressemble à l’étape 2 décrite plus haut. Quant à l’étape 1 (« récupération des données »), elle est réalisée directement par le Séquenceur. Même dans une version décentralisée du séquenceur, celui-ci récupère les données via un mécanisme de concurrence ou de consensus, et non sous forme de Storage Proof basé sur ZK. Plus important encore, un ZK Rollup doit implémenter, en plus de la couche de calcul, une couche de stockage permanente similaire à celle d’une blockchain L1. En revanche, un ZK Coprocessor est « sans état » : une fois le calcul terminé, il n’a pas besoin de conserver tous les états intermédiaires.
Sur le plan des cas d’usage, un coprocesseur peut être vu comme un plugin de service pour toutes les couches L1/L2, tandis qu’un Rollup crée une couche d’exécution indépendante destinée à agrandir la capacité de la couche de règlement.
II. Pourquoi utiliser obligatoirement ZK ? L’approche OP (optimiste) ne suffirait-elle pas ?
Après lecture de ce qui précède, vous vous demandez peut-être : faut-il absolument utiliser ZK pour construire un coprocesseur ? Cela ressemble fortement à une version « ZK-enhanced » du Graph. Or, nous n’avons généralement pas grand soupçon quant aux résultats fournis par The Graph.
C’est vrai, mais c’est parce que lorsqu’on utilise The Graph, cela concerne rarement de véritables enjeux financiers. Ces index servent principalement à des services hors chaîne. Les données que vous voyez sur l’interface utilisateur — volumes d’échanges, historiques de transactions, etc. — peuvent provenir de plusieurs fournisseurs comme Graph, Alchemy ou Zettablock. Mais ces données ne peuvent pas être réinjectées dans un contrat intelligent, car cela introduirait une dépendance supplémentaire envers ce service d’indexation. Dès lors que les données sont liées à de l’argent réel, surtout à de gros montants de TVL, cette dépendance devient critique. Imaginez qu’un ami vous emprunte 100 dollars : vous acceptez sans hésiter. Mais si c’est 10 000, voire 1 million ?
Mais alors, est-ce que tous les cas d’usage des coprocesseurs exigent vraiment du ZK ? Dans les Rollups, nous avons bien deux voies technologiques : OP et ZK. Récemment, le concept populaire de ZKML a vu émerger une branche alternative, l’OPML. Ne pourrait-on imaginer un « coprocesseur OP », un OP-Coprocessor ?
Eh bien, oui, cela existe bel et bien — mais pour l’instant, nous gardons les détails confidentiels. De plus amples informations seront bientôt publiées.
III. Comparaison des principales solutions techniques de coprocesseurs disponibles sur le marché
Brevis
L’architecture de Brevis repose sur trois composants : zkFabric, zkQueryNet et zkAggregatorRollup.
Voici un schéma d’architecture de Brevis :
zkFabric : collecte les en-têtes de blocs depuis toutes les blockchains connectées et génère des preuves ZK de leur validité (preuves de consensus). Grâce à zkFabric, Brevis permet un coprocesseur interopérable entre chaînes, autorisant une blockchain à accéder aux données historiques arbitraires d’une autre.
zkQueryNet : un marché ouvert de moteurs de requêtes ZK, capable de recevoir et traiter des requêtes de données provenant de dApps. Ces requêtes sont traitées à l’aide des en-têtes validés par zkFabric, générant des preuves ZK de requête. Ces moteurs offrent à la fois des fonctions très spécialisées et un langage de requête généraliste, répondant ainsi à divers besoins applicatifs.
zkAggregatorRollup : une blockchain ZK de type rollup, servant de couche d’agrégation et de stockage pour zkFabric et zkQueryNet. Elle vérifie les preuves provenant de ces deux composants, stocke les données validées, et soumet la racine d’état vérifiée par ZK à toutes les blockchains connectées.
zkFabric, chargé de générer les preuves des en-têtes de blocs, est une composante critique dont la sécurité est primordiale. Voici son architecture :
zkFabric repose sur des clients légers basés sur les preuves à divulgation nulle (ZKP), entièrement sans confiance, sans dépendre d’aucune entité externe de validation. Sa sécurité découle directement de la blockchain sous-jacente et des preuves mathématiquement solides.
Le réseau zkFabric Prover implémente des circuits pour le protocole de client léger de chaque blockchain, générant ainsi des preuves de validité des en-têtes de blocs. Les prouveurs peuvent utiliser des accélérateurs comme GPU, FPGA ou ASIC afin de minimiser le temps et le coût de génération des preuves.
zkFabric repose sur les hypothèses de sécurité de la blockchain et du protocole cryptographique sous-jacent. Toutefois, pour assurer son efficacité, au moins un relayeur honnête doit synchroniser la bonne branche (fork). Ainsi, zkFabric adopte un réseau de relayeurs décentralisé plutôt qu’un seul relayeur, optimisant ainsi sa fiabilité. Ce réseau peut tirer parti de structures existantes, telles que le State Guardian Network de Celer.
Répartition des prouveurs :
Le réseau de prouveurs est décentralisé. Une tâche de génération de preuve nécessite de sélectionner un prouveur parmi le réseau, et de le rémunérer.
Déploiements actuels :
Des prototypes ont été mis en œuvre pour diverses blockchains, notamment Ethereum PoS, Cosmos Tendermint et BNB Chain, à titre de preuve de concept.
Brevis collabore actuellement avec uniswap hook. Bien que hook permette de personnaliser largement les pools Uniswap, comparé aux CEX, Uniswap manque toujours de fonctionnalités efficaces de traitement des données, par exemple pour créer des programmes de fidélité basés sur le volume des transactions.
Grâce à Brevis, hook résout ce défi. Il peut désormais lire les données historiques complètes des utilisateurs ou LP, et exécuter des calculs personnalisés de manière totalement sans confiance.
Herodotus
Herodotus est un middleware puissant d’accès aux données, offrant aux contrats intelligents un accès synchronisé, en temps réel et historique aux données de la couche Ethereum :
-
États L1 depuis les L2
-
États L2 depuis les L1 et autres L2
-
États L3/App-Chain vers les L2 et L1
Herodotus introduit le concept de « preuve de stockage » (Storage Proof), combinant preuve d’inclusion (confirmation de l’existence des données) et preuve de calcul (validation de l’exécution d’un workflow multi-étapes), afin de prouver la validité d’un ou plusieurs éléments au sein de grands ensembles de données (comme l’ensemble de la blockchain Ethereum ou un rollup).
Au cœur des blockchains se trouve une base de données dont les données sont protégées cryptographiquement via des structures comme l’arbre de Merkle ou l’arbre de Merkle-Patricia. Leur particularité réside dans la possibilité de produire des preuves confirmant qu’une donnée est bien incluse dans la structure, une fois qu’elle y a été insérée de manière sécurisée.
L’utilisation des arbres de Merkle et Merkle-Patricia renforce la sécurité d’Ethereum. En hachant cryptographiquement les données à chaque niveau de l’arbre, toute modification devient presque impossible à passer inaperçue. Toute altération d’un point de données exige de modifier les hachages correspondants jusqu’à la racine, visible publiquement dans l’en-tête du bloc. Cette caractéristique fondamentale assure un haut niveau d’intégrité et d’immuabilité des données.
Ensuite, ces arbres permettent une vérification efficace des données via des preuves d’inclusion. Par exemple, pour vérifier qu’une transaction est incluse ou qu’un état de contrat est valide, il n’est pas nécessaire de parcourir toute la blockchain Ethereum : il suffit de valider le chemin dans l’arbre de Merkle pertinent.
La preuve de stockage définie par Herodotus combine :
-
Preuve d’inclusion : confirme l’existence d’une donnée spécifique dans une structure cryptographique (ex. arbre de Merkle), garantissant qu’elle appartient bien au jeu de données.
-
Preuve de calcul : vérifie l’exécution d’un workflow multi-étapes, attestant de la validité d’un ou plusieurs éléments dans un vaste ensemble de données (ex. blockchain Ethereum ou rollup). Elle va au-delà de l’existence, en validant les transformations ou opérations appliquées à ces données.
-
Preuve à divulgation nulle (ZK) : réduit la quantité de données que le contrat intelligent doit traiter. Elle permet de confirmer la validité d’une assertion sans révéler ni traiter toutes les données sous-jacentes.
Workflow :
1. Obtenir le hachage du bloc
Chaque donnée sur la blockchain appartient à un bloc spécifique. Le hachage du bloc sert d’identifiant unique, résumant tout son contenu via l’en-tête. Dans le processus de preuve de stockage, la première étape consiste à identifier et valider le hachage du bloc contenant les données recherchées.
2. Obtenir l’en-tête du bloc
Une fois le hachage du bloc obtenu, l’étape suivante consiste à accéder à l’en-tête du bloc. On calcule alors le hachage de cet en-tête, puis on le compare au hachage du bloc obtenu précédemment :
Deux méthodes permettent d’obtenir le hachage :
(1) Utiliser l’opcode BLOCKHASH pour le récupérer
(2) Interroger l’accumulateur de hachages de blocs (Block Hash Accumulator) pour obtenir les hachages historiques déjà vérifiés
Cette étape garantit que l’en-tête du bloc traité est authentique. Une fois terminée, le contrat intelligent peut accéder à toutes les valeurs présentes dans l’en-tête.
3. Identifier la racine requise (facultatif)
Avec l’en-tête du bloc, on peut explorer son contenu, notamment :
stateRoot : résumé cryptographique de l’état complet de la blockchain à ce moment.
receiptsRoot : résumé cryptographique de tous les résultats (reçus) des transactions du bloc.
transactionsRoot : résumé cryptographique de toutes les transactions du bloc.
Ces racines peuvent être décodées pour vérifier la présence d’un compte, d’un reçu ou d’une transaction spécifique dans le bloc.
4. Vérifier les données selon la racine choisie (facultatif)
Avec la racine choisie, et sachant qu’Ethereum utilise une structure de type Merkle-Patricia Trie, on peut utiliser la preuve d’inclusion de Merkle pour vérifier la présence des données dans l’arbre. Les étapes de vérification varient selon la profondeur des données dans le bloc.
Réseaux supportés actuellement :
-
D’Ethereum vers Starknet
-
D’Ethereum Goerli* vers Starknet Goerli*
-
D’Ethereum Goerli* vers zkSync Era Goerli*
Axiom
Axiom permet aux développeurs d’interroger les en-têtes de blocs, les comptes ou les valeurs de stockage à partir de tout l’historique d’Ethereum. Axiom introduit une nouvelle méthode basée sur un lien cryptographique. Tous les résultats retournés par Axiom sont vérifiés en chaîne via des preuves à divulgation nulle, ce qui signifie que les contrats intelligents peuvent les utiliser sans hypothèse de confiance supplémentaire.
Axiom a récemment publié Halo2-repl, un environnement REPL Halo2 basé sur navigateur, écrit en JavaScript. Cela permet aux développeurs d’écrire des circuits ZK en JavaScript standard, sans avoir à apprendre Rust, installer des bibliothèques de preuve ou gérer des dépendances.
Axiom repose sur deux composants techniques principaux :
- AxiomV1 — cache de la blockchain Ethereum depuis le bloc de genèse.
- AxiomV1Query — contrat intelligent exécutant des requêtes sur AxiomV1.
(1) Mise en cache des hachages de blocs dans AxiomV1 :
Le contrat AxiomV1 met en cache les hachages de blocs d’Ethereum depuis le genèse, sous deux formes :
Premièrement, il met en cache les racines Merkle Keccak de groupes successifs de 1024 blocs. Ces racines Merkle sont mises à jour via des preuves ZK, qui vérifient que les en-têtes de blocs forment une chaîne de promesses aboutissant à un bloc parmi les 256 plus récents accessibles directement par l’EVM, ou déjà présent dans le cache AxiomV1.
Deuxièmement, Axiom stocke en chaîne une Merkle Mountain Range (MMR) des racines Merkle susmentionnées, construite à partir des racines Keccak mises en cache.
(2) Exécution des requêtes dans AxiomV1Query :
Le contrat AxiomV1Query permet d’effectuer des requêtes groupées, offrant un accès sans confiance à des données arbitraires historiques d’Ethereum : en-têtes de blocs, comptes, stockage. Les requêtes sont exécutées en chaîne et validées par des preuves ZK basées sur le cache AxiomV1.
Ces preuves ZK vérifient si les données concernées sont directement dans l’en-tête du bloc, ou dans l’arbre des comptes ou de stockage du bloc, via des preuves d’inclusion (ou de non-inclusion) dans l’arbre Merkle-Patricia.
Nexus
Nexus cherche à exploiter les preuves à divulgation nulle pour construire une plateforme universelle de cloud computing vérifiable. Actuellement agnostique vis-à-vis de l’architecture machine, il supporte RISC-V, WebAssembly et EVM. Nexus utilise le système de preuve Supernova ; l’équipe a testé la génération de preuves avec seulement 6 Go de mémoire, et prévoit d’optimiser davantage pour permettre la génération de preuves sur des ordinateurs clients standards.
Plus précisément, l’architecture se divise en deux parties :
-
Nexus Zero : réseau de cloud computing décentralisé et vérifiable, soutenu par des preuves à divulgation nulle et un zkVM universel.
-
Nexus : réseau de cloud computing décentralisé et vérifiable, piloté par le calcul multipartite, la réplication d’état et une machine virtuelle WASM universelle.
Les applications Nexus et Nexus Zero peuvent être écrites en langages de programmation classiques. Rust est actuellement supporté, d’autres langages seront ajoutés ultérieurement.
Les applications Nexus s’exécutent sur un réseau de cloud computing décentralisé, qui constitue en soi une sorte de « blockchain serverless » générale directement connectée à Ethereum. Elles n’héritent donc pas directement de la sécurité d’Ethereum, mais en contrepartie, grâce à une échelle réseau réduite, bénéficient de capacités de calcul supérieures (calcul, stockage, entrées/sorties pilotées par événements). Elles s’exécutent sur un cloud dédié atteignant un consensus interne, fournissant des « preuves » de calcul vérifiable via une signature de seuil vérifiable sur Ethereum (plutôt qu’une véritable preuve ZK).
Les applications Nexus Zero, elles, héritent bien de la sécurité d’Ethereum, car ce sont des programmes universels accompagnés de preuves ZK, vérifiables en chaîne sur la courbe elliptique BN-254.
Étant donné que Nexus peut exécuter n’importe quel binaire WASM déterministe dans un environnement répliqué, il devrait servir de source de validité, de décentralisation et de tolérance aux pannes pour des applications de génération de preuves, notamment les séquenceurs de zk-rollup, les séquenceurs d’optimistic rollup, ou encore les prouveurs comme le zkVM de Nexus Zero lui-même.
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
ABCDE
