Présentation de Bonsol : la ZK sur Solana, quels nouveaux cas d'utilisation le calcul vérifiable va-t-il permettre ?
TechFlow SélectionTechFlow Sélection
Présentation de Bonsol : la ZK sur Solana, quels nouveaux cas d'utilisation le calcul vérifiable va-t-il permettre ?
Le calcul vérifiable (VC) consiste à exécuter certaines charges de travail d'une manière permettant de produire une preuve de leur exécution, cette preuve pouvant être vérifiée publiquement sans qu'il soit nécessaire de réexécuter le calcul.
Dédié à des analyses Web3 approfondiesRédaction : Austbot
Traduction : TechFlow
L'équipe d'Anagram Build passe la majeure partie de son temps à explorer de nouveaux cas d'utilisation en cryptographie et à appliquer ces cas à des produits spécifiques. L'un de nos récents projets de recherche s'est tourné vers le domaine du calcul vérifiable (VC). À partir de cette recherche, notre équipe a développé un nouveau système open source appelé Bonsol. Nous avons choisi ce domaine car le calcul vérifiable ouvre la voie à de nombreux cas d'utilisation prometteurs, et les différentes couches 1 (L1) travaillent activement à améliorer l'efficacité coûts/performance et l'extensibilité du calcul vérifiable.
Dans cet article, nous poursuivons deux objectifs :
-
Premièrement, nous souhaitons vous assurer une meilleure compréhension du concept de VC et des produits qu'il pourrait permettre dans l'écosystème Solana.
-
Deuxièmement, nous voulons vous présenter notre dernier projet : Bonsol.
Qu'est-ce que le calcul vérifiable ?
Le terme « calcul vérifiable (Verifiable Compute) » ne figure peut-être pas sur les brochures de levée de fonds des startups en période de hausse, mais celui de « zéro-connaissance » (ZK), lui, y est bien présent. Alors, que signifient exactement ces termes ?
Le calcul vérifiable (VC) consiste à exécuter une charge de travail spécifique de manière à générer une preuve de son exécution, preuve qui peut être vérifiée publiquement sans avoir besoin de refaire le calcul. La notion de « zéro-connaissance » fait référence à la capacité de prouver une affirmation concernant des données ou un calcul, sans révéler toutes les entrées du calcul ou les données elles-mêmes. Dans la pratique, ces termes sont souvent mélangés, et « zéro-connaissance » peut parfois être un abus de langage. Il s’agit davantage de choisir quelles informations doivent être rendues publiques pour valider une assertion. VC est un terme plus précis, et constitue l'objectif général de nombreuses architectures distribuées existantes.
Comment le VC peut-il nous aider à construire de meilleurs produits cryptographiques ?
Alors, pourquoi voudrions-nous ajouter des systèmes VC ou ZK aux plateformes comme Solana ou Ethereum ? La réponse semble résider principalement dans la sécurité offerte aux développeurs. Les développeurs de systèmes agissent comme intermédiaires entre la confiance que les utilisateurs accordent à une boîte noire, et les fonctionnalités techniques qui rendent cette confiance objectivement valide. En exploitant les technologies ZK/VC, les développeurs peuvent réduire la surface d'attaque de leurs produits. Les systèmes VC déplacent le point de confiance vers le système de preuve et la charge de travail calculatoire prouvée. Cela rappelle la transformation de confiance observée lorsqu'on passe d'une approche web2 classique client/serveur à une approche web3 basée sur la blockchain : la confiance se déplace des engagements des entreprises vers le code open source et les systèmes cryptographiques du réseau. Du point de vue de l'utilisateur, il n'existe aucun système véritablement « sans confiance », et tout cela leur apparaît probablement toujours comme une boîte noire.
Par exemple, grâce à un système d'authentification ZK, les développeurs ont moins à se soucier de la maintenance d'une base de données sécurisée et d'une infrastructure robuste, puisque le système doit simplement vérifier que certaines propriétés cryptographiques sont satisfaites. La technologie VC est appliquée dans de nombreux domaines où un consensus est requis, et où la seule condition nécessaire à ce consensus est la validité mathématique.
Bien qu’il existe de nombreux exemples réussis d’utilisation de VC et ZK dans la nature, beaucoup d’entre eux dépendent encore actuellement des progrès du logiciel cryptographique à différents niveaux de la pile technique, afin d’atteindre une rapidité et une efficacité suffisantes pour être utilisables en production.
Dans le cadre de notre travail chez Anagram, nous avons eu l'occasion de discuter avec de nombreux fondateurs et développeurs du secteur, afin de comprendre comment l'état actuel de la pile logicielle cryptographique influence l'innovation produit. Historiquement, ces conversations nous ont permis d'identifier une tendance intéressante : un certain nombre de projets transfèrent activement la logique de leurs produits hors chaîne (off-chain), parce que l’exécution sur chaîne (on-chain) est devenue trop coûteuse, ou parce qu'ils souhaitent intégrer une logique métier plus complexe. Ces développeurs finissent alors par chercher des outils et des systèmes capables de trouver un équilibre entre les parties on-chain et off-chain de leurs produits, qui deviennent ainsi de plus en plus puissants. C’est ici que le VC devient un élément clé, en aidant à connecter les mondes on-chain et off-chain selon des méthodes fiables et vérifiables.
Comment fonctionnent actuellement les systèmes VC/ZK ?
Actuellement, les fonctions VC et ZK sont principalement exécutées sur des couches de calcul alternatives (comme les rollups, les sidechains, les relais, les oracles ou les coprocesseurs), accessibles via des rappels (callbacks) au moment de l'exécution d'un contrat intelligent. Pour permettre ce flux de travail, de nombreuses blockchains L1 s'efforcent d'offrir des raccourcis en dehors du runtime des contrats intelligents (par exemple des appels système ou des pré-compilations), afin d'exécuter des opérations qui seraient autrement trop coûteuses sur chaîne.
Il existe plusieurs modèles courants pour les systèmes VC actuels. Je vais mentionner les quatre premiers que je connais. Dans tous les cas sauf le dernier, les preuves ZK sont générées hors chaîne, mais c’est le moment et le lieu de la vérification de la preuve qui confère à chaque modèle ses avantages propres.
Vérification entièrement on-chain
Pour les systèmes de preuve VC et ZK capables de produire de petites preuves, comme Groth16 ou certaines variantes de Plonk, la preuve est ensuite envoyée sur chaîne et vérifiée directement sur chaîne à l’aide d’un code précédemment déployé. De tels systèmes sont aujourd’hui très courants. La meilleure façon d’essayer cette approche consiste à utiliser Circom accompagné d’un vérificateur Groth16 sur Solana ou sur une machine virtuelle EVM. L’inconvénient est que ces systèmes de preuve sont assez lents. Ils exigent généralement aussi d’apprendre un nouveau langage. Par exemple, vérifier un hachage 256 bits dans Circom implique de manipuler manuellement chacun des 256 bits. Bien qu’il existe de nombreuses bibliothèques permettant d’appeler simplement la fonction de hachage, en arrière-plan, il faut néanmoins réimplémenter ces fonctions dans le code Circom. Ces systèmes sont excellents lorsque les composantes ZK et VC de votre cas d’usage sont limitées, ou lorsque vous devez prouver qu’une preuve est valide avant d’effectuer d’autres actions déterministes. Actuellement, Bonsol appartient à cette première catégorie.
Vérification hors chaîne
La preuve est soumise sur chaîne afin que toutes les parties puissent la voir, puis elle peut être vérifiée ultérieurement à l’aide d’un calcul hors chaîne. Ce modèle permet de supporter n’importe quel système de preuve, mais comme la vérification n’a pas lieu sur chaîne, on ne peut pas obtenir la même garantie de certitude pour toute action dépendant de la soumission de la preuve. Ce modèle convient bien aux systèmes dotés d’une fenêtre de contestation, durant laquelle les participants peuvent « contester » la preuve en tentant de démontrer qu’elle est incorrecte.
Réseau de vérification
La preuve est soumise à un réseau de vérification, qui agit ensuite comme oracle en appelant le contrat intelligent. Vous obtenez ainsi une certitude, mais vous devez également faire confiance au réseau de vérification.
Vérification synchrone on-chain
Le quatrième et dernier modèle est assez différent : dans ce cas, la preuve et sa vérification ont lieu simultanément sur chaîne. Ici, la L1 ou un contrat intelligent sur celle-ci peut effectivement exécuter un schéma ZK directement sur les entrées utilisateur, permettant ainsi de prouver l’exécution sur des données privées. Il n’existe pas encore beaucoup d’exemples concrets à grande échelle, et les opérations réalisables avec cette méthode sont généralement limitées à des opérations mathématiques de base.
Synthèse
Ces quatre modèles sont actuellement testés dans divers écosystèmes de blockchains. Nous verrons si de nouveaux modèles émergeront, et lequel dominera. Sur Solana par exemple, aucun modèle ne s'impose clairement pour l'instant, et le paysage VC/ZK en est encore à ses débuts. À travers de nombreuses blockchains, dont Solana, l'approche la plus populaire reste le premier modèle : la vérification entièrement on-chain, considérée comme la norme dorée. Toutefois, comme discuté précédemment, elle comporte aussi certains inconvénients, notamment en termes de latence, et elle limite les capacités de vos circuits. Comme nous allons le voir en étudiant Bonsol, ce projet suit ce premier modèle, mais avec quelques différences notables.
Présentation de Bonsol
Bonsol est un nouveau système VC natif Solana, développé et publié en open source par Anagram. Bonsol permet aux développeurs de créer des exécutables vérifiables impliquant des données privées et publiques, et d’intégrer les résultats dans des contrats intelligents Solana. Notez que ce projet repose sur la célèbre chaîne d’outils RISC0.
Ce projet s’inspire d’une question fréquemment posée lors de nos échanges hebdomadaires avec divers projets : « Comment puis-je prouver quelque chose sur chaîne en utilisant des données privées ? ». Même si le « quelque chose » varie selon les cas, le désir sous-jacent reste identique : réduire leur dépendance centralisée.
Avant d’entrer dans les détails du système, examinons deux cas d’usage différents illustrant la puissance de Bonsol.
Scénario un
Une dApp permet aux utilisateurs d’acheter des billets de loterie dans divers pools de jetons. Chaque jour, ces pools sont alimentés depuis un pool global, de sorte que les montants disponibles dans chaque pool (en nombre de jetons) restent cachés. Les utilisateurs peuvent payer pour accéder à des plages de montants de plus en plus précises au sein du pool. Mais attention : dès qu’un utilisateur achète l’accès à une plage, celle-ci devient publique pour tous. L’utilisateur doit alors décider s’il souhaite acheter un billet de loterie. Il peut juger que ce n’est pas rentable, ou bien décider d’acheter un billet pour s’assurer une part dans le pool.
C’est là que Bonsol entre en jeu, au moment de la création du pool et de l’achat d’une plage par un utilisateur. Lorsque le pool est créé ou alimenté, un programme ZK reçoit en entrée privée le nombre de chaque type de jeton. Le type de jeton est une entrée connue, tout comme l’adresse du pool. La preuve atteste que les jetons ont été sélectionnés aléatoirement dans le pool global. Elle inclut également un engagement sur les soldes. Le contrat sur chaîne reçoit cette preuve, la vérifie, et conserve les engagements afin que, lors de la fermeture finale du pool et du transfert des soldes aux gagnants, on puisse vérifier que les quantités de jetons n’ont pas changé depuis la sélection initiale.
Lorsqu’un utilisateur achète l’accès à une plage de soldes cachés (« ouverture »), le programme ZK prend en entrée privée le solde réel en jetons et génère une série de valeurs engagées conjointement à la preuve. Les entrées publiques de ce programme ZK sont la preuve précédente de création du pool et sa sortie. Ainsi, l’ensemble du système est validé : la preuve antérieure doit être vérifiée dans la preuve de plage, et les soldes en jetons doivent correspondre au hachage engagé dans la première preuve. La preuve de plage est également soumise sur chaîne, rendant la plage visible pour tous les participants, comme indiqué précédemment.
Bien qu’il existe de nombreuses façons de concevoir un tel système de loterie, les propriétés de Bonsol permettent de minimiser la confiance requise envers l’organisateur. Cela met aussi en lumière l’interopérabilité entre Solana et les systèmes VC. Le programme Solana (contrat intelligent) joue un rôle clé dans l’établissement de la confiance, car il vérifie les preuves puis autorise les prochaines étapes du processus.
Scénario deux
Bonsol permet aux développeurs de créer des suites d’outils destinés à d'autres systèmes. Bonsol inclut la notion de déploiement : un développeur peut créer plusieurs programmes ZK et les déployer auprès d’opérateurs Bonsol. Actuellement, les opérateurs du réseau Bonsol disposent de moyens simples pour évaluer si l’exécution d’un programme ZK est économiquement viable. Ils peuvent voir des informations de base sur la quantité de calcul nécessaire, la taille des entrées, et le pourboire offert par le demandeur. Un développeur peut ainsi déployer une suite d’outils qu’il pense utile à de nombreuses autres dApps.
Dans la configuration du programme ZK, le développeur spécifie l’ordre et le type des entrées nécessaires. Il peut également publier un « InputSet » préconfiguré avec certains ou tous les paramètres déjà définis. Cela lui permet de configurer partiellement les entrées, facilitant ainsi la vérification de calculs sur de très grands jeux de données pour les utilisateurs.
Par exemple, imaginons qu’un développeur crée un système capable de prouver, sur chaîne, qu’un transfert de propriété NFT inclut un ensemble spécifique de portefeuilles. Il pourrait disposer d’un InputSet préconfiguré contenant de nombreuses informations historiques de transactions. Le programme ZK parcourt cet ensemble pour trouver le propriétaire correspondant. Cet exemple est artificiel et pourrait être implémenté de multiples façons.
Prenons un autre exemple : un développeur écrit un programme ZK capable de vérifier qu’une signature provient d’une paire de clés (ou d’une hiérarchie de clés), sans révéler la clé publique autorisée. Supposons que cela soit utile à de nombreuses autres dApps, qui utilisent donc ce programme ZK. Le protocole verse une petite récompense au créateur du programme. Étant donné que les performances sont cruciales, les développeurs sont incités à rendre leurs programmes rapides, afin que les opérateurs acceptent de les exécuter. Un développeur tentant de copier le travail d’un autre devra modifier le programme d’une certaine manière pour pouvoir le redéployer, car le contenu du programme ZK est vérifié. Toute opération ajoutée affecte les performances. Bien que ce mécanisme ne soit pas infaillible, il pourrait aider à garantir que les développeurs soient récompensés pour leur innovation.
Architecture de Bonsol
Ces cas d’usage illustrent bien l’utilité de Bonsol, mais examinons maintenant son architecture actuelle, son modèle d’incitation et son flux d’exécution.
L’image ci-dessus décrit le flux d’un utilisateur devant exécuter un calcul vérifiable, généralement initié par une dApp qui demande à l’utilisateur d’effectuer une action. Cela prend la forme d’une requête d’exécution, contenant des informations sur le programme ZK à exécuter, les entrées ou InputSet, la date limite de preuve et un pourboire (mécanisme de paiement au relais). Cette requête est captée par un relais, qui doit décider s’il veut revendiquer l’exécution et commencer à produire la preuve. Selon ses capacités, un relais peut choisir d’abandonner si le pourboire est insuffisant, ou si le programme ZK ou les entrées sont trop volumineux. S’il choisit d’exécuter le calcul, il doit revendiquer l’exécution. S’il est le premier à revendiquer, sa preuve sera acceptée jusqu’à une certaine date limite. S’il ne produit pas la preuve à temps, un autre nœud peut revendiquer l’exécution. Pour revendiquer, le relais doit fournir une mise, actuellement codée en dur à pourboire/2, qui sera confisquée s’il ne produit pas la bonne preuve.
Bonsol est construit autour de l'idée que davantage de calculs seront déplacés vers un niveau où ils seront vérifiés et validés sur chaîne, et que Solana deviendra rapidement la blockchain de choix pour le VC et le ZK. La rapidité des transactions, le faible coût du calcul et la croissance constante de sa communauté font de Solana un terrain idéal pour tester ces idées.
Est-ce facile à construire ? Bien sûr que non !
Construire Bonsol n’a pas été sans défis. Pour transporter les preuves Risc0 vers Solana et les y vérifier, nous devions les rendre plus petites. Mais nous ne pouvions pas sacrifier la sécurité de la preuve. Nous avons donc utilisé Circom pour emballer la preuve Stark de Risc0 (environ 200 Ko), puis l’avons intégrée dans une preuve Groth16, dont la taille est toujours de 256 octets. Heureusement, Risc0 fournit des outils préliminaires pour cela, mais cela ajoute beaucoup de surcharge et de dépendances au système.
En commençant à construire Bonsol et en utilisant des outils existants pour emballer Stark dans Snark, nous avons cherché à réduire les dépendances et à augmenter la vitesse. Circom permet de compiler son code en C++ ou en wasm. Nous avons d’abord tenté de compiler les circuits Circom en fichiers wasmu générés par LLVM. C’était la méthode la plus rapide et efficace pour rendre le kit Groth16 portable tout en restant rapide. Nous avons choisi wasm pour sa portabilité, alors que le code C++ dépend de l’architecture CPU x86, ce qui signifie que les nouveaux MacBooks ou serveurs basés sur Arm ne pourraient pas l’utiliser. Mais dans les délais impartis, cela s’est avéré une impasse. Comme la plupart de nos expériences de recherche étaient limitées dans le temps (jusqu’à la démonstration de valeur), nous disposions seulement de 2 à 4 semaines pour tester cette idée. Le compilateur wasm LLVM ne pouvait pas traiter le code wasm généré. Malgré de nombreux essais avec des options d’optimisation et en tentant de faire fonctionner le compilateur LLVM comme plugin wasmer pour précompiler ce code en llvm, nous n’avons pas réussi. Compte tenu que le circuit Circom représente environ 1,5 million de lignes de code, on peut imaginer la taille du code wasm résultant. Nous avons alors envisagé de créer un pont uniquement entre le C++ et notre code Rust du relais. Cela a vite échoué aussi, car le C++ contenait du code assembleur spécifique à x86 que nous ne voulions pas toucher. Pour rendre le système public, nous avons finalement lancé un système utilisant le code C++ tout en supprimant certaines dépendances. À l’avenir, nous espérons explorer une autre piste d’optimisation : compiler réellement le code C++ en graphe d’exécution. Les composants C++ compilés par Circom sont principalement des opérations arithmétiques modulaires sur des corps finis avec de très grands nombres premiers. Cela a donné des résultats prometteurs pour des composants C++ plus petits et simples, mais nécessite encore du travail pour fonctionner avec le système Risc0, car le code C++ généré compte environ 7 millions de lignes, et le générateur de graphes atteint apparemment les limites de pile, et augmenter ces limites entraîne d’autres erreurs que nous n’avons pas eu le temps d’analyser. Bien que certaines de ces approches n’aient pas abouti comme prévu, nous avons pu contribuer au projet open source, et espérons que ces contributions seront un jour intégrées upstream.
Les défis suivants relevaient davantage du domaine de la conception. Une partie importante du système est la gestion des entrées privées. Ces entrées doivent provenir de quelque part, et en raison de contraintes de temps, nous n’avons pas pu intégrer un système cryptographique MPC sophistiqué permettant aux entrées privées de circuler en boucle fermée dans le système. Pour répondre à ce besoin et débloquer les développeurs, nous avons introduit le concept de serveur d’entrée privée, qui vérifie que le demandeur est bien le bénéficiaire légitime via une signature du payload, puis lui fournit les données. À mesure que nous développerons Bonsol, nous prévoyons d’implémenter un système de déchiffrement seuil MPC, permettant aux nœuds relais de permettre au demandeur de déchiffrer ses entrées privées. Toutes ces discussions sur les entrées privées nous conduisent à une évolution de conception que nous prévoyons d’ajouter au dépôt Bonsol : Bonsolace, un système plus simple permettant aux développeurs de prouver facilement ces programmes ZK sur leur propre infrastructure. Vous pouvez produire la preuve vous-même, puis la vérifier sur le même contrat que le réseau de preuves. Ce cas d’usage convient aux applications à données privées très sensibles, où l’accès aux données privées doit être minimisé autant que possible.
Enfin, un dernier point sur Bonsol que nous n’avons vu nulle part ailleurs dans l’utilisation de Risc0 : nous imposons un engagement (hachage) sur les données d’entrée dès leur entrée dans le programme ZK. Nous vérifions effectivement sur le contrat que l’entrée engagée par le prouveur correspond bien à celle attendue et envoyée par l’utilisateur dans le système. Cela induit un coût, mais sans cela, le prouveur pourrait tricher en exécutant le programme ZK sur des entrées non spécifiées par l’utilisateur. Le reste du développement de Bonsol relève du développement Solana classique, mais il convient de noter que nous y avons volontairement testé quelques idées nouvelles. Dans le contrat intelligent, nous utilisons flatbuffers comme unique système de sérialisation — une technique plutôt novatrice que nous espérons développer en framework, car elle convient bien à la génération de SDK multiplateformes. Enfin, Bonsol nécessite actuellement une étape de précompilation pour fonctionner de manière optimale, une fonctionnalité prévue dans Solana 1.18. D’ici là, nous essayons de susciter l’intérêt de l’équipe sur cette recherche, et d’explorer d’autres technologies au-delà de Bonsol.
Conclusion
Outre Bonsol, l’équipe de construction d’Anagram explore activement de nombreux aspects du domaine VC. Des projets comme Jolt, zkllvm, spartan 2, Binius figurent parmi ceux que nous suivons, ainsi que des entreprises travaillant sur le chiffrement homomorphe complet (FHE).
Consultez le dépôt Bonsol, posez des questions sur les exemples dont vous avez besoin ou sur la manière dont vous souhaiteriez l’étendre. C’est un projet très jeune, et vous avez l’opportunité d’y jouer un grand rôle.
Si vous travaillez sur un projet VC intéressant, postulez au programme Anagram EIR.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@anagramxyz
