Bitcoin : les potentielles évolutions du protocole pour 2020
11 années après la création du premier bloc, le réseau Bitcoin a drastiquement évolué. Bien qu’aucune mise à jour n’ait été déployée depuis SegWit en août 2017, l’année 2020 pourrait bien être celle du changement. De nombreux soft forks sont actuellement en développement et pourraient bien être déployés au cours de l’année 2020, à condition qu’ils obtiennent suffisamment de support de la part de la communauté.
Signatures de Schnorr et Taproot
Les signatures de Schnorr sont réputées dans le domaine de la cryptographie pour être l’un des meilleurs types de signatures. Appliquées à Bitcoin, de telles signatures permettraient une réduction de la taille des transactions. De plus, plusieurs de ces signatures peuvent aisément être agrégées en une seule améliorant de fait les solutions de confidentialités comme Coinjoin.
Nombreux sont les développeurs qui travaillent sur l’ajout des signatures Schnorr à Bitcoin : parmi eux, nous pouvons citer Pieter Wuille et Jonas Nick, travaillant chez Blockstream, ainsi que Anthony Towns, employé de Xapo.
Nos trois protagonistes ne souhaitent cependant pas s’arrêter aux signatures de Schnorr et proposent l’ajout simultané de Schnorr ainsi que deux autres améliorations connues sous le nom de MAST et Taproot. Ces améliorations permettent respectivement d’ajouter des conditions complexes à une transaction tout en réduisant sa taille et d’augmenter la confidentialité.
La combinaison de ces trois améliorations au sein d’un seul soft fork est nécessaire pour Peter Wuille :
« Les séparer en propositions indépendantes réduirait les gains d’efficacité et de protection de la vie privée et compliquerait l’analyse de leurs interactions. Il semble préférable de se concentrer sur un objectif à la fois et de combiner des technologies interactives pour les atteindre. » Pieter Wuille.
OP_CHECKTEMPLATEVERIFY
Le code OP_CHECKTEMPLATEVERIFY est une amélioration proposée par le développeur de Bitcoin Core Jeremy Rubin. L’objectif de ce soft fork est de faciliter les transactions en période de congestion ou de forte augmentation des frais sur le réseau Bitcoin.
Cette fonctionnalité permettrait aux transactions d’être coupée en deux transactions distinctes :
- La moitié « envoyée », incluant les entrées de la transaction (données relatives à l’expéditeur).
- La moitié « reçue », incluant les sorties de la transaction (données relatives au destinataire).
Au moment de la transaction, les deux moitiés sont diffusées sur le réseau. La première moitié contenant les informations de l’émetteur est diffusée avec plus de frais que la seconde afin qu’elle soit validée plus rapidement. Le fait que la seconde moitié prenne plus de temps à être validée ne pose aucun problème, car c’est la validation de la première qui garantit la réception finale des fonds.
Les drivechains
Vous avez déjà probablement entendu parler des sidechains, ces blockchains adossées à la blockchain Bitcoin qui permettent de déplacer des BTC d’une chaîne à l’autre. Dans le cas de ces chaînes, la sécurité est assurée par des entreprises influentes du milieu, c’est notamment le cas de la sidechain Liquid, mise en place par Blockstream.
Les drivechains ont tout en commun avec les sidechains, à l’exception de la manière dont elles sont sécurisées. Ces dernières seraient sécurisées par les mineurs de la blockchain Bitcoin. De ce fait, la puissance de hachage déployée sur le réseau Bitcoin protégerait également ces drivechains.
Cette proposition a été faite par les développeurs Paul Sztorc et CryptAxe sous la forme de deux soft forks, appelés Hashrate Escrows et Blind Merged Mining.
Pour plus de détails sur les différentes propositions de mise à niveau, vous pouvez consulter l’article de Aaron van Wirdum sur le sujet (en anglais).
Pour ceux qui ont suivi l’histoire des forks de Bitcoin, dans une bonne partie des cas, l’organisation ainsi que la réalisation d’un soft fork s’avère longue et périlleuse. L’ensemble des améliorations que nous avons vu précédemment en sont à un stade de développement avancé, cependant, elles ne seront pas forcement approuvées par la communauté et implémentées; seule l’année 2020 nous le dira.