By Bitcoin Tijdschrift - 1 jaar geleden - Leestijd: 7 minuten
Een paar manieren waarop we de betalingsroutering van Lightning Network kunnen upgraden
Om uit te groeien tot een protocol dat door de hele wereld kan worden gebruikt, moeten bepaalde schaalverbeteringen voor Lightning worden overwogen.
Het Lightning Network is een goed ontwikkelde, snelgroeiende Layer 2 transactieoplossing op de Bitcoin netwerk. Steeds meer diensten en uitwisselingen integreren het, de liquiditeit die beschikbaar is voor het routeren van betalingen groeit en er worden elk jaar meer toepassingen en manieren ontwikkeld waarop gebruikers ermee kunnen communiceren. Het heeft ook veel problemen die op de lange termijn moeten worden overwonnen:
De schaalbaarheid beperkt hoeveel kanalen tegelijkertijd on-chain kunnen worden geopend of gesloten. Er is een probleem met de minimumgrootte Hash Time Locked-contract (HTLC) neemt toe naarmate de on-chain-vergoedingen ook stijgen, omdat het economisch moet zijn om af te wikkelen. Er zijn ook een hele reeks privacykwesties.Een belangrijk onderwerp dat vaak wordt besproken, zijn de liquiditeitsvereisten voor het routeren van betalingen. Om een betaling succesvol te routeren, moet er een koppeling van kanalen zijn, helemaal van de afzender naar de ontvanger die voldoende liquiditeit aan de rechterkant van het kanaal heeft om de betaling door te kunnen geven. Dit maakt de beslissing waar u uw munten op het netwerk wilt inzetten erg belangrijk. Het betekent ook dat de totale hoeveelheid liquiditeit die mensen bereid zijn in te zetten een soort bovengrens is voor hoeveel waarde het netwerk kan verwerken.
Waar dit uiteindelijk op neerkomt, is dat wanneer je een kanaal opent, je besluit dat geld vast te zetten, zodat het alleen kan worden gebruikt om betalingen naar die kanaalpartner te sturen, en naar wie ze in de grafiek zijn verbonden. Ja, uiteindelijk is het idee van het Lightning Network dat je, door genoeg hops te maken, een verbinding met bijna overal kunt vinden. De realiteit is echter dat als iemand anders een betaling naar een bestemming kan leiden met minder hops dan u kunt, dat het pad is dat hoogstwaarschijnlijk wordt geselecteerd om de betaling te routeren. Lightning vereist al in hoge mate overcollateralisatie, dwz om een betaling van 1 BTC over 10 hops te routeren, moet 10 BTC aan onderpand worden vergrendeld in betalingskanalen langs die route. De concurrentie over het hebben van goede verbindingen om routeringsinkomsten te genereren, verergert dit door nog meer overbodige zekerheden te stimuleren.
Dit is een probleem dat voortvloeit uit het feit dat Lightning-kanalen uit twee partijen bestaande "buizen" zijn die de waarde gewoon heen en weer kunnen duwen in die twee richtingen. Hier is echter het probleem: het probleem is een beetje denkbeeldig. Betalingen op Lightning gebruiken HTLC's, een script in een Bitcoin output die zegt dat een persoon de output kan claimen en uitgeven door de preimage aan een hash te onthullen, of een andere persoon kan de output claimen en uitgeven nadat hij heeft gewacht tot een tijdslot verloopt. Dit is een algemeen script dat on-chain kan worden toegepast, in Lightning-kanalen, bovenop statechains, op sidechains, enz. Zolang u een HTLC kunt gebruiken, kan in theorie alles deelnemen aan het routeren van een Lightning-betaling.
Staatsketens
A staatsketen is in feite zoiets als een Lightning-kanaal, behalve dat je het eigendom van het hele kanaal volledig off-chain kunt overdragen. Hun vertrouwensmodel is afhankelijk van de exploitant (die een federatie kan zijn) van de staatsketen die weigert samen te werken met vorige eigenaren en de staatsketen van de huidige eigenaar te stelen. Het is niet zo betrouwbaar als een Lightning-kanaal, maar het is veel flexibeler omdat het eigendom kan worden doorgegeven zonder een transactie in de keten uit te voeren. Aangezien statechains zijn gebaseerd op vooraf ondertekende transacties buiten de keten, kunt u er HTLC's aan toevoegen.
Hierdoor kunnen ze worden gebruikt om de efficiëntie van het routeren van betalingen op Lightning te optimaliseren door knooppuntoperators in staat te stellen liquiditeit on-the-fly off-chain opnieuw toe te wijzen. In plaats van kanalen te moeten openen en er liquiditeiten in te laten wegvloeien om van tevoren goed aangesloten te zijn, kunnen hun fondsen dynamisch on-the-fly off-chain worden toegewezen als reactie op een verschuiving van de vraag naar plaatsen waarmee ze niet verbonden zijn (of niet goed genoeg verbonden zijn met ). De enige vereiste is dat de andere partij liquiditeit wil verschuiven naar het vertrouwen van de statechain-operator.
zijketens
Sidechains kunnen alle willekeurige regels implementeren die ze willen. Bloktijden kunnen verschillen, blokgroottes kunnen verschillen, er kan van alles worden gewijzigd. De enige vangst is momenteel dat om je te verplaatsen Bitcoin naar een zijketen moet je een federatie vertrouwen die de fondsen in de hoofdketen beheert. U kunt HTLC's toepassen op een zijketen die gebruikmaakt van Bitcoin's scriptsysteem; je kunt een meer Ethereum-achtig scriptingsysteem hebben waarmee tientallen mensen een account kunnen delen dat saldi splitst en bijwerkt naargelang een HTLC slaagt of mislukt; je kan alles doen. Zolang de blockchain het voorwaardelijk geven van geld aan de ene partij ondersteunt als ze een hash produceren, en de andere partij na het verstrijken van een tijdslot, kunnen ze helpen bij het routeren van Lightning-betalingen. Andere blockchains kunnen experimenteren met manieren om liquiditeitstoewijzing efficiënter te maken dan de belangrijkste Bitcoin blokketen. Je kunt zelfs zoiets eenvoudigs doen als een ander Lightning-netwerk bouwen op een keten die goedkoper is om kanalen op te openen en te sluiten. Fantasie is de limiet.
Geheel nieuwe constructies
Hier is een willekeurig idee van mezelf: veel mensen kunnen allemaal samen in één worden gestapeld m-van-n (dwz 3-van-5) multisig-adres met een paar escrow-agenten, en vertrouw er gewoon op dat de escrow-agenten de zaken goed regelen. Elke persoon op het adres en de escrow-agenten kunnen "saldi" volgen en bijwerken op basis van betalingsrouting; HTLC's vastleggen die worden gebruikt en of ze met succes zijn afgewikkeld of terugbetaald; en periodiek de saldi on-chain vereffenen. U stelt de multisig eenvoudig zo samen dat een enkele "routerende" deelnemer en alle escrow-agenten alles zijn wat nodig is om van de multisig uit te geven. U kunt zelfs een tijdgebonden terugbetalingstransactie maken om het geld van iedereen na een bepaalde periode terug te betalen, met als nadeel dat al het geld dat iemand tijdens de levensduur van de constructie heeft verdiend, verloren zou gaan als dat werd gebruikt. Dit zou een afwikkeling in de keten vereisen voordat de terugbetalingstransactie geldig werd om te besteden.
Dit vereist het vertrouwen van de escrow-agenten, maar het voordeel zou zijn dat elke persoon in deze "groep UTXO" geld zou kunnen overmaken of een HTLC naar elke andere persoon in de groep UTXO. Dit zou een enorme efficiëntiewinst zijn bij de allocatie van liquiditeiten.
Kredietrelaties
De eenvoudigste manier om aan efficiëntie te winnen, is door mensen gewoon te vertrouwen. Als u geld zou kunnen verdienen door een betaling voor iemand over het netwerk te routeren, maar u heeft geen kanaal open voor het knooppunt dat nodig is om die betaling te routeren, dan kun je gewoon beloven ze later te betalen als ze je vertrouwen. Als u een bijzonder betrouwbare persoon of entiteit was en veel mensen op het netwerk bereid waren u op deze manier te vertrouwen, dan zou u betalingen met een enorme mate van flexibiliteit kunnen routeren en hoeft u geen kapitaal in betalingskanalen over het hele netwerk te steken. Gewoon eerlijk afrekenen aan het eind van de dag, en mensen zullen erop blijven vertrouwen dat u betalingen voor u doorgeeft op basis van een honoreringssysteem.
Het enige probleem en de voordelen
Het grote voordeel van al deze mogelijkheden is dat, ondanks dat ze allemaal enorme verschillen hebben in termen van vertrouwensmodel (de meeste van hen vereisen zelfs expliciet dat je mensen moet vertrouwen als je ervoor kiest om ze te gebruiken), het maakt voor de zender en ontvanger helemaal niets uit. Als ik een conventioneel betrouwbaar Lightning-kanaal heb en iemand wil betalen die ook een betrouwbaar conventioneel Lightning-kanaal heeft, maakt het ons geen van beiden uit hoe die betaling daar terechtkomt. Wanneer ik het geld stuur, wordt die betaling geüpdatet en afgedwongen in mijn Lightning-kanaal met mijn collega, net als normaal. Wanneer de ontvanger het geld daadwerkelijk ontvangt, wordt die betaling geüpdatet en afgedwongen in hun Lightning-kanaal met hun peer, betrouwbaar, net als normaal. Het feit dat iemand in het midden gewoon vertrouwt op een belofte van zijn collega om hem later te betalen, is voor ons allebei totaal niet relevant. Ik heb mijn geld gestuurd en heb er geen controle meer over, en de ontvanger heeft zijn geld daadwerkelijk gekregen en heeft er nu vol vertrouwen controle over.
Het probleem is: hoe kom ik als afzender achter deze relaties? Op Lightning is de afzender degene die de route voor een betaling kiest, na te hebben gekeken naar de routeringstabel van openbare kanalen op het netwerk die bereid zijn betalingen door te sturen. Om reclame te maken voor de mogelijkheid om een betaling te routeren, moet u de UTXO on-chain tonen die uw Lightning-kanaal heeft gefinancierd en bewijzen dat het een echt kanaal is. Wat hier het probleem is, geen van de bovenstaande ideeën zou dat kunnen bieden, dus de afzender van een betaling zou op de hoogte kunnen zijn van deze andere opties om een betaling te routeren. Als het roddelprotocol en de routeringstabelstructuur werden bijgewerkt om deze andere dingen mogelijk te maken, zouden ze op andere opties kunnen worden gewezen.
De enige echte vereiste is ervoor te zorgen dat reclame voor andere 'niet-kanaal'-manieren om betalingen te routeren geen denial-of-service-vectoren opent. Het huidige schema, dat het delen van de UTXO vereist die een kanaal heeft gefinancierd, is er als een bescherming tegen mensen die reclame maken voor kanalen die niet bestaan, wat knooppunten zou kunnen overladen met nutteloze roddelgegevens en ertoe zou kunnen leiden dat gebruikers constant proberen betalingen te doen die nooit zijn gedaan een kans om te slagen in de eerste plaats.
Aan het eind van de dag zijn er problemen die moeten worden opgelost om de flexibiliteit van de manier waarop betalingen op het netwerk kunnen worden gerouteerd te vergroten, maar het zijn oplosbare problemen. Denken dat Lightning moet blijven functioneren zoals het nu doet om als betalingsnetwerk te kunnen werken, is erg bekrompen, en om het bot te zeggen, problemen bedenken die meestal denkbeeldig zijn.
Dit is een gastpost van Shinobi. De geuite meningen zijn geheel van henzelf en komen niet noodzakelijk overeen met die van BTC Inc of Bitcoin Magazine.
Originele bron: Bitcoin Magazine