Anagram Build passe la majorité de notre temps à rechercher des primitives crypto novatrices et à appliquer ces primitives dans des produits spécifiques. Un de nos projets de recherche récents nous a amenés dans le domaine du Calcul Vérifiable (VC); notre équipe a exploité cette recherche pour créer un nouveau système open source appeléBonsol. Nous avons choisi ce domaine de recherche compte tenu de l'émergence de cas d'utilisation efficaces que le VC permet et des efforts concertés de divers L1 pour optimiser la rentabilité et la scalabilité du VC.

Dans ce blog, nous avons deux objectifs.

• Tout d'abord, nous voulons nous assurer que vous comprenez mieux le VC en tant que concept et les produits possibles qu'il permet dans l'écosystème Solana.
• Deuxièmement, nous voulons vous présenter notre dernière création, Bonsol.

Qu'est-ce que le calcul vérifiable, de toute façon?

Le terme ‘Verifiable Compute’ peut ne pas apparaître dans les decks d'investissement des startups en plein essor, mais le terme ‘Zero Knowledge’ si. Alors, que signifient ces termes?

La Calcul Vérifiable (VC) exécute une charge de travail spécifique de manière à produire une attestation de son fonctionnement qui peut être vérifiée publiquement sans avoir à exécuter à nouveau le calcul. La Connaissance Zéro (ZK) consiste à pouvoir prouver une déclaration sur des données ou un calcul sans révéler toutes les données ou les entrées du calcul. Les termes sont quelque peu confondus dans le monde réel, ZK est un peu un terme inapproprié. Il s'agit davantage de sélectionner les informations qui doivent être rendues publiques pour prouver une déclaration à leur sujet. VC est un terme plus précis et est l'objectif global dans de nombreuses architectures de systèmes distribués existantes.

Comment le VC nous aide-t-il à construire de meilleurs produits cryptographiques ?

Alors, pourquoi voulons-nous ajouter des systèmes VC ou ZK, en plus de plateformes comme Solana et Ethereum? Il semble que la réponse soit davantage liée à la sécurité pour le développeur. Le développeur d'un système agit comme médiateur entre la confiance des utilisateurs finaux en une boîte noire et les fonctions techniques qui rendent cette confiance objectivement valide. En utilisant les techniques ZK/VC, le développeur peut réduire la surface d'attaque des produits qu'il construit. Les systèmes VC déplacent le lieu de confiance vers le système de preuve et la charge de calcul à prouver. Il s'agit d'une inversion de confiance similaire à celle qui se produit lors du passage d'une approche client/serveur web2 typique à une approche blockchain web3. La confiance passe de la fiabilité des promesses d'une entreprise à la confiance dans le code source ouvert et les systèmes cryptographiques du réseau. Il n'existe pas de systèmes de confiance zéro absolu du point de vue de l'utilisateur, et je soutiens que pour les utilisateurs finaux, tout cela semble être une boîte noire.

Par exemple, en utilisant un système de connexion ZK, un développeur aura moins de responsabilités dans la maintenance d'une base de données sécurisée et d'une infrastructure que dans un système qui vérifie simplement que certaines propriétés cryptographiques sont atteintes. Les techniques de VC sont appliquées dans de nombreux endroits où un consensus est nécessaire pour garantir que la seule chose nécessaire pour créer un consensus est que les mathématiques sont valides.

Bien qu'il existe de nombreux exemples prometteurs d'utilisation de VC et de ZK dans la nature, bon nombre d'entre eux reposent actuellement sur le développement en cours à tous les niveaux de la pile logicielle crypto pour le rendre suffisamment rapide et efficace pour être utilisé en production.

Dans le cadre de notre travail ici chez Anagram, nous avons l'occasion de parler à de nombreux fondateurs / développeurs de crypto afin de comprendre où en est actuellement l'innovation des produits logiciels de la crypto. Historiquement, nos conversations nous ont aidés à identifier une tendance intéressante. Plus précisément, un groupe de projets déplace activement la logique du produit on-chain hors chaîne car cela devient trop cher, ou ils ont besoin d'ajouter une logique commerciale plus exotique. Ainsi, ces développeurs se retrouvent à chercher des systèmes et des outils pour équilibrer les parties on-chain et hors chaîne des produits qu'ils développent, qui deviennent de plus en plus puissants. C'est ici que le capital-risque devient une partie critique du chemin à suivre pour aider à connecter les mondes on-chain et off-chain en utilisant des méthodes sans confiance et vérifiables.

Allons-y! Alors comment fonctionnent les systèmes VC/ZK aujourd'hui?

Les fonctions VC et ZK sont désormais principalement exécutées sur des couches de calcul alternatives (appelées rollups, sidechains, relais, oracles ou coprocesseurs) disponibles via un rappel à l'exécution de contrat intelligent. Pour permettre ce flux de travail, bon nombre des chaînes L1 ont des efforts en cours pour fournir des raccourcis en dehors de l'exécution de contrat intelligent (par exemple, syscalls ou précompilations) qui leur permettent de faire des choses qui seraient sinon trop coûteuses on-chain.

Il existe quelques modes courants des systèmes VC actuels. Je mentionnerai les quatre principaux dont j'ai connaissance. Dans tous les cas sauf le dernier, les preuves ZK se produisent hors chaîne, mais c'est l'endroit et le moment où les preuves sont vérifiées qui donnent à chacun de ces modes leur avantage.

Vérification entièrement sur chaîne

Pour les systèmes de vérification de connaissances (VC) et de preuve de connaissance nulle (ZK) capables de produire de petites preuves, tels que Groth16 ou certaines variantes de Plonk, la preuve est ensuite soumise sur la chaîne et vérifiée sur la chaîne en utilisant du code déjà déployé. De tels systèmes sont désormais très courants, et la meilleure façon d'essayer cela est d'utiliser Circom et un vérificateur Groth16 sur Solana ou 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. Pour vérifier un hachage de 256 bits dans Circom, vous devez en fait traiter manuellement chacun de ces 256 bits. Il existe de nombreuses bibliothèques qui vous permettent d'appeler simplement des fonctions de hachage, mais en coulisses, vous devez réimplémenter ces fonctions dans votre code Circom. Ces systèmes sont excellents lorsque l'élément ZK et VC de votre cas d'utilisation est plus petit, et vous avez besoin que la preuve soit valide avant qu'une autre action déterministe ne soit entreprise. Bonsol entre actuellement dans cette première catégorie.

Vérification hors chaîne

La preuve est soumise à la chaîne pour que toutes les parties puissent voir qu'elle est là et puissent ensuite utiliser un calcul hors chaîne pour vérifier. Dans ce mode, vous pouvez prendre en charge n'importe quel système de preuve, mais comme la preuve ne se produit pas sur la chaîne, vous n'obtenez pas la même détermination pour toute action qui dépend de la soumission de la preuve. C'est bon pour les systèmes qui ont une sorte de fenêtre de défi où les parties peuvent "dire non" et essayer de prouver que la preuve est incorrecte.

Réseaux de vérification

La preuve est soumise à un réseau de vérification, et ce réseau de vérification agit comme un oracle pour appeler le contrat intelligent. Vous obtenez le déterminisme, mais vous devez aussi faire confiance au réseau de vérification.

Vérification synchrone sur chaîne

Le quatrième et dernier mode est assez différent; dans ce cas, la preuve et la vérification se déroulent simultanément et entièrement sur la chaîne. C'est là que le L1 ou un contrat intelligent sur le L1 peut réellement exécuter un schéma ZK sur les entrées utilisateur qui permettent de prouver l'exécution sur des données privées. Il n'y a pas beaucoup d'exemples répandus de cela dans la nature, et généralement, les types de choses que vous pouvez faire avec cela sont limités à des opérations mathématiques plus basiques.

Récapitulatif

Les quatre modes sont tous testés dans divers écosystèmes de chaînes, et nous verrons si de nouveaux schémas émergent et quel schéma devient dominant. Par exemple, sur Solana, il n'y a pas de vainqueur clair, et le paysage VC et ZK est très précoce. La méthode la plus populaire sur de nombreuses chaînes, y compris Solana, est le premier mode. La vérification entièrement sur chaîne est la norme d'or, mais comme discuté, elle comporte certains inconvénients. Principalement la latence et cela limite ce que vos circuits peuvent faire. En plongeant dans Bonsol, vous verrez qu'il suit le premier mode avec une légère torsion.

Présentation de Bonsol!

Entrer Bonsol, un nouveau système VC natif Solana que nous avons construit chez Anagram et open source. Bonsol permet à un développeur de créer un exécutable vérifiable sur des données privées et publiques et d'intégrer les résultats dans des contrats intelligents Solana. Notez que ce projet dépend de la populaire chaîne d'outils RISC0.

Ce projet a été inspiré par une question posée par bon nombre des projets avec lesquels nous travaillons chaque semaine : « Comment puis-je faire cette chose avec des données privées et le prouver on-chain ? » Alors que la « chose » différait dans chaque cas, le désir sous-jacent était le même : réduire au minimum leurs dépendances centralisées.

Avant de plonger dans les détails du système, commençons par illustrer la puissance de Bonsol avec deux cas d'utilisation distincts.

Scénario un

Une Dapp qui permet aux utilisateurs d'acheter des billets de tombola dans des pools de différents jetons. Les pools sont « décantés » une fois par jour à partir d'un pool global de telle manière que le montant d'argent dans le pool (les montants de chaque jeton) est caché. Les utilisateurs peuvent acheter l'accès à des plages de plus en plus spécifiques des jetons dans le pool. Mais il y a un hic : une fois qu'un utilisateur achète la plage, elle devient publique pour tous les utilisateurs en même temps. L'utilisateur doit alors décider d'acheter le billet. Ils peuvent décider que l'achat n'en vaut pas la peine, ou ils peuvent sécuriser une participation dans le pool en achetant un billet.

Bonsol entre en jeu lorsque le pool est créé et lorsque l'utilisateur paie pour que la plage soit connue. Lorsque le pool est créé/décanté, le programme ZK prend en compte les entrées privées de la quantité de chaque jeton à décant. Les types de jetons sont des entrées connues, et l'adresse du pool est une entrée connue. Cette preuve est une preuve de sélection aléatoire du pool global vers le pool actuel. La preuve contient un engagement envers les soldes également. Le contrat on-chain recevra cette preuve, la vérifiera et conservera les engagements de telle sorte que lorsque le pool est finalement fermé et que les soldes sont envoyés du pool global aux propriétaires de billets de tombola, ils pourront vérifier que les montants des jetons n'ont pas changé depuis la sélection aléatoire au début du pool.

Lorsqu'un utilisateur achète une « ouverture » des plages de solde de jetons cachés, le programme ZK prend les soldes de jetons réels en tant qu'entrées privées et produit une gamme de valeurs qui sont engagées avec la preuve. Une entrée publique de ce programme ZK est la preuve de création de pool précédemment engagée et ses sorties. De cette façon, tout le système est vérifié. La preuve précédente doit être validée dans la preuve de plage, et les soldes de jetons doivent être hachés à la même valeur engagée dans la première preuve. La preuve de plage est également engagée à la chaîne et, comme précédemment dit, rend la plage visible à tous les participants.

Bien qu'il existe de nombreuses façons de réaliser ce type de système de billetterie de tombola, les propriétés de Bonsol facilitent grandement le fait de ne pas avoir beaucoup confiance en l'entité organisant la tombola. Cela met également en lumière l'interopérabilité de Solana et du système VC. Le programme Solana (contrat intelligent) joue un rôle crucial dans la médiation de cette confiance car il vérifie les preuves, puis permet au programme de passer à l'action suivante.

Scénario deux

Bonsol permet aux développeurs de créer une primitive utilisée par d'autres systèmes. Bonsol contient la notion de déploiements, où un développeur peut créer un programme ZK et le déployer auprès des opérateurs Bonsol. Les opérateurs du réseau Bonsol disposent actuellement de moyens de base pour évaluer si une demande d'exécution pour l'un des programmes ZK sera économiquement avantageuse. Ils peuvent consulter des informations de base sur la quantité de calcul que le programme ZK nécessitera, les tailles d'entrée et le pourboire offert par le demandeur. Un développeur peut déployer une primitive qu'il pense que de nombreuses autres Dapps voudront utiliser.

Dans la configuration d'un programme ZK, le développeur spécifie l'ordre et le type des entrées requises. Le développeur peut publier un InputSet qui préconfigure certaines ou toutes les entrées. Cela signifie qu'ils peuvent configurer certaines des entrées de manière à ce qu'ils puissent créer des primitives qui peuvent aider les utilisateurs à vérifier le calcul sur de très grands ensembles de données.

Par exemple, supposons qu'un développeur crée un système qui, étant donné un NFT, peut prouver on-chain que le transfert de propriété incluait un ensemble spécifique de portefeuilles. Le développeur peut avoir un ensemble d'entrées préconfiguré contenant un tas d'informations sur les transactions historiques. Le programme ZK recherche dans l'ensemble pour trouver les propriétaires correspondants. C'est un exemple artificiel et peut être fait de maintes façons.

Considérez un autre exemple : un développeur est capable d'écrire un programme ZK qui peut vérifier qu'une signature de paire de clés provient d'une paire de clés ou d'un ensemble hiérarchique de paires de clés sans révéler les clés publiques de ces paires de clés autoritaires. Disons que cela est utile à de nombreux autres Dapps, et ils utilisent ce programme ZK. Le protocole donne à l'auteur de ce programme ZK un petit pourboire d'utilisation. Parce que la performance est critique, les développeurs sont incités à rendre leurs programmes rapides afin que les opérateurs veuillent les exécuter, et les développeurs cherchant à copier le travail d'un autre devront modifier le programme de certaines manières pour pouvoir le déployer puisqu'il y a une validation du contenu du programme ZK. Toute opération ajoutée au programme ZK affectera les performances, et bien que ce ne soit pas infaillible, cela peut aider à garantir que les développeurs sont récompensés pour leur innovation.

Architecture Bonsol

Ces cas d'utilisation aident à décrire à quoi Bonsol est utile, mais jetons un œil à son architecture actuelle, son modèle d'incitation actuel et son flux d'exécution.

L'image ci-dessus décrit un flux à partir d'un utilisateur ayant besoin d'effectuer une sorte de calcul vérifiable, ce qui se fera généralement via une dapp qui a besoin de cela pour permettre à l'utilisateur d'effectuer une action. Cela prendra la forme d'une demande d'exécution contenant des informations sur le programme ZK en cours d'exécution, les entrées ou ensembles d'entrées, le délai dans lequel le calcul doit être prouvé et le pourboire (qui est comment les relais sont payés). La demande est récupérée par les relais et ils doivent se précipiter pour décider s'ils veulent revendiquer cette exécution et commencer à prouver. En fonction des capacités spécifiques des opérateurs de relais, ils peuvent choisir de passer à autre chose car le pourboire n'en vaut pas la peine ou que le zkprogramme ou les entrées sont trop importants. S'ils décident de vouloir effectuer ce calcul, ils doivent revendiquer cela. S'ils sont les premiers à obtenir la revendication, alors leur preuve sera acceptée jusqu'à un certain temps. S'ils échouent à produire la preuve dans les temps, d'autres nœuds peuvent revendiquer l'exécution. Pour revendiquer, le relais doit mettre en jeu une certaine mise actuellement codée en dur pour le pourboire / 2 qui sera réduite s'ils échouent à produire une preuve correcte.

Bonsol a été construit avec la thèse selon laquelle plus de calculs se déplaceront vers une couche où ils sont attestés et vérifiés sur la chaîne, et que Solana sera bientôt une chaîne de prédilection pour les VC et ZK. Les transactions rapides de Solana, les calculs bon marché et la base d'utilisateurs en plein essor en font un excellent endroit pour tester ces idées.

Est-ce facile à construire? Non, du tout!

Cela ne veut pas dire qu'il n'y a pas eu de défis pour construire Bonsol. Pour pouvoir prendre la preuve Risco0 et la vérifier sur Solana, nous devons la rendre plus petite. Mais nous ne pouvons pas le faire sans sacrifier les propriétés de sécurité de la preuve. Nous utilisons donc Circom et enveloppons le Risc0 Stark qui peut être dans les environs de ~200ko et l'enveloppons dans une preuve Groth16 qui finit toujours par faire 256 octets. Heureusement, Risc0 a fourni quelques outils naissants pour cela, mais cela ajoute beaucoup de surcharge et de dépendances au système.

Lorsque nous avons commencé à construire Bonsol et à utiliser les outils existants pour envelopper le Stark avec le Snark, nous avons cherché des moyens de réduire les dépendances et d’augmenter la vitesse. Circom permet de compiler du code Circom en C++ ou wasm. Nous avons d’abord essayé de compiler le circuit Circom dans un fichier wasmu produit par le LLVM. C’est le moyen le plus rapide et le plus efficace de rendre l’outillage Groth16 portable et rapide. Nous avons choisi wasm en raison de sa portabilité, car le code C++ dépendait de l’architecture du processeur x86, ce qui signifie que les nouveaux Macbooks ou serveurs basés sur Arm ne pourront pas l’utiliser. Mais c’est devenu une impasse pour nous sur le calendrier avec lequel nous devions travailler. Étant donné que la plupart de nos expériences de recherche de produits sont limitées dans le temps jusqu’à ce qu’elles fassent leurs preuves, nous avons eu 2 à 4 semaines de temps de développement pour tester cette idée. Le compilateur wasm llvm n’a tout simplement pas pu gérer le code wasm généré. Avec plus de travail, nous aurions pu passer outre, mais nous avons essayé de nombreux indicateurs d’optimisation et des moyens de faire fonctionner le compilateur llvm comme un plugin wasmer pour précompiler ce code dans llvm, mais nous n’avons pas réussi. Parce que le circuit Circom est d’environ 1,5 million de lignes de code, vous pouvez imaginer que la quantité de Wasm est devenue énorme. Nous nous sommes ensuite tournés vers la création d’un pont entre le C++ et notre base de code de relais Rust. Cela a également connu une défaite rapide car le C++ contenait du code assembleur spécifique à x86 avec lequel nous ne voulions pas jouer. Afin de rendre le système public, nous avons fini par simplement amorcer le système d’une manière qui utilise le code C++ mais supprime certaines des dépendances. À l’avenir, nous aimerions développer une autre ligne d’optimisation sur laquelle nous travaillions. Il s’agissait de prendre le code C++ et de le compiler dans un graphe d’exécution. Ces artefacts C++ de la compilation Circom ne sont pour la plupart que de l’arithmétique modulaire sur un champs finisavec un très très grand nombre premier comme générateur. Cela a montré des résultats prometteurs pour des artefacts C++ plus petits et plus simples, mais plus de travail est nécessaire pour le faire fonctionner avec le système Risc0. Cela est dû au fait que le code C++ généré compte environ 7 millions de lignes de code, et le générateur de graphiques semble atteindre les limites de la pile, et augmenter celles-ci semble produire d'autres défauts que nous n'avons pas eu le temps de déterminer. Même si certaines de ces voies n'ont pas abouti, nous avons pu apporter des contributions à des projets OSS et espérons qu'à un moment donné ces contributions seront intégrées en amont.

Le prochain ensemble de défis se situe davantage dans l'espace de conception. Une partie essentielle de ce système est la capacité à avoir des entrées privées. Ces entrées doivent venir de quelque part, et en raison de contraintes de temps, nous n'avons pas pu ajouter un système de chiffrement MPC sophistiqué pour permettre aux entrées privées d'être dans le système en boucle fermée. Ainsi, pour répondre à ce besoin et débloquer les développeurs, nous avons ajouté la notion d'un serveur d'entrée privée qui doit valider ce demandeur, ce qui est validé par une signature d'une charge utile est le demandeur actuel de la preuve et le lui servir. Alors que nous étendons Bonsol, nous prévoyons de mettre en œuvre un système de décryptage seuil MPC par lequel les nœuds Relais peuvent permettre au demandeur de décrypter les entrées privées. Toute cette discussion sur les entrées privées nous amène à une évolution de conception que nous prévoyons de rendre disponible dans le dépôt Bonsol. Il s'agit de Bonsolace, qui est un système plus simple qui vous permet en tant que développeur de prouver facilement ces programmes zk sur votre propre infrastructure. Au lieu de déléguer au réseau de prouveurs, vous pouvez simplement le prouver vous-même et le vérifier sur le même contrat que le réseau de prouveurs utilise. Ce cas d'utilisation concerne les cas d'utilisation de données privées de très grande valeur où l'accès aux données privées doit être minimisé à tout prix.

Une dernière remarque à propos de Bonsol que nous n’avons pas encore vue dans d’autres endroits en utilisant Risc0 est que nous forçons un engagement (hachage) sur les données d’entrée dans le programme zk. Et nous vérifions en fait sur le contrat que les entrées que le prouveur a dû valider correspondent à ce que l’utilisateur attendait et envoyait dans le système. Cela a un certain coût, mais sans cela, cela signifie que le prouveur pourrait tricher et exécuter le programme zk sur des entrées que l’utilisateur n’a pas spécifiées. Le reste du développement de Bonsol est tombé dans le développement normal de Solana, mais il convient de noter que nous avons intentionnellement essayé de nouvelles idées là-bas. Sur le contrat intelligent, nous utilisons des flatbuffers comme seul système de sérialisation. Il s’agit d’une technique quelque peu nouvelle que nous aimerions voir développée et transformée en framework car elle se prête bien aux SDK à génération automatique qui sont multiplateformes. Une dernière remarque à propos de Bonsol est qu’il a actuellement besoin d’une précompilation pour fonctionner le plus efficacement possible, cette précompilation est prévue pour atterrir dans Solana 1.18, mais d’ici là, nous travaillons pour voir si les équipes sont intéressées par cette recherche et regardent au-delà de Bonsol dans d’autres technologies.

Conclusion

Au-delà de Bonsol, l'équipe de construction d'anagrammes examine profondément de nombreux endroits dans le domaine du capital-risque. Des projets comme Jolt, zkllvm, spartan 2, Binius sont des projets que nous suivons, ainsi que des entreprises travaillant dans l'espace de l'Encryption Homomorphique Complète (FHE), si vous ne savez pas ce que c'est, restez à l'écoute car nous en parlerons à un moment donné.

Veuillez consulter le référentiel Bonsol et créer un problème pour les exemples dont vous avez besoin ou comment vous souhaitez l'étendre. C'est un projet très précoce et vous avez la possibilité de laisser votre empreinte.

Si vous travaillez sur des projets de VC intéressants, nous vous encourageons àpostulez ici pour le programme Anagram EIRoù, aux côtés de l'équipe Anagram, vous pourrez tester votre thèse, créer une entreprise et vous attaquer aux problèmes les plus importants possibles. N'hésitez pas à contribuer ou à poser des questions.

Avertissement：

1. Cet article est repris de [Anagramme], Tous les droits d'auteur appartiennent à l'auteur original [austbot]. Si des objections sont soulevées concernant cette reproduction, veuillez contacter le Porte Apprendreéquipe, et ils s'en occuperont 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 pas un 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.