Bitcoin Lightning #25: Verbetering van Lightning betaling met eltoo protocol
|
Het is een oud verhaal: ‘Bitcoin is traag, log en ongeschikt voor wereldwijde betalingen’. Er zijn echter verschillende schaalbaarheidsoplossingen bedacht. Eentje daarvan is het Bitcoin Lightning Network, en hier staan we in de Hup Lightning serie bij stil.
In dit artikel gaan we iets dieper de materie in met het onderwerp eltoo. Dit is een protocol dat nog niet in werking is getreden, maar wat wel een enorme verbetering zal (kunnen) zijn.
Veilig opschalen van Bitcoin
Het Lightning Network staat ook wel bekend als een ‘layer 2’ oplossing waarbij de betalingen buiten de blockchain op een off-chain manier worden gedaan. Het gebruikt multi-sig wallets waardoor er Bitcoin (BTC) opgesloten staat. Vervolgens kun je de state van de balans van deze wallet aanpassen voordat de Bitcoin in deze wallet weer beschikbaar en claimbaar wordt.
Vergelijk het met een bar rekening waarbij je telkens de onderste balans van de lijst gebruikt als je de eindbetaling doet.
Deze state moet echter wel betrouwbaar zijn. Je wilt niet dat iemand een balans van een aantal betalingen geleden gebruikt als uitgangspunt om een kanaal (in zijn voordeel) te sluiten.
In Lightning moet je dus de garantie hebben dat de meest recente versie van de ‘bar rekening’ gebruikt. Om dit te kunnen regelen is er een concept bedacht dat eltoo heet. Ironisch: het klinkt als de Engelse uitspraak van L2, wat duidt op layer two.
Eltoo is nog niet doorgevoerd, maar een verbetering van het huidige LN-penalty protocol dat nu wordt gebruikt. Hierbij krijgen kwaadwillende personen een ‘penalty’ als ze proberen vals te spelen. Eltoo is een ‘Lightning Improvement Proposal (LIP).
Een “penalty scenario” betekent dat de persoon die een oude invalid state naar het netwerk stuurt, zijn funds zal kwijtraken. Maar in zo’n geval kan een corrupte ‘channel database’ grote gevolgen krijgen. In zo’n geval stuurt een node onwillens een foutieve state en raakt daardoor toch onbedoeld zijn sats kwijt.
Eltoo
Eltoo is een ‘replacement mechanism’ voor tweedelaags protocollen. Het introduceert het idee van state numbers en on-chain variant of sequence numbers. Dat klinkt misschien allemaal erg vaag.
Gezien alle updates off-chain gebeuren, moeten we een manier vinden om de bitcoin blockchain op een juiste manier te benaderen.
Je wilt op deze laag (de mainchain) terug kunnen vallen om dit netwerk de stand van zaken te vertellen waarover zij vervolgens een oordeel moet vellen. Eigenlijk kun je de Bitcoin blockchain daarbij zien als rechter die zorgt dat alles tóch eerlijk gebeurt, zonder dat deze rechter je continu in de gaten houdt. Het eltoo en het LN-penalty protocol zijn daarbij de spelregels die tegelijkertijd ook in de gaten houden of je wel netjes ‘speelt’.
Eltoo is een mechanisme dat de final settlement van een betaling omschrijft die in de blockchain moet komen. Het geeft de tegenpartij de kans om een betere en meer recente status van deze bar rekening aan te leveren.
Hierboven zie je een voorbeeld van een uitvoering van het eltoo protocol. De tussentijdse state kan worden overgeslagen om een recentere update over de transactie te koppelen aan de setup transactie.
En alleen de laatste transactie wordt afgewikkeld in de blockchain. En dit is precies wat er voor zorgt dat de mainchain ontlast wordt én waarom je dus enorm veel microbetalingen kunt doen tegen nauwelijks kosten.
Transacties
In eltoo wordt iedere state weergegeven als een set van twee transacties:
De outputs bevatten een script die het toe laat om:
Doe je via het betaalkanaal een betaling vóórdat deze tijd is verstreken? Dan komt er automatisch een nieuwe update transactie, die de vorige output weer uitgeeft en daardoor niet meer valide is.
Op deze manier verklaar je dus herhaaldelijk een vorige state als ongeldig en bereik je een akkoord over de nieuwe state van het betaalkanaal. Zo hou je dus de balans van een kanaal in de gaten.
Maar wat is dan het handige aan dit protocol? Want als je nu de betaling doet, krijg je al deze stappen alsnog in de blockchain en ben je niets opgeschoten. Wat je eigenlijk wilt, is dat je de tussenstappen (alle tussenliggende state) kunt verwijderen uit de reeks van transacties. Dat kan!
Sluiten kanaal
Je wilt de laatste update transactie koppelen aan het contract waarmee je het betaalkanaal hebt geopend. Hiervoor kun je de sighash flag SIGHASH_NOINPUT gebruiken. Dit maakt het mogelijk om een transactie input te koppelen aan iedere andere transactie met een matchend script
Het maakt het mogelijk om een digitale handtekening een transactie te signeren, terwijl je de input hiervan achteraf nog kunt veranderen (terwijl de signature wel valide blijft).
En aangezien alle output scripts van de voorafgaande update transactions gelijk zijn, kun je dus een latere update van hetzelfde script als laatste versie gebruiken.
Dit is dus het ‘update mechanisme’ waarmee de beide partijen van een betalingskanaal hun saldi herhaaldelijk kunnen aanpassen en deze state aan contracten zoals HTLC’s kunnen koppelen, terwijl ze deze dus al hebben ondertekend.
BIP als draft
Er zitten veel meer andere protocollen in het Lightning Network, maar voor nu laten we het even bij deze uitleg van eltoo. Er zijn namelijk ook protocollen die er voor zorgen dat nodes met elkaar communiceren.
En je hebt nu dus LN-penalty, een variant die de oude state wél bewaard en penalties uitdeelt als iemand toch deze oudere state als meest recente status wil gebruiken. Het mooiste zou zijn als dit gewoon niet nodig is, en het gegarandeerd goed gaat. En daarvoor is eltoo dus een verbetering.
De BIP voor deze SIGHASH_NOINPUT is op moment van schrijven nog een draft. En dus kan eltoo op dit moment ook nog niet bestaan.
In de huidige implementatie van het Lightning Network zijn de oudere balansen (of state) niet gegarandeerd veilig. Als je deze probeert te broadcasten zal de cheater te maken krijgen met het LN-penalty protocol. Maar het kan ook mis gaan dor een bug of problemen met backups. Met eltoo kun je dit onbedoelde gevaar voorkomen.
Zodra eltoo is doorgevoerd, wordt de oude state direct gecorrigeerd naar de nieuwste balans. Dit maakt het systeem veel makkelijker en efficiënter om betaalkanalen open te hebben staan.
