Hvad er Lightning Network Inbound Capacity Problem? Komplet guide

Lynnetværks indgående kapacitet

Både hurtig vækst og tekniske forhindringer over for den mere udbredte vedtagelse af Bitcoins Lightning Network (LN) har skabt nogle produktive samtaler om, hvordan man forbedrer det unge netværk. Blandt en af ​​de forhindringer, der for nylig har fået opmærksomhed, er kendt som problemet med ‘indgående kapacitet’.

Et iboende resultat af det tovejs design af betalingskanaler i LN, problemet gør modtagelse af LN-betalinger for nye noder udfordrende, hvilket kræver flere metoder til at supplere deres indgående kapacitet. Problemet med indgående kapacitet fik almindelig anerkendelse efter stigende vanskeligheder med at modtage Lightning Torch der blev sendt mellem entusiastiske LN-brugere på Twitter.

Lynnetværks indgående kapacitet

Siden da har selve problemet og foreslåede løsninger til reduktion af komplikationerne ved det indgående kapacitetsproblem gjort sig tydeligere. Til sidst skal kompleksiteten ved kanalbalancering og emner som indgående kapacitet maskeres fra slutbrugeren, men indtil videre er det værd at evaluere, hvad problemet præcist er, og de igangværende initiativer til at løse det.

Hvad er en nodes indgående kapacitet?

Bitcoins LN består af tovejskanaler mellem brugere mellem et mesh-netværk af noder. Betalingskanalkapacitet mellem to brugere er fast, når en kanal åbnes mellem dem, og kan ikke ændres, før kanalen er lukket, og en ny er åbnet.

Betalingskanaler består af to sider, en ekstern saldo og en lokal saldo. Din side af kanalen er den lokale balance, og den anden side er den eksterne balance. Så hvis Alice og Bob har en åben betalingskanal imellem med en kapacitet på 5 BTC, og du er Bob, så er din lokale saldo 2 BTC, og fjernbalance (Alice’s balance) er 3 BTC – kanalens kapacitet er 5 BTC.

Alice 3 <————————-> 2 Bob

Alice og Bob kan opdatere balancerne inden for kanalen uden at overskride kanalens kapacitet (5 BTC), men nogle gange opstår der problemer med et tovejs kanaldesign. Hvis du vil acceptere betalinger eller afbalancere dine kanaler, kan det være vanskeligt at arbejde rundt om det tovejsdesign, især når du introducerer flere fester og betalingsvejledning i billedet.

For eksempel, hvis Charlie ønsker at modtage en betaling fra Alice, men kun har en kanal åben med Bob, er det stadig muligt for Charlie at modtage betaling fra Alice – så længe Bob har tilstrækkelig BTC til at rute til Charlie, som er Charlies fjernbetjening balance med Bob, og Bobs lokale balance med Charlie.

Alice 3 <—————-> 2 Bob 0 <—————> 2 Charlie

I eksemplet ovenfor kan Alice ikke sende Charlie nogen BTC, fordi Bobs lokale saldo (dvs. Charlies fjernbalance) er 0 BTC. Alice’s betaling hæmmes af Charlies indgående kapacitet. Så Charlies indgående kapacitet på ethvert tidspunkt under sin kanal er åben begrænses eksplicit af hans fjernbalance med modparten (i dette tilfælde Bob), der dirigerer betalingen.

I eksemplet ovenfor er Charlies indgående kapacitet nul. I eksemplet nedenfor (med 1 BTC større kanalkapacitet) ville Charlies indgående kapacitet imidlertid være en, og han kunne modtage op til 1 BTC fra Alice. Dette fremhæver, hvordan likviditet generelt er et af de største problemer for LN’s vækst, hvilket ikke er overraskende, når man betragter det som et ungt betalingsnetværk..

Alice 3 <—————-> 2 Bob 1 <—————> 2 Charlie

Problemet med indgående kapacitet skyldes, at når modparter finansierer deres kanaler, finansierer de først oprindeligt deres respektive lokale saldo. Modpartens indskud i kanalen er efterfølgende en respektive parts eksterne saldo. Som et resultat kan LN-brugere bestemme deres udgående kapacitet (som korrelerer med deres lokale saldo), men de har ikke direkte kontrol over deres indgående kapacitet.

Når du tilføjer flere forbindelser i hele netværket og routing mellem noder, kan problemet blive endnu mere indviklet. Forestil dig tusindvis af noder, der ikke er direkte forbundet, men stoler på routing-noder for at udføre betalingerne. Du har muligvis løst indgående kapacitet med en tilstødende node, men så skal du tage højde for den indgående kapacitet for en tilstødende node, der støder op til den node, og så videre osv..

En sådan dynamik kræver likviditetsudbydere, der fungerer som routing-noder, og metoder til at afbøde det indgående kapacitetsproblem hos brugere med små kanalbalancer eller dem, der er nye i netværket.

Problemet med indgående kapacitet er sandsynligvis en af ​​de primære årsager til, at Lightning Torch blev stadig sværere at passere i sine senere stadier. Da fakkelen fik værdi, blev antallet af flydende udbydere til routing af betalinger mindre, hvilket forhindrede mange brugere i at kunne modtage fakkelen – deres indgående kapacitet var ikke tilstrækkelig.

På trods af de problemer, det præsenterer, især for nye brugere, der bare starter deres noder og åbner kanaler, er der flere metoder til at øge din indgående kanalkapacitet.

Hvis du leder efter mere detaljerede oplysninger om brug af LN og indgående kapacitet, anbefaler jeg artiklerne her og her.

Løsning af problemet med indgående kapacitet

At øge din indgående kapacitet betyder at åbne kanaler og oprette forbindelse til rutekanaler med store fjernbalancer (dvs. store lokale saldi fra deres perspektiv). Balancerede og godt forbundne noder er de optimale valg til forbedring af indgående kapacitet, da de forbinder dig til mange andre offentlige noder, men det er ikke altid så simpelt for nye noder, der lanceres i økosystemet.

Heldigvis er der flere meget enkle metoder til at øge indgående kapacitet – såsom simpelthen at foretage udgående betalinger. Brug af mønter overfører dem fra din lokale saldo til din eksterne saldo. Det kræver, at du bruger mønter, men da de fleste betalinger via LN alligevel er små, er det ikke en betydelig økonomisk byrde at sende mikrobetalinger inden for forskellige kanaler og kan hjælpe med at øge din indgående kapacitet.

En anden ret ligetil metode til at øge indgående kapacitet er at bede nodeoperatører om at åbne indgående kanaler med dig. Den bedste måde at gøre dette på er med flere kanalåbningstjenester, der faktisk åbner en kanal med din node direkte – nogle gange gratis og nogle gange mod et meget lille gebyr.

Bitrefill’s Thor, LightningTo.Me, og LNBig.com er alle kanalåbningstjenester med forskellige kanalkapacitetsbetingelser og gebyrer. Sådanne tjenester er nyttige, når du starter en ny node, for eksempel hvis du har købt en Casa Node og vil begynde at modtage betalinger.

Andre tjenester, om end frihedsberøvende, tilbyder at udveksle LN BTC til on-chain BTC, hvilket grundlæggende er en anden version af at bruge LN BTC til at købe on-chain BTC. Nogle af disse tjenester inkluderer zigzag, Coinplaza, og lynkonktor. Disse tjenester er imidlertid frihedsberøvende, og en ny ikke-frihedsberøvende mulighed fra Lightning Labs kan vise sig at være et bedre alternativ – selvom det stadig er i den tidlige eksperimentfase.

Det hedder Lynsløjfe, og det er en ikke-frihedsberøvende on-chain / off-chain bro, der bruger ubådsswaps til at erhverve indgående kapacitet fra vilkårlige netværksnoder, deponere midler i on-chain tegnebøger uden at lukke en kanal eller betale til en on-chain reserveadresse, hvis likviditet er utilstrækkelig til routing.

Baseret på den første implementering fra Lightning Labs består Lightning Loop i øjeblikket kun af ‘Loop Out’-funktionaliteten, der gør det muligt at udveksle off-chain-midler til on-chain-fonde på en ikke-frihedsberøvende måde. Funktionen ‘Loop Out’ er endnu ikke tilgængelig, men vil give on-chain-midler mulighed for at øge den lokale saldo på en LN-kanal.

Konklusion

Samlet set er det indgående kapacitetsproblem mere et resultat af utilstrækkelig likviditet i et betalingsnetværk i et tidligt stadium end en central designfejl. Løsninger er allerede tilgængelige for handlende, LN-entusiaster og udviklere til at løse problemet – både enkle og nogle mere komplicerede.

Når LN fortsætter sin fremgang, vil mere åbne kanaltjenester, ikke-frihedsberøvende tjenester og UI-abstraktion af det indgående kapacitetsproblem sandsynligvis vokse i prævalens.

Mike Owergreen Administrator
Sorry! The Author has not filled his profile.
follow me