1. Qu'est-ce qu'un co-processeur et qu'est-ce que ce n'est pas?

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

Je pense que ce que le Dr Dong Mo a dit pourrait être très proche de la réponse standard - pour le dire franchement, le co-processeur donne à contrat intelligent la capacité de faire de l'analyse de Dune.

Comment déconstruire cette phrase?

Imaginez le scénario où nous utilisons Dune - vous voulez faire du LP sur Uniswap V3 pour gagner des frais de traitement, donc vous ouvrez Dune et trouvez le volume de trading récent de diverses paires de trading sur Uniswap, le Taux Annuel Effectif (APR) des frais de traitement des 7 derniers jours, et les plages de fluctuation supérieure et inférieure des paires de trading principales, etc…

Ou peut-être que lorsque StepN est devenu populaire, vous avez commencé à spéculer sur les chaussures, et vous n'étiez pas sûr quand les vendre, alors vous fixiez les données de StepN sur Dune chaque jour, le volume des transactions quotidiennes, le nombre de nouveaux utilisateurs, le prix plancher des chaussures... et aviez prévu de vendre une fois qu'il y aurait de la croissance. Si la tendance ralentit ou baisse, agissez rapidement.

Bien sûr, vous ne regardez peut-être pas seulement ces données, mais les équipes de développement d'Uniswap et de StepN portent également une attention particulière à ces données.

Ces données sont très significatives - elles peuvent non seulement aider à juger des changements de tendances, mais aussi les utiliser pour créer plus d'astuces, tout comme l'approche du "big data" communément utilisée par les grandes entreprises 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, en fonction de la durée pendant laquelle les utilisateurs conservent les chaussures Chuangshi, un « programme de récompenses de fidélité des utilisateurs » sera lancé pour offrir aux utilisateurs fidèles plus de largages aériens ou d'avantages.

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

……

À ce moment, le problème se pose - lorsque les grandes entreprises Internet jouent avec les mégadonnées + l'IA, c'est essentiellement une boîte noire. Elles peuvent faire ce qu'elles veulent. Les utilisateurs ne peuvent pas le voir et s'en fichent.

Mais du côté de Web3, la transparence et la confiance sans faille sont notre politiquement correct naturel, et nous rejetons les boîtes noires !

Donc, lorsque vous souhaitez réaliser le scénario ci-dessus, vous serez confronté à un dilemme - soit vous pouvez le réaliser par des moyens centralisés, "manuellement" utiliser Dune pour compter les données d'index en arrière-plan, puis les déployer et les mettre en œuvre; soit vous pouvez écrire des contrats intelligents pour capturer automatiquement ces données sur la chaîne, effectuer des calculs et déployer automatiquement des points.

Le premier peut vous laisser avec des problèmes de confiance « politiquement incorrects ».

Les frais de gaz générés par ce dernier sur la chaîne seront un chiffre astronomique, et votre portefeuille (côté projet) ne pourra pas se le permettre.

C'est le moment pour le co-processeur de monter sur scène. Combinez les deux méthodes utilisées précédemment, et utilisez en même temps l'étape de "manuel en arrière-plan" pour "s'autoprouver innocent" par des moyens techniques. Autrement dit, utilisez la technologie ZK pour "index +" hors de la chaîne. La partie "calcul" s'"autoprouve innocente", puis la transmet au smart contract. De cette façon, le problème de confiance est résolu, et les frais de gaz massifs disparaissent. Parfait !

Pourquoi est-il appelé un “coprocesseur”? En fait, cela vient du “GPU” dans l'histoire du développement de Web2.0. La raison pour laquelle le GPU a été introduit en tant que matériel informatique séparé et existait indépendamment du CPU à l'époque était que son architecture de conception pouvait gérer certaines calculs qui étaient fondamentalement difficiles à gérer pour le CPU, tels que les calculs parallèles à grande échelle, les calculs graphiques, etc. . C'est précisément en raison de cette architecture de “co-processeur” que nous avons aujourd'hui de merveilleux films CG, des jeux, des modèles d'IA, etc., donc cette architecture de co-processeur est en fait un bond en avant dans l'architecture informatique. Maintenant, diverses équipes de co-processeurs espèrent également introduire cette architecture dans Web3.0. La blockchain ici est similaire au CPU de Web3.0. Que ce soit L1 ou L2, ils ne conviennent pas intrinsèquement à de telles tâches de “données lourdes” et de “logique de calcul complexe”, donc un co-processeur de blockchain est introduit pour aider à gérer de tels calculs, ce qui permet d'élargir considérablement les possibilités des applications blockchain.

Donc ce que fait le coprocesseur peut être résumé en deux choses :

1. Obtenez les données de la blockchain et prouvez grâce à ZK que les données que j'ai obtenues sont vraies et non falsifiées;
2. Faites des calculs correspondants basés sur les 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 des calculs peuvent être appelés par le smart contract “Low Fee + Trustless”.

Il y a quelque temps, Starkware avait un concept populaire appelé Preuve de Stockage, également appelé Preuve d'État. Cela fait essentiellement l'étape 1, représentée par Hérodote, Langrage, etc. La focalisation technique de nombreux ponts inter-chaînes basés sur la technologie ZK se trouve également dans l'étape 1. 1 sur.

Le co-processeur n'est rien de plus que d'ajouter l'étape 2 après l'achèvement de l'étape 1. Après avoir extrait les données sans confiance, il peut ensuite effectuer un calcul sans confiance.

Donc, pour utiliser un terme relativement technique pour le décrire précisément, le coprocesseur devrait être un sur-ensemble de la Preuve de Stockage/Preuve d'État et un sous-ensemble de Calcul Vérifiable.

Il est à 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 "obtention des données" est directement implémenté via le Séquenceur. Même un Séquenceur décentralisé utilise uniquement un certain type de mécanisme de compétition ou de consensus. Prenez-le à la place de la Preuve de Stockage sous forme de ZK. Ce qui est plus important, c'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, tandis que le Coprocesseur ZK est "sans état". Après la fin du calcul, aucun état 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 tous les Layer1/Layer2, tandis que Rollup recrée une couche d'exécution pour aider à étendre la couche de règlement.

2. Pourquoi devez-vous utiliser ZK? Est-il possible d'utiliser OP?

Après avoir lu ce qui précède, vous pouvez avoir un doute, est-ce que cela doit être fait avec ZK comme coprocesseur? Cela ressemble tellement à un “Graph avec ZK ajouté”, et nous n'avons pas l'air d'avoir de “grands doutes” sur les résultats sur le Graph.

C'est parce que lorsque vous utilisez Graph, vous n'impliquez pas vraiment d'argent réel. Ces indexes servent des services hors chaîne. Ce que vous voyez sur l'interface utilisateur en front-end sont le volume des transactions, l'historique des transactions, etc. Les données peuvent être fournies par plusieurs 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égrez, 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 à un TVL de gros volume, cette confiance supplémentaire devient importante. Imaginez que la prochaine fois qu'un ami vous demande d'emprunter 100 yuans, vous pourriez simplement le lui prêter sans sourciller. Oui, et si je vous demandais 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 ci-dessus? Après tout, nous avons deux voies techniques, OP et ZK, dans Rollup. Le ZKML récemment populaire a également le concept OPML de routes de branches correspondantes. On se demande, est-ce que le coprocesseur a aussi une branche de OP, comme OP-Coprocessor?

En fait, il y en a - 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 coprocesseur est meilleur - Comparaison de plusieurs solutions technologiques de coprocesseur courantes sur le marché

1. Brevis:

L'architecture de Brevis se compose de trois composants : zkFabric, zkQueryNet et zkAggregatorRollup.

Ce qui suit est un diagramme d'architecture Brevis :

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

zkQueryNet: Un marché moteur de requête ZK ouvert 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ête ZK. Ces moteurs ont à la fois des fonctions hautement spécialisées et des langages de requête généraux pour répondre aux différents besoins des applications.

zkAggregatorRollup: Un blockchain convolutif ZK qui agit comme 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 valide son état racine zk à tous les blockchains connectés.

ZK Fabric est une partie clé de la génération de la preuve pour l'en-tête de bloc. Il est très important de garantir la sécurité de cette partie. Ce qui suit est le diagramme d'architecture de zkFabric :

Le client léger basé sur la preuve de connaissance nulle (ZKP) de zkFabric le rend totalement sans confiance sans avoir besoin de s'appuyer sur une entité de vérification externe. Il n'est pas nécessaire de compter 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 de preuves zkFabric Prover implémente une logique pour le protocole lightclient de chaque blockchain, et le réseau génère des preuves de validité pour les en-têtes de bloc. 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 du protocole de chiffrement sous-jacent, ainsi que sur les hypothèses de sécurité du protocole de chiffrement sous-jacent. Cependant, pour assurer l'efficacité de zkFabric, au moins un relais honnête est nécessaire pour synchroniser la bonne fourchette. Par conséquent, zkFabric adopte 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 tirer parti des structures existantes, telles que le réseau de garde d'état dans le réseau Celer.

Allocation du Prover: Le réseau de prover est un réseau de prover ZKP décentralisé qui sélectionne un prover pour chaque tâche de génération de preuve et paie des frais à ces provers.

Déploiement actuel :

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

Brevis a actuellement coopéré avec un crochet uniswap, ce qui ajoute considérablement des pools uniswap personnalisés. Cependant, par rapport à CEX, UnisWap manque encore de capacités de traitement des données efficaces pour créer des projets qui dépendent de grandes données de transaction utilisateur (comme des programmes de fidélité basés sur le volume de transaction). Fonction.

Avec l'aide de Brevis, hook a résolu le défi. Les hooks peuvent maintenant lire les données de l'historique complet de la chaîne d'un utilisateur ou d'un LP et effectuer des calculs personnalisables de manière totalement sans confiance.

1. Hérodote

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

États L1 des L2s

États L2 à la fois des L1 et d'autres L2

Les états de la chaîne d'applications L3 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 de calcul (vérifiant l'exécution d'un workflow à plusieurs étapes) pour prouver qu'un grand ensemble de données (tel que l'ensemble de la blockchain Ethereum ou un rollup) 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. Ce qui est unique à propos de ces structures de données, c'est que une fois que des données sont sécurisement engagées auprès d'elles, des preuves peuvent être générées pour confirmer que les données sont contenues dans la structure.

L'utilisation des arbres de Merkle et des arbres de Merkle Patricia renforce la sécurité de la blockchain Ethereum. En hachant de manière cryptographique les données à chaque niveau de l'arbre, il est presque 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 sur l'arbre jusqu'au hachage racine, qui est publiquement visible dans l'en-tête de la blockchain. Cette fonctionnalité fondamentale de la blockchain offre un haut niveau d'intégrité et d'immutabilité des données.

Deuxièmement, ces arbres permettent une vérification efficace des données via des preuves d'inclusion. Par exemple, lors de la vérification de l'inclusion d'une transaction ou de l'état d'un contrat, il n'est pas nécessaire de rechercher l'ensemble de la blockchain Ethereum mais seulement le chemin dans l'arbre de Merkle pertinent.

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

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

Workflow :

1. Obtenir le hachage de bloc

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

1. Obtenir l'en-tête de bloc

Une fois que le hachage de bloc pertinent est obtenu, l'étape suivante consiste à accéder à l'en-tête de bloc. Pour ce faire, l'en-tête de bloc associé au hachage de bloc obtenu à l'étape précédente doit être haché. Le hachage de l'en-tête de bloc fourni est ensuite comparé au hachage de bloc résultant :

Il existe deux façons d'obtenir le hash :

(1) Utilisez l'opcode BLOCKHASH pour récupérer

(2) Interrogez les hachages des blocs qui ont été vérifiés dans l'historique à partir de l'accumulateur de hachage de blocs

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

1. Déterminer les racines requises (facultatif)

Avec l'en-tête de bloc en main, nous pouvons plonger dans son contenu, plus précisément :

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

receiptsRoot: Digest crypté de tous les résultats de transaction (reçus) dans le bloc.

TransactionsRoot: Un résumé cryptographique de toutes les transactions qui ont eu lieu dans le bloc.

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

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

Avec la racine que nous avons sélectionnée, et en considérant qu'Ethereum utilise une structure de trie Merkle-Patricia, 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 varieront en fonction des données et de la profondeur des données dans le bloc.

Réseaux actuellement pris en charge :

De l'Ethereum à Starknet

Depuis Ethereum Goerlivers Starknet Goerli

Depuis Ethereum Goerlivers zkSync Era Goerli

1. Axiome

Axiom offre aux développeurs un moyen d'interroger les en-têtes de bloc, les comptes ou les valeurs de stockage de l'ensemble de l'histoire d'Ethereum. AXIOM introduit une nouvelle méthode de liaison basée sur la cryptographie. Tous les résultats retournés par Axiom sont vérifiés on-chain grâce à des preuves de connaissance nulle, ce qui signifie que les contrats intelligents peuvent les utiliser sans suppositions supplémentaires de confiance.

Axiom a récemment publiéHalo2-replhalo2 est un REPL basé sur navigateur é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 composants technologiques principaux:

AxiomV1 - mémoire cache de la blockchain Ethereum, à partir de Genesis.

AxiomV1Query - Contrat intelligent qui exécute des requêtes contre AxiomV1.

(1) Valeur de hachage de bloc de cache dans AxiomV1:

Le contrat intelligent AxiomV1 met en cache les hachages de bloc Ethereum depuis le bloc de genèse sous deux formes :

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

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

(2) Exécutez la requête dans AxiomV1Query:

Le contrat intelligent AxiomV1Query est utilisé pour les requêtes groupées 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 on-chain et sont complétées on-chain via des preuves ZK contre les hachages de blocs mis en cache AxiomV1.

Ces preuves ZK vérifient si les données on-chain pertinentes sont situées directement dans l'en-tête du bloc, ou dans le trie de compte ou de stockage du bloc, en vérifiant la preuve d'inclusion (ou de non-inclusion) du Trie Merkle-Patricia.

1. Nexus

Nexus tente de construire une plateforme commune pour le cloud computing vérifiable en utilisant des preuves de connaissance zéro. Actuellement, il est agnostique par rapport à l'architecture de la machine et prend en charge risc 5/ WebAssembly/ EVM. Nexus utilise le système de preuve de supernova. L'équipe a testé que la mémoire requise pour générer la preuve est de 6 Go. À l'avenir, il sera optimisé sur cette base afin que les appareils et ordinateurs côté utilisateur ordinaires puissent générer des preuves.

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

Nexus zero: Un réseau informatique décentralisé vérifiable alimenté par des preuves de connaissance nulle et un zkVM universel.

Nexus: Un réseau informatique décentralisé vérifiable alimenté par le calcul multipartite, la réplication d'état machine et une machine virtuelle WASM universelle.

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

Les applications Nexus s'exécutent sur un réseau informatique 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 bénéficient d'un accès à une puissance de calcul plus élevée (comme le calcul, le stockage et les E/S déclenchées par des événements) en raison de la taille réduite de son réseau. Les applications Nexus s'exécutent sur un cloud privé qui atteint un consensus interne et fournit des "preuves" vérifiables de calcul (mais pas de vraies preuves) 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 ce sont des programmes universels avec des preuves à divulgation nulle qui peuvent être vérifiées on-chain sur la courbe elliptique BN-254.

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

Avertissement：

1. Cet article est repris de [ Moyen]. Tous les droits d'auteur appartiennent à l'auteur original [ABCDE]. S'il y a des objections à cette réimpression, veuillez contacter le Porte Apprendrel'équipe s'en occupera rapidement.
2. Clause de non-responsabilité: Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont réalisées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.