Transaction via un canal
Le début d’une transaction se déroule comme avec du fiat, c’est-à-dire que la boulangerie va présenter une facture (invoice) à Alain lui précisant qu’il doit 20 000 satoshis. Cela va générer une adresse de facture souvent représentée par un QR code pour faciliter la procédure de paiement.
Le début de l’adresse d’invoice (lnbc5u1) est compréhensible par l’homme :
- ln = Lightning Network
- bc = Bitcoin (mainnet)
- 5u = 5 × 0,000001 BTC = 500 satoshis
m = milli ^3
u = micro ^6
n = nano ^9
p = pico ^12
1 = séparateur avant le reste des informations
Le reste des informations contient tout ce qui est nécessaire pour la transaction (date/heure de la transaction, expiration, signature, etc…)
Pour conclure cette transaction, il va falloir réaliser une nouvelle transaction d’engagement. Comme la première qui a été réalisée pour le premier dépôt sur le portefeuille multisig.
À noter que : à aucun moment les bitcoins qui sont sur le portefeuille multisig bougent pendant les transactions. C’est tout le principe des transactions sur LN. L’état du canal est représenté par la dernière transaction d’engagement non publiée. La nouvelle transaction d’engagement vient chasser la précédente et nous verrons en détail comment plus tard dans le cours.
Alain et la boulangerie vont ainsi chacun de leur côté construire la transaction d’engagement (non publiée). Ils vont demander la signature de l’autre partie. Ce n’est qu’à la fermeture du canal que cette transaction d’engagement sera utilisée depuis le portefeuille multisig pour répartir les fonds.
Mais, alors, comment ça se passe si l’une des deux parties veut tricher grâce à une ancienne transaction d’engagement ?
Imaginons qu’Alain dépense la moitié de ses fonds en croissants et décide de tricher en publiant la toute première transaction d’engagement qui stipulait que tous les fonds lui appartenaient. Cela serait très problématique.
Tout se passe également dans la transaction d’engagement. J’ai volontairement omis un détail dans le schéma ci-dessus. La transaction qui est construite contient deux champs « anti-triche » :
- Timelock
- Revocation
Le premier (timelock) permet au créateur de la transaction de récupérer les fonds vers un portefeuille à lui après x blocs inscrits dans la blockchain.
Le second (revocation) permet à n’importe qui possédant la clé secrète des deux parties (Alain et la boulangerie) de récupérer la totalité des fonds.
Par conséquent, la transaction construite n’est pas exactement la même, mais surtout avant de faire signer la nouvelle transaction d’engagement, chaque partie va demander à l’autre, le secret de la précédente transaction.
Conclusion : si Alain venait à publier une ancienne transaction d’engagement, il devrait attendre le timelock. Tandis que la boulangerie, si elle s’apercevait de la tricherie, pourrait immédiatement récupérer la totalité des fonds du canal grâce au champ revocation et le secret d’Alain.
Transaction multicanal
Ouvrir un canal avec un ami, ça a du sens, mais dans la vraie vie, on ne va pas ouvrir soi-même un canal avec tous les commerçants. En ouvrant des canaux, les utilisateurs du protocole Lightning Network vont former un réseau pair-à-pair. Ainsi, il n’est pas obligatoire d’ouvrir un canal direct avec tout le monde.
Ces transactions multicanales ont une particularité. Il faut comprendre que les fonds ne passent pas d’un canal à l’autre. Avec une image, il est plus facile de comprendre :
Imaginons qu’Alain ne possède pas de canal ouvert avec la boulangerie, mais avec son amie Dakota. Avec cette disposition, Alain doit traverser le nœud de Dakota pour envoyer les fonds à la Boulangerie. Voilà ce qui va se passer :
- Alain envoie 20 000 satoshis à Dakota. Ces 20 000 viennent s’ajouter aux satoshis que Dakota possède sur le canal entre elle et Alain (soit 200 000 + 20 000 = 220 000). Attention, les fonds qu’elles possèdent sur le canal entre elle et la boulangerie ne changent pas pour le moment.
- Dakota envoie 20 000 satoshis à la boulangerie. Dakota est donc débitée de cette somme sur le canal Dakota-Boulangerie
Résultat :
Dakota → 270 000 – 20 000 = 250 000
Boulangerie → 350 000 + 20 000 = 370 000
Finalement, quel intérêt pour un nœud de servir d’intermédiaire alors que l’on va faire transvaser sa liquidité. Chaque fois qu’une transaction va passer par un nœud, une taxe va s’appliquer pour récompenser le nœud intermédiaire. Il existe 2 taxes paramétrables :
- Les frais de base → peu importe le montant de la transaction, le nœud prend x Satoshi (1 satoshi par défaut)
- Les frais variables → % du montant par million (par défaut 1 % pour chaque million de satoshis)
Vous aurez peut-être remarqué un point bloquant avec ce système de fonds qui ne passent pas d’un canal à l’autre. Les transactions de gros montants peuvent poser des problèmes, car il faut trouver des canaux avec une capacité équivalente. De plus, la taxe est proportionnelle au montant puisque c’est un pourcentage de celui-ci.
L’inconvénient de ce système est que l’on retrouve des nœuds qui centralisent énormément de canaux et qui sont donc un point névralgique du réseau. De plus, si un nœud est déconnecté, cela peut couper tout contact entre deux parties.
Pas besoin de faire confiance
Mais, comment faire confiance aux nœuds intermédiaires pour qu’ils transmettent bien le montant souhaité ? Dakota pourrait choisir de conserver la somme. Lightning Network résout ce problème grâce au Hashed Time Locked Contract (HTLC Hashed Timelock Contract (HTLC) – Builder’s Guide). Nous ne détaillerons pas le concept dans ce cours. Pour faire simple, cela permet de bloquer le montant de la transaction tant que le destinataire final n’a pas été atteint. C’est une sorte de promesse que l’on va transmettre de nœud en nœud qui dit que si le destinataire final reçoit bien la transaction alors les fonds se débloquent. Par conséquent, si les nœuds ne jouent pas le jeu, c’est inutile pour eux.
Routage
Comment est déterminée la route à prendre ? Il faut savoir que la seule information connue par le nœud expéditeur est la capacité de chaque canal. Il ignore combien de liquidités il y a de chaque côté du canal. Pour déterminer la route, il va se fonder sur des probabilités. C’est-à-dire emprunter les canaux avec des capacités bien supérieures au montant que l’on souhaite envoyer. Par ailleurs, il va également vérifier les taxes de chaque nœud pour tenter d’emprunter le chemin le moins coûteux. Il va lister x parcours possibles, en les priorisant en fonction des probabilités et des taxes. Ensuite, chaque parcours va être essayé. Si un canal n’a pas suffisamment de fond, alors, il retournera un message en ce sens et le prochain parcours sera tenté. Si aucun parcours n’est valable, alors la transaction échoue.
Particularité du réseau LN, c’est au nœud expéditeur de tracer l’entièreté de l’itinéraire. En contrepartie, cela permet de garantir la vie privée de l’expéditeur et du destinataire. Ainsi, les nœuds intermédiaires savent seulement le prochain nœud à qui ils doivent envoyer le montant de la transaction (routage en oignon).
