By Bitcoin ম্যাগাজিন - 6 মাস আগে - পড়ার সময়: 6 মিনিট
টাইমআউট ট্রিস: লাইটনিং নেটওয়ার্ক এলএসপি স্কেলিং করার একটি সমাধান
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.
আরেকটি বড় সমস্যা হল যে একটি শুরু করার জন্য আপনাকে সমস্ত লেনদেনগুলিকে প্রাক-সাই করার জন্য শুরুতে অনলাইনে থাকতে হবে। আপনি যদি একটি কারখানায় বিশ জন লোক চান তবে এটি চালু করার জন্য সবাইকে অনলাইনে থাকতে হবে। আপনি যদি এক হাজার লোক চান, এক হাজার লোককে অনলাইনে থাকতে হবে ইত্যাদি।
এটি চ্যানেল কারখানাগুলিকে সমাধান করার জন্য প্রচুর সমস্যায় পূর্ণ একটি বড় ডিজাইনের জায়গা করে তোলে। তাই আমরা বজ্রপাতের জন্য একটি বিদ্যমান সমস্যা সমাধান করি, কিন্তু নতুন একটি গুচ্ছ তৈরি করি। আমার কাছে ইঞ্জিনিয়ারিং মনে হচ্ছে।
টাইমআউট গাছ
John Law's recent proposal, টাইমআউট গাছ, 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.
এখন শেষ অংশ, চ্যানেল বন্ধ. যদিও CTV-এর কারণে এগুলি খোলার জন্য শুধুমাত্র একটি একক UTXO অন-চেইন প্রয়োজন, তবুও সেগুলি বন্ধ করার জন্য পুরো CTV ট্রি অন-চেইন উন্মোচন করতে হবে যাতে প্রত্যেকে তাদের চ্যানেলের অবস্থা জমা দিতে পারে, তাই না? ভুল. এটি টাইমআউট গাছের টাইমআউট অংশ। টাইমআউট ট্রির প্রতিটি শাখার একটি স্ক্রিপ্ট শাখা রয়েছে যেখানে বব একটি টাইমলকের পরে সমস্ত তহবিল ঝাড়ু দিতে পারে৷
একটি টাইমআউট ট্রির একটি চিত্র।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.
মোড়ক উম্মচন
ব্যবহারকারীদের এখনও অন-চেইন ইন্টারঅ্যাকশনের জন্য ফি দিতে হবে, এর আশেপাশে কোন উপায় নেই, এবং একটি সম্পূর্ণ টাইমআউট ট্রি অন-চেইন অ-সহযোগীভাবে বন্ধ করা একটি বড় এবং ব্যয়বহুল অন-চেইন পদচিহ্ন হবে, কিন্তু এটি শেষ পর্যন্ত একটি সমস্যা। যেকোন মাল্টিপার্টি চ্যানেল সিস্টেমকে সম্বোধন করতে হবে। টাইমআউট ট্রিস-এর কাছে সিস্টেমের ট্রাস্ট মডেলকে হেফাজতযোগ্য কিছুতে অবনমিত না করেই একটি বিশাল মাল্টিপার্টি চ্যানেল খোলা এবং বন্ধ করার উভয় ক্ষেত্রেই সহযোগিতামূলক সমাধান রয়েছে।
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.
মূল উৎস: Bitcoin পত্রিকা