Facebook
Twitter
Lightning Network er trolig den mest etterlengtede teknologiske innovasjonen som skal distribueres på toppen av Bitcoin. Betalingslaget, som først ble foreslått av Joseph Poon og Tadge Dryja for rundt et år siden, lover å støtte et praktisk talt ubegrenset antall off-chain-transaksjoner blant brukerne, nesten uten kostnad – samtidig som den utnytter sikkerheten som tilbys av Bitcoin.
Minst tre selskaper – Poon og Dryja’s Lyn, Blockstream og Blockchain – jobber for tiden med implementeringer av teknologien. Men få utenfor denne lille teknologiske frontlinjen forstår fullstendig hvordan “fremtiden for mikrobetalinger” er satt til å øke Bitcoins evner.
I denne tredelte serien legger Bitcoin Magazine ut de grunnleggende byggesteinene i Lightning Network, og viser hvordan de passer sammen for å realisere dette kommende protokolllaget.
Denne første delen av serien etablerer de nødvendige byggesteinene, og viser hvordan disse kan kombineres for å skape “smarte kontrakter”, som kan brukes til å realisere det første kravet til Lightning Network: en toveis betalingskanal.
(Merk: Alle med en solid forståelse av Bitcoin kan hoppe over byggesteinene.)
Byggestein nr. 1: ubekreftede transaksjoner
I sitt hjerte består Bitcoin-protokollen av transaksjoner, som vanligvis er knyttet til tidligere transaksjoner, og potensielt til fremtidige transaksjoner. Hver transaksjon inneholder innganger som refererer til adresser bitcoins sendes fra, og utganger som refererer til adresser bitcoins sendes til. I tillegg må innganger inneholde kravene for å sende bitcoins, som signaturer som viser “eierskap” til inngangsadressene. Produksjoner etablerer i mellomtiden de nye kravene som må inngå i inngangen til en påfølgende transaksjon.
Som en av hovedtrekkene er Lightning Network bygget opp fra mer eller mindre vanlige Bitcoin-transaksjoner. Det er bare at disse transaksjonene vanligvis ikke faktisk sendes over Bitcoin-nettverket. I stedet lagres de lokalt, på noder til brukerne – men de kan sendes over nettverket når som helst.
Byggestein nr. 2: Dobbeltbruk-beskyttelse
Den andre byggesteinen for Lightning Network krever sannsynligvis ikke mye forklaring, da det uten tvil er grunnlaget for selve Bitcoin: beskyttelse med dobbelt bruk. Hvis to transaksjoner (eller: innganger) er avhengige av samme utdata, kan bare én bekrefte.
Det viktige du må huske på her er at selv ubekreftede transaksjoner kan være motstridende, noe som betyr at bare noen noensinne kan bekrefte.
Byggestein # 3: Multisig
Den tredje byggesteinen i Lightning Network er også en enkel: multisignatur (multisig) adresser. (Eller mer generelt: P2SH-adresser.)
Multisig-adresser er Bitcoin-adresser som – som navnet antyder – krever flere private nøkler for å “låse opp” og bruke bitcoins fra. Multisig-adresser kan settes opp under alle slags forhold. For eksempel å kreve to av tre mulige taster, eller femten av femten, eller omtrent hvilken som helst annen kombinasjon.
Lightning Network bruker ofte to av to (2-av-2) multisig-oppsett. Å låse opp bitcoins fra 2 til 2 multisig-adresser krever to signaturer, fra to dedikerte nøkler.
Byggestein nr. 4: Tidslåser
Den fjerde byggesteinen er tidslåsen. Tidslås kan “låse bitcoins opp” i en utgang, for å gjøre dem brukbare (for å bli inkludert i en påfølgende inngang) bare på et tidspunkt i fremtiden.
Det er to forskjellige typer tidslås: den absolutte typen, kalt CheckLockTimeVerify (CLTV), og den relative typen, CheckSequenceVerify (CSV). CLTV låser bitcoins frem til en (mer eller mindre) konkret tid i fremtiden: en faktisk tid og dato eller en spesifikk blokkhøyde. CSV bruker i stedet relativ tid. Når en CVS-utgang er registrert på blockchain, tar det en spesifikk mengde blokker fra det tidspunktet før bitcoins kan brukes igjen.
Byggestein nr. 5: Hashverdier og hemmeligheter
Den femte og siste byggesteinen – kryptografi – er den mest grunnleggende byggesteinen i Bitcoin selv. Men i Lightning Network brukes den på en ny måte.
Kort sagt, en “verdi” eller “hemmelighet” er en lang og unik tallstreng som det er praktisk talt umulig å gjette, selv for en datamaskin med uendelige forsøk. Med en spesiell beregning kan denne verdien (eller hemmeligheten) “hashes” til en annen streng med tall, en “hash”. Og her er trikset: Alle som kjenner verdien kan enkelt reprodusere hasjen. Men dette fungerer ikke omvendt; det er en enveiskjørt gate.
Dette trikset kan brukes i Bitcoin selv, igjen for å “låse bitcoins opp.” (Faktisk er det virkelig hvordan Bitcoin fungerer.) For eksempel kan en hash inkluderes i en utgang, og krever at den påfølgende inngangen inkluderer den tilsvarende verdien for å være brukbar.
Den første utfordringen: toveis betalingskanaler
Allerede før Lightning Network ble presentert, hadde begrepet betalingskanaler eksistert i noen tid. Typiske betalingskanaler er nyttige for visse formål, men også begrensede: de er ensrettet. Alice kan betale Bob flere off-chain-transaksjoner, men Bob kan ikke betale Alice gjennom samme kanal i det hele tatt.
Som et sentralt trekk ved Lightning Network, foreslo Poon og Dryja tillitsfulle toveis betalingskanaler.
Åpne kanalen
For å sette opp en toveis betalingskanal må begge involverte parter først bli enige om en åpningstransaksjon. Denne åpningstransaksjonen bestemmer hvor mange bitcoins hver setter inn i kanalen.
La oss si at Alice vil sende en bitcoin til Bob. Siden Alice og Bob forventer å gjøre transaksjoner oftere, bestemmer de seg for å åpne en toveis betalingskanal, og bruke denne til å sende bitcoin. (Å sende en hel bitcoin er sannsynligvis mye for en betalingskanal, da disse kan være mer nyttige for mikropayments – men det er fullt mulig.)
For å åpne kanalen sender Alice og Bob hver fem bitcoins til en 2-av-2 multisig-adresse. Dette er “åpningstransaksjonen.” Bitcoins kan bare brukes fra denne adressen hvis både Alice og Bob signerer en påfølgende transaksjon.
I tillegg lager Alice og Bob begge en hemmelighet (en streng med tall), og bytter hasjen.
Alice oppretter nå umiddelbart en påfølgende transaksjon fra åpningstransaksjonen. Dette er en “forpliktelsestransaksjon.” Med forpliktelsestransaksjonen sender Alice fire bitcoins til seg selv, og seks bitcoins til en annen multisig-adresse. Denne andre multisig-adressen er litt funky. Det kan låses opp av Bob alene, men først etter at 1000 ekstra blokker er utvunnet etter at det er inkludert i blockchain; den inkluderer en CSV-lås. Eller det kan åpnes av Alice alene, men bare hvis hun også inkluderer hemmeligheten som Bob nettopp har gitt henne hasjen for. (Selvfølgelig har Alice ingen anelse om hva denne hemmeligheten er – hun vet bare hasj – så det er ingen måte hun kan bruke dette alternativet akkurat nå.)
Alice signerer slutten på denne forpliktelsestransaksjonen. Men hun sender det ikke! I stedet gir hun det til Bob.
I mellomtiden gjør Bob det samme, men speilet. Han oppretter også en forpliktelsestransaksjon, hvorfra han sender seks bitcoins til seg selv, og fire til en funky ny multisig-adresse. Alice kan låse opp denne adressen hvis hun venter ytterligere 1000 blokker, eller Bob kan låse den opp med Alice ved hjelp av hemmeligheten sin.
Bob signerer denne halvdelen, og gir den til Alice.
Etter alt dette utvekslingen av “halvgyldige” forpliktelsestransaksjoner og hash av hemmeligheter, signerer og sender de begge åpningstransaksjonen for å sikre at den blir registrert på blockchain. Kanalen er nå offisielt åpen.
På dette tidspunktet kunne både Alice og Bob signere og kringkaste den halvgyldige forpliktelsestransaksjonen de fikk fra den andre. Hvis Alice gjør det, får Bob seks bitcoins umiddelbart. Hvis Bob gjør det, får Alice fire bitcoins umiddelbart. Men hvem som ennå signerer og kringkaster transaksjonen, må vente 1000 blokker for å låse opp den påfølgende multisig-adressen og kreve de gjenværende bitcoins.
Imidlertid, og dette er det viktigste trikset til en betalingskanal: hverken signere og kringkaste halvparten av transaksjonen i det hele tatt.
Oppdaterer kanalen
Litt senere vil Bob sende Alice en bitcoin tilbake. De vil oppdatere kanaltilstanden, for å gjøre balansen fem-fem igjen. For å oppnå dette gjør Alice og Bob to ting.
Først gjentar begge prosessen som beskrevet ovenfor (bortsett fra at åpningstransaksjonen allerede er registrert på blockchain; den delen hoppes over). Denne gangen tilskriver både Alice og Bob seg fem bitcoins, og begge tilskriver fem bitcoins til funky multisig-adresser. Forholdene for disse multisig-adressene er like, bortsett fra at de krever nye hemmeligheter: både Alice og Bob gir hverandre nye hashes. De signerer begge sin nye halvgyldige forpliktelsestransaksjon, og gir den til hverandre.
For det andre gir Alice og Bob hverandre sine første hemmeligheter, slik de ble brukt i første oppsett.
På dette tidspunktet kunne både Alice og Bob signere og kringkaste den nye “halvgyldige” forpliktelsestransaksjonen de nettopp fikk. Motparten deres ville få fem bitcoins umiddelbart, mens kringkasteren måtte vente 1000 blokker. Som sådan er kanalen oppdatert.
Men hva hindrer Bob i å sende den eldre forpliktelsestransaksjonen i stedet? Denne forpliktelsestransaksjonen førte til en bane som betalte ham seks bitcoins, i stedet for fem ….
Det som stopper Bob er selvfølgelig hans første hemmelighet, som han nå har gitt Alice.
Bob kan ikke trygt signere og kringkaste den eldre forpliktelsestransaksjonen lenger, fordi Alice nå kjenner Bobs første hemmelighet. Hvis Bob skulle signere og kringkaste denne forpliktelsestransaksjonen, ville han umiddelbart sende fire bitcoins til Alice … og han måtte vente 1000 blokker for å kreve sine egne seks bitcoins. Det er et problem, for nå som Alice kjenner hemmeligheten hans, kan hun bruke denne tiden til å slå Bob for å slå og hevde de andre seks bitcoins også!
Og siden Bob også har Alice’s hemmelighet, gjelder dette like omvendt. Hvis Alice prøver å signere og kringkaste en gammel forpliktelsestransaksjon, kan Bob stjele alle bitcoins i kanalen.
Dette betyr selvfølgelig at både Alice og Bob er sterkt oppmuntret til å spille rettferdig, og bare signere og kringkaste den siste tilstanden til kanalen.
Deretter må denne toveis betalingskanaloppsettet utvides for å tillate betalinger over et nettverk. Dette er dekket i den andre artikkelen i denne serien.
Takk til Rusty Russell og Joseph Poon for ekstra tilbakemelding.