Ceci est un éditorial d’opinion de Shinobi, un éducateur autodidacte dans l’espace Bitcoin et hôte de podcast Bitcoin orienté technologie.
Ignorer les problèmes du réseau Lightning et de la pile de protocoles semble être une chose très populaire à faire ces jours-ci. Il s’agit actuellement de la deuxième couche la plus largement adoptée et utilisée du réseau Bitcoin, et de la progression la plus rapide en termes de développement ultérieur. Il présente également de nombreuses lacunes qu’il est facile de balayer sous le tapis et de contourner, étant donné qu’il est très petit et à un stade très précoce d’adoption. Mais cela ne fait pas disparaître ces problèmes ou ne change pas la réalité qu’à une échelle beaucoup plus grande et plus loin sur la courbe d’adoption, ces problèmes deviennent des problèmes très réels qui nécessitent des solutions évolutives réelles.
L’un des problèmes au cœur de Lightning est la question de la réception de liquidités. Il n’est pas possible de recevoir des fonds sur le Lightning Network sans avoir d’abord sécurisé la réception de liquidités du nœud de quelqu’un d’autre. Il s’agit d’une limitation fondamentale et inévitable de l’utilisation du Lightning Network de manière non privative. De toute évidence, en utilisant des choses comme Wallet of Satoshi ou le LNDHub par défaut de Bluewallet (qui sont dépositaires), vous pouvez contourner ce problème, mais c’est uniquement parce que quelqu’un d’autre l’a résolu pour vous et que vous ne contrôlez pas réellement vos fonds. Cependant, lorsque vous traitez des choses en toute autonomie, vous devez réellement résoudre le problème.
Lorsque le Lightning Network a été mis en service pour la première fois et a commencé à voir une utilisation réelle à l’époque « #Reckless », ce problème a été résolu de manière très informelle. Il a été essentiellement résolu grâce aux relations sociales; par le biais de demandes adressées à des personnes que vous connaissiez ou à des amis proches ; par le biais d’accords de poignée de main « Hé mon ami, pouvez-vous m’envoyer des liquidités, je viens de créer mon nœud. » Il n’y avait pas de marchés, il n’y avait pas de services à utiliser, c’était littéralement juste des amis qui s’entraidaient. Même aujourd’hui, grâce à des choses comme PLEBNET, un grand pourcentage de l’approvisionnement en liquidités sur le réseau se fait dans ce type d’arrangements sociaux informels.
Le réseau est encore très petit et toujours confiné à ce qui, sur un graphe social, est un petit ensemble d’acteurs qui, même par des degrés indirects de séparation, ne sont pas si éloignés les uns des autres. Je dirais que nous commençons à peine à entrer aujourd’hui dans une phase de croissance où la taille du réseau et le nombre de personnes impliquées commencent à arriver au point où ce type d’arrangement et de dynamique n’est plus pérenne.
La prochaine phase de croissance dans la résolution de ce problème s’est produite peu de temps après la mise en service du réseau. Des services comme LNBIG ont commencé à créer une page où les gens pouvaient demander des liquidités entrantes. Bitrefill a commencé à proposer des canaux avec la réception de liquidités en tant que service (et dans le processus a créé sa spécification « Turbo channel » qui vous permet d’utiliser un canal avant même qu’il ne soit confirmé sur la chaîne). Coincharge, Voltage et de nombreuses autres sociétés proposent également des services similaires. En payant des frais, vous pouvez simplement demander à une entreprise d’ouvrir un canal avec vous pour fournir des liquidités de réception afin de recevoir de l’argent. Cette étape dans l’évolution des choses s’est produite pour résoudre une sorte de problème de mise à l’échelle puisque tous les nouveaux utilisateurs à bord n’avaient pas ces connexions sociales pour obtenir des liquidités entrantes. Même s’ils le faisaient, les gens n’ont qu’un montant limité d’argent qu’ils peuvent allouer aux chaînes pour les personnes qu’ils connaissent. Vous ne pouvez pas non plus vous attendre à ce que les gens restent assis toute la journée, soyez prêts à tout moment à ouvrir des canaux lorsque les gens ont besoin de liquidités. Ainsi, une entreprise a la possibilité d’intervenir et de résoudre le problème moyennant des frais.
Vous avez également la dynamique des fournisseurs de services de foudre (LSP) comme Breez qui interviennent et fournissent eux-mêmes une certaine quantité de liquidités de réception pour leurs utilisateurs. Ceci, cependant, se heurte toujours aux mêmes problèmes généraux que l’approvisionnement auprès de personnes que vous connaissez : Breez n’a qu’une quantité d’argent qu’il peut allouer à ses utilisateurs pour recevoir des fonds. Ils facturent des frais de routage en étant le nœud auquel vous êtes connecté, mais ils finiront par se heurter au problème de devoir gérer un montant limité de fonds sur une base d’utilisateurs croissante. Ce n’est pas durable à perpétuité.
Le type de solution suivant pour ce problème central de Lightning était les places de marché réelles. Il ne s’agit pas d’une entreprise qui vous vend ses propres fonds sous forme de capacité de réception, mais d’un marché où n’importe qui peut venir proposer de vendre des liquidités de réception à quiconque souhaite en acheter. Deux exemples de cette solution sont la maison de vente aux enchères « Lightning Pool » de Lightning Lab et les places de marché Magma d’Amboss. Lightning Pool impose même une durée minimale pendant laquelle les chaînes achetées doivent rester ouvertes sur la chaîne via un verrouillage horaire CLTV. Ce sont deux moyens non dépositaires pour une partie centrale (Lightning Labs et Amboss) de faire correspondre les personnes souhaitant vendre avec celles souhaitant acheter des liquidités entrantes. Le problème est qu’ils dépendent toujours d’un facilitateur centralisé pour que cela fonctionne. Lightning Lab’s et Amboss facturent tous deux des frais pour participer à leurs enchères.
Une dernière catégorie de solutions à ce problème est incarnée par les annonces de liquidité de CLN, un marché décentralisé pour recevoir des liquidités construit au-dessus de canaux à double financement (où les deux côtés du canal fournissent des liquidités sur le financement au lieu d’un seul). Liquidity Ads utilise le protocole de potins du Lightning Network qui annonce les canaux publics disponibles pour acheminer les paiements afin de publier publiquement des publicités que vous êtes prêt à vendre pour recevoir des liquidités. Tout comme Lightning Pool, il applique également une «durée de location» pendant laquelle la chaîne doit rester ouverte avec un timelock CLTV sur la chaîne.
Ainsi, toutes ces différentes options laissent une question en suspens : comment voulons-nous vraiment aborder la résolution de ce problème à long terme et à grande échelle ? C’est littéralement pas possible pour recevoir des fonds sur le Lightning Network sans avoir d’abord à s’approvisionner pour recevoir des liquidités. C’est une limitation essentielle du protocole lui-même. Voulons-nous résoudre ce problème au niveau du protocole lui-même, vu que c’est là que se trouve la limitation actuelle, ou voulons-nous nous appuyer sur des services et des places de marché centralisés pour le faire ?
En fin de compte, c’est une question d’effet de réseau et un problème d’œuf ou de poule. Les acheteurs veulent aller là où se trouvent les vendeurs, mais les vendeurs voudront également aller là où se trouvent les acheteurs. Si nous nous appuyons fortement sur des marchés ou des services centralisés pour résoudre ce problème, cet effet de réseau finira par s’aggraver et deviendra de plus en plus difficile à surmonter avec des alternatives décentralisées basées sur des protocoles. C’est donc une question très importante que les utilisateurs doivent se poser maintenant. Laissons-nous cette énorme lacune de la pile de protocoles Lightning être entièrement résolue par des services commerciaux centralisés, ou essayons-nous de la résoudre au niveau du protocole lui-même ?
Personnellement, je pense que, étant donné que le besoin de liquidités entrantes est absolument nécessaire pour utiliser le protocole de manière autonome, ce problème devrait être résolu au niveau du protocole. Et comme dernière remarque, résoudre ce problème au niveau du protocole de manière décentralisée permet toujours aux entreprises actuelles et aux solutions centralisées de se concurrencer ouvertement en utilisant elles-mêmes ce protocole.
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 Bitcoin Magazine.
