Les processeurs auxiliaires ZK de zéro à un : au-delà du paradigme piloté par les données, vers un modèle asynchrone pour le Web 3.0
TechFlow SélectionTechFlow Sélection
Les processeurs auxiliaires ZK de zéro à un : au-delà du paradigme piloté par les données, vers un modèle asynchrone pour le Web 3.0
Les coprocesseurs ZK permettent aux blockchains de déléguer ces calculs fastidieux et intensifs en données, obtenant rapidement des résultats à faible coût, sans hypothèse de confiance supplémentaire.
Dédié à des analyses Web3 approfondiesLes coprocesseurs ZK représentent une innovation passionnante dans le domaine de la blockchain. Initiés par des projets tels que Brevis, Axiom, Lagrange et Herodotus, ils promettent de révolutionner la manière dont nous développons des applications sur la blockchain. Grâce aux coprocesseurs ZK, les développeurs peuvent créer des dApps pilotées par les données, capables d'exploiter l'historique des données omnichain pour effectuer des calculs complexes, sans dépendre d'hypothèses de confiance supplémentaires. Plus important encore, ils inaugurent un nouveau modèle de développement : l'architecture d'applications asynchrone, apportant à l'écosystème logiciel Web 3.0 une efficacité et une évolutivité sans précédent.
Dans cette série d'articles, nous allons lever le voile sur les coprocesseurs ZK. Que vous soyez intéressé par leurs concepts fondamentaux, leurs cas d'utilisation pratiques, leurs mécanismes sous-jacents, les défis auxquels ils font face, leurs stratégies commerciales ou une comparaison entre différents projets, nous espérons que ces articles vous offriront de nouvelles perspectives.
L’absence de programmes VIP pour traders sur les DEX
Pour comprendre l'idée fondamentale des coprocesseurs ZK, commençons par un exemple concret tiré du monde réel.
Une différence notable entre les exchanges centralisés (CEX) et décentralisés (DEX) réside dans l'existence de systèmes tarifaires basés sur le volume d'échanges, communément appelés « programmes de fidélité VIP pour traders ». Ces programmes constituent des outils puissants pour fidéliser les traders, augmenter la liquidité et, en fin de compte, accroître les revenus des plateformes.
Ce qui est intéressant, c'est que tandis que chaque CEX dispose au moins d'un tel programme, les DEX en sont totalement dépourvus. Pourquoi ?
Parce qu'il est bien plus difficile et coûteux de mettre en œuvre cette fonctionnalité sur un DEX que sur un CEX.
Sur un CEX, la mise en place d’un programme de fidélité nécessite :
-
L’enregistrement de l’historique des transactions de tous les utilisateurs dans une base de données centralisée — une tâche facile et peu coûteuse à interroger par la suite.
-
L’exécution mensuelle d’une requête directe dans une base de données centralisée haute performance afin de déterminer, selon les données historiques, le volume d’échanges et le niveau de frais pour chaque utilisateur.
En revanche, lorsqu’un DEX tente de suivre ces mêmes étapes, il fait face à d’importants obstacles :
-
Le coût prohibitif du stockage sur la blockchain rend impossible le stockage direct de l’historique des transactions de chaque utilisateur dans un contrat intelligent. Implémenter une telle logique entraînerait des frais de transaction quatre fois plus élevés à chaque opération.
-
Même si les données étaient stockées, le coût de leur analyse statistique serait encore plus élevé. Par exemple, calculer le volume total de 10 000 transactions pour un seul utilisateur coûterait 156 millions de gas (oui, nous avons fait le calcul).
Vous pourriez objecter : « Attendez, de quoi parlez-vous exactement ? Sur la blockchain, toutes les transactions de chaque utilisateur sont automatiquement enregistrées (c’est la nature même de la blockchain !). Un contrat intelligent, natif de la blockchain, devrait donc pouvoir y accéder à tout moment, non ? »
Malheureusement, non !
Les données stockées sur la blockchain et celles accessibles aux contrats intelligents dans la machine virtuelle de la blockchain sont deux choses très différentes.
Pour les nœuds complets ou archivistes de la blockchain, une grande quantité de données historiques est conservée. À travers ces nœuds, vous pouvez facilement accéder à :
-
L’état complet de la blockchain à un instant donné dans le passé (par exemple, qui était le premier propriétaire d’un Cryptopunk).
-
Les transactions et événements générés par celles-ci à un moment donné (par exemple, Charlie a échangé 1 000 $ contre 0,5 ETH).
En effet, des outils populaires d’indexation ou d’analyse hors chaîne (comme Nansen ou Dune Analytics) exploitent précisément cet ensemble de données étendu pour réaliser des analyses approfondies.
Cependant, pour les contrats intelligents intégrés dans la machine virtuelle de la blockchain, l’accès aux données est fortement limité. Ils ne peuvent pas utiliser les données générées par des solutions d’indexation hors chaîne, car cela introduirait des problèmes de confiance supplémentaires vis-à-vis de ces sources externes, souvent centralisées.
En réalité, un contrat intelligent ne peut accéder rapidement et sans confiance qu’aux données suivantes :
-
Données stockées dans l’état de la machine virtuelle (sans inclure les transactions ni les événements).
-
Données du dernier bloc (l’accès aux données historiques est restreint).
-
Données d’autres contrats intelligents exposées via la fonction « view » (sans inclure les données privées ou internes).
La subtilité clé ici réside dans le mot « facilement ».
Les contrats intelligents ne sont pas totalement aveugles à l’ensemble des données de la blockchain. Dans l’EVM, par exemple, un contrat peut accéder aux hachages des en-têtes des 256 derniers blocs. Ces en-têtes contiennent toutes les activités de la blockchain jusqu’au bloc courant, condensées en un hachage de 32 octets via des arbres de Merkle et la fonction Keccak.
Ce qui est compressé peut être décompressé… seulement ce n’est pas facile 😂
Imaginez vouloir utiliser l’en-tête d’un bloc récent pour accéder sans confiance à une donnée spécifique dans un bloc antérieur. Cette méthode impliquerait d’obtenir les données hors chaîne depuis un nœud archiviste, puis de construire un arbre de Merkle et une preuve de validité du bloc afin de prouver l’authenticité des données sur la blockchain. Ensuite, l’EVM devrait vérifier et interpréter cette preuve. Une telle opération est fastidieuse et extrêmement coûteuse : simplement récupérer quelques soldes de jetons passés pourrait consommer plusieurs dizaines de millions de gas.
La racine de ce problème réside dans l’incapacité intrinsèque de la machine virtuelle blockchain à traiter des volumes massifs de données ou des calculs intensifs (comme la décompression décrite ci-dessus).
Architecture du coprocesseur ZK
(Source : Diapositives de la présentation de Brevis à ETHSG)
S’il existait une solution magique permettant à la blockchain de déléguer ces calculs fastidieux et gourmands en données, avec un coût faible et une rapidité élevée, sans hypothèse de confiance supplémentaire, ce serait idéal.
Eh bien, ami(e), c’est exactement là que les coprocesseurs ZK entrent en jeu.
Le terme « coprocesseur » tire son inspiration de l’histoire de l’architecture informatique. Par exemple, le GPU a été introduit comme coprocesseur du CPU parce que ce dernier devait déléguer certains calculs coûteux et difficiles (comme le rendu graphique ou l’entraînement en IA) à un « processeur auxiliaire », le GPU.
Mais alors, que signifie le « ZK » dans coprocesseur ZK ? Avant de plonger dans les détails techniques complexes, examinons d’abord la portée générale et le potentiel de cette innovation.
Des dApps pilotées par les données dans le Web 3.0
Le cashback sur les frais de transaction en est un excellent exemple. Avec les coprocesseurs ZK, il devient possible d’introduire de manière fluide divers programmes de fidélité dans de nombreux protocoles DeFi.
Mais cela va bien au-delà des programmes de fidélité en DeFi. Vous voyez probablement maintenant que le même problème existe dans d'autres domaines du Web 3.0. Réfléchissez-y : toutes les applications modernes du Web 2.0 sont pilotées par les données, alors que celles du Web 3.0 ne le sont pas. Pour créer des « applications tueuses » offrant une expérience utilisateur comparable à celle des applications internet traditionnelles, cette approche centrée sur les données est indispensable.
Prenons un autre exemple dans le domaine DeFi : améliorer l'efficacité de la liquidité via une refonte du système de récompenses de minage de liquidité.
Actuellement, les incitations à la liquidité sur les DEX à AMM fonctionnent selon un modèle « pay-as-you-go ». Dans ce modèle, les récompenses de farming sont distribuées immédiatement lorsque les fournisseurs de liquidité (LP) contribuent. Toutefois, ce modèle est loin d’être optimal. Les farmers professionnels peuvent retirer rapidement leurs liquidités dès qu’ils anticipent une volatilité du marché, évitant ainsi les pertes dues à la désynchronisation des prix (impermanent loss). Ainsi, ils apportent très peu de valeur au protocole, mais reçoivent tout de même des récompenses importantes.
Un système d’incitation idéal évaluerait rétrospectivement la fidélité des LP, particulièrement pendant les périodes de forte volatilité. Ceux qui ont maintenu leurs liquidités durant ces phases critiques devraient recevoir les récompenses maximales. Or, l'accès aux données historiques du comportement des LP, essentiel à ce modèle, reste aujourd’hui irréalisable.
Pour y parvenir, vous avez besoin d’un coprocesseur ZK.
Dans le domaine DeFi, on peut citer de nombreux autres exemples similaires : gestion proactive des positions LP selon des algorithmes prédéfinis, création de lignes de crédit basées sur des positions de liquidité non tokenisées, ou encore détermination dynamique des préférences de liquidation selon les antécédents de remboursement.
Cependant, le potentiel des coprocesseurs ZK ne se limite pas à la DeFi.
Créer des jeux entièrement sur chaîne avec une excellente expérience utilisateur grâce aux coprocesseurs ZK
Exemple de fonctions opérationnelles en temps réel dans les jeux Web 2.0
Lorsque vous commencez un nouveau jeu Web 2.0, chacun de vos gestes est minutieusement enregistré. Ces données ne restent pas inactives ; elles influencent fortement votre parcours dans le jeu. Elles déterminent quand vous recevez des suggestions d’achats intégrés, quand des mini-jeux récompensés sont déclenchés, quand des notifications push soigneusement formulées vous sont envoyées, ou encore avec quel adversaire vous êtes apparié. Tous ces éléments font partie de ce que l’industrie du jeu appelle les « LiveOps » (opérations en direct), un pilier essentiel pour renforcer l’engagement des joueurs et générer des revenus.
Pour que l’expérience utilisateur d’un jeu entièrement sur chaîne soit comparable à celle des grands classiques du Web 2.0, ces fonctionnalités LiveOps sont indispensables. Elles doivent s’appuyer sur l’historique des interactions des joueurs avec les contrats intelligents du jeu et leurs transactions.
Malheureusement, dans les jeux blockchain, ces fonctionnalités sont soit totalement absentes, soit encore pilotées par des solutions centralisées. La raison est identique à celle du cas des DEX : la difficulté d’extraire et de calculer les données historiques de jeu sur la blockchain.
Oui, encore une fois, vous avez besoin d’un coprocesseur ZK pour y parvenir.
Les applications sociales et d’identité du Web 3.0 constituent un autre domaine qui ne peut fonctionner sans soutien de coprocesseurs ZK.
Dans l’univers blockchain, votre identité numérique est un réseau tissé à partir de vos actions passées.
-
Vous voulez prouver que vous êtes un OG du NFT ? Prouvez que vous étiez l’un des mineurs originaux de Cryptopunk.
-
Vous vous vantez d’être un gros trader ? Montrez-moi que vous avez payé plus d’un million de dollars en frais sur un DEX.
-
Vous êtes proche de Vitalik ? Prouvez-moi que son adresse a déjà transféré des fonds vers la vôtre.
Les systèmes hors chaîne, qu’ils soient humains ou des applications Web 2.0, peuvent facilement produire de telles preuves, car, comme dans l’exemple du volume d’échanges, ils ont accès aux nœuds archivistes contenant toutes ces données.
Cette vérification par accès direct aux données nécessite une association forte entre l’adresse du portefeuille et l’identité, avec donc le désavantage inhérent de sacrifier la confidentialité, mais elle reste faisable.
Cependant, comme dans l’exemple du volume d’échanges, si vous souhaitez qu’un contrat intelligent croie à votre statut d’OG sans introduire de preuve de confiance supplémentaire, et ainsi obtenir un accès anticipé à certaines nouveautés, il n’existe actuellement aucune bonne solution.
Avec un coprocesseur ZK, vous pouvez tisser une preuve fiable de votre identité, une preuve de vos actions passées, que tout contrat intelligent acceptera sans aucune contestation. Vos interactions sur différentes applications, voire différentes blockchains, peuvent être habilement combinées pour former cette preuve.
Encore plus attrayant est le caractère privé par nature des preuves ZK. Votre adresse de portefeuille n’a pas besoin d’être publiquement associée à votre identité. Par exemple, vous pouvez prouver que vous possédez un NFT Cryptopunk sans révéler l’adresse spécifique. Ou encore, vous pouvez prouver avoir effectué 10 000 transactions sur Uniswap sans divulguer le nombre exact.
Les coprocesseurs ZK ouvrent un tout nouveau champ d’exploration pour la construction de dApps pilotées par les données, mais leur impact va bien au-delà.
Au-delà du paradigme piloté par les données : vers un modèle asynchrone du Web 3.0 grâce aux coprocesseurs ZK
Le modèle des dApps pilotées par les données, bien qu’attrayant, n’est qu’un début.
L’émergence des coprocesseurs ZK va transformer notre vision du calcul sur blockchain, inaugurant une ère où le traitement asynchrone deviendra la norme du Web 3.0. Ce changement redéfinit la manière dont les tâches sont exécutées, en permettant à des processeurs spécialisés de fonctionner indépendamment, augmentant ainsi l’efficacité.
Commençons par comprendre ce qu’est le traitement asynchrone.
Imaginez un restaurant synchrone où une seule personne fait office de cuisinier et de serveur. Vous passez commande, il commence à cuisiner, et vous attendez. Il ne peut servir un autre client qu’après avoir terminé votre plat. Bien que cela puisse répondre à vos besoins, cela limite gravement l’efficacité pour les autres clients.
En revanche, dans un restaurant asynchrone, des cuisiniers et des serveurs distincts collaborent. Le serveur prend votre commande, la transmet rapidement au cuisinier, puis continue d’accueillir d’autres clients. Une fois le plat prêt, le cuisinier en informe le serveur, qui vous le sert aussitôt.
Dans les systèmes informatiques :
L’architecture synchrone ressemble au premier restaurant : une entité attend la fin d’une tâche avant de passer à la suivante. Simple et directe, cette architecture peut être lente, car elle traite une tâche à la fois. Et cette personne pourrait être un bon serveur, mais un mauvais cuisinier.
L’architecture asynchrone ressemble au second restaurant, avec des composants découplés et spécialisés qui échangent messages et tâches pour coordonner leurs actions. Cela permet à chaque composant de gérer simultanément sa propre file de tâches. Bien qu’elle exige une gestion plus complexe, cette architecture est plus rapide et plus efficace.
Toute application Internet moderne repose sur une architecture asynchrone pour garantir efficacité et évolutivité. Nous pensons que le Web 3.0 devrait suivre le même chemin.
Les coprocesseurs ZK seront les pionniers de cette transformation. Pour les développeurs de dApps, la blockchain agit comme le serveur de notre restaurant asynchrone : elle gère principalement les calculs qui modifient directement l’état de la blockchain, comme le transfert de propriété d’un actif. Tous les autres calculs doivent être délégués à des coprocesseurs ZK robustes, qui, comme des chefs expérimentés, utilisent la puissance du traitement asynchrone pour préparer efficacement les résultats et les transmettre au serveur.
Plus concrètement, un coprocesseur ZK devrait être envisagé chaque fois qu’un calcul dans une application blockchain satisfait l’une des deux conditions suivantes.
Conditions d’utilisation d’un coprocesseur ZK :
-
Coût du calcul sur chaîne > (calcul hors chaîne via coprocesseur ZK [y compris la génération de preuve] + coût de vérification sur chaîne)
-
Délai du calcul sur chaîne > (calcul hors chaîne via coprocesseur ZK [y compris la génération de preuve] + délai de vérification sur chaîne)
Même si une seule condition est remplie, cela vaut la peine d’y réfléchir !
Vous voyez maintenant que cela dépasse largement les simples dApps pilotées par les données ! C’est une toute nouvelle manière d’introduire des calculs avancés généralistes (comme le machine learning) sur la blockchain, mais surtout, c’est l’introduction d’une architecture asynchrone révolutionnaire pour construire des dApps, auparavant totalement impossible.
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
IOSG Ventures
