Een probleem met de liquiditeit van het Lightning-netwerk van Bitcoin en ideeën om het aan te pakken

Een probleem met de liquiditeit van het Lightning-netwerk van Bitcoin en ideeën om het aan te pakken
Dit is een opinieredactioneel commentaar van Shinobi, een autodidactische opvoeder in de Bitcoin-ruimte en technisch georiënteerde Bitcoin-podcasthost.

Het negeren van de problemen van het Lightning Network en de protocolstack lijkt tegenwoordig erg populair te zijn. Het is momenteel de meest algemeen aanvaarde en gebruikte tweede laag van het Bitcoin-netwerk, en de snelste in termen van verdere ontwikkeling. Het heeft ook veel tekortkomingen die gemakkelijk onder het tapijt kunnen worden geveegd en omzeild, aangezien het erg klein is en zich in een zeer vroeg stadium van adoptie bevindt. Maar dat zorgt er niet voor dat die problemen verdwijnen, of de realiteit verandert dat op een veel grotere schaal en verder langs de adoptiecurve die problemen heel reëel worden waarvoor daadwerkelijke schaalbare oplossingen nodig zijn.





Een van de problemen in de kern van Lightning is de kwestie van het ontvangen van liquiditeit. Het is niet mogelijk om geld te ontvangen via het Lightning Network zonder eerst liquiditeit te hebben ontvangen van het knooppunt van iemand anders. Dit is een fundamentele en onvermijdelijke beperking van het gebruik van het Lightning Network op een niet-bewarende manier. Het is duidelijk dat je met dingen als Wallet of Satoshi of Bluewallet's standaard LNDHub (die bewaarplicht zijn) dit probleem kunt omzeilen, maar dat is alleen omdat iemand anders het voor je heeft opgelost en je niet echt de controle hebt over je geld. Als je echter zelfbeheersing aan de dag legt, moet je het probleem daadwerkelijk aanpakken.

















Toen het Lightning Network voor het eerst live ging en echt gebruik begon te zien tijdens het "#Reckless"-tijdperk, werd dit probleem zeer informeel aangepakt. Het werd in wezen opgelost door sociale connecties; door middel van verzoeken aan mensen die je kende of goede vrienden; door middel van handdrukovereenkomsten "Hé vriend, kun je me wat liquiditeit sturen, ik heb net mijn knoop doorgehakt." Er waren geen marktplaatsen, er waren geen diensten om te gebruiken, het waren letterlijk gewoon vrienden die elkaar hielpen. Zelfs vandaag de dag, via zaken als PLEBNET, vindt een groot percentage van de liquiditeitsbronnen die op het netwerk plaatsvinden plaats in dit soort informele sociale regelingen.

Het netwerk is nog steeds erg klein, en nog steeds beperkt tot wat op een sociale grafiek een kleine reeks actoren is die zelfs door indirecte graden van scheiding niet zo ver van elkaar verwijderd zijn. Ik zou zeggen dat we vandaag net een groeifase beginnen in te gaan waarin de omvang van het netwerk en het aantal betrokken mensen het punt beginnen te bereiken waarop dit soort regeling en dynamiek niet langer houdbaar is.

De volgende groeifase in het oplossen van dit probleem vond plaats niet al te lang nadat het netwerk live ging. Diensten zoals LNBIG begonnen met het opzetten van een pagina waar mensen inkomende liquiditeiten konden opvragen. Bitrefill begon kanalen aan te bieden met het ontvangen van liquiditeit als een service (en creëerde daarbij hun "Turbo-kanaal" -specificatie waarmee je een kanaal kunt gebruiken nog voordat het in de keten is bevestigd). Coincharge, Voltage en vele andere bedrijven bieden ook soortgelijke diensten aan. Door een vergoeding te betalen, kunt u een bedrijf eenvoudig een kanaal met u laten openen om ontvangende liquiditeit te verstrekken om geld te ontvangen. Deze stap in de evolutie van dingen vond plaats om een ​​soort schaalprobleem op te lossen, aangezien niet alle nieuwe gebruikers die aan boord kwamen die sociale connecties hadden om inkomende liquiditeit te krijgen. Zelfs als ze dat deden, hebben mensen maar zoveel geld dat ze kunnen toewijzen aan kanalen voor mensen die ze kennen. Je kunt ook niet verwachten dat mensen de hele dag zitten, altijd klaar staan ​​om kanalen te openen wanneer mensen liquiditeit nodig hebben. Een bedrijf heeft dus ruimte om in te grijpen en het probleem tegen betaling op te lossen.

















Je hebt ook de dynamiek van Lightning Service Providers (LSP's) zoals Breez die tussenbeide komen en zelf zorgen voor een bepaalde hoeveelheid ontvangende liquiditeit voor hun gebruikers. Dit stuit echter nog steeds op dezelfde algemene problemen als het inkopen van dingen van mensen die je kent: Breez heeft alleen zoveel geld dat ze aan hun gebruikers kunnen toewijzen om geld te ontvangen. Ze maken wel routeringsvergoedingen door het knooppunt te zijn waarmee u bent verbonden, maar uiteindelijk zullen ze het probleem tegenkomen dat ze een eindige hoeveelheid geld moeten beheren voor een groeiend gebruikersbestand. Dit is niet voor eeuwig houdbaar.

Het volgende type oplossing voor dit kernprobleem van Lightning waren echte marktplaatsen. Geen bedrijf dat u hun eigen geld verkoopt in de vorm van ontvangstcapaciteit, maar een marktplaats waar iedereen kan komen en aanbieden om ontvangende liquiditeiten te verkopen aan iedereen die het wil kopen. Twee voorbeelden van deze oplossing zijn het Lightning Lab-veilinghuis "Lightning Pool" en de Magma-marktplaatsen van Amboss. Lightning Pool handhaaft zelfs een minimale tijdsduur dat de gekochte kanalen open moeten blijven via een CLTV-tijdslot. Dit zijn beide niet-bewarende manieren voor een centrale partij (Lightning Labs en Amboss) om mensen die willen verkopen te matchen met degenen die inkomende liquiditeit willen kopen. Het probleem is dat ze nog steeds afhankelijk zijn van een gecentraliseerde facilitator om dit te laten werken. Lightning Lab's en Amboss brengen allebei een vergoeding in rekening om deel te nemen aan hun veilingen.

















Een laatste categorie oplossingen voor dit probleem wordt belichaamd door CLN's Liquidity Ads, een gedecentraliseerde marktplaats voor het ontvangen van liquiditeit die is gebouwd op dubbel gefinancierde kanalen (waar beide zijden van het kanaal liquiditeit bieden op financiering in plaats van slechts één). Liquidity Ads maakt gebruik van het roddelprotocol van het Lightning Network dat reclame maakt voor openbare kanalen die beschikbaar zijn om betalingen door te sturen, om publiekelijk advertenties te plaatsen die u bereid bent te verkopen ontvangende liquiditeit. Net als Lightning Pool dwingt het ook een "leasetijd" af waarvoor het kanaal open moet blijven met een CLTV-tijdslot aan de ketting.

Al deze verschillende opties laten dus één vraag in de lucht hangen: hoe willen we dit probleem op de lange termijn en op schaal echt aanpakken? Het is letterlijk niet mogelijk om geld te ontvangen via het Lightning Network zonder eerst liquiditeit te verwerven. Dat is een kernbeperking van het protocol zelf. Willen we dit probleem oplossen op het niveau van het protocol zelf, aangezien dat de huidige beperking is, of willen we daarvoor leunen op gecentraliseerde diensten en marktplaatsen?

Als het erop aankomt is het een kwestie van netwerkeffect, en een kip-of-ei-probleem. Kopers willen gaan waar verkopers zijn, maar verkopers willen ook gaan waar kopers zijn. Als we hard leunen op gecentraliseerde marktplaatsen of diensten om dit probleem op te lossen, zal dat netwerkeffect uiteindelijk groter worden en steeds moeilijker te overwinnen zijn met gedecentraliseerde op protocol gebaseerde alternatieven. Dit is dus een zeer belangrijke vraag die gebruikers zichzelf nu moeten stellen. Laten we deze enorme tekortkoming van de Lightning-protocolstack volledig oplossen door gecentraliseerde zakelijke services, of proberen we deze op protocolniveau zelf op te lossen?

















Persoonlijk ben ik van mening dat, gezien de behoefte aan inkomende liquiditeit absoluut vereist is om het protocol op een self-custodial manier te gebruiken, dit probleem op protocolniveau moet worden aangepakt. En als laatste opmerking: om dit op protocolniveau op een gedecentraliseerde manier op te lossen, kunnen huidige bedrijven en gecentraliseerde oplossingen nog steeds openlijk concurreren door dat protocol zelf te gebruiken.

Dit is een gastpost van Shinobi. De geuite meningen zijn geheel van henzelf en komen niet noodzakelijk overeen met die van BTC Inc of Bitcoin Magazine.