L’une des limites fondamentales du protocole Lightning réside dans la manière dont le routage des paiements est géré et réalisé. Il s’agit d’un routage entièrement source, ce qui signifie que l’expéditeur d’un paiement est celui qui construit l’intégralité du parcours depuis lui-même jusqu’au destinataire afin de faciliter le paiement. Cela pose un problème en ce qui concerne l’évolution de l’équilibre des canaux au fil du temps, car ils acheminent les paiements entre de nombreux utilisateurs différents à travers le réseau. Une fois qu’un expéditeur « se verrouille » et décide d’un itinéraire spécifique, cet itinéraire ne peut pas être modifié jusqu’à un échec. Le message revient à l’expéditeur, lui permettant de construire un itinéraire entièrement nouveau contournant le point où la tentative initiale a échoué.
Cela nécessite soit de gérer une UX lourde et ennuyeuse, soit d’utiliser une enquête de paiement, créant intentionnellement des paiements que vous échouerez volontairement juste pour voir si l’itinéraire que vous souhaitez utiliser fonctionnera avant de réessayer avec le paiement réel. La première n’est qu’une mauvaise expérience utilisateur et ce n’est pas ce que vous souhaitez lorsque vous essayez de créer quelque chose qui soit une solution de paiement viable pour les personnes à grande échelle, et la seconde impose une charge excessive au réseau dans son ensemble, car les nœuds de routage doivent gérer le réseau. complications de trafic et de liquidité liées à des paiements constants effectués sans intention de finaliser, simplement pour tester la viabilité d’une route.
La cause ultime de ces problèmes est l’incapacité d’un itinéraire à changer en cours de paiement sans l’implication de l’expéditeur. Étant donné que l’ensemble du parcours de paiement est crypté par oignon, cela n’est pas vraiment possible. Chaque saut n’est conscient que du saut qui le précède et du saut qui le suit, ils n’ont aucune connaissance de la destination finale pour leur permettre de construire un itinéraire alternatif entre eux et le récepteur.
Bien que cela constitue un énorme obstacle à l’abandon du routage basé sur la source, cela ne l’empêche pas entièrement. En tant que nœud intermédiaire, même si vous ne pouvez pas reconstruire complètement un nouvel itinéraire entre vous et la destination, vous pouvez rediriger le paiement de vous-même vers le prochain saut défini dans le chemin choisi par l’expéditeur. Ainsi, si Bob reçoit un paiement qu’il est censé acheminer vers Carol et que le canal par lequel il est censé l’acheminer n’a pas la capacité nécessaire pour le transmettre, il peut envoyer ce qu’il peut via ce canal et acheminer le reste du paiement. le montant du paiement par d’autres voies qu’il peut trouver de lui-même à Carol.
Le mois dernier, Gijs van Dam a écrit un plugin de preuve de concept pour CLN (disponible ici) qui fait exactement cela, en s’appuyant sur des paiements multi-chemins qui permettent à un paiement de se diviser et d’emprunter plusieurs itinéraires vers le destinataire. Si Bob et Carol exécutent tous les deux le plugin, ils peuvent, dans les situations appropriées, se communiquer qu’un paiement transféré via un canal est en fait partiellement redirigé afin que Carol ne l’abandonne pas immédiatement lorsqu’elle voit ce qu’elle est en train de faire. envoyé est inférieur à ce qu’elle est censée transmettre. De cette façon, si des itinéraires alternatifs sont disponibles entre Bob et Carol lorsque l’itinéraire décidé par l’expéditeur n’est pas viable, ils peuvent simplement réacheminer le montant nécessaire et le paiement peut réussir sans échouer complètement, se propager vers l’expéditeur et être réacheminé par eux.
S’il est largement adopté en tant que comportement standardisé sur le réseau, cela pourrait avoir un impact positif énorme sur le taux de réussite des paiements, améliorant considérablement l’UX des utilisateurs de Lightning à la recherche d’un mécanisme de paiement simple et efficace. Il s’agit d’un comportement incroyablement simple et logique qui pourrait améliorer considérablement une lacune bien connue. Mais ce n’est pas tout ce qu’il peut faire.
L’une des principales raisons pour lesquelles Gijs van Dam s’est intéressé à résoudre ce problème n’a en réalité rien à voir avec la simple amélioration du taux de réussite des paiements et de l’UX pour les utilisateurs, mais plutôt à cause d’un manque de confidentialité. L’un des problèmes de confidentialité bien connus auxquels Lightning est vulnérable est le sondage des canaux, c’est le problème qui préoccupait Gijs.
Comme je l’ai mentionné ci-dessus, certains portefeuilles l’utilisent pour garantir la réussite d’un paiement avant de tenter le paiement réel, mais cette technique peut également être utilisée pour vérifier la répartition des fonds des deux côtés d’un canal. Réalisé à plusieurs reprises et avec des montants soigneusement choisis, le succès ou l’échec de chaque tentative d’enquête permet de déduire la manière dont les fonds sont répartis de chaque côté du canal. Poussée encore plus loin et appliquée systématiquement sur de nombreux canaux de manière régulière, cette technique peut même désanonymiser les paiements en surveillant en temps réel l’évolution des soldes entre les canaux.
Lightning est constamment présenté comme un outil de confidentialité à usage transactionnel, mais la réalité est donnée, les techniques telles que l’analyse de la confidentialité par canal peuvent dans de nombreux cas être au mieux ténues sans qu’un utilisateur soit sophistiqué dans la façon dont il interagit avec le réseau. L’un des effets secondaires intéressants du fractionnement et du transfert de paiements est qu’ils sapent les attaques par sondage. La raison pour laquelle une attaque par sondage fonctionne est que vous pouvez continuer à sonder différents montants jusqu’à ce qu’un paiement échoue. Si cela est fait correctement, cela vous donne une très petite plage entre la dernière tentative de paiement réussie et celle qui a échoué, c’est-à-dire la répartition du solde du canal.
Dans un monde où les nœuds Lightning peuvent réacheminer à la volée les paiements de pièces qui autrement échoueraient pour réussir, cela brise complètement l’hypothèse inhérente sur laquelle repose la vérification de l’équilibre des canaux. Que votre tentative de paiement échouera lorsque le canal spécifique par lequel vous avez décidé d’acheminer n’a pas les liquidités nécessaires pour le transférer. Avec le partage et la commutation des paiements, cette hypothèse n’est plus vraie, et plus le nombre de nœuds sur le réseau prend en charge la commutation, plus cette hypothèse est sujette aux erreurs (jusqu’à 62 % selon une simulation utilisant les données réelles du réseau Lightning de Gijs).
Ainsi, non seulement cette proposition est relativement simple, non seulement elle ouvre la voie à l’amélioration du taux de réussite des tentatives de paiement, mais elle contribue également à remédier à l’une des plus grandes lacunes en matière de confidentialité du réseau Lightning. Je pense que, surtout à la suite de la récente vulnérabilité Lightning, cette proposition montre que même si Lightning n’est pas sans son lot de problèmes, ils ne sont pas impossibles à résoudre ou à atténuer. Il sera même très courant que les solutions à un problème aident à résoudre un autre problème.
Rome n’a pas été construite en un jour, et les solutions qui préservent réellement les propriétés fondamentales de Bitcoin de manière évolutive et durable ne le seront pas non plus.
Source https://bitcoinmagazine.com/technical/payment-splitting-and-switching-improving-privacy-and-payment-success-simultaneously
