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)
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.
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 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.
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.
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:
Begge parter kan underskrive den i fællesskab.
Bob kan selv bruge den efter et vist tidsrum (på grund af vores tidslås).
Alice kan bruge den, hvis hun kender Bobs Bs-hemmelighed.
For den transaktion, som Bob gav til Alice:
Begge parter kan underskrive den i fællesskab.
Alice kan selv bruge den efter et vist tidsrum.
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.
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.
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.
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
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.