Comment le coprocesseur de données ZK de Brevis opère-t-il ? Analyse complète de son fonctionnement

Le ZK Data Coprocessor constitue le composant central de Brevis, permettant aux smart contracts d’accéder en toute sécurité et fiabilité à des données historiques et cross-chain. Il récupère des données authentiques on-chain, effectue des calculs off-chain, puis fournit les résultats accompagnés d’une preuve à divulgation nulle (ZK) pour validation on-chain. Cette couche la plus orientée application de Brevis (BREV) transforme le problème des « contrats incapables de calculer ou lire des données historiques » en « calcul off-chain, vérification on-chain ».

Les mécanismes de consensus Blockchain imposent à chaque validateur de répéter les mêmes calculs, rendant l’accès direct on-chain à un grand volume de transactions historiques extrêmement coûteux. Par conséquent, les smart contracts sont presque aveugles aux données historiques.

S’appuyant sur la philosophie de Brevis « prouver le travail plutôt que le répéter », le ZK Data Coprocessor déplace la lecture intensive des données et les calculs off-chain, tandis que la validation on-chain est réduite à un processus de l’ordre de la milliseconde. Cela permet aux contrats de prendre des décisions fondées sur un comportement on-chain à long terme, sans dépendre d’intermédiaires centralisés.

Qu’est-ce que le ZK Data Coprocessor ?

Le ZK Data Coprocessor est un moteur de calcul off-chain spécialisé, conçu pour accéder aux états historiques Blockchain et aux données cross-chain, exécuter des calculs que les contrats ne peuvent pas effectuer efficacement on-chain, et attacher une preuve cryptographique à chaque calcul. Il génère des justificatifs vérifiables — « résultat + preuve que le résultat provient de données authentiques et est calculé correctement ».

Au sein de la stack technologique Brevis, le ZK Data Coprocessor illustre le Pico zkVM en tant que « coprocessor niveau application ». Pico zkVM agit comme une couche « glue » pour acheminer les données entre le core général et les modules spécialisés, tandis que le Data Coprocessor se concentre sur « la lecture de l’historique, l’analyse et l’attachement de preuves », permettant aux contrats de faire confiance aux mathématiques plutôt qu’à des opérateurs centralisés.

Pourquoi les smart contracts ne peuvent-ils pas « lire » les données historiques ?

Par conception, les smart contracts accèdent efficacement uniquement à l’état du bloc courant et sont presque aveugles aux données des blocs précédents. Même si des réseaux comme Ethereum conservent l’historique complet, l’accès on-chain par les contrats au stockage ou aux transactions des blocs passés nécessite des preuves supplémentaires coûteuses et manque souvent d’interfaces natives.

La raison fondamentale est le coût et le consensus : rejouer, par exemple, le volume de transactions d’une adresse sur six mois on-chain exigerait que chaque validateur traite une masse de données d’état, dépassant rapidement les limites de gas par transaction. Ainsi, les données historiques « existent » mais sont « indisponibles ». Des fonctionnalités telles que des frais de trading à plusieurs niveaux ou des récompenses de fidélité basées sur le comportement historique reposaient traditionnellement sur des calculs off-chain et une réintégration, réintroduisant la confiance dans des intermédiaires centralisés.

Comment le ZK Data Coprocessor accède-t-il aux données on-chain off-chain ?

Le ZK Data Coprocessor accède à l’ensemble des états historiques via des nœuds d’archive Blockchain. Les nœuds d’archive stockent des snapshots de chaque bloc historique, permettant au coprocessor de lire les soldes, slots de stockage et enregistrements de transactions à tout moment — couvrant les états single-chain et multi-chain — sans exiger des contrats de rejouer les données on-chain.

Après avoir récupéré les données brutes, le coprocessor exécute la logique de calcul définie par l’utilisateur off-chain, comme l’agrégation, le filtrage, la pondération ou l’évaluation conditionnelle. Contrairement au calcul off-chain standard, chaque point de donnée consulté est inclus dans la preuve suivante, garantissant à la fois « l’existence des données » et « la correction du calcul ».

De la requête à la vérification : comment fonctionne le flux complet des données ?

Le flux de données du ZK Data Coprocessor se compose de quatre étapes formant une boucle fermée, de la requête de l’application à l’adoption par le smart contract on-chain. Dans le workflow pure-ZK, la génération de preuve à chaque étape repose sur la couche d’exécution zkVM générale. Le tableau suivant détaille chaque étape :

Ces quatre étapes créent un pipeline « calcul off-chain, vérification on-chain » : la lecture intensive des données et le calcul sont gérés off-chain, tandis que on-chain ne vérifie qu’une preuve succincte à coût minimal, sans avoir à déplacer les données brutes on-chain.

Figure 1. Flux de données en quatre étapes du ZK Data Coprocessor : requête de l’application → accès aux données off-chain (nœud d’archive) → calcul → génération de preuve ZK (les données existent et le calcul est correct) → vérificateur on-chain → résultat retourné.

Pourquoi les preuves générées sont-elles fiables ?

La fiabilité des preuves du ZK Data Coprocessor repose sur une triple garantie : le résultat, l’authenticité des données et la correction du calcul. Toute altération à n’importe quel niveau entraînera l’échec de la vérification on-chain.

Les preuves à divulgation nulle dissocient le coût de vérification de l’échelle de calcul : quel que soit le nombre de blocs historiques traités off-chain, la vérification on-chain nécessite seulement de vérifier une preuve succincte de taille fixe, généralement en quelques millisecondes. Le tableau ci-dessous détaille les trois types de faits sécurisés par la preuve.

Cette structure explique pourquoi les contrats peuvent « ne pas faire confiance, seulement vérifier » : le résultat, l’entrée et le processus sont tous inclus dans la preuve, empêchant le coprocessor de manipuler à n’importe quel stade. Cette propriété minimisant la confiance le distingue fondamentalement des solutions reposant sur des parties de confiance pour réintégrer les données.

Figure 2. Structure de la preuve du ZK Data Coprocessor : une seule preuve sécurise simultanément le résultat, l’existence des données et la correction du calcul, vérifiée par un smart contract on-chain en quelques millisecondes.

Quels scénarios sont adaptés au ZK Data Coprocessor ?

Le ZK Data Coprocessor est parfaitement adapté à tout scénario on-chain nécessitant des « résultats fiables fondés sur des données historiques ou cross-chain ». Les cas d’usage qui dépendaient auparavant de calculs off-chain et de réintégration peuvent désormais s’appuyer sur des calculs vérifiables. Le tableau ci-dessous présente plusieurs scénarios courants :

Le point commun dans ces scénarios est que les décisions reposent sur des « événements passés », et ces données ne peuvent pas être rejouées efficacement on-chain. Contrairement aux oracles qui importent simplement des données off-chain, la différence entre Brevis et les oracles est que le coprocessor fournit non seulement les données mais aussi le « calcul fondé sur les données et sa preuve de correction », déplaçant la confiance de la source de données vers la vérification mathématique.

Quels sont les avantages et limites de l’utilisation du ZK Data Coprocessor ?

Les principaux atouts du ZK Data Coprocessor sont la minimisation de la confiance et la scalabilité. L’exécution off-chain élimine les contraintes computationnelles imposées par les limites de gas des blocs, et les preuves à divulgation nulle permettent de vérifier les résultats sans dépendre de tiers. Cela permet aux contrats de prendre des décisions sécurisées sur la base de l’activité on-chain à long terme.

Les limites principales proviennent du calcul ZK lui-même : la génération de preuves à divulgation nulle requiert du matériel spécialisé et du taux de hachage, et les preuves pour des logiques complexes génèrent une surcharge et une latence plus élevées que l’exécution native, ce qui les rend moins adaptées aux scénarios ultra-low-latency. La fiabilité des résultats dépend également de l’intégrité de la source de données — des données manquantes ou incorrectes sur les nœuds d’archive affectent directement l’authenticité des entrées.

Ainsi, le ZK Data Coprocessor est le plus adapté aux scénarios où « la correction du résultat prime sur l’immédiateté », rendant les calculs historiques à grande échelle fiables et exploitables, mais non sans coût. Pour les cas d’usage plus sensibles à la latence et au coût des preuves, le modèle optimiste du token BREV et coChain propose une alternative. Tous les éléments ci-dessus sont des contraintes objectives au niveau du mécanisme et ne constituent pas un conseil en investissement.

Résumé

En tant que couche orientée application de Brevis, le ZK Data Coprocessor répond aux défis de l’accès limité des smart contracts aux données historiques et au coût élevé du replay on-chain. Il accède à des données historiques authentiques et cross-chain via des nœuds d’archive off-chain, effectue des calculs et retourne une preuve à divulgation nulle — « résultat + existence des données et correction du calcul » — pour une vérification contractuelle en millisecondes. Le processus en quatre étapes — requête, calcul off-chain, génération de preuve et vérification on-chain — déplace la confiance des intermédiaires centralisés vers la cryptographie, permettant des incitations data-driven fiables, des programmes de fidélité, des contrôles de risque et la lecture d’états cross-chain.

FAQ

Qu’est-ce que le ZK Data Coprocessor ?

En tant que moteur de calcul off-chain, le ZK Data Coprocessor accède à des données historiques et cross-chain Blockchain, exécute des calculs que les contrats ne peuvent pas effectuer on-chain, et attache une preuve à divulgation nulle au résultat. Les contrats n’ont qu’à vérifier une preuve succincte on-chain pour accepter le résultat, éliminant la nécessité de rejouer les données brutes.

D’où proviennent les données du ZK Data Coprocessor ?

Les données proviennent de nœuds d’archive Blockchain, qui stockent des snapshots complets de chaque bloc historique. Le coprocessor utilise ces snapshots pour lire les soldes, le stockage et les enregistrements de transactions à tout moment, couvrant des états historiques sur plusieurs chaînes. Chaque point de donnée est inclus dans la preuve suivante.

Pourquoi les résultats du ZK Data Coprocessor sont-ils fiables ?

La preuve à divulgation nulle retournée sécurise simultanément trois faits : le résultat, que les données d’entrée existent réellement sur la chaîne cible, et que le calcul suit strictement la logique déclarée. Toute altération entraînera l’échec de la vérification de la preuve on-chain, permettant aux contrats de « ne pas faire confiance, seulement vérifier ».

En quoi le ZK Data Coprocessor diffère-t-il des oracles ?

Les oracles importent principalement des données off-chain sur la Blockchain et exigent toujours une confiance dans la source de données. À l’inverse, le ZK Data Coprocessor effectue des calculs off-chain sur la base de données on-chain ou historiques authentiques et attache une preuve à divulgation nulle de correction, déplaçant la confiance de la source de données vers la vérification mathématique.