⚡ Bitcoin Lightning en détail: Ouverture d'un canal
Cet article est le premier d'une série qui va explorer plus en détail le cycle standard de la participation au réseau Lightning: de la création d'un canal à sa fermeture, en passant par l'exécution des transactions.
Afin d'avoir une bonne vue d'ensemble du processus, il est fortement conseillé de commencer cette série par Bitcoin Lightning: Comment Ça Marche?.
Nous allons nous concentrer sur l'étape 2 du diagramme ci-dessus, en essayant de limiter le jargon technique. Le but étant d'éviter une explication qui rendrait obscures les étapes intermédiaires.
Qu'est-ce qu'un canal Lightning ?
Il s'agit en fait d'une transaction qui envoie des fonds de garantie par un contrat multi-signatures 2-de-2. Cela crée un UTXO et le canal est ouvert jusqu'à ce que cet UTXO soit dépensé par une transaction de fermeture du canal.
Lorsque vous consultez la balance de vos Bitcoins dans un portefeuille, celui-ci vous affiche la somme de toutes ses transactions non dépensées, et dont vous seul êtes capable de les décaisser (grâce à votre clé privée)
Pendant la durée de vie du canal, un certain nombre de microtransactions sont créées et finalement la balance de toutes ces transactions sera enregistrée sur la chaîne Bitcoin et le canal sera fermé. On ne verra alors que ces deux transactions sur la chaîne : celle pour ouvrir le canal et celle pour le fermer, les microtransactions ayant été complétées durant la vie du canal n'y apparaîtront pas.
Qu'est ce qu'une transaction multi-signatures 2-de-2?
Si un seul des signataires ayant été définis dans le script de dépense associé à la première adresse est capable de signer la transaction, celle-ci est impossible.
Lorsque deux des deux (2-de-2) signataires ayant été définis dans le script de dépense associé à la première adresse sont capables de signer la transaction de dépense, celle-ci peut être exécutée!
Les étapes de la création d'un canal
La façon avec laquelle un canal est créé entre 2 nœuds du réseau Lightning est définie dans le document de spécification BOLT: Basis Of Lightning Technology. Particulièrement dans la section BOLT2 disponible ici: https://github.com/lightning/bolts/blob/master/02-peer-protocol.md
Nous allons tenter ensemble de démystifier chacun des messages qui constituent la création d'un canal.
Tout commence par Alice qui a sélectionné le nœud de Bob, et est capable de s'y connecter, pour ouvrir un canal Lightning afin de pouvoir envoyer et recevoir des Bitcoins directement à Bob ou par son intermédiaire.
À la date de cet article, dans le réseau Lightning, un canal est souvent financé par une seule partie, dans notre exemple, ce sera Alice.
N'oublions pas aussi que l'objectif du protocole de création décrit ci-dessous est ultimement de créer la transaction de financement multi-signatures 2-de-2 entre Alice et Bob.
Pourquoi doit-on passer au travers de ces étapes de communication et de validation entre Alice et Bob?
Tout simplement, pour que Alice soit protégée contre le risque que Bob disparaisse et ne soit jamais là pour signer une transaction visant à dépenser les fonds de cette transaction de financement, ce qui signifierait que les fonds d'Alice seraient bloqués dans cette UTXO pour toujours.
Passons donc en revue chacun des messages présentés dans le diagramme ci-dessous pour voir comment Alice et Bob établissent leur relation de confiance pour l'ouverture de ce canal.
En cas d'échec à une étape quelconque, ou si un nœud décide que les conditions du canal offertes par l'autre nœud ne lui conviennent pas, l'établissement du canal échouera.
Jusqu'à l'attribution d'un identifiant unique channel_id (celui qui apparaît publiquement dans les explorateurs de réseau Lightning), un identifiant temporaire pour le canal sera utilisé entre les deux participants: temporary_channel_id
(1) open_channel
Source: https://github.com/lightning/bolts/blob/master/02-peer-protocol.md#the-open_channel-message
Alice envoie ce message à Bob pour lui indiquer qu'elle souhaite ouvrir un canal avec lui. Ce message contient divers détails concernant les demandes d'Alice pour ce nouveau canal (dont le montant en Satoshi qu'elle va commettre dans la transaction: funding_satoshis), mais le plus important est la clé publique de financement funding_pubkey. Il s'agit de la clé publique qu'Alice a l'intention d'utiliser dans le script de la transaction de financement qui sera consignée sur la chaîne Bitcoin.
(2) accept_channel
Source: https://github.com/lightning/bolts/blob/master/02-peer-protocol.md#the-accept_channel-message
Si Bob est satisfait des conditions proposées par Alice dans son offre d'ouverture de canal, il peut renvoyer à Alice un message accept_channel qui contient également certaines de ses exigences ainsi que la clé de financement qu'il a l'intention d'utiliser funding_pubkey.
Interlude
À ce stade, Alice est prête à construire la transaction de financement, mais elle devra attendre une garantie de la part de Bob avant de la diffuser sur le réseau Bitcoin.
Elle a d'abord besoin d'une transaction d'engagement signée par Bob qui divisera le solde du canal selon leurs accords.
De plus, Bob souhaite également disposer d'une transaction d'engagement valide au cas où Alice disparaîtrait.
Pour le moment, et avant d'envoyer le prochain message du protocole d'ouverture, Alice construit la transaction de financement dont le script de dépense est vérifiable, car relié directement à l'identifiant de transaction funding_txid.
Cependant, elle ne diffuse pas encore la transaction. Elle envoie maintenant un message funding_created à Bob pour l'informer de l'état actuel de la transaction.
(3) funding_created
Source: https://github.com/lightning/bolts/blob/master/02-peer-protocol.md#the-funding_created-message
Ce message contient le funding_txid de la transaction de financement créée par Alice, ainsi que l'index de sortie approprié funding_output_index et une signature associée à la clé publique de Alice pour que Bob puisse créer sa transaction d'engagement initiale.
Remarquez que Bob ne peut encore rien faire avec sa transaction d'engagement puisqu'elle est dépensée à partir d'une transaction qui n'est pas encore sur la chaîne de blocs.
Nous étudierons ce type de transaction dans un autre article de la série, mais le plus important à retenir, dans notre cas d'ouverture d'un canal, est que ces transactions permettent (sous certaines conditions, par exemple pas avant que 1000 blocs soient confirmés sur la chaîne de blocs) à chacun de récupérer leurs fonds si l'une des parties disparaît.
source: https://github.com/lightning/bolts/blob/master/03-transactions.md#commitment-transaction
(4) funding_signed
Source: https://github.com/lightning/bolts/blob/master/02-peer-protocol.md#the-funding_signed-message
Ce message contiendra la signature de Bob pour la transaction d'engagement d'Alice (c'est grâce à cette signature que Alice peut vérifier que Bob a créé la transaction d'engagement qui la remboursera en cas de problème ultérieur).
À ce stade, Alice dispose désormais d'une transaction d'engagement valide signée par Bob, qui dépense à partir de la transaction de financement. Alice peut donc diffuser l'opération de financement en toute sécurité.
C'est à ce moment que le channel_id pour identifier le canal officiellement est créé. Il est dérivé de la transaction de financement en combinant le funding_txid et le funding_output_index.
(5,6) channel_ready
Source: https://github.com/lightning/bolts/blob/master/02-peer-protocol.md#the-channel_ready-message
À ce stade, les deux parties surveillent la chaîne de blocs en attendant que la transaction de financement soit confirmée après le nombre de confirmations minimum_depth définie dans les conditions d'ouverture de la première étape. Une fois que chaque partie la voit, elle envoie à l'autre partie le message channel_ready qui contient l'identifiant du canal.
Lorsque les messages channel_ready sont échangés, le canal est enfin ouvert!
Conclusion
Une fois toutes les étapes complétées par Alice et Bob, le canal est ouvert. Alice peut commencer à l'utiliser grâce aux fonds de financement initiaux qu'elle a commis dans la transaction d'ouverture.
Dans un prochain article, nous allons étudier comment Alice et Bob peuvent se mettre d'accord sur une nouvelle répartition des fonds à chaque nouvelle transaction Lightning.