Lightning Network Inngående kapasitet

Begge hurtig vekst og tekniske hindringer for den mer utbredte adopsjonen av Bitcoins Lightning Network (LN) har skapt noen produktive samtaler om hvordan man kan forbedre det unge nettverket. Blant en av de hindringene som nylig har fått oppmerksomhet, er kjent som problemet med ‘inngående kapasitet’.

Et iboende resultat av toveis utforming av betalingskanaler i LN, gjør problemet mottak av LN-betalinger for nye noder utfordrende, og krever flere metoder for å supplere deres innkommende kapasitet. Problemet med innkommende kapasitet fikk vanlig anerkjennelse etter økende vanskeligheter med å motta lynlampen som ble sendt mellom entusiastiske LN-brukere på Twitter.

Lightning Network Inngående kapasitet

Siden den gang har selve problemet og foreslåtte løsninger for å redusere komplikasjonene ved det innkommende kapasitetsproblemet gjort seg tydeligere. Til slutt bør kompleksiteten i kanalbalansering og problemer som innkommende kapasitet maskeres fra sluttbrukeren, men foreløpig er det verdt å evaluere hva problemet er og de pågående initiativene for å løse det.

Hva er en Node’s Inbound Capacity?

Bitcoins LN består av toveis betalingskanaler mellom brukere blant et nettverk av noder. Betalingskanal kapasitet mellom to brukere er løst når en kanal er åpnet mellom dem, og kan ikke endres før etter at kanalen er stengt og en ny er åpnet.

Betalingskanaler består av to sider, en ekstern saldo og lokal saldo. Din side av kanalen er den lokale balansen, og den andre siden er den eksterne balansen. Så hvis Alice og Bob har en åpen betalingskanal mellom dem med en kapasitet på 5 BTC, og du er Bob, så er din lokale saldo 2 BTC, og den eksterne saldoen (Alice’s balance) er 3 BTC – kanalkapasiteten er 5 BTC.

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

Alice og Bob kan oppdatere balansene i kanalen uten å overskride kanalkapasiteten (5 BTC), men noen ganger oppstår problemer fra en toveis kanaldesign. Hvis du vil akseptere betalinger eller balansere kanalene dine, kan det være vanskelig å jobbe rundt den toveis designen, spesielt når du introduserer flere fester og betalingsruting i bildet.

For eksempel, hvis Charlie ønsker å motta en betaling fra Alice, men bare har en kanal åpen med Bob, er det fortsatt mulig for Charlie å motta betaling fra Alice – så lenge Bob har tilstrekkelig BTC til å rute til Charlie, som er Charlies fjernkontroll balanse med Bob, og Bobs lokale balanse med Charlie.

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

I eksemplet ovenfor kan Alice ikke sende Charlie noen BTC fordi Bobs lokale saldo (dvs. Charlies fjernbalanse) er 0 BTC. Alice’s betaling hindres av Charlies innkommende kapasitet. Så Charlies innkommende kapasitet når som helst i løpet av at kanalen er åpen, er eksplisitt begrenset av hans eksterne saldo med motparten (i dette tilfellet Bob) som dirigerer betalingen.

I eksemplet ovenfor er Charlies innkommende kapasitet null. Imidlertid, i eksemplet nedenfor (med 1 BTC større kanalkapasitet), ville Charlies innkommende kapasitet være en, og han kunne motta opptil 1 BTC fra Alice. Dette belyser hvordan likviditet generelt er et av de største problemene LNs vekst står overfor, noe som ikke er overraskende med tanke på det som et ungt betalingsnettverk..

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

Det innkommende kapasitetsproblemet oppstår fra det faktum at når motparter finansierer kanalene sine, finansierer de først sin respektive lokale saldo. Motpartens innskudd i kanalen blir deretter en respektive parts eksterne saldo. Som et resultat kan LN-brukere bestemme utgående kapasitet (som korrelerer med deres lokale saldo), men de har ikke direkte kontroll over sin innkommende kapasitet.

Når du legger til flere tilkoblinger i hele nettverket og ruting mellom noder, kan problemet bli enda mer kronglete. Tenk deg tusenvis av noder som ikke er direkte koblet, men som stoler på rutingnoder for å utføre betalingene. Du har kanskje løst inngående kapasitet med en tilstøtende node, men da må du ta hensyn til den inngående kapasiteten til en tilstøtende node som ligger ved siden av den noden, og så videre og så videre.

En slik dynamikk krever at likviditetsleverandører fungerer som rutingnoder, og metoder for å redusere det innkommende kapasitetsproblemet til brukere med små kanalbalanser eller de som er nye i nettverket.

Det innkommende kapasitetsproblemet er sannsynligvis en av de viktigste årsakene til at Lightning Torch ble stadig vanskeligere å passere i sine senere stadier. Da fakkelen fikk verdi ble antallet flytende leverandører for ruting av betalinger mindre, og forhindret dermed mange brukere fra å kunne motta fakkelen – deres innkommende kapasitet var ikke tilstrekkelig.

Til tross for problemene det presenterer, spesielt for nye brukere som bare lanserer nodene sine og åpner kanaler, er det flere metoder for å øke den innkommende kanalens kapasitet.

Hvis du leter etter mer grundig informasjon om bruk av LN og innkommende kapasitet, anbefaler jeg artiklene her og her.

Løser problemet med innkommende kapasitet

Å øke din innkommende kapasitet betyr å åpne kanaler og koble til rutekanaler med store eksterne saldoer (dvs. store lokale saldoer fra deres perspektiv). Balanserte og godt tilkoblede noder er de optimale valgene for å forbedre innkommende kapasitet, da de vil koble deg til mange andre offentlige noder, men det er ikke alltid så enkelt for nye noder som lanseres i økosystemet.

Heldigvis er det flere veldig enkle metoder for å øke innkommende kapasitet – for eksempel bare å utføre utbetalinger. Bruk av mynter overfører dem fra din lokale saldo til din eksterne saldo. Det krever at du bruker mynter, men siden de fleste betalinger via LN uansett er små, er det ikke en betydelig økonomisk byrde å sende mikrobetalinger innen forskjellige kanaler, og det kan bidra til å øke din innkommende kapasitet.

En annen ganske grei metode for å øke innkommende kapasitet er å be nodeoperatører om å åpne innkommende kanaler med deg. Den beste måten å gjøre dette på er med flere kanalåpningstjenester som faktisk vil åpne en kanal med din node direkte – noen ganger gratis og noen ganger mot en veldig liten avgift.

Bitrefill’s Thor, LightningTo.Me, og LNBig.com er alle kanalåpningstjenester med forskjellige kanalkapasitetsbetingelser og avgifter. Slike tjenester er nyttige når du starter en ny node, for eksempel hvis du kjøpte en Casa Node og vil begynne å motta betalinger.

Andre tjenester, om enn forvaring, tilbyr å bytte LN BTC til on-chain BTC, som i utgangspunktet er en annen versjon av å bruke LN BTC for å kjøpe on-chain BTC. Noen av disse tjenestene inkluderer sikksakk, coinplaza, og lynkonjunktur. Disse tjenestene er imidlertid forvaring, og et nytt alternativ for ikke-forvaring fra Lightning Labs kan vise seg å være et bedre alternativ – selv om det fremdeles er i den tidlige eksperimenteringsfasen..

Det heter Lynløkke, og det er en ikke-frihetsberøvende bro i kjeden / off-chain som bruker ubåtbytter for å tilegne seg inngående kapasitet fra vilkårlige nettverksnoder, deponere penger i lommebøker uten å lukke en kanal, eller betale til en tilbaketrekksadresse hvis likviditet er ikke tilstrekkelig for ruting.

Basert på den første implementeringen fra Lightning Labs, består Lightning Loop for øyeblikket bare av funksjonen ‘Loop Out’, som gjør det mulig å bytte off-chain-fond til on-chain-midler på en ikke-frihetsberøvende måte. Funksjonen ‘Loop Out’ er ikke tilgjengelig ennå, men vil gjøre det mulig for fond i kjeden å øke den lokale saldoen til en LN-kanal.

Konklusjon

Samlet sett er problemet med inngående kapasitet mer et resultat av utilstrekkelig likviditet i et tidlig betalingsnettverk enn en sentral designfeil. Løsninger er allerede tilgjengelig for selgere, LN-entusiaster og utviklere for å løse problemet – både enkle og noen mer kompliserte.

Når LN fortsetter sin progresjon, vil mer åpne kanaltjenester, ikke-frihetsberøvende tjenester og UI-abstraksjon av det innkommende kapasitetsproblemet sannsynligvis vokse i prevalens.

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