Partnered With:

Detail the accounting capacity problem of lightning network

Read this article in 14 Minutes

Not all nodes in a lightning network have the same needs.

The Inbound Capacity Problem in The Lightning Network

原文作者： Florencia Ravenna

原文编译：阿剑，以太坊爱好者

For weeks, many in the Bitcoin community have been talking about inbound Capacity for the Lightning Network. It's getting harder and harder to get lightning torches, plus & NBSP; Bitrefill starts Thor, and there's The LAUNCH of the Lightning Loop by LND brought more attention to this issue. In this article, I'll explain the form of the problem and its roots.

We'll also share some insights that are too easy to miss.

Local and remote balances

To understand billing capacity, we need to dive into the first basic building block of the Lightning network: the payment channel. This is a concept you've probably heard before, so let's jump right to the part about booking capacity.

Let's start with a single channel, and then slowly increase the complexity of our thinking.

When a payment channel is open, it locks a constant amount of BTC called " channel capacity ". . The parties involved in the payment channel each own a portion of this capacity. The balance on your side, we call it "local balance". And the balance on your counterparty's side is called the "remote balance." . Your local balance and remote balance can be updated as many times as you want before closing the channel, but the channel capacity cannot be changed unless you close the channel or splice the channel.

- The payment channel is like an hourglass: although the total amount of sand is constant, you can move the sand to one end at will. But if you want to change the amount of sand in it, you have to break this hourglass

- Your channel with Robert has 8 BTC, your local balance is 5 BTC, your remote balance is 3 BTC -

With each payment, you're transferring some of your local balance to your counterparty, reducing your local balance and increasing your remote balance. Similarly, when you receive a payment, your local balance increases by exactly the same amount as your remote balance decreases.

- After you pay 1 BTC to Robert, your remote balance increases by 1 BTC -

The capacity of entry and exit

Now that we have a better understanding of what determines channel capacity and how local and remote balances are updated, let's think about the difference if you are a node in a lightning network, part of the network.

There is no direct payment channel between the two parties. However, they can do it through & NBSP; Routing node & NBSP; Payment to be made. A two-way payment channel is used for each transfer along the entire payment path. Therefore, the characteristics of the payment channel we just talked about apply to every transfer.

Suppose you want to sell stickers through the Lightning Network. Then, you need to establish a connection to at least one lightning network node. You carefully select a node that is likely to be connected to your potential clients Sophie and Angela. Let's call this node lnTop.

- You opened a channel with InTop and locked in 2 BTC. Your local balance is 2 BTC and your remote balance is 0 BTC -

Now, Angela wants to buy some of your stickers and pay for them through lnTop. However, in the channel between you and lnTop, your remote balance is 0, so lnTop can't pay you. Therefore, lnTop cannot route this transaction.

The amount of BTC you can receive at a point in time (also known as the "booking capacity") is determined by your remote balance. It's very simple, if you're connected to a node that can only send you 1 BTC, you can't receive more than 1 BTC. Similarly, the amount of BTC you can send (" outgoing capacity ") is determined by your local balance.

When you decide to open a channel with lnTop, you need to determine how much BTC you want to lock in, i.e. what your initial local balance is. Same with lnTop, their selection determines your initial remote balance. This has an important effect. While you can determine your initial local balance (your initial outgoing capacity), you have no control over your initial remote balance (and incoming capacity).

If you were to launch your own Lightning network node today, and you just randomly selected a node to open the channel, you might find that you have no billing capacity available, that is, you can't receive payments through the Lightning network at all. Sounds very unfriendly to businessmen, doesn't it?

The good news is that there are many ways you can increase your booking capacity, such as initiating the payment yourself, or asking other nodes for capacity (and paying them for it). This article explains different solutions to the accounting capacity problem.

Is it that simple?

HMM... Also is not. Even if you know how you can increase the remote balance, you may not be able to solve the booking capacity problem. Here's the catch: Not all channels have the same billing capacity. To understand that, you have to understand what happens to other parts of the lightning network in the process of paying for routing. Let's plot out the channel capacity of the network shown in the figure above to make it easier to understand.

- This is what happens when lnTop charges 3 BTC into the channel. In a network, all nodes have special local and remote balances - with the nodes they are connected to

After you get some booking capacity from lnTop, Angela can only send you 2 BTC at most, because your booking capacity from lnTop is more than 2 BTC, but lnTop's booking capacity from Angela is only 2 BTC.

However, in this network, Sophie cannot send you 1 BTC. You can look at the channel capacity status on the path Sophie paid you. You do have 3 BTC capacity, but lnTop does not have lnFirst capacity. For payment, each node that participates in routing and you (the recipient) must have enough booking capacity to keep up with one node. So, although you can solve the problem of lnTop's booking capacity with neighboring nodes, lnTop may not have enough booking capacity with neighboring nodes. Alex Bosworth, Lightning Labs' director of Lightning Network infrastructure, pointed out this problem a few weeks ago. There is also a fact that makes it hard to solve. It is impossible to reveal the local and remote balances of all nodes on the Lightning network. As a node in a network, you only know the channel capacity, not how that capacity is distributed between the two actors.

Who will be affected by this problem?

Not all nodes in a lightning network have the same needs. From the above example, we can identify at least three types of nodes.

Merchant nodes We use the term merchant nodes to refer to those nodes that are primarily billing collectors. In the example above, "you" is a billing node because all you care about is receiving the payment from the sticker buyer. So you need the booking capacity. Remember: not only do you have to have enough bookkeeping, but there must be enough bookkeeping at all points along the payment path from the buyer to you.

End user nodes These nodes primarily use the Lightning network to send accounts. Occasionally they receive money from friends or from the Lightning app. Sophie and Angela are both end users. For this group, the key is to connect to nodes that are well funded and connected to businesses. They need both entry and exit capacity, depending on what they need at a given time.

Routing nodes These nodes are the nodes from which routing payments are made and from which fees are earned. LnTop and lnFirst are both such nodes. Their job is to find the people who need it, like you, the biggest sticker seller in town. For the end user, they need sufficient inbound traffic; For merchants, they need the capacity to pay out. They also have to compete with other services in the market and make sure they're always online. It's not easy to make some money, is it?

conclusion

We started with a single channel, explained the characteristics of channels within the network, and finally discussed the problem of billing capacity using the assumption that "node information is fully open". We define the entry capacity as the amount of BTC you can receive in the Lightning network at a given point in time and deduce that it depends on your remote balance. Booking capacity issues are likely to be a lightning network startup problem. So if liquidity were more fully and better distributed across the network, the problem would be lessened. We'll continue to write about some of the early problems with the Lightning Network.