Canaux de paiement

Curiosité

1. Comment deux parties peuvent-elles effectuer des milliers de paiements instantanés en ne soumettant que deux transactions à la chaîne de blocs Bitcoin ?
2. Quel mécanisme empêche un participant de diffuser une transaction d’engagement plus ancienne qui favorise son solde ?
3. Pourquoi les premiers canaux de paiement, décrits par Jeremy Spilman en 2013, étaient-ils uniquement unidirectionnels ?

Explorer

1. La couche de base de Bitcoin règle les transactions à intervalles d’environ dix minutes, ce qui crée des contraintes de latence et de frais pour les micropaiements à haute fréquence. Les canaux de paiement déplacent hors chaîne la charge de calcul des mises à jour d’état, ce qui permet aux participants d’échanger indéfiniment des états de solde signés sans propagation sur le réseau. La blockchain sert uniquement de couche de règlement et ne vérifie que les événements de financement initial et de clôture finale.
2. Le canal commence par une transaction de financement : une sortie multisig 2-sur-2 qui verrouille des fonds contrôlés à la fois par Alice et par Bob. Si chacun apporte 1 BTC, la capacité du canal est de 2 BTC. Aucune des parties ne peut dépenser unilatéralement ces fonds sans la signature de l’autre. Cette structure lie les participants au sein d’un compte commun qui n’existe que sous la forme d’une créance potentielle sur la chaîne principale.
3. En cours de fonctionnement, Alice et Bob échangent des transactions d’engagement qui représentent de nouvelles répartitions du solde. Chaque mise à jour remplace l’état précédent ; si Alice envoie 0,1 BTC à Bob, ils signent une nouvelle transaction qui transfère des fonds de la sortie d’Alice vers celle de Bob. Ces transactions signées mais non diffusées sont des transactions Bitcoin valides, ce qui garantit que tout état final peut être imposé on-chain sans dépendre de la confiance envers la contrepartie.
4. Il faut également empêcher chaque partie de diffuser un état obsolète qui lui attribuait davantage. Lightning y parvient grâce à des secrets de révocation et à des verrous temporels (timelocks), abordés dans une leçon ultérieure ; en bref, publier un état révoqué permet à l’autre partie de s’emparer de la totalité du solde du canal, ce qui fait de la tricherie un pari perdant.
5. La clôture s’effectue soit de manière coopérative, soit de manière unilatérale. Lors d’une clôture coopérative, les deux parties signent une transaction de règlement qui verse immédiatement leurs soldes finaux, sans timelock. Si l’une des parties se déconnecte ou agit de manière malveillante, l’autre peut procéder à une fermeture forcée en diffusant la dernière transaction d’engagement. Dans ce cas unilatéral, la partie qui force la fermeture doit attendre l’expiration d’un verrou temporel relatif avant de pouvoir dépenser sa propre part, ce qui laisse le temps de réclamer une éventuelle pénalité ; la sortie de l’autre partie est disponible presque immédiatement.
6. Parmi les précurseurs figurent les canaux unidirectionnels de Jeremy Spilman (2013), dans lesquels les paiements ne pouvaient circuler que du payeur vers le bénéficiaire, ainsi que les canaux duplex de Christian Decker et Roger Wattenhofer (2015). L’article de Joseph Poon et Thaddeus Dryja sur le Lightning Network (brouillon en 2015, version de 2016) a introduit les engagements révocables, qui permettent à un canal de rester ouvert indéfiniment, ainsi que les HTLC, qui permettent de router les paiements à travers de nombreux canaux. Des implémentations sur le mainnet comme LND, Core Lightning et Eclair gèrent aujourd’hui ces états, et l’adoption a véritablement pris de l’ampleur à partir de 2018.

Faits clés

Exercice neuf, six, trois, un

Vérification des faits

Les dates, les chiffres et les affirmations ont été vérifiés à l’aide des sources publiées listées ci-dessous.

• J. Poon & T. Dryja, 'The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments' (2016)
• A. M. Antonopoulos, O. Osuntokun & R. Pickhardt, Mastering the Lightning Network (2021)
• Lightning Network BOLT specifications (github.com/lightning/bolts)