Några sätt vi kan uppgradera Lightning Network Payment Routing

By Bitcoin Magasin - 1 år sedan - Lästid: 7 minuter
Fre 20 maj 2022 10:32

Några sätt vi kan uppgradera Lightning Network Payment Routing

In order to develop into a protocol usable by the entire world, certain scaling improvements for Lightning need to be considered.

The Lightning Network is a well-developed, fast-growing, Layer 2 transaction solution on the Bitcoin network. More and more services and exchanges are integrating it, the liquidity available for routing payments is growing, and more applications and ways for users to interact with it are being developed each year. It also has many problems to overcome in the long run: 

En viktig fråga som diskuteras ofta är likviditetskraven för att dirigera betalningar. För att lyckas dirigera en betalning måste det finnas en länk av kanaler, hela vägen från avsändaren till mottagaren som har tillräckligt med likviditet på höger sida av kanalen för att kunna föra betalningen vidare. Detta gör beslutet om var du ska distribuera dina mynt i nätverket mycket viktigt. Det betyder också att den totala mängden likviditet som människor är villiga att använda är en slags övre gräns för hur mycket värde nätverket kan bearbeta.

I slutändan, vad det handlar om är att när du öppnar en kanal bestämmer du dig för att låsa de pengarna så att de bara kan användas för att dirigera betalningar till den kanalpartnern, och vem de än är ansluten till på grafen. Ja, i slutändan är tanken med Lightning Network att genom att göra tillräckligt många hopp kan du hitta en anslutning till nästan var som helst. Verkligheten är dock att om någon annan kan dirigera en betalning till en destination med mindre hopp än du kan, är det den väg som troligen kommer att väljas för att dirigera betalningen. Lightning kräver redan i hög grad översäkerhet, dvs för att dirigera en 1 BTC-betalning över 10 hopp krävs 10 BTC i säkerhet för att låsas in i betalningskanaler längs den vägen. Konkurrensen om att ha bra förbindelser för att göra routingintäkter förvärrar detta genom att stimulera till ännu mer överflödiga säkerheter.

This is a problem resulting from the fact that Lightning channels are two-party "tubes" that can just push value back and forth in those two directions. Here's the thing though: The problem is kind of an imaginary one. Payments on Lightning use HTLCs, a script in a Bitcoin output that says one person can claim the output and spend it by revealing the preimage to a hash, or another person can claim the output and spend it after waiting for a timelock to expire. This is a general script that can be applied on-chain, in Lightning channels, on top of statechains, on sidechains, etc. As long as you can utilize an HTLC, in theory, anything can participate in routing a Lightning payment.

Statskedjor

A delstatskedja är faktiskt något som en Lightning-kanal, förutom att du kan överföra äganderätten till hela kanalen helt utanför kedjan. Deras förtroendemodell är beroende av att operatören (som kan vara en federation) av delstatskedjan vägrar att samarbeta med tidigare ägare och stjäla delstatskedjan från den nuvarande ägaren. Den är inte lika tillitslös som en Lightning-kanal, men den är mycket mer flexibel eftersom ägandet kan föras runt utan att behöva utföra en on-chain-transaktion. Med tanke på att tillståndskedjor är baserade på försignerade transaktioner utanför kedjan, kan du lägga till HTLC:er till dem.

Detta gör att de kan användas för att optimera effektiviteten för att dirigera betalningar på Lightning genom att tillåta nodoperatörer att omfördela likviditet i farten utanför kedjan. Istället för att behöva öppna kanaler och sänka likviditet i dem för att vara väl anslutna i förväg, kan deras medel dynamiskt omfördelas i farten utanför kedjan som svar på en förskjutning av efterfrågan till platser de inte är anslutna till (eller inte är anslutna tillräckligt bra för att ). Det enda kravet är att den andra parten vill flytta likviditeten till att lita på statechain-operatören.

sidokedjor

Sidechains can implement any arbitrary rules they want. Block times can be different, block sizes can be different, anything can be changed. The only catch currently is that to move your Bitcoin to a sidechain, you have to trust a federation that custodies the funds on the main chain. You can apply HTLCs on a sidechain that uses Bitcoin's scripting system; you can have a more Ethereum-like scripting system that lets dozens of people share an account that splits balances and updates them according to whether an HTLC succeeds or fails; you can do anything. As long as the blockchain supports conditionally giving money to one party if they produce a hash, and the other party after a timelock expires, they can help route Lightning payments. Other blockchains can experiment with ways to make liquidity allocation more efficient than the main Bitcoin blockchain. You can even just do something as basic as build another Lightning Network on a chain that is cheaper to open and close channels on. Imagination is the limit.

Helt nya konstruktioner

Here's a random idea of my own: Many people can all pile together into a single m-av-n (i.e., 3-of-5) multisig address with a few escrow agents, and simply trust the escrow agents to settle things properly. Every person in the address and the escrow agents can track and update “balances” based on payment routing; record HTLCs that are used and whether they are successfully settled or refunded; and periodically settle the balances on-chain. You simply construct the multisig so that a single "routing" participant and all of the escrow agents are all that is necessary to spend from the multisig. You can even create a timelocked refund transaction to refund everyone's money after a certain period, the downside of which would be all the money anyone had gained during the lifetime of the construct would be lost if that was used. This would require settling on-chain before the refund transaction became valid to spend.

This would require trusting the escrow agents, but the benefit would be that any person in this "group UTXO" could transfer funds or route an HTLC to vilken som helst annan person i gruppen UTXO. Detta skulle vara en enorm effektivitetsvinst i likviditetsallokeringen.

Kreditrelationer

The simplest way to gain efficiency would be to simply trust people. If you could make money routing a payment across the network for someone, but you don't have a channel open to the node necessary to route that payment, då kan du bara lova att betala dem senare om de litar på dig. Om du var en särskilt pålitlig person eller enhet, och många människor i nätverket var villiga att lita på dig på det här sättet, så kunde du dirigera betalningar med en enorm grad av flexibilitet och inte behöva sjunka in kapital i betalningskanaler över hela nätverket. Bara lösa upp ärligt i slutet av dagen, och folk kommer att fortsätta lita på att du skickar betalningar för dig på ett hederssystembasis.

Det enda problemet och fördelarna

Den stora fördelen med alla dessa möjligheter är att trots att de alla har enorma skillnader när det gäller förtroendemodell (de flesta av dem kräver faktiskt uttryckligen att du litar på människor du interagerar med om du väljer att använda dem), it doesn't matter at all for the sender and receiver. If I have a conventional trustless Lightning channel and want to pay someone who also has a trustless conventional Lightning channel, how that payment gets there doesn't matter to either of us at all. When I send the money, that payment is updated and enforced in my Lightning channel with my peer trustlessly, just like normal. When the receiver actually gets the money, that payment is updated and enforced in their Lightning channel with their peer, trustlessly, just like normal. The fact that someone in the middle is just trusting a promise from their peer to pay them later is totally irrelevant to both of us. I sent my money and no longer have control of it, and the receiver actually got their money and now has control of it, trustlessly.

Problemet är hur jag som avsändare får reda på dessa relationer? På Lightning är avsändaren den som väljer vägen för en betalning, efter att ha tittat på routingtabellen för offentliga kanaler på nätverket som är villiga att vidarebefordra betalningar. För att annonsera möjligheten att dirigera en betalning måste du visa UTXO-kedjan som finansierade din Lightning-kanal och bevisa att det är en faktisk kanal. Vilket är problemet här, ingen av ovanstående idéer skulle kunna tillhandahålla det, så avsändaren av en betalning kan vara medveten om dessa andra alternativ för att dirigera en betalning. Om skvallerprotokollet och routningstabellstrukturen uppdaterades för att tillåta dessa andra saker, kunde de dock göras medvetna om andra alternativ.

The only real requirement is making sure that advertising other "non-channel" ways to route payments does not open up denial-of-service vectors. The current scheme, requiring sharing the UTXO that funded a channel, is there as a protection against people advertising channels that don't exist, which could overload nodes with useless gossip data as well as lead to users constantly trying to make payments that never had a chance to succeed in the first place.

I slutändan finns det problem att lösa för att öka flexibiliteten i hur betalningar kan dirigeras på nätet, men de är lösbara problem. Att tänka att Lightning måste fortsätta att fungera på det sätt som det gör idag för att fungera som ett betalningsnätverk är väldigt snävt tänkande, och rent ut sagt att hitta på problem som mestadels är inbillade.

Detta är ett gästinlägg av Shinobi. Åsikter som uttrycks är helt deras egna och återspeglar inte nödvändigtvis BTC Incs eller Bitcoin magazine.

Ursprunglig källa: Bitcoin magazine