Payment Channel

Imaginez deux parties qui modifient leurs droits sur une somme bloquée en commun. Chaque paiement ne nécessite pas sa propre transaction Bitcoin dans un bloc : elles échangent des signatures pour un nouvel état. Ce n’est pas un simple tableau auquel il faudrait faire confiance. Elles disposent de transactions permettant d’imposer le règlement selon les conditions convenues. [1] [2]

La transaction de financement place les bitcoins dans le canal. Sa sortie est un montant assorti de règles indiquant qui peut le dépenser ; une confirmation signifie que la transaction a été incluse dans un bloc. Dans un canal Lightning classique, cette sortie exige les signatures des deux parties : 2-of-2. Avant de diffuser la transaction de financement, les participants doivent disposer d’une voie valide de fermeture unilatérale. Ils attendent normalement des confirmations. Sous certaines conditions, zero-conf permet d’utiliser le canal sans attendre de confirmation. Le destinataire dépend alors davantage de la partie qui le finance : la transaction reste non confirmée et pourrait être remplacée par une transaction concurrente dépensant les mêmes fonds. [2] [3]

Une transaction commitment est signée à l’avance pour régler la répartition convenue. Ici, un nœud est le logiciel qui gère le canal et ses mises à jour. Chaque partie possède sa propre version de la transaction commitment. Lors d’une mise à jour, les nœuds coordonnent les signatures et les secrets de révocation via commitment_signed et revoke_and_ack. Un nouvel accord ne rend pas une ancienne transaction signée invalide au regard du consensus Bitcoin. La protection contre la publication d’un état révoqué doit donc figurer dans les conditions de dépense des sorties. [2] [3]

Dans un canal classique avec révocation, la partie qui publie son commitment doit attendre to_self_delay avant de dépenser ses propres fonds. Le délai se compte en blocs à partir de la confirmation de la transaction commitment. Si elle a publié un état révoqué, l’autre partie peut employer la clé de révocation pour dépenser les sorties concernées à titre correctif. Elle doit agir à temps et obtenir une confirmation. Un Watchtower est un service qui surveille la chaîne et peut utiliser des données préparées à l’avance pour réagir à la publication d’un état révoqué. Ce service ne garantit toutefois pas le succès et ne remplace pas une sauvegarde. [3] [4]

Sat est l’abréviation de satoshi, la plus petite unité de bitcoin sur la chaîne. La capacité est le montant total du canal, pas le solde de chaque participant. Prenons un canal de 100000 sat : Alice possède 70000 sat et Bob 30000 sat. Si Alice verse 10000 sat à Bob, la répartition devient 60000 sat et 40000 sat. Pour simplifier, nous ignorons ici les frais et les réserves. La capacité reste identique, mais Alice peut envoyer moins et recevoir davantage. Les réserves et les paiements en cours limitent aussi les montants réellement disponibles. [6]

Lightning cherche une route à travers plusieurs canaux reliés. Un HTLC est un paiement conditionnel : réclamer les fonds exige de révéler un secret, la preimage, dont le hash, ou empreinte numérique, correspond à la valeur connue à l’avance. Les conditions temporelles permettent aussi un règlement si le paiement n’aboutit pas. Les intermédiaires ont besoin de liquidité, c’est-à-dire de fonds disponibles à envoyer dans le sens requis, et peuvent facturer des frais. Un canal direct avec chaque commerçant n’est donc pas nécessaire, mais une connexion ne garantit pas une route utilisable pour n’importe quel montant. [2] [4]

Lors d’une fermeture d’un commun accord, ou cooperative close, les participants conviennent de la transaction de fermeture, du partage des fonds et des frais. Tous deux signent puis diffusent la transaction sur la blockchain. C’est généralement plus simple qu’un règlement unilatéral, mais pas automatiquement gratuit ni immédiat. Il faut toujours une confirmation et des frais adaptés à l’état du réseau. [2] [4]

Une fermeture unilatérale, ou force close, permet de publier son commitment actuel sans obtenir un nouvel accord du partenaire. Les fonds ne sont pas nécessairement dépensables immédiatement : les délais et l’éventuel règlement des HTLC s’appliquent encore. D’autres transactions et frais peuvent être nécessaires. Une sortie de secours existe, mais sa durée et son coût dépendent de l’état du canal et de la blockchain. [3] [4]

Une Seed Phrase est un ensemble de mots de sauvegarde permettant au portefeuille de restaurer ses clés. Elle ne restitue pas à elle seule le dernier état d’un canal ouvert : suivez donc la procédure de votre portefeuille. Par exemple, LND, un logiciel pour faire fonctionner un nœud Lightning, associe ces mots à un Static Channel Backup (SCB). Cette sauvegarde statique conserve les informations nécessaires pour contacter les partenaires et leur demander de fermer les canaux ; elle ne restaure pas des canaux permettant de continuer à payer. La récupération dépend aussi de la réponse des partenaires. Le fichier channel.db contient quant à lui la base de données des canaux, et une ancienne copie peut renfermer un état dangereusement périmé. Ne saisissez jamais vos vrais mots de sauvegarde sur un site tiers pour « réparer » un canal. [5]

Vérifiez qui détient les clés, qui surveille les canaux et comment récupérer l’accès après la perte d’un appareil. Dépositaire signifie ici que le prestataire détient les clés. Un solde Lightning chez un service dépositaire ne représente pas nécessairement votre propre canal. En autogarde, les sauvegardes, la disponibilité et les réactions aux incidents vous incombent. Les canaux économisent des inscriptions dans la blockchain ; ils n’éliminent ni toutes les tâches d’exploitation ni les coûts de règlement. [4] [5]