Μερικοί τρόποι με τους οποίους μπορούμε να αναβαθμίσουμε τη δρομολόγηση πληρωμών του δικτύου Lightning

By Bitcoin Περιοδικό - 1 έτος πριν - Χρόνος ανάγνωσης: 7 λεπτά

Μερικοί τρόποι με τους οποίους μπορούμε να αναβαθμίσουμε τη δρομολόγηση πληρωμών του δικτύου Lightning

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 Κλειδωμένο συμβόλαιο Hash Time (HTLC) increasing as on-chain fees also increase, because it has to be economical to settle.There are also a slew of privacy issues.

Ένα σημαντικό ζήτημα που συζητείται συχνά είναι οι απαιτήσεις ρευστότητας για τη δρομολόγηση πληρωμών. Προκειμένου να δρομολογηθεί με επιτυχία μια πληρωμή, πρέπει να υπάρχει ένας σύνδεσμος καναλιών, σε όλη τη διαδρομή από τον αποστολέα έως τον παραλήπτη που να έχει αρκετή ρευστότητα στη δεξιά πλευρά του καναλιού για να μπορεί να μεταφέρει την πληρωμή μαζί. Αυτό καθιστά πολύ σημαντική την απόφαση για το πού θα αναπτύξετε τα νομίσματά σας στο δίκτυο. Σημαίνει επίσης ότι η συνολική ποσότητα ρευστότητας που είναι πρόθυμοι να αναπτύξουν οι άνθρωποι είναι ένα είδος ανώτατου ορίου για το πόση αξία μπορεί να επεξεργαστεί το δίκτυο.

Τελικά, αυτό που καταλήγει είναι ότι όταν ανοίγετε ένα κανάλι, αποφασίζετε να κλειδώσετε αυτά τα χρήματα έτσι ώστε να μπορούν να χρησιμοποιηθούν μόνο για τη δρομολόγηση πληρωμών σε αυτόν τον συνεργάτη καναλιού και σε όποιον είναι συνδεδεμένος στο γράφημα. Ναι, τελικά η ιδέα του Lightning Network είναι ότι, κάνοντας αρκετά hops, μπορείτε να βρείτε μια σύνδεση σχεδόν οπουδήποτε. Ωστόσο, η πραγματικότητα είναι ότι εάν κάποιος άλλος μπορεί να πραγματοποιήσει τη δρομολόγηση μιας πληρωμής σε έναν προορισμό χρησιμοποιώντας λιγότερα άλματα από ό,τι μπορείτε, αυτή είναι η διαδρομή που πιθανότατα θα επιλεγεί για τη δρομολόγηση της πληρωμής. Το Lightning απαιτεί ήδη σε μεγάλο βαθμό υπερασφάλιση, δηλαδή, για να δρομολογηθεί μια πληρωμή 1 BTC σε 10 άλματα, απαιτείται 10 BTC εξασφαλίσεων να κλειδωθούν σε κανάλια πληρωμής κατά μήκος αυτής της διαδρομής. Ο ανταγωνισμός για την ύπαρξη καλών συνδέσεων για τη δημιουργία εσόδων από τη δρομολόγηση το επιδεινώνει, παρέχοντας κίνητρα για ακόμη πιο περιττές εξασφαλίσεις.

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 κρατική αλυσίδα είναι ουσιαστικά κάτι σαν κανάλι Lightning, εκτός από το ότι μπορείτε να μεταβιβάσετε την ιδιοκτησία ολόκληρου του καναλιού εντελώς εκτός αλυσίδας. Το μοντέλο εμπιστοσύνης τους εξαρτάται από τον χειριστή (ο οποίος μπορεί να είναι μια ομοσπονδία) της statechain που αρνείται να συνεννοηθεί με προηγούμενους ιδιοκτήτες και να κλέψει την statechain από τον τρέχοντα ιδιοκτήτη. Δεν είναι τόσο αξιόπιστο όσο ένα κανάλι Lightning, αλλά είναι πολύ πιο ευέλικτο καθώς η ιδιοκτησία μπορεί να μεταδοθεί χωρίς να χρειάζεται να πραγματοποιήσετε μια συναλλαγή on-chain. Δεδομένου ότι οι statechains βασίζονται σε προ-υπογεγραμμένες συναλλαγές εκτός αλυσίδας, μπορείτε να προσθέσετε HTLC σε αυτές.

Αυτό τους επιτρέπει να χρησιμοποιούνται για τη βελτιστοποίηση της αποτελεσματικότητας της δρομολόγησης πληρωμών στο Lightning, επιτρέποντας στους χειριστές κόμβων να εκχωρούν εκ νέου τη ρευστότητα on the fly off-chain. Αντί να χρειάζεται να ανοίγουν κανάλια και να βυθίζουν τη ρευστότητά τους για να είναι καλά συνδεδεμένα εγκαίρως, τα κεφάλαιά τους μπορούν να ανακατανεμηθούν δυναμικά on the fly off-chain ως απάντηση στη μετατόπιση της ζήτησης σε μέρη με τα οποία δεν συνδέονται (ή δεν είναι αρκετά συνδεδεμένα με ). Η μόνη απαίτηση είναι το άλλο μέρος να θέλει να μετατοπίσει τη ρευστότητα στην εμπιστοσύνη του χειριστή της κρατικής αλυσίδας.

πλευρικές αλυσίδες

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.

Το πρόβλημα είναι πώς μπορώ, ως αποστολέας, να μάθω για αυτές τις σχέσεις; Στο Lightning, ο αποστολέας είναι αυτός που επιλέγει τη διαδρομή για μια πληρωμή, αφού κοιτάξει τον πίνακα δρομολόγησης των δημόσιων καναλιών στο δίκτυο που είναι πρόθυμοι να προωθήσουν πληρωμές. Για να διαφημίσετε τη δυνατότητα δρομολόγησης μιας πληρωμής απαιτείται η εμφάνιση της αλυσίδας UTXO που χρηματοδότησε το κανάλι Lightning σας και να αποδείξετε ότι είναι πραγματικό κανάλι. Αυτό που είναι το πρόβλημα εδώ, καμία από τις παραπάνω ιδέες δεν θα μπορούσε να το παρέχει, επομένως ο αποστολέας μιας πληρωμής θα μπορούσε να γνωρίζει αυτές τις άλλες επιλογές για τη δρομολόγηση μιας πληρωμής. Εάν το πρωτόκολλο κουτσομπολιού και η δομή του πίνακα δρομολόγησης ενημερωνόταν για να επιτρέψουν αυτά τα άλλα πράγματα, θα μπορούσαν να ενημερωθούν για άλλες επιλογές.

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.

Στο τέλος της ημέρας, υπάρχουν προβλήματα που πρέπει να λυθούν για να αυξηθεί η ευελιξία του τρόπου δρομολόγησης των πληρωμών στο δίκτυο, αλλά είναι επιλύσιμα προβλήματα. Το να πιστεύει κανείς ότι το Lightning πρέπει να συνεχίσει να λειτουργεί με τον τρόπο που λειτουργεί αυτή τη στιγμή για να λειτουργεί ως δίκτυο πληρωμών είναι πολύ περιορισμένο, και για να το θέσω ωμά, επινοώντας προβλήματα που είναι ως επί το πλείστον φανταστικά.

Αυτή είναι μια guest post από τον Shinobi. Οι απόψεις που εκφράζονται είναι εξ ολοκλήρου δικές τους και δεν αντικατοπτρίζουν απαραίτητα αυτές της BTC Inc ή Bitcoin περιοδικό.

Πρωτότυπη πηγή: Bitcoin περιοδικό