Lightning: superconductor in de maak
In eerdere artikelen zijn we uitgebreid ingegaan op de basisprincipes van het Lightning netwerk, waaronder payment channels en bijbehorende HTLC's.
Tot op heden laat de gebruiksvriendelijkheid van het Lightning netwerk nog te wensen over. De Lightning implementaties zijn nog allemaal in de beta fase, waarin het vooral noodzaak is om alle vouwen glad te strijken voor een soepele gebruikerservaring. Er worden gedurende dit proces nieuwe ideeën geopperd om dit te bewerkstelligen.
Watchtowers
Een van de nieuwe ideeën zijn watchtowers. Om het nut van watchtowers te achterhalen dient er eerst begrepen te worden hoe het strafmechanisme binnen Lightning werkt, wat er voor zorgt dat men eerlijk blijft gedurende het onderhouden van een payment channel.
Waar payment channels werken met het bijhouden van de staat — de balans die onderling is afgesproken — van de channels, zorgt het strafmechanisme ervoor dat men niet zonder consequenties een oudere staat van de balans kan broadcasten. Dit zou Alice mogelijk willen doen wanneer zij een betaling heeft gedaan aan Bob. Alice kan door de oude staat van de payment channel te gebruiken haar balans van vóór de betaling terug krijgen. Wanneer men een oudere staat verstuurt naar het bitcoinnetwerk, detecteert het strafmechanisme dit en zorgt ervoor dat de oneerlijke partij de volledige balans over dient te dragen aan de wederpartij, als zijnde een boete. Hierdoor resulteert oneerlijk gedrag dus in verlies van tegoeden.
Om eventuele oneerlijke transacties te detecteren, en zo verlies van tegoeden te voorkomen, dient er een Lightning node online te zijn die dit in de gaten kan houden. Bij zo'n node komt helaas ook alle extra data van de blockchain mee. Het is dus zo goed als onmogelijk om dit volledig soeverein te doen op bijvoorbeeld een mobiele telefoon. Naast de dataopslag van vele gigabytes dien je ook nog eens permanent verbonden te zijn met het netwerk. Hier schieten watchtowers te hulp.
Watchtowers houden voor jou de transacties in de gaten. Het gebruik van een derde partij voor validatie van transacties is vaak niet wenselijk. Het streven is een groot aantal onafhankelijke en zelf gekozen watchtowers te kunnen raadplegen. Deze watchtowers zullen vervolgens melding maken wanneer er iets niet in de haak is. Zo is te voorkomen dat een oudere staat van een payment channel wordt gebruikt door de wederpartij, wat zou kunnen resulteren in een verlies van balans.
Het broadcasten van een oude staat kan, naast door een kwaadwillende wederpartij, ook door een eigen wallet gebeuren. Dit kan voor komen wanneer de eigen wallet niet op de hoogte is van de laatste staat van de payment channel. Bijvoorbeeld wanneer een wallet hersteld dient te worden zonder dat alle actuele data zich in de wallet bevindt. Hierdoor broadcast de wallet mogelijk zonder kwade bedoelingen een oudere staat waardoor het strafmechanisme in werking wordt gesteld, resulterend in een verlies van tegoeden.
eltoo
Eltoo is een door Christian Decker en Rusty Russell geopperde verandering van het strafmechanisme. Waar tot op heden een boete wordt gehanteerd voor het bewust of onbewust broadcasten van een oude staat, zoekt eltoo de oplossing in het uitsluitend mogelijk maken van het broadcasten van de laatste staat. Dit voorkomt dus de behoefte om een straf op te leggen voor het broadcasten van een oude staat. Het grootste voordeel hiervan is dat het hiervoor geschetste probleem, met een niet up-to-date wallet, zich niet meer voor zal doen. Zo zal een Lightning gebruiker zonder kwade intenties tegoeden niet verliezen door het broadcasten van een oude staat.
In bovenstaande afbeelding wordt een voorbeeld getoond van het eltooprotocol. Het laat zien hoe een tussenstaat overgeslagen kan worden door het koppelen van een latere transactiestaat aan een eerdere transactie. Het koppelen is ook mogelijk aan de initiële setuptransactie. Alleen de laatste settlementtransactie kan zo bevestigd worden op de Bitcoin blockchain.
Om eltoo functioneel te krijgen moet er een kleine aanpassing gedaan te worden aan het bitcoinprotocol. SIGHASH_NOINPUT dient geïntroduceerd te worden voor de digitale handtekeningen van bitcointransacties. Deze verandering kan middels een soft fork uitgevoerd worden, mocht men het eens worden over hoe deze verandering het beste geïmplementeerd kan worden.
Splicing
Tot op heden is het betalen via Lightning bij bijvoorbeeld een webshop die slechts directe bitcoinbetalingen accepteert niet mogelijk, zonder eerst de volledige payment channel te sluiten. Splicing maakt het mogelijk om vanuit een Lightning channel direct een onchain transactie te doen, zonder dat de payment channel hiervoor gesloten hoeft te worden. Dit maakt het vastzetten van bitcoins in een payment channel flexibeler doordat deze naast Lightning betalingen ook nog de functionaliteit van een onchain transactie blijft behouden.
Dit is ook vice versa mogelijk; het ophogen van de balans van een payment channel met een onchain bitcoin transactie, zonder het hoeven sluiten van een oude channel en het openen van een nieuwe. Splicing maakt hierbij gebruik van veranderen van de balans van de transactie waarmee de channel werd geopend.
Atomic Multipath Payments (AMP)
Lightning maakt gebruik van een routingmechanisme waarbij bitcoins via meerdere hubs verstuurd kunnen worden. Een hub kan slechts de hoeveelheid bitcoins doorsturen die zich in de wallet van de hub zelf bevindt. Het Lightning netwerk faciliteert snelle en kleine transacties tegen minimale kosten. Doordat een Lightning wallet gezien kan worden als een portemonnee met kleingeld voor de dagelijkse koffie, is het lastig om grotere bedragen te versturen. Dit komt doordat elke hub voldoende balans dient te hebben om de bitcoins bij de begunstigde te krijgen, wanneer er geen directe payment channel in stand is gebracht.
AMP maakt het mogelijk om een grotere betaling in kleinere delen op te splitsen en deze via meerdere routes naar de begunstigde te sturen, waarna de ontvanger de betaling als één ontvangt. Zo kan een groot bedrag toch door kleinere hubs worden doorgestuurd.