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.
Όπως ανέφερα παραπάνω, χρησιμοποιείται από ορισμένα πορτοφόλια για να διασφαλιστεί ότι μια πληρωμή θα είναι επιτυχής πριν επιχειρήσει πραγματικά την πραγματική πληρωμή, αλλά αυτή η τεχνική μπορεί επίσης να χρησιμοποιηθεί για να εξακριβωθεί η κατανομή των κεφαλαίων και στις δύο πλευρές ενός καναλιού. Όταν γίνεται επανειλημμένα και με προσεκτικά επιλεγμένα ποσά, η επιτυχία και η αποτυχία κάθε προσπάθειας ανίχνευσης μπορεί να συναγάγει τον τρόπο κατανομής των κεφαλαίων σε κάθε πλευρά του καναλιού. Προχωρώντας ακόμη περισσότερο και γίνεται συστηματικά σε πολλά κανάλια σε τακτική βάση, αυτή η τεχνική μπορεί ακόμη και να ανωνυμοποιήσει τις πληρωμές παρακολουθώντας αποτελεσματικά σε πραγματικό χρόνο καθώς αλλάζουν τα υπόλοιπα μεταξύ των καναλιών.
Το Lightning πλαισιώνεται συνεχώς ως εργαλείο απορρήτου για συναλλακτική χρήση, αλλά η πραγματικότητα είναι δεδομένη τεχνικές όπως η διερεύνηση του απορρήτου σε πολλές περιπτώσεις μπορεί να είναι αδύναμη στην καλύτερη περίπτωση χωρίς ο χρήστης να είναι περίπλοκος στον τρόπο αλληλεπίδρασης με το δίκτυο. Μία από τις ενδιαφέρουσες παρενέργειες του διαχωρισμού και της αλλαγής πληρωμών είναι ότι υπονομεύει τις επιθέσεις διερεύνησης. Ο λόγος για τον οποίο λειτουργεί μια επίθεση διερεύνησης είναι επειδή μπορείτε να συνεχίσετε να ελέγχετε με διαφορετικά ποσά μέχρι να αποτύχει μια πληρωμή. Εάν γίνει σωστά, αυτό σας δίνει ένα πολύ μικρό εύρος μεταξύ της τελευταίας επιτυχημένης προσπάθειας πληρωμής και της αποτυχημένης που είναι η κατανομή του υπολοίπου του καναλιού.
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 Αστραπιαία ευπάθεια, 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 περιοδικό