Dans notre dernier article, Les principaux défis auxquels est confronté le Lightning Network (1), nous avons discuté de la liquidité, l'un des principaux facteurs limitant le développement du Lightning Network. Le problème de liquidité peut être décomposé en deux aspects : d'une part, le manque global de liquidité dans le réseau, ce qui nécessite de réduire les obstacles à la construction et à la maintenance des nœuds Lightning Network et d'introduire des mécanismes d'incitation supplémentaires ; d'autre part, le problème de répartition de la liquidité. Actuellement, des solutions telles que Submarine Swap, le raccordement de canaux, les paiements multipath, Lightning Pool, la publicité de liquidité et les paiements en boucle sont en place pour optimiser la liquidité dans le Lightning Network.
Aujourd'hui, nous continuerons à aborder d'autres défis auxquels est actuellement confronté le Lightning Network et les solutions innovantes proposées par la communauté.
Avec sa haute capacité de traitement, sa faible latence, son faible coût et ses fonctionnalités de confidentialité, le Lightning Network est devenu un choix idéal pour les paiements en cryptomonnaie et constitue une infrastructure de paiement clé pour la construction d'une économie P2P. En 2021, suite à l'adoption du Bitcoin comme monnaie légale par El Salvador, le champ d'application du Lightning Network s'est considérablement étendu, avec à la fois le nombre et le montant des paiements en hausse, conduisant à plus de 82 000 canaux de paiement dans le réseau à un moment donné.
Source: https://mempool.space/graphs/lightning/capacity
Cependant, au cours des deux dernières années, il y a eu quelques changements dans la tendance de développement du Lightning Network. À partir des graphiques ci-dessus, nous pouvons observer que le taux de croissance des fonds dans le Lightning Network a ralenti. Plus remarquablement, le nombre de canaux a même diminué. Ce phénomène reflète que le Lightning Network est confronté à de nouveaux défis après une expansion rapide.
Actuellement, BTC est la principale devise en circulation au sein du réseau Bitcoin Lightning. Cependant, l'une des plus grandes difficultés auxquelles fait face BTC en tant que moyen d'échange est sa forte volatilité des prix. Cette instabilité a depuis longtemps été un obstacle majeur à l'adoption généralisée du réseau Lightning. Pour vraiment introduire le réseau Lightning dans les foyers et en faire une méthode préférée pour les petits paiements quotidiens et fréquents, il est particulièrement essentiel de prendre en charge les stablecoins. Après tout, dans la vie réelle, les gens ont l'habitude d'utiliser des devises ayant une valeur stable pour les transactions quotidiennes.
Pour remédier à cela, le 23 juillet 2024, Lightning Labs a lancé la première version mainnet du Lightning Network multi-actifs, introduisant officiellement les actifs Taproot dans le Lightning Network. Taproot Assets est un protocole d'émission d'actifs sur Bitcoin, permettant aux actifs émis d'être déposés dans les canaux de paiement du Lightning Network et transférés à travers le réseau existant du Lightning Network. Le lancement de la version principale du Lightning Network multi-actifs marque le soutien formel des stablecoins sur le réseau Lightning Bitcoin, ouvrant la voie à des applications telles que le trading forex à règlement instantané mondial via le réseau Lightning et l'utilisation de stablecoins pour l'achat de biens.
Image: Dans le Lightning Network, Alice envoie un stablecoin USD, et Bob reçoit un stablecoin EUR.
De plus, Nervos CKB a lancé le réseau Fiber pour le réseau Lightning, qui exploite la flexibilité de la blockchain CKB pour prendre en charge nativement les actifs définis par l'utilisateur, y compris les stablecoins natifs de Bitcoin émis par des protocoles décentralisés tels que Stable++. Dans la version de test entièrement fonctionnelle publiée en septembre, les développeurs peuvent déjà tester le stablecoin natif de Bitcoin RUSD en utilisant le réseau Fiber.
Nous croyons que l'intégration du Lightning Network et des stablecoins va libérer de puissantes synergies, injectant une nouvelle vitalité dans le Lightning Network et favorisant l'adoption généralisée des paiements cryptos dans la vie quotidienne.
Malgré des avancées technologiques significatives dans le Lightning Network, il reste encore de la place pour améliorer l'expérience utilisateur, en particulier par rapport aux expériences de paiement traditionnelles. Quelques lacunes clés incluent :
Les utilisateurs doivent rester en ligne lorsqu'ils reçoivent ou envoient des paiements sur le Lightning Network. Cela est dû au fait que les paiements sur le Lightning Network impliquent de modifier l'état des fonds dans un canal partagé avec d'autres personnes, ce qui signifie que les deux parties doivent être en ligne pour modifier l'état des fonds ensemble. L'une des principales raisons des échecs de paiement sur le Lightning Network est que le destinataire est hors ligne. Du point de vue de l'expérience utilisateur, il s'agit d'un défaut de conception majeur. En revanche, les méthodes de paiement traditionnelles (comme les virements bancaires) et les paiements sur la blockchain (comme les transferts USDT on-chain) ne nécessitent pas que le destinataire soit en ligne ; les transactions peuvent être effectuées simplement en connaissant le compte ou l'adresse du destinataire.
La solution principale actuelle consiste à introduire des fournisseurs de services Lightning Network (LSP). Les LSP peuvent recevoir des paiements au nom des utilisateurs hors ligne, éliminant ainsi l'exigence stricte de rester en ligne. Cette solution rapproche l'expérience utilisateur du réseau Lightning de celle des méthodes de paiement existantes, améliorant considérablement sa praticité et sa commodité.
Cependant, cette solution introduit également un nouveau défi : les hypothèses de confiance. Les utilisateurs doivent accorder un certain degré de confiance à leur fournisseur de services Lightning Network choisi. Cette dépendance à l'égard de tiers contredit quelque peu l'intention initiale de la décentralisation et peut susciter des inquiétudes chez certains utilisateurs.
Les factures dans le Lightning Network sont l'outil principal pour demander des paiements. Elles sont générées par le destinataire du paiement et fournissent à l'initiateur toutes les informations nécessaires pour finaliser la transaction. Nous pouvons simplement assimiler les factures aux "codes de paiement" couramment utilisés dans les applications de paiement.
Actuellement, la facture par défaut dans le Lightning Network est à usage unique, contenant une valeur de hachage pour un seul paiement ainsi que son montant. Une fois que le paiement est effectué ou que la facture expire, elle devient invalide. Ce mécanisme se traduit par un processus fastidieux : chaque paiement nécessite de générer, copier, coller et envoyer une nouvelle facture au payeur. Cette conception a un impact significatif sur l’expérience utilisateur dans certains scénarios. Par exemple, un commerçant habitué à afficher un code QR de paiement (comme ceux de WeChat ou Alipay) trouverait l’utilisation du Lightning Network fastidieuse. En particulier pendant les heures de pointe, la nécessité de générer et de partager fréquemment des factures pourrait réduire considérablement l’efficacité et même affecter les opérations normales.
Pour remédier à cela, la communauté Bitcoin a proposé plusieurs solutions :
The node_id of Lightning Network nodes remains unchanged and is exposed to the payer after an invoice is given, so Keysend treats it as a static endpoint. This method has a significant advantage: it relies entirely on the Lightning Network’s architecture without requiring additional protocol support. Its drawback is that it offers weaker privacy protection, as sensitive data such as the recipient’s node, channel, and channel UTXO are exposed.
Néanmoins, la praticité de Keysend a été largement reconnue, et la plupart des clients du Lightning Network ont déjà implémenté la fonctionnalité Keysend.
LNURL-pay est une norme qui permet aux utilisateurs de créer un code QR statique capable de recevoir plusieurs paiements, améliorant ainsi considérablement l'expérience utilisateur. Le flux de travail est le suivant :
L'adresse Lightning optimise encore ce processus en encodant le code QR de l'utilisateur (LNURL-pay) dans une URL ressemblant à une adresse e-mail. Lorsque d'autres utilisateurs accèdent à cette URL, le système renvoie automatiquement une demande LNURL-pay, simplifiant l'ensemble du processus de paiement.
Il convient de noter que la plupart des portefeuilles implémentant la fonctionnalité LNURL fonctionnent actuellement en mode de garde. Ces services de portefeuille attribuent à chaque utilisateur une adresse Lightning, leur permettant de recevoir facilement des paiements. Bien que cette approche offre des avantages pratiques, elle introduit également un degré de centralisation, obligeant les utilisateurs à peser le compromis entre la commodité et la décentralisation.
BOLT12 est une nouvelle proposition de spécification technique pour le réseau Lightning visant à obtenir certaines des fonctionnalités offertes par LNURL sans dépendre d'un serveur web. Bien que BOLT12 n'ait pas encore été fusionné dans BOLT (le fondement technique du réseau Lightning), il a obtenu le soutien de la plupart des développeurs. Le principal avantage de BOLT12 par rapport à LNURL est qu'il peut être mis en œuvre au sein du protocole Lightning Network lui-même, sans avoir besoin de dépendre d'autres protocoles réseau ou méthodes de communication.
En plus des problèmes de liquidité globale et de distribution de liquidité mentionnés dans le article précédentEn plus du manque de support stablecoin mentionné dans cet article, il y a de nombreux domaines à améliorer en termes d'expérience utilisateur au sein du Lightning Network. Le développement du Lightning Network fait également face à de nombreux autres défis. Par exemple, le mécanisme LN-Penalty utilisé dans le réseau Lightning Bitcoin ajoute non seulement de la complexité, mais impose également des charges de stockage. La mise en œuvre de l'amélioration proposée, eltoo, nécessite un soft fork de Bitcoin et l'introduction d'un nouveau type de hachage de signature. De même, les préoccupations relatives à la confidentialité concernant les HTLCs pourraient voir des améliorations grâce aux PTLCs, qui pourraient d'abord être mises en œuvre sur des réseaux Lightning d'autres blockchains.
Bien que la route à venir soit difficile, les avancées technologiques continues et les efforts soutenus de la communauté finiront par surmonter ces obstacles. Nous avons toutes les raisons de croire que le Lightning Network se rapproche de son objectif d'adoption généralisée. Il ne transformera pas seulement les paiements cryptographiques, mais il a également le potentiel de devenir un moteur clé de l'innovation financière mondiale.
Dans notre dernier article, Les principaux défis auxquels est confronté le Lightning Network (1), nous avons discuté de la liquidité, l'un des principaux facteurs limitant le développement du Lightning Network. Le problème de liquidité peut être décomposé en deux aspects : d'une part, le manque global de liquidité dans le réseau, ce qui nécessite de réduire les obstacles à la construction et à la maintenance des nœuds Lightning Network et d'introduire des mécanismes d'incitation supplémentaires ; d'autre part, le problème de répartition de la liquidité. Actuellement, des solutions telles que Submarine Swap, le raccordement de canaux, les paiements multipath, Lightning Pool, la publicité de liquidité et les paiements en boucle sont en place pour optimiser la liquidité dans le Lightning Network.
Aujourd'hui, nous continuerons à aborder d'autres défis auxquels est actuellement confronté le Lightning Network et les solutions innovantes proposées par la communauté.
Avec sa haute capacité de traitement, sa faible latence, son faible coût et ses fonctionnalités de confidentialité, le Lightning Network est devenu un choix idéal pour les paiements en cryptomonnaie et constitue une infrastructure de paiement clé pour la construction d'une économie P2P. En 2021, suite à l'adoption du Bitcoin comme monnaie légale par El Salvador, le champ d'application du Lightning Network s'est considérablement étendu, avec à la fois le nombre et le montant des paiements en hausse, conduisant à plus de 82 000 canaux de paiement dans le réseau à un moment donné.
Source: https://mempool.space/graphs/lightning/capacity
Cependant, au cours des deux dernières années, il y a eu quelques changements dans la tendance de développement du Lightning Network. À partir des graphiques ci-dessus, nous pouvons observer que le taux de croissance des fonds dans le Lightning Network a ralenti. Plus remarquablement, le nombre de canaux a même diminué. Ce phénomène reflète que le Lightning Network est confronté à de nouveaux défis après une expansion rapide.
Actuellement, BTC est la principale devise en circulation au sein du réseau Bitcoin Lightning. Cependant, l'une des plus grandes difficultés auxquelles fait face BTC en tant que moyen d'échange est sa forte volatilité des prix. Cette instabilité a depuis longtemps été un obstacle majeur à l'adoption généralisée du réseau Lightning. Pour vraiment introduire le réseau Lightning dans les foyers et en faire une méthode préférée pour les petits paiements quotidiens et fréquents, il est particulièrement essentiel de prendre en charge les stablecoins. Après tout, dans la vie réelle, les gens ont l'habitude d'utiliser des devises ayant une valeur stable pour les transactions quotidiennes.
Pour remédier à cela, le 23 juillet 2024, Lightning Labs a lancé la première version mainnet du Lightning Network multi-actifs, introduisant officiellement les actifs Taproot dans le Lightning Network. Taproot Assets est un protocole d'émission d'actifs sur Bitcoin, permettant aux actifs émis d'être déposés dans les canaux de paiement du Lightning Network et transférés à travers le réseau existant du Lightning Network. Le lancement de la version principale du Lightning Network multi-actifs marque le soutien formel des stablecoins sur le réseau Lightning Bitcoin, ouvrant la voie à des applications telles que le trading forex à règlement instantané mondial via le réseau Lightning et l'utilisation de stablecoins pour l'achat de biens.
Image: Dans le Lightning Network, Alice envoie un stablecoin USD, et Bob reçoit un stablecoin EUR.
De plus, Nervos CKB a lancé le réseau Fiber pour le réseau Lightning, qui exploite la flexibilité de la blockchain CKB pour prendre en charge nativement les actifs définis par l'utilisateur, y compris les stablecoins natifs de Bitcoin émis par des protocoles décentralisés tels que Stable++. Dans la version de test entièrement fonctionnelle publiée en septembre, les développeurs peuvent déjà tester le stablecoin natif de Bitcoin RUSD en utilisant le réseau Fiber.
Nous croyons que l'intégration du Lightning Network et des stablecoins va libérer de puissantes synergies, injectant une nouvelle vitalité dans le Lightning Network et favorisant l'adoption généralisée des paiements cryptos dans la vie quotidienne.
Malgré des avancées technologiques significatives dans le Lightning Network, il reste encore de la place pour améliorer l'expérience utilisateur, en particulier par rapport aux expériences de paiement traditionnelles. Quelques lacunes clés incluent :
Les utilisateurs doivent rester en ligne lorsqu'ils reçoivent ou envoient des paiements sur le Lightning Network. Cela est dû au fait que les paiements sur le Lightning Network impliquent de modifier l'état des fonds dans un canal partagé avec d'autres personnes, ce qui signifie que les deux parties doivent être en ligne pour modifier l'état des fonds ensemble. L'une des principales raisons des échecs de paiement sur le Lightning Network est que le destinataire est hors ligne. Du point de vue de l'expérience utilisateur, il s'agit d'un défaut de conception majeur. En revanche, les méthodes de paiement traditionnelles (comme les virements bancaires) et les paiements sur la blockchain (comme les transferts USDT on-chain) ne nécessitent pas que le destinataire soit en ligne ; les transactions peuvent être effectuées simplement en connaissant le compte ou l'adresse du destinataire.
La solution principale actuelle consiste à introduire des fournisseurs de services Lightning Network (LSP). Les LSP peuvent recevoir des paiements au nom des utilisateurs hors ligne, éliminant ainsi l'exigence stricte de rester en ligne. Cette solution rapproche l'expérience utilisateur du réseau Lightning de celle des méthodes de paiement existantes, améliorant considérablement sa praticité et sa commodité.
Cependant, cette solution introduit également un nouveau défi : les hypothèses de confiance. Les utilisateurs doivent accorder un certain degré de confiance à leur fournisseur de services Lightning Network choisi. Cette dépendance à l'égard de tiers contredit quelque peu l'intention initiale de la décentralisation et peut susciter des inquiétudes chez certains utilisateurs.
Les factures dans le Lightning Network sont l'outil principal pour demander des paiements. Elles sont générées par le destinataire du paiement et fournissent à l'initiateur toutes les informations nécessaires pour finaliser la transaction. Nous pouvons simplement assimiler les factures aux "codes de paiement" couramment utilisés dans les applications de paiement.
Actuellement, la facture par défaut dans le Lightning Network est à usage unique, contenant une valeur de hachage pour un seul paiement ainsi que son montant. Une fois que le paiement est effectué ou que la facture expire, elle devient invalide. Ce mécanisme se traduit par un processus fastidieux : chaque paiement nécessite de générer, copier, coller et envoyer une nouvelle facture au payeur. Cette conception a un impact significatif sur l’expérience utilisateur dans certains scénarios. Par exemple, un commerçant habitué à afficher un code QR de paiement (comme ceux de WeChat ou Alipay) trouverait l’utilisation du Lightning Network fastidieuse. En particulier pendant les heures de pointe, la nécessité de générer et de partager fréquemment des factures pourrait réduire considérablement l’efficacité et même affecter les opérations normales.
Pour remédier à cela, la communauté Bitcoin a proposé plusieurs solutions :
The node_id of Lightning Network nodes remains unchanged and is exposed to the payer after an invoice is given, so Keysend treats it as a static endpoint. This method has a significant advantage: it relies entirely on the Lightning Network’s architecture without requiring additional protocol support. Its drawback is that it offers weaker privacy protection, as sensitive data such as the recipient’s node, channel, and channel UTXO are exposed.
Néanmoins, la praticité de Keysend a été largement reconnue, et la plupart des clients du Lightning Network ont déjà implémenté la fonctionnalité Keysend.
LNURL-pay est une norme qui permet aux utilisateurs de créer un code QR statique capable de recevoir plusieurs paiements, améliorant ainsi considérablement l'expérience utilisateur. Le flux de travail est le suivant :
L'adresse Lightning optimise encore ce processus en encodant le code QR de l'utilisateur (LNURL-pay) dans une URL ressemblant à une adresse e-mail. Lorsque d'autres utilisateurs accèdent à cette URL, le système renvoie automatiquement une demande LNURL-pay, simplifiant l'ensemble du processus de paiement.
Il convient de noter que la plupart des portefeuilles implémentant la fonctionnalité LNURL fonctionnent actuellement en mode de garde. Ces services de portefeuille attribuent à chaque utilisateur une adresse Lightning, leur permettant de recevoir facilement des paiements. Bien que cette approche offre des avantages pratiques, elle introduit également un degré de centralisation, obligeant les utilisateurs à peser le compromis entre la commodité et la décentralisation.
BOLT12 est une nouvelle proposition de spécification technique pour le réseau Lightning visant à obtenir certaines des fonctionnalités offertes par LNURL sans dépendre d'un serveur web. Bien que BOLT12 n'ait pas encore été fusionné dans BOLT (le fondement technique du réseau Lightning), il a obtenu le soutien de la plupart des développeurs. Le principal avantage de BOLT12 par rapport à LNURL est qu'il peut être mis en œuvre au sein du protocole Lightning Network lui-même, sans avoir besoin de dépendre d'autres protocoles réseau ou méthodes de communication.
En plus des problèmes de liquidité globale et de distribution de liquidité mentionnés dans le article précédentEn plus du manque de support stablecoin mentionné dans cet article, il y a de nombreux domaines à améliorer en termes d'expérience utilisateur au sein du Lightning Network. Le développement du Lightning Network fait également face à de nombreux autres défis. Par exemple, le mécanisme LN-Penalty utilisé dans le réseau Lightning Bitcoin ajoute non seulement de la complexité, mais impose également des charges de stockage. La mise en œuvre de l'amélioration proposée, eltoo, nécessite un soft fork de Bitcoin et l'introduction d'un nouveau type de hachage de signature. De même, les préoccupations relatives à la confidentialité concernant les HTLCs pourraient voir des améliorations grâce aux PTLCs, qui pourraient d'abord être mises en œuvre sur des réseaux Lightning d'autres blockchains.
Bien que la route à venir soit difficile, les avancées technologiques continues et les efforts soutenus de la communauté finiront par surmonter ces obstacles. Nous avons toutes les raisons de croire que le Lightning Network se rapproche de son objectif d'adoption généralisée. Il ne transformera pas seulement les paiements cryptographiques, mais il a également le potentiel de devenir un moteur clé de l'innovation financière mondiale.