Auteur : Viktor Bunin, expert en protocole cloud Coinbase Compilateur : Qianwen, ChainCatcher
Je n'ai pas utilisé Lightening (appelé plus tard "Lightning Network") depuis un moment.
La dernière fois que j'ai passé du temps à y travailler, c'était en 2019, lorsque j'ai fait équipe avec Elizabeth Stark et d'autres dirigeants communautaires pour organiser la première conférence Lightning Network à Berlin. Depuis lors, j'ai passé la plupart de mon temps à travailler sur d'autres protocoles, et bien que je sois toujours ami avec des gens comme Elizabeth, ma compréhension du fonctionnement réel du Lightning Network s'est dégradée. Après avoir réexaminé, j'ai réalisé que ce n'était pas seulement moi, mais la plupart de mes amis aussi.
Ce message est destiné à ceux qui n'ont pas utilisé le Lightning Network récemment. Il discutera des idées fausses que j'ai ou d'autres que j'ai vues. Si j'ai raté de bons points, s'il vous plaît envoyez-moi une ligne sur Twitter.
**Idée fausse 1 : vous devez exécuter votre propre nœud pour utiliser le réseau Lightning sans surveillance, ce qui empêche les utilisateurs ordinaires d'utiliser des appareils mobiles. **
C'était vrai il y a quelques années, mais les utilisateurs peuvent désormais utiliser le Lightning Network sur des appareils mobiles via des clients légers non gérés. Les utilisateurs contrôlent toujours leurs clés et l'expérience du portefeuille avec Lightning Light Client est la même que celle d'appeler Alchemy ou Infura via RPC lors de l'utilisation d'Ethereum.
**Idée fausse 2 : l'expéditeur et le destinataire doivent être en ligne en même temps pour que les paiements Lightning réussissent (pas de paiements hors ligne/synchrones). **
Cette situation existe toujours, mais avec quelques solutions de contournement intéressantes. Les portefeuilles mobiles Lightning non dépositaires peuvent recevoir des paiements via des tâches en arrière-plan ou des notifications téléphoniques même lorsque le portefeuille ne fonctionne pas au premier plan. Cependant, cette approche est limitée par les systèmes d'exploitation mobiles. Les systèmes d'exploitation modernes limitent la quantité de calculs effectués par les applications d'arrière-plan pour économiser la batterie. Recevoir quelques paiements LN, c'est bien, mais si trop de paiements sont reçus dans un court laps de temps, ils commencent à expirer en raison de contraintes de calcul.
À plus long terme, les développeurs du protocole Lightning Network travaillent sur la spécification Async Payments, qui permettra des latences sans confiance arbitrairement longues. Essentiellement, le paiement est crédité à partir du nœud de l'expéditeur, mais si le nœud du destinataire se déconnecte, le paiement reste dans le LSP de l'expéditeur (Lightning Network/Liquidity Service Provider, généralement géré par le portefeuille lui-même), jusqu'à ce que le destinataire revienne en ligne. ** Cette mise à jour devrait avoir lieu l'année prochaine, mais il n'y a pas encore de date de lancement officielle. ** Cependant, cela nécessite que les portefeuilles participants contiennent LSP, ce qui peut entraver son adoption en tant que solution à l'échelle du réseau.
** Malentendu 3 : Lightning Network exige que les deux utilisateurs investissent la même quantité de BTC dans le canal pour ouvrir le canal. **
Cela n'est pas vrai. Sur la plupart des clients Lightning Network, le canal est ouvert à sens unique par défaut, de sorte que seul l'expéditeur doit investir des fonds dans le canal, et le bénéficiaire peut être une toute nouvelle adresse vide. Ce malentendu découle du livre blanc Lightning Network, où les exemples font systématiquement référence à des canaux de financement bidirectionnels.
Il est en fait basé sur une trame de fond intéressante. Le premier canal de paiement (Spilman) n'autorisait que les paiements à sens unique. L'innovation du Lightning Network réside dans la réalisation de doubles fonds et de paiements bidirectionnels, et le canal n'a pas de délai d'expiration. C'est peut-être pour cette raison que l'article de Lightning Network s'y concentre autant. Il s'agissait d'une invention importante par rapport aux conceptions de protocoles connues à l'époque.
**Mythe 4 : le Lightning Network oblige les utilisateurs à spécifier des factures spécifiques à usage unique, ce qui est une expérience utilisateur terrible. **
C'était effectivement le cas au début. Mais maintenant, avec l'adresse Lightning Network, il s'agit essentiellement de l'ENS du Lightning Network. Ils sont activés par lnurl-pay, qui permet aux utilisateurs d'envoyer des BTC à viktor@example.com via le Lightning Network, quels que soient le montant et la durée.
** Malentendu 5 : Les utilisateurs doivent comprendre et choisir Bitcoin et Lightning Network lors de l'envoi de BTC. **
Il devait en être ainsi avant. Mais c'est différent maintenant. Désormais, ils disposent d'un code QR unifié qui regroupe soigneusement l'adresse en chaîne avec la facture Lightning Network afin que le portefeuille expéditeur puisse choisir le bon itinéraire. Ouvrez CashApp, allez dans l'onglet Bitcoin. Notez que même si Cash App prend en charge Lightning Network, il n'y a pas d'option pour sélectionner Lightning Network. C'est parce qu'ils utilisent le code QR unifié.
Cependant, cela ne résout pas le problème d'un solde unique - le solde BTC d'un utilisateur peut toujours être divisé en chaîne et dans le Lightning Network. Ce problème peut être résolu dans une certaine mesure grâce à Submarineswap et/ou Splicing, mais mon point de vue à long terme est que les utilisateurs ne se rendront même pas compte qu'il s'agit d'un problème, ni ne se rendront compte que le Lightning Network existe parce que le portefeuille et les autres fournisseurs gèrent les complexités sous-jacentes qui seront cachées sous une expérience utilisateur fluide.
**Mythe #6 : Le Lightning Network est inefficace en termes de capital et n'est donc pas viable. **
Cette discussion est délicate et je vais essayer d'être le plus neutre possible.
Le Lightning Network utilise un modèle en étoile. La partie hub-to-hub du réseau est très efficace en termes de capital en raison du ratio élevé «d'allocation de capital par unité» des grands canaux entre les bourses, les portefeuilles de garde, les LSP et les nœuds de routage optimaux.
Cependant, là où l'inefficacité du capital du réseau Lightning se situe aux extrémités - les utilisateurs non dépositaires. Pour les utilisateurs dépositaires de Lightning, les portefeuilles n'ont besoin que de maintenir de grands canaux avec d'autres hubs et d'effectuer une comptabilité interne des soldes des utilisateurs. Pour les utilisateurs non dépositaires, le portefeuille doit maintenir un canal de financement ouvert séparé avec chaque utilisateur. Le défi est de savoir comment maintenir une allocation et une gestion continues des liquidités à travers ces canaux.
Pour donner un exemple concret : un utilisateur de portefeuille non dépositaire souhaite envoyer 0,1 BTC à un ami via le Lightning Network. En supposant qu'il y ait suffisamment de liquidités dans le canal entre eux et le fournisseur de portefeuille et chaque nœud en cours de route, le paiement sera réussi. Mais maintenant, le portefeuille a un problème - ils ont 0,1 BTC dans le canal de leur côté, si l'utilisateur ne reçoit aucun paiement (rééquilibrant ainsi le canal), ce 0,1 BTC y sera inactif, ce qui entraînera une faible inefficacité du fournisseur de portefeuille. À ce stade, les fournisseurs de portefeuilles doivent décider s'ils souhaitent préserver la liquidité ou retirer de la liquidité en fermant des canaux (ce qui crée une mauvaise expérience utilisateur) ou en fusionnant des canaux (qui sont invisibles pour les utilisateurs).
Pour les utilisateurs non dépositaires, ce problème d'inefficacité marginale du capital est un problème d'optimisation très ennuyeux, qui est objectivement pire que le modèle basé sur les comptes, quelle que soit la taille de la transaction. Cependant, ce n'est pas un problème insoluble. Tant que ce n'est pas impossible, il faut réussir, ce qui est aussi la devise de la communauté des développeurs Bitcoin.
Outre la difficulté d'optimiser le capital, un autre défi provient des coûts associés à la gestion des canaux et des liquidités, car chaque raccordement, fermeture de canal, etc. nécessite une transaction en chaîne. Le budget de sécurité de Bitcoin repose sur une augmentation massive des frais de transaction, mais si les frais de transaction atteignent 30 à 60 $, la gestion des canaux sera d'un coût prohibitif à grande échelle, et le Lightning Network non dépositaire pourrait ne pas être disponible pour une grande partie de la population mondiale. Les portefeuilles Lightning hébergés ont actuellement un avantage en raison des incitations intégrées et augmenteront probablement encore plus à mesure que les frais en chaîne augmentent, car leur modèle de compte omnibus rend la gestion des canaux beaucoup moins fréquente. La communauté travaille dur pour résoudre ce problème et s'assurer que les portefeuilles Lightning non dépositaires continuent d'être des citoyens de première classe sur le réseau, mais il n'y a pas encore de solution claire.
Lightning Network a encore un long chemin à parcourir pour être simple, transparent et complètement abstrait. Il existe encore de nombreux cas extrêmes et les utilisateurs non gérés n'ont pas encore profité de l'expérience utilisateur ultime. Cependant, de nombreux problèmes ont déjà été résolus, et bien d'autres le seront dans les prochaines années. Maintenant que l'éclair est arrivé, le tonnerre peut-il être loin derrière ?
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
Clarifier 6 idées fausses sur le réseau Lightning de Bitcoin
Auteur : Viktor Bunin, expert en protocole cloud Coinbase Compilateur : Qianwen, ChainCatcher
Je n'ai pas utilisé Lightening (appelé plus tard "Lightning Network") depuis un moment.
La dernière fois que j'ai passé du temps à y travailler, c'était en 2019, lorsque j'ai fait équipe avec Elizabeth Stark et d'autres dirigeants communautaires pour organiser la première conférence Lightning Network à Berlin. Depuis lors, j'ai passé la plupart de mon temps à travailler sur d'autres protocoles, et bien que je sois toujours ami avec des gens comme Elizabeth, ma compréhension du fonctionnement réel du Lightning Network s'est dégradée. Après avoir réexaminé, j'ai réalisé que ce n'était pas seulement moi, mais la plupart de mes amis aussi.
Ce message est destiné à ceux qui n'ont pas utilisé le Lightning Network récemment. Il discutera des idées fausses que j'ai ou d'autres que j'ai vues. Si j'ai raté de bons points, s'il vous plaît envoyez-moi une ligne sur Twitter.
**Idée fausse 1 : vous devez exécuter votre propre nœud pour utiliser le réseau Lightning sans surveillance, ce qui empêche les utilisateurs ordinaires d'utiliser des appareils mobiles. **
C'était vrai il y a quelques années, mais les utilisateurs peuvent désormais utiliser le Lightning Network sur des appareils mobiles via des clients légers non gérés. Les utilisateurs contrôlent toujours leurs clés et l'expérience du portefeuille avec Lightning Light Client est la même que celle d'appeler Alchemy ou Infura via RPC lors de l'utilisation d'Ethereum.
**Idée fausse 2 : l'expéditeur et le destinataire doivent être en ligne en même temps pour que les paiements Lightning réussissent (pas de paiements hors ligne/synchrones). **
Cette situation existe toujours, mais avec quelques solutions de contournement intéressantes. Les portefeuilles mobiles Lightning non dépositaires peuvent recevoir des paiements via des tâches en arrière-plan ou des notifications téléphoniques même lorsque le portefeuille ne fonctionne pas au premier plan. Cependant, cette approche est limitée par les systèmes d'exploitation mobiles. Les systèmes d'exploitation modernes limitent la quantité de calculs effectués par les applications d'arrière-plan pour économiser la batterie. Recevoir quelques paiements LN, c'est bien, mais si trop de paiements sont reçus dans un court laps de temps, ils commencent à expirer en raison de contraintes de calcul.
À plus long terme, les développeurs du protocole Lightning Network travaillent sur la spécification Async Payments, qui permettra des latences sans confiance arbitrairement longues. Essentiellement, le paiement est crédité à partir du nœud de l'expéditeur, mais si le nœud du destinataire se déconnecte, le paiement reste dans le LSP de l'expéditeur (Lightning Network/Liquidity Service Provider, généralement géré par le portefeuille lui-même), jusqu'à ce que le destinataire revienne en ligne. ** Cette mise à jour devrait avoir lieu l'année prochaine, mais il n'y a pas encore de date de lancement officielle. ** Cependant, cela nécessite que les portefeuilles participants contiennent LSP, ce qui peut entraver son adoption en tant que solution à l'échelle du réseau.
** Malentendu 3 : Lightning Network exige que les deux utilisateurs investissent la même quantité de BTC dans le canal pour ouvrir le canal. **
Cela n'est pas vrai. Sur la plupart des clients Lightning Network, le canal est ouvert à sens unique par défaut, de sorte que seul l'expéditeur doit investir des fonds dans le canal, et le bénéficiaire peut être une toute nouvelle adresse vide. Ce malentendu découle du livre blanc Lightning Network, où les exemples font systématiquement référence à des canaux de financement bidirectionnels.
Il est en fait basé sur une trame de fond intéressante. Le premier canal de paiement (Spilman) n'autorisait que les paiements à sens unique. L'innovation du Lightning Network réside dans la réalisation de doubles fonds et de paiements bidirectionnels, et le canal n'a pas de délai d'expiration. C'est peut-être pour cette raison que l'article de Lightning Network s'y concentre autant. Il s'agissait d'une invention importante par rapport aux conceptions de protocoles connues à l'époque.
**Mythe 4 : le Lightning Network oblige les utilisateurs à spécifier des factures spécifiques à usage unique, ce qui est une expérience utilisateur terrible. **
C'était effectivement le cas au début. Mais maintenant, avec l'adresse Lightning Network, il s'agit essentiellement de l'ENS du Lightning Network. Ils sont activés par lnurl-pay, qui permet aux utilisateurs d'envoyer des BTC à viktor@example.com via le Lightning Network, quels que soient le montant et la durée.
** Malentendu 5 : Les utilisateurs doivent comprendre et choisir Bitcoin et Lightning Network lors de l'envoi de BTC. **
Il devait en être ainsi avant. Mais c'est différent maintenant. Désormais, ils disposent d'un code QR unifié qui regroupe soigneusement l'adresse en chaîne avec la facture Lightning Network afin que le portefeuille expéditeur puisse choisir le bon itinéraire. Ouvrez CashApp, allez dans l'onglet Bitcoin. Notez que même si Cash App prend en charge Lightning Network, il n'y a pas d'option pour sélectionner Lightning Network. C'est parce qu'ils utilisent le code QR unifié.
Cependant, cela ne résout pas le problème d'un solde unique - le solde BTC d'un utilisateur peut toujours être divisé en chaîne et dans le Lightning Network. Ce problème peut être résolu dans une certaine mesure grâce à Submarineswap et/ou Splicing, mais mon point de vue à long terme est que les utilisateurs ne se rendront même pas compte qu'il s'agit d'un problème, ni ne se rendront compte que le Lightning Network existe parce que le portefeuille et les autres fournisseurs gèrent les complexités sous-jacentes qui seront cachées sous une expérience utilisateur fluide.
**Mythe #6 : Le Lightning Network est inefficace en termes de capital et n'est donc pas viable. **
Cette discussion est délicate et je vais essayer d'être le plus neutre possible.
Le Lightning Network utilise un modèle en étoile. La partie hub-to-hub du réseau est très efficace en termes de capital en raison du ratio élevé «d'allocation de capital par unité» des grands canaux entre les bourses, les portefeuilles de garde, les LSP et les nœuds de routage optimaux.
Cependant, là où l'inefficacité du capital du réseau Lightning se situe aux extrémités - les utilisateurs non dépositaires. Pour les utilisateurs dépositaires de Lightning, les portefeuilles n'ont besoin que de maintenir de grands canaux avec d'autres hubs et d'effectuer une comptabilité interne des soldes des utilisateurs. Pour les utilisateurs non dépositaires, le portefeuille doit maintenir un canal de financement ouvert séparé avec chaque utilisateur. Le défi est de savoir comment maintenir une allocation et une gestion continues des liquidités à travers ces canaux.
Pour donner un exemple concret : un utilisateur de portefeuille non dépositaire souhaite envoyer 0,1 BTC à un ami via le Lightning Network. En supposant qu'il y ait suffisamment de liquidités dans le canal entre eux et le fournisseur de portefeuille et chaque nœud en cours de route, le paiement sera réussi. Mais maintenant, le portefeuille a un problème - ils ont 0,1 BTC dans le canal de leur côté, si l'utilisateur ne reçoit aucun paiement (rééquilibrant ainsi le canal), ce 0,1 BTC y sera inactif, ce qui entraînera une faible inefficacité du fournisseur de portefeuille. À ce stade, les fournisseurs de portefeuilles doivent décider s'ils souhaitent préserver la liquidité ou retirer de la liquidité en fermant des canaux (ce qui crée une mauvaise expérience utilisateur) ou en fusionnant des canaux (qui sont invisibles pour les utilisateurs).
Pour les utilisateurs non dépositaires, ce problème d'inefficacité marginale du capital est un problème d'optimisation très ennuyeux, qui est objectivement pire que le modèle basé sur les comptes, quelle que soit la taille de la transaction. Cependant, ce n'est pas un problème insoluble. Tant que ce n'est pas impossible, il faut réussir, ce qui est aussi la devise de la communauté des développeurs Bitcoin.
Outre la difficulté d'optimiser le capital, un autre défi provient des coûts associés à la gestion des canaux et des liquidités, car chaque raccordement, fermeture de canal, etc. nécessite une transaction en chaîne. Le budget de sécurité de Bitcoin repose sur une augmentation massive des frais de transaction, mais si les frais de transaction atteignent 30 à 60 $, la gestion des canaux sera d'un coût prohibitif à grande échelle, et le Lightning Network non dépositaire pourrait ne pas être disponible pour une grande partie de la population mondiale. Les portefeuilles Lightning hébergés ont actuellement un avantage en raison des incitations intégrées et augmenteront probablement encore plus à mesure que les frais en chaîne augmentent, car leur modèle de compte omnibus rend la gestion des canaux beaucoup moins fréquente. La communauté travaille dur pour résoudre ce problème et s'assurer que les portefeuilles Lightning non dépositaires continuent d'être des citoyens de première classe sur le réseau, mais il n'y a pas encore de solution claire.
Lightning Network a encore un long chemin à parcourir pour être simple, transparent et complètement abstrait. Il existe encore de nombreux cas extrêmes et les utilisateurs non gérés n'ont pas encore profité de l'expérience utilisateur ultime. Cependant, de nombreux problèmes ont déjà été résolus, et bien d'autres le seront dans les prochaines années. Maintenant que l'éclair est arrivé, le tonnerre peut-il être loin derrière ?