1. Introduction du concept

En ce qui concerne le concept de coprocesseur, un exemple très simple et facile à comprendre est la relation entre un ordinateur et une carte graphique. Le CPU peut accomplir la plupart des tâches, mais une fois une tâche spécifique rencontrée, la carte graphique a besoin d'aide car le CPU a une puissance de calcul insuffisante, comme l'apprentissage machine, le rendu graphique ou l'exécution de jeux à grande échelle. Si nous ne voulons pas perdre des images ou geler en jouant à des jeux à grande échelle, nous avons définitivement besoin d'une carte graphique performante. Dans ce scénario, le CPU est le processeur et la carte graphique est le coprocesseur. En transposant à la blockchain, le contrat intelligent est le CPU et le coprocesseur ZK est le GPU.

Le point clé est de déléguer des tâches spécifiques à des coprocesseurs spécifiques. Tout comme dans une usine, le patron connaît les étapes de chaque lien et peut le faire lui-même ou enseigner aux employés l'ensemble du processus de production, mais cela est très inefficace et il ne peut produire qu'une pièce à la fois, et seulement après en avoir terminé une peut-il produire la suivante, il a donc embauché de nombreux employés spécifiques. Ils exécutent chacun leurs tâches et font le travail pour lequel ils sont compétents dans la chaîne de production dans leurs propres ateliers. Les liens de la chaîne peuvent interagir les uns avec les autres. Communiquer et coordonner mais ne pas interférer avec le travail des autres. Ils ne font que ce qu'ils font de mieux. Ceux qui ont les mains rapides et la force physique peuvent visser. Ceux qui savent comment utiliser les machines peuvent les faire fonctionner. Ceux qui savent compter peuvent calculer le volume de production et les coûts. Travail de collaboration asynchrone pour maximiser l'efficacité du travail.

Pendant la révolution industrielle, les capitalistes avaient déjà découvert que ce modèle pouvait amener une capacité de production maximale à leurs usines. Cependant, lorsqu'une étape du processus de production rencontre des obstacles en raison de la technologie ou d'autres raisons, d'autres facteurs peuvent nécessiter d'être externalisés. Les fabricants spécialisés le font. Par exemple, pour une entreprise qui produit des téléphones portables, les puces peuvent être produites par d'autres sociétés de puces spécialisées. L'entreprise de téléphonie mobile est le processeur central, et la société de puces est le coprocesseur. Les coprocesseurs peuvent facilement et de manière asynchrone gérer des tâches spécifiques qui sont trop contraignantes et lourdes pour que le processeur central les traite seul.

Le coprocesseur ZK est relativement large dans un sens large. Certains projets l'appellent leur propre coprocesseur, et certains l'appellent ZKVM, mais ils ont tous la même idée: permettre aux développeurs de contrats intelligents de prouver sans état des calculs hors chaîne sur des données existantes. Pour le dire simplement, certains travaux de calcul sur chaîne sont effectués hors chaîne pour réduire les coûts et augmenter l'efficacité. En même temps, ZK est utilisé pour garantir la fiabilité des calculs et protéger la confidentialité des données spécifiques. Dans le monde orienté données de la blockchain, c'est particulièrement important.

2. Pourquoi avons-nous besoin d'un coprocesseur ZK ?

Un des plus grands goulets d'étranglement auxquels les développeurs de contrats intelligents sont confrontés reste les coûts élevés associés à la computation on-chain. Comme le Gas doit être mesuré pour chaque opération, le coût de la logique d'application complexe deviendra rapidement trop élevé pour être exécuté, car bien que les nœuds d'archive dans la couche DA de la blockchain puissent en effet stocker des données historiques, c'est pourquoi des choses comme les applications d'analyse hors-chaîne de Dune telles que Analytics, Nansen, 0xscope et Etherscan peuvent avoir autant de données de la blockchain et peuvent remonter longtemps en arrière, mais il n'est pas simple pour les contrats intelligents d'accéder à toutes ces données. Ils peuvent seulement accéder facilement aux données stockées dans l'état de la machine virtuelle, les données du dernier bloc et d'autres données publiques de contrat intelligent. Pour plus de données, les contrats intelligents peuvent devoir déployer beaucoup d'efforts pour y accéder:

Les contrats intelligents dans la machine virtuelle Ethereum (EVM) ont accès aux hachages d'en-tête de bloc des 256 derniers blocs. Ces en-têtes de bloc contiennent toutes les informations d'activité dans la blockchain jusqu'au bloc actuel et sont compressés en une valeur de hachage de 32 octets à l'aide de l'arbre de Merkle et de l'algorithme de hachage Keccak.

Bien que les données soient compressées par hachage, elles peuvent être décompressées, mais ce n'est pas facile. Par exemple, si vous souhaitez tirer parti de l'en-tête de bloc le plus récent pour accéder de manière fiable à des données spécifiques dans le bloc précédent, cela implique une série complexe d'étapes. Tout d'abord, vous devez obtenir les données hors chaîne du nœud d'archive, puis construire un arbre de Merkle et une preuve de validité du bloc pour vérifier l'authenticité des données sur la blockchain. Ensuite, l'EVM traitera ces preuves de validité, les vérifiera et les expliquera. Cette opération est non seulement fastidieuse mais prend également beaucoup de temps, et le gaz est également particulièrement coûteux.

La raison fondamentale de ce défi est que les machines virtuelles de la blockchain (telles que l'EVM) ne sont pas adaptées pour gérer de grandes quantités de données et des tâches de calcul intensives, telles que le travail de décompression mentionné ci-dessus. L'objectif de conception de l'EVM est d'exécuter du code de contrat intelligent tout en garantissant la sécurité et la décentralisation, plutôt que de traiter des données à grande échelle ou d'effectuer des tâches de calcul complexes. Par conséquent, lorsqu'il s'agit de tâches nécessitant de grandes quantités de ressources de calcul, il est souvent nécessaire de trouver d'autres solutions, telles que l'utilisation de calcul hors chaîne ou d'autres technologies de mise à l'échelle. À ce moment-là, le coprocesseur ZK émerge.

Les rollups ZK sont en fait les premiers coprocesseurs ZK, prenant en charge le même type de calculs utilisés sur L1 à une plus grande échelle et quantité. Ce processeur est au niveau du protocole, et le coprocesseur ZK dont nous parlons maintenant est au niveau de l'application. Le coprocesseur ZK améliore la scalabilité des contrats intelligents en permettant aux contrats intelligents de déléguer de manière décentralisée l'accès aux données et les calculs historiques sur la chaîne en utilisant des preuves ZK. Plutôt que d'effectuer toutes les opérations dans l'EVM, les développeurs peuvent décharger les opérations coûteuses vers le coprocesseur ZK et simplement utiliser les résultats sur la chaîne. Cela offre une nouvelle manière aux contrats intelligents de s'adapter en dissociant l'accès aux données et les calculs du consensus de la blockchain.

Le coprocesseur ZK introduit un nouveau modèle de conception pour les applications on-chain, éliminant la restriction selon laquelle les calculs doivent être effectués dans la machine virtuelle blockchain. Cela permet aux applications d'accéder à plus de données et de fonctionner à une plus grande échelle qu'auparavant tout en contrôlant les coûts de gaz, en augmentant la scalabilité et l'efficacité des contrats intelligents sans compromettre la décentralisation et la sécurité.

3. Mise en œuvre technique

Cette partie utilisera l'architecture Axiom pour expliquer comment le coprocesseur zk résout le problème techniquement. En fait, il y a deux cœurs : la capture de données et le calcul. Dans ces deux processus, ZK garantit efficacité et confidentialité en même temps.

3.1 Capture de données

L'un des aspects les plus importants de l'exécution de calculs sur le coprocesseur ZK est de s'assurer que toutes les données d'entrée sont correctement accessibles depuis l'historique de la blockchain. Comme mentionné précédemment, cela est en réalité assez difficile car les contrats intelligents ne peuvent accéder qu'à l'état actuel de la blockchain dans leur code, et même cet accès est la partie la plus coûteuse du calcul on-chain. Cela signifie que les données historiques on-chain telles que les enregistrements de transactions ou les soldes précédents (entrées on-chain intéressantes dans les calculs) ne peuvent pas être utilisées nativement par les contrats intelligents pour vérifier les résultats du coprocesseur.

Le coprocesseur ZK résout ce problème de trois manières différentes, équilibrant coût, sécurité et facilité de développement:

1. Stockez des données supplémentaires dans l'état de la blockchain et utilisez l'EVM pour stocker toutes les données utilisées on-chain par le co-processeur de vérification de lecture. Cette approche est assez coûteuse et prohibitive pour de grandes quantités de données.
2. Faites confiance à un Oracle ou à un réseau de signataires pour vérifier les données d'entrée au coprocesseur. Cela nécessite que les utilisateurs du coprocesseur fassent confiance à l'Oracle ou au fournisseur de signature multiple, ce qui réduit la sécurité.
3. Utilisez des preuves ZK pour vérifier si des données on-chain utilisées dans le co-processeur ont été engagées dans l'historique de la blockchain. Chaque bloc dans la blockchain engage tous les blocs passés et donc toutes les données historiques, fournissant des garanties cryptographiques de validité des données et ne nécessitant aucune hypothèse supplémentaire de confiance de l'utilisateur.

3.2 Calcul

Effectuer des calculs hors chaîne dans un coprocesseur ZK nécessite de convertir des programmes informatiques traditionnels en circuits ZK. Actuellement, toutes les méthodes pour y parvenir ont un impact énorme sur les performances, les preuves ZK entraînant un surcoût de 10 000 à 1 000 000 par rapport à l'exécution du programme natif. D'autre part, le modèle de calcul des circuits ZK diffère des architectures informatiques standard (par exemple, actuellement, toutes les variables doivent être encodées modulo un grand nombre premier cryptographique, et l'implémentation peut être non déterministe), ce qui signifie que les développeurs ont du mal à les écrire directement.

Par conséquent, les trois principales approches de spécification des calculs dans les coprocesseurs ZK sont principalement des compromis entre performances, flexibilité et facilité de développement:

1. Circuits personnalisés : les développeurs écrivent leurs propres circuits pour chaque application. Cette approche offre le plus grand potentiel de performance, mais nécessite des efforts importants de la part des développeurs.
2. eDSL/DSL pour les circuits: Les développeurs écrivent des circuits pour chaque application, mais abstractisent les problèmes spécifiques à ZK dans un cadre dogmatique (similaire à l'utilisation de PyTorch pour les réseaux neuronaux). Mais les performances sont légèrement inférieures.
3. Les développeurs zkVM écrivent des circuits dans des machines virtuelles existantes et vérifient leur exécution dans ZK. Cela offre l'expérience la plus simple aux développeurs lors de l'utilisation de VM existantes, mais se traduit par des performances et une flexibilité moindres en raison des différents modèles de calcul entre les VM et ZK.

4. Application

Le coprocesseur ZK a une large gamme d'applications. Le coprocesseur ZK peut théoriquement couvrir tous les scénarios d'application que Dapp peut couvrir. Tant qu'il s'agit d'une tâche liée aux données et au calcul, le coprocesseur ZK peut réduire les coûts, augmenter l'efficacité et protéger la vie privée. Ce qui suit va commencer à partir de différentes pistes et explorer ce que le processeur ZK peut faire au niveau de l'application.

4.1 Defi

4.1.1 DEX

Prenez le crochet dans Uniswap V4 comme exemple :

Hook permet aux développeurs d'effectuer des opérations spécifiées à n'importe quel point clé du cycle de vie complet du pool de liquidité - comme avant ou après le trading de tokens, ou avant ou après les changements de position LP, les pools de liquidité personnalisés, les échanges, les frais Comment interagir avec les positions LP, par exemple :

• Time Weighted Average Market Maker (TWAMM);
• frais dynamiques basés sur la volatilité ou d'autres entrées;
• Ordre limite de prix en chaîne;
• Déposez des liquidités hors champ dans les protocoles de prêt;
• Oracles personnalisés sur chaîne, tels que les oracles de moyenne géométrique;
• Composé automatiquement les frais LP aux positions LP;
• Les profits de MEV de Uniswap sont distribués aux LP;
• Programme de réduction de fidélité pour les LPs ou traders;

En termes simples, il s'agit d'un mécanisme qui permet aux développeurs de capturer des données historiques sur n'importe quelle chaîne et de les utiliser pour personnaliser le pool dans Uniswap selon leurs propres idées. L'émergence de Hook apporte plus de composition et une plus grande efficacité aux transactions sur la chaîne. l'efficacité du capital. Cependant, une fois que la logique de code qui définit ces éléments devient compliquée, cela entraînera un énorme fardeau en gaz pour les utilisateurs et les développeurs. Ensuite, le zkcoprocessor s'avère utile à ce moment-là, ce qui peut aider à économiser ces coûts en gaz et à améliorer l'efficacité.

D'un point de vue à plus long terme, le coprocesseur ZK accélérera l'intégration de DEX et CEX. Depuis 2022, nous avons constaté que DEX et CEX sont devenus fonctionnellement cohérents. Tous les principaux CEX acceptent cette réalité et adoptent des portefeuilles Web3, construisent des EVM L2 et adoptent une infrastructure existante comme le Lightning Network ou l'open source pour embrasser la part de liquidité on-chain. Ce phénomène est inséparable du renforcement du coprocesseur ZK. Toutes les fonctions que CEX peut accomplir, que ce soit le trading en grille, le suivi, le prêt rapide ou l'utilisation des données utilisateur, DEX peut également être implémenté via le coprocesseur ZK, ainsi que la composabilité et la liberté de Defi, ainsi que les transactions de petites devises sur la chaîne, sont difficile à réaliser avec les CEX traditionnels. En même temps, la technologie ZK peut également protéger la vie privée de l'utilisateur pendant l'exécution.

4.1.2 Airdrop

Si certains projets souhaitent réaliser des largages aériens, ils ont besoin d'un contrat intelligent pour interroger les activités historiques de l'adresse, mais ne veulent pas exposer les informations d'adresse de l'utilisateur et l'exécuter sans introduire de preuve de confiance supplémentaire. Par exemple, un projet de prêt Defi souhaite, grâce à l'interaction entre l'adresse et une série de protocoles de prêt tels que Aave, Compound, Fraxlend et Spark en tant que norme pour les largages aériens, les fonctionnalités de capture de données historiques et de confidentialité du coprocesseur ZK peuvent facilement résoudre ce besoin.

4.2 ZKML

Un autre point excitant du coprocesseur ZK se situe dans le domaine de l'apprentissage automatique. Comme les contrats intelligents peuvent bénéficier de capacités de calcul hors chaîne, il deviendra possible d'effectuer un apprentissage automatique à haute efficacité sur la chaîne. En fait, le coprocesseur ZK est également une partie indispensable pour l'entrée et le calcul des données ZKML. Il peut extraire les données d'entrée nécessaires à l'apprentissage automatique à partir des données historiques sur chaîne/hors chaîne importées dans le contrat intelligent, puis écrire le calcul dans un circuit ZK et le jeter sur la chaîne.

4.3 KYC

KYC est un gros business, et maintenant le monde web3 adopte progressivement la conformité. Avec le coprocesseur ZK, il est possible de rendre un contrat intelligent vérifiable en saisissant toutes les données hors chaîne fournies par l'utilisateur sans avoir besoin de divulguer des informations inutiles sur les utilisateurs, en fait, certains projets sont en cours de mise en œuvre, tels que le crochet KYC d'Uniswap, qui utilise le coprocesseur ZK Pado pour capturer des données hors chaîne sans confiance. Preuve des actifs, preuve des qualifications académiques, preuve des déplacements, preuve de conduite, preuve de l'application de la loi, preuve des joueurs, preuve des transactions... Tous les comportements historiques sur et hors chaîne peuvent même être regroupés en une identité complète, et peuvent être rédigés avec une forte crédibilité. ZK prouve qu'il est sur la chaîne tout en protégeant la vie privée de l'utilisateur.

4.4 Social

L’attribut spéculatif du Friend.tech est en fait plus fort que l’attribut social. Le noyau réside dans sa courbe de liaison. Est-il possible d’ajouter un crochet à la courbe de liaison de friend.tech afin que les utilisateurs puissent personnaliser la direction de la courbe de liaison, par exemple en mettant en œuvre Après la fin de l’engouement pour les clés de trading et le départ des spéculateurs, la courbe de liaison sera lissée, la barrière d’entrée pour les vrais fans sera abaissée et le trafic réel du domaine privé augmentera. Ou laissez le contrat intelligent obtenir le graphe social on-chain/off-chain de l’utilisateur, et être en mesure de suivre vos amis sur différentes Dapps sociales en un seul clic. Ou vous pouvez créer un club privé sur la chaîne, tel que le club Degen, et seules les adresses qui répondent aux conditions historiques de consommation de gaz peuvent entrer, etc.

4.5 Jeu

Dans les jeux Web2 traditionnels, les données utilisateur sont un paramètre très important. Le comportement d'achat, le style de jeu et la contribution peuvent rendre le jeu plus performant et offrir une meilleure expérience utilisateur, comme le mécanisme de correspondance ELO dans les jeux MOBA. La fréquence d'achat de skins, etc., mais ces données sont difficiles à capturer par des contrats intelligents sur la blockchain, elles ne peuvent donc être remplacées que par des solutions centralisées ou simplement abandonnées. Cependant, l'émergence du coprocesseur ZK rend les solutions décentralisées possibles.

5. Projet Parti

Il y a déjà quelques joueurs exceptionnels sur cette piste. Les idées sont en fait similaires. Ils génèrent une preuve ZK grâce à une preuve de stockage ou un consensus, puis la jettent sur la chaîne. Cependant, chacun a ses propres avantages en termes de caractéristiques techniques et de fonctions mises en œuvre.

5.1 Axiom

Axiom, le leader des coprocesseurs ZK (zero-knowledge), se concentre sur le fait que les contrats intelligents peuvent accéder à l'ensemble de l'histoire d'Ethereum et à tous les calculs de vérification ZK sans confiance. Les développeurs peuvent soumettre des requêtes on-chain à Axiom, qui les traite ensuite via la vérification ZK et renvoie les résultats au contrat intelligent du développeur de manière décentralisée. Cela permet aux développeurs de créer des applications on-chain plus riches sans se fier à des hypothèses de confiance supplémentaires.

Pour implémenter ces requêtes, Axiom effectue les trois étapes suivantes :

1. Lire: Axiom utilise des preuves ZK pour lire de manière décentralisée les données des en-têtes de bloc, de l'état, des transactions et des reçus des blocs historiques d'Ethereum. Comme toutes les données on-chain d'Ethereum sont encodées dans ces formats, Axiom est capable d'accéder à tout ce à quoi les nœuds d'archive ont accès. Axiom vérifie toutes les données d'entrée du coprocesseur ZK via des preuves ZK de triplets Merkle-Patricia et des chaînes de hachage des en-têtes de bloc. Bien que cette approche soit plus difficile à développer, elle offre la meilleure sécurité et le meilleur coût pour les utilisateurs finaux car elle garantit que tous les résultats renvoyés par Axiom sont cryptographiquement équivalents aux calculs on-chain effectués dans l'EVM.
2. calculer: Après que les données ont été ingérées, Axiom applique des calculs éprouvés sur celles-ci. Les développeurs peuvent spécifier leur logique de calcul dans le front-end JavaScript, et la validité de chaque calcul est vérifiée dans la preuve ZK. Les développeurs peuvent visiter AxiomREPL ou consulter la documentation pour en apprendre davantage sur les primitives de calcul disponibles. Axiom permet aux utilisateurs d'accéder aux données on-chain et de spécifier leurs propres calculs via eDSL. Il permet également aux utilisateurs d'écrire leurs propres circuits en utilisant la bibliothèque de circuits ZK.
3. vérifier: Axiom fournit des preuves de validité ZK pour chaque résultat de requête. Ces preuves garantissent que (1) les données d'entrée ont été extraites correctement de la chaîne et (2) les calculs ont été correctement appliqués. Ces preuves ZK sont vérifiées on-chain dans les contrats intelligents d'Axiom, garantissant que les résultats finaux sont utilisés de manière fiable dans les contrats intelligents des utilisateurs.

Parce que les résultats sont vérifiés via des preuves de ZK, les résultats d'Axiom sont cryptographiquement aussi sécurisés que ceux d'Ethereum. Cette approche ne fait aucune hypothèse sur la cryptéconomie, les incitations ou la théorie des jeux. Axiom estime que cette approche fournira le plus haut niveau d'assurance possible pour les applications de contrats intelligents. L'équipe d'Axiom a travaillé en étroite collaboration avec la Fondation Uniswap et a obtenu des subventions d'Uniswap, et construira un oracle sans confiance sur Uniswap.

5.2 Risque Zéro

Bonsaï: En 2023, RISC Zero a lancé Bonsaï, un service de preuve qui permet aux applications sur et hors chaîne de demander et de recevoir des preuves zkVM. Bonsaï est un service de preuve de connaissance zéro universel qui permet à n'importe quelle chaîne, n'importe quel protocole et n'importe quelle application d'utiliser des preuves ZK. Il est hautement parallélisable, programmable et performant.

Bonsai vous permet d'intégrer des preuves de connaissance nulle directement dans n'importe quel contrat intelligent, sans avoir besoin d'un circuit personnalisé. Cela permet à ZK d'être directement intégré dans des applications décentralisées sur n'importe quelle chaîne EVM, avec la possibilité de prendre en charge tout autre écosystème.

zkVM est la fondation de Bonsai et prend en charge une large compatibilité linguistique, prend en charge le code Rust pouvant être prouvé, et potentiellement le code prouvable à connaissance nulle dans n'importe quel langage compilé en RISC-V (comme C++, Rust, Go, etc.). Grâce aux preuves récursives, aux compilateurs de circuits personnalisés, à la continuation d'état et aux améliorations continues des algorithmes de preuve, Bonsai permet à quiconque de générer des preuves ZK hautes performances pour une variété d'applications.

RISC Zero zkVM: RISC Zero zkVM, lancé pour la première fois en avril 2022, peut prouver l'exécution correcte de code arbitraire, permettant aux développeurs de construire des applications ZK dans des langages matures tels que Rust et C++. Cette version constitue une avancée majeure dans le développement de logiciels ZK : zkVM rend possible la construction d'applications ZK sans construire de circuits et sans utiliser de langages personnalisés.

En permettant aux développeurs d'utiliser Rust et de tirer parti de la maturité de l'écosystème Rust, zkVM permet aux développeurs de construire rapidement des applications ZK significatives sans nécessiter de connaissances avancées en mathématiques ou en cryptographie.

Ces applications comprennent:

• JSON: Prouvez le contenu d'une entrée dans un fichier JSON tout en gardant les autres données privées.
• Où est Charlie : Prouvez que Charlie est présent dans le fichier JPG tout en gardant les autres parties de l'image privées.
• ZK Checkmate: Prouvez que vous avez vu un coup pour mater sans révéler le coup gagnant.
• Preuve de l'exploitation ZK : Preuve que vous pouvez exploiter un compte Ethereum sans révéler la vulnérabilité.
• Vérification de la signature ECDSA : Prouver la validité de la signature ECDSA.

Ces exemples sont mis en œuvre en tirant parti d'un écosystème logiciel mature : la plupart des outils Rust sont disponibles immédiatement dans Risc Zero zkVM. Être compatible avec Rust est un élément déterminant pour le monde logiciel ZK : des projets qui pourraient prendre des mois ou des années à construire sur d'autres plateformes peuvent être résolus facilement sur la plateforme de RISC Zero.

En plus d'être plus facile à construire, RISC Zero offre également des performances. zkVM dispose d'une accélération GPU de CUDA et Metal, et réalise la preuve parallèle de grands programmes grâce à la continuation.

Auparavant, Risc Zero a reçu 40 millions de dollars US dans le cadre d'un financement de série A de la part de Galaxy Digital, IOSG, RockawayX, Maven 11, Fenbushi Capital, Delphi Digital, Algaé Ventures, IOBC et d'autres institutions.

5.3 Brevis

Brevis, une filiale de Celer Network, se concentre sur la capture de données historiques multi-chaînes. Il donne aux contrats intelligents la capacité de lire l'ensemble de ses données historiques à partir de n'importe quelle chaîne et d'effectuer des calculs personnalisés complets sans confiance. Actuellement, il prend principalement en charge Ethereum POS, Comos Tendermint et BSC.

Interface de l'application: Le système actuel de Brevis prend en charge des preuves ZK efficaces et concises, fournissant les informations de chaîne source ZK suivantes prouvées pour les contrats d'application décentralisée (dApp) connectés à la blockchain:

1. Le hachage de bloc et les racines d’état, de transaction et de réception associées de n’importe quel bloc de la chaîne source.
2. Valeur de slot et métadonnées associées pour un bloc, un contrat, un slot spécifique sur la chaîne source.
3. Reçus de transaction et métadonnées associées pour toute transaction sur la chaîne source.
4. Entrées de transaction et métadonnées associées à toute transaction sur la chaîne source.
5. Tout message envoyé par une entité quelconque sur la chaîne source à une entité quelconque sur la chaîne cible.

Aperçu de l'architecture: L'architecture de Brevis se compose de trois parties principales:

1. réseau de répéteurs : Il synchronise les en-têtes de bloc et les informations on-chain de différentes blockchains et les transmet au réseau de validateurs pour générer des preuves de validité. Ensuite, il soumet les informations vérifiées et leurs preuves associées à la blockchain connectée.
2. réseau de vérification : Implémenter des circuits pour chaque protocole client léger de la blockchain, mises à jour des blocs, et générer des preuves des valeurs de créneaux demandées, des transactions, des reçus, et de la logique d'application intégrée. Pour minimiser le temps de preuve, les coûts et les coûts de vérification on-chain, un réseau de vérificateurs peut agréger les preuves distribuées générées simultanément. De plus, il peut utiliser des accélérateurs tels que les GPU, les FPGA et les ASIC pour améliorer l'efficacité.
3. Connexion des contrats de validation sur la blockchain : Recevoir des données vérifiées zk et des preuves associées générées par le réseau de validateurs, puis renvoyer les informations vérifiées au contrat d'application décentralisée (dApp).

Cette architecture intégrée permet à Brevis de garantir une efficacité et une sécurité élevées lors de la fourniture de données et de calculs inter-chaînes, permettant aux développeurs d'application décentralisée d'utiliser pleinement le potentiel de la blockchain. Grâce à cette architecture modulaire, Brevis peut fournir un accès aux données et des capacités de calcul entièrement décentralisés, flexibles et efficaces pour les contrats intelligents sur chaîne sur toutes les chaînes prises en charge. Cela offre un tout nouveau paradigme pour le développement d'applications décentralisées. Brevis a une large gamme de cas d'utilisation tels que la finance décentralisée basée sur les données, les zkBridges, l'acquisition d'utilisateurs sur chaîne, zkDID, l'abstraction des comptes sociaux, etc., augmentant l'interopérabilité des données.

5.4 Langrange

Langrange et Brevis ont une vision similaire, visant à améliorer l'interopérabilité entre plusieurs chaînes grâce à la pile de données ZK Big Data, qui peut créer des preuves d'état universelles sur toutes les blockchains principales. En s'intégrant au protocole Langrange, les applications peuvent soumettre des preuves agrégées de l'état multi-chaîne, qui peuvent ensuite être vérifiées de manière non interactive par des contrats sur d'autres chaînes.

Contrairement aux protocoles de pont traditionnels et de messagerie, le protocole Langrange ne repose pas sur un groupe spécifique de nœuds pour livrer des informations. Au lieu de cela, il tire parti de la cryptographie pour coordonner les preuves d'état inter-chaînes en temps réel, y compris celles soumises par des utilisateurs non fiables. Sous ce mécanisme, même si la source de l'information n'est pas digne de confiance, l'application de la technologie de chiffrement garantit la validité et la sécurité du certificat.

Le protocole Langrange sera initialement compatible avec tous les rollups L1 et L2 compatibles avec l'EVM. De plus, Langrange prévoit également de prendre en charge des chaînes non compatibles avec l'EVM dans un avenir proche, notamment, mais sans s'y limiter, Solana, Sui, Aptos et les chaînes publiques populaires basées sur le Cosmos SDK.

La différence entre le protocole Langrange et les protocoles traditionnels de pontage et de messagerie :

Les protocoles de pont traditionnels et de messagerie sont principalement utilisés pour transférer des actifs ou des messages entre une paire spécifique de chaînes. Ces protocoles s'appuient généralement sur un ensemble de nœuds intermédiaires pour confirmer l'en-tête de bloc le plus récent de la chaîne source sur la chaîne cible. Ce mode est principalement optimisé pour les relations chaîne unique-chaîne unique, basé sur l'état actuel des deux chaînes. En revanche, le protocole de Langrange fournit une méthode plus générale et flexible d'interaction entre chaînes, permettant aux applications d'interagir dans un écosystème blockchain plus large plutôt que d'être limitées à une relation chaîne unique-chaîne unique.

Le protocole Langrange optimise spécifiquement le mécanisme de démonstration de l'état des contrats inter-chaînes, plutôt que simplement la transmission d'informations ou d'actifs. Cette fonctionnalité permet au protocole Langrange de gérer efficacement des analyses complexes impliquant les états actuels et historiques des contrats, pouvant s'étendre sur plusieurs chaînes. Cette capacité permet à Langrange de prendre en charge une série de scénarios d'application complexes inter-chaînes, tels que le calcul de la moyenne mobile des prix des actifs sur les échanges décentralisés multi-chaînes (DEX), ou l'analyse de la volatilité des taux d'intérêt du marché monétaire sur plusieurs chaînes différentes.

Par conséquent, les preuves de l'état de Langrange peuvent être considérées comme des optimisations pour les relations de chaîne de nombreux à un (n-à-1). Dans cette relation inter-chaînes, une application décentralisée (DApp) sur une chaîne s'appuie sur l'agrégation de données d'état en temps réel et historiques provenant de plusieurs autres chaînes (n). Cette fonctionnalité élargit considérablement la fonctionnalité et l'efficacité des DApps, leur permettant d'agréger et d'analyser des données provenant de plusieurs blockchains différentes pour fournir des informations plus approfondies et plus complètes. Cette méthode est significativement différente de la relation traditionnelle à chaîne unique ou à chaîne un à un, et offre un champ d'application et un potentiel plus large pour les applications blockchain.

Langrange a déjà reçu des investissements de 1kx, Maven11, Lattice, CMT Digital et gumi crypto.

5.5 Hérodote

Herodotus est conçu pour fournir aux contrats intelligents un accès synchrone aux données on-chain à partir d’autres couches Ethereum. Ils pensent que la preuve de stockage peut unifier l’état de plusieurs cumuls et même permettre des lectures synchrones entre les couches Ethereum. Pour faire simple, il s’agit de la capture de données entre la chaîne principale EVM et le rollup. Prend actuellement en charge le réseau principal ETH, Starknet, Zksync, OP, Arbitrum et Polygon.

La Preuve de Stockage telle que définie par Hérodote est une preuve composite qui peut être utilisée pour vérifier la validité d'un ou de plusieurs éléments dans un grand ensemble de données, telles que les données de l'ensemble de la blockchain Ethereum.

Le processus de génération de preuve de stockage est grossièrement divisé en trois étapes :

Étape 1: Obtenez l'accumulateur de stockage d'en-tête de bloc des engagements vérifiables

• Cette étape vise à obtenir un "engagement" que nous pouvons vérifier. Si l'accumulateur ne contient pas encore le dernier en-tête de bloc dont nous avons besoin de prouver, nous devons d'abord prouver la continuité de la chaîne pour nous assurer de couvrir la plage de blocs contenant nos données cibles. Par exemple, si les données que nous voulons prouver sont dans le bloc 1 000 001 et que le contrat intelligent stocké dans l'en-tête de bloc ne couvre que le bloc 1 000 000, alors nous devons mettre à jour le stockage de l'en-tête.
• Si le bloc cible est déjà dans l’accumulateur, vous pouvez passer directement à l’étape suivante.

Étape 2: Prouver l'existence d'un compte spécifique

• Cette étape nécessite la génération d’une preuve d’inclusion de la part de l’État composé de tous les comptes du réseau Ethereum. La racine d’état est une partie importante de la dérivation du hachage d’engagement de bloc et fait également partie du stockage de l’en-tête. Il est important de noter que le hachage de l’en-tête de bloc dans l’accumulateur peut différer du hachage réel du bloc car une méthode de hachage différente peut avoir été utilisée pour plus d’efficacité.

Étape 3: Prouver des données spécifiques dans l'arbre de compte

• À cette étape, des preuves d'inclusion peuvent être générées pour des données telles que des nonces, des soldes, des racines de stockage ou codeHash. Chaque compte Ethereum dispose d'un triplet de stockage (arbre de Merkle Patricia), qui est utilisé pour sauvegarder les données de stockage du compte. Si les données que nous voulons prouver se trouvent dans le magasin de compte, alors nous devons générer des preuves d'inclusion supplémentaires pour les points de données spécifiques dans ce magasin.

Après avoir généré toutes les preuves d'inclusion nécessaires et les preuves computationnelles, une preuve de stockage complète est formée. Cette preuve est ensuite envoyée à la chaîne, où elle est vérifiée par rapport à un engagement initial unique (tel qu'un blockhash) ou à la racine MMR stockée dans l'en-tête. Ce processus garantit l'authenticité et l'intégrité des données tout en maintenant l'efficacité du système.

Herodotus est déjà soutenu par Geometry, Fabric Ventures, Lambda Class et Starkware.

5.6 HyperOracle

Hyper Oracle est spécialement conçu pour les oracles à connaissance nulle programmables afin de maintenir la sécurité et la décentralisation de la blockchain. Grâce à sa norme zkGraph, Hyper Oracle rend pratiques, vérifiables et à finalité rapide les données on-chain et les calculs équivalents on-chain. Il offre aux développeurs un tout nouveau moyen d'interagir avec la blockchain.

Le noeud zkOracle de Hyper Oracle est principalement composé de deux composants : zkPoS et zkWASM.

1. zkPoS: Ce composant est responsable de l'obtention de l'en-tête de bloc et de la racine de données de la blockchain Ethereum grâce à une preuve de connaissance nulle (zk) pour garantir la justesse du consensus Ethereum. zkPoS agit également en tant que circuit externe pour zkWASM.
2. zkWASM: Il utilise les données obtenues de zkPoS comme entrée clé pour exécuter zkGraphs. zkWASM est responsable de l'exécution de cartes de données personnalisées définies par zkGraphs et de la génération de preuves de connaissance nulle pour ces opérations. Les opérateurs des nœuds zkOracle peuvent sélectionner le nombre de zkGraphs qu'ils veulent exécuter, qui peut être de un à tous les zkGraphs déployés. Le processus de génération de preuves zk peut être délégué à un réseau distribué de prouveurs.

La sortie de zkOracle est des données hors chaîne, et les développeurs peuvent utiliser ces données via la norme zkGraph d'Hyper Oracle. Les données sont également accompagnées de certificats zk pour vérifier la validité des données et des calculs.

Pour maintenir la sécurité du réseau, le réseau Hyper Oracle ne nécessite qu'un seul nœud zkOracle. Cependant, plusieurs nœuds zkOracle peuvent exister dans le réseau, fonctionnant contre zkPoS et chaque zkGraph. Cela permet de générer des preuves zk en parallèle, améliorant considérablement les performances. En général, Hyper Oracle fournit aux développeurs une plateforme d'interaction blockchain efficace et sécurisée en combinant une technologie zk avancée et une architecture de nœud flexible.

En janvier 2023, Hyper Oracle a annoncé avoir reçu 3 millions de dollars américains dans le cadre d'un financement de pré-amorçage auquel ont participé conjointement Dao5, Sequoia China, Foresight Ventures et FutureMoney Group.

5.7 Chemin

Pado est une existence spéciale parmi les co-processeurs ZK. Les autres co-processeurs se concentrent sur la capture de données on-chain, tandis que Pado fournit un chemin pour capturer des données off-chain, dans le but de faire entrer toutes les données Internet dans les contrats intelligents. Il remplace la fonction de l'oracle dans une certaine mesure tout en garantissant la confidentialité et en éliminant le besoin de faire confiance aux sources de données externes.

5.8 Comparaison entre ZK coprocesseur et machine oracle

• Latence : L'oracle est asynchrone, donc la latence lors de l'accès aux données plates est plus longue par rapport au coprocesseur ZK.
• Coût : Alors que de nombreux oracles ne nécessitent pas de preuves computationnelles et sont donc moins coûteux, ils sont moins sécurisés. Stocker des preuves est plus coûteux, mais plus sécurisé.
• Sécurité : La sécurité maximale de la transmission des données est limitée par le niveau de sécurité de l’oracle lui-même. En revanche, le coprocesseur ZK correspond à la sécurité de la chaîne. De plus, les oracles sont vulnérables aux attaques de manipulation en raison de l’utilisation de preuves hors chaîne.

La figure ci-dessous montre le flux de travail de Pado :

Pado utilise des nœuds de cryptographie comme prouveurs en arrière-plan. Afin de réduire les hypothèses de confiance, l'équipe de Pado adoptera une stratégie évolutive et améliorera progressivement la décentralisation du service de prouveur. Le prouveur participe activement au processus de récupération et de partage des données des utilisateurs tout en prouvant l'authenticité des données des utilisateurs obtenues à partir des sources de données réseau. Ce qui le rend unique, c'est que Pado exploite MPC-TLS (Transport Layer Secure Multi-Party Computation) et IZK (Interactive Zero-Knowledge Proof) pour permettre aux prouveurs de prouver les données « aveuglément ». Cela signifie que les validateurs ne peuvent pas voir les données originales, y compris les informations publiques et privées des utilisateurs. Cependant, le vérificateur peut toujours garantir l'origine des données de toutes les données TLS transmises grâce à des méthodes cryptographiques.

1. MPC-TLS : TLS est un protocole de sécurité utilisé pour protéger la confidentialité et l'intégrité des données des communications Internet. Lorsque vous visitez un site Web et que vous voyez l'icône de "verrou" et "https" dans l'URL, cela signifie que votre visite est sécurisée par TLS. MPC-TLS imite la fonctionnalité d'un client TLS, permettant à l'authentificateur de Pado de collaborer avec le client TLS pour effectuer les tâches suivantes :
   Il est important de noter que ces opérations liées au TLS sont effectuées entre le client et le vérificateur par le biais du protocole de calcul à deux parties (2PC). La conception du MPC-TLS repose sur certaines technologies de chiffrement, telles que le circuit d'obfuscation (GC), la transmission d'oubli (OT), IZK, etc.
   • Établir une connexion TLS, y compris le calcul de la clé primaire, de la clé de session et des informations de vérification.
   • Exécutez des requêtes sur un canal TLS, y compris la génération de demandes chiffrées et le déchiffrement des réponses du serveur.
2. EXC: Preuve de connaissance nulle interactive est une preuve de connaissance nulle dans laquelle le prouveur et le vérificateur peuvent interagir. Dans le protocole IZK, le résultat du vérificateur est d'accepter ou de rejeter la revendication du prouveur. Comparé aux simples NIZKs (comme zk-STARKs ou zk-SNARKs), le protocole IZK présente plusieurs avantages, tels qu'une grande extensibilité aux grandes revendications, un faible coût computationnel, pas besoin de configuration de confiance et une utilisation minimisée de la mémoire.

Pado développe activement le crochet kyc d’Uniswap, recherchant plus de données sur les scénarios d'application on-chain, et a été sélectionné dans le premier groupe de programmes de bourses Consensys.

6. Perspectives futures

Le coprocesseur ZK permet à la blockchain de capturer plus de données et d'obtenir des ressources informatiques hors chaîne à moindre coût sans nuire à la décentralisation. Il découple également le flux de travail des contrats intelligents et augmente la scalabilité et l'efficacité.

Du seul côté de la demande, le coprocesseur ZK est une nécessité. Du seul point de vue de la piste DEX, ce crochet a un grand potentiel et peut faire beaucoup de choses. Si sushiswap n'a pas de crochets, il ne pourra pas rivaliser avec uniswap, et il sera très bientôt éliminé. Si le coprocesseur ZK n'est pas utilisé pour les crochets, le gaz sera très cher pour les développeurs et les utilisateurs, car les crochets introduisent une nouvelle logique et rendent les contrats intelligents plus complexes, ce qui est contre-productif. Donc pour l'instant, l'utilisation du coprocesseur zk est la meilleure solution. Que ce soit du point de vue de la capture de données ou du calcul, plusieurs méthodes ont des avantages et des inconvénients différents. Le coprocesseur adapté à des fonctions spécifiques est un bon coprocesseur. Le marché de l'informatique vérifiable sur chaîne a de larges perspectives et reflétera de nouvelles valeurs dans davantage de domaines.

Dans le développement futur de la blockchain, elle a le potentiel de briser les barrières traditionnelles de données du web2. L'information ne sera plus des îles isolées et atteindra une plus grande interopérabilité. Les co-processeurs ZK deviendront des middleware puissants pour garantir la sécurité, la confidentialité et des conditions sans confiance pour réduire les coûts et augmenter l'efficacité pour la capture, le calcul et la vérification des contrats intelligents, libérer le réseau de données, ouvrir plus de possibilités et devenir l'infrastructure pour les applications d'intention réelle et les agents d'IA sur la chaîne. Seulement si vous ne pouvez pas y penser, vous ne pouvez pas le faire.

Imagine un scénario dans le futur : en utilisant la haute fiabilité et la confidentialité de ZK pour la vérification des données, les chauffeurs de VTC en ligne peuvent construire un réseau d'agrégation en plus de leurs propres plateformes. Ce réseau de données peut couvrir Uber, Lyft, Didi, Bolt, etc., les chauffeurs de VTC en ligne peuvent fournir des données sur leurs propres plateformes. Tu prends une partie, je prends une partie, et on les rassemble sur la blockchain. Lentement, un réseau indépendant de leur propre plateforme est établi et agrégé. Toutes les données des chauffeurs sont devenues un grand agrégateur de données de VTC en ligne, et en même temps, cela peut rendre les chauffeurs anonymes et ne pas divulguer leur vie privée.

7. Indice

https://blog.axiom.xyz/qu-est-ce-qu-un-coprocesseur-zk/

https://crypto.mirror.xyz/BFqUfBNVZrqYau3Vz9WJ-BACw5FT3W30iUX3mPlKxtA

https://dev.risczero.com/api

https://blog.uniswap.org/uniswap-v4

https://blog.celer.network/2023/03/21/brevis-a-zk-omnichain-data-attestation-platform/

https://lagrange-labs.gitbook.io/lagrange-labs/overview/what-is-the-lagrange-protocol

https://docs.herodotus.dev/herodotus-docs/

https://docs.padolabs.org/

Avertissement：

1. Cet article est repris de [Gate.io]ForesightResearch]. Tous les droits d'auteur appartiennent à l'auteur original [Mike]. If there are objections to this reprint, please contact the Gate Learn et ils s’en occuperont rapidement.
2. Clause de non-responsabilité : Les vues et opinions exprimées dans cet article sont uniquement celles de l'auteur et ne constituent pas des conseils en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.