By Bitcoin Moheni - 6 marama ki muri - Te Wa Panui: 6 meneti
Nga Rakau Waahi: He Otinga ki te Whakanuia i nga LSP Whatunga Uira
One of the biggest inherent limitations to the Lightning Network is the limited number of channels that can be opened or closed per block given the blocksize limit. Regardless of how many transactions can occur off-chain how cheaply, this is a fundamental bottleneck restricting how many people could actually realistically use the Lightning Network. Even the Lightning Network whitepaper went through in the conclusion that in a scenario where the entire world's population of 7 billion was using Lightning, with only two on-chain transactions a year per person, Bitcoin would require 133 MB blocks for Lightning to work. This isn't some out of left field problem, or unpredictable issue, it was a limitation of the protocol design fully understood from day one.
Part of the plan to address this issue has always been the idea of channel factories, i.e. a type of channel that more than two users participated in. This was always the direction things would have to go in order to scale Lightning and Bitcoin without a blocksize increase, but the issue is that solving the problem of on-chain footprints introduces a whole host of other problems. First of all, nothing fundamental changes about the requirement to enforce intermediate states if a counterparty becomes non-responsive. This has implications for the value-add. The entire point of a channel factory is that, for example, twenty people can share one UTXO and rearrange the liquidity inside with the other twenty people however they want. Once someone closes out on-chain non-cooperatively this starts to interfere with that goal.
If I close out my channel inside a channel factory, I drag a bunch of people with me out of the factory. Think of a factory like a merkle tree, there's one UTXO at the top, and that splits in half off-chain, and those split in half, etc. until we get to everyone's individual channels. Once I peel my channel out of the factory, everyone on my side of each split that goes on-chain is now cut off from everyone else in the factory. They can no longer reorganize their liquidity into that part of the group if everyone cooperates.
Ko tetahi atu take nui, ara ki te timata i tetahi me whai ipurangi katoa i te timatanga ki te haina i mua i nga whakawhitinga katoa. Ki te hiahia koe kia rua tekau nga tangata i roto i te wheketere, me noho ipurangi katoa ki te timata. Mena kei te pirangi koe kia kotahi mano tangata, kotahi mano nga tangata me noho ipurangi, etc.
Na tenei ka waiho nga wheketere hongere hei waahi hoahoa nui ki tonu i te maha o nga raru hei whakaoti. No reira ka whakatauhia e matou he rapanga o naianei mo te Uira, engari ka hanga he paihere o nga mea hou. He rite ki te miihini ki ahau.
Nga Rakau Waahi
John Law's recent proposal, Nga Rakau Waahi, attempts to offer a solution to the one core issue of channel factories. I wouldn't quite call a timeout tree a channel factory, more of a "proto-factory," but it offers a potential solution to the issue of opening and closing massive amounts of channels without introducing the problem of non-cooperative closes ruining the use of the factory for other users. It requires CHECKTEMPLATEVERIFY (CTV) and a Lighting Service Provider (LSP) in order to work functionally.
A Timeout Tree is essentially a channel factory guaranteed by covenants, with no ability to change how the liquidity is reorganized off-chain after it is made, with a special escape clause. An LSP, we'll call them Bob, plays the role of bridging casual users into the wider Lightning Network. Bob can take coins he controls and create a CTV tree that creates a single UTXO unfurling to open channels to any arbitrary number of users of his LSP service. The nice thing about CTV is it enables this to be done without everyone being online at the same time. Bob can simply get everyone to sign their initial channel state one at a time and hold onto them until everyone has set up the channel, and just spend the funds into the CTV tree when he has channels set up with every user.
This addresses the problem of everyone having to be online at the same time in order to set up the "factory" and start using Lightning. Because of CTV, once Bob spends coins into the tree setting up everyone's Lightning channels, there is no way for him to back out and take the coins (yet). With that first UTXO in the CTV confirmed on-chain, everyone can treat their channels as open and there is no risk of them being doublespent.
Na ko te waahanga whakamutunga, ka kati i nga hongere. Ahakoa ko te whakatuwheratanga he kotahi UTXO i runga-mekameka na te CTV, ko te kati i a raatau ka hiahia tonu te rakau CTV katoa kia mahora i runga i te mekameka kia taea e te katoa te tuku i a raatau whenua hongere, tika? He he. Ko tenei te wahanga Timeout o nga Rakau Waahi. Kei ia peka o te Rakau Timeout he peka tuhi ka taea e Bob te tahiti i nga moni katoa i muri i te kati taima.
He hoahoa o te Rakau Waahi.Now I'm sure you're thinking "what!?" This is the real genius of how this proposal works. Because Bob can sweep the on-chain UTXOs himself without anyone else after the timelock, these channels all have an expiration date unless users actually unfurl the whole tree and confirm the real channel funding on-chain. This allows Bob to do something neat: when that timelock is coming up, he can open a brand new Timeout Tree with all the users of the current one, and have them move all of their funds from the expiring tree into the new one entirely off-chain on Lightning and then sweep the single on-chain UTXO of the last tree.
This allows for efficient closing of all these channels on-chain. The only problem left now is enforcing an HTLC on-chain if the other party stops cooperating. Well…that isn't really an issue in this case, or rather it's an all or nothing issue. The reason channels have to be closed to enforce an HTLC is if the other party of the channel stops responding in the middle of routing it. In a Timeout Tree every single user's counterpart is Bob. So if Bob, as long as he is being honest, is not responding to update a failed or successful HTLC for one user, he's not responding for any other user either. In that case everyone can still close out their channels on-chain before the timeout and stop using Bob's LSP.
Whakakuku
Ka utua tonu e nga kaiwhakamahi nga utu mo nga taunekeneke i runga i te mekameka, karekau he huarahi mo tera, a ko te katoa o te Rakau Timeout e kati ana i runga i te mekameka me te kore mahi tahi ka waiho he tapuwae i runga i te mekameka, engari he take tenei. me whakatika nga punaha hongere maha. Heoi ano he otinga kaha a Timeout Trees ki te keehi mahi tahi mo te whakatuwhera me te kati i tetahi hongere roopu maha me te kore e whakaheke i te tauira whakawhirinaki o te punaha ki tetahi mea ka tiakina.
John has even in his most recent version of the paper proposed a scheme where users could be penalized for non-cooperative closures enough to cover Bob's cost for eventually sweeping a bunch of fragmented tree UTXOs after the timeout. Potentially there are ways to do the reverse if Bob's inactivity or dishonesty is the cause for users having to non-cooperatively close their part of the tree.
At the end of the day though, this is a very concrete and specific proposal for a channel factory design that actually attempts to address the real issues of use and implementation instead of a half-defined and vague concept. That is massive progress in terms of addressing Lightning's long-term scaling limitations.
Kuputuhi taketake: Bitcoin moheni