Lightning: hoe werkt het eigenlijk?
Het Lightning netwerk is een nieuwe technologie voor Bitcoin waarmee bitcointransacties razendsnel en spotgoedkoop zijn. Maar wat is het Lightning netwerk precies en hoe werkt het? In dit artikel duiken we dieper in op de technische werking.
De basis
Allereerst is het handig om even terug te gaan naar de basis. Het is namelijk handig om weer even helder te hebben wat men met Bitcoin poogt te bereiken en hoe dit netwerk globaal werkt. Met die principes helder voor de geest kunnen we de noodzaak van Lightning beter duiden.
Om gebruik te kunnen maken van Bitcoin dient men een node te hebben of er een te kunnen benaderen. Zo’n node heeft een kopie van de blockchain. Ook ontvangt het de nieuw verzonden transacties die wachten om in een blok opgenomen te worden en uiteindelijk de blokken die aan de blockchain toegevoegd zijn. Dit zijn alle benodigdheden om, zonder op gegevens van anderen te vertrouwen, zelf op het netwerk te kunnen participeren.
Doordat de capaciteit van het bitcoinnetwerk beperkt is kunnen transactiekosten echter oplopen op momenten waarop er veel transacties worden verstuurd. Nu het streven naast vertrouwensloosheid ook kostenbesparing is, willen we deze pieken in kosten ontlopen. Hiervoor kan een tweede, cryptografische betaallaag gebruikt worden; het Lightning netwerk.
In deze conceptomschrijving zal de theorie en werking van het Lightning netwerk worden toegelicht.
Lightning netwerk
Het Lightning netwerk werkt op basis van payment channels. Dit zijn multisignature adressen waarbij de balans op het adres tussen partijen onderling aangepast kan worden, zolang deze nog niet naar het bitcoinnetwerk verstuurd wordt. Een soort gezamenlijke rekening dus, maar waarbij je alleen je eigen geld zou mogen uitgeven. Een multisignature adres is een bitcoinadres waarbij meerdere privésleutels nodig zijn om een transactie te kunnen versturen. Denk hierbij aan een kluis waar twee verschillende sleutels voor nodig zijn; met slechts één van de sleutels kan de kluis niet geopend worden.
In de onderstaande illustratie wordt de constructie van een payment channel afgebeeld. Alex heeft 0,1 bitcoin op zijn bitcoinadres staan. Beau heeft geen bitcoins, maar wel een bitcoinadres en de bijbehorende privésleutel.
Wanneer Alex en Beau een payment channel willen openen, creëren zij samen een multisig adres, waarbij zowel de privésleutel van Alex als die van Beau nodig zijn om een transactie te mogen verzenden. Alex stuurt zijn 0,1 bitcoin naar het multisig adres, met de voorwaarden dat Beau al een transactie ondertekent die 0,1 bitcoin terug overmaakt naar Alex met een nLockTime van 30 dagen. Dit is dus een transactie naar een multisig adres die daadwerkelijk bevestigd wordt op de bitcoinblockchain.
nLockTime is een methode waarbij een transactie vastgezet kan worden, zodat deze niet eerder kan worden uitgegeven dan het aantal bepaalde dagen. In dit geval kan de refund transactie van de 0,1 bitcoin dus pas na 30 dagen naar het bitcoinnetwerk verzonden worden. Deze refund transactie garandeert dat Alex in staat is om de bitcoin terug te krijgen wanneer Beau plotseling zou verdwijnen en daardoor geen transactie meer kan ondertekenen. Wanneer je één van de twee sleutels kwijtraakt van de kluis, kom je namelijk de kluis niet meer in. In de echte wereld zijn er vaak wel oplossingen om een kluis alsnog in te komen zoals een goede slijptol of een reservesleutel, maar met digitale encryptie is het op dit moment zo goed als onmogelijk om om naderhand nog een oplossing te vinden.
Wanneer Beau de refund transactie heeft ondertekend, heeft Alex dus de garantie dat wanneer hij er ook zijn handtekening onder zet, de transactie daadwerkelijk verzonden kan worden en hij de 0,1 bitcoin terug zal ontvangen.
Payment channel
Dankzij payment channels hoeven nodes niet meer alle individuele
transacties bij te houden en te verifiëren. In plaats daarvan houden
payment channels de mutaties van balansen tussen de participanten onderling bij. In dit geval doen Alex en Beau dit dus samen voor de transacties die er tussen hen plaatsvinden.
In onderstaande illustratie wordt de werking van deze mutatie van de balans getoond. Het multisig adres is inmiddels dus, zoals hiervoor omschreven, aangemaakt en de refund transactie is door Beau ondertekend.
Na een lange werkdag zijn Alex en Beau de kroeg ingedoken. Beau heeft de hele avond de drankjes voorgeschoten en Alex wil zijn schulden aflossen door 0,01 bitcoin naar Beau te sturen. Dit doen ze door een nieuwe transactie aan te maken en door Alex te laten ondertekenen vanuit hun multisig adres, waarbij er 0,09 bitcoin naar Alex gaat en 0,01 bitcoin naar Beau. Dit adres heeft geen nLockTime, waardoor deze transactie per direct al naar het bitcoinnetwerk gestuurd zou kunnen worden. Het heeft alleen nog de handtekening van Beau nodig, waarna de transactie op de blockchain opgenomen kan worden.
Zolang Beau dit doet voordat de refund transactie mogelijk wordt, heeft zij de garantie dat de 0,01 bitcoin haar kant op kan komen op elk gewild moment. Deze mutatie kan zo vaak plaats vinden als ze zelf willen; de overige 0,09 bitcoin zou in een keer naar Beau ‘gestuurd’ kunnen worden of in meerdere betalingen van 0,00000001 bitcoin. Dit is onbeperkt mogelijk, tot er uiteindelijk een transactie naar het bitcoin netwerk wordt verzonden.
Eenrichtingsverkeer
Voorgaande situatie maakt het mogelijk om de balans binnen een payment channel één kant op te laten schuiven, namelijk van Alex naar Beau. Nu bestaat er een situatie waarbij er weer bitcoins van Beau naar Alex zouden moeten verschuiven, bijvoorbeeld voor een etentje die Alex ditmaal heeft voorgeschoten. Doordat er in de voorgaande eenrichtingsverkeer geen gebruik gemaakt werd van een nLockTime, zou Beau de voorgaande mutatie naar het netwerk kunnen sturen. Hierdoor publiceert ze dus eigenlijk een eerdere transactie waarop ze méér bitcoin had, namelijk in de tijd waarin het etentje en de terugbetaling nog niet plaats hebben gevonden. Zoals eerder gezegd; het verzenden van een door beiden ondertekende transactie naar het bitcoinnetwerk en de volgende bevestiging daarvan, zorgt voor een eindafrekening van de payment channel, of zoals eerder genoemd de gezamenlijke rekening. Er is vervolgens geen mogelijkheid meer voor Alex om terugbetaling van het etentje op te eisen met de ondertekende mutatie van Beau.
Eenrichtingsverkeer voorkomt dat een wederpartij een voorgaande ‘staat’ met een gunstigere balans naar het netwerk stuurt. De ontvangende partij heeft er immers alleen maar baat bij om de laatste balans te versturen; daarop heeft ze het meeste bitcoin ontvangen. Echter is eenrichtingsverkeer natuurlijk ongewenst als het om betalingen gaat. Je wilt ook wel eens wat bitcoin toesturen naar degene waarvan jij bitcoin van ontvangt.
Bilateraal
Om het twee kanten op mogelijk te maken, komt nLockTime weer om de hoek kijken. Net zoals bij de refund transactie, kan nLockTime garanderen dat een nieuwe transactie eerder kan worden verzonden. Hierdoor ontstaat de garantie dat deze ook uitgevoerd kan worden voordat een transactie met een oudere balans verstuurd kan worden.
In onderstaande illustratie wordt weergeven hoe het tweerichtingsverkeer tot stand kan komen met behulp van nLockTime. Van de 0,1 bitcoin van Alex wordt weer een transactie aangemaakt waarbij 0,01 bitcoin naar Beau zal gaan. Waar de transactie in voorgaande situatie geen nLockTime meekreeg, is dat nu wel het geval. De n is het aantal dagen. Een nieuwe mutatie dient een n minder te zijn dan de vorige mutatie. Zo kan gegarandeerd worden dat een oude transactie in geen geval eerder naar het netwerk verzonden kan worden dan een nieuwere mutatie. In dit geval kan de transactie dus na 29 dagen verzonden worden, één dag eerder dan de refund transactie.
Nu kan Alex nogmaals 0,01 bitcoin naar Beau sturen. Hier hoeft de nLockTime niet voor veranderd te worden; beide transacties kunnen dus gelijktijdig naar het bitcoinnetwerk verzonden worden door Beau. Echter heeft zij, zoals eerder beschreven, enkel belang in het versturen van de transactie waarbij zij de meeste bitcoins zal ontvangen. Oftewel: de laatste staat van de payment channel.
Nu stuurt Beau weer 0,01 bitcoin terug naar Alex. Hier is dus van belang dat de nLockTime wel verandert; een dag minder dan de vorige mutatie. Er dient gegarandeerd te worden dat Alex de 0,09 kan claimen, en niet achterblijft met 0,08 wanneer Beau de voorgaande transactie eerder naar het bitcoinnetwerk kan sturen.
In onderstaande illustratie zie je de mutatie die weer heeft plaatsgevonden; 0,01 bitcoin terug naar Alex en een nLockTime van 28 dagen. Eén minder dan de vorige mutatie met een nLockTime van 29 dagen.
Dit is het principe van een payment channel, waarbij in theorie een onbeperkt aantal mutaties aan transacties kan worden gecreëerd. Men kan dus zelf de nLockTime kiezen, waarbij er ook vanaf een miljard dagen terug geteld zou kunnen worden. Echter is dit geen verstandige keuze. Mocht de wederpartij verdwijnen, dan geeft de nLockTime de garantie dat de transactie na verloop van n dagen alsnog verzonden kan worden, zonder participatie van deze wederpartij. De n is dus het maximumaantal dagen waarbij de bitcoins vast zouden kunnen staan wanneer er geen coöperatie plaatsvindt of de wederpartij verdwijnt.
Betalingsnetwerk
Nu zijn directe payment channels handig, maar nog niet ideaal. Het is handiger wanneer je niet voor elke partij waarmee je zaken doet of interactie hebt een payment channel hoeft te openen. Het komt vaak genoeg voor dat je slechts eenmalig een betaling aan een ander doet. Dan verdwijnt het voordeel van een payment channel ten opzichte van een normale bitcointransactie. Idealiter wil je dat jij een kanaal open hebt staan met slechts één andere partij, en een betaling toch bij iemand aan kan komen waar je geen directe verbinding mee hebt. Het zogeheten ‘routen’ – het doorsturen van betalingen – is mogelijk door gebruik te maken van HTLC’s: hashed time lock contracts.
In onderstaande illustratie is de situatie afgebeeld waarin Alex een kanaal open heeft met Beau en Beau een kanaal open heeft met Chris. Nu zal geschetst worden hoe een betaling van Alex naar Chris mogelijk is.
Het lijkt logisch dat Beau hier gewoon de tussenpersoon is die de betaling zo weer over de schutting kan gooien. Maar we hadden het streven om dit allemaal vertrouwensloos te doen. Wat weerhoudt Beau er in deze situatie van om de bitcoins die voor Chris bestemd zijn niet gewoon zelf te houden? De oplossing is zoals eerder benoemd een fenomeen wat hashed time lock contract wordt genoemd.
Hashed lock contracts
Het eerste deel van de HTLC is het hashed lock contract, de HLC. In onderstaande en volgende illustraties wordt de letter H voor hash gebruikt en R staat voor een willekeurig (random) getal.
Alex en Chris zijn overeengekomen dat er 0,01 bitcoin van Alex naar Chris zal moeten gaan. De eerste stap wordt genomen door Chris. Hij zal een willekeurig getal — de R — moeten maken. Deze R mag alles zijn en is dus volledig aan Chris zelf om te bepalen. Vervolgens maakt hij van dit zelf gekoze getal R een hash, de H. Deze hash stuurt hij naar Alex toe.
Nu Alex de hash (H) van Chris heeft ontvangen, maakt hij een transactie naar Beau aan. Alex en Chris hebben immers geen direct kanaal tussen hen beiden. De transactie die Alex maakt, heeft de voorwaarde dat deze pas geldig is wanneer Beau het willekeurige getal — de R — kan tonen die bij de hash — de H — hoort. Beau onderneemt dezelfde stappen en maakt een transactie aan richting Chris, waarbij ook Chris de R moet tonen voordat de transactie geldig kan worden verklaard en dus de bitcoins geclaimd zouden kunnen worden.
Chris, die zelf het willekeurige getal R heeft bepaald, kan nu dus de transactie van Beau claimen. Deze R geeft hij dus aan Beau als bewijs. Beau weet nu dus ook het willekeurige getal, die hij aan Alex kan laten zien, waardoor ook zijn transactie geldig wordt en de bitcoin geclaimd kan worden. De transacties vinden dus eigenlijk in omgekeerde richting plaats, van Chris naar Beau, en van Beau naar Alex. Het voorkomt dat een tussenpartij een betaling achter kan houden; hij stuurt immers zelf al een transactie, en claimt deze vervolgens terug.
Er zit hier echter nog één kink in de kabel, betreft de vertrouwensloosheid. Als Chris weigert het willekeurige getal prijs te geven, dan kan hij net zolang wachten totdat het kanaal tussen Alex en Beau is verlopen. Wanneer dat het geval is, zal Beau niet meer in staat zijn om Alex de R te overhandigen en de bitcoin te claimen. Doordat Chris wel nog een kanaal heeft met Beau, kan Chris simpelweg de R overhandigen aan Beau waardoor hij de bitcoin ontvangt. Beau zit vervolgens met de R, maar zonder bitcoins die zij terug kan claimen bij Alex. Zo raakt ze in de praktijk dus bitcoin kwijt; ze heeft wel al de betaling voorgeschoten, maar kan dat voorschot niet meer terugeisen. Om dit probleem op te lossen komt de eerder gebruikte factor tijd weer langs. Hierdoor ontstaat de hash time lock contract.
Hashed time lock contracts
In de onderstaande illustratie wordt de situatie met behulp van de HTLC getoond. In dit geval maakt Dani de R aan, en stuurt zij de hash hiervan naar Alex. Hij wil Dani namelijk een klein presentje in de vorm van satoshi’s sturen.
Nu wordt er naast de HLC ook een eerder uitgelegde nLockTime toegevoegd, wat het een HTLC maakt. Alex maakt weer een voorwaardelijke transactie aan, waarbij de R getoond moet worden. Als extra tijdsvoorwaarde geldt dat dit tonen binnen 3 dagen moet gebeuren. Beau doet weer hetzelfde met 2 dagen lock time. Chris stelt de voorwaarde dat Dani haar willekeurige getal binnen één dag kenbaar maakt. Wordt er niet aan het gestelde termijn voldaan, dan kan de transactie niet meer geclaimd worden.
Doordat de transacties in omgekeerde volgorde ongeldig worden, kan er geen situatie ontstaan zoals die eerder bij Beau ontstond. Als Dani de R niet binnen een dag toont, zal ze de bitcoins van Chris niet meer kunnen claimen. Hetzelfde geldt voor Chris, die zal de R namelijk niet meer ontvangen van Dani omdat ze te laat is. Dit werkt zo de keten door, waarbij alle transacties niet meer te claimen zijn, en iedereen met zijn eigen oorspronkelijke balans achter blijft.
Wordt de R wel vrijgegeven? Dan kan de betaling van Alex naar Dani voldaan worden, doordat het willekeurige getal R de omgekeerde weg bewandelt en zo de transacties, en dus de bitcoin, claimbaar maakt. Dit allemaal op een vertrouwensloze manier, met de snelheid van het internet.
Om met een eigen bitcoinnode gebruik te kunnen maken van het Lightning netwerk dien je een extra Lightning node te draaien, of een applicatie te gebruiken die zelf al gebruik maakt van het netwerk. Zo'n Lightning node houdt de bitcoinnode en bijbehorende blockchain in de gaten. Dit doet het om nieuw geopende of juist sluitende payment channels in de gaten te houden. Ook zorgt de Lightning node dat het het betalingsnetwerk, bestaande uit payment channels tussen alle participerende partijen, in kaart heeft. Zo kan het zelf routes vinden om betalingen over te verzenden.
Lightning node
Benieuwd hoe je zelf kan participeren op het Lightning netwerk en overweeg je zelf een node op te zetten? Bekijk dan de uitlegvideo’s van De Nodezaak waarin stap voor stap de werking én de praktijk wordt uitgelegd.
Sinds de lancering van het Lightning Network in 2018 is de transactiecapaciteit hard gegroeid. Momenteel is de totale liquiditeit in het netwerk gestegen naar 3915,71 BTC, een nieuw record.
