GPU de la blockchain : Analyse complète des processeurs auxiliaires ZK
TechFlow SélectionTechFlow Sélection
GPU de la blockchain : Analyse complète des processeurs auxiliaires ZK
Les co-processeurs ZK améliorent la capacité des blockchains à traiter des tâches de calcul complexes, réduisent les frais de gaz et étendent les fonctionnalités des contrats intelligents grâce au calcul hors chaîne et aux preuves à connaissance nulle.
Dédié à des analyses Web3 approfondiesAuteur : Zeke, chercheur chez YBB Capital
TL ; DR
-
Un coprocesseur ZK peut être vu comme un module de calcul hors chaîne issu du concept de modularité, jouant un rôle similaire à celui d'un GPU dans un ordinateur classique qui décharge l'unité centrale (CPU) pour les tâches liées aux graphismes, c'est-à-dire un processeur spécialisé dans le traitement des calculs pour des scénarios spécifiques.
-
Il permet de traiter des calculs complexes et des données volumineuses, réduit les frais de gaz et étend les fonctionnalités des contrats intelligents.
-
Différence avec les Rollups : le coprocesseur ZK est sans état, utilisable entre différentes blockchains, et adapté aux scénarios nécessitant des calculs complexes.
-
Le développement des coprocesseurs ZK reste difficile, avec une forte surcharge de performance et un manque de standardisation. Du côté matériel, les coûts sont élevés. Bien que ce secteur ait mûri par rapport à l'année dernière, il en est encore à ses débuts.
-
À mesure que les infrastructures blockchain entrent dans une ère modulaire de scalabilité fractale, elles rencontrent divers problèmes tels que la rareté de liquidités, la dispersion des utilisateurs, le manque d'innovation et la faible interopérabilité entre chaînes, créant un paradoxe avec les L1 axés sur la scalabilité verticale. Les coprocesseurs ZK pourraient à l’avenir renforcer ces deux approches, les sortir de cette impasse, fournir un soutien de performance aux applications anciennes et émergentes intensives, et ouvrir de nouvelles perspectives narratives.
I. Une autre branche de l'infrastructure modulaire : le coprocesseur ZK
1.1 Aperçu du coprocesseur ZK
Un coprocesseur ZK peut être considéré comme un plug-in de calcul hors chaîne découlant du concept de modularité, jouant un rôle similaire à celui d’un GPU dans un ordinateur classique qui décharge l’unité centrale (CPU) pour les tâches de calcul graphique — un processeur spécialisé dans certaines situations. Dans ce cadre architectural, les tâches de « données lourdes » et de « logique de calcul complexe », pour lesquelles les blockchains publiques sont mal adaptées, peuvent être exécutées par un coprocesseur ZK. La chaîne principale n’a besoin que de recevoir le résultat du calcul, dont la validité est garantie par une preuve ZK, permettant ainsi un calcul hors chaîne fiable pour des tâches complexes.
Actuellement, des applications populaires telles qu’IA, SocialFi, DEX et GameFi ont un besoin urgent de hautes performances et de maîtrise des coûts. Avec les solutions traditionnelles, ces « applications lourdes » à forte intensité de performance optent souvent pour une combinaison actifs sur chaîne + application hors chaîne, ou conçoivent une blockchain dédiée. Mais ces deux approches présentent des inconvénients intrinsèques : la première crée une boîte noire, tandis que la seconde implique des coûts élevés de développement, une rupture avec l’écosystème de la chaîne d’origine et une fragmentation de la liquidité. En outre, la machine virtuelle principale impose de fortes limitations au développement et au fonctionnement de ces applications (par exemple, absence de standards applicatifs, langages de programmation complexes).
Les coprocesseurs ZK existent précisément pour résoudre ces problèmes. Prenons un exemple plus détaillé : imaginons la blockchain comme un terminal (téléphone, ordinateur, etc.) incapable de se connecter à Internet. Dans ce cas, nous pouvons exécuter certaines applications simples, comme Uniswap ou d'autres applications DeFi, entièrement sur chaîne. Mais lorsqu’il s’agit d’applications plus complexes, comme faire fonctionner une application semblable à ChatGPT, les capacités de performance et de stockage de la blockchain publique deviennent totalement insuffisantes, entraînant une explosion des frais de gaz. Dans le Web2, lorsque nous utilisons ChatGPT, notre terminal ne peut pas non plus traiter seul un grand modèle linguistique comme GPT-4o. Nous envoyons la requête via Internet aux serveurs d’OpenAI, qui effectuent le calcul, puis nous recevons directement la réponse. Le coprocesseur ZK joue un rôle similaire à un serveur distant pour la blockchain. Selon les projets, les designs peuvent légèrement varier, mais la logique fondamentale reste identique : calcul hors chaîne suivi de vérification par preuve ZK ou preuves de stockage. Prenons l'exemple du déploiement de Bonsai par Rise Zero, qui illustre bien la simplicité de cette architecture. Ce projet s'intègre parfaitement au zkVM de Rise Zero, et les développeurs n'ont besoin que de deux étapes très simples pour utiliser Bonsai comme coprocesseur :
-
Écrire une application zkVM pour gérer la logique applicative ;
-
Écrire un contrat Solidity demandant à Bonsai d’exécuter votre application zkVM et de traiter le résultat.
1.2 Quelle est la différence avec les Rollups ?
D’après la définition ci-dessus, on constate que les Rollups semblent hautement superposables aux coprocesseurs ZK, tant par la logique que par les objectifs. Cependant, les Rollups ressemblent davantage à une multi-cœurisation de la chaîne principale. Voici les différences clés :
1. Objectif principal :
-
Rollup : augmenter le débit transactionnel de la blockchain et réduire les frais.
-
Coprocesseur ZK : étendre les capacités de calcul des contrats intelligents, leur permettant de gérer des logiques plus complexes et des volumes de données plus importants.
2. Principe de fonctionnement :
-
Rollup : agrège les transactions hors chaîne, puis les soumet à la chaîne principale, avec preuve de fraude ou preuve ZK.
-
Coprocesseur ZK : similaire au ZK Rollup, mais destiné à des scénarios différents. Le ZK Rollup, limité par la forme et les règles de la chaîne, n’est pas adapté aux tâches d’un coprocesseur ZK.
3. Gestion d’état :
-
Rollup : doit maintenir son propre état, synchronisé périodiquement avec la chaîne principale.
-
Coprocesseur ZK : ne maintient aucun état persistant ; chaque calcul est sans état.
4. Scénarios d'utilisation :
-
Rollup : orienté grand public (B2C), adapté aux transactions fréquentes.
-
Coprocesseur ZK : orienté entreprises (B2B), adapté aux scénarios nécessitant des calculs complexes, comme les modèles financiers avancés ou l’analyse de grandes données.
5. Relation avec la chaîne principale :
-
Rollup : peut être vu comme une extension de la chaîne principale, généralement centrée sur un réseau blockchain spécifique.
-
Coprocesseur ZK : peut servir plusieurs blockchains, sans être limité à une chaîne principale spécifique, et peut également fournir des services aux Rollups.
En somme, ces deux technologies ne sont pas opposées mais complémentaires. Même si un Rollup existe sous forme de chaîne dédiée, un coprocesseur ZK peut toujours lui apporter un soutien.
1.3 Cas d'utilisation
Théoriquement, les applications du coprocesseur ZK sont très vastes et peuvent couvrir presque tous les secteurs de la blockchain. Grâce à lui, les DApp peuvent offrir des fonctionnalités proches de celles des applications centralisées Web2. Voici quelques exemples recueillis en ligne :
Développement de DApp piloté par les données
Les coprocesseurs ZK permettent aux développeurs de créer des DApp exploitant l'historique complet des données blockchain et réalisant des calculs complexes, sans hypothèse de confiance supplémentaire. Cela ouvre des possibilités sans précédent pour le développement de DApp, par exemple :
-
Analyse avancée de données : fonctionnalités d’analyse de données similaires à Dune Analytics.
-
Logique métier complexe : mise en œuvre d’algorithmes et de logiques métiers complexes présents dans les applications centralisées traditionnelles.
-
Applications multi-chaînes : construction de DApp multi-chain basés sur des données provenant de plusieurs chaînes.
Programme VIP pour traders sur DEX
Un cas d’utilisation typique consiste à mettre en œuvre sur une DEX un programme de réduction des frais basé sur le volume de trading, appelé « programme de fidélité pour traders VIP ». Ce type de programme est courant sur les exchanges centralisés (CEX), mais rare sur les DEX.
Grâce au coprocesseur ZK, une DEX peut :
-
Suivre le volume historique des transactions utilisateur
-
Calculer le niveau VIP de l'utilisateur
-
Ajuster dynamiquement les frais selon le niveau
Cette fonctionnalité pourrait aider les DEX à améliorer la rétention des utilisateurs, accroître la liquidité et finalement augmenter leurs revenus.
Amélioration des données pour contrats intelligents
Le coprocesseur ZK peut agir comme un middleware puissant, fournissant aux contrats intelligents des services de capture, calcul et vérification de données, réduisant ainsi les coûts et améliorant l’efficacité. Cela permet aux contrats intelligents de :
-
Accéder et traiter de grandes quantités de données historiques
-
Exécuter des calculs complexes hors chaîne
-
Implémenter des logiques métier plus avancées
Technologie de pont multi-chaînes
Certaines technologies de pont multi-chaînes basées sur ZK, comme Herodotus et Lagrange, peuvent aussi être considérées comme des applications de coprocesseurs ZK. Elles se concentrent principalement sur l’extraction et la vérification de données, fournissant ainsi une base de données fiable pour la communication multi-chaînes.
1.4 Le coprocesseur ZK n’est pas parfait
Bien que de nombreux avantages aient été énumérés, les coprocesseurs ZK actuels ne sont pas parfaits et font face à de nombreux défis. J’en ai identifié quatre points principaux :
1. Développement : le concept ZK est difficile à comprendre pour beaucoup de développeurs, qui doivent acquérir des connaissances en cryptographie et maîtriser des langages et outils spécifiques.
2. Coût matériel élevé : le matériel ZK utilisé pour le calcul hors chaîne doit être entièrement pris en charge par les équipes projets. Ce matériel est cher et évolue rapidement, risquant d’être obsolète à tout moment. Il faut donc se demander s’il est possible d’établir un modèle économique viable.
3. Concurrence accrue : les différences techniques entre projets sont minimes. À terme, le paysage pourrait ressembler à celui actuel des Layer 2, avec quelques projets dominants et la majorité ignorée.
4. Circuits ZK : exécuter des calculs hors chaîne via un coprocesseur ZK nécessite de convertir les programmes informatiques classiques en circuits ZK. Créer un circuit personnalisé pour chaque application est fastidieux, tandis que l’utilisation d’un zkVM implique une surcharge importante due à des modèles de calcul différents.
II. La pièce manquante vers les applications à grande échelle
(Ce chapitre reflète fortement l'opinion personnelle de l'auteur)
Ce cycle est dominé par les infrastructures modulaires. Si cette voie est correcte, elle pourrait bien constituer la dernière étape vers l'adoption massive des applications. Pourtant, nous partageons tous une même impression : pourquoi voyons-nous seulement de vieilles applications sous de nouveaux habits ? Pourquoi y a-t-il plus de chaînes que d'applications ? Pourquoi les normes de jetons comme les inscriptions sont-elles considérées comme la plus grande innovation de ce cycle ?
Ce manque criant de nouvelles narrations découle du fait que les infrastructures modulaires actuelles ne suffisent pas à porter des super-applications, notamment en raison de l’absence de conditions préalables essentielles (interopérabilité complète, seuil d’entrée utilisateur, etc.), ce qui accentue la plus grande fracture de l’histoire de la blockchain. Le Rollup, cœur de l’ère modulaire, a certes accéléré les choses, mais il a aussi introduit de nombreux problèmes : fragmentation de la liquidité, dispersion des utilisateurs, et la chaîne — ou sa machine virtuelle — continue de limiter l’innovation applicative. Par ailleurs, Celestia, un autre « joueur clé » de la modularité, a inauguré l’idée que la disponibilité des données (DA) n’a pas besoin d’être assurée par Ethereum. Que ce soit pour des raisons idéologiques ou économiques, cela a aggravé la fragmentation : BTC est contraint d’assurer sa propre DA, tandis que d’autres blockchains cherchent des solutions DA plus rentables. Résultat : chaque chaîne publique héberge désormais au moins un, voire des dizaines de projets Layer 2. Enfin, tous les projets d’infrastructure et d’écosystème ont profondément intégré le modèle « farming de points » popularisé par Blur (TieShun) pour éliminer OpenSea, obligeant les utilisateurs à staker leurs jetons dans le projet. Ce modèle triplement bénéfique pour les gros poissons (intérêts, hausse de l’ETH ou du BTC, jetons gratuits) compresse encore davantage la liquidité disponible sur chaîne.
Durant les précédents marchés haussiers, les capitaux circulaient entre quelques dizaines de chaînes, voire étaient concentrés sur Ethereum. Aujourd’hui, ils sont dispersés sur des centaines de chaînes, bloqués dans des milliers de projets quasi identiques. La prospérité sur chaîne a disparu, même Ethereum manque d’activité. Les joueurs asiatiques s’affrontent dans l’écosystème BTC, ceux occidentaux sur Solana — autant de solutions de repli. Mon intérêt principal aujourd’hui porte donc sur la manière de promouvoir l’agrégation de la liquidité sur toutes les chaînes, et de soutenir l’émergence de nouveaux usages et super-applications. Dans le domaine de l’interopérabilité globale, les projets leaders traditionnels ont jusqu’ici déçu, restant proches des ponts multi-chaînes classiques. Quant aux nouvelles solutions d’interopérabilité, mentionnées dans nos rapports précédents, elles visent surtout à agréger plusieurs chaînes en une seule — citons AggLayer, Superchain, Elastic Chain, JAM, etc., sujet que nous n’aborderons pas ici.
En résumé, l’agrégation de toutes les chaînes est une étape obligatoire dans l’architecture modulaire, mais elle prendra encore longtemps. Le coprocesseur ZK représente, à ce stade, une pièce encore plus cruciale. En plus de renforcer les Layer 2, il peut aussi soutenir les Layer 1. Existe-t-il un moyen de contourner temporairement les problèmes d’interopérabilité globale et du triangle impossible, afin de développer dès maintenant certaines applications pertinentes sur des Layer 1 ou Layer 2 ayant déjà une large liquidité ? Car la narration actuelle des applications blockchain est vraiment pauvre. D’autre part, la diversification des usages, la maîtrise des frais de gaz, l’émergence d’applications massives, voire l’interopérabilité et la réduction des barrières d’entrée pour les utilisateurs, pourraient être mieux servies par l’intégration de solutions de coprocesseurs plutôt que par un retour à la centralisation.
III. Aperçu des projets
Le secteur des coprocesseurs ZK est apparu vers 2023 et est désormais relativement mature. Selon la classification de Messari, ce secteur compte actuellement 18 projets répartis en trois domaines verticaux principaux : calcul général, interopérabilité et multi-chaînes, IA et apprentissage automatique. La plupart des projets bénéficient du soutien de grands fonds VC. Nous analysons ci-dessous certains projets représentatifs de chaque domaine.
3.1 Giza
Giza est un protocole zkML (machine learning à preuves de connaissance) déployé sur Starknet et soutenu officiellement par StarkWare. Il se concentre sur la possibilité d'utiliser des modèles d'intelligence artificielle de façon vérifiable dans les contrats intelligents blockchain. Les développeurs peuvent déployer des modèles d'IA sur le réseau Giza, qui valide ensuite la justesse des inférences via des preuves ZK, fournissant les résultats aux contrats intelligents de manière non fongible. Cela permet de construire des applications chaines combinant les capacités de l'IA tout en conservant la décentralisation et la vérifiabilité de la blockchain.
Giza suit trois étapes clés dans son flux de travail :
-
Conversion du modèle : Giza convertit les modèles d’IA au format ONNX couramment utilisé en un format exécutable dans un système de preuve à connaissance nulle. Cela permet aux développeurs d’utiliser des outils familiers pour entraîner leurs modèles, puis de les déployer sur le réseau Giza.
-
Inférence hors chaîne : lorsque le contrat intelligent demande une inférence du modèle d’IA, Giza effectue le calcul hors chaîne, évitant ainsi le coût prohibitif d’exécuter directement un modèle d’IA complexe sur la blockchain.
-
Vérification par preuve ZK : Giza génère une preuve ZK pour chaque inférence, attestant que le calcul a été correctement exécuté. Ces preuves sont vérifiées sur chaîne, garantissant la justesse des résultats sans avoir à refaire le calcul complet.
L’approche de Giza rend les modèles d’IA sources d’entrée fiables pour les contrats intelligents, sans dépendre d’oracle centralisé ou d’environnement d’exécution fiable. Cela ouvre de nouvelles possibilités, comme la gestion d’actifs basée sur l’IA, la détection de fraude ou la tarification dynamique. Giza est l’un des rares projets dans le domaine Web3 x IA à présenter une logique cohérente, et illustre brillamment l’usage des coprocesseurs dans le domaine de l’IA.
3.2 Risc Zero
Risc Zero est un projet de coprocesseur soutenu par plusieurs grands fonds VC, et figure parmi les leaders du secteur. Il vise à permettre l’exécution vérifiable de calculs arbitraires dans les contrats intelligents blockchain. Les développeurs peuvent écrire des programmes en Rust et les déployer sur le réseau RISC Zero, qui valide ensuite la justesse de l’exécution via une preuve ZK, fournissant les résultats aux contrats intelligents de manière non fongible. Cela permet de construire des applications complexes tout en préservant la décentralisation et la vérifiabilité.
Nous avons déjà brièvement décrit le processus de déploiement. Voyons maintenant les deux composants clés :
Bonsai : Bonsai est le composant coprocesseur de RISC Zero. Intégré de manière transparente au zkVM basé sur l’architecture RISC-V, il permet aux développeurs d’intégrer rapidement des preuves ZK haute performance dans Ethereum, les blockchains L1, les chaînes Cosmos, les rollups L2 et les dApps en quelques jours. Il offre un appel direct depuis les contrats intelligents, un calcul hors chaîne vérifiable, l’interopérabilité multi-chaînes et des fonctions de rollup généralistes, avec une architecture distribuée priorisant la décentralisation. Grâce à des preuves récursives, un compilateur de circuits personnalisés, une continuité d’état et des algorithmes de preuve en constante amélioration, il permet à quiconque de générer des preuves ZK hautes performances pour diverses applications.
zkVM : ce zkVM est un ordinateur vérifiable fonctionnant comme un microprocesseur RISC-V embarqué réel. Basé sur l’architecture RISC-V, il permet d’écrire des programmes générant des preuves ZK en utilisant divers langages (Rust, C++, Solidity, Go, etc.), supporte plus de 70 % des crates Rust populaires, combine calcul généraliste et preuves ZK de manière fluide, génère efficacement des preuves ZK pour des calculs d’une complexité quelconque, tout en préservant la confidentialité du calcul et la vérifiabilité du résultat. Il utilise des technologies ZK comme STARK et SNARK, et des composants comme Recursion Prover et STARK-to-SNARK Prover pour une génération et vérification efficaces des preuves, adoptant un modèle d’exécution hors chaîne et de vérification sur chaîne.
Risc Zero s’est déjà intégré à plusieurs Layer 2 de l’écosystème ETH et a démontré plusieurs cas d’usage de Bonsai. L’un d’eux, Bonsai Pay, est particulièrement intéressant : il utilise le zkVM et les services de preuve de RISC Zero pour permettre aux utilisateurs d’envoyer ou retirer ETH et jetons sur Ethereum via leur compte Google. Cela montre comment RISC Zero peut intégrer sans friction les applications chaines avec OAuth2.0 (standard utilisé par Google et autres fournisseurs d’identité), illustrant une réduction du seuil d’entrée Web3 grâce à des applications Web2. D’autres exemples incluent des applications basées sur DAO.
3.3 =nil;
=nil; est financé par des projets et institutions renommés comme Mina, Polychain, Starkware et Blockchain Capital. Notons que Mina et Starkware, pionniers des technologies ZK, y participent, témoignant d’une reconnaissance technique élevée. =nil; est aussi un projet mentionné dans notre précédent rapport sur « les marchés de puissance de calcul », centré alors sur son Proof Market (marché décentralisé de génération de preuves). Le projet dispose d’un autre produit, zkLLVM.
zkLLVM est un compilateur de circuits innovant développé par la =nil; Foundation. Il convertit automatiquement en circuits prouvables et efficaces sur Ethereum le code d’applications écrites en C++ ou Rust, sans nécessiter de langage spécifique à domaine (DSL) ZK, simplifiant ainsi grandement le développement et abaissant la barrière d’entrée. En évitant le recours à un zkVM, il améliore les performances, supporte l’accélération matérielle pour accélérer la génération de preuves, et convient à divers cas d’usage ZK (rollups, ponts, oracles, apprentissage machine, jeux). Il s’intègre étroitement au Proof Market de =nil; Foundation, offrant un support bout-en-bout, de la création du circuit à la génération de la preuve.
3.4 Brevis
Brevis est un sous-projet de Celer Network. C’est un coprocesseur intelligent ZK pour blockchain, permettant aux dApps d’accéder, calculer et exploiter n’importe quelle donnée sur plusieurs blockchains de manière entièrement non fongible. Comme d’autres coprocesseurs, Brevis couvre un large éventail d’applications : DeFi pilotée par les données, zkBridges, acquisition d’utilisateurs sur chaîne, zkDID, abstraction de comptes sociaux.
L’architecture de Brevis repose sur trois composants principaux :
-
zkFabric : zkFabric est le relais de l’architecture Brevis. Son rôle principal est de collecter et synchroniser les en-têtes de blocs de toutes les blockchains connectées, puis de générer une preuve de consensus via un circuit ZK léger pour chaque en-tête collecté.
-
zkQueryNet : zkQueryNet est un marché ouvert de moteurs de requête ZK. Il accepte directement des requêtes de données depuis les contrats intelligents sur chaîne, et génère via un circuit de requête ZK les résultats et leurs preuves associées. Ces moteurs vont de spécialisés (ex : calcul du volume des transactions sur un DEX pendant une période donnée) à généralistes, avec abstraction d’indexation de données et langage de requête avancé, répondant à divers besoins applicatifs.
-
zkAggregatorRollup : sert de couche d’agrégation et de stockage pour zkFabric et zkQueryNet. Il vérifie les preuves de ces deux composants, stocke les données prouvées, et soumet sur toutes les blockchains connectées la racine d’état de ses preuves ZK, permettant ainsi aux dApps d’accéder directement aux résultats de requête prouvés dans leur logique métier sur chaîne.
Grâce à cette architecture modulaire, Brevis offre à tous les contrats intelligents des blockchains supportées un accès non fongible, efficace et flexible. La version V4 d’UNI a adopté ce projet, l’intégrant à son système Hooks (permettant de personnaliser la logique pour divers utilisateurs), facilitant la lecture des données historiques blockchain, réduisant les frais de gaz tout en préservant la décentralisation. Un exemple de l’impact des coprocesseurs ZK sur les DEX.
3.5 Lagrange
Lagrange est un protocole de coprocesseur ZK interopérable, financé par 1kx et Founders Fund. Son objectif principal est de soutenir l’interopérabilité multi-chaînes non fongible et l’innovation pour des applications nécessitant des calculs complexes sur de grandes données. Contrairement aux ponts traditionnels basés sur des nœuds, l’interopérabilité multi-chaînes de Lagrange repose sur deux mécanismes innovants : ZK Big Data et State Committee.
ZK Big Data : ce produit est au cœur de Langrange, chargé de traiter et valider les données multi-chaînes, générant les preuves ZK associées. Ce composant inclut un coprocesseur ZK hautement parallèle pour exécuter des calculs complexes hors chaîne et générer des preuves à connaissance nulle, une base de données vérifiable spécialement conçue supportant un nombre illimité de slots de stockage et autorisant des requêtes SQL directes depuis les contrats intelligents, un mécanisme de mise à jour dynamique qui met uniquement à jour les points de données modifiés pour réduire le temps de preuve, et une fonction d’intégration permettant aux développeurs d’utiliser des requêtes SQL depuis les contrats intelligents pour accéder aux données historiques sans écrire de circuits complexes. Ensemble, ils forment un système massif de traitement et de vérification des données blockchain.
State Committee : ce composant est un réseau de validation décentralisé constitué de plusieurs nœuds indépendants, chacun misant de l’ETH comme garantie. Ces nœuds agissent comme des clients légers ZK, vérifiant spécifiquement l’état de rollups optimisés. State Committee s’intègre à EigenLayer AVS, utilisant le mécanisme de re-staking pour renforcer la sécurité, permettant la participation d’un nombre illimité de nœuds et assurant une croissance de sécurité supralinéaire. Il propose également un « mode rapide » permettant aux utilisateurs d’effectuer des opérations multi-chaînes sans attendre la fenêtre de défi, améliorant grandement l’expérience utilisateur. La combinaison de ces deux technologies permet à Lagrange de traiter efficacement de grandes masses de données, d’exécuter des calculs complexes et de transmettre et valider des résultats entre différentes blockchains, soutenant ainsi le développement d’applications multi-chaînes complexes.
Lagrange s’est déjà intégré à EigenLayer, Mantle, Base, Frax, Polymer, LayerZero, Omni et AltLayer, et sera le premier ZK AVS à se connecter à l’écosystème Ethereum.
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
@YBBCapital
