Dry goods | Current main limitations of Lightning Network (Part-2)

Editor's Note: This article is the second part of Alex Bosworth's article "Major Limitations of the Lightning Network". It talks very specifically about the problems and development directions in lightning network design, such as the division of responsibility between systems and users, and the transaction transmission. Routing problem. Obviously, although the principle of Layer-2 is very simple, it really needs to be done in order to make it work in an orderly manner.

Dry goods | Lightning network's current main limitations, Part-1

responsibility

Pulling the topic back to the system design, I want to talk about the malleable design of the lightning network and how we can achieve the extension . We are faced with these problems and are also responsible in the system. Participants in the system must answer the following questions: Whose money will be returned to whom? Who plays the control role? Did these operations occur in the channel? How is the channel established? Who is verifying these operations? Who will guarantee that everyone will abide by the rules? At the same time, how to ensure that everyone gets the right data? All of the above are high-level problems encountered by blockchains and lightning networks in terms of scalability.

Responsibility sharing

The design route of Lightning Network is to share responsibility. Everyone in the system needs to control as much of their responsibilities as possible, so that as many people as possible can be involved without giving the entire system too much responsibility . One principle that will be used in Lightning Networks is: "You must keep a database of your funds."

• Depth | DLT technology "touchstone" How does the central bank digital currency CBDC break into the butterfly?
• Getting started with blockchain | Teach you how to understand Bitcoin computing power
• The great game of 2.7 billion people, Facebook's launch of stable currency is imminent?

No one except you is obligated to tell you how much the transaction has received. You must track the metadata of your transaction, ie who sent the transaction and who sent the transaction to you. These will be your own. Responsibility, not the responsibility shared by everyone.

When you are doing some general operations and you have to prove it to others, you only need to show them the most basic evidence that their operations are legal. As a result, new users who join will not burden the system , and other methods will undermine the scalability of network growth. We also set up mechanisms to ensure that users only need to verify the block and check the transaction signatures and operations of other participants who interact with themselves. Users only need to interact with a small number of other participants in a fixed number of people, without the need to check each new person. This idea is also reflected in the data sharing of the lightning network. We will distribute only those data that are directly related to you—that is, what you need to pay attention to—may be part of the transaction. The number of other participants who define user interactions ensures that the network is expanded without increasing the marginal cost of adding new users.

Responsible agent

This poses a challenge for users to join the lightning network. In the blockchain, the system has already done a lot of work for you. The user does not need to be responsible for the database of his own funds, but is automatically completed by the blockchain system. You only need to take your own mnemonics, download the blockchain, and scan all the blocks to check where your funds are stored. We have done more work in this direction. Although there are many proposals that users should take more responsibility to allow Layer-1 to expand, at least for now we are not doing this. At the moment, as long as you have not forgotten the mnemonic, everything else is easy to say. In the blockchain, extension has become a problem because the addition of new users in the system has increased the number of people who need to be verified. For example, if there are a thousand new users added to the network, then every old user will have to check the thousands of new people, which is very unfavorable for extension. From the perspective of data sharing between users, the more users mean the more data, so with the expansion of the network, the resource overhead has also increased dramatically.

It's really hard to rely on others to manipulate data on the blockchain, and it's not so friendly to manage it all on the lightning network. What happens if a user loses their database? Since we have removed the responsibility of database sharing, database maintenance is now entirely the user's own work. If you lose the database, it will be bad luck.

One way to deal with this problem is to "take everyone to use responsible agents." That is to say, the responsibility is not completely on the user's shoulder, but there are some responsibility for the public share, but the user needs to decide how much share responsibility he wants to bear. We currently call this mechanism a data loss protection protocol , and lnd is in need of this feature.

Your partner node will help you save a small set of data, and when you want to close the channel but lose some of the data, provide you with the data you need to complete the shutdown . We just added this feature in version 0.6 to implement a static channel backup system. This is a set of data that you copied from elsewhere. You can copy it to the P2P service and put it on Google Drive as you wish. It is presented in an encrypted, small file format. We are currently working on the development of the watchtower project, which can be outsourced to the watchtower when you don't want to keep monitoring the channel or take on all the responsibilities of your own channel.

In systems such as blockchains, if someone wants to spend a double flower or something else, the entire social network will unite to smash their plot. The righteous will condemn: "You can't do this, it doesn't do anything good." Or otherwise invalidate these attacks. Comparing this behavior to the lightning network, you can say: "I want to choose these people as my observers, although I can take all of them myself, but then I can only hang on the Internet." . Also because the blockchain is a distributed ledger that shares all the data, it keeps the relevant data for you. In the lightning network, if you are not online, you may not receive data related to yourself. So we can delegate the responsibility and tell everyone: "This node can act as my mailbox." The node acting as the mailbox will delay the last step of the HTLC (Hash Time Lock Contract) and then send you an email, or you can Log in to the lightning network every day to check if the email is received . Then you will complete the last step of HTLC. The key to the design of the above mechanism is that although you need others to act as your mailbox, they cannot do anything about your assets. We will design a moderate solution at the responsibility delegation.

Routing restrictions

Another common dilemma in lightning networks is: How do we design routes? Routing jumps in lightning networks are very difficult, and its theoretical basis is based on the phenomenon of “six-degree connections” (Translator's Note: It can be described in a popular way: “The person you are separated from any stranger” No more than six, that is, you can meet any stranger with up to six people."). Choosing routing among such large, millions of users, jumping from one of the current million users to the next in another, is a very difficult problem.

However, there is a connection between people. I know you, and you know him. With this in mind, in theory, it is not difficult for me to jump to the recipient user through this middleman. The problem in practice is that we can't know who is online and who can help us find the intended users . Just knowing the relationship between users is not enough. You must also know who can respond to routing requests. Users also don't know how much money is in other people's channels, so we need to know which paths make it easy for us to restructure our funds so that no matter who we initiate the transaction, we can go smoothly. Think about the relationship between billions of people on a mobile phone, so much data should be updated in a timely manner, which is simply whimsical. It is impractical for the user to have a complete understanding of the entire picture. What we want to do is let the user know only a part of the relationship in the network (it will make the whole network work) .

dead end

Routing has another problem, big problem. What if a node does not forward your HTLC? What if they sit back and ignore the subsequent forwarding and return to the chain? Smart contracts on which Lightning Networks operates are built on these blocks of time. The block time can be long, theoretically for several days. Lnd allows you to set your own acceptable block time, but let the routing node accept this time as well. The paradox is that because the lightning network is an onion routing network, you can't tell who is forwarding the route for you. After you send the transaction from this point, your transaction is processed by someone else on the entire line. You can feel the delay of the operation, but you can't explore what it is, or how long it will take. Although this will not affect the safety of funds, your money is locked in the process, and it is very troublesome to call the user experience. I want to complete the payment, but I can't complete it immediately. This is the routing problem that lightning faces.

a trusted routing network

One solution to solve these problems is to divide the nodes into roles with different responsibilities. Each node can assume any role that you want to do, so you can think of each node as being the same, except that some nodes want to be distinguished from other nodes and play different roles . A simple example is that users of mobile end nodes do not want their mobile phones to be connected to the Internet at all times. After all, millions of nodes are already doing this kind of work. He only wants to be a consumer node. He can be a routing node if he can, but that's not what he wants.

In the future we will see the professional differentiation of nodes. We will have a specific set of nodes to transfer money and earn a fee. We divide the network into different types of nodes. If we can build a network in which we can identify which nodes are routing nodes based on the behavior of the nodes, then we can let the user choose the routing nodes autonomously …….. I will choose you to send my traffic. Because you seem to be online often, the success rate and speed are good. If we can build such a network, there will be people at the edge of the network, those who are mobile wallets or those who are not interested in routing or are not good at it will be assigned to the edge of the network. In the network center, there will be nodes that are good at routing, long-term online, and capable. Then we can better understand how to go from point A to point B on the network. It runs a web server on your laptop like the analog internet, but you don't have to. You can run it on a server somewhere. How you build it depends on you, but if you want to route on the Internet, you may need to choose a server.

This also solves the problem of capital liquidity that we mentioned before. If the routing node is equivalent to a broadband router and there are large channels between routing nodes, then you no longer need to consider the mobility problem at the destination. You can rely on routing nodes to connect to each other very well.

The only question is whether you can reach the routing node, which is the opposite, that is, whether the receiver can receive your transaction from the routing node . This makes the problem easier, because you don't have to worry about whether the six hops (in the delivery path) have the right fluidity, you only need to pay attention to whether the first hop is you during the delivery process, and the last hop is The recipient will be fine. In order to achieve this effect, we need to establish a market. What we need is to reward the routing nodes that have completed the work, so that the routing nodes run smoothly, and the routing nodes are not expensive to run, so they only need to charge a limited fee. This is a process of market formation and a process of software perfection.

Common reference point

Once we have such a network, we can use good routing nodes and solve the computation of routing maps. Our original idea is: I am one of a billion people, so I need to pass through such a network of one billion people to get to other people's nodes from my node. How can I do this? I even have a route map. nothing.

But now, for example, if you want to initiate a payment request, you can record (and send it to me) the reference point nodes that are well connected to you. You can treat all good routing nodes as reference points. When I choose to make a payment, I can see the (all) reference points because the number of reference points is limited and they are well connected. Although I can't understand the entire route map, when you send a payment request to me, it can contain the last part of the path to your node . This makes routing easier. We can even outsource the routing time period and even just outsource the relevant computing part.

Some people recently talked about how to ensure privacy. If you don't have this need, you only need to pay for the people you can find and keep them in sync with the billions of people on the network. They will try their best to find the most economical model. You can outsource to them without trusting them, because you can… (Translator's Note: Original). At the same time, I also think there is a trade-off between outsourcing, and you may not get the perfect path because of the trade-offs of the entire network. There may be programs with lower fees and better privacy.

So far, the route map algorithm can only focus on providing you with the current minimum cost and trying to lower the cost over time. In the future, due to the limited nature, we realize that we can't get a perfect path, so we only need to get an acceptable path.

Capital limit

Another huge limitation on the lightning network that I talked about earlier is that there are financial restrictions. You have some small (transfer) channels and small (UTXO) outputs. You sent 100 Sat, but the deal was not able to go on the chain (because the amount is too small). If you have more money, such as $5, you can chain the deal regardless of the current fee or the conditions of the chain. Large transactions also encounter liquidity problems. This is the basic limitation of the lightning network.

Multiple payment path

There is currently a solution, although not completely solved, but the idea of ​​reaching the destination through multiple paths is indeed very helpful for the subsequent development . We have a variety of ways to achieve it. At present, we can immediately adopt a solution that has been tested in the real network and is not too difficult to implement. This is Base AMP. For example: "I want to get $100, so I waited until I received a $100 equivalent HTLC (Hash Time Lockout), and you would send a total value of $100 through a different path. Multiple HTLCs, I only receive it before receiving all HTLC, but I won't expose that pre-image (that is, the data used to build the hash lock). Once I get $100, I expose the pre-image and Take out all the money in the HTLC." This is a low-tech but safe AMP solution. Although the current client does not support this well, it is indeed a worthwhile solution.

Another way to send more money and circumvent the maximum limit of a single channel is, if we have multiple channels in a single transfer direction, and the same solution, you only need to wait between two different nodes. HTLC. You don't even need to let the sender and receiver know this, just set it up in the routing path.

In the future, we can adopt a scheme in which we get pre-image and decompose it into a bunch of different encrypted information, so even in Base AMP, the recipient will be economically motivated to wait for information. By using Schnorr signatures, using more advanced structures, even if they want to get such information, they can't be implemented.

Multi-system support

Another thing we can do with Lightning Networks is to accept these limitations and to suggest small tricks to deal with some marginal situations. Due to the small size, we can make some small (UTXO) output a transaction fee. At the same time, we can also do some crazy things, such as probabilistic payment, "we have a 1% chance of getting $100". We can use this chain or that chain. We can use the Liquid side chain. This may come in handy if we close the channel and remove traffic in order to absolutely minimize the size of the channel on the chain. We can use different methods to use other different chains to transfer other outputs through submarine swaps (a backbone and lightning network asset transfer scenario). We can also return to the chain. We can say, “Let's integrate the assets sent by the main chain and the assets sent by the lightning network into the same wallet. In this case, if the amount sent is too large and fails, we can accept it and switch to the main chain to complete the cooperation. Transfer.” Now people are also trying a mode called turbo, which can achieve zero confirmation channel in certain situations. This means you can get the benefits of both the main chain and the lightning network, that is, you can stay in the lightning network system but use the main chain to transfer any high-value assets. Another way I think is cool, I don't know if anyone is studying this issue. In small transactions, we can use client-side signatures to handle small commits between nodes. We can use e-cash so that you can secretly trade some tiny commits that don't make sense in the main chain. Finally, another thing we can do is to increase the limits of the assets, thereby increasing the complexity of the capital market. This is another direction that people are working on now. For example, Bitrefill focuses on the turbo mode but also works on the Thor project, which allows you to purchase inbound liquid assets (ie receive other node data), which is in line with our Lightning Lab. The Lightning Loop project coincides. When we have more tools, we will attract more mature buyers and sellers, and you will be able to enhance your ability to circumvent asset restrictions.

Version 1.0 protocol restrictions

I have added many other things to this speech. What I want to talk about is that the 1.0 protocol actually has some annoying limitations. I hope to emphasize it here. Considering the importance of the lightning network, although it is not a static agreement, we need to adapt and develop. This is a good thing.

I think the first problem to be fixed in the 1.0 version of the protocol is that when you force a channel to close, the returned forced (UTXO) output uses a random key. If you only have your seed, you can't scan all the blocks from the main chain to find your assets, because these are random keys and you don't know what the random number is. This is a problem in version 1.0. This increases the amount of material you need to back up. You need to keep your own random numbers from time to time.

Of course, there are other issues. Whenever you close a channel on the blockchain, the corresponding funds are locked into a CSV output (ie CheckSequenceVerify file), which means that it will lock for a certain amount of time, only in certain blocks. Can only be unlocked after being dug out. This raises another problem, you can't bounce the fees in a CPFP (Child-pays-for-parent) transaction because you can't spend it before several blocks are confirmed. . CPFP requires you to put parent transactions and sub-transactions in the same block in order to bind the benefits to the same miner. Another problem we know is that the capacity of the channel is fixed, and we have a lower limit on the capacity of the channel, such as 0.16. This has created a lot of problems, especially for the exchange to support the lightning network. It is very difficult to achieve now. Another problem with spending is that if you have some low-cost transactions during the capital surge, you will have difficulty negotiating with other nodes to raise the fee. This is also the limitation that Lightning Networks is facing now, because the agreement does not support it, you can't send it to others, and others can't accept it.

Upgrade to version 1.1 agreement

In version 1.1, if it can be completed successfully, we will add various new features to solve all the above problems. We will set the remote address to be static so that if you have forcibly closed the channel, you can also scan the entire main chain to get the information you want. You don't have to keep that string of random numbers. In CSV-constrained transactions, we add some other trigger conditions. I have some timeouts, I will not continue to extend, enter the Q&A session.

Question and answer

Q – AMP Is there a problem with the current system, that is, a node may hold HTLC and lock in mobility? How to deal with this?

A – Of course, first of all, I think you have to consider the entire routing node network. You are not sending through a completely random node. Your transmission is through a dedicated network of nodes. In fact, these selected nodes are motivated by your large fees. You still have the problem that you are not sure which nodes are doing evil. There is another way to solve this problem. Once we have these push transactions, or if we have more interaction with the receiver, we can check to see if it is valid to pre-verify the routing path. In this case, we are not using real money, we are using some false hashes that they do not know. We can say "this problem is already a past tense." We can send it again. With this in mind, we can make this situation less and less.

Q – How to solve the wide channel balance problem in the network?

A – I do think that we should reflect on the idea of ​​capital as a commodity. Liquidity is a product. I have seen many people talk about "Can you inject some liquid assets into me?" I think the corresponding mature approach is “Do you want inbound liquid assets? Please go into the inbound mobile market first to find out if you have the inbound liquid assets you want.” Once we have a more mature solution, we can target your Specific liquidity issues suggest a simpler approach.

Q – Is it possible to change the lower value limit of the HTLC that is willing to forward after the channel is opened?

A – Yes, I think this size is adjustable. You can say that this is part of the channel strategy. Of course, it is technically possible. You can receive an HTLC and say "This is too small, I refuse to accept it."

Q – Will we increase the size of the channel in version 1.1?

A – Yes, in fact it is unlimited. The capacity of the channel is unrestricted. But we still have such a problem, we may need some default security restrictions, so we can discuss the more reasonable values. Second, even if a node in a path has a huge capacity, it does not mean that all nodes in the path have such a large capacity. Therefore, a better way is to slowly grow as an ecosystem.

Q – I want to move my Ind node to the .onion network to hide my IP, but I hope I can still access my e-commerce store via the Ind REST API. What do you think I should do? Is it using a VPN to replace Tor?

A- No. Tor is only available for the lightning network node itself. I am doing this with your own node on Tor-based Yalls.org. I suggest that everyone build their own nodes based on Tor, which is cool. It will still maintain a normal network open, so you can get your own IP and use it normally.

Q – Which primary use cases or services do you think will be open in version 1.1?

A – I am not very clear about the exact, these are still being worked out. Push transactions are one of my most anticipated because it allows full interaction on the network. You can use an API that only exists on Lightning Networks, not elsewhere. You are not using an HTTP REST API, but a Lightning Network API. This is the coolest thing for me.

Q – What do you recommend for developers who are trying to better understand the Lightning Network?

A – I really like the BOLT RFC, which is where I explored the lightning network. I just browsed through all the different RFCs. They have changed, but you can still see some main chain deals or other things. Lightning Labs has an API development system, on which I built my own internal service library, which can make things simple and work well. This is also what I used when building Y'alls and HTLC.me.

Original link: http://diyhpl.us/wiki/transcripts/boltathon/2019-04-06-alex-bosworth-major-limitations/ Author: Alex Bosworth translation & proofreading: Leonard Clint, Whisker & A sword

(This article is from the EthFans of Ethereum fans, and it is strictly forbidden to reprint without the permission of the author.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!