The Lightning Conference, Berlijn

Afgelopen weekend was er in Berlijn een conferentie over het Lightning-netwerk. Er waren meer dan vierhonderd mensen aanwezig, en het was daarmee ook meteen het Lightning-netwerk-evenement van dit decennium.

Het hoge aantal ontwikkelaars, onderzoekers en applicatie-bouwers op deze conferentie was een indicatie dat de Lightning-community de afgelopen jaren enorm is gegroeid. Het is nu moeilijk meer voor te stellen dat het nog maar drie jaar geleden was dat de community bestond uit ongeveer tien ontwikkelaars die in Milaan bij elkaar zaten om het software-protocol vorm te geven.

De conferentie duurde twee dagen, en er werden in twee zalen presentaties gegeven. Daarnaast waren er nog workshops en demo's. Helaas zijn er voor zover bekend alleen opnames gemaakt van de eerste zaal. Die opnames kunnen hier bekeken worden:

<img src="https://img.youtube.com/vi/HtU7ZlxvLL4/0.jpg" alt="Lightning Conference dag 1" width="240" height="180" border="10" /> <img src="https://img.youtube.com/vi/hY-0dqlZsJ0/0.jpg" alt="Lightning Conference dag 2" width="240" height="180" border="10" />

Gebruiksgemak

Er was vrij veel aandacht voor technieken die het gebruiksgemak van Lightning moeten verbeteren. Voorbeelden van besproken technieken zijn:

Watchtowers

Dienstverlening op het netwerk om kanalen van anderen te bewaken op momenten dat die anderen offline zijn. Met watchtowers hoeft een normale gebruiker dus niet meer continu online te zijn, maar dan moeten die watchtowers natuurlijk wel betrouwbaar zijn.

Stuckless payments

Een innovatie van de Japanse ontwikkelaars van de Ptarmigan Lightning-software. In Lightning kan een transactie in theorie lange tijd blijven "hangen" als ergens in het netwerk een node niet goed werkt. Je weet dan als betaler al die tijd niet of de transactie wel of niet door gaat. Bij "stuckless payments" wordt het Lightning-protocol een beetje veranderd, waardoor de software van de betaler een "hangende" transactie onschadelijk kan maken: je weet dan zeker dat de transactie uiteindelijk niet door zal gaan. De software kan de transactie dan veilig via een andere route opnieuw proberen, zonder dat daarvoor gewacht hoeft te worden op de afloop van de hangende transactie.

Atomic Multipath Payments (AMP)

Met AMP kan een betaling gesplitst worden in verschillende Lightning-transacties die elk via een eigen route over het netwerk verstuurd worden, en is het toch zeker dat ze òf allemaal wel, òf allemaal niet slagen: je blijft nooit met een half-voltooide betaling zitten. Op deze manier kan de capaciteit van meerdere kanalen tegelijk gebruikt worden, en wordt de grootte van een transactie niet beperkt door de grootte van een enkel kanaal.

Payment Points

Er worden steeds meer technieken bedacht die mogelijk worden als het Lightning-netwerk in de toekomst gebruik maakt van elliptic curve points in Point Time Locked Contracts (PTLCs), in plaats van hashes in Hash Time Locked Contracts (HTLCs). Het voordeel van points ten opzichte van hashes is dat ze op allerlei manieren te combineren zijn: je kunt ze bijvoorbeeld bij elkaar optellen. Daardoor kunnen in een enkel point allerlei technieken tegelijk gebruikt worden.

Voorbeelden van technieken die van elliptic curve points gebruik kunnen maken:

• Path decorrelation: op verschillende hops in de route wordt een verschillend point gebruikt. Dit verbetert de privacy.
• Proof of Payment: Een hash-waarde bewijst alleen dat iemand heeft betaald. Met payment points kan ook bewezen worden dat de bezitter ook echt de partij is die heeft betaald.
• Scriptless Scripts: Allerlei smart contracts zijn opeens mogelijk op Lightning. De beperking is wel dat er voor Lightning uiteindelijk een lock time op een contract moet zitten, en dat tussenpartijen graag hebben dat die lock time vrij kort is. Dit lijkt dus niet echt geschikt voor contracten die een lange levensduur kunnen hebben.
• Combinaties: Stuckless scripts, AMP en Proof of Payment lijken goed combineerbaar te zijn. Zonder payment points is dit moeilijker of onmogelijk.

Payment points zijn in principe mogelijk op Bitcoin's ECDSA-handtekeningen, maar het algoritme is complex, en de veiligheid is niet optimaal. De ontwikkelaars hopen op de toevoeging van Schnorr-handtekeningen in de onderliggende Bitcoin blockchain: dat moet payment points eenvoudig en veilig realiseerbaar maken.

Andere technieken

Er was ook veel aandacht voor "path finding" algoritmes: manieren hoe Lightning-software op het netwerk een route vindt van betaler naar ontvanger. Ãén van de nieuwe ideeën is bijvoorbeeld Trampoline Routing, waarbij een node het maken van een route (deels) uitbesteedt aan een andere node. Dit maakt het makkelijker voor lichtgewicht nodes (bijv. mobiele apps) om te blijven werken op een steeds groter wordend Lightning-netwerk.

Een ander leuk idee was het voorstel van Olaoluwa Osuntokun ("Roasbeef") voor integratie van Lightning in websites door middel van de HTTP 402 ("Payment Required") error code. En Rusty Russell deed een oproep aan iedereen om ideeën te delen met de Lightning-ontwikkelaars voor de volgende generatie invoices. Voorbeelden van gewenste features: Proof of Payment, refunds, en recurring payments (voor abonnementen en dergelijke). Recurring payments zouden dan wel volledig onder controle van de gebruiker moeten blijven, in tegenstelling tot bijvoorbeeld recurring payments op creditcards.

Dienstverleners op het Lightning-netwerk

Er waren meerdere presentaties over liquiditeit op het netwerk: de huidige toestand van het netwerk, technieken om gebruikers van binnenkomende liquiditeit te voorzien, optimale strategieën voor het maken van nieuwe transactiekanalen, en de "markt" voor liquiditeitsvoorziening die daarmee ontstaat.

Verder werd duidelijk dat verschillende exchanges en makers van wallet-software bezig zijn met Lightning-integratie. Praktijkervaringen werden gedeeld, bijvoorbeeld voor de beveiliging van een Lightning node (maximaliseren van cold storage, minimaliseren van attack surface). Op het gebied van exchanges zijn diverse nieuwe concepten in ontwikkeling, bijvoorbeeld een gedecentraliseerde exchange op basis van atomic swap op Lightning met een stable coin, en een gecentraliseerde, maar wel non-custodial exchange op basis van een dienstverlener die HTLCs aanbiedt op een fiat-rekening, zodat daarmee atomic swap kan worden uitgevoerd.

Conclusie

Het Lightning-netwerk is nu nog vrij experimenteel, maar de community is enorm actief, en voor elk pijnpunt in Lightning lijkt wel een oplossing te zijn. Het Lightning-netwerk gaat in de toekomst een groot aantal nieuwe mogelijkheden bieden, waarschijnlijk zelfs mogelijkheden die we nu nog niet kennen. Deze conferentie gaf een blik in de toekomst, en was daarmee wat mij betreft een groot succes.