Une introduction au script Bitcoin

Introduction

Le Bitcoin est parfois appelé monnaie programmable. En raison de sa nature numérique, il offre aux utilisateurs une grande flexibilité lorsqu’il s’agit de définir les conditions de dépense des fonds.

Nous parlons de portefeuilles et de pièces lorsque nous parlons de Bitcoin. Mais nous pourrions également considérer les portefeuilles comme des clés, les pièces de monnaie comme des chèques et la blockchain comme une rangée après l’autre de coffres-forts verrouillés. Chaque coffre-fort est doté d'une fine fente, de sorte que n'importe qui peut déposer des chèques ou regarder à l'intérieur pour voir la valeur du coffre-fort. Toutefois, seul le détenteur de la clé pourra accéder à l’intérieur.

Lorsqu’un détenteur de clé souhaite donner de l’argent à quelqu’un d’autre, il déverrouille sa boîte. Ils établissent un nouveau chèque faisant référence à l'ancien (qui est ensuite détruit) et le verrouillent dans une boîte que le destinataire peut ouvrir. Pour dépenser cela, le nouveau destinataire répète le processus.

Dans cet article, nous examinerons de plus près Script, le langage de programmation interprété par les nœuds du réseau Bitcoin. Le script est ce qui régit le mécanisme de verrouillage/déverrouillage mentionné pour les coffres-forts.

Comment fonctionne le Bitcoin ?

En reprenant notre analogie ci-dessus, vous pourriez dire que chaque transaction comporte deux parties : une clé (pour déverrouiller votre boîte) et un verrou. Vous utilisez votre clé pour ouvrir la boîte contenant le chèque que vous souhaitez envoyer, puis vous en ajoutez une nouvelle à une nouvelle boîte avec un verrou différent. Pour dépenser depuis la nouvelle boîte, vous avez besoin d'une autre clé.

Assez simple. Vous pouvez également obtenir quelques variations sur les types de serrures du système. Peut-être que certains coffres-forts exigent que vous fournissiez plusieurs clés, et peut-être que d'autres nécessitent que vous prouviez que vous connaissez un secret. Il y a toute une série de conditions que les gens peuvent poser.

Notre clé est ce que nous appelons un scriptSig. Le verrou est notre scriptPubKey. Si nous examinons ces composants un peu plus en détail, nous constaterons qu’ils sont en réalité constitués de bits de données et de blocs de code. Une fois combinés, ils créent un petit programme.

Lorsque vous effectuez une transaction, vous diffusez cette combinaison sur le réseau. Chaque nœud qui le reçoit vérifiera le programme, qui lui indiquera si la transaction est valide. Sinon, il sera simplement rejeté et vous ne pourrez pas dépenser les fonds bloqués.

Les chèques (pièces) que vous détenez sont appelés sorties de transaction non dépensées (UTXO). Les fonds peuvent être utilisés par toute personne pouvant fournir la clé adaptée à la serrure. Plus précisément, la clé est le scriptSig et le verrou est le scriptPubKey.

Si les UTXO sont dans votre portefeuille, ils auront probablement une condition stipulant que seule la personne pouvant prouver qu'elle est propriétaire de cette clé publique peut débloquer ces fonds. Pour le déverrouiller, vous fournissez un scriptSig qui inclut une signature numérique, en utilisant la clé privée qui correspond à la clé publique spécifiée dans scriptPubKey. Tout cela deviendra plus clair sous peu.

Comprendre la pile Bitcoin

Le script est ce qu’on appelle un langage basé sur une pile. Tout cela signifie que, lorsque nous lisons un ensemble d’instructions, nous les plaçons dans ce que l’on peut considérer comme une colonne verticale. La liste A, B, C, par exemple, donnerait une pile avec A en bas et C en haut. Lorsque les instructions nous demandent de faire quelque chose, nous opérons sur un ou plusieurs éléments en commençant par le haut de la pile.

Les éléments A, B et C sont ajoutés et « supprimés » de la pile.

Nous pouvons faire la distinction entre les données (des éléments comme les signatures, les hachages et les clés publiques) et les instructions (ou opcodes). Les instructions suppriment les données et en font quelque chose. Voici un exemple très simple de ce à quoi pourrait ressembler un script :

<xyz> <md5 hasher> <d16fb36f0911f878998c136191af705e> <vérifier si égal>

En rouge, nous avons les données, et en bleu, nous avons les opcodes. Nous lisons de gauche à droite, nous mettons donc d'abord la chaîne <xyz> sur la pile. La prochaine étape est l'opcode <md5 hasher>. Celui-ci n’existe pas dans Bitcoin, mais disons qu’il supprime l’élément supérieur de la pile (<xyz>) et le hache à l’aide de l’algorithme MD5. Ensuite, la sortie est rajoutée sur la pile. La sortie ici se trouve être d16fb36f0911f878998c136191af705e.

Quelle coïncidence! Notre prochain élément à ajouter est <d16fb36f0911f878998c136191af705e>, donc maintenant notre pile a deux éléments identiques. Enfin, <check if égal> fait apparaître deux éléments du haut et vérifie s'ils sont égaux. Si tel est le cas, cela ajoute <1> à la pile. Sinon, il ajoute <0>.

Nous sommes arrivés à la fin de notre liste d’instructions. Notre script aurait pu échouer de deux manières : si l'élément restant était un zéro, ou si l'un des opérateurs provoquait son échec lorsque certaines conditions n'étaient pas remplies. Nous n'avions pas de tels opérateurs dans cet exemple, et nous nous retrouvons avec un élément non nul (<1>), donc notre script était valide. Ces règles s’appliquent également aux transactions Bitcoin réelles.

C'était juste un programme inventé. Examinons-en quelques-uns maintenant.

Payer pour Pubkey (P2PK)

Pay-to-Pubkey (P2PK) est incroyablement simple. Cela implique de verrouiller les fonds sur une clé publique particulière. Si vous souhaitez recevoir des fonds de cette manière, vous fournirez à l’expéditeur votre clé publique, par opposition à une adresse Bitcoin.

La toute première transaction entre Satoshi Nakamoto et Hal Finney en 2009 était une transaction P2PK. La structure était largement utilisée au début du Bitcoin, mais de nos jours, Pay-to-Pubkey-Hash (P2PKH) l'a largement remplacée.

Le script de verrouillage pour une transaction P2PK suit le format <public key> OP_CHECKSIG. Assez simple. Vous avez peut-être deviné que OP_CHECKSIG vérifie une signature par rapport à la clé publique fournie. En tant que tel, notre scriptSig sera une simple <signature>. N'oubliez pas que le scriptSig est la clé du verrou.

Il n’y a rien de plus simple que cela. Une signature est ajoutée à la pile, suivie d'une clé publique. OP_CHECKSIG les affiche tous les deux et vérifie la signature par rapport à la clé publique. S'ils correspondent, cela ajoute un <1> à la pile. Sinon, cela ajoute un <0>.

Pour les raisons que nous développerons dans la section suivante, le P2PK n’est plus vraiment utilisé.

Payer pour Pubkey-Hash (P2PKH)

Pay-to-Pubkey-Hash (P2PKH) est désormais le type de transaction le plus courant. À moins que vous ne cherchiez à télécharger des logiciels archaïques, votre portefeuille le fait probablement par défaut.

Le scriptPubKey dans P2PKH est le suivant :

OP_DUP OP_HASH160 <hachage de clé publique> OP_EQUALVERIFY OP_CHECKSIG

Avant de présenter le scriptSig, décomposons ce que feront les nouveaux opcodes :

OP_DUP

OP_DUP affiche le premier élément et le duplique. Ensuite, il ajoute les deux à la pile. Généralement, cela est fait pour que nous puissions effectuer une opération sur le duplicata sans affecter l'original.

OP_HASH160

Cela fait apparaître le premier élément et le hache deux fois. Le premier tour sera haché avec l'algorithme SHA-256. La sortie SHA-256 est ensuite hachée avec l'algorithme RIPEMD-160. La sortie résultante est rajoutée sur la pile.

OP_EQUALVERIFY

OP_EQUALVERIFY combine deux autres opérateurs – OP_EQUAL et OP_VERIFY. OP_EQUAL affiche deux éléments et vérifie s'ils sont identiques. Si tel est le cas, cela ajoute un 1 à la pile. Sinon, il ajoute un 0. OP_VERIFY affiche l'élément supérieur et vérifie s'il est vrai (c'est-à-dire différent de zéro). Si ce n’est pas le cas, la transaction échoue. Combiné, OP_EQUALVERIFY provoque l'échec de la transaction si les deux premiers éléments ne correspondent pas.

Cette fois, le scriptSig ressemble à ceci :

<signature> <clé publique>

Vous devez fournir une signature et la clé publique correspondante pour déverrouiller les sorties P2PKH.

Vous pouvez voir ce qui se passe dans le GIF ci-dessus. Ce n'est pas trop différent d'un script P2PK. Nous ajoutons simplement une étape supplémentaire pour vérifier que la clé publique correspond au hachage dans le script.

Il y a cependant quelque chose à noter. Dans un script de verrouillage P2PKH, la clé publique n'est pas visible – on ne peut voir que son hachage. Si nous accédons à un explorateur de blockchain et examinons une sortie P2PKH qui n’a pas été dépensée, nous ne pouvons pas déterminer la clé publique. Cela n’est révélé que lorsque le destinataire décide de transférer les fonds.

Cela présente quelques avantages. La première est que le hachage de clé publique est tout simplement plus facile à transmettre qu’une clé publique complète. Satoshi l'a lancé en 2009 pour cette raison. Le hachage de clé publique est ce que nous appelons aujourd’hui une adresse Bitcoin.

Le deuxième avantage est que les hachages de clé publique pourraient fournir une couche de sécurité supplémentaire contre l’informatique quantique. Étant donné que notre clé publique n’est connue que lorsque nous dépensons les fonds, il est encore plus difficile pour d’autres de calculer la clé privée. Ils devraient inverser les deux cycles de hachage (RIPEMD-160 et SHA-256) pour l'obtenir.

➠ Vous cherchez à vous lancer dans la crypto-monnaie ? Achetez du Bitcoin sur Binance !

Paiement au script-Hash (P2SH)

Pay-to-Script-Hash (P2SH) était un développement très intéressant pour Bitcoin. Il permet à l’expéditeur de verrouiller les fonds sur le hachage d’un script – il n’a pas besoin de savoir ce que fait réellement le script. Prenez le hachage SHA-256 suivant :

e145fe9ed5c23aa71fdb443de00c7d9b4a69f8a27a2e4fbb1fe1d0dbfb6583f1

Vous n’avez pas besoin de connaître l’entrée du hachage pour y verrouiller les fonds. Le dépensier, cependant, doit fournir le script qui a été utilisé pour le hacher et doit satisfaire aux conditions de ce script.

Le hachage ci-dessus a été créé à partir du script suivant :

<multiplier par 2> <4> <vérifier si égal>

Si vous souhaitez dépenser les pièces liées à ce scriptPubKey, vous ne fournissez pas seulement ces commandes. Vous avez également besoin d'un scriptSig qui permet au script terminé d'être évalué à True. Dans cet exemple, il s’agit d’un élément que vous <multipliez par 2> pour donner un résultat de <4>. Bien sûr, cela signifie que notre scriptSig n'est que <2>.

Dans la vraie vie, le scriptPubKey pour une sortie P2SH est :

OP_HASH160 <redeemScript hachage> OP_EQUAL

Pas de nouveaux opérateurs ici. Mais nous avons <redeemScript hash> comme nouvel élément. Comme son nom l’indique, il s’agit d’un hachage du script que nous devons fournir pour racheter les fonds (appelé « redemptScript »). Le scriptSig changera en fonction du contenu du rachatScript. En général, cependant, vous constaterez qu'il s'agit d'une combinaison de signatures et de clés publiques jointes, suivie du script de rachat (obligatoire) :

<signature> <clé publique> <redeemScript>

Notre évaluation diffère un peu de l’exécution de la pile que nous avons vue jusqu’à présent. Cela se déroule en deux parties. Le premier vérifie simplement que vous avez fourni le bon hachage.

Vous remarquerez que nous ne faisons rien avec les éléments précédant le rachatScript. Ils ne sont pas utilisés à ce stade. Nous avons atteint la fin de ce mini-programme et l’élément supérieur est non nul. Cela signifie que c’est valide.

Mais nous n’avons pas encore fini. Les nœuds du réseau reconnaissent cette structure comme P2SH, ils ont donc en fait les éléments du scriptSig en attente dans une autre pile. C'est là que la signature et la clé publique seront utilisées.

Jusqu'à présent, nous avons traité le rachatScript comme un élément. Mais maintenant, cela sera interprété comme des instructions, qui pourraient être n’importe quoi. Prenons l'exemple d'un script de verrouillage P2PKH, auquel nous devons fournir la <signature> et la <public key> qui correspondent à un <public key hash> à l'intérieur du <redeemScript>.

Une fois votre rachatScript développé, vous pouvez voir que nous nous trouvons dans une situation qui ressemble exactement à une transaction P2PKH classique. À partir de là, vous l’exécutez comme vous le feriez normalement.

Nous avons démontré ici ce qu’on appelle un script P2SH (P2PKH), mais il est peu probable que vous en trouviez un dans la nature. Rien ne vous empêche d'en créer un, mais cela ne vous apporte aucun avantage supplémentaire et finit par prendre plus de place dans un bloc (et coûte donc plus cher).

P2SH est généralement utile pour des choses comme les transactions multisignatures ou compatibles SegWit. Les transactions multisig peuvent être très volumineuses car elles peuvent nécessiter plusieurs clés. Avant la mise en œuvre de Pay-to-Script-Hash, un expéditeur devait lister toutes les clés publiques possibles dans son script de verrouillage.

Mais avec P2SH, peu importe la complexité des conditions de dépenses. Le hachage du rachatScript est toujours d'une taille fixe. Les coûts sont donc répercutés sur le(s) utilisateur(s) qui souhaitent déverrouiller le script de verrouillage.

La compatibilité SegWit est un autre cas où P2SH s'avère utile (nous entrerons dans les détails de la façon dont la structure des transactions diffère dans la section suivante). SegWit était un soft fork qui a entraîné une modification des formats de bloc/transaction. Puisqu’il s’agit d’une mise à niveau facultative, tous les logiciels de portefeuille ne reconnaissent pas les modifications. Peu importe si les clients encapsulent le hachage du script SegWit dans P2SH. Comme pour toutes les transactions de ce type, ils n’ont pas besoin de savoir quel sera le script de déverrouillage.

Transactions SegWit (P2WPKH et P2WSH)

Pour une introduction plus complète à SegWit, consultez le Guide du débutant sur les témoins séparés.

Pour comprendre le format de transaction dans SegWit, il suffit de savoir que nous n'avons plus seulement un scriptSig et un scriptPubKey. Maintenant, nous avons également un nouveau champ appelé témoin. Les données que nous avions l'habitude de conserver dans le scriptSig sont déplacées vers le témoin, le scriptSig est donc vide.

Si vous rencontrez des adresses commençant par « bc1 », il s'agit de ce que nous appelons SegWit-native (par opposition à simplement compatibles SegWit, qui commencent par un « 3 » puisqu'il s'agit d'adresses P2SH).

Paiement au témoin-Pubkey-Hash (P2WPKH)

Pay-to-Witness-Pubkey-Hash (P2WPKH) est la version SegWit de P2PKH. Notre témoin ressemble à ceci :

<signature> <clé publique>

Vous remarquerez que c'est la même chose que le scriptSig de P2PKH. Ici, le scriptSig est vide. Pendant ce temps, le scriptPubKey ressemble à ce qui suit :

<OP_0> <hachage de clé publique>

Cela semble un peu étrange, n'est-ce pas ? Où sont les opcodes pour comparer la signature, la clé publique et son hachage ?

Nous n'affichons pas d'opérateurs supplémentaires ici, car les nœuds qui reçoivent la transaction savent quoi en faire en fonction de la longueur du <hachage de clé publique>. Ils calculeront la durée et comprendront qu’elle doit être exécutée dans le même style qu’une bonne vieille transaction P2PKH.

Les nœuds non mis à niveau ne savent pas comment interpréter la transaction de cette manière, mais cela n'a pas d'importance. Selon les anciennes règles, il n'y a pas de témoin, donc ils lisent un scriptSig vide et quelques données. Ils évaluent cela et le marquent comme valide – en ce qui les concerne, n’importe qui peut dépenser le résultat. C’est pourquoi SegWit est considéré comme un soft fork rétrocompatible.

Paiement au témoin-Script-Hash (P2WSH)

Pay-to-Witness-Script Hash (P2WSH) est le nouveau P2SH. Si vous êtes arrivé jusqu’ici, vous pouvez probablement comprendre à quoi cela ressemblera, mais nous l’examinerons quand même. Notre témoin est ce que nous mettions normalement dans le scriptSig. Dans un P2WSH qui encapsule une transaction P2PKH, par exemple, cela pourrait ressembler à ceci :

<signature 1> <clé publique>

Voici notre scriptPubKey :

<OP_0> <hachage de script>

Les mêmes règles s’appliquent. Les nœuds SegWit lisent la longueur du hachage du script et déterminent qu'il s'agit d'une sortie P2WSH, qui est évaluée de la même manière que P2SH. Pendant ce temps, les anciens nœuds le voient simplement comme une sortie que tout le monde peut dépenser.

Pensées finales

Dans cet article, nous en avons appris un peu plus sur les éléments constitutifs du Bitcoin. Résumons-les rapidement :

Une fois que vous aurez approfondi vos connaissances sur Bitcoin, vous commencerez à comprendre pourquoi il a autant de potentiel. Les transactions peuvent être composées de nombreux éléments différents. En manipulant ces éléments de base, les utilisateurs disposent d’une grande flexibilité lorsqu’il s’agit de définir les conditions sur la manière et le moment où les fonds peuvent être dépensés.

➠ Des questions sur le script ? Rendez-vous sur Ask Academy !