By Bitcoin مجله - 6 میاشتې دمخه - د لوستلو وخت: 5 دقیقې
د تادیې ویشل او بدلول: په ورته وخت کې د محرمیت او تادیې بریا ښه کول
One of the fundamental limitations of the Lightning protocol is how payment routing is handled and accomplished. It is entirely source routed, meaning that the sender of a payment is the one who constructs the entire route from themselves to the receiver in order to facilitate the payment. This presents an issue when it comes to the changing balances of channels over time as they are routing payments between numerous different users across the network, once a sender "locks in" and decides on a specific route, that route cannot be changed until a failure message makes it way back to the sender, allowing them to construct an entirely new route going around the point where the initial attempt failed.
دا یا د یو پیچلي او ځورونکي UX سره معامله کولو ته اړتیا لري ، یا د تادیې تفتیش کارول ، په قصدي ډول د تادیاتو چمتو کول چې تاسو به په هدف کې پاتې شئ یوازې دا وګورئ چې ایا هغه لاره چې تاسو یې کارول غواړئ د اصلي تادیې سره بیا هڅه کولو دمخه به کار وکړي. پخوانی یوازې د کارونکي خراب تجربه ده او نه هغه څه چې تاسو یې غواړئ کله چې یو څه رامینځته کولو هڅه وکړئ ترڅو په پیمانه د خلکو لپاره د تادیې وړ تادیه حل وي ، او وروستنی په ټوله کې په شبکه کې غیر مناسب بار اچوي ځکه چې د روټینګ نوډونه باید د شبکې سره معامله وکړي. د دوامداره تادیاتو ټرافیک او د مایعاتو پیچلتیاوې پرته له دې چې نهایی کولو اراده ولري یوازې د یوې لارې د وړتیا ازموینې لپاره.
د دې ستونزو وروستی لامل د لیږونکي د ښکیلتیا پرته د مینځنۍ تادیې بدلولو لپاره د لارې نشتوالی دی. ځکه چې د تادیې ټوله لاره د پیاز کوډ شوې ده، دا واقعیا ممکنه نه ده. هر هپ یوازې د هغې څخه دمخه د هپ په اړه پوهیږي ، او وروسته هپ ، دوی د وروستي منزل په اړه هیڅ پوهه نلري ترڅو دوی وکولی شي له دوی څخه ترلاسه کونکي ته بدیل لاره جوړه کړي.
Now, while this does present a huge barrier to shifting away from source-based routing, it doesn't entirely prevent it. As an intermediary node, while you can't completely reconstruct a new route from you to the destination, you can reroute the payment from yourself to the next hop defined in the path picked by the sender. So if Bob receives a payment that he is supposed to route to Carol, and the channel he is supposed to route it through doesn't have the capacity needed to forward it, he can send what he can through that channel and route the rest of the payment amount through other routes he can find from himself to Carol.
Last month Gijs van Dam wrote a proof of concept plugin for CLN (شتون لري دلته) that does exactly that, building on multi-path payments that allow a payment to split up and take multiple routes to the receiver. If Bob and Carol are both running the plugin they can, in the appropriate situations, communicate to each other that a payment being forwarded along one channel is actually being partially rerouted so that Carol doesn't immediately drop it when she sees what she is being sent is less than what she is expected to forward. This way if alternate routes are available between Bob and Carol when the sender-decided route isn't viable, they can simply reroute the needed amount and the payment can succeed without having to completely fail, propagate back to the sender, and be rerouted by them.
If widely adopted as a standardized behavior on the network this could have a huge positive impact in the success rate of payments, drastically improving the UX of Lightning users looking for a simple payment mechanism that just works. It's an incredibly simple and logical behavior that could significantly improve a well known shortcoming. That's not all it can do though.
One of the big reasons that Gijs van Dam became interested in addressing this issue actually has nothing to do with simply improving the payment success rate and UX for users, it was actually because of a privacy shortcoming. One of the well known privacy issues that Lightning is vulnerable to is channel probing, this is the problem Gijs was concerned with.
لکه څنګه چې ما پورته یادونه وکړه دا د ځینې بټو لخوا کارول کیږي ترڅو ډاډ ترلاسه شي چې تادیه به د ریښتینې تادیې هڅه کولو دمخه بریالۍ وي ، مګر دا تخنیک د دې لپاره هم کارول کیدی شي چې د چینل په دواړو خواو کې د فنډونو ویش معلوم کړي. په مکرر ډول او په احتیاط سره ټاکل شوي مقدار سره ترسره شوي، د هرې پلټنې هڅې بریا او ناکامي کولی شي دا معلومه کړي چې څنګه د چینل په هر اړخ کې فنډونه ویشل شوي. حتی نور هم اخیستل شوی او په منظم ډول په ډیری چینلونو کې په منظم ډول ترسره شوی ، دا تخنیک حتی کولی شي په مؤثره توګه په ریښتیني وخت کې د لیدو له لارې تادیات بې نومه کړي ځکه چې په چینلونو کې توازن بدلیږي.
بریښنا په دوامداره توګه د لیږدونې کارونې لپاره د محرمیت وسیلې په توګه رامینځته کیږي ، مګر حقیقت ته تخنیکونه ورکړل شوي لکه چینل چې په ډیری قضیو کې د محرمیت پلټنه کولی شي خورا ټیټ وي پرته لدې چې یو کارونکي پدې کې پیچلي وي چې څنګه دوی له شبکې سره تعامل کوي. د تادیې ویشلو او بدلولو یو په زړه پورې اړخیزو اغیزو څخه دا دی چې دا د تحقیقاتو بریدونه کمزوري کوي. د پلټنې برید د کار کولو دلیل دا دی چې تاسو کولی شئ د مختلف مقدارونو سره تفتیش ته دوام ورکړئ تر هغه چې تادیه ناکامه شي. که په سمه توګه ترسره شي، دا تاسو ته د وروستي بریالي تادیې هڅې او د ناکامې هڅې تر مینځ خورا کوچنۍ لړۍ درکوي چې د چینل توازن ویش دی.
In a world where Lightning nodes can on the fly reroute parts payments that would otherwise fail so they succeed, it completely breaks the inherent assumption that channel balance probing relies on. That your payment attempt will fail when the specific channel you decided to route through doesn't have the liquidity to forward it. With payment splitting and switching that assumption is no longer true, and the more nodes on the network support switching the more error prone it makes that assumption (by up to 62% according to a simulation using real-world Lightning network data by Gijs).
So not only is this proposal relatively simple, not only does it provide a path to improving the success rate of payment attempts, it also helps address one of the largest privacy shortcomings of the Lightning Network. I think especially in the wake of the recent Lightning vulnerability, this proposal shows that while Lightning is not without its share of problems, they are not impossible to solve or mitigate. It will even be very common for solutions to one problem to help with another problem.
Rome wasn't built in a day, and solutions that actually preserve Bitcoin's core properties in a scalable and sustainable way won't be either.
اصلي سرچینه: Bitcoin مجله