By Bitcoin पत्रिका - 1 साल पहले - पढ़ने का समय: 7 मिनट
कुछ तरीके जिनसे हम लाइटनिंग नेटवर्क भुगतान रूटिंग को अपग्रेड कर सकते हैं
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:
The scalability limits how many channels can be opened or closed on-chain at a time. There’s an issue with the minimum size हैश टाइम लॉक्ड कॉन्ट्रैक्ट (HTLC) increasing as on-chain fees also increase, because it has to be economical to settle.There are also a slew of privacy issues.एक प्रमुख मुद्दा जिस पर अक्सर चर्चा की जाती है वह है रूटिंग भुगतान के लिए तरलता की आवश्यकताएं। भुगतान को सफलतापूर्वक रूट करने के लिए, चैनलों का एक लिंक होना चाहिए, प्रेषक से लेकर रिसीवर तक, जिसके पास भुगतान को पास करने में सक्षम होने के लिए चैनल के दाईं ओर पर्याप्त तरलता है। यह निर्णय लेता है कि नेटवर्क पर आपके सिक्कों को कहां तैनात किया जाए, यह बहुत महत्वपूर्ण है। इसका मतलब यह भी है कि लोग जिस तरलता को तैनात करने के इच्छुक हैं, वह एक प्रकार की ऊपरी सीमा है कि नेटवर्क कितना मूल्य संसाधित कर सकता है।
अंतत:, इसका मतलब यह है कि जब आप कोई चैनल खोलते हैं, तो आप उस पैसे को लॉक करने का निर्णय लेते हैं ताकि इसका उपयोग केवल उस चैनल पार्टनर को भुगतान रूट करने के लिए किया जा सके, और जिससे वे ग्राफ पर जुड़े हों। हां, अंततः लाइटनिंग नेटवर्क का विचार यह है कि पर्याप्त हॉप्स बनाकर आप लगभग कहीं भी एक कनेक्शन पा सकते हैं। हालांकि, वास्तविकता यह है कि यदि कोई अन्य व्यक्ति आपकी तुलना में कम हॉप्स का उपयोग करके भुगतान को गंतव्य तक पहुंचा सकता है, तो यही वह रास्ता है जो भुगतान को रूट करने के लिए सबसे अधिक चुना जाएगा। लाइटनिंग को पहले से ही बड़े पैमाने पर ओवरकोलेटरलाइज़ेशन की आवश्यकता होती है, अर्थात, 1 बीटीसी भुगतान को 10 हॉप्स में रूट करने के लिए उस मार्ग के भुगतान चैनलों में 10 बीटीसी संपार्श्विक को लॉक करने की आवश्यकता होती है। रूटिंग रेवेन्यू बनाने के लिए अच्छे कनेक्शन होने की होड़ ने इसे और भी बेमानी संपार्श्विकता को प्रोत्साहित करके इसे बढ़ा दिया है।
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.
राज्यवासी
A राज्य श्रृंखला प्रभावी रूप से एक लाइटनिंग चैनल की तरह कुछ है, सिवाय इसके कि आप पूरे चैनल के स्वामित्व को पूरी तरह से ऑफ-चेन स्थानांतरित कर सकते हैं। उनका ट्रस्ट मॉडल स्टेटचेन के ऑपरेटर (जो एक फेडरेशन हो सकता है) पर निर्भर है, जो पिछले मालिकों के साथ मिलीभगत से इनकार करता है और वर्तमान मालिक से स्टेटचैन चोरी करता है। यह एक लाइटनिंग चैनल की तरह भरोसेमंद नहीं है, लेकिन यह बहुत अधिक लचीला है क्योंकि स्वामित्व को ऑन-चेन लेनदेन किए बिना पारित किया जा सकता है। यह देखते हुए कि स्टेटचेन पूर्व-हस्ताक्षरित लेनदेन ऑफ-चेन पर आधारित हैं, आप उनमें एचटीएलसी जोड़ सकते हैं।
यह उन्हें नोड ऑपरेटरों को फ्लाई ऑफ-चेन पर तरलता को पुन: असाइन करने की अनुमति देकर लाइटनिंग पर रूटिंग भुगतान की दक्षता को अनुकूलित करने के लिए उपयोग करने की अनुमति देता है। समय से पहले अच्छी तरह से जुड़े होने के लिए चैनल खोलने और उनमें तरलता को डुबोने के बजाय, उनके फंड को गतिशील रूप से फ्लाई ऑफ-चेन पर पुन: असाइन किया जा सकता है ताकि वे उन जगहों पर मांग को स्थानांतरित कर सकें जहां वे जुड़े नहीं हैं (या पर्याप्त रूप से जुड़े नहीं हैं) ) एकमात्र आवश्यकता यह है कि दूसरी पार्टी राज्य श्रृंखला ऑपरेटर पर भरोसा करने के लिए तरलता को स्थानांतरित करना चाहती है।
पक्ष श्रृंखला
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.
पूरे नए निर्माण
Here's a random idea of my own: Many people can all pile together into a single m-का-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 कोई समूह UTXO में अन्य व्यक्ति। यह तरलता आवंटन में बड़े पैमाने पर दक्षता लाभ होगा।
क्रेडिट संबंध
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, तो आप उन्हें बाद में भुगतान करने का वादा कर सकते हैं अगर वे आप पर भरोसा करते हैं। यदि आप एक विशेष रूप से भरोसेमंद व्यक्ति या संस्था थे, और नेटवर्क पर बहुत से लोग इस तरह से आप पर भरोसा करने को तैयार थे, तो आप बड़े पैमाने पर लचीलेपन के साथ भुगतान कर सकते थे और पूरे नेटवर्क में भुगतान चैनलों में पूंजी नहीं डाल सकते थे। दिन के अंत में बस ईमानदारी से समझौता करें, और लोग सम्मान प्रणाली के आधार पर आपके लिए भुगतान पारित करने के लिए आप पर भरोसा करना जारी रखेंगे।
एक समस्या और लाभ
इन सभी संभावनाओं का प्रमुख लाभ यह है कि, इन सभी में विश्वास मॉडल के संदर्भ में भारी अंतर होने के बावजूद (उनमें से अधिकांश को वास्तव में स्पष्ट रूप से आपको उन लोगों पर भरोसा करने की आवश्यकता होती है जिनके साथ आप बातचीत कर रहे हैं यदि आप उनका उपयोग करना चुनते हैं), 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.
समस्या यह है कि, मैं, प्रेषक के रूप में, इन संबंधों के बारे में कैसे पता लगाऊं? लाइटनिंग पर, प्रेषक वह होता है जो भुगतान को अग्रेषित करने के इच्छुक नेटवर्क पर सार्वजनिक चैनलों की रूटिंग तालिका को देखने के बाद भुगतान के लिए मार्ग चुनता है। भुगतान को रूट करने की क्षमता का विज्ञापन करने के लिए UTXO ऑन-चेन दिखाने की आवश्यकता है जिसने आपके लाइटनिंग चैनल को वित्त पोषित किया और यह साबित किया कि यह एक वास्तविक चैनल है। यहां कौन सी समस्या है, उपरोक्त विचारों में से कोई भी इसे प्रदान करने में सक्षम नहीं होगा, इसलिए भुगतान भेजने वाले को भुगतान को रूट करने के लिए इन अन्य विकल्पों के बारे में पता हो सकता है। यदि गपशप प्रोटोकॉल और रूटिंग टेबल संरचना को इन अन्य चीजों की अनुमति देने के लिए अद्यतन किया गया था, तो उन्हें अन्य विकल्पों से अवगत कराया जा सकता था।
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.
दिन के अंत में, नेटवर्क पर भुगतान कैसे रूट किया जा सकता है, इसके लचीलेपन को बढ़ाने के लिए हल करने में समस्याएं हैं, लेकिन वे हल करने योग्य समस्याएं हैं। भुगतान नेटवर्क के रूप में काम करने के लिए लाइटनिंग को वर्तमान में जिस तरह से कार्य करना जारी रखना चाहिए, यह सोचना बहुत ही संकीर्ण सोच है, और इसे सीधे शब्दों में कहें तो, ऐसी समस्याओं का आविष्कार करना जो ज्यादातर काल्पनिक हैं।
यह शिनोबी की अतिथि पोस्ट है। व्यक्त की गई राय पूरी तरह से उनकी अपनी हैं और जरूरी नहीं कि वे बीटीसी इंक या . के विचारों को प्रतिबिंबित करें Bitcoin पत्रिका.
मूल स्रोत: Bitcoin पत्रिका