Catégorie

Cryptomonnaie

Catégorie

Comment Fonctionne une Transaction Bitcoin

Que vous souhaitiez devenir développeur d’applications de blockchain ou que vous cherchiez simplement à comprendre ce qui se passe sous le capot lorsque vous envoyez des bitcoins à un ami, il est bon d’avoir une connaissance pratique de ce qui se passe lorsque vous créez  des transactions  sur le réseau Bitcoin. Pourquoi ?

Parce que les transactions sont la base sur laquelle se construit la blockchain Bitcoin. Les transactions sont le résultat d’un brillant mélange entre la cryptographie, les structures de données et un script simple de turing. Elles sont suffisamment simples pour que les types de transactions courants ne soient pas trop complexes, mais suffisamment souples pour permettre aux développeurs d’encoder également des types de transactions assez personnalisés. Aujourd’hui, nous allons faire un tour d’horizon des premiers type de transaction.

En tant que développeur, comment votre client Bitcoin affiche-t-il une nouvelle transaction sur le réseau (et que se passe-t-il lorsqu’il la reçoit) ?

Que se passe-t-il exactement lorsque vous envoyez des bitcoins à un ami ?

Cet article suppose que vous avez une connaissance de base du hachage, de la cryptographie asymétrique et des réseaux P2P. Il est également utile de bien comprendre ce qu’est exactement une blockchain, même si vous ne connaissez pas les mécanismes spécifiques.

Les transactions de bitcoin et leur rôle dans l’ensemble

Bitcoin est composé de  : nœuds et un blockchain. Le rôle d’un nœud typique est de maintenir sa propre version de blockchain et de la mettre à jour lorsqu’il entend parler d’une « meilleure » version (plus longue). En termes simples, la blockchain comporte des blocs et les blocs comportent des transactions.

En gardant cette image simplifiée mais précise à l’esprit, vous vous demandez peut-être de quoi est faite exactement une transaction. Comment les transactions me permettent-elles de transférer des bitcoins à un ami ?

Il s’avère que les réponses à ces questions varient en fonction de nombreux facteurs. Même en supposant que nous ne parlons que de bitcoin, nous pouvons utiliser les transactions de plusieurs manières pour atteindre divers objectifs personnalisés. Commençons par le début, c’est-à-dire par un bon vieux type de transaction de type « paiement à la carte ». Après tout, ce type de transaction représente plus de 99 % de toutes les transactions de la blockchain des bitcoins.

Tout d’abord, construisons un modèle. Il est tentant de considérer le bitcoin comme un système basé sur les comptes. Après tout, lorsque j’envoie des bitcoins à quelqu’un, cette personne reçoit de l’argent et il me reste un solde. Mais dans le monde réel, les choses sont représentées un peu différemment. En général, lorsque j’envoie de l’argent à quelqu’un, je dépense tout cet argent (moins les frais de transaction). Une partie de cet argent sera reversée sur mon compte personnel s’il existe un solde restant. Le fait est que tout l’argent bouge à chaque fois.

En gardant cela à l’esprit, nous pouvons généraliser et dire qu’une transaction de bitcoin a des entrées et des sorties. Une représentation graphique pourrait ressembler à ceci :

How-do-Bitcoin-Transactions-Actually-Work-1

Comment les transactions de bitcoin fonctionnent-elles réellement ?

Lorsque je publie une transaction, je « revendique » essentiellement une sortie et je prouve que j’ai la permission de dépenser la somme d’argent à cette sortie. Ainsi, si je suis Bob et que je veux payer Alice, ces entrées sont la preuve que j’ai reçu une certaine somme d’argent (bien que cela puisse ne représenter qu’une partie de mon solde total), et les sorties correspondront au compte d’Alice. Dans ce cas simple, il n’y aurait qu’une seule entrée et une seule sortie.

Un examen plus approfondi des transactions Bitcoin

Comprenons les mécanismes d’une véritable transaction de bitcoin. Nous utiliserons l’image ci-dessus comme référence.

Si vous découpez une transaction de bitcoin typique, vous vous retrouvez avec trois pièces principales : l’en-tête, les entrées et les sorties. Examinons brièvement les champs dont nous disposons dans ces sections, car ils seront importants pour la discussion. Notez qu’il s’agit des champs qui se trouvent dans une transaction dite brute. Les transactions brutes sont diffusées entre pairs lorsqu’une transaction est créée.

L’en-tête

  • haschisch : Le hachage sur l’ensemble de la transaction. bitcoin utilise généralement les valeurs de hachage à la fois comme pointeur et comme moyen de vérifier l’intégrité d’une donnée. Nous y reviendrons dans la prochaine section.
  • ver : Le numéro de version qui doit être utilisé pour vérifier ce bloc. La dernière version a été introduite dans un soft fork qui est devenu actif en décembre 2015.
  • vin_sz : Le nombre d’entrées pour cette transaction. De même, vout_sz compte le nombre de sorties.
  • lock_time : Nous y reviendrons dans des articles ultérieurs, mais cela décrit essentiellement le moment le plus précoce auquel un bloc peut être ajouté à la blockchain. Il s’agit soit de la hauteur du bloc, soit d’un horodatage unix.

Entrée

  • hachage de sortie précédent : Il s’agit d’un pointeur de hachage vers une sortie de transaction précédemment non dépensée (UTXO). Il s’agit essentiellement de l’argent qui vous appartient et que vous vous apprêtez à dépenser dans cette transaction.
  • n : Un index dans la liste des sorties de la transaction précédente. Il s’agit du produit réel que vous dépensez.
  • scriptSig : Il s’agit d’un script de dépense qui prouve que le créateur de cette transaction a la permission de dépenser l’argent référencé par 1. et 2.

Sortie

  • valeur : Le montant de Satoshi dépensé (1 CTB = 100.000.000 Satoshi).
  • scriptPubKey : Le second des deux scripts fournis dans une transaction bitcoin, qui indique la clé publique hash du destinataire. Plus d’informations à ce sujet dans la dernière section de cet article.

Vérification de la transaction

L’une des tâches d’un nœud bitcoin est de vérifier que les transactions entrantes sont correctes (les données n’ont pas été altérées, l’argent n’est pas créé, seuls les destinataires prévus dépensent des UTXO, etc.) Une liste plus exhaustive peut être trouvée en ligne, mais quelques-unes des plus importantes :

  • Toutes les sorties réclamées par les entrées de cette transaction sont dans le pool des UTXO. Les sorties non dépensées ne peuvent être réclamées qu’une seule fois.
  • Les signatures sur chaque entrée sont valables. Plus précisément, nous disons que les scripts combinés retournent vrais après les avoir exécutés l’un après l’autre. Plus d’informations à ce sujet dans la dernière section.
  • Aucun UTXO n’est dépensé plus d’une fois par cette transaction. Remarquez que cela est différent du premier élément.
  • Toutes les valeurs de sortie de la transaction sont non négatives.
  • La somme des valeurs d’entrée de cette transaction est supérieure à la somme des valeurs de sortie. Notez que si les chiffres sont différents, la différence est considérée comme un frais de transaction qui peut être réclamé par le mineur.

Une opération de base de paiement au moyen d’un PC de hachage

bitcoin possède son propre langage de script personnalisé (de type Forth) qui est suffisamment puissant pour permettre aux développeurs de créer des types de transactions complexes et personnalisés. Il existe environ cinq types de transactions standard qui sont acceptés par les clients de bitcoin standard , mais il existe d’autres clients qui acceptent d’autres types de transactions moyennant des frais. Nous nous contenterons ici d’aborder les mécanismes du hachisch de type « pay-to-PK ».

Pour qu’une transaction soit valable, une paire scriptSig/scriptPubKey doit être évaluée comme vraie. Plus précisément, un dépenseur de transaction fournit un scriptSig qui est exécuté et suivi par le scriptPubKey de la sortie de transaction réclamée (vous vous souvenez que nous avons dit que les entrées réclament les sorties de transactions précédentes non dépensées ?) ). Les deux scripts partagent la même pile.

Dans un souci d’efficacité, utilisons  une référence wikipedia ICI . Lorsque vous visitez le lien, allez à peu près à mi-chemin pour trouver un tableau contenant 7 lignes. Ce tableau montre comment les scripts sont combinés, comment l’exécution se produit et à quoi ressemble la pile à chaque étape.

Une chose à noter est que, comme les adresses bitcoin sont en fait des hachages (enfin, ça devient encore un peu plus compliqué ), il n’y a aucun moyen pour l’expéditeur de connaître la clé publique réelle pour la comparer à la clé privée. Par conséquent, le Rédempteur spécifie à la fois la clé publique et la clé privée, et le scriptPubKey dupliquera et hachera la clé publique pour s’assurer que le Rédempteur est bien le destinataire prévu.

Pendant l’exécution, vous pouvez voir que les constantes sont placées directement sur la pile lorsqu’elles sont rencontrées. Les opérations ajoutent ou retirent des éléments de la pile au fur et à mesure de leur évaluation. Par exemple, OP_HASH160 prendra l’objet du haut de la pile, et l’aura deux fois, d’abord avec SHA-256 et ensuite avec RIPEMD-160. Lorsque tous les éléments de notre script ont été évalués, l’ensemble de notre script sera évalué comme vrai si vrai reste sur la pile, et comme faux sinon.

Dans l’ensemble, le paiement au moyen du hachage par carte de crédit est un type de transaction assez simple. Il permet de s’assurer que seul un échangeur possédant la paire de clés publiques/privées appropriée peut réclamer et ensuite dépenser des bitcoins. En supposant que tous les autres critères soient remplis (voir la section précédente), la transaction est bonne et peut être placée dans un bloc.

Dans les prochains articles, je détaillerai les types de transactions plus complexes. Nous verrons comment plus de deux parties peuvent participer à une transaction, et nous verrons comment des types de transaction plus longs peuvent être mis en œuvre.