By Bitcoin Tijdschrift - 6 maanden geleden - Leestijd: 6 minuten
Time-outbomen: een oplossing voor het schalen van Lightning-netwerk-LSP's
Een van de grootste inherente beperkingen van het Lightning Network is het beperkte aantal kanalen dat per blok kan worden geopend of gesloten, gegeven de limiet voor de blokgrootte. Ongeacht hoeveel transacties er zo goedkoop buiten de keten kunnen plaatsvinden, dit is een fundamenteel knelpunt dat beperkt hoeveel mensen daadwerkelijk realistisch gezien het Lightning Network kunnen gebruiken. Zelfs de whitepaper van Lightning Network kwam tot de conclusie dat in een scenario waarin de hele wereldbevolking van 7 miljard mensen Lightning gebruikte, met slechts twee on-chain transacties per jaar per persoon, Bitcoin zou 133 MB-blokken nodig hebben om Lightning te laten werken. Dit is geen probleem dat buiten het linkerveld ligt, of een onvoorspelbaar probleem; het was een beperking van het protocolontwerp die vanaf dag één volledig werd begrepen.
Een deel van het plan om dit probleem aan te pakken is altijd het idee geweest van kanaalfabrieken, d.w.z. een soort kanaal waaraan meer dan twee gebruikers deelnamen. Dit was altijd de richting waarin dingen moesten gaan om Lightning en Bitcoin zonder een toename van de blokgrootte, maar het probleem is dat het oplossen van het probleem van voetafdrukken in de keten een hele reeks andere problemen met zich meebrengt. In de eerste plaats verandert er niets fundamenteels aan de eis om tussenstaten af te dwingen als een tegenpartij niet meer reageert. Dit heeft gevolgen voor de toegevoegde waarde. Het hele punt van een kanalenfabriek is dat bijvoorbeeld twintig mensen één UTXO kunnen delen en de liquiditeit daarbinnen met de andere twintig mensen kunnen herschikken zoals zij dat willen. Zodra iemand de keten op niet-coöperatieve wijze afsluit, begint dit dat doel te belemmeren.
Als ik mijn kanaal sluit in een kanalenfabriek, sleep ik een aantal mensen met me mee de fabriek uit. Denk aan een fabriek als een Merkle-boom, er is één UTXO bovenaan, en die splitst zich off-chain in tweeën, en die splitsen zich in tweeën, enz. totdat we bij ieders individuele kanalen komen. Zodra ik mijn kanaal uit de fabriek heb geplukt, is iedereen aan mijn kant van elke splitsing die in de keten plaatsvindt, nu afgesloten van alle anderen in de fabriek. Ze kunnen hun liquiditeit niet langer in dat deel van de groep reorganiseren als iedereen meewerkt.
Een ander groot probleem is dat je, zelfs om er een te starten, iedereen in het begin online moet hebben om alle transacties vooraf te ondertekenen. Als je twintig mensen in een fabriek wilt, moet iedereen online zijn om hem te starten. Als je duizend mensen wilt, moeten duizend mensen online zijn, enz.
Dit maakt kanaalfabrieken tot een grote ontwerpruimte vol met veel problemen om op te lossen. We lossen dus een bestaand probleem voor Lightning op, maar maken er een aantal nieuwe. Klinkt mij als techniek.
Time-out bomen
Het recente voorstel van John Law, Time-out bomen, probeert een oplossing te bieden voor het enige kernprobleem van kanaalfabrieken. Ik zou een time-outboom niet echt een kanaalfabriek willen noemen, eerder een ‘protofabriek’, maar het biedt een mogelijke oplossing voor het probleem van het openen en sluiten van enorme hoeveelheden kanalen zonder het probleem van niet-coöperatieve sluitingen te introduceren, waardoor de gebruik van de fabriek voor andere gebruikers. Het vereist CHECKTEMPLATEVERIFY (CTV) en een Lighting Service Provider (LSP) om functioneel te kunnen werken.
Een Timeout Tree is in wezen een kanaalfabriek die wordt gegarandeerd door convenanten, zonder de mogelijkheid om de manier te veranderen waarop de liquiditeit buiten de keten wordt gereorganiseerd nadat deze is gemaakt, met een speciale ontsnappingsclausule. Een LSP, we zullen ze Bob noemen, speelt de rol van het overbruggen van incidentele gebruikers naar het bredere Lightning Network. Bob kan munten nemen die hij beheert en een CTV-boom creëren die één enkele UTXO creëert die zich ontvouwt om kanalen te openen voor een willekeurig aantal gebruikers van zijn LSP-service. Het leuke van CTV is dat dit mogelijk is zonder dat iedereen tegelijkertijd online is. Bob kan eenvoudigweg iedereen de oorspronkelijke kanaalstatus één voor één laten ondertekenen en deze vasthouden totdat iedereen het kanaal heeft ingesteld, en het geld gewoon in de CTV-boom steken als hij voor elke gebruiker kanalen heeft ingesteld.
Hiermee wordt het probleem opgelost dat iedereen tegelijkertijd online moet zijn om de "fabriek" op te zetten en Lightning te gaan gebruiken. Vanwege CTV kan Bob, zodra hij munten in de boom heeft uitgegeven om de Lightning-kanalen van iedereen op te zetten, (nog) niet terugtrekken en de munten pakken. Nu die eerste UTXO in de CTV on-chain is bevestigd, kan iedereen zijn kanalen als open beschouwen en bestaat er geen risico dat ze dubbel worden uitgegeven.
Nu het laatste deel, het sluiten van de kanalen. Hoewel het openen ervan slechts één UTXO on-chain vereist vanwege CTV, zou het sluiten ervan nog steeds vereisen dat de hele CTV-boom zich on-chain ontvouwt, zodat iedereen zijn kanaalstatussen kan indienen, toch? Fout. Dit is het Time-outgedeelte van Time-outbomen. Elke tak in de Time-outboom heeft een scripttak waar Bob na een tijdslot al het geld kan verzamelen.
Een diagram van een time-outboom.Nu weet ik zeker dat je denkt: "Wat!?" Dit is het echte genie van hoe dit voorstel werkt. Omdat Bob de UTXO's op de keten zelf zonder iemand anders kan opruimen na de tijdslot, hebben deze kanalen allemaal een vervaldatum, tenzij gebruikers daadwerkelijk de hele boom ontvouwen en de echte kanaalfinanciering op de keten bevestigen. Hierdoor kan Bob iets leuks doen: wanneer dat tijdslot eraan komt, kan hij een gloednieuwe Time-outboom openen met alle gebruikers van de huidige, en hen al hun geld van de aflopende boom naar de nieuwe laten verplaatsen, geheel uitgeschakeld. -chain op Lightning en veeg vervolgens de enkele on-chain UTXO van de laatste boom.
Dit maakt een efficiënte afsluiting van al deze kanalen in de keten mogelijk. Het enige probleem dat nu nog rest is het afdwingen van een HTLC on-chain als de andere partij niet meer meewerkt. Nou… dat is in dit geval niet echt een probleem, of beter gezegd: het is een alles of niets-kwestie. De reden dat kanalen moeten worden gesloten om een HTLC af te dwingen, is dat de andere partij van het kanaal niet meer reageert tijdens het routeren ervan. In een Timeout Tree is de tegenhanger van elke gebruiker Bob. Dus als Bob, zolang hij eerlijk is, niet reageert op het updaten van een mislukte of succesvolle HTLC voor de ene gebruiker, reageert hij ook niet voor een andere gebruiker. In dat geval kan iedereen nog steeds vóór de time-out zijn kanalen in de keten sluiten en stoppen met het gebruik van Bob's LSP.
Afsluiten
Gebruikers zullen nog steeds vergoedingen moeten betalen voor interacties in de keten, daar is geen ontkomen aan, en een volledige Timeout Tree die de keten niet-coöperatief afsluit zou een grote en dure voetafdruk in de keten zijn, maar dit is uiteindelijk een probleem elk kanaalsysteem met meerdere partijen zal dit moeten adresseren. Timeout Trees heeft echter overtuigende oplossingen voor het coöperatieve geval van zowel het openen als sluiten van een enorm meerpartijenkanaal zonder het vertrouwensmodel van het systeem te degraderen tot iets voogdijachtigs.
John heeft zelfs in zijn meest recente versie van het artikel een regeling voorgesteld waarbij gebruikers voldoende gestraft kunnen worden voor niet-coöperatieve sluitingen om de kosten van Bob te dekken voor het uiteindelijk opruimen van een aantal gefragmenteerde boom-UTXO's na de time-out. Mogelijk zijn er manieren om het omgekeerde te doen als de inactiviteit of oneerlijkheid van Bob de oorzaak is dat gebruikers hun deel van de boom niet-coöperatief moeten sluiten.
Uiteindelijk is dit echter een heel concreet en specifiek voorstel voor een kanaalfabriekontwerp dat daadwerkelijk probeert de echte problemen van gebruik en implementatie aan te pakken in plaats van een half gedefinieerd en vaag concept. Dat is een enorme vooruitgang als het gaat om het aanpakken van de schaalbeperkingen van Lightning op de lange termijn.
Originele bron: Bitcoin Magazine