Pourquoi les paiements Lightning peuvent-ils être plus rapides ?

Pourquoi un paiement Bitcoin peut-il avoir besoin d'un autre chemin ?

La couche de base de Bitcoin donne aux participants un seul historique partagé, mais cet historique n'est pas conçu pour enregistrer immédiatement chaque petit paiement possible. Quand un paiement doit être fréquent ou réactif, inscrire chaque mise à jour directement dans un bloc peut réintroduire le délai et la compétition pour l'espace de bloc évoqués dans la leçon précédente.

Lightning est une réponse, au niveau de la couche de paiement, à cette contrainte. Il permet aux participants d'effectuer de nombreuses mises à jour de solde dans un canal, puis d'utiliser la couche de base de Bitcoin quand ils ont besoin d'établir ou de régler ce canal.

Qu'est-ce qu'un canal de paiement Lightning ?

Un canal de paiement commence quand des participants engagent du BTC dans un arrangement que Bitcoin peut reconnaître. À l'intérieur du canal, ils peuvent se mettre d'accord sur de nouveaux états de solde à mesure qu'ils se paient l'un l'autre, sans diffuser chaque mise à jour comme une transaction Bitcoin séparée. Le canal n'est pas déconnecté de Bitcoin : son financement et son chemin de fermeture ou d'exécution forcée restent liés à des transactions Bitcoin.

Comment un paiement peut-il atteindre quelqu'un sans canal direct ?

Lightning peut faire suivre un paiement à travers une séquence de canaux. Chaque nœud relais transmet un paiement conditionnel au saut suivant, plutôt que de prendre la garde d'un actif séparé. C'est ce qui permet à Lightning de connecter des personnes qui n'ont pas ouvert de canal directement entre elles.

Cette route n'est pas garantie simplement parce qu'un schéma montre des nœuds connectés. Un paiement a besoin d'un montant utilisable dans la direction requise à chaque saut, tout en respectant les limites de frais, de délai et de HTLC en vigueur à chaque saut. Dans ce contexte, la liquidité désigne le fait que le paiement demandé puisse effectivement circuler le long de cette route maintenant — pas simplement la quantité de valeur qui existe quelque part dans l'ensemble du réseau.

Quels compromis subsistent après avoir déplacé les paiements dans des canaux ?

Lightning peut réduire le besoin de se disputer un bloc Bitcoin pour chaque paiement, mais il ne fait pas disparaître les contraintes. Des fonds doivent être engagés dans des canaux, la liquidité disponible peut différer selon la direction, et une route peut échouer si un saut ne peut pas relayer le montant. Les participants d'un canal conservent aussi une relation avec Bitcoin pour le financement et le règlement final de ces soldes.

Conclusion

Lightning est une réponse ciblée à une contrainte précise : la couche de base de Bitcoin n'a pas été conçue pour enregistrer immédiatement chaque petit paiement fréquent, et inscrire chacun dans un bloc réintroduit l'attente et la compétition pour l'espace de bloc. Les canaux permettent aux participants d'engager du BTC une fois, puis de se mettre d'accord entre eux sur de nouveaux états de solde à mesure qu'ils se paient, sans diffuser chaque mise à jour comme une transaction Bitcoin séparée.

La vitesse vient du déplacement des mises à jour hors de la couche de base, pas d'un moyen d'y échapper. Le financement d'un canal et son chemin de fermeture ou d'exécution forcée restent des transactions Bitcoin, ce qui rend l'arrangement exécutoire. C'est aussi pourquoi Lightning n'introduit pas d'actif séparé — les soldes mis à jour sont du BTC, et ils se règlent sur Bitcoin quand le canal se ferme.

La contrainte qui remplace l'espace de bloc, c'est la liquidité, et elle est directionnelle. Un paiement acheminé a besoin d'une capacité utilisable dans la direction requise à chaque saut, ainsi que de limites compatibles en matière de frais, de délai et de HTLC, si bien qu'une route peut échouer même quand un schéma montre les nœuds connectés et même quand une grande quantité de valeur existe quelque part sur le réseau. Pour un utilisateur, les attentes pratiques sont que des fonds doivent être engagés dans des canaux avant de pouvoir être dépensés de cette façon, qu'un paiement peut échouer pour des raisons indépendantes de votre propre solde, et que la relation avec le règlement Bitcoin ne disparaît jamais complètement.

Lightning est un exemple de couche construite au-dessus de Bitcoin pour un objectif précis : les paiements fréquents. Sa vitesse vient du déplacement de nombreuses mises à jour dans des canaux, pas de la suppression des règles de règlement de Bitcoin. La prochaine leçon suit un chemin différent sur Ethereum, où les rollups déplacent une grande partie de l'exécution hors de la couche de base et soumettent des informations groupées en retour.

Questions fréquentes