Innledning
Kryptovalutaer har noen ganske unike egenskaper. Det er ikke lett å hacke eller stenge dem, og hvem som helst kan bruke dem til å overføre verdi rundt om i verden uten innblanding fra en tredjepart.
For at disse egenskapene skal opprettholdes, må det gjøres store kompromisser. Ettersom mange noder deler på ansvaret med å drive et kryptovalutanettverk, blir gjennomstrømningen begrenset. Resultatet er at antall transaksjoner per sekund (TPS) som et blokkjedenettverk kan behandle, er relativt lavt med tanke på at teknologien tar sikte på masseinnføring.
For å overvinne de iboende begrensningene i blokkjedeteknologien har det blitt foreslått en rekke skalerbarhetsløsninger for å øke antall transaksjoner som et nettverk kan håndtere. I denne artikkelen ser vi nærmere på Lightning Network, som er en slik utvidelse av Bitcoin-protokollen.
Hva er Lightning Network?
Lightning Network er et nettverk som ligger over en blokkjede for å legge til rette for raske peer-to-peer-transaksjoner. Det er ikke eksklusivt for Bitcoin – andre kryptovalutaer, som Litecoin, har også integrert det.
Du lurer kanskje på hva vi mener med «ligger over en blokkjede». Lightning Network er det som kalles en løsning utenfor kjeden eller lag 2-løsning. Det gjør at man kan drive handel uten å måtte registrere alle transaksjonene på blokkjeden.
Lightning Network er adskilt fra Bitcoin-nettverket – det har egne noder og programvare, men det kommuniserer fortsatt med hovedkjeden. For å gå inn eller ut av Lightning Network må du opprette spesielle transaksjoner på blokkjeden.
Det du faktisk gjør med den første transaksjonen, er å bygge en slags smart kontrakt sammen med en annen bruker. Vi kommer snart inn på detaljene, men foreløpig holder det å vite at den smarte kontrakten har en slags privat hovedbok sammen med den andre brukeren. Du kan skrive mange transaksjoner i denne hovedboken. De er bare synlige for deg og motparten, men det er ikke mulig for noen av dere å jukse på grunn av visse unike funksjoner i oppsettet.
Denne minihovedboken kalles en kanal. Sett at Anne og Benjamin setter inn 5 BTC hver i den smarte kontrakten. I kanalen deres har begge nå en saldo på 5 BTC. Anne kan deretter skrive til hovedboken at hun betaler 1 BTC til Benjamin. Nå har Benjamin 6 BTC, og Anne har 4. Deretter kan Benjamin sende 2 BTC tilbake til Anne senere, og så oppdateres saldoene til 6 BTC hos Anne, og 4 BTC hos Benjamin. Dette kan de fortsette med en stund.
En av dem kan når som helst publisere den nåværende tilstanden til kanalen på blokkjeden. Da blir saldoene på hver side av kanalen fordelt på hver av dem på kjeden.
Lightning-transaksjoner er lynraske, slik navnet tilsier. Det er ingen blokkbekreftelser man må vente på – betalingene kan gjøres så raskt som internettforbindelsen din tillater.
Hvorfor er Lightning Network nødvendig?
Hittil ser Lightning Network (eller ganske enkelt LN) ut til å være den mest fornuftige metoden for å skalere Bitcoin-blokkjeden. Det er vanskelig å koordinere endringer i et så stort økosystem – det er en risiko for hard forks og potensielt katastrofale feil. Ettersom så mye verdi står på spill, er det utrolig farlig å eksperimentere.
Når man flytter eksperimenteringen bort fra blokkjeden, får man mye mer fleksibilitet. Hvis noe går galt, får det ingen innvirkning på selve Bitcoin-nettverket. Lag 2-løsninger undergraver ikke noen av sikkerhetsforutsetningene som har holdt protokollen i gang i 10+ år.
Det er heller ingen krav om at man må gå bort fra den gamle måten å gjøre ting på. Transaksjoner på kjeden fortsetter å fungere som normalt for sluttbrukeren, men de har nå muligheten til å utføre transaksjoner utenfor kjeden også.
Det finnes flere fordeler med å bruke Lightning Network. Vi skal se på noen av de viktigste nedenfor.
Skalerbarhet
Det lages en ny Bitcoin-blokk omtrent hvert tiende minutt, og den kan bare inneholde et visst antall transaksjoner. Blokkplass er en knapp ressurs, så du må by mot andre brukere for å få transaksjonen din inkludert i tide. Minerne er først og fremst opptatt av å få betalt, så de tar med transaksjoner med høyere gebyrer først.
Men når det ikke er mange brukere som prøver å sende penger samtidig, er ikke dette egentlig noe problem. Da kan du angi et lavt gebyr, og du får sannsynligvis inkludert transaksjonen din i neste blokk. Men når alle kringkaster transaksjoner samtidig, kan gjennomsnittsgebyret stige mye. Det har passert USD 5 et par ganger. Og på høyden av bull-markedet i 2017 gikk det faktisk over USD 50.
Gjennomsnittlig Bitcoin-transaksjonsgebyr (i USD)
Dette kan virke ubetydelig for transaksjoner der Bitcoin for tusenvis av dollar flyttes, men for mindre betalinger er det ikke bærekraftig. Finnes det noen som vil betale et gebyr på 50 kr for en kaffe som koster 30 kr?
Med Lightning Network betaler du fortsatt to gebyrer – ett for å åpne kanalen, og et nytt for å stenge den. Men du og motparten kan foreta tusenvis av gratis transaksjoner så lenge kanalen er åpen. Når dere er ferdige, trenger dere bare å publisere den endelige tilstanden på blokkjeden.
I det store bildet blir det også slik at hvis flere brukere benytter løsninger utenfor kjeden, som Lightning Network, kommer blokkplassen til å bli brukt mer effektivt. Overføringer med lav verdi og hyppig frekvens kan utføres i betalingskanaler, mens blokkplassen brukes til større transaksjoner og åpning/stenging av kanaler. På denne måten blir systemet tilgjengelig for en mye bredere brukerbase, slik at det kan oppskaleres i det lange løp.
Mikrobetalinger
Det er et minimumsbeløp av Bitcoin du kan sende i en transaksjon – cirka 0,00000546 BTC. Da dette ble skrevet, tilsvarte det omtrent 40 øre. Det er et lite beløp, men Lightning Network lar deg presse grensene ytterligere, slik at du kan handle med den minste enheten som er tilgjengelig for øyeblikket – 0,00000001 BTC, eller én satoshi.
Lightning er mye mer attraktivt for mikrobetalinger. Gebyrene på regelmessige transaksjoner gjør det upraktisk å sende bittesmå beløp på hovedkjeden. Men innenfor en kanal kan du fritt sende en brøkdels brøkdel av en Bitcoin gratis.
Mikrobetalinger egner seg for mange bruksområder. Noen spekulerer i om de kan være en god erstatning for abonnementsbaserte modeller – at brukerne heller betaler små beløp hver gang de bruker en tjeneste.
Personvern
En annen fordel med Lightning Network er at det kan tilby brukerne en høy grad av konfidensialitet. Partene trenger ikke å gjøre kanalen kjent for det bredere nettverket. Selv om du kanskje kan se på blokkjeden at denne transaksjonen åpnet en kanal, vet du ikke nødvendigvis hva som skjer inni den. Hvis deltakerne velger å gjøre kanalen privat, er det bare de selv som får vite hvilke transaksjoner som skjer.
Hvis Anne har en kanal med Benjamin, og Benjamin har en kanal med Caroline, kan Anne og Caroline sende betalinger til hverandre via Benjamin. Hvis Dan er koblet til Caroline, kan Anne sende betalinger til han. Forestill deg at dette utvides til et omfattende nettverk av sammenkoblede betalingskanaler. I et slikt oppsett kan du ikke vite hvem Anne har sendt penger til, når kanalen stenges.
Hvordan fungerer Lightning Network?
Vi har forklart generelt hvordan Lightning Network benytter kanaler mellom noder. La oss nå ta en nærmere titt på det.
Multisignaturadresser
En multisignatur (eller multisig)-adresse er en adresse som flere private nøkler kan bruke penger fra. Når du oppretter en slik, angir du hvor mange private nøkler som kan bruke pengene, og hvor mange av disse nøklene som kreves for å signere en transaksjon. For eksempel betyr 1-av-5-oppsett at det er fem nøkler som kan produsere en gyldig signatur, og at det bare kreves én. Ved 2-av-3 er det tre mulige nøkler, og to kreves for å bruke pengene.
For å starte en Lightning-kanal låser deltakerne penger i et 2-av-2-opplegg. Det er bare to private nøkler som kan signere, og begge kreves for å flytte mynter. La oss ønske vennene våre, Anne og Benjamin, velkommen tilbake. De skal betale mye til hverandre de neste månedene, så de åpner en Lightning Network-kanal.
Dette starter med at begge setter inn 3 BTC hver i multisig-adressen, som de har delt eierskap av. Det er verdt å gjenta at Benjamin ikke kan flytte penger ut av adressen uten at Anne samtykker, og omvendt.
Men de kunne jo bare hatt et papirark for å justere saldoen på hver sin side. Begge har en startsaldo på 3 BTC. Hvis Anne vil betale 1 BTC til Benjamin, hvorfor ikke bare notere seg at Anne nå eier 2 BTC og Benjamin eier 4 BTC? Saldoene kan loggføres på denne måten helt frem til de bestemmer seg for å flytte ut pengene.
Det er mulig, men det er vel ikke så moro? Og enda viktigere: Ville ikke det gjøre det utrolig enkelt for en person å nekte å samarbeide? Hvis Anne ender opp med 6 BTC og Benjamin med ingen, taper ikke Benjamin noe på å nekte å frigjøre pengene (bortsett fra vennskapet med Anne).
Hash Timelock Contracts (HTLC)
Systemet ovenfor er kjedelig og tilbyr ikke så mye ekstra i forhold til vanlige opplegg som krever tillit. Det blir mye mer interessant når vi introduserer en mekanisme som håndhever «kontrakten» mellom Anne og Benjamin. Hvis en av partene bestemmer seg for ikke å følge reglene, har den andre fortsatt mulighet til å få ut pengene sine fra kanalen.
Denne mekanismen er en Hash Timelock Contract (eller HTLC / hash-tidslåskontrakt). Begrepet høres kanskje litt skremmende ut, men det er faktisk ganske enkelt å forstå. Det kombinerer to andre teknologier (hashlocks og timelocks) som et tiltak mot lite samarbeidsvillig adferd i betalingskanaler.
En hashlock (hash-lås) er en betingelse for en transaksjon som angir at du bare kan bruke penger ved å bevise at du kjenner til en hemmelighet. Avsenderen hasher et stykke data og inkluderer hashen i transaksjonen til mottakeren. Den eneste måten mottakeren kan bruke dem på, er om mottakeren oppgir de originale dataene (hemmeligheten) som samsvarer med hashen. Og den eneste måten disse dataene kan skaffes på, er at avsenderen oppgir dem.
En timelock (tidslås) er en betingelse som hindrer deg i å bruke pengene før det har gått en viss tid. Den angis enten som en faktisk tid eller som en spesifisert blokkhøyde.
HTLC-er opprettes ved å kombinere hashlocks og timelocks. I praksis kan HTLC-er brukes til å opprette betingede betalinger – mottakeren må oppgi en hemmelighet innen en viss tid, eller så kan avsenderen kreve tilbake pengene. Denne neste delen er sannsynligvis lettere å forstå ved hjelp av et eksempel, så vi går tilbake til Anne og Benjamin.
Åpning og stenging av kanaler
I eksemplet hadde Anne og Benjamin nettopp opprettet transaksjoner som finansierer multisignaturadressen de skal dele. Men disse transaksjonene er ikke publisert på blokkjeden ennå! Det er én ting til vi må gjøre først.
Tre mynter fra Benjamin og tre mynter fra Anne.
Husk at den eneste måten disse myntene kan flyttes ut av multisig-en på, er hvis både Anne og Benjamin signerer en transaksjon i fellesskap. Hvis Anne vil sende alle de seks myntene til en ekstern adresse, trenger hun godkjenning fra Benjamin. Hun setter da først sammen en transaksjon (6 bitcoin til denne adressen) og legger inn sin egen signatur.
Hun kan prøve å kringkaste transaksjonen med en gang, men den ville være ugyldig fordi Benjamins signatur ikke er med. Anne må gi ham den ufullstendige transaksjonen først. Når han legger til signaturen sin, blir den gyldig.
Vi har altså fortsatt ikke en mekanisme som sikrer at alle opptrer ærlig. Som sagt er det slik at hvis motparten nekter å samarbeide, er pengene i praksis fanget. La oss se på mekanismen som hindrer dette. Det er noen forskjellige brikker i bevegelse her, så vær tålmodig med oss.
Hver av partene må finne på en hemmelighet – vi kan bare kalle disse As og Bs. De ville vært dårlige hemmeligheter hvis Anne og Benjamin avslørte dem, så vi holder dem skjult inntil videre. Paret genererer de respektive hemmelighetenes hasher – h(As) og h(Bs). Så istedenfor å dele hemmelighetene, deler de disse hashene med hverandre.
Anne og Benjamin deler hashene av hemmelighetene sine med hverandre.
Anne og Benjamin må også lage et sett med forpliktelsestransaksjoner før de publiserer sine første transaksjoner til multisignaturadressen. Dette gir dem en utvei i tilfelle den andre bestemmer seg for å holde pengene som gissel.
Hvis du tenker på en kanal som minihovedboken vi snakket om tidligere, er forpliktelsestransaksjoner oppdateringene du gjør i hovedboken. Hver gang du oppretter et nytt par med forpliktelsestransaksjoner, oppdaterer du saldoen på pengene mellom de to deltakerne.
Anne sin har to utdata – én som betaler en adresse hun eier, og en annen som låses til en ny multisig-adresse. Hun signerer den og gir den til Benjamin.
Annes transaksjon med to utdata – én til egen adresse, og én til en ny multisig. Hun trenger fortsatt Benjamins signatur for at den skal være gyldig.
Benjamin gjør det samme – én utdata for å betale seg selv, mens den andre betaler til en annen multisig-adresse. Han signerer den og gir den til Anne.
Vi har to ufullstendige transaksjoner som er veldig like.
Vanligvis kan Anne legge til en signatur i Benjamins transaksjon for å gjøre den gyldig. Men du ser at disse pengene blir brukt fra en 2-av-2-multisig som vi ikke har finansiert ennå. Det er litt som å prøve å bruke en sjekk fra en konto som foreløpig har null i saldo. Derfor er disse delvis signerte transaksjonene bare brukbare når multisigen er oppe og går.
De nye multisignaturadressene (hvor de 3 BTC-utdataene havner) har noen spesielle egenskaper. La oss ta en titt på den ufullstendige transaksjonen som Anne signerte og ga til Benjamin. Multisig-utdataene kan brukes under følgende forhold:
Begge parter kan signere i fellesskap.
Benjamin kan bruke dem på egen hånd etter en viss tid (på grunn av tidslåsen).
Anne kan bruke dem hvis hun kjenner til Benjamins hemmelighet Bs.
For transaksjonen Benjamin ga til Anne, gjelder dette:
Begge parter kan signere i fellesskap.
Anne kan bruke dem på egen hånd etter en viss tid.
Benjamin kan bruke dem hvis han kjenner til Annes hemmelighet As.
Husk at ingen av partene kjenner den andres hemmelighet, så 3) er ikke mulig ennå. Noe annet som er verdt å merke seg, er at hvis du signerer en transaksjon, kan motparten bruke pengene umiddelbart fordi det ikke finnes spesielle betingelser for disse utdataene. Du kan enten vente til tidslåsen utløper, for å bruke pengene på egen hånd (uten signatur fra den andre), eller du kan samarbeide med den andre parten for å kunne bruke dem med en gang.
Greit! Nå kan du publisere transaksjonene til den originale 2-av-2-multisignaturadressen. Det er endelig trygt å gjøre det fordi du kan hente pengene dine hvis motparten forlater kanalen.
Når transaksjonene bekreftes, er kanalen oppe og går. Det første paret med transaksjoner viser oss nåværende tilstand for minihovedboken. For øyeblikket betales det ut 3 BTC til Benjamin, og 3 BTC til Anne.
Når Anne ønsker å foreta en ny betaling til Benjamin, oppretter paret to nye transaksjoner som erstatter det første settet. Opplegget er likt – de er bare halvveis signert. Men Anne og Benjamin oppgir først sine gamle hemmeligheter og bytter ut med nye hasher for neste runde med transaksjoner.
Hvis Anne for eksempel vil betale 1 BTC til Benjamin, krediterer de to nye transaksjonene 2 BTC til Anne, og 4 BTC til Benjamin. På denne måten oppdateres saldoen.
Begge partene kan signere og kringkaste en av de siste transaksjonene når som helst for å «gjøre opp» på blokkjeden. Men den parten som gjør det, må vente til tidslåsen har utløpt, mens den andre kan bruke pengene umiddelbart. Husk at hvis Benjamin signerer og kringkaster Annes transaksjon, får hun en utdata uten betingelser.
Begge partene kan bli enige om å stenge kanalen sammen (en kooperativ stenging). Dette er sannsynligvis den enkleste og raskeste måten å få pengene tilbake til kjeden på. Men selv om den ene parten ikke reagerer eller nekter å samarbeide, kan den andre fortsatt kreve tilbake pengene sine ved å vente til tidslåsen utløper.
Hvordan hindrer Lightning Network juks?
Du har kanskje identifisert en mulighet for angrep her. Hvis Benjamin for øyeblikket har en saldo på 1 BTC, hva er det som hindrer at han kan kringkaste en eldre transaksjon der han hadde mer? Han har allerede den halvsignerte transaksjonen fra Anne, så han trenger vel bare å legge til signaturen sin og kringkaste den, eller?
Det er ingenting som stopper ham fra å gjøre det – bortsett fra at han kan miste hele saldoen sin. Tenk deg at han gjennomfører dette og kringkaster en gammel transaksjon som betaler én mynt til Anne og fem til multisig-adressen vi snakket om tidligere.
Anne mottar da mynten umiddelbart. Mens Benjamin derimot må vente til tidslåsen utløper for å bruke pengene fra multisig-adressen. Husker du den andre betingelsen vi nevnte, som gjør at Anne kan bruke disse samme pengene umiddelbart? Hun trenger en hemmelighet som hun ikke hadde da. Men nå har hun den – så snart den andre runden med transaksjoner ble opprettet, oppga Benjamin hemmeligheten.
Mens Benjamin sitter der og ikke kan gjøre noe mens han venter på at tidslåsen skal utløpe, kan Anne flytte disse pengene. Denne straffbaserte mekanismen innebærer at det er usannsynlig at deltakerne i det hele tatt prøver å jukse, for da vil den andre få tilgang til myntene.
Ruting av betalinger
Vi har vært innom dette tidligere – kanaler kan kobles sammen. Ellers ville ikke Lightning Network vært så nyttig med tanke på betalinger. Ville du virkelig ha låst av 5000 kr i en kanal med en kafé bare for å få morgenkaffen din de neste månedene?
Du trenger ikke å gjøre det. Hvis Anne åpner en kanal med Benjamin og Benjamin allerede har en med Caroline, kan Benjamin rute betalinger mellom de to. Dette kan fungere på tvers av flere «hopp», noe som betyr at Anne kan betale alle som det finnes en vei til.
I dette scenarioet kan Anne gå gjennom flere ruter for å komme til Frank. I praksis tar hun alltid den enkleste.
Mellomleddene kan ta et lite gebyr for rollen de har i rutingen (selv om de ikke er forpliktet til det). Lightning Network er fortsatt veldig nytt, så det finnes ikke et gebyrmarked enda. Mange regner med at det vil komme gebyrer basert på likviditeten som tilføres.
På basiskjeden er gebyret utelukkende basert på plassen transaksjonen opptar i en blokk – verdien som overføres, spiller ingen rolle – betalinger på USD 1 og USD 10 000 000 koster like mye. Men det finnes ikke noe som heter blokkplass i Lightning Network.
Isteden benyttes ideen om lokale og eksterne saldoer. Den lokale saldoen er beløpet du kan «skyve» til den andre enden av kanalen, mens den eksterne saldoen er det som motparten kan skyve til deg.
På tide med et eksempel. La oss se nærmere på en av stiene over: Anne <> Caroline <> Frank .
Brukernes saldo før og etter en overføring på 0,3 BTC fra Anne til Frank.
Både Anne <> Caroline og Caroline <> Frank har en total kapasitet på 1 BTC. Anne sin lokale saldo er 0,7 BTC. Hvis de gjorde opp på blokkjeden nå, ville hun ha mottatt 0,7 BTC, og Caroline ville motta den eksterne saldoen (dvs. 0,3 BTC).
Hvis Anne vil sende 0,3 BTC til Frank, skyver hun 0,3 BTC til Caroline sin side av kanalen. Så skyver Caroline 0,3 BTC fra sin lokale saldo i kanalen med Frank. Resultatet er at Caroline sin saldo holder seg lik: +0,3 BTC fra Anne og -0,3 BTC til Frank utligner hverandre.
Caroline taper ikke noe på å fungere som en forbindelse til Frank, men hun gjør seg mindre fleksibel. Det er fordi hun nå kan bruke 0,6 BTC i kanalen med Anne, men bare 0,1 BTC i kanalen med Frank.
Tenk deg en situasjon der Anne bare er koblet til Caroline, mens Frank er koblet til et mye større nettverk. Caroline kunne tidligere ha sendt totalt 0,4 BTC til andre via Frank, men nå kan hun bare skyve 0,1 BTC fordi det er alt hun har på sin ende av kanalen.
I dette scenarioet benytter Anne seg av Carolines likviditet. Caroline har kanskje ikke lyst til å svekke sin egen posisjon uten å bli kompensert for det. Så kanskje hun sier: «Jeg vil rute hver 0,01 BTC mot et gebyr på 10 satoshier». Da blir det slik at jo mer av sin lokale saldo Caroline ofrer på «sterkere» baner, jo mer tjener hun.
Som nevnt finnes det ikke noe krav om å ta et gebyr. Noen bryr seg kanskje ikke om at likviditeten reduseres. Andre åpner bare kanaler direkte til mottakeren.
Begrensninger for Lightning Network
Det hadde vært fantastisk hvis Lightning Network var løsningen på alle Bitcoins skalerbarhetsproblemer. Men dessverre har nettverket sine egne mangler som kan stå i veien for det.
Brukervennligheten
Bitcoin er ikke det mest intuitive systemet for nybegynnere – adresser, gebyrer osv. kan være forvirrende å bli kjent med. Men lommebøker kan fjerne de kompliserte tingene og gi brukerne noe som ligner bittelitt på eksisterende betalingssystemer. Du kan få noen til å laste ned en lommebok for smarttelefon, sende dem mynter, og så er alt klart.
Foreløpig er ikke dette mulig med Lightning Network. Alternativene er begrenset når det gjelder smarttelefonapper – generelt krever Lightning-noder tilgang til en Bitcoin-node for å være fullt brukbare.
Etter at en klient er konfigurert, må brukerne også begynne å åpne kanaler før de kan gjennomføre betalinger. Dette kan være en tidkrevende prosess, og det kan være overveldende for nykommere med konsepter som inngående/utgående kapasitet.
Når det er sagt, gjøres det stadig forbedringer for å redusere inngangsbarrierene og for å gi brukerne en mer strømlinjeformet opplevelse.
Likviditet
En av de største kritikkene av Lightning Network er at evnen til å gjennomføre transaksjoner er begrenset. Du kan ikke bruke mer enn du har låst inn i en kanal. Hvis du bruker alle pengene dine slik at den eksterne saldoen har alle kanalens penger, må du stenge kanalen. Alternativt kan du vente til noen betaler deg gjennom den, men det er ikke ideelt.
Banene dine kan også begrenses av kanalens totalkapasitet. Ta eksemplet med Anne <> Caroline <> Frank fra tidligere. Hvis Anne og Caroline har en kapasitet på 5 BTC i kanalen, men Caroline og Frank bare har en kapasitet på 1 BTC, kan Anne aldri sende mer enn 1 BTC. Selv da må hele saldoen være på Caroline sin side av Caroline <> Frank-kanalen for at det skal fungere. Dette kan sterkt begrense pengemengden som kan sendes langs LN-kanaler, og dette får konsekvenser for brukervennligheten.
Sentraliserte huber
På grunn av problemet som ble nevnt i forrige del, er det en viss bekymring for at nettverket vil legge til rette for at det opprettes enorme «huber». Altså store, sterkt sammenkoblede enheter med mye likviditet. Alle store betalinger vil måtte rutes gjennom en av disse enhetene.
Selvfølgelig er ikke det en særlig gunstig situasjon. Det ville svekke systemet, for hvis disse enhetene koblet seg fra, ville det i stor grad forstyrre forholdet mellom brukerne. Det blir også en økt risiko for sensur, siden det bare er noen få punkter transaksjonene ville flyte gjennom.
Den nåværende tilstanden til Lightning Network
Per mars 2022 ser Lightning Network sunt ut. Det har så mange som 35 000 tilkoblede noder, 85 000+ aktive kanaler og litt over 3570 BTC i kapasitet.
Global fordeling av fulle Bitcoin-noder. Kilde: explorer.acinq.co
Det finnes noen forskjellige nodeimplementeringer – Blockstreams c-lightning, Lightning Labs' Lightning Network Daemon og ACINQs Eclair er noen av de mest populære. For brukere som er mindre teknisk anlagt, tilbyr mange selskaper plug-and-play-noder. Det eneste du må gjøre med disse, er å slå på enheten og så er du klar til å sette i gang med Lightning Network.
Avsluttende tanker
Siden lanseringen av hovednettet i 2018 har Lightning Network hatt en imponerende vekst, til tross for at mange anser det for å fortsatt være i beta.
Det er fortsatt noen hindringer knyttet til brukervennlighet som må overvinnes, ettersom det for øyeblikket krever en viss grad av teknisk kompetanse å betjene en Lightning-node. Men med mengden utvikling som er på gang, ser det ut til at inngangsbarrierene reduseres med tiden.
Hvis problemene kan løses, kan Lightning Network bli en viktig del av Bitcoin-økosystemet, noe som ville økt skalerbarheten og transaksjonshastighetene betraktelig.