Efter år med konceptualisering og udvikling er de første Lightning-implementeringer nu i beta. Som et resultat vises der flere noder online hver dag, et stigende antal brugere åbner kanaler med hinanden, og nogle købmænd begyndte endda at acceptere lynbetalinger.

Men selvfølgelig er dette stadig de meget tidlige dage af Lightning Network. Mens de vigtigste implementeringer er anvendelige, og nogle tegnebøger og andre applikationer er tilgængelige, forventes Bitcoins overlay-betalingsnetværk at forbedre sig i løbet af de næste par år inden for områder, der spænder fra netværksarkitektur til sikkerhed og brugervenlighed og mere.

Dette er nogle af de mere vigtige Lynprojekter, der i øjeblikket er under udvikling.

Dual-finansierede kanaler

Lightning Network består af en række betalingskanaler. Hver betalingskanal eksisterer mellem to brugere, hvilket gør det muligt at sende midler frem og tilbage mellem dem.

I dette tidlige udviklingsstadium kan betalingskanaler imidlertid kun finansieres af en af ​​de to parter. Finansieringsparten skal først foretage en transaktion med sin modpart; først da kan modparten returnere en betaling inden for den samme betalingskanal.

Det Lightning Network hvidbog, dog foreslåede dobbeltfinansierede kanaler, for hvilke a specifikationsforslag er nu også lavet af ACINQ, virksomheden bagved eclair. Som navnet antyder, vil dobbeltfinansierede kanaler lade begge brugere delvis finansiere en betalingskanal ved hver at deponere noget bitcoin. Dette burde give Lightning-brugeroplevelsen mere fleksibilitet, da brugere straks kan sende og modtage betaling efter at have åbnet en kanal.

Ubådsbytter

For at kunne foretage en Lightning-betaling skal brugerne indbetale penge i en Lightning-kanal. En gang i en kanal kan disse midler ikke sendes til almindelige (on-chain) Bitcoin-adresser (medmindre kanalen først lukkes). Dette betyder, at bitcoin i en lynkanal er noget adskilt fra bitcoin i en almindelig tegnebog, ikke i modsætning til, hvordan penge på en kontrolkonto er noget adskilt fra penge på en opsparingskonto.

Men der er løsninger, der gør skift mellem Lyn- og on-chain-betalinger mere problemfri.

En løsning er Ubådsbytter. Udviklet af Alex Bosworth (men konceptualiseret af Lightning Labs CTO Olaoluwa Osuntokun endda inden da), Submarine Swaps lader i det væsentlige brugere sende lynbetalinger til en mellemmand på Lightning Network; denne mellemmand sender en tilsvarende mængde bitcoin til en almindelig (on-chain) Bitcoin-adresse. Det fungerer også omvendt: brugere kan sende regelmæssige betalinger via kæden til mellemmanden; den mellemmand vil derefter sende en tilsvarende mængde bitcoin til en modtagende Lightning-node på Lightning Network.

Det er vigtigt, at denne konvertering med Submarine Swaps sker “atomisk”. Ved hjælp af et trick, der allerede er indlejret i Lightning Network, kan Lightning-betalingen og betalingen via kæden effektivt knyttes til hinanden. Dette gør det umuligt for mellemmanden at stjæle penge ved ikke at videresende betalingen. (Efter aftale med brugerne kunne han opkræve et mindre gebyr for sin service.)

Splejsning

En anden løsning til at gøre Lightning-brugeroplevelsen mere problemfri kaldes “splejsning”. I princippet vil splejsning lade en bruger “fylde op” midler i en eksisterende lynkanal eller “dræne” penge fra den, potentielt samtidig med at kanalen holdes åben.

Ideen er enkel. Enhver lynkanal starter med en åbningstransaktion, som sikrer, at begge brugere giver samtykke til at flytte midlerne i kanalen. Resten af ​​Lightning-kanalen består af en række efterfølgende transaktioner, der udveksles mellem brugerne, som normalt ikke sendes til Bitcoin-netværket. Midlerne i åbningstransaktionen bevæger sig ikke, før kanalen er lukket.

Når “splejses ind”, tager brugerne åbningstransaktionen for i stedet at sende penge til en erstatningsåbningstransaktion, som inkluderer mere bitcoin, fra en eller begge brugere. Når denne nye åbningstransaktion bekræfter på blockchain, fyldes kanalen op. Indtil den nye åbningstransaktion er bekræftet, kan de to brugere simpelthen opdatere både den gamle og den nye kanal på samme tid for at undgå “kanalnedetid”.

Omvendt, når de “splitter ud”, tager brugerne åbningstransaktionen for at sende penge til en almindelig (on-chain) adresse og potentielt opbevare noget af det i kanalen ved hjælp af det samme trick. På denne måde kan brugere foretage on-chain-transaktioner lige ud af en Lightning-kanal.

Eltoo

Hver gang en ny betaling foretages, opdateres lynkanaler mellem brugere for at afspejle deres gensidige saldi. Det trick, der bruges til at opnå dette, inkluderer i øjeblikket en straf for brugere, der prøver at snyde ved at udsende en ældre saldo (formodentlig fordi den ældre saldo ville betale dem mere). Snydende brugere kan miste alle de midler, de har i en kanal.

Problemet er, at transmission af gamle saldi ikke altid er et snydeforsøg. Der er en række scenarier, hvor brugere ved et uheld kan sende en ældre saldo; for eksempel på grund af en softwarefejl eller en backup gået galt. I sådanne scenarier er et fuldstændigt tab af kanalfonde ret tung straf.

Først offentliggjort den 30. april 2018, eltoo er det nyeste forslag i denne artikel. Udviklet af Blockstream’s c-lyn udviklingsteam – Dr. Christian Decker og Rusty Russell – og Osuntokun fra Lightning Labs, opdaterer eltoo en kanal ved at opbygge en kæde af tidslåste transaktioner, hvor hver transaktion bruger midler fra den forrige til at afspejle den seneste kanalsaldo.

Hvis en bruger sender en ældre transaktion (repræsenterer en ældre kanalsaldo), har hendes modpart noget tid til at udsende den seneste transaktion (repræsenterer den seneste kanalsaldo).

En løsning som denne kan fungere i dag, men den er ikke praktisk i tilfælde af fiasko. Det ville kræve, at hele transaktionskæden sendes og optages på Bitcoin blockchain, hvilket mere eller mindre besejrer formålet med Lightning Network. Decker derfor foreslog en soft-fork-ændring af Bitcoin-protokollen for at indføre en type hierarki i disse transaktionstyper: enhver nyere transaktion kan tilsidesætte enhver ældre transaktion uden at kræve, at alle transaktioner i hele kæden udsendes.

Hvis denne bløde gaffel vedtages og aktiveres på Bitcoin-netværket, kan Lightning-brugere oprette kanaler i både den aktuelle stil og ved hjælp af eltoo, afhængigt af hvad de foretrækker.

Kompakt blokfiltrering på klientsiden

Mens Lightning Network er en protokoll af andet lag, er selve Bitcoin-blockchain stadig relevant for Lightning-brugere af sikkerhedsmæssige årsager. Specifikt skal lynbrugere holde øje med blockchain for at se, om specifikke transaktioner er inkluderet. Dette kan være ressourceintensivt, især for mobilbrugere.

En løsning på dette kaldes Simplified Payment Verification (SPV) og blev beskrevet i Bitcoin-hvidbogen. Nuværende SPV-tegnebøger bruger et trick kaldet “Bloom filtre”For at finde ud af, om der var nogen relevante transaktioner.

Desværre er Bloom-filtre temmelig fortrolige-uvenlige, da tegnebøger i det væsentlige afslører alle deres adresser til noder på Bitcoin-netværket. De har også nogle problemer med skalering og brugervenlighed, da hver enkelt SPV-tegnebog optager ressourcer fra mindst en fuld Bitcoin-node.

For at tackle disse problemer, Osuntokun og Alex Akselrod, Lightning Labs sammen med Coinbase udvikler Jim Posen, designet en ny løsning kaldet “kompakt klientsides blokfiltrering”, som de implementerer i Neutrino tegnebog.

Kompakt blokfiltrering på klientsiden inverterer i det væsentlige det trick, som de nuværende SPV-tegnebøger bruger. I stedet for tegnebøger, der anmoder om transaktioner, der er relevante for dem, ved at oprette og sende et Bloom-filter til fulde noder, opretter fulde noder et filter til alle Neutrino-tegnebøger. Neutrino-tegnebogen bruger derefter dette filter til at fastslå, at den relevante transaktion ikke skete – hvilket virkelig er alt, hvad brugerne har brug for at vide for at være sikre på, at de ikke bliver snydt. (Hvis filteret producerer et match, henter Neutrino den relevante blok for at se, om kampen virkelig vedrører den nøjagtige transaktion i stedet for en falsk positiv.)

Interessant nok, mens dette trick blev designet med Lightning-oplevelsen i tankerne, kunne det også bruges til at gavne almindelige lyspunge.

Vagttårne

For at undgå at blive snydt skal Lightning-brugere holde styr på potentielle on-chain-transaktioner, der kan være relevante for dem.

Mens kompakt blokfiltrering på klientsiden skulle gøre tingene meget nemmere, skal brugerne “tjekke ind” en gang imellem for at sikre, at de ikke bliver snydt. Hvis de glemmer at kontrollere, skaber det en sikkerhedsrisiko.

“Vagttårne” er en potentiel løsning, der kan spores tilbage til Lightning Network-hvidbogen og har siden været forbedret af Lightning Network hvidbog medforfatter og tændt udvikler Tadge Dryja og andre. Som navnet antyder, kunne Vagttårne ​​lade brugerne outsource blockchain-overvågning til tredjeparter.

Nuværende Vagttårnsdesign er ikke sat i sten, men vil omtrent fungere sådan. Hver gang brugere opdaterer en kanal, sender de en lille datapakke til et vagttårn. Den første del af denne pakke er et “antydning” til en transaktion, de skal passe på, som om det var et stykke af et puslespil. Dette antydning alene afslører ikke noget om indholdet af transaktionen, som Vagttårnet skal passe på; brugere opgiver ikke privatlivets fred i denne forstand.

Men hvis den relevante transaktion vises i Bitcoin blockchain, kan Vagttårnet bruge hintet til at genkende det. Derefter, med transaktionsdataene på selve blockchain, kan Vagttårnet bruge den anden del af den pakke, de har modtaget, til at rekonstruere sanktionstransaktionen. Denne straffetransaktion sender alle midler i kanalen til den bruger, der bliver snydt. (Eller i tilfælde af eltoo udsender den bare den korrekte kanalsaldo.) Straffetransaktionen kan også være designet til at lade Vagttårnet kræve en del af midlerne som en belønning som et incitament til at udføre sit arbejde.

Brugere kan outsource kanalovervågning til flere vagttårne. Selv hvis en fejler, kan en anden muligvis ikke begrænse risikoen for Lightning-brugere til det punkt, hvor det uden tvivl er ubetydelig.

Atomic Multi-Path-betalinger

Hvad gør Lightning Network til netværk er, at betalingskanalerne mellem brugerne er indbyrdes forbundne. Brugere kan betale på tværs af betalingskanaler gennem jævnaldrende på netværket, der fungerer som “mellemmænd”, til brugere, de ikke har en direkte kanal åben med.

Men lige nu skal en enkelt betaling dirigeres over en enkelt rute. Hvis en bruger ønsker at betale 5 mBTC til en anden, skal han ikke kun have 5 mBTC i en enkelt kanal, alle mellemmænd på ruten skal også have 5 mBTC klar i en kanal til at videresende. Jo større en betaling er, jo mindre er oddsene for dette tilfældet.

Atomic Multi-Path Payments (AMP’er) kunne gå langt med at løse denne begrænsning. Først foreslået af Lightning Labs ‘Osuntokun og Conner Fromknecht, er ideen enkel: Større betalinger kan “skæres op” i mindre stykker, som alle har deres egen rute fra betaleren til betalingsmodtageren gennem forskellige mellemmænd.

En udfordring med at realisere denne løsning er, at Lynbetalinger kan mislykkes, hvilket i dette tilfælde vil betyde, at en betaling foretages delvist. Delvise betalinger kan let være et større problem end ingen betaling overhovedet: En købmand vil ikke være tilfreds med en delvis betaling, mens en kunde ikke vil være glad for at bruge penge til ingenting.

Løsningen på dette problem er, at AMP’er bruger en udvidelse til de hash-tidslåste kontrakter, som allerede bruges langs lynruter og involverer videregivelse af hemmelige data langs et netværk. Ved at bruge et trick svarende til det, der bruges af deterministiske tegnebøger (som genererer flere Bitcoin-adresser fra et enkelt frø), kan de mindre stykker af en større betaling kun indløses af betalingsmodtageren, hvis de alle er: hvis nogle hemmelige data ikke gør det gøre det gennem ruten hel, hele betalingen mislykkes.

Atomiske swaps

Lightning Network er designet som et skaleringslag for Bitcoin. Men da mange altcoins er softwaregafler til Bitcoins kodebase (r), er det ofte ikke svært at oprette lignende skaleringslag til disse altcoins. Allerede eksisterer et lille Litecoin Lightning Network, og flere Lightning Networks vil sandsynligvis følge.

Interessant nok behøver disse netværk ikke at forblive adskilt i fremtiden.

Brug af en grundlæggende byggesten i Lightning Network kaldet “atomiske swaps” (først foreslog af Tier Nolan og realiseret på Lightning af Lightning Labs ‘Fromknecht), kan betalingskanaler linkes på tværs af forskellige blockchains. Med andre ord kan en bruger sende bitcoin, og så længe en node på netværket er villig til at foretage udvekslingen, kan en anden bruger modtage betalingen som litecoin.

Selvfølgelig betyder det også, at brugerne kan sende sådanne betalinger til sig selv: de kan sende bitcoin og modtage litecoin. I virkeligheden kunne Lightning Network etablere et netværk af tillidsløse kryptokursudvekslinger.

For mere information om dette emne, se: “Atomiske swaps: Hvordan lynnetværket udvides til Altcoins.”

Kanalfabrikker

Den største fordel ved Lightning Network er uden tvivl dets potentiale til at øge den øvre grænse for bitcoin-transaktioner kraftigt uden at belaste Bitcoin-netværket. Så længe to brugere begge har midler i deres kanal, kan de betale hinanden et næsten ubegrænset antal gange, mens de kun kræver to on-chain-transaktioner: en for at åbne en betalingskanal og en for at lukke den.

Alligevel kan to transaktioner pr. Betalingskanal tilføjes, hvis Bitcoin og Lightning Network får mere adoption over tid.

Et forslag fra ETH Zürich forskere Christian Decker (også fra Blockstream), Roger Wattenhofer og Conrad Burchert kaldet “Channel Factories” kunne yderligere reducere det gennemsnitlige antal on-chain-transaktioner, der kræves pr. betalingskanal, måske markant.

Løst baseret på et tidligere lynlignende forslag fra Decker og Wattenhofer fra 2015 er Channel Factories en type betalingskanal, der kan eksistere blandt mange brugere. I mellemtiden, som enhver betalingskanal, kræver en Channel Factory kun to on-chain-transaktioner. (Hvis Schnorr-signaturer implementeres på Bitcoin, kan disse transaktioner være ret kompakte, selvom det involverer mange brugere.)

Kanalfabrikkerne kan igen fungere som “underkanaler” for Lightning Network. Deltagere inden for en kanalfabrik kan åbne og lukke et næsten ubegrænset antal lynkanaler med hinanden uden at kræve yderligere on-chain-transaktioner. Ved at gøre dette kunne de i teorien sænke antallet af krævede on-chain-transaktioner for Lightning Network med en størrelse.

For mere information om dette emne, se: “Dette nye skaleringslag kunne gøre betalingskanaler ti gange mere effektive”.

Tak til Blockstream-udvikleren Christian Decker, Lightning Labs-udvikleren Conner Fromknecht, ACINQ CEO Pierre-Marie Padiou og andre for information og feedback.