Le brouillage des canaux est-il une menace pour le réseau Lightning de Bitcoin ?

(Remerciements particuliers à Antoine Riard et Gleb Naumenko, dont recherches récentes est la base de cet article.)

Le brouillage des canaux est l'un des problèmes en suspens du Lightning Network en termes de choses qui pourraient perturber le succès des paiements acheminés à travers celui-ci. C'est un problème largement connu parmi les développeurs qui a été compris bien avant que le réseau lui-même ne soit mis en ligne sur le réseau principal et ne commence à traiter même un seul satoshi.

Jusqu'à présent, le problème n'a pas vraiment eu d'effets négatifs sur le réseau, mais compte tenu de ce fait, il est important de garder à l'esprit que le réseau est encore, dans le grand schéma des choses, relativement petit. Les processeurs marchands ont commencé à le prendre en charge, tout comme quelques échanges et de nombreux services et entreprises natifs Lightning/Bitcoin, mais en réalité, ce n'est pas beaucoup. Le réseau est encore une petite chose principalement utilisée par les Bitcoiners, et ce n'est pas du tout une très grande partie du monde.

De plus, le nombre de Bitcoiners qui dépensent et utilisent régulièrement leur bitcoin dans les paramètres de commerce est un sous-ensemble encore plus petit de ce groupe déjà restreint. Ce n'est pas parce que les attaques possibles ne se produisent pas actuellement que cela signifie qu'elles continueront à ne pas se produire lorsque le réseau se développera à plus grande échelle. Plus il grandit, plus il deviendra compétitif et conflictuel.

Qu'est-ce que le Brouillage de Canal ?

Le concept de base du brouillage de canal consiste à acheminer les paiements via un canal Lightning que vous souhaitez brouiller de vous-même, puis de ne pas les finaliser en libérant la préimage du hachage de paiement dans le contrats de verrouillage de temps hachés (HTLC). La ou les victimes ne pourront pas supprimer les HTLC de leur chaîne avant l'expiration du délai de remboursement, car elles n'auraient aucun moyen de faire valoir leur droit à l'argent qui leur est dû si la préimage était publiée après l'avoir supprimée. Si vous bloquez complètement un canal en procédant ainsi, ce canal sera incapable d'acheminer des paiements jusqu'à l'expiration du délai sur tous les paiements malveillants.

Il existe deux stratégies différentes qui peuvent être employées ici afin d'effectuer l'attaque. Vous pouvez soit essayer de brouiller la quantité routable disponible dans un canal, soit essayer de brouiller tous les slots HTLC individuels dans un canal. Un canal Lightning ne peut avoir que 483 HTLC en attente dans chaque direction qu'il peut acheminer, car il existe une limite de taille maximale à la taille d'une transaction Bitcoin. Si vous ajoutez plus de 483 HTLC par direction dans le canal, la transaction pour fermer le canal si nécessaire serait trop volumineuse et non valide pour être soumise au réseau. Cela rendrait tout ce qui se trouve dans le canal inapplicable sur la chaîne.

Ainsi, un attaquant peut soit essayer de verrouiller toute la liquidité d'un canal, soit essayer de verrouiller tous les créneaux HTLC d'un canal. L'une ou l'autre stratégie rendrait le canal inutilisable, mais le brouillage des créneaux sera généralement moins cher que le brouillage de la quantité. L'attaquant a besoin d'avoir des pièces sur le réseau pour effectuer cette attaque, donc acheminer la valeur minimale autorisée pour un HTCL d'une capacité de 483 sera plus rentable que d'essayer de verrouiller toutes les liquidités disponibles dans le canal.

Pourquoi quelqu'un voudrait-il brouiller un canal d'éclairage ?

Il existe de nombreuses raisons pour effectuer cette attaque. Premièrement, une entité malveillante qui veut attaquer Bitcoin lui-même pourrait brouiller tous les canaux clés au «cœur» du réseau afin de rendre la majeure partie du réseau inutilisable pour le routage des paiements, à l'exception des nœuds très étroitement connectés les uns aux autres. . Cela nécessiterait beaucoup plus de pièces pour fonctionner à cette échelle, mais ce n'est pas quelque chose qui devrait être écarté comme une possibilité à mesure que Bitcoin grandit et devient une alternative aux systèmes monétaires et de paiement sanctionnés par le gouvernement.

Deuxièmement, un nœud de routage, ou un commerçant, pourrait tenter d'attaquer un concurrent afin de lui faire payer des frais plutôt que la concurrence. Un commerçant vendant des produits similaires pourrait bloquer les canaux d'un concurrent pour empêcher les clients d'y faire des achats, dans l'espoir de les inciter à faire leurs achats dans leur magasin à la place. Un nœud de routage qui a une connectivité de canal similaire à celle d'un autre nœud pourrait bloquer les canaux du nœud de routage concurrent afin de les rendre inutilisables pour le routage des paiements. Au fil du temps, cela détruirait la réputation de ce nœud en termes de fiabilité de routage et, en raison d'une connectivité similaire, il serait de plus en plus probable que les portefeuilles des utilisateurs choisissent le nœud de l'attaquant afin d'acheminer les paiements sur le réseau.

Ces attaques peuvent être encore plus efficaces en termes de capital pour l'attaquant si elles transitent de manière circulaire par un même canal plusieurs fois. S'ils sont suffisamment proches de la victime sur le réseau, ils peuvent construire un itinéraire de paiement qui fait une boucle et continue de passer par le canal de la victime. Il y a des limites à la durée d'un itinéraire de paiement, donc cela ne peut pas être fait à l'infini, mais faire un itinéraire de paiement en boucle comme celui-ci peut réduire considérablement la quantité de pièces dont l'attaquant a besoin pour bloquer complètement le ou les canaux d'une victime.

Atténuation des attaques de brouillage de canal

Certaines atténuations partielles de base pourraient être appliquées afin d'augmenter le coût pour les attaquants et d'atténuer les dommages pour les victimes. Le premier serait un processus en plusieurs étapes pour la gestion des HTLC.

Actuellement, chaque HTLC ajoute individuellement une nouvelle sortie dans la transaction d'engagement pour l'état de canal actuel. Un processus en deux étapes pourrait créer une seule sortie supplémentaire dans la transaction d'engagement, puis avoir une deuxième transaction après celle à laquelle le HTLC réel a été ajouté. Cela permettrait un maximum de 483 multipliés par 483 slots HTLC par canal (ou 233,289 XNUMX slots). Cependant, cela ne résout rien en soi et nécessiterait d'étendre les délais, car vous ajoutez une transaction supplémentaire pour appliquer les choses en chaîne, et pourrait en fait aider l'attaquant plus que la victime s'il utilisait cette nouvelle structure de transaction et le la victime ne l'a pas fait. Cependant, cela aidera en combinaison avec une autre technique expliquée momentanément.

La seconde serait une stratégie réactive, où un nœud qui a été victime d'un brouillage peut simplement ouvrir un nouveau canal vers le même pair que celui qui est bloqué. Cependant, cela nécessiterait d'avoir un capital supplémentaire pour le faire, ne résout pas le coût d'opportunité d'avoir l'autre canal bloqué et de perdre des revenus de redevance, et le nouveau canal pourrait également être bloqué par la suite si l'attaquant dispose du capital disponible pour le faire. .

La troisième technique consisterait à compartimenter les slots HTLC. Il existe actuellement 483 créneaux, et il s'agit d'une limite de créneau unique appliquée universellement à tous les paiements, quelle que soit la valeur du paiement. Les nœuds pourraient créer des compartiments séparés de limites de créneaux plus petits et les appliquer à des paiements de différentes valeurs, c'est-à-dire que les paiements de 100,000 150 sats ou moins ne pourraient avoir accès qu'à XNUMX créneaux. Ainsi, le routage des paiements de plus petite valeur ne peut pas consommer tous les créneaux HTLC disponibles.

Les paiements de 100,000 1 sats à 300 million de sats pourraient avoir accès à 1 slots, et 10 million de sats à 483 millions de sats pourraient avoir accès aux 483 slots complets. Cela augmenterait considérablement le coût en capital d'un attaquant pour bloquer les machines à sous, car il ne serait plus en mesure de consommer les 546 machines à sous avec le paiement de la plus petite valeur possible. De plus, étant donné que les sorties HTLC inférieures au seuil de poussière (actuellement, 0 sats) ne peuvent même pas être diffusées et appliquées sur la chaîne, tout ce qui est en dessous de cette limite pourrait être traité comme un « XNUMX seau » car aucune sortie HTLC n'est créée de toute façon. Les nœuds pourraient simplement imposer des limites à ces transactions en fonction des ressources CPU utilisées ou d'autres mesures pour les empêcher de devenir des risques de déni de service, en fonction de ce qu'ils peuvent se permettre de perdre s'ils ne sont pas réglés honnêtement.

Le regroupement des créneaux en combinaison avec la gestion HTLC en deux étapes peut être utilisé pour optimiser l'application des limites HTLC, c'est-à-dire que les paiements de valeur plus élevée peuvent utiliser la structure en deux étapes pour créer plus de créneaux pour eux par canal, car la valeur de paiement plus élevée augmente le coût de les bloquant pour un attaquant, ce qui rend moins probable l'abus d'une limite d'emplacement plus élevée pour effectuer un brouillage des attaquants.

Dans leurs recherches citées ci-dessus, Riard et Naumenko ont montré qu'avec la combinaison optimale de fentes de godet et d'extension de fente en deux étapes, la cause du brouillage des fentes peut être rendue aussi coûteuse que le brouillage de la quantité. Cela ne résoudrait pas complètement le problème, mais cela augmenterait le coût minimum d'exécution de l'attaque si elle était largement mise en œuvre par les nœuds du réseau.

Les deux solutions complètes qu'ils ont envisagées sont des frais initiaux / de temps de retenue pour bloquer la liquidité et un système de réputation utilisant des jetons chaumiens aveuglés. Le TLDR du système de frais est qu'une caution pour des frais initiaux serait payée pour le routage d'un HTLC qui devrait prendre beaucoup de temps à régler, et plus il reste longtemps non réglé, il libérerait des frais pour chaque nœud de routage par tranche de temps qui s'est écoulée sans règlement. Le problème est que l'application de cette règle pourrait entraîner la nécessité de fermer les canaux si les frais ne sont pas envoyés au moment requis, et cela entraînera des cas d'utilisation légitimes qui nécessitent de longs temps de blocage pour payer les mêmes frais plus élevés qu'un attaquant tentant de brouiller les canaux.

Le schéma de réputation impliquerait un «lien de participation» utilisant des preuves à connaissance nulle pour prouver le contrôle de Bitcoin en tant que défense Sybil, puis utilisant le lien lié à votre réputation pour acquérir des jetons chaumiens aveuglés à partir de nœuds de routage qui seraient échangés et réémis sur HTLC. s'installer avec succès d'une manière préservant la vie privée. Les nœuds émettraient des jetons une fois par identité, et si un HTLC n'était pas réglé ou remboursé en temps opportun, les nœuds pourraient refuser de réémettre le jeton, empêchant ainsi un utilisateur de passer par son nœud à moins qu'il ne dépense du temps et de l'argent pour créer un nouveau obligation de participation avec différentes pièces à émettre dans un nouveau jeton.

Pour ceux qui souhaitent en savoir plus sur ces deux solutions, plus d'informations peuvent être trouvées dans les sections cinq ainsi que six dans les recherches de Riard et Naumenko.

Il convient également de noter que si les nœuds de routage devaient adopter des systèmes d'entiercement tiers ou des lignes de crédit basées sur la confiance, comme je l'ai écrit à propos de ici, tous ces problèmes liés au brouillage des canaux cesseraient de les affecter. Ce serait un énorme changement dans le modèle de confiance pour les nœuds de routage, mais cela n'aurait aucun effet sur les personnes utilisant de vrais canaux Lightning pour envoyer et recevoir des satellites, la sécurité de leurs fonds ou leur capacité à appliquer cela sur la chaîne.

Les gens pourraient ne pas vouloir l'entendre, mais en fin de compte, si les solutions ci-dessus pour atténuer le brouillage des canaux pour les canaux réels ne suffisent pas, ces systèmes tiers sont toujours une option potentielle.

Ceci est un article invité de Shinobi. Les opinions exprimées sont entièrement les leurs et ne reflètent pas nécessairement celles de BTC Inc ou de Bitcoin Magazine.