En quoi Brevis diffère-t-il des oracles et des autres co-processeurs ZK ?

La différence essentielle entre les oracles et les coprocessseurs ZK comme Brevis concerne la direction des données : les oracles sont conçus pour transférer des données externes, off-chain, vers la blockchain, tandis que les coprocessseurs ZK, tels que Brevis, se consacrent à des calculs vérifiables à partir de données historiques déjà présentes on-chain, avec des résultats validés mathématiquement. En tant que plateforme de calcul vérifiable pour le Web3, Brevis (BREV) répond à la problématique « comment exploiter les données on-chain et prouver leur exactitude », alors que les oracles traitent la question « comment importer des données off-chain sur la blockchain ».

Les Smart Contracts sur blockchain sont privés d’accès direct aux données externes et peinent à rejouer de grands volumes de transactions historiques on-chain. Ces contraintes ont mené à l’apparition des oracles et des coprocessseurs ZK : les oracles servent de passerelle pour l’entrée des données externes, tandis que les coprocessseurs ZK rendent possible un calcul de confiance sur les historiques on-chain. Cette distinction est déterminante pour choisir l’infrastructure à déployer ou la combinaison adaptée à chaque cas d’usage.

Figure 1. Comparaison entre Brevis ZK Coprocessor et Oracle selon quatre axes : direction des données, modèle de confiance, capacité de calcul et méthode de vérification.

Qu’est-ce qu’un oracle et quels problèmes résout-il ?

Un oracle constitue le pont de données entre la blockchain et l’extérieur, son rôle principal étant d’acheminer de façon sécurisée des données off-chain ou externes vers les Smart Contracts on-chain. Les usages majeurs incluent les flux de prix, la génération de nombres aléatoires, la remontée de résultats d’événements et la synchronisation d’états entre systèmes.

Dans un environnement fermé et déterministe, les Smart Contracts n’ont pas accès directement aux API off-chain ni aux données du monde réel. Les oracles s’appuient sur des réseaux de nœuds pour collecter, agréger et inscrire les données on-chain, ce qui permet aux contrats dépendant des conditions de marché externes — comme les liquidations de prêts ou les règlements de produits dérivés — de fonctionner correctement.

La fiabilité des oracles repose sur l’intégrité des réseaux de nœuds, les dispositifs multisignature, les mécanismes d’agrégation et les incitations économiques. L’exactitude des données dépend avant tout de l’honnêteté des nœuds rapporteurs et de la solidité de l’agrégation, et non de preuves mathématiques on-chain.

Qu’est-ce qu’un coprocessseur ZK comme Brevis ?

Les coprocessseurs ZK, tels que Brevis, sont conçus pour traiter des données historiques et cross-chain déjà présentes on-chain, en exécutant des calculs complexes off-chain et en renvoyant résultats et preuves à divulgation nulle de connaissance (Zero-Knowledge). Ces preuves permettent aux Smart Contracts de vérifier mathématiquement la validité des calculs on-chain. Les coprocesseurs de données ZK récupèrent les données authentiques depuis des nœuds d’archive off-chain, effectuent les calculs, puis renvoient résultats et preuves on-chain, instaurant ainsi un flux « calcul off-chain, vérification on-chain ».

Brevis s’appuie sur un coprocessseur de données ZK et Pico zkVM, fonctionnant selon deux modèles de sécurité : pure-ZK (zéro connaissance pure) ou coChain (OP), tel que décrit dans BREV Token and coChain. Le modèle pure-ZK repose sur des preuves cryptographiques, tandis que le modèle coChain intègre le staking et le slashing sur Ethereum pour renforcer la sécurité crypto-économique.

Contrairement aux oracles, les coprocessseurs ZK ne reposent pas sur la sincérité des rapporteurs de données. Ils rendent le processus de calcul lui-même vérifiable : tant que la preuve est valide, le contrat peut s’assurer de l’existence et de la validité des données et calculs on-chain concernés, minimisant ainsi la confiance nécessaire.

Quelles différences entre sources de données et modèles de confiance ?

Pour les sources de données, les oracles récupèrent des données externes, off-chain (prix, événements, API), tandis que les coprocessseurs ZK exploitent des données déjà on-chain (transactions historiques, soldes, états cross-chain).

En matière de modèle de confiance, les oracles reposent sur des nœuds rapporteurs ou des dispositifs multisignature, soutenus par des incitations économiques : il s’agit d’un modèle socio-économique, basé sur la confiance envers les rapporteurs. Les coprocessseurs ZK s’appuient, eux, sur la vérifiabilité mathématique des preuves à divulgation nulle de connaissance : un modèle de confiance cryptographique, fondé sur le calcul lui-même.

Aucun modèle n’est intrinsèquement supérieur. Les données externes ne peuvent être prouvées vraies uniquement par cryptographie, et la correspondance entre prix on-chain et prix réels dépend d’une source fiable. En revanche, les calculs sur des données on-chain existantes sont vérifiables directement via des preuves ZK.

Comment diffèrent leurs capacités de calcul ?

En termes de capacités de calcul, les oracles assurent principalement le « transport de données » : transmission et agrégation de données externes à destination de la blockchain, sans analyse complexe des données on-chain. Les coprocessseurs ZK, eux, réalisent du « calcul intensif », avec des statistiques à grande échelle, de l’agrégation et même de l’inférence de modèles sur données historiques off-chain.

Les Smart Contracts disposent d’un accès limité à l’historique des données, et rejouer de longues séquences de transactions on-chain est très coûteux. Les coprocessseurs ZK déplacent ces calculs off-chain et fournissent des preuves succinctes, permettant une vérification rapide on-chain et dépassant les limites de Gas sur l’ampleur du calcul.

Tableau : différences clés entre Brevis, oracles et autres coprocessseurs ZK

Le tableau ci-dessous compare les coprocessseurs ZK comme Brevis, d’autres coprocessseurs ZK et les oracles selon quatre axes : direction des données, modèle de confiance, capacité de calcul, méthode de vérification.

Points clés : oracles et coprocessseurs ZK occupent des pôles opposés du flux de données. Les « autres coprocessseurs ZK », en tant qu’infrastructures similaires, font chacun des compromis sur l’accès aux données, les systèmes de preuve et les modèles de sécurité. Brevis se distingue par son Pico zkVM généraliste et ses modèles duals pure-ZK/coChain. Ce tableau offre une vue catégorielle sans tirer de conclusions sur les projets tiers non confirmés.

Quel type choisir selon le contexte ?

Le choix dépend du besoin applicatif : « données externes on-chain » ou « calcul sur historiques on-chain ». Les oracles sont indiqués pour les prix d’actifs en temps réel, les résultats d’événements off-chain ou les nombres aléatoires. Les coprocessseurs ZK conviennent mieux pour inciter les utilisateurs selon leur comportement on-chain à long terme, le contrôle du risque ou l’agrégation cross-chain.

Les scénarios « data-on-chain » sont généralement couverts par les oracles : prix de liquidation de prêts, règlement de produits dérivés, déclencheurs d’événements d’assurance. Les scénarios de calcul sur données historiques sont adaptés aux coprocessseurs ZK : récompense basée sur le volume de trading effectif, calcul de fidélité via la durée de détention, agrégation d’actifs cross-chain pour le contrôle du risque. En pratique, les deux approches sont souvent combinées : une application DeFi peut utiliser les oracles pour les prix externes et les coprocessseurs ZK pour évaluer les contributions historiques on-chain — ils sont complémentaires et non substituables.

Figure 2. Choix du scénario : oracles pour les données externes on-chain, coprocessseurs ZK comme Brevis pour le calcul historique on-chain vérifiable ; les deux peuvent être combinés.

Quelles limites et points d’attention dans ces comparaisons ?

Les catégories terminologiques ne sont pas figées : « oracle » et « coprocessseur ZK » sont des fonctions, mais les produits réels intègrent souvent plusieurs capacités, et ces frontières deviennent floues à mesure que les architectures évoluent. Les « autres coprocessseurs ZK » doivent être considérés comme une catégorie générale — il convient d’éviter toute conclusion définitive sur des projets tiers sans confirmation publique.

Les solutions hybrides se multiplient : certaines infrastructures combinent l’import de données externes avec le calcul vérifiable, ou utilisent des preuves à divulgation nulle de connaissance pour renforcer l’intégrité des données transmises par les oracles. Opter strictement pour l’un ou l’autre risque d’écarter ces modèles hybrides.

Le coût et la latence sont aussi déterminants : la génération de preuves ZK requiert du matériel spécialisé et engendre un surcoût pour le calcul généraliste par rapport à l’exécution native. Les oracles sont sensibles à la fréquence de mise à jour, à la couverture des nœuds et à la latence d’agrégation. Les comparaisons doivent être adaptées à chaque scénario, et non à un critère unique.

Résumé

Oracles et coprocessseurs ZK comme Brevis relèvent des défis distincts situés aux extrémités opposées du flux de données blockchain : les oracles importent des données externes on-chain, fondés sur la confiance et les incitations économiques ; les coprocessseurs ZK permettent le calcul vérifiable sur les historiques on-chain, reposant sur l’intégrité mathématique des preuves à divulgation nulle de connaissance. Chacun occupe une place spécifique selon la direction des données, le modèle de confiance et la capacité de calcul, et la frontière n’est pas absolue. En pratique, les approches hybrides sont souvent privilégiées pour optimiser l’efficacité.

FAQ

Les oracles et les coprocessseurs ZK peuvent-ils se substituer ?

Non, ils ne sont pas interchangeables. Les oracles apportent des données externes, off-chain, sur la blockchain, tandis que les coprocessseurs ZK effectuent des calculs vérifiables sur des historiques déjà on-chain. Ils interviennent à des étapes différentes du flux de données et sont souvent combinés ou utilisés ensemble dans une même application.

Quelle est la différence centrale entre Brevis et les oracles ?

La différence principale réside dans la direction des données et le modèle de confiance. Les oracles importent des données externes on-chain, avec une confiance basée sur les nœuds/multisig et des incitations économiques. Brevis et les coprocessseurs ZK similaires effectuent des calculs sur des historiques on-chain et renvoient des preuves à divulgation nulle de connaissance, permettant une vérification mathématique directe des résultats on-chain.

Pourquoi les coprocessseurs ZK sont-ils considérés comme trust-minimized ?

Les coprocessseurs ZK rendent le calcul lui-même vérifiable : tant que la preuve à divulgation nulle de connaissance on-chain est valide, elle atteste de la présence des données et de la bonne exécution du calcul — il n’est pas nécessaire de faire confiance à des tiers pour la remontée des données ou le calcul. C’est pourquoi ils sont considérés comme trust-minimized.

Les oracles utilisent-ils des preuves à divulgation nulle de connaissance ?

Certains oracles recourent à des preuves à divulgation nulle de connaissance pour améliorer l’intégrité ou la confidentialité des données, mais leur fonction première reste d’importer des données externes on-chain. Pour les oracles, les preuves ZK sont un complément, alors qu’elles sont centrales dans les coprocessseurs ZK pour la vérification de la validité des calculs.

Une application peut-elle combiner oracles et coprocessseurs ZK ?

Oui. Par exemple, une application DeFi peut utiliser des oracles pour obtenir les prix d’actifs en temps réel et des coprocessseurs ZK pour calculer des incitations ou gérer le risque selon l’historique on-chain réel des utilisateurs, répondant ainsi aux besoins de « données externes on-chain » et de « calcul sur historiques on-chain ».