Les smart contracts avec Bitcoin (3/3) : Les cas d'utilisation

Dans la première partie de cette série d'articles, nous avons vu que Bitcoin était un système de monnaie programmable et que toutes les transactions faisaient intervenir des scripts, les smart contracts. Dans la deuxième partie, nous avons découvert comment le langage de script de Bitcoin fonctionnait. Nous allons voir aujourd'hui quelles utilisations on peut faire de ce langage de script, qui est d'une richesse étonnante même si il n'est pas aussi évolué que celui d'Ethereum.

Bitcoin est un système monétaire décentralisé. Il semble donc évident que la plupart des smart contracts auront un rapport, direct ou indirect, avec le domaine financier. On s'attachera ici à décrire le fonctionnement des usages les plus fréquents. On parlera d'abord des comptes multi-signatures, qui permettent aux utilisateurs de détenir des bitcoins à plusieurs. Puis, on verra comment se passe le dépôt fiduciaire dans le contexte de Bitcoin. Enfin, on s'intéressera aux canaux de paiement, qui forment les briques de base du réseau Lightning, l'une des solutions au problème de scalabilité de Bitcoin.

Les comptes multisignatures

Parmi tous les cas d'utilisation du langage de script de Bitcoin, le compte multi-signatures est largement le plus répandu. Il permet notamment l'existence de comptes joints entre personnes mariées ou entre plusieurs associés d'une entreprise.

Comme on l'a vu dans l'article précédent, les contrats sont généralement contenus au sein d'adresses P2SH (Pay-to-Script-Hash). Les contrats de multisignatures ne dérogent pas à la règle : c'est pourquoi la plupart de ces comptes prendront la forme d'une adresse à laquelle on envoie des fonds. Un exemple d'adresse signature est :

3DyDCGSC59yYY46dnRH7Vw1iKbV8zeW36q

Dans le contexte de SegWit, il existe des adresses P2WSH (Pay-to-Witness-Script-Hash) qui possèdent exactement la même fonction, comme :

bc1qjv5w5d64mac6esvxcqj4nmfsycssgp3rmxluhxcp9na3zu3xe6fqut04y3

Le schéma de multisignature fait intervenir un certain nombre de participants qui peut aller jusqu'à 15. Parmi ces personnes, le nombre de signataires requis pour dépenser des fonds est prédéfini et peut être strictement inférieur au nombre de participants. On prendra ici l'exemple d'un schéma à 3 participants et à 2 signataires.

Le script de règlement de ce schéma est formé des 3 clés publiques des participants :

2 <clé publique 1> <clé publique 2> <clé publique 3> 3 CHECKMULTISIG

OP_3 signifie qu'il y a 3 participants. De même, OP_2 signifie qu'on attend seulement 2 signatures valides pour déverrouiller les fonds.

Le déverrouillage de ce contrat se fait à l'aide de deux signatures, par exemple celles des participants 1 et 3 :

0 <signature 1> <signature 3>

OP_CHECKMULTISIG permet de vérifier si chacune des signature correspond à l'une des clés publiques. La présence de OP_0 provient d'une erreur de conception de OP_CHECKMULTISIG qui nécessite un élément supplémentaire pour être exécuté.

Le dépôt fiduciaire (escrow)

Un autre cas d'usage de la programmabilité de Bitcoin est le dépôt fiduciaire, aussi appelé escrow en anglais. Le dépôt fiduciaire est un mode de paiement qui cherche à réduire le risque inhérent à une transaction entre deux parties qui se méfient l'une de l'autre. Il s'agit essentiellement d'un recours à un tiers de confiance pour sécuriser la transaction.

Par exemple, supposons que deux personnes, Alice et Bob, veuillent réaliser une transaction sur Internet. Disons que Alice veuille acheter un bien à Bob. Puisqu'elles ne se connaissent pas, les deux personnes ne se font pas confiance. Elles recourent donc à un intermédiaire de confiance, Lenny, qui a une bonne réputation publique. Celui-ci se charge d'arbitrer la situation dans le cas où l'une des deux parties ne respecte pas les termes de la transactions.

Voyons comment le langage de script intervient dans tout cela. Si Bitcoin est réputé pour supprimer les tiers de confiance, ce n'est pas le cas ici : on en a toujours besoin. Cependant, Bitcoin permet de sécuriser un peu plus la chose.

Alice, Bob et Lenny construisent le contrat de dépôt fiduciaire à l'aide de leurs clés publiques et Alice envoie son paiement (disons 1 BTC) à l'adresse de ce contrat. Le script de règlement correspondant à ce contrat est :

IF
  <temps de verrouillage: 30 jours> CHECKSEQUENCEVERIFY DROP
  <clé publique de Lenny> CHECKSIGVERIFY
  1
ELSE
  2 
ENDIF
<clé publique d'Alice> <clé publique de Bob> 2 CHECKMULTISIG

Ce script est composé de deux branches conditionnelles. Les instructions situées après l'opérateur OP_IF sont exécutées si la valeur au sommet de la pile n'est pas FALSE. Si la valeur FALSE se trouve au sommet de la pile, ce sont les instructions situées entre OP_ELSE et OP_ENDIF qui sont exécutées. La valeur est supprimée du haut de la pile une fois le choix de branche réalisé.

Si tout se passe bien, Alice et Bob réalisent la transaction vers l'adresse de Bob. Si les circonstances font que Bob ne peut pas envoyer le bien à Alice, ils peuvent également annuler l'accord à l'amiable en signant une transaction vers l'adresse d'Alice. Dans les deux cas, le script de déverrouillage est :

0 <signature d'Alice> <signature de Bob> FALSE

Le code opératoire OP_FALSE permet d'accéder à la seconde branche conditionnelle et tout se passe comme dans le cas d'un compte multi-signatures à 2 signataires.

S'il y a litige, c'est là que Lenny intervient. Par exemple, on peut imaginer qu'Alice n'a pas reçu le bien (triche de Bob) ou qu'elle l'a reçu mais qu'elle affirme n'avoir rien reçu (triche d'Alice). Le script pour débloquer les fonds est alors :

0 <signature d'Alice ou de Bob> <signature de Lenny> TRUE

Grâce à OP_TRUE c'est la première branche conditionnelle qui est exécutée. On constate que cette partie du script fait intervenir un temps de verrouillage : celui-ci est comparé à celui de la transaction grâce à OP_CHECKSEQUENCEVERIFY. Il s'agit d'un temps de verrouillage relatif : cette branche ne peut être exécutée que 30 jours après la première transaction d'Alice. Le reste sert juste à vérifier la signature de Lenny, puis celle d'Alice ou de Bob selon l'arbitrage choisi par Lenny.

Le temps de verrouillage est très utile ici car il permet de dissuader Alice et Bob d'intervenir auprès de Lenny. S'il y a litige, ils devront attendre longtemps (ici 30 jours) avant que la situation soit débloquée, ce qui les incitera à favoriser un règlement à l'amiable.

Mieux : avant que ce temps de verrouillage soit passé, Alice ne peut pas corrompre l'intermédiaire de confiance Lenny (pour qu'ils se partagent les fonds par exemple). Elle ne peut pas non plus le menacer par la violence pour récupérer les fonds, puisqu'il n'a aucun pouvoir avant le délai imposé. Cette automatisation du processus a donc pour effet vertueux de sécuriser la situation de Lenny.

Les canaux de paiement bidirectionnels

Les canaux de paiement bidirectionnels constituent une amélioration majeure dans la capacité transactionnelle de Bitcoin. Ils permettent à deux participants de réaliser des paiements répétés qui ne sont pas enregistrés sur la chaîne de blocs. Cela rend possible réseau Lightning qui est tout simplement un réseau de canaux de paiements.

Pour ouvrir un canal de paiement bidirectionnel, les deux participants doivent créer un compte multisignatures. Ils construisent ensuite une transaction d'ouverture vers ce compte qui détermine la capacité du canal. Une fois le canal ouvert, les deux participants réalisent des paiements qui ne sont pas écrits sur la chaîne.

De manière générale, la fermeture du canal a lieu de manière consensuelle : les deux participants signent une transaction qui leur verse leurs soldes finaux respectifs. Cependant, il faut qu'ils soient incités à le faire et c'est là qu'interviennent les smarts contracts plus complexes.

Avant l'ouverture du canal et à chaque fois qu'un paiement est réalisé, les participants doivent tous les deux créer ce qu'on appelle une transaction d'engagement qui n'est diffusée sur le réseau qu'en cas de litige. Cette transaction sert donc de garantie pour que les participants ne trichent pas.

Nous allons voir ici en détail comment le processus a lieu. Supposons qu'Alice et Bob (encore eux !) ouvrent un canal de paiement qu'ils financent tous les deux à hauteur de 10 mBTC chacun.

Disons qu'Alice envoie 5 mBTC à Bob par le biais du canal. Alice doit construire et signer une transaction d'engagement qui permette de dépenser les fonds présents à l'adresse de façon à ce que Bob puisse récupérer ses fonds s'il est lésé. Pour ce faire :

• Elle génère un secret, un nombre qu'elle ne dévoile pas à Bob.
• Elle hache ce secret à l'aide de la fonction SHA-256 et envoie l'empreinte résultante à Bob.
• Avec cette empreinte, elle construit et signe la transaction d'engagement qui envoie 5 mBTC vers son adresse (ses 10 mBTC moins les 5 mBTC envoyés à Bob) et 15 mBTC vers l'adresse contenant un contrat de réclamation. Elle envoie cette transaction à Bob, qu'il pourra signer et diffuser sur le réseau si nécessaire.

De son côté, Bob construit et signe une transaction similaire qu'il envoie à Alice.

Le contrat de réclamation présent dans la transaction d'engagement d'Alice est :

IF 
  <temps de verrouillage : 1 jour> CHECKSEQUENCEVERIFY DROP
  <clé publique de Bob>
ELSE
  SHA256 <empreinte du secret de Bob> EQUALVERIFY
  <clé publique d'Alice>
ENDIF
CHECKSIG

Si quelqu'un se déconnecte, essaie de tricher ou refuse de rendre les fonds de manière consensuelle. Alors l'autre signe et diffuse la transaction d'engagement de l'autre. Par exemple, Bob peut signer et diffuser la transaction d'engagement d'Alice. Alice sera créditée de ses 5 mBTC. Bob pourra récupérer ses 15 mBTC un jour après l'inclusion de la transaction dans un bloc, grâce au script de déverrouillage :

<signature de Bob> TRUE

Lorsque qu'un paiement au sein du canal est effectué, chacun des participants génère un nouveau secret, échange l'empreinte de ce secret avec l'autre participant, et construit une nouvelle transaction d'engagement qu'il signe et envoie également à l'autre. Supposons ici que Bob envoie 1 mBTC à Alice.

Pour que le paiement au sein du canal soit effectif (que la canal soit correctement mis à jour), les précédents secrets sont échangés : cela permet d'éviter que quelqu'un ne triche en diffusant la transaction d'engagement précédente. Par exemple, si Bob essaie (pour récupérer 15 mBTC au lieu de 14), il doit attendre un jour pour récupérer les fonds, ce qui laisse à Alice le temps de récupérer tous les bitcoins du canal. En effet, elle peut alors dépenser les fonds présents à l'adresse du contrat de révocation en utilisant le secret précédent de Bob :

<signature d'Alice> <secret de Bob> FALSE

Les participants sont donc fortement incités à respecter les règles et à agir de manière consensuelle. Notez que ce type de stratégie est aussi utilisé dans le fonctionnement des atomic swaps.

Autres usages et sidechain RSK (Rootstock)

Les cas d'utilisation présentés ici ne sont que des exemples de ce qu'on peut faire avec cette monnaie programmable qu'est Bitcoin. Il en existe beaucoup d'autre. On peut notamment citer la prime pour la découverte d'une collision dans l'algorithme de hachage SHA-1, qui a permis à quelqu'un de récupérer 2.48 bitcoins le 23 février 2017. Cette prime était présente à l'adresse 37k7toV1Nv4DfmQbmZ8KuZDQCYK9x5KpzP qui contenait le contrat suivant :

2DUP EQUAL NOT VERIFY SHA1 SWAP SHA1 EQUAL

Toutefois, ce langage de script se heurte à deux inconvénients majeurs : la scalabilité limitée de Bitcoin et son incomplétude au sens de Turing. C'est pourquoi une équipe de développement travaille sur la mise en place d'une sidechain appelée RSK (anciennement Rootstock) qui élargirait les possibilités de smart contracts de Bitcoin.

Je suis fasciné par les cryptomonnaies et par l’impact qu’elles pourraient avoir sur nos vies. De formation scientifique, je m’attache à décrire leur fonctionnement technique de la façon la plus fidèle possible. Sur Cryptoast, je me propose de vous aider à mieux comprendre comment fonctionnent les cryptomonnaies (principalement Bitcoin, Bitcoin Cash et Ethereum) et quels sont les enjeux qui animent cet écosystème fascinant.

Ludovic Lars

65 articles

Tous ses articles