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

introduction

I launched a survey on Twitter and found that everyone seems to be interested in the limitations of the lightning network – what the lightning network can do or not. Today I will come and clarify the scope of the lightning network.

Channel configuration problem

From the very beginning of my contact with the lightning network, I was thinking about what the goal of the lightning network was; I suddenly saw the light – what if the world’s transactions were lightning transactions? (Of course this is impractical because there are too many types of transactions worldwide.) I want to use this assumption as an entry point to discuss how to make Lightning Network compatible with all transactions.

First we need to define the definition of lightning network – lightning network refers to the system built on the state channel of balance lock . In the system you and I hold some money, and then we use the lightning network to achieve "transfer money from me to you" or "transfer money from you to me." We can also use HTLCs to extend the above functions, such as implementing "I transfer money to you, and then you transfer money to someone." The premise of the above behavior is that we have the status channel locked by these balances, which is also the basic functional boundary of the lightning network. The problem now is that these channels have a fixed capacity and a collection of participants. If we need to send a large transaction temporarily, and before you have never had any interaction with the payee, you will face the channel is not correct. The problem of setting; you can change the settings yourself, but asking the user to do this is contrary to the original intention of designing the lightning network.

This may be the main problem with using Lightning Networks, but there are some issues that you might be interested in.

• Korea Exchange Bithumb enters STO field
• Is the pledge token cut off? BitGo co-founder talks about the vicious circle of Staking drive
• LTC's total network computing power has dropped significantly for the first time after reaching a four-month high this month.

First, the lightning network is a brand new ecosystem, the first platform, you need to learn how to use it, but also need some people to carry out protocol development, software development, routing nodes, guarantee funds and so on. Building a lightning network ecosystem is also a process of building a market. Without these people contributing, the lightning network will be worthless, so the establishment of an ecosystem is also one of the factors that constrain the lightning network.

Second, Layer-1 is a key factor in determining whether a lightning network can operate. Even if we can do a lot of things under the chain, we still need to ensure that these operations are based on the decentralized Layer-1, and the transactions under the chain can eventually be chained.

As far as the current situation is concerned, the Bitcoin network is the Layer-1 most likely to be the underlying support of the Layer 2 network (Lightning Network).

Large transaction

From a monetary point of view, we must ensure that Bitcoin is a popular payment instrument, because the biggest obstacle to recommending others to use the Lightning Network for payment is how to convince them to use such strange currency (bits Currency), what good is this for users? Why is this a cool thing? This seems to be something that our lightning network protocol developers can't control, but it is extremely important for the development of lightning networks.

I just want to emphasize that if you want to make low-frequency, high-volume, and occasional transactions, then using the lightning network will encounter many restrictions, which is not for you. Many people ask: "What is a big transaction? Is it more than $5? Is it more than $50,500?" – So asking itself is very problematic.

The Lightning Network is a market, an evolutionary ecosystem that you can think of as the Internet. The Internet also connects the intranet of the university and the intranet of the company. The users in the intranet are related to each other, so the network bandwidth is very large and the information can be sent quickly; however, once the user logs in to the Internet to watch the video or do something else They will face the "last mile" of the computer. The user thinks that the service provider can provide high-quality video, but when they dial the network, they find that (because the network speed is not enough), they can't see the HD video; or they use it. I want to upload a video, but I find that my upload speed is not enough.

My so-called "big deal" problem means the same thing as this speed issue .

If there is a network today, and each other is connected to each other in a channel with a balance locked to $1,000, then even if I am very wealthy and want to transfer the value of millions of dollars, I will still be limited by the capacity of the system. So even if I have a lot of money, I want to transfer money to someone in a channel with a lock-in balance of $1,000, so the upper limit is $1,000, which is called a large amount.

Blockchain vs lightning network

Why do you want to use blockchain? Blockchain technology is great, but you have to endure a lot of redundancy; state channels just benefit from redundancy. If you are operating high-value transactions, then the blockchain is right for you, because the blockchain can avoid problems that may arise during asset flow; at the same time, blockchains are relatively simple to use if you need to be as safe as possible. Local savings, I will say that use a super cold wallet.

The blockchain network shifts part of the responsibility to the entire blockchain community; the Lightning Network assigns more responsibility to the user, which means more difficult to use, as I will explain further.

Hosted vs lightning network

Another competitor to Lightning Networks is a hosted clearing-line network (eg, Liquid or similar exchanges) or other systems that use lightning networks, such as tipping.me or htlc.me I created. Compared to lightning networks, hosted work is suitable for low-value transactions, because the blockchain has a certain cost of winding, and if your trading quota is lower than this cost, then there will be some problems. Therefore, the difficulty of the blockchain in clearing small transactions also constrains the lightning network.

Lightning networks also have problems when sending large transactions. It’s probably not a business to launch tens of millions of transactions in the blockchain, but if it’s a multi-billion-dollar deal, you’ll start to worry about whether the blockchain’s workload proves to be reliable, and then you’ll miss hosting Service or other systems are better; even worse, the proof of work takes a long time, you can only wait. So lightning network can't do much. In the face of these kinds of situations, lightning network is not a good choice. If you can find a trustworthy host, don't mind making compromises, and don't want to take responsibility for the money, then hosted services will work better than Lightning.

Block size limit

I discuss the limitations of lightning networks from a more abstract perspective. If you mainly want to understand the limitations of lightning network scalability, let's talk about the block size limit. It’s very interesting to see how many transactions a block can fit in. I think it’s interesting to see how the trade is loaded into the block, so I made a chart to show the data of a normal trade. Composition, because the trading of the switching channel is an ordinary transaction, we can directly see how much data the switching channel needs to occupy. The legend shows a minimum channel, bytes are mapped to virtual bytes; because the isolation witness is used, the number of signature bytes is compressed. According to estimates, the size of a channel transaction is approximately 112 virtual bytes.

This is the minimum amount of data that theoretically constructs a channel. We can think of it as the unit channel size and estimate how many channel transactions can fit in a block. Each block has about one million bytes of space. If we can reduce the channel size to about 100 bytes, we should be able to put a lot of channels in the block. But this is not the case. To get the exact unit channel size, more complicated considerations are needed.

Tips for saving virtual bytes

Is there any way to reduce the channel switch transaction size to the theoretical minimum? If all transactions have only one output, you can save a lot of space. But when we close a channel, there may be multiple outputs because at least two of the channels are in the process of transferring funds. At this point you can stand up and call, "In order to reduce the size of the data on the chain, we will do a reorganization before closing the channel"; so we will launch one of the outputs in some way, so that the blockchain only needs to process one transaction. Output. Doing so saves block space while saving money.

Another way to release space on the chain is to "turn off one channel while closing another channel." In other words, because some transaction output can be used as input to other transactions, we can combine channels into one. This is a very useful technique.

Another useful technology that we don't currently support, but that will see progress in the short term is multi-signature conversion, which is the technique of compressing multiple signatures into a single signature . This technology is extremely powerful and there are few major flaws. Through signature aggregation, we are able to combine a large number of signatures into one. It's great to be able to use Schnorr and Musig for signature integration, but it's also possible with Elliptic Curve Digital Signature (ECDSA).

There is one more thing to consider. Many times people will estimate the cost of the winding and tend not to close the channel. For example, there is such a situation – "We want to broadcast the channel output, but the other party is offline, what should I do?"

In the example, if one party chooses not to close the channel, this does not need to be solved by any complicated script, because we can directly regard the operation that does not cooperate with the closed channel as one of the transaction failure conditions. We should try to use economic means to motivate people to close the channel with time locks or higher costs. For example, if you do not cooperate to close the channel, you have to pay more.

Another solution we have implemented to save virtual bytes is about the output of dust trading (for example, in a lightning network, there may be a trading output of only half a cent), because in the chain, this very small transaction The output is rejected by the blockchain or treated as a junk transaction during the peer-to-peer transmission phase. As a solution, the software puts these tiny outputs into the miners' fees, so when we have to close the channel in a non-cooperative manner, we can slightly increase the transaction confirmation speed.

Increase channel members and reduce virtual bytes

Another tool to improve the lightning network is to create multiple channels, not just channels that involve both parties. Of course, such a design is not a perfect solution, and the complexity of this mechanism limits its application. At present, we can only add two participants in one channel at most, and adding more people in one channel is actually a perfect way to expand the utilization of virtual bytes.

The constraint for joining multiple participants in a single channel is, how many outputs is the input converted to? The transactions in the channel will eventually fall into the blockchain. Even if we don't plan to package the transaction at a certain moment, we must have the ability to trade at any time.

The limitation now is that everyone wants to get back the trade output of their own. For example, when I close the channel, I want to take back my own money, and each output costs about 30 dummy bytes. In fact, you don't have to spend these 30 virtual bytes at this time, but when you encounter differences in the channel and can't finally integrate into an output situation, you must consume these 30 virtual bytes.

It must be reminded that these multi-participating channels require only one person to make a capital injection when they are established, that is, only one person is required to establish input and initiate a transaction. I can actually tell you after I have injected funds into the channel. "Take ten people to join the channel I just established. The input of this channel is my own. Everyone will then toss my input into everyone's output. Of course, these outputs are not immediately reflected in the blockchain, unless we can't continue to re-tune these outputs, we can only reluctantly close the channel and broadcast the transaction to the chain."

The number of participants in multiple channels can be quite high. Based on the signature integration technology I mentioned earlier—consolidating hundreds of signatures into one signature—in theory we can add thousands of participants to a single channel. You need to pay attention to setting the input: you are actually setting everyone's collective public key, and the collective public key is hashed by everyone's public key, so it doesn't need much storage space, it is fixed size. a section.

If the above ideas are implemented, it means we can add hundreds or thousands of channels to a block. Irresponsible to think about it, maybe thousands of participants can join the channel. Even from reality, reaching dozens of players is not a problem. In this way, we can handle transactions that reach millions of people in a week. In this way, the processing potential of the channel to increase the number of channel participants has considerable exploration space, and the direction of this effort does not change the attributes of the blockchain.

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."

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.

Original link:

Http://diyhpl.us/wiki/transcripts/boltathon/2019-04-06-alex-bosworth-major-limitations/

Author: Alex Bosworth

Translation & Proofreading: IAN LIU, Anzai Clint & Ajian

(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!