Payment channels: de basis voor Lightning

Payment channels maken het mogelijk om een groot aantal transacties tussen twee partijen te doen, zonder direct de blockchain te belasten en zonder een compromis te doen op het gebied van vertrouwen. Payment channels dienen hiermee als de basis voor het Lightning Netwerk. In dit artikel beschrijven we hoe payment channels werken.

Het probleem

Wanneer twee partijen regelmatig betalingen naar elkaar willen doen, kan het gunstig zijn om deze transacties uit te voeren zonder een fee te betalen voor het opnemen van elke individuele transactie in de blockchain. Een optie zou bijvoorbeeld zijn om de twee partijen samen een rekening bij te laten houden van wie elkaar welk bedrag verschuldigd is, een soort WieBetaaltWat. Het probleem met deze insteek is dat beide partijen niet verzekerd zijn van daadwerkelijke betaling in de toekomst, en beide partijen elkaar moeten vertrouwen.

Payment channels zijn ontstaan als oplossing voor dit probleem. Payment channels gebruiken de beperkte (maar toch krachtige!) middelen die Bitcoin biedt om geheel vertrouwensloos een groot aantal betalingen tussen twee partijen uit te voeren. Payment channels zorgen er niet alleen voor dat betalingen vertrouwensloos blijven, maar ook zijn betalingen onmiddellijk definitief: er hoeft niet gewacht te worden op een bevestiging in de blockchain om zeker te zijn van ontvangst. Daarnaast vinden de betalingen off-chain plaats, transacties worden dus niet direct in de blockchain opgenomen. Hierdoor zijn transacties goedkoop en snel: er hoeft niet voor elke transactie een fee betaald te worden en de snelheid van het internet is de enige beperking.

Het ontwerp

Er zijn twee verschillende soorten payment channels: unidirectional payment channels en bidirectional payment channels. Om het begrip van payment channels goed op te bouwen beginnen we met een simpele variant van een unidirectional payment channel. Dat wil zeggen, een payment channel waar betalingen alleen van partij A naar partij B verstuurd worden. Voor het gemak noemen we in dit verhaal de twee partijen die betalingen naar elkaar zullen gaan doen Alice (A) en Bob (B).

Bij een multi-signature transactie kunnen meerdere partijen toegang hebben tot de bitcoins die bij het adres horen. De bitcoins kunnen echter alleen worden uitgegeven wanneer 2-van-2 eigenaren tekenen met hun eigen privé-sleutel. Dit kan ook in theorie ook 2-van-3, 5-van-7 of 50-van-100 zijn.

In het unidirectional payment channel worden alleen betalingen van Alice naar Bob gedaan, en niet andersom. Voor het opzetten van het payment channel is één gewone bitcointransactie nodig: een initïele transactie om het payment channel te voorzien van bitcoins die Alice aan Bob gaat betalen. Deze transactie doet Alice naar een multi-signature adres waar zowel Alice als Bob een privé-sleutel voor hebben.

Voordat Alice betalingen gaat doen aan Bob, tekent Bob een transactie voor 1 BTC vanaf het multi-signature adres terug naar een adres van Alice. Deze transactie heeft een nLockTime van 30 dagen. Deze transactie dient als refund-transactie: mocht Bob niet meer bereikbaar zijn, dan kan Alice altijd over 30 dagen haar 1 BTC terugkrijgen. Vervolgens stuurt Bob deze transactie naar Alice.

nLockTime, ook wel locktime genoemd, is een restrictie op een bitcointransactie die ervoor zorgt dat de transactie pas op een bepaald moment in de toekomst kan worden uitgegeven. Bijvoorbeeld een tijdstip in de toekomst of vanaf een bepaald block in de toekomst.

Het payment channel is nu "opgezet". Alice kan nu betalingen uit gaan voeren naar Bob. Wanneer Alice een betaling doet van bijvoorbeeld 0.1 BTC naar Bob, dan maakt Alice een transactie aan waarin zij de 1 BTC uit het multi-signature adres verdeeld tussen zichzelf en Bob. Deze transactie bevat (in een unidirectional payment channel) geen locktime en wordt getekend door Alice. Alice verstuurd de transactie niet naar het bitcoinnetwerk, maar stuurt de transactie off-chain (gewoon via het internet) naar Bob.

Op dit moment heeft Bob een transactie in handen die 0.1 BTC waard is. Hij zou deze transactie in theorie naar het bitcoinnetwerk kunnen sturen om zijn 0.1 BTC te claimen. Bob wacht hier echter nog even mee, want Alice zal hem in de toekomst nog meer betalingen gaan sturen. Hiermee wordt voorkomen dat de blockchain voor elke transactie belast wordt. Laat duidelijk zijn dat zowel Alice als Bob elkaar niet hoeven te vertrouwen: mocht Bob verdwijnen, dan krijgt Alice na 30 dagen haar 1 BTC terug, en geen van de partijen kan de 1 BTC uit het multi-signature adres uitgeven zonder de digitale handtekening van de andere partij. Ook kan Alice haar betaling niet ongedaan maken.

Even later wil Alice nog een betaling doen aan Bob. Wederom wil Alice 0.1 BTC naar Bob sturen. Het totale bedrag dat naar Bob gestuurd moet worden is nu dus 0.2 BTC. Dit geschied op dezelfde manier als de vorige transactie: Alice tekent een transactie zonder locktime en stuurt deze naar Bob.

Nu besluit Bob dat hij genoeg betalingen heeft ontvangen van Alice en dat hij zijn 0.2 BTC wil claimen. Dit kan Bob doen door de transactie van 0.2 BTC die hij van Alice heeft ontvangen naar het bitcoinnetwerk te sturen. In theorie zou Bob, in plaats van de transactie voor 0.2 BTC, de transactie met een waarde van 0.1 BTC kunnen claimen. Het is echter in het voordeel van Bob om zoveel mogelijk bitcoins te claimen, dus Bob stuurt de transactie voor 0.2 BTC naar het bitcoinnetwerk. Besef wel dat Bob maar éeen van de transacties kan claimen: als de bitcoins eenmaal uitgegeven zijn kunnen ze niet opnieuw worden uitgegeven.

Met het publiceren van de transactie naar het bitcoinnetwerk is de transactie van 0.2 BTC naar Bob voldaan, nadat deze bevestigd is door de miners. Om de betalingen te doen waren uiteindelijk twee gewone bitcointransacties nodig: één om het payment channel op te zetten, en één om het payment channel te sluiten (het claimen van de bitcoins door Bob).

In dit geval was het dus niet helemaal de moeite waard om de betalingen via een payment channel te doen, omdat Alice ook twee gewone transacties van 0.1 BTC naar Bob had kunnen doen. Het is echter duidelijk dat er ook honderden, duizenden, of wel honderduizenden transacties via het payment channel hadden kunnen lopen. Omdat er per transactie geen fees betaald hoeven te worden, kunnen ook bedragen van bijvoorbeeld 0.00000001 BTC per keer verstuurd worden. Wanneer dit 1 miljoen keer is gedaan, heeft Bob 0.01 BTC ontvangen, waarvoor hij vervolgens slechts één transactie naar het bitcoinnetwerk hoeft te sturen om de bitcoins te claimen. Echte microbetalingen dus, voor een fractie van de kosten van gewone transacties.

Het unidirectional payment channel is gelimiteerd tot betalingen van Alice naar Bob. Het zou mooi zijn als Alice en Bob over en weer betalingen kunnen doen via hetzelfde payment channel. Ook dit is mogelijk, maar het vergt een iets andere configuratie. De initiële opzet is hetzelfde: Alice stuurt 1 BTC naar een multi-signature adres en Bob maakt een refund-transactie aan voor Alice met 30 dagen locktime.

Als Alice een betaling van 0.1 BTC wil gaan doen aan Bob, ziet de transactie die Alice aan Bob geeft er iets anders uit. De transactie wordt wederom getekend door Alice, maar bevat deze keer een locktime van 29 dagen. Deze locktime garandeert dat Bob de transactie van Alice eerder zal kunnen claimen dan dat Alice de refund-transactie kan claimen.

Vervolgens kan Alice wederom een transactie naar Bob sturen om een tweede betaling te doen, nogmaals voor 0.2 BTC. Deze tweede transactie die Alice doet, waarmee zij het bedrag dat naar Bob gestuurd wordt verhoogd van 0.1 BTC naar 0.2 BTC, heeft dezelfde locktime als de eerste: 29 dagen. Tot zover verlopen de transacties hetzelfde als in het scenario met een unidirectional payment channel, maar Bob heeft nog geen betaling terug aan Alice gedaan.

Bob heeft inmiddels 0.2 BTC van Alice ontvangen en kan met deze 0.2 BTC een betaling gaan doen aan Alice. Stel nu dat Bob een betaling van 0.1 BTC wil doen naar Alice. Dit is mogelijk, en door dit te doen "verandert" Bob de richting van het payment channel. Waar voorheen alleen Alice transacties verstuurde, zal Bob nu een transactie gaan aanmaken. Bob neemt het bedrag van 0.2 BTC dat hij reeds ontvangen heeft en trekt hier de betaling die Bob naar Alice wil doen van af. Bob maakt dus een nieuwe transactie aan van 0.1 BTC naar zichzelf, en 0.9 BTC naar Alice, Bob ondertekent deze transactie en stuurt de transactie naar Alice. Het verschil met voorgaande transacties is dat de transactie van Bob naar Alice een locktime van 28 dagen bevat.

Met een locktime van 28 dagen op de transactie van Bob naar Alice is Alice er zeker van dat zij deze transactie zal kunnen claimen voordat Bob de kans krijgt om de transactie van 0.2 BTC te claimen - deze transactie heeft immers een locktime van 29 dagen. Bob zal dus een dag langer moeten wachten voordat hij deze transactie kan claimen.

Alice besluit nu dat zij het payment channel wil sluiten en publiceert de transactie die zij van Bob heeft ontvangen naar het bitcoinnetwerk, voordat de locktime van 29 dagen op de andere transacties verloopt. Het zal de oplettende lezer opvallen dat de transactie die Alice publiceert een locktime van 28 dagen heeft; zij kan de bitcoins dus nog niet uitgeven. Bij het sluiten van het payment channel hebben de deelnemers de optie om wel of niet samen te werken. Werken ze wel samen, dan stuurt Bob een nieuwe transactie voor dezelfde hoeveelheid BTC naar Alice, maar dit maal zonder locktime. Alice kan nu direct deze transactie publiceren. Wanneer Alice en Bob niet samen willen werken zal Alice tot het einde van de 28-daagse locktime moeten wachten.

Met het sluiten van het payment channel zijn alle transacties gedaan. Wederom waren er twee normale bitcointransacties nodig voor het openen en sluiten van het payment channel. Het is duidelijk dat, door het korter maken van de locktime, er in twee richtingen vertrouwensloos betalingen plaats kunnen vinden. De hoeveelheden verstuurde BTC en het aantal dagen locktime uit deze scenario's zijn puur gekozen als makkelijk voorbeeld: in de realiteit zullen de bedragen variëren en de locktime op transacties minder ver uit elkaar liggen. Een payment channel is het best geschikt voor kleinere bedragen, waarbij het wenselijk is om dure fees te vermijden. Voor het versturen van grote bedragen zal het betalen van de fee voor een normale transactie waarschijnlijk de voorkeur hebben.

De voordelen

• Transacties zijn onmiddellijk definitief. Bij het ontvangen van een transactie zijn Alice en Bob zeker van een betaling in de toekomst. Er hoeft niet gewacht te worden op een bevestiging in de blockchain.
• Echte micro-betalingen worden mogelijk. Het is op dit moment te duur om een transactie van 0.00000001 BTC te versturen. Met payment channels wordt het mogelijk om veel van dit soort transacties te doen zonder hier hoge fees voor te betalen. De transacties worden simpelweg "opgespaard" en eenmaling op de blockchain verrekend bij het sluiten van het payment channel.
• Ondanks de voordelen blijft het doen van transacties vertrouwensloos. Geen van de betrokken partijen hoeft elkaar te vertrouwen. Dit is een belangrijke eigenschap, want het bitcoinnetwerk draait om het zover mogelijk verminderen, dan wel elimineren van de noodzaak voor vertrouwen.

Het Lightning Netwerk

Payment channels zijn de basis voor het Lightning Netwerk. Het is namelijk mogelijk om een payment channel tussen Alice (A) en Bob (B) te koppelen aan een payment channel tussen Bob en Carol (C), welke weer gekoppeld kan worden aan een payment channel tussen Carol en Dave (D). Zo wordt het mogelijk dat Alice een betaling doet aan Carol of Dave, zonder dat Alice een payment channel open heeft met een van beiden. Dit is de oorsprong van het Lightning Netwerk. Hoe payment channels uitgebreid kunnen worden tot het Lightning Netwerk zullen we in een volgend artikel toelichten.