Fra et par uger siden var den første Lynimplementering – lnd – er officielt i beta. Den anden implementering – eclair – fulgte sidste uge, mens den tredje – c-lyn – forventes at gøre det snart. Som sådan betragtes Lightning Network, det længe ventede Bitcoin overlay-netværk til billige og øjeblikkelige transaktioner, af mange af dets udviklere som sikre nok til at bruge på Bitcoins mainnet: en vigtig milepæl for den teknologi, der har været år i gang.

Dette er historien indtil videre.

The First Musings

Den tidligste oprindelse af Lightning Network kan spores helt tilbage til Bitcoin selv.

Det første stykke af Lightning-puslespillet er et koncept kaldet “betalingskanaler”. Betalingskanaler er i det væsentlige bitcoin-saldi mellem to Bitcoin-brugere og kun to brugere: resten af ​​verden behøver ikke at vide eller være interesseret i deres gensidige saldi. Det er vigtigt, at disse saldi kan opdateres uden at kræve nogen Bitcoin-transaktioner på kæden; hvor saldoen for den ene bruger stiger, falder saldoen for den anden med det samme beløb. Dette giver faktisk begge deltagere mulighed for at handle mellem hinanden uden at belaste hele netværket med deres transaktionsdata.

Når brugerne er færdige med at handle, kan de afvikle deres betalingskanal ved kun at sende en transaktion til netværket: den transaktion udbetaler til hver, hvad de skal modtage baseret på deres kanalsaldoer. Til disse brugeres fordel bør dette også betyde, at kanalopdateringerne (“off-chain-transaktioner”) er billigere, fordi de ikke kræver minegebyrer og er hurtigere, fordi de ikke kræver blockchain-bekræftelser.

Denne generelle idé er uden tvivl lige så gammel som den allerførste Bitcoin-software udgivet af Satoshi Nakamoto i 2009. Bitcoin 0,1 inkluderede en rå udkast til kode der giver brugerne mulighed for at opdatere en transaktion, før den blev bekræftet:

Et groft udkast til betalingskanalkode inkluderet i Bitcoin 0.1. Kilde: GitHub

Mens denne kode var et groft kladde, gik Satoshi Nakamoto nærmere ind i, hvordan betalingskanaler kunne fungere i privat kommunikation med dengang-bitcoinj udvikler Mike Hearn.

Flere år senere, i 2013, Hearn offentliggjort Satoshi Nakamotos forklaring af betalingskanaler på Bitcoin-udvikling mailingliste:

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

De første betalingskanaler

Selvom det generelle koncept med betalingskanaler har eksisteret så længe som Bitcoin selv, var Satoshi Nakamotos design ikke helt sikkert. Vigtigst er det, at en bruger i en betalingskanal kunne samarbejde med minearbejdere for at få en ældre transaktion bekræftet og hævde mere bitcoin end kanalbalancen skulle lade ham.

En løsning på dette problem blev foreslået for første gang i sommeren 2011, efter at Satoshi Nakamoto havde forladt Bitcoin-projektet. Bitcointalk forum bruger “hashcoin” skitseret en to-lags betalingskanal, der krævede, at brugerne udvekslede flere delvist underskrevne multisignaturtransaktioner og transaktioner med tidslåse, der var afhængige af hinanden for at være gyldige. Hvis en deltager skulle forsvinde, kunne den anden kræve alle midlerne i betalingskanalen, efter at der var gået nogen tid. En ulempe ved dette design var dog, at hashcoins kanaler kun kunne fungere i en retning. “Alice” kunne betale “Bob” et vilkårligt antal gange, men Bob kunne ikke betale Alice gennem den samme kanal.

En idé, der ligner hashcoin, dukkede op igen i begyndelsen af ​​2013, og denne gang undgik den den teoretiske verden. I april samme år var et betalingskanalkoncept beskrevet af Jeremy Spilman på postlisten til Bitcoin-udvikling. Han havde endda kodet op a bevis på konceptet. Dette design blev igen tweaked af Mike Hearn, hvorefter fremtidig Bitcoin Core-bidragyder, Blockstream medstifter og Chaincode Labs udvikler Matt Corallo forvandlede konceptet til arbejdskode til bitcoinj ved midten af ​​2013.

Et andet år senere, i 2014, var Alex Akselrod (nu ingeniør hos Lightning Labs) den første til foreslå en tovejs betalingskanal. Alice kunne betale Bob et vilkårligt antal gange, mens Bob ved hjælp af faldende tidslåse kunne betale Alice inden for den samme kanal – omend et begrænset antal gange. I modsætning til envejsbetalingskanaler blev denne løsning imidlertid aldrig faktisk implementeret i kode.

De første betalingsnetværkskoncepter

Omkring samme tid, som de første betalingskanaler blev foreslået, andre – herunder for eksempel Bitcoin Core-udviklere Peter Todd og Gavin Andresen – tænkte på off-chain betalingsnetværk. Hvis Alice kunne betale Bob gennem en off-chain-transaktion, og Bob kunne betale Carol gennem en off-chain-transaktion, skulle Alice være i stand til at betale Carol gennem Bob uden at kræve nogen on-chain-transaktioner.

Corné Plooy (nu Lightning-udvikler ved hollandsk Bitcoin-udveksling BL3P) havde også arbejdet på et betalingslag til Bitcoin, som han først foreslog som en grov idé i 2011.

En tidlig illustration af Plooys betalingslagsdesign, som ville udvikle sig til Lightning Network-forløber Amiko Pay. Kilde: Corné Plooy

Med forslag tilføjet af Bitcoin Core-udvikler og fremtidige Blockstream CTO Gregory Maxwell, og Ripple opfinder Ryan Fugger (blandt andre) udviklede denne idé sig hele vejen igennem det flere år ind i en fusion af Bitcoin og den originale Ripple-teknologi, hvilket resulterede i system Plooy kaldet “Amiko Pay.” Tidligere udkast til Amiko Pay benyttede ikke betalingskanaler og injicerede derfor tillid til systemet, dog: skulle en bruger nægte at afregne en balance med en anden bruger, ville sidstnævnte ikke have brug for.

Et netværk for tidlig betaling forslag at udnyttede betalingskanaler var foreslog af matematiker og fremtid Bitcoin emBassy TLV medstifter Meni Rosenfeld sommeren 2012. På Bitcointalk forum beskrev Rosenfeld et system, hvor Bob (fra ovenstående eksempel) erstattes af en betalingsprocessor med både Alice og Carol som sine kunder. Betalingsprocessoren kunne til gengæld også have kanaler med andre betalingsprocessorer med flere kunder, der gjorde betalingskanalnetværket til et hub-and-spoke-system.

Mens et sådant system indførte en lille smule tillid til betalingsbehandlerne – kunne de nægte at videresende en betaling og beholde pengene i stedet – denne risiko blev betragtet som lille: tricket ville kun fungere for en betaling, før en kunde bemærkede og stoppede ved hjælp af kanalen. Derudover kunne større betalinger opdeles i mindre intervaller, så hvis en betalingsprocessor viste sig at være upålidelig, ville kun en lille del af betalingen gå tabt.

Denne løsning dukkede op igen et par gange gennem årene. Bitcoin Core-bidragyder Peter Todd, for eksempel, offentliggjort konceptet til Bitcoin-udviklings mailingliste i 2014. Betalingsprocessor BitPay, i mellemtiden offentliggjort en hvidt papir på lignende interkanalbetalinger (“Impuls”) i begyndelsen af ​​2015. Og en opløsning som dette faktisk ville blive implementeret af den svenske startup Strawpay, hedder Stroem (eller Ström), på samme tid – men ingen af ​​disse gentagelser startede nogensinde på en meningsfuld måde.

Logoet for den nu nedlagte Strawpay-mikropayment-opstart. Kilde: Internetarkivet

Et relativt tidligt forsøg på at etablere et tillidsløst betalingskanalnet blev foretaget af Alex Akselrod. Først beskrevet i a wiki-udkast i 2013, skal implementeres som en bevis på konceptet igennem 2014 gik Akselrods løsning langt i retning af at løse problemet på et teoretisk niveau. Hovedproblemet var, at det stadig ville være ret klodset i praksis. Hvis en betaling for eksempel mislykkedes hvor som helst langs ruten for en transaktion, ville en bruger f.eks. Ikke have mulighed for at vente, indtil pengene blev frigjort gennem betalingskanalens tidslåse, hvilket potentielt kunne tage måneder.

I mellemtiden havde Plooys Amiko Pay inden 2015 haft udviklet sig til det punkt, hvor det også potentielt kunne fungere tillidsfuldt. Imidlertid ville hans design have krævet relativt vidtrækkende ændringer af Bitcoin-protokollen, til det punkt, hvor det var nødvendigt at rulle visse typer transaktioner tilbage. Selvom det var teknisk muligt, var det ikke indlysende, om sådanne ændringer i Bitcoin-protokollen ville blive vedtaget.

Senere samme år forskere fra det tekniske universitet i Zürich (ETH Zürich), Dr. Christian Decker (nu i Blockstream) og Roger Wattenhofer foreslog endnu et overlay-netværksdesign i deres hvidbog “Et hurtigt og skalerbart betalingsnetværk med Bitcoin Duplex mikropayment-kanaler.”Deres løsning stod stærkt på tidslåse som en slags“ nedtællingstikker ”for betalingskanalgyldighed, som blev kombineret med et kryptografisk trick kaldet et“ ugyldighedstræ ”for udløbne kanalsaldoer.

Akselrods løsning, de senere udkast til Amiko Pay og Duplex Micropayment Channels (DMC’er) lignede alle på nogle måder Lightning Network og kunne have arbejdet i deres egen ret ved at foretage forskellige afvejninger. Hvis Lightning Network ikke var opfundet, kunne nogen af ​​disse løsninger muligvis være (grundlaget for) Bitcoins go-to-skaleringslag i stedet.

Men selvfølgelig Lightning Network var opfundet.

The Lightning Network

Efter år med betalingskanal og netværksdesignudvikling faldt alle brikkerne i puslespillet endelig sammen i begyndelsen af ​​2015.

Thaddeus “Tadge” Dryja – CTO for smart kontrakt handelsplatform Spejl – og Joseph Poon skrev en hvidbog med titlen “Bitcoin Lightning Network: Skalerbare øjeblikkelige betalinger uden for kæden,”Første gang offentliggjort i februar samme år.

Det viste sig at være en game-changer.

Lightning Network-hvidbogen, som denne publikation kom til at blive henvist til, foreslog adskillige løsninger til at realisere et betalingskanalenetværk helt tillidsfuldt: ingen deltagere kunne snyde uden at risikere alle de penge, de lagde i deres kanal, mens mellemmænd, der videresender transaktioner, ikke kunne at stjæle endda en lille smule af det. Derudover krævede løsningen relativt få ændringer af Bitcoin-protokollen og lovede at være mere fleksibel og brugervenlig end de foreslåede alternativer hidtil.

Den vigtigste innovation beskrevet i hvidbogen er “Poon-Dryja-kanaler”. Som tidligere betalingskanaldesigner afhænger Poon-Dryja-kanaler af udvekslingen af ​​delvist underskrevne og ikke-udsendte transaktioner. Men sammenlignet med tidligere betalingskanaler tager disse nye kanaler et yderligere trin, der involverer udveksling af hemmelige numre, som gør det muligt at opdatere betalingskanaler i begge “retninger”. Alice kan betale Bob et vilkårligt antal gange, og Bob kan betale Alice inden for den samme kanal et lige så vilkårligt antal gange.

Derudover udnytter Lightning Network Hashed Timelock-kontrakter (HTLC’er). Dette koncept er normalt tilskrives til Tier Nolan og blev oprindeligt designet til cross-blockchain-transaktioner; for eksempel at udveksle bitcoin og litecoin uden tillid. I Lightning Network bruges denne løsning i stedet til at linke betalinger på tværs af betalingskanaler.

Poon og Dryja præsenterede først deres idé offentligt på San Francisco Bitcoin Devs Seminar i februar 2015:

SF Bitcoin Devs Seminar: Skalering af Bitcoin til milliarder af transaktioner pr. DagSF Bitcoin Devs Seminar: Skalering af Bitcoin til milliarder af transaktioner pr. Dag

Se denne video på YouTube

I månederne derefter, i løbet af foråret og sommeren 2015, blev Bitcoins skaleringsproblem og blokstørrelsesgrænsestriden til en offentlig fejde. Midt i denne krisestemning blev der arrangeret en række af to konferencer i slutningen af ​​2015: Skalering af Bitcoin Montreal i september og Skalering af Bitcoin Hong Kong i december. I Montreal, Poon og Dryja forelagde deres forslag igen, så begge Poon og Dryja gav også en anden mere dybtgående præsentation i Hong Kong.

Lige efter denne anden udgave af konferencen i Hong Kong foreslog Gregory Maxwell en skalering af vejkort på postlisten til Bitcoin-udvikling. Dette køreplan indeholdt fremtrædende Lightning Network. Det fik support fra størstedelen af ​​Bitcoins tekniske samfund og blev de facto køreplanen for Bitcoin Core-projektet.

Hvis forventningen til Lightning Network ikke allerede var stor nok, var det bestemt nu.

Implementeringerne

Lightning Network-hvidbogen er et langt og komplekst dokument, der dækker højtekniske begreber; i 2015 havde få mennesker tid og dygtighed til at læse igennem og forstå det. Men generel forståelse steg markant, da Linux-kerneudvikler i lang tid Rusty Russell lærte om hvidbogen. I en serie af blog indlæg offentliggjort i begyndelsen af ​​2015 “oversatte” Russell forslaget til et mere generelt (men stadig ret teknisk) publikum.

Derefter, i maj 2015, blev Russell hyret af blockchain-udviklingsfirmaet Blockstream til at udvikle en faktisk implementering af Lightning på C-programmeringssproget: c-lyn. Dette store skridt mod implementering viste sig at være afgørende. Et koncept, der kun var blevet foreslået et par måneder tidligere, var nu i færd med at være gik op for af en verdensklasse udvikler. Russell blev senere følgeskab af Christian Decker i Blockstream, mens andre udviklere – herunder Corné Plooy – i løbet af de næste par år også ville bidrage til open source-projektet.

Kort efter at Russell begyndte at arbejde på c-lightning, var Blockstream ikke længere det eneste firma, der realiserede en Lightning-implementering. I sommeren 2015, ACINQ, et mindre Bitcoin-teknologivirksomhed, der oprindeligt havde planlagt at udvikle smart-card-baserede hardware-tegnebøger, besluttede også at prøve deres hånd på den lovende teknologi. Den Paris-baserede opstart ville senere meddele, at den havde gjort det udviklede sig sin egen implementering af Lightning-protokollen på Scala-programmeringssproget, der hedder eclair.

Fra ACINQs eclair-meddelelse. Kilde: medium.com

Endnu et par måneder nede ad vejen var en tredje implementering i gang. I januar 2016 grundede begge Lightning Network-hvidbogsforfatterne, Poon og Dryja sammen med Elizabeth Stark og Olaoluwa “Laolu” Osuntokun, et helt nyt firma til at udvikle Lightning: Lightning Labs. Lightning Labs ville være spydspidsen for udviklingen lnd, en implementering af Lightning på Googles Go-programmeringssprog (også kendt som “golang”), som de allerede var begyndt at udvikle inden de stiftede virksomheden.

Cirka et år efter grundlæggelsen af ​​virksomheden, i slutningen af ​​2016, forlod Dryja Lightning Labs til i stedet tilslutte MIT Media Labs Digital Currency Initiative, den samme organisation, der beskæftiger Bitcoin Core-lederudvikler Wladimir van der Laan og flere andre Bitcoin Core-bidragydere. På MIT fortsatte Dryja med at arbejde med Lightning-implementeringen, som han startede på Lightning Labs, som han omdøbte tændt; både lnd og lit findes i dag. Lit adskiller sig fra lnd og andre implementeringer ved at være en tegnebog og en node indpakket i en; i dag understøtter den også flere mønter samtidigt gennem en konfigurationsmulighed.

Derudover blockchain-selskab Bitfury, bedst kendt for sin minedrift og minedrift hardware, forked den første implementering til endnu en version af softwaren. Unikt for denne gaffel er, at det foretog afvejninger i designet for ikke at kræve en smidbar løsning på Bitcoin-netværket – mere om det senere. Bitfury leverede også bidrag inden for transaktionsrutingen, især i form af en protokol kaldet “Flare.”(Udviklingen af ​​Bitfury-gaffelen fra lnd ser dog ud til at være gået i stå for nu.)

Yderligere, i 2016, meddelte den store tegnebogsudbyder Blockchain, at den udviklede sig en forenklet version af Lightning Network kaldet torden. Denne implementering gjorde relativt store afvejninger sammenlignet med typiske Lightning-implementeringer, især fordi det krævede tillid til modparter på netværket. Ved at gøre dette kompromis var det i stand til at lancere en alfa-frigivelse af implementeringen så tidligt som foråret 2016, længe før ethvert andet udviklingsteam. (Mens torden også kan være gjort kompatibel med Lightning Network i fremtiden ser det også ud til, at udviklingen af ​​denne implementering er gået i stå for nu.)

I dagene lige efter skalering af Bitcoin Milan, den tredje udgave af konferencen, der blev arrangeret i slutningen af ​​2016, var bidragydere til de fleste lynimplementeringer samlet til det, der blev omtalt som det første lynmøde. Her diskuterede de, hvordan man kunne gøre alle de forskellige implementeringer interoperable, hvilket resulterede i en Lightning Network-protokolspecifikation kaldet “BOLT”(Et akronym for Basis of Lightning Technology). Hvor hvidbogen Lightning Network var et teoretisk forslag, blev BOLT grundlaget for det egentlige Lightning Network, som vi kender det i dag.

Protokollen ændres

Da Lightning Network-hvidbogen først blev offentliggjort, var den beskrevne idé faktisk ikke kompatibel med Bitcoin-protokollen – i det mindste ikke sikkert. For at aktivere Lightning Network som beskrevet krævede Bitcoin flere protokolændringer.

Den første af disse var nye timelocks, der ville gøre betalingskanaler modstandsdygtige over for Bitcoins smidighedsfejl. Dette problem var imidlertid allerede i færd med at blive løst allerede før offentliggørelsen af ​​Lightning Network-hvidbogen og blev endelig løst i 2015, da en ny type tidslås designet og foreslået af Peter Todd blev implementeret i Bitcoin-protokollen: CheckLockTimeVerify (CLTV).

Senere indså Bitcoin Core-udviklere, at Lightning Network ville fungere endnu bedre med relative tidslåse. Disse giver brugerne mulighed for at låse bitcoins op i et bestemt tidspunkt, efter at en anden transaktion er blevet bekræftet. I forbindelse med Lightning kan brugerne holde deres betalingskanaler åbne på ubestemt tid, mens CLTV-timelocks kræver, at de lukker deres kanaler med jævne mellemrum. En blød gaffelopgradering for at realisere relative timelocks, kaldet CheckSequenceVerify (CSV), blev designet af Bitcoin Core-bidragydere BtcDrak, Eric Lombrozo og Mark Friedenbach og aktiveret på Bitcoin-netværket inden sommeren 2016.

Men den største protokolændring, som Lightning-netværket krævede (i det mindste forudsat en anstændig brugeroplevelse), var en formbarhedsløsning for enhver Bitcoin-transaktion.

På tidspunktet for offentliggørelsen af ​​Lightning Network-hvidbogen blev smidbarhed betragtet som en stor udfordring. Mens en blød gaffeltræk for at rette op på, at det var i gang på det tidspunkt, var udviklere ikke sikre på, at dette kunne fungere, og troede, at det måske krævede en hård gaffel i stedet. Senere i 2015 indså Bitcoin Core-bidragsydere, at Segregated Witness (SegWit), en formbarhed, der var en del af Blockstreams Elements Project, kunne blive indsat på Bitcoin som en bagudkompatibel blød gaffel.

Efter en lang kamp aktiverede Segregated Witness soft fork endelig sommeren 2017 og banede også vejen for Lightning Network på Bitcoin.

(For mere om historien om Segregated Witness, se også “Den lange vej til SegWit: Hvordan Bitcoins største protokolopgradering blev virkelighed.”)

Alpha

Selv mens Segregated Witness endnu ikke var implementeret på Bitcoin-protokollen (og det ikke var helt sikkert, at det nogensinde ville), var udviklingen af ​​Lightning Network godt i gang.

Dette startede på testnet, Bitcoin-kopien specielt designet til testformål. Eller mere præcist, i dette tilfælde startede Lightning Network på en dedikeret version af testnet, kaldet “SegNet 4” (det var det fjerde SegWit-specifikke testnet), der blev lanceret i maj 2016.

Mindre end seks måneder efter implementeringen af ​​SegNet 4, i oktober 2016, havde Blockstream-udviklingsteamet avanceret sin c-lightning-prototype til det punkt, hvor den var anvendelig. I det, der blev omtalt som “Lightning First Strike,”Decker havde” købt ”et kattebillede fra Russell ved hjælp af testnet-bitcoins over en tidlig iteration af Lightning Network.

Kattebilledet Christian Decker “købte” fra Rusty Russell. Kilde: Blockstream.com

I januar 2017 blev den første Lightning-implementering frigivet i alfa. Dermed var selve Lightning-netværket ”officielt” kommet ind i dets “alfa-fase”: udviklere fra hele verden blev for første gang inviteret til at eksperimentere med teknologien, mens Lightning Labs fortsatte med at teste og forbedre koden.

Denne alfafase førte igen til, at et voksende antal udviklere byggede applikationer oven på lnd og andre lynimplementeringer. Disse “Lapps,”Som Lynimplementeringer er kommet til at blive kaldt, varierede fra desktop og mobil tegnebøger, til mikropayment blogging platforme, til hasardspil, til opdagelsesrejsende, og meget mere – dog i de fleste tilfælde stadig designet til Bitcoins testnet.

I løbet af sommeren 2017 aktiveredes Segregated Witness endelig, og grundlaget for Lightning Network på Bitcoin blev afsluttet. Fra da tog det Blockstream cirka tre måneder at annoncere sin første transaktion på Bitcoins mainnet. Lidt senere, i november, lavede Lightning Labs sin første Lightning-transaktion på tværs af blockchains: fra Bitcoin til Litecoin. Og i december udviklingshold fra Blockstream, Lightning Labs og ACINQ annonceret at de havde udført vellykkede interoperabilitetstest.

Desuden begyndte andre ved årets udgang faktisk at bruge alpha Lightning-implementeringerne på Bitcoins mainnet med rigtige penge – i nogle tilfælde endog mod anbefalinger fra dets udviklere. Et voksende antal lynkanaler blev åbnet, og i december havde udvikleren Alex Bosworth gjort det betalte sin telefonregning gennem en lynkanal, han havde oprettet med betalingsprocessor Bitrefill: et af de første køb med rigtige penge over Lightning Network nogensinde.

En anden måned senere, Blockstream – mens implementeringen af ​​c-lyn stadig var i beta – åbnet -en webshop hvor ægte produkter kunne købes med ægte bitcoins, omend med en klar advarsel om de involverede risici. Og i februar 2018, i en næsten poetisk lukning af Lightnings alfa-fase, Bitcoins legendariske Lazlo Hanyecz af “Bitcoin pizza” berømmelse annonceret at han havde købt pizzaer (selvfølgelig!) gennem Lightning Network.

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

Beta

Efter mange års udvikling og endnu flere års konceptualisering blev den måske største milepæl af alle nået for flere uger siden.

Midt i marts 2018 var Lightning Labs ‘første den første Lightning-implementering, der blev frigivet i beta. Annonceret samtidig med en $ 2,5 millioner frøinvesteringsrunde, som omfattede store navneinvestorer som Twitter-administrerende direktør Jack Dorsey, anså Lightning Labs Lightning-implementeringen, som den havde været spydspids klar til brug på Bitcoins mainnet – dog primært til tekniske brugere.

Denne meddelelse blev efterfulgt af en tweet fra ACINQ den 28. marts og meddelte, at eclair også var blevet frigivet i beta og derfor også blev anset for klar til mainnet-brug. Opstarten tilføjede, at deres Android Lightning-tegnebog blev frigivet den følgende uge. (På tidspunktet for offentliggørelsen af ​​denne artikel er det denne uge.)

Blockstreams implementering af c-lightning er endnu ikke frigivet i beta, selvom dets udviklingsteam angav det Bitcoin Magazine dette kan også følge kort efter. Tilføjelse til en stadig voksende liste gjorde blockchain-udviklingsfirmaet det dog, introducere syv helt nye lapper i den sidste uge af marts og fremhævede virksomhedens fremskridt på lynfronten.

Mens folk allerede brugte Lightning-software selv i alfa, har beta-fasen kun stimuleret dette yderligere vækst. På tidspunktet for offentliggørelsen af ​​denne artikel har langt over 1.000 lynknudepunkter åbnet næsten 5.000 betalingskanaler og samlet over 10 bitcoin (ca. $ 70.000 i skrivende stund) samlet. Hundredvis af nye noder kommer online hver dag, og endda et Litecoin-specifikt lynnetværk tager form, som i fremtiden kan gøres interoperabelt med Bitcoins.

En graf over Lightning Network på tidspunktet for offentliggørelsen. Kilde: lnmainnet.gaben.win

Men selv med alle disse fremskridt er det stadig tidlige dage for Lightning Network. De fleste brugere af netværket i dag er stadig meget tekniske (ofte udviklere), og brugssager er for det meste eksperimentelle. Mens frigivelse (r) af beta-software er vigtige milepæle, er udvikling og forbedring af netværket en løbende proces, og der skal stadig gøres meget, mens åbne spørgsmål om routing, privatliv og andre risici forblive.

Mest sandsynligt er det kun yderligere vedtagelse, der besvarer dem.

Forfatterens note: Mens jeg undersøgte for denne artikel, indså jeg, at Lightning Network’s fulde (præ) historie er endnu mere omfattende, end jeg allerede vidste, at det var. At skitsere det i et enkelt stykke krævede at skære hjørner og udelade detaljer, hvilket ikke gør retfærdighed mod alle mennesker, projekter og koncepter, der hjælper (rediger) at realisere denne teknologi. Denne artikel er et forsøg på at skitsere historien indtil videre, men det forstås bedst som en grov opsummering – ikke en udtømmende historisk eller teknisk redegørelse. Tak til alle, der leverede information og andet input.