Bitcoin PIPE, une proposition de Mikhail Komarov, cherche à mettre en œuvre des clauses restrictives et une preuve zéro de connaissance (ZKP) dans Bitcoin sans nécessiter de soft fork dans le réseau. Ces programmations apporteraient des avantages en matière de confidentialité (tests SNARK) et de convivialité dans Bitcoin, via des contrats intelligents ou des conceptions de transactions plus complexes et avancées.
L’intention d’ajouter ces avancées à la couche de base du Bitcoin n’est pas nouvelle, mais cette proposition est la première qui, si elle est mise en œuvre, n’impliquerait pas de fork du réseau.
PIPE éviterait cette fourchette grâce à l’émulation de pactes ou de conventions dans la programmation Bitcoinet non par sa mise en œuvre directe, historiquement contrainte par la taille autorisée des scripts Bitcoin.
“Malgré plusieurs propositions (par exemple, BIP-420) visant à réactiver ou à introduire de nouveaux opcodes, ces modifications n’ont pas été adoptées, laissant la vérification ZKP dans Bitcoin L1 comme un défi non résolu.”
Mikhaïl Komarov, développeur ZKP
Que sont les Covenants et que contribueraient-ils au Bitcoin ?
La mise en œuvre de Covenants, par exemple, introduirait un langage et une couche de programmabilité plus flexibles et plus avancés dans Bitcoin.
En termes simples, les clauses restrictives peuvent être définies comme des restrictions conditionnelles imposées aux transactions Bitcoin. Ils définissent des règles sur où et comment le BTC peut être dépensé.
L’introduction de ceux-ci rendrait Bitcoin aurait tendance à rattraper son retard dans la course aux réseaux plus axés sur la création d’applications décentralisées et de contrats intelligentscomme Ethereum ou Solana. La flexibilité de ces réseaux est démontrée par le fait qu’ils hébergent une variété de jeux, de services financiers et de solutions technologiques qui, aujourd’hui, échappent à la programmabilité de Bitcoin.
La difficulté historique de la mise en œuvre des clauses restrictives dans Bitcoin est due au fait que le faire de manière traditionnelle nécessite l’introduction de nouveaux codes de fonctionnement (codes d’opération), des codes ou des règles d’exécution dans la programmation Bitcoin. Ce qui précède apporterait des modifications aux scripts Bitcoin (ou base de règles de programmation Bitcoin). À leur tour, les deux changements Ils introduiraient des modifications irréversibles aux règles de consensus sur le réseau.
Toute proposition modifiant le codes d’opération et parce qu’un fork, tel que le BIP-119 ou le BIP-420 susmentionné, devrait mobiliser la communauté Bitcoiner au sens large pour s’adapter au nouveau logiciel et aux nouvelles règles. Une telle démarche serait coûteuse pour toutes les personnes impliquées dans le réseau, c’est pourquoi ces propositions passées ont pour la plupart échoué et ont été rejetées.
Pour Mikhaïl Komarov, ce soft fork dans Bitcoin est la solution évidente, mais pas la meilleure pour mettre en œuvre des covenants : « mettre à jour le protocole Bitcoin, pour introduire (ou réintroduire) les codes d’opération manquants (codes d’opération). Malheureusement, cela conduit à la nécessité de parvenir à un consensus social, ce qui est un processus plutôt compliqué.»
Émuler des clauses restrictives dans Bitcoin
Le développeur commente que la prochaine étape pour amener les clauses absentes à Bicoin, étant donné la difficulté de modifier le codes d’opérationc’est « les émuler pour une application particulière ». La procédure pour les émuler est contenue dans le papier de Bitcoin PIPE.
L’émulation de certains covenants dans Bitcoin permettra la mise en œuvre de tests zk-SNARK (Argument de connaissance succinct et non interactif sans connaissance), un type de preuve cryptographique qui permet à une partie («échantillons“”) prouver à une autre partie (“vérificateur») qui possède certaines informations sans les révéler lui-même. Ce modèle de vérification permettrait d’éviter la présentation indésirable d’informations par les participants lors des transactions pas Bitcoin.
Les clauses sont essentielles pour introduire les tests SNARK dans Bitcoin, car son langage de programmation permettrait de mettre en œuvre la vérification du chemin de l’arborescence Merkle.
Ce type de vérification permettrait des transactions plus privées, celles où Les détails restent cachés, bien qu’ils restent vérifiables par les participants.
Les tests SNARK visent à résoudre le problème du pseudo-anonymat dans Bitcoin, où les transactions sont publiques et traçables. Pour le meilleur ou pour le pire, l’état actuel de la programmabilité des données de transaction dans Bitcoin vous permet de retracer, avec une relative facilité, les activités financières des utilisateurs. Ces preuves sans connaissance intègrent une couche supplémentaire d’anonymat, indispensable aux utilisateurs soucieux de leur confidentialité.
A noter que les tests SNARK ont un atout supplémentaire : Ils sont compatibles avec Onion Router (TOR) et d’autres technologies de navigation Internet privéece qui augmente le potentiel de Bitcoin vers un réseau plus anonyme et sécurisé.
Comme l’a rapporté CriptoNoticias, Bitcoindevs a mis en lumière une expérience d’apprentissage interactive sur la programmabilité BTC, appelée Decoding Bitcoin.
Grâce à des mini-programmes interactifs et simples, les modules pédagogiques permettent de comprendre des concepts et des applications tels que les scripts Bitcoin et codes d’opérationce qui peut être utile pour comprendre les avantages (et les limites) des tests SNARKS, des conventions et d’autres avancées informatiques dans Bitcoin.
