Fra et par uker siden, den første Lynimplementeringen – lnd – er offisielt i beta. Den andre implementeringen – eclair – fulgte forrige uke, mens den tredje – c-lyn – forventes å gjøre det snart. Som sådan er Lightning Network, det etterlengtede Bitcoin-overleggsnettverket for billige og øyeblikkelige transaksjoner, av mange av utviklerne ansett som trygge nok til å bruke på Bitcoins mainnet: en viktig milepæl for teknologien som har vært mange år i ferd med å bli.

Dette er historien så langt.

The First Musings

Den tidligste opprinnelsen til Lightning Network kan spores så langt som Bitcoin selv.

Det første stykket i Lightning-puslespillet er et konsept som kalles “betalingskanaler.” Betalingskanaler er i hovedsak bitcoin-saldoer mellom to Bitcoin-brukere, og bare to brukere: resten av verden trenger ikke å vite eller bry seg om deres gjensidige saldoer. Det er viktig at disse saldiene kan oppdateres uten at Bitcoin-transaksjoner kreves; der saldoen til en bruker øker, reduseres saldoen til den andre med samme beløp. Dette gjør at begge deltakerne kan gjøre transaksjoner mellom hverandre, uten å belaste hele nettverket med deres transaksjonsdata.

Når brukerne er ferdige med transaksjoner, kan de gjøre opp betalingskanalen ved å overføre bare en transaksjon til nettverket: den transaksjonen utbetaler til hver hva de skal motta basert på kanalbalansen. Til fordel for disse brukerne, bør dette også bety at kanaloppdateringene (“off-chain-transaksjoner”) er billigere fordi de ikke krever gruvegebyr, og er raskere fordi de ikke krever bekreftelse av blockchain.

Denne generelle ideen er uten tvil like gammel som den aller første Bitcoin-programvaren som ble utgitt av Satoshi Nakamoto i 2009. Bitcoin 0,1 inkluderte en rå utkast til kode som lar brukerne oppdatere en transaksjon før den ble bekreftet:

Et grovt utkast til betalingskanalkode inkludert i Bitcoin 0.1. Kilde: GitHub

Mens denne koden var et grovt utkast, gikk Satoshi Nakamoto nærmere inn på hvordan betalingskanaler kunne fungere i privat kommunikasjon med den gangen-bitcoinj utvikler Mike Hearn.

Flere år senere, i 2013, Hearn publisert Satoshi Nakamotos forklaring på betalingskanaler på Bitcoin-utvikling postliste:

Satoshi Nakamotos forklaring på hvordan betalingskanaler kunne fungere, beskrevet av Mike Hearn. Kilde: Bitcoin-dev-postliste

De første betalingskanalene

Selv om det generelle konseptet med betalingskanaler har eksistert så lenge Bitcoin selv, var Satoshi Nakamotos design ikke helt sikker. Viktigst, en bruker i en betalingskanal kan samarbeide med gruvearbeidere for å få en eldre transaksjon bekreftet og hevde mer bitcoin enn kanalsaldoen skulle tillate ham..

En løsning på dette problemet ble foreslått for første gang sommeren 2011, etter at Satoshi Nakamoto hadde forlatt Bitcoin-prosjektet.. Bitcointalk forum bruker “hashcoin” skissert en to-trinns betalingskanal som krevde at brukerne utvekslet flere delvis signerte multisignatur-transaksjoner og transaksjoner med tidlåser som var avhengige av hverandre for å være gyldige. Hvis den ene deltakeren skulle forsvinne, kunne den andre kreve alle midlene i betalingskanalen etter en tid. En ulempe ved dette designet var imidlertid at hashcoin sine kanaler bare kunne fungere i en retning. “Alice” kunne betale “Bob” et vilkårlig antall ganger, men Bob kunne ikke betale Alice gjennom samme kanal.

En idé som ligner på hashcoin’s dukket opp igjen tidlig i 2013, og denne gangen slapp den det teoretiske riket. I april samme år var det et betalingskanalkonsept beskrevet av Jeremy Spilman på adresselisten til Bitcoin-utvikling. Han hadde til og med kodet opp en bevis på konseptet. Dette designet ble i sin tur justert av Mike Hearn, hvoretter fremtidig Bitcoin Core-bidragsyter, Blockstream medstifter og Chaincode Labs utvikler Matt Corallo gjorde konseptet til arbeidskode for bitcoinj av midten av 2013.

Nok et år senere, i 2014, var Alex Akselrod (nå ingeniør hos Lightning Labs) den første til foreslå en toveis betalingskanal. Alice kunne betale Bob et vilkårlig antall ganger, mens Bob kunne bruke Alice innen samme kanal – om enn et begrenset antall ganger. I motsetning til enveis betalingskanaler ble denne løsningen imidlertid aldri implementert i kode.

De første betalingsnettverkskonseptene

Omtrent samtidig som de første betalingskanalene ble foreslått, andre – inkludert for eksempel Bitcoin Core-utviklere Peter Todd og Gavin Andresen – tenkte på off-chain betalingsnettverk. Hvis Alice kunne betale Bob gjennom en off-chain-transaksjon, og Bob kunne betale Carol gjennom en off-chain-transaksjon, burde Alice kunne betale Carol gjennom Bob uten å kreve noen on-chain-transaksjoner.

Corné Plooy (nå en lynutvikler på nederlandsk Bitcoin-børs BL3P) hadde også jobbet med et betalingslag for Bitcoin, som han først foreslo som en grov idé i 2011.

En tidlig illustrasjon av Plooys betalingslagsdesign, som vil utvikle seg til Lightning Network forløper Amiko Pay. Kilde: Corné Plooy

Med forslag lagt til av Bitcoin Core-utvikler og fremtidig Blockstream CTO Gregory Maxwell, og Ripple oppfinner Ryan Fugger (blant andre) utviklet denne ideen seg gjennom de år inn i en sammenslåing av Bitcoin og den opprinnelige Ripple-teknologien, noe som resulterte i system Plooy kalt “Amiko Pay.” Tidligere utkast til Amiko Pay benyttet seg ikke av betalingskanaler og injiserte derfor tillit til systemet, men hvis en bruker nekter å balansere med en annen bruker, vil sistnevnte ikke gjøre noe..

Et tidlig betalingsnettverk forslag som benyttet betalingskanaler var foreslått av matematiker og fremtid Bitcoin emBassy TLV medstifter Meni Rosenfeld sommeren 2012. På Bitcointalk-forumet beskrev Rosenfeld et system der Bob (fra ovenstående eksempel) erstattes av en betalingsprosessor, med både Alice og Carol som kunder. Betalingsprosessoren kan i sin tur også ha kanaler med andre betalingsprosessorer, med flere kunder, som gjør betalingskanalnettverket til et nav-og-talesystem.

Mens et slikt system innførte litt tillit til betalingsbehandlerne – de kunne nekte å videresende en betaling og beholde pengene i stedet – ble denne risikoen ansett som liten: trikset ville bare fungere for en betaling før en kunde ville legge merke til og stoppe ved hjelp av kanalen. I tillegg kan større betalinger kuttes i mindre trinn, slik at hvis en betalingsbehandler viste seg å være upålitelig, ville bare en liten del av betalingen gå tapt.

Denne løsningen dukket opp et par ganger gjennom årene. Bitcoin Core-bidragsyter Peter Todd, for eksempel, publisert konseptet til Bitcoin-utviklingslisten i 2014. Betalingsprosessor BitPay, i mellomtiden publisert en hvitt papir på lignende interkanalbetalinger (“Impuls”) tidlig på 2015. Og en løsning som dette faktisk ville bli implementert av den svenske oppstarten Strawpay, kalt Stroem (eller Ström), omtrent samtidig – men ingen av disse gjentakelsene tok noen gang av på en meningsfull måte.

Logoen til den nå nedlagte Strawpay-mikropayment-oppstarten. Kilde: Internet Archive

Et relativt tidlig forsøk på å etablere et pålitelig betalingskanalnettverk ble gjort av Alex Akselrod. Først beskrevet i a wiki-utkast i 2013, skal implementeres som en bevis på konseptet I løpet av 2014 gikk løsningen til Akselrod langt mot å løse problemet på et teoretisk nivå. Hovedproblemet var at det fortsatt ville være ganske klumpete i praksis. Hvis en betaling for eksempel mislyktes hvor som helst langs ruten til en transaksjon, ville en bruker for eksempel ikke ha noe annet å gjøre enn å vente til midlene ble frigjort gjennom tidslåsene for betalingskanalen, noe som potensielt kan ta måneder.

I mellomtiden hadde Plooys Amiko Pay innen 2015 utviklet seg til det punktet hvor det potensielt også kan fungere pålitelig. Imidlertid ville designet hans ha krevd relativt vidtrekkende endringer i Bitcoin-protokollen, til det punktet der det var nødvendig å rulle tilbake visse typer transaksjoner. Selv om det var teknisk mulig, var det ikke åpenbart om slike endringer i Bitcoin-protokollen ville bli vedtatt.

Senere samme år kom forskere fra det tekniske universitetet i Zürich (ETH Zürich), Dr. Christian Decker (nå i Blockstream) og Roger Wattenhofer, foreslo enda et nettverkdesign i nettboken “Et raskt og skalerbart betalingsnettverk med Bitcoin Duplex Micropayment-kanaler.”Løsningen deres baserte seg sterkt på tidslåser som en slags“ nedtellingstikker ”for betalingskanalgyldighet, som ble kombinert med et kryptografisk triks kalt et“ ugyldighetstreet ”for utløpte kanalsaldoer..

Akselrods løsning, de senere utkastene til Amiko Pay og Duplex Micropayment Channels (DMC), lignet alle på noen måte på Lightning Network, og kunne ha jobbet i seg selv ved å gjøre forskjellige kompromisser. Hvis Lightning Network ikke hadde blitt oppfunnet, kan noen av disse løsningene ha blitt (grunnlaget for) Bitcoins gå-til-skaleringslag i stedet.

Men selvfølgelig Lightning Network var oppfunnet.

The Lightning Network

Etter år med betalingskanal og nettverksdesignutvikling falt alle brikkene i puslespillet sammen til slutt tidlig på 2015.

Thaddeus “Tadge” Dryja – CTO for handelsplattform for smarte kontrakter Speil – og Joseph Poon skrev et hvitt papir med tittelen “Bitcoin Lightning Network: Skalerbare øyeblikkelige betalinger utenfor kjeden,”Første gang publisert i februar det året.

Det viste seg å være en spillveksler.

The Lightning Network White Paper, som denne publikasjonen kom til å bli referert til, foreslo flere løsninger for å realisere et betalingskanalnettverk helt tillitsløst: ingen deltakere kunne jukse uten å risikere alle pengene de la inn i kanalen sin, mens mellommenn som videresender transaksjoner ikke kunne å stjele til og med en liten bit av den. I tillegg krevde løsningen relativt få endringer i Bitcoin-protokollen og lovet å være mer fleksibel og brukervennlig enn alternativene som er foreslått så langt.

Den viktigste innovasjonen som er beskrevet i stortingsmeldingen er “Poon-Dryja-kanaler”. Som tidligere betalingskanaldesigner er Poon-Dryja-kanaler avhengig av utveksling av delvis signerte og ikke-kringkastede transaksjoner. Men sammenlignet med tidligere betalingskanaler tar disse nye kanalene et ekstra skritt som involverer utveksling av hemmelige numre, som gjør at betalingskanaler kan oppdateres i begge retninger. Alice kan betale Bob et vilkårlig antall ganger, og Bob kan betale Alice innen samme kanal et like vilkårlig antall ganger.

I tillegg utnytter Lightning Network Hashed Timelock-kontrakter (HTLC). Dette konseptet er vanligvis tilskrevet til Tier Nolan og ble opprinnelig designet for cross-blockchain-transaksjoner; for eksempel å utveksle bitcoin og litecoin pålitelig. I Lightning Network brukes denne løsningen i stedet for å koble betalinger på tvers av betalingskanaler.

Poon og Dryja presenterte først ideen sin offentlig på San Francisco Bitcoin Devs Seminar i februar 2015:

SF Bitcoin Devs Seminar: Skalering av Bitcoin til milliarder transaksjoner per dagSF Bitcoin Devs Seminar: Skaler Bitcoin til milliarder transaksjoner per dag

Se denne videoen på YouTube

I månedene etterpå, i løpet av våren og sommeren 2015, ble Bitcoins skaleringsproblem og konflikt med blokkstørrelse til en offentlig feide. Midt i denne krisestemningen ble det arrangert en serie med to konferanser for slutten av 2015: Skalerer Bitcoin Montreal i september og Skalering av Bitcoin Hong Kong i desember. I Montreal, Poon og Dryja presentert deres forslag nok en gang, så begge deler Poon og Dryja holdt en andre, mer inngående presentasjon også i Hong Kong.

Rett etter denne andre utgaven av konferansen i Hong Kong foreslo Gregory Maxwell en skalering av veikart på postlisten til Bitcoin-utvikling. Dette veikartet hadde fremtredende Lightning Network. Det fikk Brukerstøtte fra flertallet av Bitcoins tekniske samfunn og ble de facto veikart for Bitcoin Core-prosjektet.

Hvis forventningen til Lightning Network ikke allerede var stor nok, var det absolutt nå.

Implementasjonene

Lightning Network White Paper er et langt og komplekst dokument som dekker svært tekniske konsepter; i 2015 hadde få mennesker tid og dyktighet til å lese gjennom og forstå det. Men generell forståelse økte betydelig da langvarig Linux-kjerneutvikler Rusty Russell lærte om papirboken. I en serie av blogg innlegg publisert tidlig i 2015, “oversatte” Russell forslaget for et mer generelt (men fortsatt ganske teknisk) publikum.

I mai 2015 ble Russell ansatt av Blockchain-utviklingsselskapet Blockstream for å utvikle en faktisk implementering av Lightning i C-programmeringsspråket: c-lyn. Dette store skrittet mot implementering viste seg å være avgjørende. Et konsept som bare hadde blitt foreslått et par måneder før var nå i ferd med å være realisert av en verdensklasse utvikler. Senere fikk Russell selskap av Christian Decker i Blockstream, mens andre utviklere – inkludert Corné Plooy – i løpet av de neste par årene også ville bidra til open source-prosjektet..

Rett etter at Russell begynte å jobbe med c-lyn, var ikke Blockstream lenger det eneste selskapet som realiserte en Lynimplementering. Sommeren 2015, ACINQ, et mindre Bitcoin-teknologiselskap som opprinnelig hadde planlagt å utvikle smartkortbaserte hardware-lommebøker, bestemte seg også for å prøve seg på den lovende teknologien. Den Paris-baserte oppstarten skulle senere kunngjøre at den hadde gjort det utviklet sin egen implementering av Lightning-protokollen på Scala-programmeringsspråket, kalt eclair.

Fra ACINQs eclair-kunngjøring. Kilde: medium.com

Nok et par måneder nedover veien var det en tredje implementering i arbeid. I januar 2016 grunnla begge Lightning Network-papirforfatterne, Poon og Dryja, sammen med Elizabeth Stark og Olaoluwa “Laolu” Osuntokun, et helt nytt selskap for å utvikle Lightning: Lyn Labs. Lightning Labs ville spydspissutviklingen videre lnd, en implementering av Lightning på Googles Go-programmeringsspråk (også kjent som “golang”), som de allerede hadde begynt å utvikle før de grunnla selskapet.

Omtrent ett år etter at selskapet ble grunnlagt, i slutten av 2016, forlot Dryja Lightning Labs til stedet bli med MIT Media Labs Digital Currency Initiative, den samme organisasjonen som ansetter Bitcoin Core-lederutvikler Wladimir van der Laan og flere andre Bitcoin Core-bidragsytere. På MIT fortsatte Dryja å jobbe med Lynimplementeringen han bootstrapped på Lightning Labs, som han omdøpte tent; både lnd og lit eksisterer i dag. Lit skiller seg fra lnd og andre implementeringer ved å være en lommebok og en node pakket inn i en; i dag støtter den også flere mynter samtidig gjennom et konfigurasjonsalternativ.

I tillegg blockchain selskap Bitfury, best kjent for gruvedrift og gruvedrift, forkledde den første implementeringen til enda en versjon av programvaren. Unikt for denne gaffelen er at det kom til å avveie designen for ikke å kreve en smidighetskorrigering på Bitcoin-nettverket – mer om det senere. Bitfury ga også bidrag innen transaksjonsruting, særlig i form av en protokoll kalt “Bluss.”(Utviklingen av Bitfury-gaffelen fra lnd ser ut til å ha gått i stå for nå.)

Videre i 2016 kunngjorde den store lommebokleverandøren Blockchain at den utviklet en forenklet versjon av Lightning Network kalt torden. Denne implementeringen ga relativt store avveininger sammenlignet med typiske lynimplementeringer, spesielt fordi det krevde tillit til motparter i nettverket. Ved å gjøre dette kompromisset, var det i stand til å lansere en alfa-utgivelse av implementeringen allerede våren 2016, lenge før noe annet utviklingsteam. (Mens torden også kan være gjort kompatibel med Lightning Network i fremtiden, ser det ut til at utviklingen av denne implementeringen også har stoppet.)

I dagene rett etter Scaling Bitcoin Milan, den tredje utgaven av konferansen organisert i slutten av 2016, bidro bidragsytere til de fleste lynimplementeringer for det som ble referert til som det første lynmøtet. Her diskuterte de hvordan man kunne gjøre alle de forskjellige implementeringene interoperable, noe som resulterte i en Lightning Network-protokollspesifikasjon kalt “BOLT”(Et akronym for Basis of Lightning Technology). Hvor Lightning Network-papiret var et teoretisk forslag, ble BOLT grunnlaget for det faktiske Lightning Network slik vi kjenner det i dag.

Protokollen endres

Da Lightning Network-hvittboken først ble publisert, var ideen som ble beskrevet, faktisk ikke kompatibel med Bitcoin-protokollen – i det minste ikke sikkert. For å aktivere Lightning Network som beskrevet, krevde Bitcoin flere protokollendringer.

Den første av disse var nye tidlåser som ville gjøre betalingskanaler motstandsdyktige mot Bitcoins smidighetsfeil. Dette problemet var imidlertid allerede i ferd med å bli løst allerede før utgivelsen av Lightning Network-papirboken, og ble definitivt løst i 2015, da en ny type tidslås designet og foreslått av Peter Todd ble implementert i Bitcoin-protokollen: CheckLockTimeVerify (CLTV).

Senere innså Bitcoin Core-utviklere at Lightning Network ville fungere enda bedre med relative tidlåser. Disse lar brukerne låse bitcoins i et bestemt tidspunkt etter at en annen transaksjon er bekreftet. I lynets sammenheng kan brukerne holde betalingskanalene åpne på ubestemt tid, mens CLTV-tidslåser krever at de lukker kanalene sine med jevne mellomrom. En myk gaffeloppgradering for å realisere relative timelocks, kalt CheckSequenceVerify (CSV), ble designet av Bitcoin Core-bidragsytere BtcDrak, Eric Lombrozo og Mark Friedenbach, og aktivert på Bitcoin-nettverket sommeren 2016.

Men den største protokollendringen som Lightning Network krevde (i det minste forutsatt en anstendig brukeropplevelse), var en formbarhet for enhver Bitcoin-transaksjon.

På tidspunktet for utgivelsen av Lightning Network white paper ble smidighet ansett som en stor utfordring. Mens en mykt gaffeltrekk for å fikse at det var i gang på det tidspunktet, var utviklerne ikke sikre på at dette kunne fungere, og tenkte at det kanskje måtte kreve en hard gaffel i stedet. Senere i 2015 innså Bitcoin Core-bidragsytere at Segregated Witness (SegWit), en formbarhetskorrigering som var en del av Blockstreams Elements Project, kan distribueres på Bitcoin som en bakoverkompatibel myk gaffel.

Etter en lang kamp aktiverte Segregated Witness myk gaffel endelig sommeren 2017, og banet vei for Lightning Network på Bitcoin også..

(For mer om historien til Segregated Witness, se også “Den lange veien til SegWit: Hvordan Bitcoins største protokolloppgradering ble virkelighet.”)

Alpha

Selv om Segregated Witness ennå ikke måtte distribueres på Bitcoin-protokollen (og det ikke var helt sikkert at det noen gang ville gjort det), var utviklingen av Lightning Network godt i gang.

Dette startet på testnet, Bitcoin-kopien spesielt designet for testformål. Eller mer nøyaktig, i dette tilfellet startet Lightning Network på en dedikert versjon av testnet, kalt “SegNet 4” (det var det fjerde SegWit-spesifikke testnet), lansert i mai 2016.

Mindre enn seks måneder etter distribusjonen av SegNet 4, i oktober 2016, hadde Blockstream-utviklingsteamet avansert sin c-lynprototype til det punktet hvor den var brukbar. I det som ble referert til som “Lightning First Strike,”Decker hadde“ kjøpt ”et kattebilde fra Russell ved hjelp av testnet-bitcoins over en tidlig iterasjon av Lightning Network.

Kattebildet Christian Decker “kjøpte” fra Rusty Russell. Kilde: Blockstream.com

I januar 2017 ble den første Lynimplementeringen – lnd – lansert i alfa. Med det hadde Lightning Network selv “offisielt” gått inn i “alfa-scenen”: utviklere fra hele verden ble for første gang invitert til å eksperimentere med teknologien, mens Lightning Labs ville fortsette å teste og forbedre koden.

Denne alfafasen førte igjen til at et økende antall utviklere bygde applikasjoner på toppen av lnd og andre lynimplementeringer. Disse “Runder,”Som lynimplementeringer har kommet til å bli kalt, alt fra stasjonær og mobil lommebøker, til mikropayment-bloggplattformer, til gambling nettsteder, til oppdagelsesreisende, og mye mer – skjønt, i de fleste tilfeller, fremdeles designet for Bitcoins testnet.

Sommeren 2017 aktiverte Segregated Witness endelig, og grunnlaget for Lightning Network på Bitcoin ble fullført. Fra da tok det Blockstream omtrent tre måneder å kunngjøre sin første transaksjon på Bitcoins mainnet. Litt senere, i november, gjorde Lightning Labs sin første Lightning-transaksjon på tvers av blokkjeder: fra Bitcoin til Litecoin. Og i desember utviklingslag fra Blockstream, Lightning Labs og ACINQ kunngjort at de hadde utført vellykkede interoperabilitetstester.

Videre begynte andre ved slutten av året å bruke alfa-lynimplementeringene på Bitcoins mainnet med ekte penger – i noen tilfeller til og med mot anbefalinger fra utviklerne. Et økende antall lynkanaler ble åpnet, og i desember hadde utvikleren Alex Bosworth gjort det betalte telefonregningen gjennom en lynkanal han hadde satt opp med betalingsprosessor Bitrefill: et av de første kjøpene med ekte penger over Lightning Network noensinne.

Nok en måned senere, Blockstream – mens implementeringen av c-lyn fortsatt var i beta – åpnet en nettbutikk der ekte produkter kan kjøpes med ekte bitcoins, om enn med en klar advarsel om risikoen. Og i februar 2018, i en nesten poetisk avslutning av Lightnings alfa-scene, Bitcoins legendariske Lazlo Hanyecz av “Bitcoin pizza”Berømmelse kunngjort at han hadde kjøpt pizza (selvfølgelig!) gjennom Lightning Network.

Lazlo Hanyecz nyter pizzaene sine. Kilde: http://eclipse.heliacal.net/~solar/bitcoin/lightning-pizza/

Betaen

Etter år med utvikling, og enda flere år med konseptualisering, ble kanskje den største milepælen av alle nådd for flere uker siden.

Midt i mars 2018 var Lightning Labs den første Lightning-implementeringen som ble utgitt i beta. Kunngjort samtidig med en $ 2,5 millioner frøinvesteringsrunde, som inkluderte store navneinvestorer som Twitter-sjef Jack Dorsey, anså Lightning Labs Lightning-implementeringen som den hadde vært spydspiss klar til bruk på Bitcoins mainnet – men først og fremst for tekniske brukere.

Denne kunngjøringen ble fulgt av en kvitring fra ACINQ 28. mars og kunngjorde at eclair også hadde blitt utgitt i beta og dermed ble ansett som klart for bruk av mainnet også. Oppstarten la til at Android Lightning-lommeboken deres ble utgitt uken etter. (Da denne artikkelen ble publisert, er det denne uken.)

Blockstreams implementering av c-lyn er ennå ikke utgitt i beta, selv om utviklingsteamet antydet det Bitcoin Magazine dette kan også følge kort tid. Ved å legge til en fortsatt voksende liste gjorde blockchain-utviklingsselskapet imidlertid, introdusere syv splitter nye lapper den siste uken i mars, og fremhever selskapets fremgang på lynfronten.

Mens folk allerede brukte lynprogramvare selv i alfa, har beta-fasen bare stimulert dette ytterligere vekst. På tidspunktet for publiseringen av denne artikkelen har godt over 1000 lynnoder åpnet nesten 5000 betalingskanaler, og samlet har de over 10 bitcoin (rundt $ 70 000 i skrivende stund). Hundrevis av nye noder kommer online hver dag, og til og med et Litecoin-spesifikt lynnettverk tar form, som i fremtiden kan gjøres interoperabelt med Bitcoins.

En graf over Lightning Network på tidspunktet for utgivelsen. Kilde: lnmainnet.gaben.win

Likevel, selv med all denne fremgangen, er det fortsatt tidlige dager for Lightning Network. De fleste brukere av nettverket i dag er fremdeles veldig tekniske (ofte utviklere), og brukstilfeller er stort sett eksperimentelle. Selv om utgivelsen (e) av beta-programvaren er viktige milepæler, er utvikling og forbedring av nettverket en pågående prosess, og mye må fortsatt gjøres, mens åpne spørsmål om ruting, personvern og annen risikoer forbli.

Mest sannsynlig vil bare videre adopsjon svare på dem.

Forfatterens merknad: Mens jeg undersøkte for denne artikkelen, kom jeg til å innse at hele (pre) historien til Lightning Network er enda mer omfattende enn jeg allerede visste at den var. Å skissere det i ett stykke krevde å kutte hjørner og utelate detaljer, noe som ikke gjør rettferdighet til alle mennesker, prosjekter og konsepter som hjelper (rediger) å realisere denne teknologien. Denne artikkelen er et forsøk på å skissere historien så langt, men den forstås best som en grov oppsummering – ikke en uttømmende historisk eller teknisk redegjørelse. Takk til alle som ga informasjon og andre innspill.