Hjem
Artikler
En guide for begyndere til Bitcoins Lightning Network

En guide for begyndere til Bitcoins Lightning Network

Begynder
Offentliggjort Nov 28, 2018Opdateret Mar 31, 2024
20m

Introduktion

Kryptovalutaer har nogle ret unikke egenskaber. De kan ikke hackes eller lukkes let ned, og alle kan bruge dem til at overfĂžre vĂŠrdier rundt om i verden uden indblanding fra tredjepart.

For at sikre, at disse funktioner bevares, mÄ der foretages betydelige afvejninger. Eftersom mange noder er ansvarlige for at drive et kryptovalutanetvÊrk, er dataoverfÞrselshastigheden begrÊnset. Som fÞlge heraf er antallet af transaktioner pr. sekund (TPS), som et blockchain-netvÊrk kan behandle, relativt lavt for en teknologi, der har til formÄl at blive vedtaget af masserne.

For at overvinde de iboende begrÊnsninger i blockchain-teknologien er der blevet foreslÄet en rÊkke skalerbarhedslÞsninger for at Þge antallet af transaktioner, som et netvÊrk kan hÄndtere. I denne artikel vil vi dykke dybt ned i Lightning Network, som er en sÄdan udvidelse af Bitcoin-protokollen.


Hvad er Lightning Network?

Lightning Network er et netvĂŠrk, der sidder oven pĂ„ en blockchain for at lette hurtige peer to peer-transaktioner. Det er ikke kun Bitcoin – andre kryptovalutaer sĂ„som Litecoin har ogsĂ„ integreret det.

Du undrer dig mÄske over, hvad vi mener med "sidder oven pÄ en blockchain". Lightning Network er det, der kaldes en off-chain- eller layer 2-lÞsning. Det giver enkeltpersoner mulighed for at foretage transaktioner uden at skulle registrere hver enkelt transaktion i blockchainen.

Lightning Network er adskilt fra Bitcoin-netvĂŠrket – det har sine egne noder og software, men det kommunikerer ikke desto mindre med main chain. For at komme ind i eller ud af Lightning Network skal du oprette sĂŠrlige transaktioner pĂ„ blockchainen.

Det, du faktisk gĂžr med din fĂžrste transaktion, er at opbygge en slags smart contract med en anden bruger. Vi kommer ind pĂ„ detaljerne om lidt – indtil videre skal du bare tĂŠnke pĂ„, at din smart contract har en privat ledger med den anden bruger. Du kan skrive mange transaktioner til denne ledger. De er kun synlige for dig og din modpart, men ingen af jer kan snyde pĂ„ grund af nogle sĂŠrlige funktioner i opsĂŠtningen.

Denne mini-ledger kaldes en kanal. Lad os sige, at Alice og Bob hver sÊtter 5 BTC i en smarte contract. I deres kanal vil de nu begge have en saldo pÄ 5 BTC. Alice kan derefter skrive betal 1 BTC til Bob i deres ledger. Nu har Bob 6 BTC pÄ sin side, og Alice har 4. Bob kan derefter sende 2 BTC tilbage til Alice pÄ et senere tidspunkt, hvilket opdaterer saldiene til 6 BTC pÄ Alices side og 4 BTC pÄ Bobs side. Det kan de fortsÊtte med at gÞre i et stykke tid.

De kan begge pÄ et hvilket som helst tidspunkt offentliggÞre den aktuelle tilstand af kanalen pÄ blockchainen. PÄ det tidspunkt tildeles saldi pÄ hver side af kanalen til deres respektive parter pÄ kÊden.

Som navnet antyder, er Lightning-transaktioner lynhurtige. Der er ingen blokbekrĂŠftelser at vente pĂ„ – betalingerne kan foretages sĂ„ hurtigt, som din internetforbindelse tillader det.


Hvorfor er Lightning Network nĂždvendigt?

Indtil videre ser Lightning Network ud til at vĂŠre den mest fornuftige tilgang til at skalere Bitcoin-blockchainen. Det er vanskeligt at koordinere ĂŠndringer i et sĂ„ stort Ăžkosystem – der er risiko for hard forks (forgreninger) og potentielt katastrofale fejl. Med sĂ„ meget vĂŠrdi pĂ„ spil er det utroligt farligt at eksperimentere.

NÄr du flytter eksperimenterne vÊk fra blockchainen, har du meget mere fleksibilitet. Hvis noget gÄr galt, vil det ikke have nogen indvirkning pÄ det faktiske Bitcoin-netvÊrk. Layer to-lÞsningerne underminerer ikke nogen af de sikkerhedsforudsÊtninger, der har holdt protokollen i gang i over 10 Är.

Der er heller ingen forpligtelse til at skifte fra den gamle mÄde at gÞre tingene pÄ. Transaktioner pÄ kÊden fungerer fortsat som normalt for slutbrugeren, men de har nu ogsÄ mulighed for at foretage transaktioner off-chain.

Der er flere fordele ved at bruge Lightning Network. Vi vil se pÄ nogle af de vigtigste nedenfor. 


Skalerbarhed

Bitcoin-blokke oprettes ca. hvert tiende minut og kan kun rumme et vist antal transaktioner. Blokplads er en knap ressource, sÄ du skal byde mod andre brugere for at fÄ din blok inkluderet i tide. Minere er fÞrst og fremmest interesseret i at blive betalt, sÄ de vil inkludere transaktioner med hÞjere gebyrer fÞrst.

NÄr der ikke er mange brugere, der forsÞger at sende midler pÄ samme tid, er dette ikke noget problem. Du kan fastsÊtte et lavt gebyr, og du vil sandsynligvis fÄ transaktionen medtaget i den nÊste blok. Men nÄr alle udsender transaktioner samtidig, kan det gennemsnitlige gebyr stige betydeligt. I nogle fÄ tilfÊlde har det vÊret pÄ over 5 USD. PÄ hÞjdepunktet af bull-markedet i 2017 oversteg det 50 USD.

Gennemsnitligt gebyr for Bitcoin-transaktioner (i USD)

Gennemsnitligt gebyr for Bitcoin-transaktioner (i USD)


Det kan virke ubetydeligt for transaktioner, der flytter bitcoin til tusindvis af USD, men for mindre betalinger er det ikke holdbart. Hvem Þnsker at betale 3 USD for en kaffe med et gebyr pÄ 5 USD?

Med Lightning Network betaler du stadig to gebyrer – et for at Ă„bne din kanal og et andet for at lukke den. Men du og din modpart kan foretage tusindvis af transaktioner gratis, nĂ„r kanalen er Ă„ben. NĂ„r du er fĂŠrdig, skal du blot offentliggĂžre den endelige tilstand pĂ„ blockchainen.

Hvis flere brugere benytter sig af lÞsninger off-chain sÄsom Lightning Network, vil blokpladsen blive brugt mere effektivt. OverfÞrsler af lav vÊrdi og med hÞj frekvens kan foretages i betalingskanaler, mens blokplads anvendes til stÞrre transaktioner og til Äbning/lukning af kanaler. Det vil gÞre systemet tilgÊngeligt for en langt bredere brugerbase og gÞre det muligt at udvide det pÄ lang sigt.


Mikrobetalinger

Der er et minimumsbelþb af Bitcoin, som du kan sende i en transaktion – ca. 0,00000546 BTC. I skrivende stund svarer det til ca. fire cent (USD). Det er et lille belþb, men Lightning Network giver dig mulighed for at skubbe grénserne for at gennemfþre den mindste enhed, der i þjeblikket er tilgéngelig – 0,000000000001 BTC, eller en satoshi.

Lightning er meget mere attraktivt til mikrobetalinger. Gebyrerne pÄ almindelige transaktioner gÞr det upraktisk at sende smÄ belÞb pÄ main chainen. Inden for en kanal er du dog fri til at sende en brÞkdel af en brÞkdel af en bitcoin gratis.

Mikrobetalinger er velegnede til mange forskellige use cases. Nogle spekulerer i, at de kunne vÊre en levedygtig erstatning for abonnementsbaserede modeller, hvor brugerne i stedet betaler smÄ belÞb, hver gang de bruger en tjeneste.


Beskyttelse af personlige oplysninger

En anden fordel ved Lightning Network er, at det kan tilbyde brugerne en hÞj grad af fortrolighed. Parterne behÞver ikke at give deres kanaler til kende over for det bredere netvÊrk. Mens du mÄske kan se pÄ blockchainen og sige, denne transaktion har Äbnet en kanal, vil du ikke nÞdvendigvis kunne se, hvad der foregÄr inde i den. Hvis deltagerne vÊlger at gÞre deres kanal privat, vil kun de vide, hvilke transaktioner der finder sted.

Hvis Alice har en kanal med Bob, og Bob har en kanal med Carol, kan Alice og Carol sende betalinger til hinanden via Bob. Hvis Dan er forbundet med Carol, kan Alice sende betalinger til ham. Du kan forestille dig, at dette kan udvikle sig til et omfattende netvÊrk af indbyrdes forbundne betalingskanaler. I en sÄdan opsÊtning kan du ikke vÊre sikker pÄ, hvem Alice har sendt midler til, nÄr kanalen er lukket.


Hvordan fungerer Lightning Network?

Vi har forklaret, hvordan Lightning Network er baseret pÄ kanaler mellem noder pÄ et hÞjt niveau. Lad os se nÊrmere pÄ det.


Multisignaturadresser

En multisignaturadresse (eller multisig) er en adresse, som flere private keys kan bruge fra. NÄr du opretter en sÄdan, angiver du, hvor mange private keys der kan bruge midlerne, og hvor mange af disse nÞgler der skal bruges til at underskrive en transaktion. En "1 ud af 5"-ordning betyder f.eks., at fem nÞgler kan producere en gyldig signatur, og at der kun er behov for én. En "2 ud af 3"-ordning ville betyde, at ud af de tre mulige nÞgler er to af dem pÄkrÊvet for at bruge midlerne.

For at initialisere en Lightning-kanal skal deltagerne lÄse midlerne i en "2 ud af 2"-ordning. Der er kun to private keys, der kan signere, og begge er nÞdvendige for at flytte coins. Lad os nu bringe vores venner Alice og Bob tilbage til dette punkt. De vil foretage mange betalinger til hinanden i de kommende mÄneder, sÄ de beslutter sig for at Äbne en Lightning Network-kanal.

Det starter med, at de begge indsÊtter f.eks. 3 BTC hver til den fÊlles multisig-adresse. Det er vÊrd at gentage, at Bob ikke kan flytte midler fra adressen, uden at Alice er indforstÄet med det, eller omvendt. 

De kunne i princippet bare have et ark papir, der justerer saldiene pÄ hver side. Begge har en startsaldo pÄ 3 BTC. Hvis Alice Þnsker at foretage en betaling pÄ 1 BTC til Bob, hvorfor sÄ ikke bare notere, at Alice nu ejer 2 BTC, og Bob ejer 4 BTC? Saldi kan fÞlges pÄ denne mÄde, indtil de beslutter sig for at flytte midlerne ud.

Det er muligt, men hvor er det sjove ved det? Og endnu vigtigere: vil det ikke vÊre utroligt nemt for nogen at undlade at samarbejde? Hvis Alice ender med 6 BTC, og Bob ender med ingen, mister Bob intet ved at nÊgte at frigive midlerne (bortset fra, mÄske, sit venskab med Alice).


Hash Timelock-kontrakter (HTLC'er)

OvenstÄende system er kedeligt og tilbyder ikke meget mere end de nuvÊrende pÄlidelige opsÊtninger. Det bliver meget mere interessant, nÄr vi indfÞrer en mekanisme, der hÄndhÊver "kontrakten" mellem Alice og Bob. Hvis én af parterne beslutter sig for ikke at overholde reglerne, har den anden part stadig en mulighed for at fÄ sine midler ud af kanalen.

Denne mekanisme er en Hash Timelock-kontrakt (eller HTLC). Udtrykket kan lyde skrÊmmende, men det er faktisk et ret enkelt begreb at forstÄ. Den kombinerer to andre teknologier (hashlocks og timelocks) for at afhjÊlpe enhver usamarbejdsvillig adfÊrd i betalingskanalerne.

En hashlock er en betingelse for en transaktion, der betyder, at du kun kan bruge midler ved at bevise, at du kender en hemmelighed. Afsenderen hasher et stykke data og inkluderer hashet i transaktionen til modtageren. Den eneste mÄde, hvorpÄ modtageren kan bruge den, er, hvis denne leverer de originale data (hemmeligheden), der passer til hash-koden. Og den eneste mÄde, hvorpÄ modtageren kan levere disse data, er, hvis denne har fÄet dem af afsenderen.

En timelock (tidslÄs) er en tilstand, der forhindrer dig i at bruge midler fÞr et bestemt tidspunkt. Det er enten angivet som et faktisk tidspunkt eller en specificeret block height.

HTLC'er oprettes ved at kombinere hashlocks og timelocks. I praksis kan HTLC'er bruges til at skabe betingede betalinger – modtageren skal afgive en hemmelighed inden et bestemt tidspunkt, ellers kan afsenderen krĂŠve midlerne tilbage. Denne nĂŠste del kan nok bedre forklares med et eksempel, sĂ„ lad os vende tilbage til Alice og Bob.


Åbning og lukning af kanaler

Vi gav et eksempel med Alice og Bob, som netop har oprettet transaktioner, der finansierer den multisignaturadresse, som de vil dele. Men disse transaktioner er endnu ikke offentliggjort i blockchainen! Vi er nĂždt til fĂžrst at gĂžre en ting mere.

Tre coins fra Bob og tre coins fra Alice.

Tre coins fra Bob og tre coins fra Alice.


Husk, at den eneste mÄde, hvorpÄ disse coins kan flyttes ud af multisig-systemet, er, hvis bÄde Alice og Bob underskriver en transaktion i fÊllesskab. Hvis Alice Þnsker at sende alle seks coins til en ekstern adresse, skal hun have Bobs godkendelse. Hertil skal hun fÞrst lave en transaktion (seks bitcoins til denne adresse) og tilfÞje sin egen underskrift. 

Hun kan forsĂžge at sende transaktionen med det samme, men den vil vĂŠre ugyldig, fordi Bob ikke har underskrevet den. Alice skal fĂžrst give ham den ufuldstĂŠndige transaktion. NĂ„r han tilfĂžjer sin underskrift, bliver den gyldig.

Vi har stadig ikke indfÞrt en mekanisme, der sikrer, at alle spiller Êrligt. Som vi sagde tidligere, er dine midler reelt fanget i en fÊlde, hvis din modpart nÊgter at samarbejde. Lad os kigge pÄ den mekanisme, der forhindrer dette. Der er et par forskellige bevÊgelige dele, sÄ vÊr tÄlmodig.

Hver part skal finde pĂ„ en hemmelighed – lad os bare kalde dem A'er og B'er. Det ville vĂŠre dĂ„rlige hemmeligheder, hvis Alice og Bob afslĂžrede dem, sĂ„ de holder dem skjult indtil videre. Parret vil generere de respektive hemmeligheders hashes – h(A'er) og h(B'er). SĂ„ i stedet for at dele deres hemmeligheder deler de disse hashes med hinanden.

Alice og Bob deler hashes af deres hemmeligheder med hinanden.

Alice og Bob deler hashes af deres hemmeligheder med hinanden.


Alice og Bob skal ogsÄ oprette et sÊt af forpligtelsestransaktioner, fÞr de offentliggÞr deres fÞrste transaktioner til multisignaturadressen. Det vil give dem et middel, hvis den anden part beslutter sig for at holde midlerne som gidsler.

Hvis du tÊnker pÄ en kanal som den mini-ledger, vi nÊvnte tidligere, sÄ er forpligtelsestransaktioner de opdateringer, som du foretager i din ledger. Hver gang du opretter et nyt par forpligtelsestransaktioner, afbalancerer du midlerne mellem de to deltagere igen.

Alices vil have to udgange – en, der betaler en adresse, hun ejer, og en anden, der er lĂ„st i en ny multisig-adresse. Hun underskriver den og giver den til Bob.

Alices transaktion med to udgange – en til hendes egen adresse og en til en ny multisig-adresse. Hun har stadig brug for Bobs underskrift for at gþre den gyldig.

Alices transaktion med to udgange – en til hendes egen adresse og en til en ny multisig-adresse. Hun har stadig brug for Bobs underskrift for at gþre den gyldig.


Bob gþr det samme – det ene output betaler sig selv, den anden betaler en anden multisig-adresse. Han underskriver den og giver den til Alice.

Vi har to ufuldstĂŠndige transaktioner, der ligner hinanden meget.

Vi har to ufuldstĂŠndige transaktioner, der ligner hinanden meget.


Normalt kan Alice fÞje en signatur til Bobs transaktion for at gÞre den gyldig. Men du vil bemÊrke, at disse midler bruges fra en "2 ud af 2"-multisig, som vi endnu ikke har finansieret. Det svarer lidt til at forsÞge at bruge en check fra en konto, der har nul saldo i Þjeblikket. Derfor vil disse delvist signerede transaktioner fÞrst kunne anvendes, nÄr multisig-systemet er i gang. 

De nye multisignaturadresser (hvortil de 3 BTC-outputs er bestemt) har nogle sÊrlige egenskaber. Lad os se pÄ den ufuldstÊndige transaktion, som Alice underskrev og gav til Bob. Multisig-outputtet kan bruges under fÞlgende betingelser:

  1. Begge parter kan underskrive den i fĂŠllesskab.

  2. Bob kan selv bruge den efter et vist tidsrum (pÄ grund af vores tidslÄs).

  3. Alice kan bruge den, hvis hun kender Bobs Bs-hemmelighed.

For den transaktion, som Bob gav til Alice:

  1. Begge parter kan underskrive den i fĂŠllesskab.

  2. Alice kan selv bruge den efter et vist tidsrum.

  3. Bob kan bruge den, hvis han kender Alices Bs-hemmelighed.

Husk pÄ, at ingen af parterne kender den andens hemmelighed, sÄ 3) er endnu ikke en mulighed. En anden ting at bemÊrke er, at hvis du underskriver en transaktion, kan din modpart bruge midlerne med det samme, fordi der ikke er nogen sÊrlige betingelser for deres udgang. Du kan enten vente pÄ, at tidslÄsen udlÞber for at bruge midlerne selv, eller du kan samarbejde med den anden part om at bruge dem direkte.

Okay! Nu kan du offentliggÞre transaktionerne i den oprindelige "2 ud af 2"-multisignaturadresse. Omsider er det sikkert at gÞre det, fordi du kan fÄ dine midler tilbage, hvis din modpart forlader kanalen.

NÄr transaktionerne er bekrÊftet, er kanalen i gang. Det fÞrste par transaktioner viser den aktuelle status for din mini-ledger. I Þjeblikket udbetaler den 3 BTC til Bob og 3 BTC til Alice. 

NĂ„r Alice Ăžnsker at foretage en ny betaling til Bob, opretter parret to nye transaktioner, som erstatter det fĂžrste sĂŠt. Det er det samme som fĂžr – de er kun halvt underskrevet. Alice og Bob skal dog fĂžrst opgive deres gamle hemmeligheder og udveksle nye hashes for den nĂŠste transaktionsrunde.

Hvis Alice f.eks. Þnsker at betale 1 BTC til Bob, vil de to nye transaktioner kreditere 2 BTC til Alice og 4 BTC til Bob. PÄ denne mÄde opdateres saldoen.

 Hvis Alice f.eks. Þnsker at betale 1 BTC til Bob, vil de to nye transaktioner kreditere 2 BTC til Alice og 4 BTC til Bob. PÄ denne mÄde opdateres saldoen.


Begge parter kan til enhver tid underskrive og udsende én af de seneste transaktioner for at "afvikle" den pÄ blockchainen. Men den part, der gÞr det, skal vente, indtil tidsfristen er udlÞbet, mens den anden part kan bruge midlerne med det samme. Husk, at hvis Bob underskriver og udsender Alices transaktion, har hun nu et output uden betingelser.

Begge parter kan blive enige om at lukke kanalen sammen (en fÊlles lukning). Dette er sandsynligvis den nemmeste og hurtigste mÄde til at fÄ dine midler tilbage i kÊden. Men selv hvis den ene part ikke reagerer eller nÊgter at samarbejde, kan den anden part stadig krÊve sine midler tilbage ved at afvente tidsfristen.



Hvordan forhindrer Lightning Network snyd?

Du har mÄske identificeret en angrebsvektor her. Hvis Bob i Þjeblikket har en saldo pÄ 1 BTC, hvad forhindrer ham sÄ i at udsende en Êldre transaktion, hvor han havde mere? Han har allerede fÄet den halvt underskrevne transaktion fra Alice, sÄ han skal bare tilfÞje sin underskrift og sende den, ikke sandt?

Der er intet, der forhindrer ham i at gþre det – bortset fra, at han kan miste hele saldoen. Lad os sige, at han gennemfþrer den og sender en gammel transaktion, der betaler en coin til Alice og fem til den multisig-adresse, som vi névnte tidligere.

Alice modtager sin coin med det samme. Bob skal derimod vente, indtil tidslĂ„sen udlĂžber, for at bruge fra den multisig-adresse. Kan du huske den anden betingelse, som vi nĂŠvnte, og som ville give Alice mulighed for at bruge de samme midler med det samme? Hun har brug for en hemmelighed, som hun ikke havde dengang. Det har hun nu – sĂ„ snart den anden runde af transaktioner blev oprettet, afslĂžrede Bob denne hemmelighed.

Mens Bob sidder og ikke kan gÞre noget, mens han venter pÄ, at tidslÄsen udlÞber, kan Alice flytte disse midler. Denne straffebaserede mekanisme betyder, at deltagerne sandsynligvis ikke vil forsÞge at snyde, fordi brugeren vil fÄ adgang til deres coins.


Routing af betalinger

Vi har berĂžrt dette tidligere – kanaler kan forbindes. I modsat fald ville Lightning Network ikke vĂŠre sĂ„ nyttigt til betalinger. Vil du virkelig lĂ„se 500 USD i en kanal med en kaffebar, bare for at du kan fĂ„ dit daglige fix i de nĂŠste par mĂ„neder?

Det behÞver du ikke at gÞre. Hvis Alice Äbner en kanal med Bob, og Bob allerede har en kanal med Carol, kan Bob videresende betalinger mellem de to. Dette kan fungere pÄ tvÊrs af flere "hop", hvilket betyder, at Alice kan betale alle, som der findes en vej til.

I dette scenarie kan Alice gÄ flere veje for at komme til Frank. I praksis tager hun altid den letteste af dem.

I dette scenarie kan Alice gÄ flere veje for at komme til Frank. I praksis tager hun altid den letteste af dem.


MellemmÊnd kan tage et lille gebyr for deres rolle i routing (men det er der ingen forpligtelse til). Lightning Network er stadig meget nyt, sÄ der er endnu ikke opstÄet et marked for gebyrer. Mange forventer at se gebyrer baseret pÄ den leverede likviditet. 

PĂ„ basiskĂŠden er dit gebyr udelukkende baseret pĂ„ den plads, din transaktion fylder i en blok – vĂŠrdien, der overfĂžres, er ligegyldig – betalinger for henholdsvis 1 USD og 10.000.000.000 USD koster det samme. Derimod er der ikke noget, der hedder blokplads i Lightning Network. 

I stedet er der ideen om lokale og eksterne saldi. Den lokale saldo er det belĂžb, som du kan "skubbe" til den anden ende af kanalen, mens den eksterne saldo er det belĂžb, som din modpart kan skubbe til dig.

Det er tid til et andet eksempel. Lad os se nÊrmere pÄ én af de ovennÊvnte stier: Alice <> Carol <> Frank.

Brugernes saldo fĂžr og efter en overfĂžrsel af 0,3 BTC fra Alice til Frank.

Brugernes saldo fĂžr og efter en overfĂžrsel af 0,3 BTC fra Alice til Frank.


Alice < > Carol og Carol <> Frank har hver en samlet kapacitet pÄ 1 BTC. Alices lokale saldo er 0,7 BTC. Hvis de afregnede pÄ blockchainen nu, ville hun modtage 0,7 BTC, og Carol ville modtage den eksterne saldo (dvs. 0,3 BTC).

Hvis Alice Ăžnsker at sende 0,3 BTC til Frank, skubber hun 0,3 BTC til Carols side af kanalen. Carol skubber derefter 0,3 BTC fra sin lokale saldo ind i kanalen med Frank. Som fĂžlge heraf forbliver Carols saldo den samme: +0,3 BTC fra Alice og -0,3 BTC til Frank udligner hinanden.

Carol mister ikke vĂŠrdi ved at fungere som en forbindelse mellem Frank, men hun gĂžr sig selv mindre fleksibel. Hun kan nu bruge 0,6 BTC i sin kanal med Alice, men kun 0,1 BTC i kanalen med Frank.

Du kan forestille dig en situation, hvor Alice kun er forbundet med Carol, mens Frank er forbundet med et meget bredere netvĂŠrk. Carol kunne tidligere sende i alt 0,4 BTC til andre via Frank, men nu kan hun kun skubbe 0,1 BTC, fordi det er alt, hvad hun har i sin ende af kanalen.

I dette scenarie Êder Alice sig reelt set ind pÄ Carols likviditet. Uden nogen form for incitament Þnsker Carol mÄske ikke at svÊkke sin egen position. SÄ i stedet kan hun mÄske bare sige: Jeg videresender hver 0,01 BTC til et gebyr pÄ ti satoshis. PÄ den mÄde fÄr Carol mere ud af sine lokale saldi. Jo mere hun ofrer pÄ "stÊrkere" veje, jo mere tjener hun.

Som tidligere nÊvnt er der ikke noget de facto-krav om at opkrÊve et gebyr. Nogle vil mÄske ikke vÊre bekymrede over den reducerede likviditet. Andre Äbner mÄske bare kanaler direkte til modtageren.


BegrĂŠnsninger ved Lightning-netvĂŠrket

Det ville vÊre fantastisk, hvis Lightning Network viste sig at vÊre lÞsningen pÄ alle Bitcoins problemer med skalerbarhed. DesvÊrre har det sine egne mangler, som kan stÄ i vejen. 


Anvendelighed

Bitcoin er ikke det mest intuitive system for nybegyndere – adresser, gebyrer osv. kan vĂŠre forvirrende at sĂŠtte sig ind i. Men wallets kan abstrahere fra de komplicerede ting og give brugerne noget, der ligner de eksisterende betalingssystemer meget svagt. Du kan fĂ„ nogen til at downloade en smartphone-wallet, sende dem coins, og sĂ„ er de klar.

Indtil videre er det ikke muligt med Lightning Network. Mulighederne er begrÊnsede, nÄr det kommer til smartphone-apps. Generelt krÊver Lightning-noder adgang til en Bitcoin-node for at vÊre fuldt anvendelige.

NÄr en klient er oprettet, skal brugerne ogsÄ begynde at Äbne kanaler, fÞr de kan foretage betalinger. Dette kan vÊre en tidskrÊvende proces, og det kan vÊre overvÊldende, nÄr en nybegynder skal introduceres til begreber sÄsom indgÄende/udgÄende kapacitet.

NĂ„r det er sagt, foretages der hele tiden forbedringer for at reducere adgangsbarriererne og give brugerne en mere strĂžmlinet oplevelse.


Likviditet

Ét af de stĂžrste kritikpunkter af Lightning Network er, at din mulighed for at gennemfĂžre transaktioner er begrĂŠnset. Du kan ikke bruge mere, end du har lĂ„st fast i en kanal. Hvis du bruger alle dine midler, sĂ„ledes at den eksterne saldo har alle kanalens midler, bliver du nĂždt til at lukke den kanal. Alternativt kan du vente, indtil nogen betaler dig gennem den, men det er ikke ideelt.

Dine veje kan ogsÄ vÊre begrÊnsede af kanalens samlede kapacitet. Tag eksemplet Alice < > Carol < > Frank fra tidligere. Hvis Alice og Carol har en kapacitet pÄ 5 BTC i deres kanal, men Carol og Frank kun har en kapacitet pÄ 1 BTC, kan Alice aldrig sende mere end 1 BTC. Selv da skulle hele saldoen vÊre pÄ Carols side af kanalen Carol <> Frank, for at det kunne fungere. Dette kan i hÞj grad begrÊnse den mÊngde midler, der kan overfÞres via Lightning Network-kanaler, og det har sÄledes en afsmittende virkning pÄ brugervenligheden.


Centraliserede hubs

PÄ grund af det problem, der er nÊvnt i det foregÄende afsnit, er der en vis bekymring for, at netvÊrket vil gÞre det lettere at skabe massive "hubs". Det vil sige store, stÊrkt forbundne enheder med en masse likviditet. Eventuelle betydelige betalinger vil skulle gÄ gennem nogle af disse enheder.

Det ville naturligvis ikke vÊre en god situation. Det ville svÊkke systemet, da disse enheder, der gÄr offline, i hÞj grad ville forstyrre relationerne mellem brugerne. Der er ogsÄ en Þget risiko for censur, da der kun er fÄ punkter, som transaktionerne strÞmmer igennem.


Den nuvĂŠrende tilstand af Lightning Network

Pr. marts 2022 ser Lightning Network sundt ud. Der er mere end 35.000 online noder, mere end 85.000 aktive kanaler og lidt over 3.570 BTC i kapacitet.

Global distribution af Lightning Network-noder. Kilde: explorer.acinq.co

Global distribution af Lightning Network-noder. Kilde: explorer.acinq.co


Der findes en hĂ„ndfuld forskellige nodeimplementeringer – Blockstreams c-lightning, Lightning Labs' Lightning Network Daemon og ACINQ's Eclair er nogle af de mest populĂŠre. For brugere, der er mindre teknisk interesserede, tilbyder mange virksomheder plug-and-play-noder. Det eneste, du skal gĂžre med disse, er at tĂŠnde for enheden, og sĂ„ er du klar til at komme i gang med Lightning-netvĂŠrket.


Sammenfatning

Siden lanceringen af dets mainnet i 2018 har Lightning Network oplevet en imponerende vĂŠkst, selvom mange mener, at det stadig vil vĂŠre i beta.

Der er stadig nogle hindringer for brugervenligheden, der skal overvindes, da det i Þjeblikket krÊver en vis grad af teknisk viden at betjene en Lightning-node. Men med den udvikling, der finder sted, kan vi meget vel se, at adgangsbarriererne med tiden bliver reduceret. 

Hvis problemerne kan lĂžses, kan Lightning Network blive en integreret del af Bitcoin-Ăžkosystemet og i hĂžj grad Ăžge skalerbarheden og transaktionshastigheden.