Payment channels: HTLCs

In het vorige artikel over payment channels als basis voor het Lightning Netwerk hebben we besproken hoe payment channels het mogelijk maken om een groot aantal transacties tussen twee partijen te doen, zonder direct de blockchain te belasten en zonder compromis te doen op het gebied van vertrouwen. In dit artikel breiden we de bidirectional payment channels uit naar Hashed Time-Lock Contracts (HTLCs).

De volgende stap richting het Lightning Netwerk

In het vorige artikel hebben we beschreven hoe unidirectional en bidirectional payment channels werken. Maar, hoewel krachtig voor betalingen tussen twee partijen, zijn de mogelijkheden van een simpel bidirectional payment channel beperkt wanneer we betalingen in een geheel netwerk van gebruikers mogelijk willen maken. Het is namelijk alleen mogelijk betalingen te doen tussen de partijen die een payment channel met elkaar open hebben. HTLCs zijn een uitbreiding aan bidirectional payment channels die het het mogelijk maken om betalingen te doen naar partijen waarmee niet direct een payment channel is geopend. HTLCs zijn daarmee de volgende stap in de basis voor het Lightning Netwerk.

Betalingen doorspelen

Met een bidirectional payment channel kunnen Alice en Bob gemakkelijk, goedkoop, en snel een groot aantal betalingen aan elkaar doen. Maar wat nu als Alice een betaling wil doen aan Carol, of aan Dave, waarmee zij geen payment channel geopend heeft? Het zou inefficiënt en duur zijn als Alice voor elke betaling die zij naar een andere partij wil doen een apart payment channel moet openen. Wat we wel kunnen doen, is Alice gebruik laten maken van de reeds bestaande payment channels tussen andere partijen.

Door Alice gebruik te laten maken van het reeds geopende payment channel tussen Bob en Carol, kan Alice een betaling naar Carol sturen via Bob. Hiermee wordt voorkomen dat de blockchain belast moet worden, en blijven de transacties snel en goedkoop.

Er zijn echter een paar vertrouwensproblemen met deze aanpak, en laat dat nou net zijn wat we willen vermijden. Er zijn twee problemen die meteen duidelijk worden:

1. Wat weerhoudt Bob ervan om de betaling van 0.01 BTC voor zichzelf te houden? Er is niks geïmplementeerd dat Bob ertoe dwingt om de betaling door te versturen naar Carol. We zullen Bob moeten vertrouwen dat hij eerlijk handelt.
2. Hoe weten we dat Carol eerlijk zal zijn over de betaling die zij ontvangen heeft? Zij kan immers bij ontvangst van de betaling, als Bob inderdaad eerlijk handelt, beweren dat de betaling die zij ontvangen heeft niet van Alice komt, maar van een andere partij. Er is geen manier om te garanderen dat Carol eerlijk zal handelen.

Deze problemen vallen echter op te lossen door slim gebruik te maken van de scripting functionaliteit die Bitcoin biedt. We kunnen namelijk de betalingen van Alice naar Bob en van Bob naar Carol afhankelijk laten zijn van bepaalde condities. Dit noemen we een Hash-Locked Contract (HLC).

Een hashfunctie is een algoritme dat, gegeven een bepaalde input, een unieke output genereert. Vanuit de gegenereerde output kan niet terug berekend worden wat de input was, maar het is wel mogelijk om, gegeven de input, te controleren dat de eerder getoonde output klopt door het algoritme nogmaals uit te voeren met de input.

Bij een HLC genereert Carol een willekeurig getal R en neemt hier de hash (H) van. Vervolgens stuurt Carol de hash H naar Alice.

Alice maakt vervolgens een transactie van 0.01 BTC naar Bob aan onder voorwaarde dat Bob R kan tonen die bij de gegeven H hoort. Bob doet hetzelfde met een transactie naar Carol: hij stuurt een transactie van 0.01 BTC naar Carol, wederom onder voorwaarde dat Carol R kan tonen.

Carol is nu in staat om de betaling die zij van Bob heeft ontvangen te claimen; Carol is immers die enige die de juiste R voor H weet. Wanneer Carol de betaling van Bob claimt, geeft zij R prijs aan Bob, waarmee Bob op zijn beurt de betaling die hij van Alice heeft ontvangen kan claimen. Deze constructie zorgt ervoor dat:

1. Bob er niet voor kan kiezen de betaling van Alice zelf te houden; hij moet immers eerst de betaling aan Carol voldoen voordat hij de betaling van Alice kan claimen, en
2. Alice zeker weet (en kan bewijzen) dat haar betaling naar Carol is gegaan; de betaling was immers alleen te claimen met de juiste R voor de gegeven H die van Carol af kwam.

Er is echter ook met deze oplossing nog een vertrouwensprobleem:

• Als Carol weigert om R prijs te geven, dan kan zij de betaling mogelijk zo lang uitstellen dat het payment channel tussen Alice en Bob verloopt. Wanneer dit gebeurt zou Carol de betaling van Bob kunnen claimen, zonder dat Bob nog de mogelijkheid heeft om de betaling van Alice te claimen. Bob loopt dus een risico dat hij geld verliest en moet erop vertrouwen dat Carol meewerkt.

Dit probleem valt af te vangen door wederom slim gebruik te maken van de scripting functionaliteit die Bitcoin biedt en een tijdsfactor toe te voegen aan het HLC: een Hashed Time-Lock Contract (HTLC). We stellen nu dat Bob drie dagen de tijd heeft (of een andere hoeveelheid tijd) om de juiste R te tonen aan Alice. Doet Bob dit niet binnen drie dagen, dan vervalt de betaling (lees: het contract) van 0.01 BTC die Alice naar Bob heeft gestuurd.

We kunnen het voorbeeld nu uitbreiden om het al wat meer op een netwerk te laten lijken. Bob en Carol zijn in dit voorbeeld willekeurige tussenpartijen en representeren een willekeurige hoeveelheid tussenpartijen die de betaling van Alice naar Dave faciliteren. In de praktijk kan dit één enkele tussenpartij zijn, of een willekeurig aantal tussenpartijen. Wat van belang is dat er een route mogelijk is van Alice naar Dave, zodat de betaling kan plaatsvinden. In dit scenario maakt Dave het willekeurige getal R aan en stuurt de hash van R, H, naar Alice.

Vervolgens maakt Alice voor de betaling naar Bob een HTLC aan met, naast de voorwaarde dat R nodig is om het bedrag te claimen, de voorwaarde dat de betaling binnen drie dagen voltooid moet zijn. Bob doet hetzelfde met Carol, maar stelt de tijd waarbinnen de betaling voltooid moet zijn in op twee dagen. Tot slot doet Carol hetzelfde met Dave, met de voorwaarde dat de betaling binnen één dag voltooid moet zijn.

Nu is Dave in staat om de betaling die Alice aan hem wil maken te claimen; Dave weet immers de R die nodig is om te voldoen aan de voorwaarden van het HTLC. Maar wat als Dave besluit niet meer mee te werken of wegvalt uit het netwerk? Er ontstaat dan geen risico voor een van de tussenpartijen op het verlies van de betaling die zij gereserveerd hebben. De gehele reeks HTLCs zal in omgekeerde volgorde sluiten, beginnend met het HTLC tussen Carol en Dave omdat deze de kortste tijdsvoorwaarde heeft. Hiermee is bij elke stap het risico voor de tussenpartijen gemitigeerd en kunnen er vertrouwensloos (micro-) betalingen door een netwerk verstuurd worden.

De voordelen:

• (Bijna) alle betalingen kunnen off-chain plaatsvinden, waardoor de Bitcoin blockchain niet belast wordt en de druk op het netwerk verlicht wordt.
• Er ontstaat een netwerk van betalingen bovenop het Bitcoinnetwerk. Het Lightning Netwerk maakt slim gebruik van de middelen die Bitcoin biedt en opereert als een tweede laag bovenop Bitcoin. Dit draagt bij aan het behouden van de decentraliteit en vertrouwensloosheid van het Bitcoinnetwerk zelf.
• Door betalingen door het netwerk te leiden is het niet nodig om vaak en veel nieuwe payment channels te openen: een enkele, of een paar, payment channels per persoon volstaat om iedereen in het netwerk te kunnen bereiken.
• Doordat de transacties off-chain plaatsvinden zijn deze:
  • Goedkoop - er hoeft niet voor elke transactie een fee aan de miners betaald te worden.
  • Micro - het is door de lage kosten mogelijk om echte micro-betalingen uit te voeren van één enkele satoshi (0.00000001 BTC) en zelfs kleiner.
  • Instant - betalingen via het Lightning Netwerk zijn instant, er hoeft niet gewacht te worden op een bevestiging.

Het Lightning Netwerk in essentie

De unidirectional en bidirectional payment channels, de hash-locked contracts (HLC) en de hashed time-locked contracts (HTLC) zoals beschreven in dit en het vorige artikel zijn in essentie de gehele basis van het Lightning Netwerk. Er komt uiteraard nog veel meer kijken bij het daadwerkelijk implementeren van deze theorie, zoals het oplossen van het probleem hoe de betalingen op een efficiënte manier door het netwerk van payment channels geleid kunnen worden. Maar het vernuftige gebruik van de mogelijkheden die de scripting functionaliteit van Bitcoin biedt om een netwerk van off-chain bitcoinbetalingen mogelijk te maken is de grote innovatie. Innovatie die inmiddels al bijna realiteit is.