Juillet s’est avéré être un mois record pour les efforts visant à faire évoluer Bitcoin à l’aide de preuves à connaissance nulle.
Tout d’abord, StarkWare a présenté un vérificateur STARK sur le réseau de test Signet de Bitcoin le 17 juillet.
La semaine dernière, lors de la conférence Bitcoin 2024 à Nashville, deux équipes concurrentes derrière BitcoinOS et BitVMX ont vérifié les preuves zk sur le réseau principal Bitcoin. Les deux utilisent BitVM, ou « Bitcoin Virtual Machine », une approche permettant de créer des contrats Bitcoin Turing-complets sans avoir besoin d’un soft fork.
Selon Weikeng Chen de L2 Iterative Ventures, qui a travaillé sur le vérificateur STARK avec StarkWare, l’une des principales différences entre les deux approches est le degré d’exécution sans confiance.
« BitVM a une hypothèse de confiance qui nécessite toujours [a multisignature scheme] », a déclaré Chen à Blockworks. « Cette hypothèse peut être supprimée si nous avons OP_CAT. »
La distinction est similaire à celle entre optimiste et zk, ou cumuls de validité, sur Ethereum.
Même si les équipes de BitcoinOS et de BitVMX vérifient les preuves zk, elles le font au sein d’une BitVM. Par rapport à une future version de Bitcoin avec OP_CAT, ce sont des modèles de confiance assez différents, a convenu Willem Schroe, fondateur de Botanix Labs. Botanix Labs construit une preuve d’enjeu décentralisée de niveau 2 utilisant BTC, appelée Spiderchain.
« BitVM vous permet d’exécuter n’importe quel type de code, et l’hypothèse de confiance pour exécuter n’importe quel type de code est optimiste », a déclaré Schroe à Blockworks. « Vous pouvez donc désormais dire : « Avec une hypothèse de preuve de fraude optimiste de BitVM, nous pouvons vérifier une preuve zk dans BitVM. »
Rootstock Labs a travaillé avec Sovereign Labs sur BitVMX. BitcoinOS, dont Sovryn (à ne pas confondre avec Sovereign Labs) est une implémentation, est un framework pour les rollups interopérables.
Selon Chen, il n’y a pas de « gagnant évident », car même si OP_CAT est ajouté à Bitcoin, « l’approche BitVM est beaucoup moins chère à mettre en œuvre sur la chaîne ». Un compromis potentiel est que « la procédure de contestation-réponse peut conduire à une longue période de règlement », a-t-il déclaré.
Par exemple, 52 petites transactions ont été effectuées sur le réseau principal Bitcoin pour démontrer le protocole de vérification BitSnark de BitcoinOS.
La configuration implique deux parties : le prouveur, qui souhaite accéder aux fonds verrouillés dans une adresse Taproot, et le vérificateur. Le protocole commence avec les deux parties co-signant toutes les transactions. Si le prouveur est honnête, le protocole se termine après la transaction initiale et le prouveur peut accéder aux fonds après un temps de verrouillage défini.
Cependant, si le vérificateur détecte une preuve malhonnête, il peut la contester, en initiant une série de transactions où chaque partie se relaie – contestation et réponse – jusqu’à 26 itérations, selon l’équipe BitcoinOS.
Il est trop tôt pour dire dans quelle mesure cette approche sera évolutive dans la pratique, selon Matt Black, cofondateur et directeur technique d’Atomic Finance.
« Tout le monde aime parler d’évolutivité illimitée avec des cumuls optimistes, mais en réalité, il existe des limites importantes », a déclaré Black dans le groupe de télégrammes BitVM Builders.
Black souligne que les hypothèses de confiance ne sont que de 1 sur n, ce qui signifie qu’« il doit y avoir une partie honnête sur n, sinon les fonds peuvent être volés », a-t-il déclaré à Blockworks – mieux que votre multisig Ethereum typique.
Robin Linus, l’un des auteurs du livre blanc BitVM, a souligné que lors de la conception d’un pont utilisant BitVM, l’attente était qu’il ne serait utilisé que rarement pour traiter de grandes quantités de bitcoins, comme pour envelopper des BTC pour une utilisation sur un autre réseau.
Dans la démonstration de BitcoinOS, la transaction finale qui cherchait à exécuter une instruction CPU en chaîne sur le bloc 853626 impliquait que le Prover effectue une opération arithmétique spécifique dans la machine virtuelle, qui, une fois validée, permettait au Prover d’accéder aux fonds comme prévu.
Mais Chen aimerait voir plus d’informations sur la manière de contester la preuve, notant que la publication de la preuve « est la partie facile ».
« Contester une preuve est probablement la partie la plus difficile du paysage BitVM », explique Chen. « Le problème de leur construction est qu’ils ne prennent pas en charge les preuves de fraude en mémoire (un démonstrateur malveillant peut modifier l’état pour faire passer une preuve invalide) ; il est facile de les casser. »
Il s’agit d’un problème général avec BitVM, a déclaré Chen. « Nous n’avons pas de réponse claire sur la manière de réaliser efficacement le transfert d’état entre les unités de défi-réponse. »
Ces deux solutions sont encore loin d’être prêtes à être mises en production. On ne sait même pas exactement comment, et encore moins quand, Bitcoin Core pourrait être mis à niveau pour utiliser OP_CAT.
Black pense que cela pourrait prendre un certain temps. « Personnellement, je doute que cela soit activé de sitôt », a-t-il déclaré.
En théorie, l’utilisation de Circle STARKs de StarkWare améliore l’efficacité du processus de preuve, positionnant la solution de StarkWare comme une alternative hautement évolutive et sécurisée pour la mise en œuvre de la preuve zk sur Bitcoin.
Cependant, en permettant la vérification des preuves – dans ce cas une preuve SNARK – sans modifier le protocole Bitcoin, BitVMX et BitcoinOS ouvrent le potentiel d’applications avancées comme les contrats intelligents de style Ethereum qui étaient auparavant irréalisables sur Bitcoin et donc liés aux chaînes latérales.
