Read the Bitcoin Lightning Network Mechanism, Progress and Challenges in One Article

Written by: Baijun Qian, HashKey Capital Research

Review: Zou Chuanwei, Chief Economist of Wanxiang Blockchain, PlatON

Source: Chain News

It's time to seriously study the technology, solutions and recent developments of the Bitcoin Lightning Network. Lightning Network's once-criticized asset security issues have been significantly improved in 2019, and the user experience has also been optimized. The problem that the Lightning Network was limited to small payments in the past was also solved by the expansion of payment paths.

• Application of DAO: DAO of Art
• Bitcoin's Secret History: How Much Bitcoin Satoshi has
• bZx revelation: What should Oracle oracles need for DeFi?

In the future, HTLC (Hashing Time Locking Contract) with atomic multipath payment will multiply routing options, which is expected to greatly increase channel liquidity. But the challenge still exists: the stability and payment scale of the Lightning Network system are still insufficient, and it cannot support most application layers, so there is still a long way to go before large-scale commercial applications and large-scale user expansion. In addition, Lightning Network channel fees are too low, and the number of nodes is rising slowly. How to motivate operating nodes to join will also be a big test.

The Lightning Network is a Bitcoin off-chain payment protocol, the goal of which is to solve the scalability problem of Bitcoin. Although the Lightning Network is still in its early stages of development, the Bitcoin payment network plus the Lightning Network uses off-chain payments and the concept of "net margin rolling" to help improve Bitcoin transaction efficiency, reduce transaction costs, and strengthen it to a certain extent. The attributes of Bitcoin as a medium of transaction.

This article will explain and analyze the progress and challenges of the Bitcoin Lightning Network through three aspects:

• The first part introduces the operation mechanism of Lightning Network;
• The second part introduces the progress of Lightning Network technology in 2019;
• The third part introduces the landing situation of Lightning Network and the problems to be solved.

Lightning Network Operation Mechanism

Lightning Network is based on the evolution of micro payment channels (two-way payment channels). It is constructed by the two concepts of micro banking and payment channels, and has designed two types of transaction contracts on the concept of payment channels-revocable serial maturity contracts. RSMC (Revocable Sequence Maturity Contract) and Hash Time Lock Contract (HTLC). Among them, RSMC solves the problem of one-way currency flow and confirmation of power in the channel, and HTLC solves the problem of currency cross-node transmission channel.

The advantages of Lightning Network include: First, the transaction costs are low, and no miners are required to participate. Users only need to pay the channel fees for the intermediate nodes. Second, the transaction time is fast, with only a few nodes participating, maintaining second-level transaction time. Third, the data storage burden is small, most of the data is stored off-chain, and there is little pressure on the chain. Fourth, privacy, transaction data is not on-chain, and privacy is protected to a certain degree.

Next, the key components of the Lightning Network are introduced in turn: smart contracts (microbanks), payment channels (RSMC and HTLC), routing and fee mechanisms.

Smart contract

Smart contracts on the Lightning Network chain operate like microbanks. Users A and B (the counterparties to each other) are like depositors of micro-banks, and the transactions in the payment channel are the acts of both parties to adjust their respective deposit balances. The following elements exist in microbanking:

• Point-to-point: Only A and B exist
• No trust required: open, transparent, non-tamperable, non-forgeable
• Autonomy: A and B jointly manage assets on the chain
• Double sign: Assets on the chain require signatures from both parties
• Commitment: Both parties reached a consensus on the deposit balance adjustment plan, and both parties signed it. This message is not broadcast to the chain immediately, but is stored locally by both parties and can be overwritten by mutual agreement.

Payment channel

The payment channel is a payment network that uses the Lightning Network to host the assets of both parties and re-liquidates the deposit balances of both parties through a joint commitment to achieve the effect of value transfer.

RSMC

First assume that there is a payment channel between the two parties to the transaction. The two parties of the transaction first deposit a part of the funds into the micro payment channel. In the initial situation, the distribution plan of the two parties is equal to the pre-stored amount. After each transaction, it is necessary to jointly confirm the adjusted fund allocation plan, and at the same time sign the old version of the allocation plan to be abolished. When any party needs to withdraw cash, the transaction results signed by both parties in his hand are written into the blockchain network and confirmed. It needs to be emphasized that it is only necessary to pass the blockchain when withdrawing cash.

Any version of the fund distribution plan needs to be signed and authenticated by both parties to be legal. Either party can request a withdrawal at any time. At the time of withdrawal, a fund allocation plan signed by both parties is required (meaning that the result after a transaction has been confirmed by both parties, but not necessarily the latest result). Within a certain period of time, if the other party presents a certificate showing that the scheme is not the latest transaction result, the claimant's funds are attributed to the questioning party (penalty mechanism); otherwise, the claimant's results are allocated. The penalty mechanism can ensure that users do not intentionally use old transaction results to withdraw cash. Even if both parties have confirmed a withdrawal, the claimant's funds will arrive later than the other party.

• RSMC transaction structure

Figure 1: RSMC transaction structure, source: https://blocking.net/1516/bitcoin-lightning-network-rsmc/

Suppose Alice and Bob want to conduct an off-chain Lightning Network transaction, and the pre-stored amount of both parties is 0.5 BTC.

First, Alice and Bob each put a 0.5 BTC margin into a 2-2 multi-signature address (that is, Funding Tx). Funding Tx transactions are not signed for the time being and are not broadcast on the chain.

Alice then constructs a committed transaction C1a, which contains a refund transaction RD1a. The first output of C1a is RD1a. The multi-signature of Alice's other private key, Alice2 and Bob's private key, is transferred to Alice's address by 0.5 BTC. But RD1a contains a seq variable to prevent it from entering the block immediately, but has to wait for seq = 100 blocks. The second output of C1a is to transfer 0.5 BTC to Bob's address. Alice hands C1a / RD1a to Bob for signature.

At the same time, Bob constructs a committed transaction C1b, which contains a refund transaction RD1b. The first output of C1b is RD1b, and the multi-signature of Bob's another private key, Bob2 and Alice's private key, transfers 0.5 BTC to Bob's address. But RD1b contains a seq variable to prevent it from entering the block immediately. Instead, it has to wait for seq = 1000 blocks to confirm. The second output of C1b is to transfer 0.5 BTC to Alice's address. Bob hands C1b / RD1b to Alice for signature.

Bob then signs C1a / RD1a and returns it to Alice, while Alice signs C1b / RD1b and returns it to Bob.

Finally, Alice checks the signatures of C1a / RD1a and Bob, and signs them after confirming. At the same time, Bob checks the signatures of C1b / RD1b and Alice, and signs them after confirming.

Two points can be seen: First, C1a / RD1a and C1b / RD1b are symmetrical in structure with each other. In fact, they stand on the respective positions of Alice and Bob, and express the fact that the pre-deposited amount of both parties is 0.5 BTC. A property right relationship, each expressed "). This is similar to the concept of ancient Chinese "coupons": writing a contract with bamboo chips, divided into two coupons, one for each, and the left coupon is the voucher for performance claims in the contract. But C1a / RD1a and C1b / RD1b are equal in status compared to left and right bonds.

Second, C1a and C1b spend the same transaction output, so only one of C1a and C1b can be packed into a block. If Alice broadcasts C1a, then Bob can get 0.5 BTC immediately, and Alice has to wait for confirmation of seq = 1000 blocks before getting 0.5 BTC. Conversely, if Bob broadcasts C1b, then Alice can get 0.5 BTC immediately, and Bob will only get 0.5 BTC after the confirmation of seq = 1000 blocks. In other words, if one side of the transaction broadcasts the transaction unilaterally to close the payment channel, he will delay the withdrawal of his own funds, while the other party can immediately get back his own funds. This arrangement constitutes protection for the latter.

• RSMC Trading Update

Suppose Alice pays 0.1 BTC to Bob, then the fund allocation scheme of both parties in the payment channel will change from 0.5 / 0.5 to 0.4 / 0.6. As before, in accordance with the principle of "one property right and one expression," Alice and Bob will construct C2a / RD2a and C2b / RD2b, respectively, to confirm the adjusted funding allocation plan (Figure 2).

Figure 2: RSMC transaction update, source: https://blocking.net/1516/bitcoin-lightning-network-rsmc/

At the same time, both parties need to sign off the old version of the fund allocation plan (C1a / RD1a and C1b / RD1b). This requires the Reveal to Revoke arrangement.

In C1a's first output RD1a, Alice hands Bob, another private key of her, Alice2, which means that Alice gives up C1a and recognizes C2a. If Alice regrets, then Bob can use Alice2 to construct a penalty transaction BR1a. The penalty transaction transfers Alice's funds to Bob's address and is not subject to the seq variable. If Alice broadcasts C1a / RD1a, then Bob broadcasts BR1a. BR1a will be executed before RD1a, which will punish Alice.

Figure 3: Penalty transactions, source: https://blocking.net/1516/bitcoin-lightning-network-rsmc/

Conversely, in the first output RD1b of C1b, Bob gives his other private key Bob2 to Alice, which means that Bob gives up C1b and recognizes C2b. Similarly, Alice can construct a punishment transaction to counter Bob.

It is not difficult to see from the above that the seq variable provides a time window for punishment and countermeasures.

• RSMC transaction terminated

Close the payment channel, and construct and broadcast the transaction according to the fund distribution plan finally approved by both parties.

HTLC

RSMC can already meet the basic clearing requirements, but there are also obvious limitations: both parties who settle through the RSMC solution must establish a direct payment channel to pay. Based on this pain point, Lightning Network needs another protocol, HTLC.

HTLC supports "Conditional Payment", which is a payment path formed by connecting multiple payment channels connected end to end, and supports both ends to complete the payment through the payment path.

The core of HTLC is time lock and hash lock. The time lock is valid only when both parties agree to submit within a certain time T, and the timeout will invalidate the commitment scheme (either the submitter or the receiver). A hash lock can be understood as: for a hash value H, providing the original image R, so that Hash (R) = H, the promise is valid; otherwise, it is invalid. If the payment transaction fails for various reasons, time lock can allow the parties involved in the transaction to recover their funds and avoid fraud.

Suppose Alice wants to open a transaction with Bob, the transaction amount is 0.5 BTC, but Alice needs to go through Carol to establish a channel with Bob for trading (Figure 4):

Figure 4: HTLC and payment path

Step 1: Bob sets the original image R (also called the implied number), and tells Alice the hash value H = Hash (R).

Step 2: Alice makes conditional payment to Carol via HTLC: Alice pays Carol 0.5 BTC if and only if Carol provides the preimage corresponding to the hash value H before time T. Similarly, Carol makes conditional payments to Bob via HTLC: Carol pays 0.5 BTC to Bob if and only if Bob provides the preimage corresponding to the hash value H before time t. Among them, t <T.

Step 3: Bob provides R to Carol before time t and gets 0.5 BTC. At this time, Carol knows R. Conversely, 0.5 BTC will be returned to Carol, and Carol will not suffer any losses.

Step 4: Carol provides R to Alice before time T and gets 0.5 BTC. Conversely, 0.5 BTC will be returned to Alice, and Alice will not suffer any losses.

Two points can be seen: first, under HTLC, payments are either completed or incomplete but do not cause losses to participants, so they are "atomic", which is the result of sequential game equilibrium; Second, the original image R (information) and funds flow in opposite directions, and the original image R can be regarded as a receipt.

In general, RSMC guarantees that direct transactions between two people can be completed off-chain, and HTLC guarantees that transfers between any two people can be completed through a payment channel that connects end to end. The Lightning Network integrates these two mechanisms, so that transactions between any two people can be completed off-chain. In the entire transaction, smart contracts play an important role as an intermediary, and the blockchain network ensures that the final transaction result is confirmed.

routing

Lightning Network uses source routing and onion routing. Through source routing, the source node is responsible for calculating the entire payment path from the source to the destination. To this end, the source node needs to download the complete public payment channel table in order to calculate a payment path, and calculate the commission and required number according to the load of all channels involved in this payment path. In peer-to-peer transactions, this process involves a large amount of data, and the amount of data will increase as the network expands. Onion routing prevents the middle node of the transaction chain from knowing the entire transaction initiator or recipient, which protects user privacy.

Due to the timeliness of HTLC, transactions are not fast enough to fail, so increasing transaction propagation speed is very important for the efficiency of Lightning Network. To increase the speed of transaction propagation, the most important issue is how to plan the shortest payment path.

Lightning Network uses the PBMC (Probability-based mission control) mechanism to solve this problem. Initially, each node has a default success rate, which is adjusted according to the actual transfer completion rate. The more transactions routed by the network, the better the task control component understands the characteristics of the network and the better it can plan payment paths.

Cost mechanism

For on-chain BTC transactions, the user selects a transaction fee for each transaction, and the miner selects a transaction with a higher transaction fee to generate a block to maximize revenue. However, Lightning Network currently operates in another way: node operators set fees, and users choose paths and channels for their payments to minimize the fees. Therefore, Lightning Network can provide a lower-cost charging structure. Operators provide specialized services, and it is more appropriate for operators (rather than ordinary users) to compete on rates, and it is more convenient to operate.

In Lightning Network, node operators must determine two types of routing fees: basic fees and rates. The basic fee is a fixed fee charged when each transaction is paid through a route, expressed in one thousandth of a Satoshi. For example, a basic fee of 1,000 means that the basic fee for each transaction is Satoshi. The rate refers to a certain percentage of the value of the payment. The actual rate formula is the rate divided by 1,000,000. For example, a rate of 1,000 means 1,000 / 1,000,000, which is 0.1%. Once the transfer is successful, the routing channel will charge a 0.1% transfer value fee.

In addition, in order to provide liquidity for routing payments, Lightning Network node operators need to lock a certain number of bitcoins in payment channels, including inbound and outbound flows. Inbound flow refers to the maximum amount of funds that a node's payment channel can receive from other routing nodes. Outbound flow refers to the maximum amount of funds that a node's payment channel can use to pay other routing nodes. Nodes can control outbound flows, but they cannot control inbound flows, because inbound flows depend on the amount of funds deposited in the channel by other routing nodes. For example, if node A wants to collect 1 BTC of node C through routing node B, then node A needs to have an inflow of at least 1 BTC. That is, routing node B needs to place at least 1 BTC in the channel between A and B for the transaction to succeed.

Uncontrolled inbound flows can cause inefficiencies in Lightning Network transactions. If there is more than one routing node separated by two node transactions, even if the inbound mobile balance can be sufficient on its own, it is impossible to confirm whether the inbound mobile balance of other routing nodes is sufficient. As long as one routing node has insufficient entry balance, it will cause transaction failure.

The node operator needs to adjust the basic fee and rate from time to time and monitor the adjusted impact. Because the payment demand channel changes from time to time, and the current rate is generally too low (the average daily income of a large node is 100,000 Satoshi, which is equal to about $ 7), so most nodes are unable to make ends meet. Therefore, the current liquidity providers in the Lightning Network are not driven by return on investment. However, in order to achieve large-scale applications, Lightning Network's rate design needs to rethink incentives and attract node operators by considering both return on investment and liquidity structure.

Lightning Network Technology Progress in 2019

In 2019, there have been many advances in Lightning Network, which have significantly increased ease of use, user asset security, and payment scale. The following are the four more important technological advances:

Watchtowers

The Lightning Network white paper first described the watchtower mechanism, which was improved and applied in 2019. The watchtower targets the issue that people using Lightning Network need to stay online to ensure that their counterparties are not trying to steal funds. The watchtower can detect whether the dishonest party is trying to steal funds, and then broadcast the message of the correct transaction, sending the funds back to the honest party (even if the honest node is offline). In other words, if a misbehaving node attempts to propagate an old transaction, the watchtower will punish the node.

Lightning Network users can connect professionally operated third-party watchtowers to protect their interests, and any routing node can also run their own watchtowers to protect their own interests. Lookouts can also bring intimidation and curb fraud effects. For potential attackers, because it is unclear whether the counterparty is linked to the watchtower, the cost of fraud will increase significantly. Figure 5 shows the operation mechanism of the watchtower. The watchtower actually implements the punishment mechanism of Figure 3 on behalf of the general users.

Figure 5: Watchtower operating mechanism

Continuing the expressions in Figures 1-3, consider two counterparties, Alice and Bob, each putting 0.5 BTC in the channel (ie, C1a / RD1a and C1b / RD1b, might as well be called transaction 1 or "old transaction"), and then Alice pays Bob 0.1 BTC (that is, C2a / RD2a and C2b / RD2b, may be referred to as transaction 2 or "new transaction"). At this point, the channel balance should be 0.4 BTC for Alice and 0.6 BTC for Bob. Suppose Alice wants to cheat and broadcast the channel status of transaction 1 with the signatures of both parties to the chain. If Bob does not go online to submit an objection within the seq = 1000 block confirmation time, the fraud will succeed and Bob will lose 0.1 BTC.

Suppose Bob entrusts a watchtower to prevent counterparty fraud. Bob establishes a reversal transaction (BR1a in Figure 3), authorizing the watchtower to revoke expired transactions broadcast by the counterparty if necessary. Bob pre-signed the transaction and set the implied number, and sent the implied number and the pre-signed transaction to the watchtower. This hint allows the watchtower to identify outdated transactions, but it does not let the watchtower know transaction details or channel balances.

Thereafter, whenever a new transaction is broadcast on the blockchain, the watchtower compares the number of hints based on the hash table. Once the implied number of a transaction matches the implied number set by Bob, the watchtower can know that the transaction is a transaction that needs to be cancelled. At this point, the watchtower decrypts the revocation transaction provided by Bob and proves that Alice issued an expired transaction, reorganizes and broadcasts the transaction that Bob signed in advance, and confiscates Bob's balance in the channel. In other words, the watchtower can decrypt the undo transaction and learn its content only when fraud occurs, so it will not seriously affect user privacy.

Submarine Swaps

Latent exchange technology was created by Alex Bosworth, and is used as a technology that seamlessly connects on-chain and off-chain Bitcoin circulation. The operation mechanism of latent exchange is similar to HTLC, but it involves both on-chain and off-chain transactions (Figure 6).

Figure 6: Operation mechanism of latent exchange

Suppose Alice wants to pay Bitcoin on the chain to user Bob on the Lightning Network, but Alice does not have a Lightning Network channel.

Step 1: Bob will set a set of implied numbers R (that is, the preimage) and inform Alice of its hash value H.

Step 2: Alice sends the bitcoin with Bob's Lightning Network address to the potential exchange service provider through the on-chain HTLC, and requires the potential exchange service provider to reveal the hint number within a certain period of time to obtain the bitcoin on the chain. Similarly, the potential exchange service provider transfers the same amount of Bitcoin to Bob's Lightning Network address through the Lightning Network payment channel through the off-chain HTLC, and requires Bob to reveal the hint number within a certain period of time in order to obtain this off-chain Bitcoin.

Step 3: Bob reveals the implicit number to obtain the bitcoin off-chain, and the potential exchange service provider then uses the implicit number to obtain the bitcoin on the chain, and the entire hidden exchange is completed.

It can be seen that the biggest function of the latent exchange is to improve the interoperability between on-chain and off-chain, and because of the characteristics of HTLC, it can minimize the cost of credit. Latent exchange can be used to extend the life of the payment channel. Lightning network transactions require sufficient channel balance between the two parties in the transaction. When channel liquidity is exhausted, users tend to shut down the original channel and wait until the next time they need to open a new channel, but this limits the expansion of Lightning Network channels and commercial scale. When using latent exchange, users can obtain off-chain bitcoin through the latent exchange service provider without going through on-chain transactions, thereby maintaining the channel balance.

Atomic Multi-Path Payments

At present, the single payment route for Lightning Network transactions can only be unidirectional. Assuming Alice wants to pay 0.01 BTC to user Bob, not only must he have 0.01 BTC on a single channel, but all middlemen on the route must also have 0.01 BTC in the channel in order to trade. In other words, the larger the payment amount, the harder it is to find a suitable payment path.

The idea of ​​multi-path payment has been extensively discussed in 2018. The original idea was as follows: split large payments into small payments, and these small payments are then transferred from the payer to the payee through different node operators. The challenge for this solution is that the possibility of using Lightning Network to pay may fail. Dividing a transaction into multiple transactions may result in some transactions being successful and some transactions failing. In other words, the larger the payment, the more likely it is that there will be a partial payment problem, which will restrict the user's willingness to use the Lightning Network for large payments.

The solution is atomic multi-path payment, which is simply the multi-path payment + partial payment prevention mechanism. The meaning of "atomic" is: only when all small payments are successful, the counterparty will receive the full payment; if some small payments fail, the entire transaction will fail and the funds will be returned to the payer.

Figure 7: Atomic Multipath Payment Process

Atomic multi-path payment has the following advantages: First, it improves privacy. No matter how many channels are split into to pay, only the two parties to the transaction know the process. Second, improve the payment experience. Users can transfer large amounts of money at one time, without having to consider the maximum amount of channels.

Neutrino protocol

The neutrino protocol consists of a "filter layer" chain. Each filter layer is connected to a Bitcoin block, which represents its connected block in a compressed manner. The filter layer is about 250 times smaller than the original block size. The purpose of the neutrino protocol is to reduce the burden on the client's hardware facilities, and only capture the data related to the two parties of the transaction, to avoid the need for the hardware facilities to be synchronized with the Bitcoin main chain at all times. The neutrino protocol runs as follows:

Figure 8: Operation process of neutrino protocol

Whenever a new block is produced, the full node calculates the neutrino filter layer corresponding to the block and sends it to all neutrino clients on the Lightning Network. Therefore, approximately every 10 minutes, the client receives a neutrino filter layer, and the client compares all wallets to see if any transactions are related to the wallet user. Once the block is found to contain transactions related to wallet users, the client will download the "stripping block". The "stripping block" only contains transaction data and does not include signature and "witness" data, which can reduce the client's hardware burden by more than half. With the new data, the client is able to update the wallet balance.

Generally speaking, Lightning Network Wallet operators hope to provide products with high user experience and low barriers to use, but improving ease of use often reduces security, such as theft of personal data or loss of user assets. In addition, the large amount of data carrying makes it difficult to implement Lightning Network on the mobile end. The neutrino protocol frees users from having to run full nodes and can operate on mobile devices, which greatly helps users expand.

Overview of Lightning Network landing and problems to be solved

Lightning Network landing profile

Key indicators such as the number of Lightning Network nodes, channels, and BTC carrying capacity provided by Bitcoin Visuals show that Lightning Network has stalled since reaching its peak in April 2019.

At present, the number of Lightning Network nodes is 5,104. The number of nodes has experienced continuous growth in the first half of 2019, and the number of nodes has increased by 77% since January 2019. However, from the beginning of May 2019 to February 10, 2020, the number of Lightning Network nodes has only increased by 15%, and the growth rate has fallen sharply.

The number of Lightning Network channels has begun to decline from early April 2019. As of February 10, 2020, the number of channels has dropped by 20%. The current number of channels is 32,030.

The BTC carrying capacity increased from 525.80 pieces in January 2019 to 1,059.50 pieces in early April 2019, an increase of 101.5%; but since the beginning of April 2019, as of February 10, 2020, the BTC carrying capacity has fallen to 865.58 pieces.

Figure 9: Changes in the number of Lightning Network nodes (left), channels (right), and BTC carrying capacity (left)

There are three main reasons for the number of Lightning Network nodes, channels, and BTC carrying capacity to decline from April 2019:

• Bitcoin price has risen rapidly since March, and investors' willingness to realise has increased

It can be seen from Figure 9 that the fastest growth of the number of Lightning Network nodes (November 2019 to March 2019) is precisely the interval where the price of Bitcoin hovered at the bottom of the valley. During this time, many investors' bitcoins were arbitrarily in the secondary market and could not be realized. The Lightning Network Channel became a bitcoin depository that investors can consider.

However, since March 2019, Bitcoin has risen, and the Lightning Network has not yet had enough application scenarios and merchants. Many Lightning Network users choose to realise Bitcoin in the secondary market to arbitrage rather than continue to store in the Lightning Network. It can also be seen from Figure 10 that since April 2019, the transaction volume of Bitcoin has increased significantly, which means that the circulation of Bitcoin in the secondary market has increased, and the proportion of deposits in the Lightning Network Channel has decreased.

Figure 9: Bitcoin price (left) and number of nodes (right)

Figure 9: Bitcoin transaction volume (left) and number of nodes (right)

• Lightning network node profit cannot cover costs and risks

The cost of operating a Lightning Network node = the cost of setting up the node + the operating cost + the cost of liquidity of the locked capital, and the risk is the possibility of the Lightning Network or node being hacked. At present, the Lightning Network locks in bitcoin worth more than 8 million US dollars, loses a lot of liquidity and faces the risk of hacking, but the monthly profit of node operators is only 1-20 US dollars. Obviously, the Lightning Network nodes currently lack a sustainable business model.

• Lightning Network is a natural monopoly market, and small nodes are gradually unable to survive

Due to the design of Lightning Network's switching channel fees, users open a channel for an additional switching channel fee, and the service of each node is highly homogeneous, the difference is mainly the number of other nodes connected. Therefore, users tend to find a node that is more connected to other nodes, so that not only is the transaction easier to succeed, the lower the channel fee to be paid. From an economic perspective, a centralized supernode is an ideal choice for users. In the situation that the number of users has not increased significantly, closing small or useless nodes and expanding the connection volume of large nodes is a way for node operators to save costs.

Problems to be solved by Lightning Network

• Node needs to stay online

In order to make transactions successful, Lightning Network nodes need to be online at all times, which is not convenient compared to traditional payment systems. Lightning Network users do not have the option of cold storage of funds, and users cannot safely store funds. Although the observatory can solve the problem of online fraud, it also makes the entire ecosystem more centralized. If an important node goes offline, it is easy to greatly reduce the liquidity of the entire network and even cause the user's funds to freeze for several days.

• Poorly designed routing economy

Lightning Network implements onion routing for high privacy. Under the onion routing, each node only knows the addresses of the two nodes before and after. It cannot restore the entire chain or determine the identity of the payee. The intermediate party only transmits information on the basis of grasping the required information. The problem in actual operation is that it is impossible to know which node is online and which node can connect to the destination user. Although finding the shortest path is not a problem, there are already many mature and reliable algorithms, but during the transaction, Lightning Network needs to calculate the cost of the entire path. Once a node in the middle fails to send, in addition to resending the transaction, the user who initiated the transaction must recalculate the rate from the originating node, resulting in wasted time and reduced user experience.

In order to improve the transaction success rate, each node needs to maintain a list of all nodes and channels. As the size of the network increases, this table becomes larger and larger, and more and more messages need to be synchronized and updated, which consumes a lot of bandwidth. Even so, there is no guarantee of success before sending, and the channel may be closed during sending. A possible solution is to build a reliable routing network, and a large-scale commercial node is responsible for serving as a routing node to build a low-cost and efficient routing network.

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