ZK : nouveaux cas d'utilisation, discussion approfondie sur les coprocesseurs et diverses solutions

Le concept de coprocesseur étant devenu populaire au cours des derniers mois, ce nouveau cas d'utilisation du ZK a commencé à susciter de plus en plus d'intérêt.

Cependant, nous avons constaté que la plupart des gens sont encore relativement peu familiarisés avec le concept de coprocesseur, en particulier avec le positionnement précis des coprocesseurs - ce qu'est un coprocesseur et ce qu'il n'est pas est encore relativement vague. Quant à la comparaison des solutions techniques de plusieurs pistes de co-processeurs sur le marché, personne n'a encore fait le tri de manière systématique. Cet article espère donner au marché et aux utilisateurs une compréhension plus claire de la piste du coprocesseur.

1. Qu'est-ce que le coprocesseur et qu'est-ce qu'il n'est pas ?

Si l'on vous demandait d'expliquer les coprocesseurs à un non-technicien ou à un développeur en une seule phrase, comment le décririez-vous ?

Je pense que ce qu'a dit M. Dong Mo est très proche de la réponse standard - pour dire les choses crûment, un coprocesseur consiste à "donner aux contrats intelligents la capacité d'effectuer des analyses Dune".

Comment déconstruire cette phrase ?

Imaginez le scénario dans lequel nous utilisons Dune - Vous voulez faire de la LP dans Uniswap V3 pour gagner des frais de gestion, vous ouvrez donc Dune et vous trouvez le volume récent de transactions de diverses paires sur Uniswap, le TAP des frais de gestion dans les 7 derniers jours, et les paires de transactions principales Les plages de fluctuation supérieures et inférieures, etc...

Ou peut-être que lorsque StepN est devenu populaire, vous avez commencé à spéculer sur les chaussures et ne saviez pas quand les vendre, alors vous avez regardé les données StepN sur Dune tous les jours, le volume quotidien des transactions, le nombre de nouveaux utilisateurs, le prix plancher des chaussures... et vous avez planifié de le faire une fois qu'il y aurait de la croissance. Si la tendance se ralentit ou diminue, courez vite.

Bien entendu, vous n'êtes pas le seul à observer ces données, les équipes de développement d'Uniswap et de StepN y prêtent également attention.

Ces données sont très significatives - elles peuvent non seulement aider à juger de l'évolution des tendances, mais aussi les utiliser pour créer davantage d'astuces, à l'instar de l'approche "big data" couramment utilisée par les grandes entreprises de l'internet.

Par exemple, en fonction du style et du prix des chaussures que les utilisateurs achètent et vendent souvent, des chaussures similaires sont recommandées.

Par exemple, un "programme de récompense de la fidélité des utilisateurs" sera lancé en fonction de la durée de détention de Creation Shoes par les utilisateurs, afin d'offrir aux utilisateurs fidèles davantage de largages ou d'avantages.

Par exemple, un plan VIP similaire à Cex peut être lancé sur la base du TVL ou du volume d'échange fourni par LP sur Uniswap ou Trader, donnant lieu à une réduction des frais de transaction de Trader ou à une augmentation de la part des frais de LP...

C'est à ce moment-là que le problème se pose : les big data + l'IA des grandes entreprises de l'internet sont essentiellement une boîte noire. Ils peuvent faire ce qu'ils veulent. Les utilisateurs ne le voient pas et s'en moquent.

Mais ici, à Web3, la transparence et la confiance sont notre politiquement correct naturel, et nous rejetons les boîtes noires !

Ainsi, lorsque vous voudrez réaliser le scénario ci-dessus, vous serez confronté à un dilemme : soit vous y parvenez par des moyens centralisés, en utilisant " manuellement " Dune pour compter les données de l'indice en arrière-plan, puis en le déployant et en le mettant en œuvre ; soit vous écrivez un ensemble de contrats intelligents pour capturer automatiquement ces données sur la chaîne, effectuer les calculs, et déployer automatiquement les points.

La première vous conduira à des problèmes de confiance "politiquement incorrects".

Les frais d'essence générés par ce dernier sur la chaîne atteindront un chiffre astronomique, et votre portefeuille (côté projet) ne peut pas se le permettre.

C'est le moment pour le coprocesseur d'entrer en scène. Combinez les deux méthodes décrites ci-dessus et utilisez en même temps l'étape du "backend manuel" pour "auto-certifier l'innocence" par des moyens techniques. En d'autres termes, utilisez la technologie ZK pour "indexer + La partie "calcul" "prouve l'innocence", puis la transmet au contrat intelligent. De cette manière, le problème de la confiance est résolu et les frais d'essence massifs disparaissent. Parfait !

Pourquoi l'appelle-t-on "coprocesseur" ? En fait, cela vient du "GPU" dans l'histoire du développement du Web2.0. La raison pour laquelle le GPU a été introduit en tant que matériel informatique distinct et a existé indépendamment du CPU à l'époque était que son architecture pouvait traiter certains calculs qui étaient fondamentalement difficiles à traiter pour le CPU, tels que les calculs parallèles répétés à grande échelle, les calculs graphiques, etc. C'est précisément grâce à cette architecture "coprocesseur" que nous disposons aujourd'hui de merveilleux films en images de synthèse, de jeux, de modèles d'IA, etc. Aujourd'hui, plusieurs équipes de co-processeurs espèrent également introduire cette architecture dans le Web3.0. La blockchain est ici similaire à l'unité centrale du Web3.0. Qu'il s'agisse de L1 ou de L2, ils sont intrinsèquement inadaptés à ces tâches de "données lourdes" et de "logique de calcul complexe", c'est pourquoi un coprocesseur blockchain est introduit pour aider à gérer ces calculs, ce qui élargit considérablement les possibilités d'applications blockchain.

Le rôle du coprocesseur peut donc se résumer à deux choses :

1. Obtenez les données de la blockchain et utilisez ZK pour prouver que les données que j'ai obtenues sont vraies et non falsifiées ;
2. Effectuez les calculs correspondants sur la base des données que je viens d'obtenir et utilisez à nouveau ZK pour prouver que les résultats que j'ai calculés sont vrais et non falsifiés. Les résultats du calcul peuvent être appelés par le contrat intelligent "Low Fee + Trustless".

Il y a quelque temps, Starkware a présenté un concept populaire appelé Storage Proof, également appelé State Proof. Il s'agit essentiellement de l'étape 1, représentée par Hérodote, Langrage, etc. L'objectif technique de nombreux ponts inter-chaînes basés sur la technologie ZK se situe également à l'étape 1. 1 sur.

Le coprocesseur n'est rien d'autre que l'étape 1 suivie de l'étape 2. Après avoir extrait les données sans confiance, faites un calcul sans confiance et c'est tout.

Ainsi, pour utiliser un terme relativement technique afin de le décrire avec précision, le coprocesseur devrait être un surensemble de la preuve de stockage/preuve d'état et un sous-ensemble de l'informatique vérifiable.

Il convient de noter que le coprocesseur n'est pas Rollup.

Techniquement parlant, la preuve ZK de Rollup est similaire à l'étape 2 ci-dessus, et le processus de l'étape 1 "obtenir des données" est directement mis en œuvre par Sequencer. Même un séquenceur décentralisé n'utilise qu'un mécanisme de concurrence ou de consensus pour y parvenir. Prenez, au lieu de Storage Proof, cette forme de ZK. Le plus important est qu'en plus de la couche de calcul, ZK Rollup doit également mettre en œuvre une couche de stockage similaire à la blockchain L1. Ce stockage est permanent, alors que le coprocesseur ZK est "sans état". Une fois le calcul terminé, aucun statut "Tous" n'est conservé.

Du point de vue des scénarios d'application, le coprocesseur peut être considéré comme un plug-in de service pour toutes les couches 1 et 2, tandis que le Rollup recrée une couche d'exécution pour aider à étendre la couche de règlement.

2. Pourquoi dois-je utiliser ZK ? Peut-on utiliser l'OP ?

Après avoir lu ce qui précède, vous vous demandez peut-être si ZK doit être utilisé comme coprocesseur. Cela ressemble tellement à un "Graphique avec ZK ajouté", et nous ne semblons pas avoir de "gros doutes" sur les résultats du Graphique.

En effet, lorsque vous utilisez Graph, il n'est pas question d'argent réel. Ces index offrent des services hors chaîne. L'interface utilisateur frontale affiche le volume et l'historique des transactions, etc. Les données peuvent être fournies par de multiples fournisseurs d'index de données tels que Graph, Alchemy, Zettablock, etc., mais ces données ne peuvent pas être réintégrées dans le contrat intelligent, car une fois que vous les réintégrerez, vous ajouterez une confiance supplémentaire dans le service d'indexation. Lorsque les données sont liées à de l'argent réel, en particulier à des volumes importants de TVL, cette confiance supplémentaire devient importante. Imaginez que la prochaine fois qu'un ami vous demandera de lui prêter 100 yuans, vous pourrez le faire sans sourciller. Oui, et si je vous demande d'emprunter 10 000 yuans, voire 1 million de yuans ?

Mais encore une fois, devons-nous vraiment utiliser ZK pour co-traiter tous les scénarios susmentionnés ? Après tout, nous avons deux itinéraires techniques, OP et ZK, dans le Rollup. Le ZKML, qui a connu une popularité récente, reprend également le concept OPML des itinéraires secondaires correspondants. Le coprocesseur a-t-il également une branche d'OP, telle que OP-Coprocesseur ?

En fait, il y en a vraiment un - mais nous gardons les détails spécifiques confidentiels pour le moment, et nous publierons bientôt des informations plus détaillées.

3. Quel est le meilleur coprocesseur - Comparaison de plusieurs solutions techniques de coprocesseurs courantes sur le marché

Brevis

L'architecture de Brevis se compose de trois éléments : zkFabric, zkQueryNet et zkAggregatorRollup.

Vous trouverez ci-dessous un diagramme de l'architecture de Brevis :

zkFabric : Rassemble les en-têtes de blocs de toutes les blockchains connectées et génère des preuves de consensus ZK prouvant la validité de ces en-têtes de blocs. Grâce à zkFabric, Brevis met en œuvre un coprocesseur interopérable pour plusieurs chaînes, qui permet à une blockchain d'accéder à toutes les données historiques d'une autre blockchain.

zkQueryNet : Une place de marché ouverte pour le moteur de requête ZK qui accepte les requêtes de données des dApps et les traite. Les requêtes de données traitent ces requêtes en utilisant les en-têtes de blocs vérifiés de zkFabric et génèrent des preuves de requêtes ZK. Ces moteurs disposent à la fois de fonctions hautement spécialisées et de langages d'interrogation généraux pour répondre aux différents besoins des applications.

zkAggregatorRollup : Une blockchain convolutionnelle ZK qui agit comme une couche d'agrégation et de stockage pour zkFabric et zkQueryNet. Il vérifie les preuves des deux composants, stocke les données vérifiées et transmet sa racine d'état zk-validated à toutes les blockchains connectées.

Le ZK Fabric est un élément clé de la production de preuves pour l'en-tête de bloc. Il est très important d'assurer la sécurité de cette partie. Vous trouverez ci-dessous le schéma d'architecture de zkFabric :

Le client léger de zkFabric, basé sur une preuve de connaissance zéro (ZKP), est totalement sans confiance, sans dépendre d'une entité de vérification externe. Il n'est pas nécessaire de s'appuyer sur une entité de vérification externe, car sa sécurité provient entièrement de la blockchain sous-jacente et de preuves mathématiquement fiables.

Le réseau zkFabric Prover met en œuvre des circuits pour le protocole lightclient de chaque blockchain et génère des preuves de validité pour les en-têtes de blocs. Les prouveurs peuvent tirer parti d'accélérateurs tels que les GPU, les FPGA et les ASIC pour minimiser le temps et le coût de la preuve.

zkFabric s'appuie sur les hypothèses de sécurité de la blockchain et des protocoles cryptographiques sous-jacents et sur les hypothèses de sécurité des protocoles cryptographiques sous-jacents. Toutefois, pour garantir l'efficacité de zkFabric, il faut au moins un relayeur honnête pour synchroniser la fourche correcte. Par conséquent, zkFabric utilise un réseau de relais décentralisé au lieu d'un seul relais pour optimiser l'efficacité de zkFabric. Ce réseau de relais peut s'appuyer sur des structures existantes, telles que le réseau des gardes d'État dans le réseau Celer.

Attribution des prouveurs : Le réseau de prouveurs est un réseau de prouveurs ZKP décentralisé qui sélectionne un prouveur pour chaque tâche de génération de preuve et paie des frais à ces prouveurs.

Déploiement actuel :

Les protocoles clients légers actuellement mis en œuvre pour diverses blockchains, notamment Ethereum PoS, Cosmos Tendermint et BNB Chain, servent d'exemples et de preuves de concept.

Brevis a actuellement coopéré avec le crochet uniswap, ce qui permet d'ajouter des piscines uniswap personnalisées. Cependant, par rapport à CEX, UnisWap ne dispose pas encore de capacités de traitement de données efficaces pour créer des projets qui reposent sur des données de transactions d'utilisateurs volumineuses (tels que des programmes de fidélisation basés sur le volume de transactions). Fonction.

Avec l'aide de Brevis, hook a relevé le défi. Les crochets peuvent désormais lire l'ensemble des données de la chaîne d'historique d'un utilisateur ou d'un partenaire et effectuer des calculs personnalisables en toute confiance.

Hérodote

Herodotus est un puissant intergiciel d'accès aux données qui fournit aux contrats intelligents les fonctions suivantes pour accéder de manière synchronisée aux données actuelles et historiques de la chaîne à travers la couche Ethereum :

1. Les états L1 des L2
2. Les états L2 des L1 et des autres L2
3. États L3/App-Chain vers L2 et L1

Hérodote a proposé le concept de preuve de stockage, qui combine la preuve d'inclusion (confirmant l'existence de données) et la preuve computationnelle (vérifiant l'exécution d'un flux de travail en plusieurs étapes) pour prouver qu'un grand ensemble de données (comme l'ensemble de la blockchain ou du rollup Ethereum) ou la validité de plusieurs éléments.

Le cœur de la blockchain est la base de données, dans laquelle les données sont cryptées et protégées à l'aide de structures de données telles que les arbres de Merkle et les arbres de Merkle Patricia. La particularité de ces structures de données est qu'une fois que les données y sont enregistrées de manière sécurisée, des preuves peuvent être générées pour confirmer que les données sont bien contenues dans la structure.

L'utilisation d'arbres de Merkle et d'arbres Merkle Patricia renforce la sécurité de la blockchain Ethereum. En hachant cryptographiquement les données à chaque niveau de l'arbre, il est pratiquement impossible de modifier les données sans être détecté. Toute modification d'un point de données nécessite de changer le hachage correspondant de l'arbre pour le hachage de la racine, qui est visible publiquement dans l'en-tête de la blockchain. Cette caractéristique fondamentale de la blockchain offre un niveau élevé d'intégrité et d'immutabilité des données.

Deuxièmement, ces arbres permettent une vérification efficace des données par le biais de preuves d'inclusion. Par exemple, pour vérifier l'inclusion d'une transaction ou l'état d'un contrat, il n'est pas nécessaire d'effectuer une recherche dans l'ensemble de la blockchain Ethereum, mais uniquement dans le chemin de l'arbre de Merkle concerné.

La preuve de stockage telle que définie par Hérodote est une fusion :

1. Preuves de confinement : Ces preuves confirment l'existence de données spécifiques dans une structure de données cryptographiques (telle qu'un arbre de Merkle ou un arbre Merkle Patricia), garantissant que les données en question sont effectivement présentes dans l'ensemble de données.
2. Preuve informatique : Vérifier l'exécution d'un flux de travail en plusieurs étapes, en prouvant la validité d'un ou de plusieurs éléments dans un vaste ensemble de données, comme l'ensemble de la blockchain Ethereum ou un agrégat. En plus d'indiquer la présence de données, ils vérifient également les transformations ou les opérations appliquées à ces données.
3. Preuves sans connaissance : Simplifiez la quantité de données avec lesquelles les contrats intelligents doivent interagir. Les preuves à connaissance nulle permettent aux contrats intelligents de confirmer la validité d'une demande sans traiter toutes les données sous-jacentes.

Flux de travail

1. obtenir le hachage du bloc

Chaque donnée de la blockchain appartient à un bloc spécifique. Le hachage du bloc sert d'identifiant unique du bloc et résume tout son contenu dans l'en-tête du bloc. Dans le flux de travail de la preuve de stockage, nous devons d'abord déterminer et vérifier le hachage du bloc contenant les données qui nous intéressent. Il s'agit de la première étape de l'ensemble du processus.

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. Pour ce faire, l'en-tête du bloc associé au hachage du bloc obtenu à l'étape précédente doit être haché. Le hachage de l'en-tête du bloc fourni est ensuite comparé au hachage du bloc résultant :

Il y a deux façons d'obtenir le hachage :

1. Utilisez l'opcode BLOCKHASH pour récupérer les informations suivantes
2. Interroger le hachage des blocs qui ont été vérifiés dans l'historique à partir de l'accumulateur de hachage de blocs.

Cette étape permet de s'assurer que l'en-tête du bloc traité est authentique. Une fois cette étape terminée, le contrat intelligent peut accéder à n'importe quelle valeur dans l'en-tête du bloc.

3. déterminer les racines nécessaires (facultatif)

Une fois l'en-tête du bloc en main, nous pouvons nous pencher sur son contenu, en particulier :

stateRoot : Un condensé cryptographique de l'état complet de la blockchain au moment où la blockchain s'est produite.

receiptsRoot : Résumé chiffré de tous les résultats de transaction (reçus) dans le bloc.

TransactionsRoot : Un condensé cryptographique de toutes les transactions effectuées dans le bloc.

peut être décodée, ce qui permet de vérifier si un compte, un reçu ou une transaction spécifique est inclus dans le bloc.

4. valider les données par rapport à la racine sélectionnée (facultatif)

Avec la racine que nous avons sélectionnée, et compte tenu du fait qu'Ethereum utilise une structure Merkle-Patricia Trie, nous pouvons utiliser la preuve d'inclusion de Merkle pour vérifier que les données existent dans l'arbre. Les étapes de vérification varient en fonction des données et de leur profondeur dans le bloc.

Réseaux actuellement pris en charge :

1. D'Ethereum à Starknet
2. De Ethereum Goerli à Starknet Goerli
3. De Ethereum Goerli à zkSync Era Goerli

Axiome

Axiom permet aux développeurs d'interroger les en-têtes de blocs, les valeurs de compte ou de stockage à partir de l'historique complet d'Ethereum. AXIOM introduit une nouvelle méthode de liaison basée sur la cryptographie. Tous les résultats renvoyés par Axiom sont vérifiés sur la chaîne grâce à des preuves à zéro connaissance, ce qui signifie que les contrats intelligents peuvent les utiliser sans hypothèses de confiance supplémentaires.

Axiom a récemment publié Halo2-repl, un REPL halo2 basé sur un navigateur et écrit en Javascript. Cela permet aux développeurs d'écrire des circuits ZK en utilisant simplement du Javascript standard sans avoir à apprendre un nouveau langage comme Rust, à installer des bibliothèques de preuves ou à gérer des dépendances.

Axiom se compose de deux éléments technologiques principaux :

1. AxiomV1 - Cache de la blockchain Ethereum, en commençant par Genesis.
2. AxiomV1Query - Un contrat intelligent qui exécute des requêtes contre AxiomV1.

Mise en cache des hachages de blocs dans AxiomV1 :

Les contrats intelligents AxiomV1 cachent les hachages de blocs Ethereum depuis le bloc genesis sous deux formes :

Tout d'abord, la racine Keccak Merkle de 1024 blocs consécutifs est mise en cache. Ces racines de Merkle sont mises à jour au moyen de preuves ZK, en vérifiant que le hachage de l'en-tête de bloc forme une chaîne d'engagement se terminant par l'un des 256 blocs les plus récents directement accessibles à l'EVM ou par le hachage d'un bloc qui existe déjà dans le cache de l'AxiomV1.

Deuxièmement, Axiom stocke la chaîne de montagnes Merkle de ces racines Merkle à partir du bloc de genèse. La chaîne de montagnes Merkle est construite en mettant à jour la première partie du cache, la racine Keccak Merkle.

Exécutez la requête dans AxiomV1Query :

Le contrat intelligent AxiomV1Query est utilisé pour les requêtes par lots afin de permettre un accès sans confiance aux en-têtes de blocs Ethereum historiques, aux comptes et aux données arbitraires stockées dans les comptes. Les requêtes peuvent être effectuées sur la chaîne et sont complétées sur la chaîne par des preuves ZK contre les hachages de blocs mis en cache par AxiomV1.

Ces preuves ZK vérifient si les données pertinentes de la chaîne se trouvent directement dans l'en-tête du bloc ou dans le triangle de compte ou de stockage du bloc, en vérifiant la preuve d'inclusion (ou de non-inclusion) du triangle Merkle-Patricia.

Nexus

Nexus tente d'utiliser des preuves à zéro connaissance pour construire une plateforme universelle d'informatique en nuage vérifiable. Actuellement, il est agnostique en matière d'architecture de machine et supporte risc 5/ WebAssembly/ EVM. Nexus utilise le système de preuve de Supernova. L'équipe a testé que la mémoire nécessaire pour générer la preuve est de 6 Go. À l'avenir, il sera optimisé sur cette base afin que les ordinateurs ordinaires puissent générer des preuves.

Pour être plus précis, l'architecture est divisée en deux parties :

1. Nexus zero : Un réseau informatique en nuage décentralisé et vérifiable, alimenté par des preuves à connaissance nulle et une zkVM universelle.
2. Nexus : Un réseau informatique en nuage décentralisé et vérifiable, alimenté par des calculs multipartites, la réplication des machines d'état et une machine virtuelle universelle WASM.

Les applications Nexus et Nexus Zero peuvent être écrites dans des langages de programmation traditionnels, actuellement Rust, et d'autres langages à venir.

Les applications Nexus s'exécutent sur un réseau informatique en nuage décentralisé, qui est essentiellement une "blockchain sans serveur" à usage général, connectée directement à Ethereum. Par conséquent, les applications Nexus n'héritent pas de la sécurité d'Ethereum, mais en échange, elles ont accès à une plus grande puissance de calcul (calcul, stockage et E/S événementielles) en raison de la taille réduite de son réseau. Les applications Nexus s'exécutent sur un nuage dédié qui atteint un consensus interne et fournit des "preuves" de calcul vérifiables (plutôt que des preuves réelles) grâce à des signatures de seuil vérifiables à l'échelle du réseau au sein d'Ethereum.

Les applications Nexus Zero héritent de la sécurité d'Ethereum, car il s'agit de programmes universels avec des preuves à zéro connaissance qui peuvent être vérifiées sur la chaîne sur la courbe elliptique BN-254.

Puisque Nexus peut exécuter n'importe quel binaire WASM déterministe dans un environnement répliqué, il devrait être utilisé comme source de preuve de validité/dispersion/tolérance aux pannes pour les applications générées, y compris les séquenceurs zk-rollup, les séquenceurs optimistes rollup, et d'autres serveurs de preuve, tels que le zkVM de Nexus Zero lui-même.

Clause de non-responsabilité：

1. Cet article est repris de[panewslab]. Tous les droits d'auteur appartiennent à l'auteur original[ABCDE]. Si vous avez des objections à cette réimpression, veuillez contacter l'équipe de Gate Learn, qui s'en chargera rapidement.
2. Clause de non-responsabilité : Les points de vue et les opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent pas un conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe de Gate Learn. Sauf mention contraire, il est interdit de copier, distribuer ou plagier les articles traduits.