Facebook
Twitter
Lightning Network er sandsynligvis den mest forventede teknologiske innovation, der skal implementeres oven på Bitcoin. Betalingslaget, der først blev foreslået af Joseph Poon og Tadge Dryja for omkring et år siden, lover at understøtte et næsten ubegrænset antal off-chain-transaktioner blandt brugerne næsten uden omkostninger – samtidig med at den udnytter den sikkerhed, der tilbydes af Bitcoin.
Mindst tre virksomheder – Poon og Dryja’s Lyn, Blockstream og Blockchain – arbejder i øjeblikket med implementeringer af teknologien. Men få uden for denne lille teknologiske frontlinje forstår fuldt ud, hvordan “fremtiden for mikrobetalinger” er indstillet til at øge Bitcoins muligheder.
I denne tredelte serie lægger Bitcoin Magazine de grundlæggende byggesten i Lightning Network ud og viser, hvordan de passer sammen for at realisere dette kommende protokollag.
Denne første del af serien fastlægger de nødvendige byggesten og viser, hvordan disse kan kombineres for at skabe “smarte kontrakter”, som kan anvendes til at realisere Lightning Network’s første krav: en tovejs betalingskanal.
(Bemærk: Enhver med en solid forståelse af Bitcoin kan springe over byggestenene.)
Byggesten nr. 1: ubekræftede transaktioner
I sin kerne består Bitcoin-protokollen af transaktioner, der typisk er knyttet til tidligere transaktioner og potentielt til fremtidige transaktioner. Hver transaktion indeholder input, der henviser til adresser, bitcoins sendes fra, og output, der henviser til adresser, der sendes bitcoins til. Derudover skal input omfatte kravene til at sende bitcoins, som signaturer, der viser “ejerskab” af input-adresserne. Outputs fastlægger i mellemtiden de nye krav, der skal inkluderes i input af en efterfølgende transaktion.
Som en af dets nøglefunktioner er Lightning Network bygget op fra mere eller mindre regelmæssige Bitcoin-transaktioner. Det er bare, at disse transaktioner typisk ikke faktisk sendes over Bitcoin-netværket. I stedet gemmes de lokalt på brugerens noder – men de kan til enhver tid sendes over netværket.
Byggesten # 2: Dobbeltforbrugsbeskyttelse
Den anden byggesten til Lightning Network kræver sandsynligvis ikke meget forklaring, da det uden tvivl er raison d’être for Bitcoin i sig selv: beskyttelse med dobbelt forbrug. Hvis to transaktioner (eller: input) er afhængige af den samme output, kan kun én bekræfte.
Den vigtige ting at huske på her er, at selv ubekræftede transaktioner kan være modstridende, hvilket betyder, at kun én nogensinde kan bekræfte.
Byggesten # 3: Multisig
Den tredje byggesten i Lightning Network er også ligetil: multisignature (multisig) adresser. (Eller mere generelt: P2SH-adresser.)
Multisig-adresser er Bitcoin-adresser, der – som navnet antyder – kræver flere private nøgler for at “låse op” og bruge bitcoins fra. Multisig-adresser kan oprettes under alle mulige forhold. For eksempel at kræve to ud af tre mulige taster eller femten ud af femten eller næsten enhver anden kombination.
Lightning Network bruger ofte to ud af to (2-af-2) multisig-opsætninger. At låse op bitcoins fra 2-of-2 multisig-adresser kræver to underskrifter fra to dedikerede nøgler.
Byggesten # 4: Time-Locks
Den fjerde byggesten er tidslåsen. Tidslåse kan “låse bitcoins op” i en output for at gøre dem brugbare (kun inkluderet i en efterfølgende input) på et eller andet tidspunkt i fremtiden.
Der er to forskellige typer tidslåse: den absolutte type, kaldet CheckLockTimeVerify (CLTV), og den relative type, CheckSequenceVerify (CSV). CLTV låser bitcoins op til en (mere eller mindre) konkret tid i fremtiden: en faktisk tid og dato eller en bestemt blokhøjde. CSV bruger i stedet relativ tid. Når en CVS-output er registreret på blockchain, tager det en bestemt mængde blokke fra dette tidspunkt, før bitcoins kan bruges igen.
Byggesten # 5: Hashværdier og hemmeligheder
Den femte og sidste byggesten – kryptografi – er den mest grundlæggende byggesten i selve Bitcoin. Men i Lightning Network anvendes det på en ny måde.
Kort sagt er en “værdi” eller “hemmelighed” en lang og unik talstreng, som det er praktisk umuligt at gætte, selv for en computer med uendelige forsøg. Med en særlig beregning kan denne værdi (eller hemmelighed) “hashes” til en anden række tal, en “hash”. Og her er tricket: Enhver, der kender værdien, kan let gengive hashen. Men dette fungerer ikke omvendt; det er en envejsgade.
Dette trick kan bruges i Bitcoin selv, igen til at “låse bitcoins op.” (Faktisk er det virkelig, hvordan Bitcoin fungerer.) For eksempel kan en hash inkluderes i en output og kræve, at den efterfølgende input inkluderer den tilsvarende værdi for at være brugbar.
Den første udfordring: tovejs betalingskanaler
Allerede før Lightning Network blev præsenteret, havde begrebet betalingskanaler eksisteret i nogen tid. Typiske betalingskanaler er nyttige til visse formål, men også begrænsede: de er retningsbestemte. Alice kan betale Bob flere transaktioner uden for kæden, men Bob kan slet ikke betale Alice gennem den samme kanal.
Som et nøglefunktion i Lightning Network foreslog Poon og Dryja tillid til tovejs betalingskanaler.
Åbning af kanalen
For at oprette en tovejs betalingskanal skal begge involverede parter først blive enige om en åbningstransaktion. Denne åbningstransaktion bestemmer, hvor mange bitcoins hver deponerer i kanalen.
Lad os sige, at Alice vil sende en bitcoin til Bob. Da Alice og Bob forventer at handle hyppigere, beslutter de at åbne en tovejs betalingskanal og bruge denne til at sende bitcoin. (At sende en hel bitcoin er sandsynligvis meget for en betalingskanal, da disse kan være mere nyttige til mikropayments – men det er fuldt ud muligt.)
For at åbne kanalen sender Alice og Bob hver fem bitcoins til en 2-af-2 multisig-adresse. Dette er “åbningstransaktion.” Bitcoins kan kun bruges fra denne adresse, hvis både Alice og Bob underskriver en efterfølgende transaktion.
Derudover skaber Alice og Bob begge en hemmelighed (en række numre) og udveksler hash.
Alice opretter nu straks en efterfølgende transaktion fra åbningstransaktionen. Dette er en “forpligtelsestransaktion”. Med forpligtelsestransaktionen sender Alice fire bitcoins til sig selv og seks bitcoins til en anden multisig-adresse. Denne anden multisig-adresse er lidt funky. Det kan låses op af Bob alene, men først efter at 1000 ekstra blokke er blevet udvundet, efter at det er inkluderet i blockchain; det inkluderer en CSV-lås. Eller det kan åbnes af Alice alene, men kun hvis hun også inkluderer den hemmelighed, som Bob lige nu har givet hende hash for. (Naturligvis har Alice ingen idé om, hvad denne hemmelighed er – hun kender kun hash – så der er ingen måde, hvorpå hun kan bruge denne mulighed lige nu.)
Alice underskriver sin afslutning på denne forpligtelsestransaktion. Men hun sender det ikke! I stedet giver hun det til Bob.
I mellemtiden gør Bob det samme, men spejlet. Han opretter også en forpligtelsestransaktion, hvorfra han sender seks bitcoins til sig selv og fire til en funky ny multisig-adresse. Alice kan låse op for denne adresse, hvis hun venter yderligere 1000 blokke, eller Bob kan låse den op med Alice ved hjælp af sin hemmelighed.
Bob underskriver denne halvdel og giver den til Alice.
Efter al denne udveksling af “halvgyldige” forpligtelsestransaktioner og hash af hemmeligheder underskriver og sender de begge åbningstransaktionen for at sikre, at den registreres i blockchain. Kanalen er nu officielt åben.
På dette tidspunkt kunne både Alice og Bob underskrive og udsende den halvgyldige forpligtelsestransaktion, de fik fra den anden. Hvis Alice gør det, får Bob seks bitcoins med det samme. Hvis Bob gør det, får Alice straks fire bitcoins. Men hvem der underskriver og sender transaktionen bliver nødt til at vente 1000 blokke for at låse den efterfølgende multisig-adresse op og kræve de resterende bitcoins.
Imidlertid, og dette er det vigtigste trick for en betalingskanal: hverken underskrive og udsende deres halvdel af transaktionen overhovedet.
Opdatering af kanalen
Lidt senere vil Bob sende Alice en bitcoin tilbage. De vil opdatere kanaltilstanden for at gøre saldoen fem-fem igen. For at opnå dette gør Alice og Bob to ting.
For det første gentager begge processen som beskrevet ovenfor (bortset fra at åbningstransaktionen allerede er registreret på blockchain; den del springes over). Denne gang tilskriver både Alice og Bob sig selv fem bitcoins, og begge tilskriver fem bitcoins til funky multisig-adresser. Betingelserne for disse multisig-adresser er ens, bortset fra at de kræver nye hemmeligheder: både Alice og Bob forsyner hinanden nye hashes. De underskriver begge deres nye halvgyldige forpligtelsestransaktion og giver den til hinanden.
For det andet giver Alice og Bob hinanden deres første hemmeligheder, som de blev brugt i den første opsætning.
På dette tidspunkt kunne både Alice og Bob igen underskrive og udsende den nye “halvgyldige” engagementstransaktion, de lige har fået. Deres modpart ville få fem bitcoins med det samme, mens tv-selskabet skulle vente 1000 blokke. Som sådan opdateres kanalen.
Men hvad forhindrer Bob i at sende den ældre engagementstransaktion i stedet? Denne forpligtelsestransaktion førte til en sti, der betalte ham seks bitcoins i stedet for fem ….
Hvad der stopper Bob er selvfølgelig hans første hemmelighed, som han nu har givet Alice.
Bob kan ikke sikkert underskrive og udsende den ældre engagementstransaktion mere, for Alice kender nu Bobs første hemmelighed. Hvis Bob skulle underskrive og udsende denne forpligtelsestransaktion, ville han straks sende fire bitcoins til Alice … og han skulle vente 1000 blokke for at kræve sine egne seks bitcoins. Det er et problem, for nu da Alice kender sin hemmelighed, kunne hun bruge denne tid til at slå Bob til punch og hævde de andre seks bitcoins også!
Og da Bob også har Alice’s hemmelighed, gælder dette lige så omvendt. Hvis Alice forsøger at underskrive og udsende en gammel forpligtelsestransaktion, kan Bob stjæle alle bitcoins i kanalen.
Dette betyder selvfølgelig, at både Alice og Bob er stærkt tilskyndet til at spille fair, og kun nogensinde underskriver og sender kanalens seneste tilstand.
Dernæst skal denne tovejs betalingskanalopsætning udvides for at tillade betalinger via et netværk. Dette er dækket af den anden artikel i denne serie.
Tak til Rusty Russell og Joseph Poon for tilføjet feedback.