Le fonctionnement de la chaîne de blocs Bitcoin est relativement complexe. Il existe de nombreuses sources expliquant le processus de preuve de travail permettant de valider des blocs. Cependant, certaines questions sont rarement abordées. Qu'est-ce que contient un bloc ? Comment les transactions sont-elles écrites ? Comment fonctionnent-elles ? C’est ce que nous allons développer ici.
Dans un premier temps, il faudra peut-être oublier certaines choses que vous pensiez connaître sur la chaîne de blocs. « Dans Bitcoin, il n’y a pas de monnaies, pas d’expéditeurs pas de bénéficiaires, pas de comptes et pas d’adresses » - Andreas M. Antonopoulos dans Mastering Bitcoin. Tous ces concepts sont créés par-dessus la chaîne de blocs par des logiciels comme les portefeuilles et permettent une interface et une interaction plus simple pour les utilisateurs. En effet, la chaîne de blocs n’est pas conçue pour être facilement compréhensible par ses utilisateurs, elle est plutôt optimisée pour être fiable et sécurisée. Nous verrons comment ces concepts émergent après avoir expliqué le fonctionnement concret des transactions.
Voici un exemple de transaction tel qu’il est écrit dans un bloc (cet exemple est pris du livre Mastering Bitcoin de Andreas M. Antonopoulos) :
{
"version": 1,
"locktime": 0,
"vin": [
{
"txid": "7957a35fe64f80d234d76d83a2a8f1a0d8149a41d81de548f0a65a8a999f6f18",
"vout": 0,
"scriptSig" : "3045022100884d142d86652a3f47ba4746ec719bbfbd040a570b1deccbb6498c75c4ae24cb02204b9f039ff08df09cbe9f6addac960298cad530a863ea8f53982c09db8f6e3813[ALL] 0484ecc0d46f1918b30928fa0e4ed99f16a0fb4fde0735e7ade8416ab9fe423cc5412336376789d172787ec3457eee41c04f4938de5cc17b4a10fa336a8d752adf",
"sequence": 4294967295
}
],
"vout": [
{
"value": 0.01500000,
"scriptPubKey": "OP_DUP OP_HASH160 ab68025513c3dbd2f7b92a94e0581f5d50f654e7 OP_EQUALVERIFY OP_CHECKSIG"
},
{
"value": 0.08450000,
"scriptPubKey": "OP_DUP OP_HASH160 7f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a8 OP_EQUALVERIFY OP_CHECKSIG",
}
]
}
Les UTXO
Dans la chaîne de blocs, il n’y a pas de monnaies, il y a des UTXO.
Ce terme vient de l’anglais 'unspent transaction outputs' qui se traduirait par « le résultant d'une transaction qui n’a pas été dépensée ». Comme son nom l’indique, un UTXO représente une transaction qui a été reçue, mais qui n’a pas été dépensée.
Pour connaître le nombre de bitcoins en votre possession, votre portefeuille numérique va parcourir la chaîne de blocs à la recherche de tous vos UTXO. Votre balance sera ainsi la somme de ces derniers.
Pour effectuer une transaction, il faudra dans un premier temps référencer un UTXO qui se situe dans un ancien bloc. Cela est coder dans une partie appelée transaction input, ce qui est entre crochets [] après "vin" dans l’exemple plus haut. Dans un deuxième temps, de nouveaux UTXO sont créé (i.e. les bitcoins sont envoyés). Cela est coder dans une partie appelée transaction output, qui est entre crochets [] après "vout" dans l’exemple plus haut. Une fois la transaction validée et ajoutée dans un bloc, ces nouveaux UTXO pourront être dépensés par une prochaine transaction.
À noter qu’un UTXO doit être consommé entièrement lorsqu’il est référencé pour une transaction. Si l’UTXO est d’une valeur supérieure à celle que nous souhaitons envoyer, il faudra créer une deuxième transaction output vers sa propre adresse. Par exemple, pour envoyer 0,1 BTC avec un UTXO de 1BTC, l’expéditeur devra créer un UTXO de 0,1 (pour le bénéficiaire) puis un de 0,9BTC (pour lui-même). Il est aussi possible de combiner plusieurs petits UTXO (plusieurs transactions input) pour effectuer une plus grande transaction.
Le seul type de transaction dont l’UTXO n’a pas de référence (i.e. pas de transaction input) est la transaction coinbase (qui à donné sont nom à la plateforme d’échange). Cette transaction est la récompense que gagne un mineur lorsque son bloc est ajouté dans la chaîne Bitcoin. Concrètement, lorsqu’un mineur crée un bloc, il va écrire un transaction output de 12,5BTC (la valeur actuelle de la transaction coinbase, qui est divisée par 2 tous les 4 ans) pour sa propre adresse. Il va ensuite ajouter les autres transactions puis tenter de résoudre la preuve de travail. (Le mineur n’a aucun intérêt à se faire une transaction avec une valeur supérieure à 12,5 BTC puisqu’elle sera refusée par le reste du réseau. Il aura fait la preuve de travail pour rien.)
Ainsi, il est possible de remonter tous les UTXO à leur transaction coinbase via leur transaction input.
Nous allons maintenant expliquer ce qu’il y a dans les transaction outputs et les transaction inputs. Nous verrons alors pourquoi il n’y a pas d’expéditeurs, pas de bénéficiaires, pas de comptes et pas d’adresses dans un bloc de la chaîne Bitcoin.
Outputs de la transaction
Comme expliqué plutôt, les « outputs » sont présentées de la manière suivante :
"vout": [
{
"value": 0.01500000,
"scriptPubKey": "OP_DUP OP_HASH160 ab68025513c3dbd2f7b92a94e0581f5d50f654e7 OP_EQUALVERIFY OP_CHECKSIG"
},
{
"value": 0.08450000,
"scriptPubKey": "OP_DUP OP_HASH160 7f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a8 OP_EQUALVERIFY OP_CHECKSIG",
}
]
Dans chaque transaction output, il y a deux éléments : la valeur des bitcoins envoyés (les UTXO) indiquée dans l’exemple par "value" et un problème cryptographique qui détermine comment l’UTXO pourra être dépensé par la suite. Ceci est indiqué après "scriptPubKey".
Dans l’exemple ci-dessus, il y a deux outputs dans la transaction. Comme expliqué auparavant, cela vient du fait qu’un UTXO doit être consommé entièrement et que l’expéditeur s’est renvoyé le reste. Cependant, il serait aussi possible d’effectuer une transaction avec plusieurs outputs pour différents bénéficiaires ou encore des outputs avec des règles différentes pour la dépense des UTXO.
Lorsqu’un expéditeur souhaite effectuer une transaction, il va créer un problème cryptographique à partir du hash de la clé publique du bénéficiaire (ce qui correspond à son adresse sous un autre format). Ce problème devra être résolu par le bénéficiaire à l’aide de sa clé privée lorsqu’il souhaitera effectuer une transaction à son tour. Cette résolution sera indiquée dans la partie transaction inputs de sa future transaction.
Le fonctionnement de ce problème cryptographique ainsi que les différentes règles qui peuvent être choisies par l’émetteur de la transaction seront discutés plus en détail dans les parties deux et trois.
Inputs de la transaction
Comme présenté plutôt les « inputs » permettent de référencer un (ou des) ancien(s) UTXO. Voici comment elles sont organisées :
"vin": [
{
"txid": "7957a35fe64f80d234d76d83a2a8f1a0d8149a41d81de548f0a65a8a999f6f18",
"vout": 0,
"scriptSig" : "3045022100884d142d86652a3f47ba4746ec719bbfbd040a570b1deccbb6498c75c4ae24cb02204b9f039ff08df09cbe9f6addac960298cad530a863ea8f53982c09db8f6e3813[ALL] 0484ecc0d46f1918b30928fa0e4ed99f16a0fb4fde0735e7ade8416ab9fe423cc5412336376789d172787ec3457eee41c04f4938de5cc17b4a10fa336a8d752adf",
"sequence": 4294967295
}
]
Dans chaque « inputs », il y a 4 éléments :
- l’identifiant (le hash) de la transaction de référence qui contient l’UTXO que nous souhaitons consommer; ici représenté par « txid »
- l’indice (le positionnement) de l’UTXO dans la liste des « outputs » de la transaction; ici représenté par « vout » (l’indice commence par 0)
- le script permettant de résoudre le problème cryptographique; ici représenté par « scriptSig »
- le nombre séquence qui sera expliquer dans la partie 2; ici représenté par « sequence ».
Les « inputs » permettent ainsi de référencer un ancien UTXO dans la chaîne de blocs puis de prouver qu’il nous appartient en résolvant le problème cryptographique. Ainsi, si nous souhaitons comprendre entièrement la transaction, il faut aussi regarder le bloc qu’elle référence. Chaque nœud de validation du réseau Bitcoin devra effectuer ces opérations pour vérifier la validité des transactions qu’il reçoit.
Dans cet exemple, il y a seulement une « input » mais, comme expliqué auparavant, il est possible d’additionner plusieurs petits UTXO pour faire une plus grande transaction. Dans ce cas, il y aurait plusieurs « inputs », soit plusieurs références à différents anciens UTXO.
Les frais de transaction
Jusqu’à présent, nous n’avons pas parlé des frais de transaction. En effet, en plus de la récompense de 12,5 BTC que les mineurs obtiennent en ajoutant un nouveau bloc à la chaîne Bitcoin, ils récoltent également des frais pour chacune des transactions. Ces frais permettent d’éviter qu’une personne malintentionnée ralentisse ou bloque le réseau en effectuant énormément de petites transactions.
Comment sont-ils calculés? C’est très simple : c’est ce qui reste des UTXO qui n’a pas été consommé. Dans l’exemple plus haut, la transaction input fait référence à un UTXO de 0,1 BTC et la somme des transactions outputs est de 0,015 + 0,0845 = 0,0995. Les frais sont donc de 0,1 - 0,0995 = 0,0005BTC.
Ainsi, il n’est pas obligatoire de consommer entièrement un UTXO dans sa transaction, mais le reste sera envoyé au mineur (l’UTXO sera alors entièrement consommé).
Lorsqu’ils ajoutent des transactions dans un bloc, les mineurs vont avoir tendance à choisir celles avec le plus de frais (par kilobyte) en priorité, mais il est en théorie possible de faire une transaction sans frais.
Pour résumer, une transaction est composée de deux parties : les inputs qui font référence aux UTXO d’une ou d’anciennes transactions et les outputs qui permettent de créer les nouveaux UTXO. En faisant, référence à une ancienne transaction, l’émetteur résout un problème cryptographique (à l’aide de sa clé privée) pour prouver que la transaction lui était bien attribuée. Il génère ensuite de nouveaux problèmes cryptographiques (à l’aide de la clé publique des bénéficiaires) pour créer des nouveaux UTXO. Lorsque le bénéficiaire souhaitera émettre une transaction, il répétera le même procédé à son tour. Les frais de transactions destinés aux mineurs sont quant à eux calculés en faisant la somme des UTXO des inputs moins la somme des UTXO des outputs.
Dans la deuxième et troisième parties, nous expliquerons plus en détails le fonctionnement des problèmes cryptographiques pour bloquer puis débloquer les UTXO. Nous discuterons également des différents types de transactions qu’il est possible de réaliser en ajoutant des règles ou des conditions dans ces problèmes cryptographiques.