En 2017, la mise à jour WegWit, la plus importante du réseau, avait permis d’augmenter le nombre de transactions par seconde à une moyenne de 10 TPS (précisément de 5, voire 15 Transactions Par Seconde). Comme expliqué dans “les fondamentaux de la blockchain”, la blockchain Bitcoin permet d’effectuer des transactions de pair à pair sur un réseau totalement ouvert. Or, cela peut représenter un frein pour des secteurs où la confidentialité des opérations est primordiale.
Taproot est la seconde mise à jour la plus importante du réseau depuis WegWit. Elle permet des améliorations au niveau sur les transactions en renforçant la confidentialité et la performance au réseau.
Dans sa traduction littérale, le mot Taproot désigne la racine pivotante ou principale d’une plante. Dans le contexte Bitcoin, l’idée selon laquelle la mise à jour posera les nouveaux fondements; la colonne vertébrale de ce que sera Bitcoin : un système amélioré prenant en compte les spécificités des transactions, tout en assurant sa scalabilité.
De plus, cette mise à jour permettra d’augmenter la performance du réseau et des (futurs) Smart Contrat de Bitcoin et dans l’immédiat, elle ne change rien pour le grand public et s’adresse directement aux développeurs.
Pour en saisir l’intérêt, voyons quelles sont les différentes formes de transactions qui existent, avant d’entrer dans le vif du sujet.
Typologie des transactions sur la blockchain Bitcoin
Sur la blockchain Bitcoin, on a non seulement des transactions simples, mais aussi des transactions ayant des spécificités.
De manière générale, lorsque Paul souhaite envoyer de l’argent à Jacques, on se place dans le cadre d’une transaction simple.
On a ce que l’on nomme des “UTXO” : des entrées et des sorties, générées par la transaction.
Ces UTXO (entrées / sorties) ne peuvent être utilisées qu’une seule fois, c’est en cela que (techniquement) la blockchain Bitcoin est inaltérable et inviolable et que le réseau peut se passer d’un tiers de confiance pour garantir l’intégrité des transactions.
Par ailleurs, chaque UTXO d’entrée générée (solde que nous allons dépenser) est la sortie d’un UTXO de sortie d’une transaction précédente (solde reçu). Le fonctionnement de ce mécanisme central est garanti par le Script Bitcoin : le langage de programmation utilisé pour écrire toutes les opérations en Bitcoin.
Chaque transaction à un script associé qui permet :
- De valider les transactions
- Garantir que le solde envoyé ne puisse être dépensé plus d’une fois.
Le Script est la clé de voûte qui assure la bonne marche des opérations.
Pour que la transaction soit effectuée, il faut que les conditions du Script soient réunies afin de le débloquer et que la transaction soit effective.
Néanmoins, il existe de nombreuses autres possibilités, une transaction pouvant être conditionnée.
Précisément, les UTXO de sorties peuvent comporter un “script optionnel”, une condition qui doit être remplie pour que la sortie (d’argent) puisse être déverrouillée (dépensée).
Il existe un nombre important de transactions spécifiques, en voici quelques-unes :
- Une transaction où l’on a un “timelock” et où les fonds seront dépensés qu’une fois passé un certain bloc
- Une transaction multisignature, où plusieurs signatures sont nécessaires pour pouvoir déplacer les bitcoins
- Des transactions avec des scipts plus personnalisées où un mot de passe doit être renseigné pour dépenser les bitcoins.
Par ailleurs, il est possible de combiner ces scripts “simples” dans des scripts plus “complexes” (combinant plusieurs conditions optionnelles).
Bref, une myriade de transactions existe pour différents usages.
Or, du fait de l’ouverture du réseau, toutes les données cryptées sont publiques, y compris les données liées aux conditions optionnelles utilisées. Quasiment tout le monde peut y avoir accès en consultant le registre de transaction.
Par ailleurs, lorsque l’une des conditions est utilisée parmi la multitude de conditions possibles, toutes celles qui n’ont pas été utilisées sont exploitées pour authentifier le fait que la condition est bien remplie.
Par exemple, dans le cas d’une transaction multisignature, imaginons un scénario dans lequel, un portefeuille soit la propriété de quatre personnes. Avec la condition selon laquelle, trois signatures sont requises pour vérifier une transaction ; la validation de cette transaction (par les mineurs) passera forcément par une comparaison des clés publiques des signataires, avec l’intégrité des clés publiques appartenant aux propriétaires du portefeuille (4).
Dit autrement, l’UTXO est composé (entre autres) d’un script optionnel comportant plusieurs signatures qui peuvent être utilisées afin de déverrouiller le Script (le solde). Or, toutes les données liées aux signatures seront exploitées donc associées à la transaction, ce qui encombre l’espace de stockage dans les blocs.
Conséquence, on a deux inconvénients liés à l’authentification des conditions.
1/ Un manque de confidentialité, particulièrement lorsque l’on fait des transactions comportant des sommes importantes. Les opérations liées au portefeuille peuvent être tracées de bout en bout car, les adresses publiques associées à une transaction sont consultables sur la blockchain. Malgré la possibilité d’utiliser des HD wallet (Hierachical derterminstic wallet) et donc des adresses publiques différentes de celles qui sont générées via la clé publique (*). Au vu des besoins spécifiques des utilisateurs, la confidentialité reste tout de même insuffisante. Les informations sont cryptées, mais il est encore possible de repérer et analyser les mouvements d’un portefeuille donné.
(*) L’adresse publique d’un portefeuille est obtenu par la clé publique via la fonction de Hashage et la fonction RIPEMD-160 (↔ If (RIPEMD160 (SHA-256 (clé publique))), elle-même obtenue par la clé privée via le calcul de l’algorithme asymétrique ECDSA (Elliptic Curve Digital Signature) et la courbe elliptique : secp256k1. (Source : Bitcoin Academy)
2/ Pas d’optimisation en termes de stockage des transactions car, les données associées aux conditions inutilisées (lorsqu’il y en a plusieurs), sont liées à la transaction dans le block et prennent de l’espace.
Ce qui entraîne inéluctablement :
– La réduction mécanique du nombre de transactions validées toutes les 10 minutes
– Une augmentation (mécanique) des frais de la transaction
⇒ La mise à jour Taproot, opère un changement des règles qui régissent le fonctionnement du réseau et permet de pallier ces inconvénients.
Un changement de consensus : pour plus de confidentialité, agilité et performance du réseau
La mise à jour comporte trois “BIP” (“Bitcoin Improvment Proposal”). Sans entrer dans les détails techniques, voyons de façon concrète et synthétique, les trois propositions d’amélioration et leurs apports respectifs.
PROPOSITION 1
- LA SIGNATURE SCHNORR, un nouvel algorithme de signature permettant d’apposer une seule et même signature ayant un format réduit. Plus besoin de passer par les manœuvres d’authentification initiales (pour en savoir plus cf. fonctionnement de l’algorithme asymétrique ECDSA (Elliptic Curve Digital Signature).
Avantage :
→ Optimisation du stockage des transactions.
Conséquence :
- -Diminution des frais de transaction
- -Augmentation du nombre de transactions réalisable par seconde
PROPOSITION 2
- Le TAPSCRIPT, qui permet d’utiliser une clé publique Schnorr lors de la transaction (d’autres moyens intégrés sont possibles).
On a alors :
→ La possibilité de rendre la transaction non identifiable. Avec cette fonctionnalité, il est dorénavant possible d’intégrer directement une clé publique totalement anonymisée et non plus générée (entre autres) par la clé privée.
Avantage :
→ Prise en compte des spécificités des transactions
Conséquence :
- Augmentation de la confidentialité sur la blockchain
PROPOSITION 3
- Le TAPROOT, du même nom que la mise à jour : un code intégré permettant de coordonner et diffuser au réseau le Tapscript et la signature Schorr afin qu’ils soient bien intégrés et utilisables.
Ces propositions ne sont que les composantes liées qui constituent la mise à jour.
Comme toutes mises à jour, son succès dépendra de la proportion d’utilisateurs qui l’utiliseront, mais dans l’absolu Taproot permettra certainement au réseau de gagner en efficacité.
Par ailleurs, cette mise à jour va considérablement révolutionner l’écosystème Bitcoin avec l’arrivée du RGB. Vous souvenez-vous, nous avons évoqué les Smart Contracts de Bitcoin…
Jusqu’à nouvel ordre, Bitcoin, ne permet pas de créer des applications décentralisées. Cependant des travaux menés pourraient bien changer la donne. Le RGB, un protocole fonctionnant à la fois sur la blockchain et sur le Lightning Network(*) verra probablement le jour et bénéficiera de cette mise à jour, car Taproot est circonscrit (aussi) dans ce projet de développement. C’est un protocole qui ambitionne, pour Bitcoin, d’aller au-delà de ce que fait Ethereum aujourd’hui tout en dépassant les limites rencontrées par cette dernière, notamment au niveau des transactions Smart contrat. Dans tous les cas, la mise à jour contribuera aussi à un changement majeur en permettant à l’écosystème Bitcoin de jouer un rôle dans la création et le déploiement d’applications décentralisées au côté d’Ethereum et des autres blockchains concurrentes.
(*) Un protocole de seconde couche qui permet d’augmenter la scalabilité du réseau.
Pour plus d’info :
Le guide complet de la mise à jour
Les fondamentaux de la blockchain
Retrouve-nous sur Clubhouse le dimanche 14 novembre à 19 h, pour discuter des évolutions du Bitcoin et revenir sur ses fondamentaux.
Pour y accéder :
Téléchargez l’application Clubhouse et rejoignez-nous sur le club de discussion ici
