Het is ongeveer een jaar geleden sinds de drie implementatieteams voor het Lightning Network samenwerkten om een specificatie voor het protocol te maken. Ondertussen zijn zowel de specificatie als de drie implementaties stabiel en bruikbaar geworden, en is het tijd om vooruit te kijken. We willen het protocol verbeteren, nieuwe functies toevoegen, het versimpelen, en problemen oplossen.
Een van de belangrijkste innovaties van Lightning was het off-chain mechanisme om een nieuw staat te kunnen onderhandelen en te zorgen dat de oude staat niet op de blockchain verschijnt. Vandaag brengen we onze nieuwste paper uit voor een nieuw en versimpeld update-mechanisme voor layer 2 protocollen genaamd eltoo.
Hoe werkt eltoo?
We kunnen off-chain onderhandeling zien als een contractuele overeenkomst tussen een aantal partijen, en settlement (het on-chain in ontvangst nemen van bitcoins) als het indienen van de bewijsstukken aan de rechtbank om te beslissen over de laatste staat. De rechtbank is in dit geval de blockchain. Gezien alle updates off-chain plaatsvinden, moet er een manier zijn voor de on-chain rechtbank om alle bewijsstukken in te zien voordat er een beslissing wordt gemaakt. In het geval dat een deelnemer een contract met een oude staat on-chain probeert af te dwingen, is er een mechanisme nodig om tijd te gunnen voor de tegenpartij om aan te tonen dat er een nieuwere staat is. De rechtbank moet wachten tot er geen reactie meer is op de laatst bekendgemaakte staat, en deze wordt vervolgens definitief. Verrassend genoeg heeft de bitcoin-blockchain al bijna alle benodigdheden om dit layer 2 protocol te creëren.
Figuur 1: Een voorbeeld van het eltoo-protocol. De tussenliggende staten kunnen worden overgeslagen door een latere update-transactie te verbinden aan een eerdere, of door direct de setup-transactie te gebruiken. Alleen de laatste settlement-transactie kan worden bevestigd op de blockchain.
In eltoo wordt elke staat vertegenwoordigd als een set van twee transacties: een update-transactie die de output van het contract uitgeeft en een nieuwe output creëert, en een settlement-transactie die de nieuwe update-output uitgeeft en de balans opsplitst volgens de overeengekomen distributie. De outputs hebben een script die het toelaat om direct een nieuwe update-transactie te verbinden, of om na een configureerbare tijdsperiode een settlement-transactie te verbinden. Als de deelnemers kiezen om een update te maken voor de tijdsperiode voorbij is, kunnen ze een nieuwe update-transactie maken die de vorige output uitgeeft en de bijbehorende settlement-transactie onbruikbaar maakt (een soort "double spend").
Dit herhaaldelijke proces van het overschrijven van een voorgaande staat met een nieuwere staat, creëert een lange ketting van update-transacties die uiteindelijk wordt beëindigd met de laatste settlement-transactie. Deze naïeve methode heeft echter één groot nadeel: om settlement te bereiken moeten we de hele reeks aan update-transacties naar de blockchain sturen. Dit is net zo efficiënt als het versturen van on-chain transacties. Het belangrijkste aspect van eltoo is dat we alle tussentijdse updates kunnen overslaan door de laatste update-transactie direct te verbinden aan het contract. Om deze functionaliteit mogelijk te maken, stellen we voor om een nieuwe SIGHASH-flag genaamd SIGHASH_NOINPUT toe te voegen. Dit maakt het mogelijk om een input te verbinden met elke output die een geldig script heeft. Gezien alle output-scripts van voorgaande update-transacties geldig zijn voor latere input-scripts, kunnen we een latere update verbinden aan een eerdere update en zo dus alle tussentijdse updates overslaan. Onze paper bevat de volledige constructie van het protocol, inclusief details over hoe de scripts zijn opgebouwd.
Lightning verbeteren
Wat we hierboven hebben beschreven is een update-mechanisme dat het mogelijk maakt voor eindpunten van een betalingskanaal (payment channel) om herhaaldelijk de balans aan te passen en tevens geavanceerde constructies zoals HTLC's aan de staat toe te voegen.
Het oorspronkelijke ontwerp van de originele paper van Lightning had een vergelijkbaar update-mechanisme, dus proberen we Lightning te vervangen met dit voorstel? Absoluut niet!
Figuur 2: Een diagram met de verschillende sub-protocollen die bij Lightning horen.
De huidige specificatie van het Lightning Network is niet een enkel protocol, maar een hele stapel protocollen die allemaal hun eigen verantwoordelijkheden hebben. eltoo is niet bedoeld om al deze Lightning-protocollen te vervangen. Het is een vervanging voor het huidige update-mechanisme en behoudt de achterwaartse compatibiliteit met de andere protocollen.
eltoo heeft andere eigenschappen dan het straf-mechanisme uit de originele paper van Lightning. Als een deelnemer zich misdraagt, wordt hij financieel gestraft. Met eltoo is dit niet nodig en kan via het update-mechanisme gewoon de laatste staat worden afgedwongen. Dit heeft een stel belangrijke implicaties voor de toepasbaarheid en veiligheid van de protocollen die gebruikmaken van het update-mechanisme.
Het is namelijk zo dat in eltoo alle participanten dezelfde transacties bezitten, terwijl het straf-mechanisme asymmetrie vereist tussen de deelnemers om de reactie af te kunnen stemmen op de misdragende partij. Deze verandering elimineert wat wij in Lightning toxische informatie noemen. Toxische informatie zijn transacties die horen bij verouderde staten. Als deze informatie vrijkomt, kan de deelnemer worden gestraft en geld verliezen. Dit gebeurt niet alleen als een deelnemer expres valsspeelt, maar ook als een node per ongeluk een update vergeet (bijvoorbeeld door een back-up te herstellen). Met eltoo is dit niet meer mogelijk, want settlement gebeurt alleen met de laatst overeengekomen staat (ofwel; eltoo heeft geen straf-mechanisme).
Het gegevensbeheer voor de deelnemers is ook versimpeld onder het nieuwe systeem. Het is niet meer nodig om de hash pre-images van HTLC's te bewaren voor oude staten, want de bijbehorende settlement-transactie kan nooit naar de blockchain worden gestuurd. Het enige wat bewaard hoeft te worden is de laatste update-transactie, de bijbehorende settlement-transactie, en mogelijke HTLC's die erbij horen. Settlement is ook nog eens versimpeld: verbind de laatste update-transactie aan de setup-output en wacht tot de timeout afloopt om vervolgens de settlement-transactie te sturen.
We kunnen de update-outputs combineren met SIGHASH_SINGLE om het mogelijk te maken om aanvullende inputs en outputs aan de update-transactie toe te voegen tijdens settlement. Dit lijkt misschien maar een kleine verandering, maar het stelt ons in staat om het transactietarief voor miners toe te voegen wanneer settlement plaatsvindt, waardoor dit niet van tevoren bepaald hoeft te worden. In de huidige implementaties moeten we mogelijk maanden van tevoren bepalen wat het transactietarief gaat zijn voor on-chain settlement. Dit betekent dat we rekening moeten houden met mogelijke tariefstijging in de toekomst, waardoor we aan de hoge kant moeten gokken om veilig te zijn. Nu we het tarief later pas hoeven vast te stellen, hoeven we er niet meer over te onderhandelen en kunnen we altijd nog meer betalen als het gekozen tarief te laag blijkt te zijn.
Dankzij het gebruik van feature flags waarmee nodes bij het verbinden met een peer aan kunnen geven welke functies ze ondersteunen, kan eltoo stapsgewijs worden uitgerold op het huidige netwerk. Het is niet nodig om een geheel nieuw netwerk op te starten.
Meer dan Lightning
Omdat eltoo een algemeen update-mechanisme is voor layer 2, kan het voor meer worden gebruikt dan alleen Lightning. Het is bijvoorbeeld mogelijk om off-chain contracts met zeven deelnemers te maken, en met Schnorr signatures is zelfs elke hoeveelheid deelnemers mogelijk.
Channel factories, zoals gepresenteerd door Burchert et al., is hier een voorbeeld van. Dit is een schaalbare manier om meerdere betalingskanalen te bouwen op een enkele on-chain transactie en ze dynamisch aan te passen of verplaatsen zonder de blockchain aan te raken.
De weg naar eltoo
Voordat we eltoo kunnen implementeren, moeten we eerst een kleine verandering aanbrengen aan bitcoin: de introductie van SIGHASH_NOINPUT voor signatures. Dit is een aantal maanden geleden voor het eerst besproken in de context van het gebruik van watchtowers (wachttorens) om Lightning-kanalen te beveiligen, maar nooit formeel voorgesteld. Het formele voorstel is nu te vinden in de paper van eltoo.
We nodigen de community uit om ons voorstel te overwegen en te participeren in de discussie. We hopen dat we consensus kunnen vinden voor het gebruik van SIGHASH_NOINPUT, zodat het na acceptatie toegevoegd kan worden in een toekomstige soft fork voor het script van bitcoin. Dit zou de weg vrijmaken voor een versie van het Lightning Network die betrouwbaarder en eenvoudiger is, met een nieuwe update-mechanisme dat ook kan worden gebruikt voor andere doeleinden.