HTLC virtuels. Le réseau/protocole Lightning a été… | par Shinobi [SHI256] | Bloc mémoire de résumé

Le réseau/protocole Lightning a constitué une source gravitationnelle massive d’attention en matière de développement au cours des 2 à 3 dernières années. Je suppose qu’il y a autant, sinon plus, de part d’esprit des développeurs se souciant des tenants et des aboutissants des problèmes du protocole Lightning qu’ils se préoccupent du protocole Bitcoin de base. La majeure partie du côté « réseau » de Lightning tourne autour de l’utilisation de contrats de verrouillage temporel de hachage (HTLC) pour imposer l’atomicité des résultats dans les sorties sur de nombreux canaux Lightning individuels.

Les HTLC se sont révélés être un énorme vecteur potentiel de DoS en général pour les nœuds participant au réseau pour acheminer les paiements. Chaque HTLC individuel nécessite sa propre sortie, avec une limite maximale de 483 HTLC pouvant exister dans un canal. En fin de compte, le problème est que les transactions deviennent plus coûteuses à mesure qu’il y a d’entrées ou de sorties, et que les transactions elles-mêmes sont limitées par une taille maximale. Cela permet de contrarier les chaînes en saturant leur limite HTLC, et en refusant de coopérer et en forçant les choses sur la chaîne, cela peut entraîner des coûts énormes pour l’opérateur de chaîne en difficulté. Et dans certains cas, cela peut même permettre le vol d’un certain % des fonds bloqués dans les HTLC.

Cela nécessite de limiter efficacement le nombre de HTLC en vol bien en dessous de la limite maximale pour vous protéger, en tant qu’opérateur de chaîne, contre ces types d’attaques pénibles et d’attaques de vol pur et simple. Ces types de limitations s’ajoutent intrinsèquement à une rareté supplémentaire du débit du Lightning Network, ce qui a des conséquences négatives à long terme sur la viabilité des micropaiements nativement sur le Lightning Network.

J’aimerais proposer une intuition approximative pour une solution à ce problème. Il ne s’agit en aucun cas d’une idée pleinement étoffée, et il y a certainement des problèmes et des problèmes en suspens que je ne sais pas vraiment comment résoudre de manière hermétique, mais je souhaite diffuser l’idée générale et délimiter ces problèmes. voyez ce que les autres peuvent penser des solutions possibles à ces problèmes et au concept général.

Virtualisez de nombreux HTLC dans un seul UTXO à l’aide de Smart Contracts Unchained dans une structure similaire à un DLC. En principe, il n’y a aucune raison pour laquelle vous ne pouvez pas émuler une quantité infinie de HTLC virtuels au-dessus d’une seule sortie Multi-HTLC avec la coopération d’un ou plusieurs séquestres. Pensez à ce qu’est un HTLC, c’est simplement une sortie avec un script qui peut être résolu par deux transactions différentes : une transaction de réussite et une transaction de remboursement.

Chaque HTLC nécessite sa propre sortie, son propre script avec différentes pré-images et sa propre paire de transactions de règlement potentielles (succès et remboursement). L’ensemble du cas d’utilisation d’un DLC est de pouvoir englober beaucoup plus de résultats possibles qu’un binaire réussite/échec à l’aide d’oracle(s). Construisons donc ce Multi-HTLC de la même manière qu’un DLC, en utilisant des agents de dépôt au lieu d’oracles :

Et si nous n’avions qu’une seule sortie Multi-HTLC de type DLC avec ces deux HTLC émulés ? Les états de règlement potentiels de la sortie Multi-HTLC sont tous les résultats possibles du règlement des HTLC émulés en réseau. Les satoshis « x » circulent dans une direction dans le canal pour tous les HTLC virtuels qui ont réussi, les satoshis « y » circulent dans la direction opposée pour tous les HTLC virtuels qui échouent. Tout cela peut être hébergé dans une seule sortie, les haslocks/préimages étant utilisés de manière interactive avec un ou plusieurs séquestres pour prouver sur quelle transaction de règlement ils doivent signer. Idéalement, les participants au canal signeraient simplement de manière coopérative les transactions de règlement appropriées pour le Multi-HTLC, et en cas de non-coopération (qu’elle soit innocente ou malveillante), un seul membre du canal peut accéder au dépôt et fournir les pré-images qu’il a obtenues. réglez honnêtement le Multi-HTLC.

C’est maintenant là que les problèmes surviennent. À savoir les timelocks et les pré-images individuelles. Premièrement, les préimages : cela pose un problème car le but même d’une préimage révélée explicitement lors du règlement en chaîne est de permettre à toute personne impliquée dans ce paiement acheminé qui traite avec des pairs non coopératifs de garantir qu’elle peut réclamer cet argent lors du règlement en chaîne. le HTLC. Sans restituer beaucoup d’efficacité gagnée par un « HTLC virtuel » comme celui-ci en révélant explicitement des préimages HTLC individuelles sur la chaîne lors du règlement multi-HTLC, l’adoption d’un contrat comme celui-ci remettrait en question cette hypothèse qui fait partie du modèle de sécurité HTLC. . À mon avis, il n’y a aucun moyen d’éviter de restituer une partie du gain d’efficacité ou d’adapter le modèle de sécurité aux mécanismes hors chaîne pour apprendre des pré-images individuelles dans différents scénarios de défaillance.

Les verrous temporels : un HTLC acheminé est structuré pour avoir spécifiquement des verrous temporels décrémentants qui s’éloignent d’une destination de paiement pour permettre aux sauts précédents d’apprendre une pré-image si elle a été révélée avant que leur délai d’expiration HTLC ne permette au transitaire de récupérer ses fonds. Le regroupement de HTLC virtuels au-dessus d’un Multi-HTLC nécessite que chaque HTLC virtuel soit verrouillé sous une seule période de verrouillage définie par le Multi-HTLC sur lequel il est hébergé. Je ne sais vraiment pas vraiment comment faire fonctionner les hypothèses générales de timelock pour les HTLC dans ce contexte. J’espère que quelque chose est possible qui permettrait aux HTLC virtuels d’interagir atomiquement avec les natifs, mais jusqu’à présent, je suis perdu ici. Sans une solution ici, le routage serait limité et possible uniquement entre les HTLC virtuels à peu près synchronisés avec leurs délais d’attente Multi-HTLC.

Donc, il y a l’idée générale des points faibles et tout. J’espère que certains des problèmes ici sont des choses pour lesquelles des personnes plus intelligentes que moi peuvent trouver des solutions.