A Dive into Lightning Network (Part One)
Note：The Link of “A Dive into Lightning Network (Part Two)”
Note：The Link of “A Dive into Lightning Network (Part Three)”
Abstract：
As Bitcoin has been gaining an increasing level of popularity, its scalability issue has always been considered one of the biggest “dark cloud” from the very beginning. To address this top concern, academic researchers and industrial practitioners proposed a variety of solutions, including block expansion, sharding, side chain etc. Lighting Network, representative of the payment channel based solutions to the blockchain scalability limitation, has been widely acknowledged as the most promising technique in this context, or the perfect “lightning” to cut through the “dark cloud” on top of Bitcoin.
Since 2015 when the white paper of Lightning Network was released, Lightning Labs, ACINQ and Blockstream as the top three leading players have implemented the protocol of Lightning Network based on mainstream programming languages and developed important technical frameworks as well. Developers from popular open-source communities also actively joined the ecosystem of Lightning Network to create different types of useful applications, such as digital wallet, game, online shopping, instant messaging etc. Nowadays, Lightning Network has become a platform with more than 13,000 nodes and 37,000 payment channels operating on around 1,000 bitcoins.
From the technical perspective, Lightning Network is a layer-2 off-chain scalability optimization of Bitcoin. More specifically, it was derived from the micro-payment channel technique with two key extensions, i.e., Revocable Sequence Maturity Contract (RSMC) and Hashed Time Lock Contract (HTLC) respectively. Micro-payment channel allows users to perform off-chain one-way payments thus enables more efficient payments compared to on-chain transactions. However, the main limitation of micro-payment channel is that only one-way payments are supported and a specific payment should be completed within a specified time window. Based on micro-payment channel, RSMC enables bi-directional payments without time limits and delivers a real-time high-performance solution for a pair of users with business relationships. Furthermore, HTLC creates a trusted multi-party payment framework to securely transfer funds through a routing path. The combination of RSMC and HTLC is the core of Lightning Network.
Like many other technical inventions, the design of Lightning Network is a double-edged sword. On one hand, Lightning Network creates a technical solution which is able to increase the scalability of Bitcoin to another level with low transaction fee and can flexibly interface to cross-chain transactions. Such potential is important to the ecosystem in terms of attracting more developers and motivating new models of application as well. On the other hand, the nature of Lightning Network will inevitably raise concerns on centralization, stability, privacy and usability issues, all of which are very challenging tasks.
While new problems are introduced by new technologies, new technologies are always created to address new problems. Lightning Network is also facing a similar situation and a similar opportunity at the same time. In order to mitigate limitations of Lightning Network itself, an increasing number of research teams have been working on new practical solutions. For example, watch tower was proposed to protect digital assets of offline users. Submarine swaps is designed to realize flexible exchanges between off-chain and on-chain funds. Atomic multi-path payment was highlighted to break a specific payment limit of a single payment channel.
In the future, Lightning Network is highly likely to become one of the fundamental techniques of the Bitcoin ecosystem and attract more research interests for further optimizations. More importantly, we could imagine a world where Lightning Network becomes the general payment tool for individual financial services and retailing business as well. To make this imagination come true, technical and operational people are needed to make sure that Lighting Network is stable, secure, privacy-preserving and open to the community.
Authors
【Huobi Research】Yuming Yuan，Wenqi Zhao
Contact information
1. The Creation of Lightning Network
The Bitcoin white paper was published in 2008, bringing cryptocurrency and blockchain technology to public attention. Since its release, there have always been technical concerns with the Bitcoin blockchain, as follows. 1. Transaction delay. While nowadays electronic payment solutions are able to confirm a single transaction at millisecond level, each transaction on Bitcoin needs to wait at least for 6 blocks to be confirmed, which amounts to about 1 hour on average. 2. Throughput problem. Bitcoin runs a Proof of Work (PoW) based consensus algorithm which generates a new block every 10 minutes. The peak transaction processing throughput is only 7 transactions per second while Tmall consumes 544,000 transactions per second on Nov.11th, 2019. 3. Storage problem. Current Bitcoin requires a storage space more than 270GB with 600,000 blocks on the blockchain, which is much more than the storage capacity of modern mobile phones or personal computers. Even worse, the storage space of Bitcoin will continue to rapidly increase in the future. In addition to Bitcoin, other popular blockchain platforms are likely to face similar challenges. These technical bottlenecks severely restrict the potential of cryptocurrency and blockchain to not only commercialize but reform traditional industries as well.
As a result, the academia and industry have proposed and implemented various solutions to aforementioned limitations, both on-chain and off-chain. 1. On-chain scaling methods include block expansion (e.g. Bitcoin Cash), optimization of PoW to reduce mining time (e.g. Litecoin), sharding, non-PoW consensus (e.g. PoS), etc; 2. Off-chain scaling methods include SegWit, Pegged Sidechain, Parallel Blockchain, Plasma, Payment Channel, etc. Table 1 shows the comparison of state-of-art techniques designed to improve the scalability of blockchain.
As a representative technique of payment channel, lightning network is regarded as the most promising technical solution to the scalability problem of Bitcoin. It has been attracting an increasing level of attention since 2015. Laszlo Hanyecz, who had used 10,000 bitcoins to buy two pizzas, used lightning network again in 2018 to pay 649,000 Satoshi for two pizzas. Moreover, a campaign called “Lightning Torch” launched in January 2019 is even more momentous. The transmission route of “Torch” covers dozens of countries around the world, and many influential people in the scientific and technological field have participated as torchbearers. Within only 5 years, multiple teams have implemented lightning network based on various languages, with lots of LApps running on it. So far, the Lightning Network has more than 13,000 nodes and more than 37,000 payment channels, which can accommodate 1,000 Bitcoins.
Why is lightning network able to bring a qualitative leap to Bitcoin’s scalability? Why didn’t it solve the scalability problem of the Bitcoin network thoroughly? This article will present an in-depth explanation of the lightning network, covering its technical principle, key contributions and limitations, extension techniques in the literature and its current ecosystem.
2. The Technical Principle of Lightning Network
“If a tree falls in the forest and no one is around to hear it, does it make a sound?” quoted from Dr. George Berkeley, a philosopher in the 18th century. The idea of “Lightning Network” proposed by Joseph Poonwas and Thaddeus Dryja in 2015 also originated from it. Similarly, in the bitcoin blockchain newtork, it is not necessary for all nodes to know every single transaction within a business activity if it’s nothing to do with them.
For the bitcoin network, there is no need to synchronize every single transaction to every node if there exists many transactions between two parties. As long as the final fund allocation is broadcasted and agreed on the whole network, it can not only guarantee the eventual integrity of digital assets but also improve the business efficiency to a large degree. Moreover, the storage space of Bitcoin will be significantly saved. In this sense, lightning Network is a protocol that enables high-volume, low latency digital micropayments without trusted intermediaries, breaking the bottleneck that has plagued Bitcoin for a long time.
In this section, we will discuss the technical principle of the seemingly “perfect” solution, “Lightning Network”. LN evolves from the micropayment channel with an important extension from its one-way payment channel to a two-way one; Specifically, RSMC (Revocable Sequence Maturity Contract) solves the problem of invalidation of historical contracts in the two-way channel; HTLC (Hashed Time Lock Contract) solves the problem of cross-node relay transactions. As a result, a decentralized and reliable payment channel network built on top of the bitcoin blockchain is formed.
2.1 Micropayment Channel
The proposal of the micropayment channel provides a solution for both sides in a transaction to establish a channel to perform small payments. We highlight its four key characteristics as follows: high performance and low transaction fee, high security, one-way micropayment channel, and time limit.
2.1.1 High performance and low transaction fee
1) Only two on-chain transactions are required on Bitcoin.The first transaction is made to establish a micropayment channel. After the transaction is broadcasted on chain, the payment channel is opened and ready for payment. The second transaction updates the final fund allocation of the channel on the blockchain network.
2) Transactions in a channel are peer-to-peer. A payment in a channel only needs the signature of both parties to be confirmed without the heavyweight process of on-chain synchronization and validation. As a result, transactions are near-instant on Lightning Network. Besides, the peer-to-peer transaction fee is almost negligible.
2.1.2 High security
1) Both parties use a double-signature account to build a payment channel. The transaction in the payment channel needs to be signed by both parties or it will not be synchronized to the main net.
2) The payer is able to withdraw the balance even if the receiver disappears. As shown inFigure1, Alice will ask Bob to sign a refund contract before signing a fund contract to deposit 10 BTC in a double-signature account. In the refund contract, a due time is specified to refund in the channel. In this case, Alice can publish this refund contract after April 30th and refund her 10 BTC back to her account. In this way, there is no chance for Bob to prevent Alice from getting her money back by refusing to publish transaction contract.
Figure1 Establishment of the micropayment channel
Note：In this figure, the bracketed part means unsigned and the unbracketed part means signed.
Resource：Dryja’s lecture in MIT，Huobi research
3) The payer cannot deny the payment therefore the rights of the receiver are guaranteed. As shown in Figure 2, Alice will sign a new contract to update the allocation of the current fund in the channel with Bob each time a transaction occurs. In this example, Alice pays Bob 1 BTC in tx1, and 3 BTC in tx2. However, it is impossible for Alice to deny the previous two payments and retrieve all 10 BTC in tx3. The reason is that tx3 has not been signed by Bob, so it is invalid to publish. On Bob’s side, he can get his 4 BTC back by ignoring tx3, signing tx2 and publishing it on the Bitcoin network. Particularly, we should mention that the micropayment channel has no penalty mechanism for cheaters (Alice in this case). That said, the remaining 6BTC will be retuned to Alice.
Figure 2 Transactions in micropayment channel
Note：In this figure, the bracketed part means unsigned and the unbracketed part means signed.
Resource：Dryja’s lecture in MIT，Huobi research
2.1.3 One-way flow of funds in channel
The micropayment channel only works when Alice pays Bob. While it does not restrict the two-way flow of funds, the transaction from Bob to Alice is an untrusted transaction. Even if Bob signs a payment contract and delivers it to Alice, Bob can still deny the payment by signing and publishing an outdated contract .
2.1.4 Time limit of channel
The micropayment channel protects the payer’s rights through time lock (as explained in section 2.1.2). A channel will be closed when time lock is due no matter how much fund remains in the channel. Otherwise, in the above example, all 10 BTC in the channel will be returned to Alice which leads to a loss of Bob. Hence, Bob would certainly sign a contract and close the channel before the due time.
2.2 RSMC
Based on the micropayment channel, Lightning Network designed RSMC to provide a two-way payment channel without due time. Meanwhile, more complicated mechanism for signing and non-repudiation followed.
RSMC involves 5 kinds of transactions:
1) Fund: Users deposit their funds into a double-signature wallet before initiating the payment channel. After the “fund” transaction is broadcasted on the Bitcoin network, the payment channel will be formally established. However, payers need to sign a “commit” contract to make sure that they can withdraw the money in double-signature wallet even if the counterparty disappears.
2) Commit: Users exchange the funds through “commit” transaction after a payment channel has been established. Specifically, the commit transaction requires two copies for each side and each copy has been signed by counterparty. If they want to terminate the payment channel, they could sign and publish the contract to the Bitcoin network. Then the channel will be closed and fund settled.
3) Delivery: Specifically, “delivery” is a transaction that executes the allocation of fund. Normally, the allocation is irrevocable once been finished.
4) Revocable delivery: Different from “delivery”, the “revocable delivery” transaction could be withdrawn in some situation. In RSMC, it mainly resulted from “breach remedy”.
5) Breach remedy: It helps to construct non-repudiation mechanism in RSMC. With breach remedy, users can retrieve all funds when the counterparty attempts to deny latest transactions by publishing historical transactions.
In this section, we will discuss how these 5 transactions cooperate with each other to set an efficient and reliable payment channel in transactions between Alice and Bob in detail.
2.2.1 Establishment of a payment channel
1) “Fund” transaction and the problem of trust
Figure 3 shows both the process of establishing a payment channel, and the flow of funds in channel. In the beginning, Alice and Bob contribute 2 BTC and 8 BTC respectively to deposit the funds in their double-signature wallet. Given that the funds could only be used when each side signed and approved, it was reasonable for Bob who has contributed more to worry that if Alice disappears, he would not be able to withdraw his money. Even worse, Alice might even blackmail by threating of not signing. Therefore, before broadcasting the “fund” transaction, both sides need to sign a “commit” transaction to get a guarantee which can ensure the to get their account balance back whenever the counterparty disappears.
2) Commitment and establishment of channel
In State 1, Alice and Bob signed a commit transaction respectively and then deliver it to another. Take the C1a held by Alice as an example. The input is the signatures of both sides. And now Bob has signed while Alice has not.
The output is the script of the fund allocation that only executed when Alice signs and broadcasts the transaction. The idea is similar to a competition contract signed by employees. Only when the employee violates the contract, the company is likely to enforce the compensation clause.
Figure 3 The establishment of a payment channel and the transaction process
Resource：Dryja’s lecture in MIT，Huobi research
Output script consists of two parts. 1. Allocate 8 BTC to Bob. 2. Allocate 2 BTC to Alice after 100 blocks with the key of Alice; or return 2 BTC to Bob immediately with the key of AliceR1 (this key will be introduced later) and the key of Bob. Therefore, even if Bob disappears, Alice can withdraw her money by broadcasting C1a and waiting for 100 blocks.
To conclude, the fund transaction will be broadcasted on Bitcoin network after C1a and C1b is executed. Both sides don’t need to trust each other to ensure the safety of their asset so that the payment channel is established.
3) Transactions within payment channel
It is not necessary to synchronize every transaction after the payment channel is established. Users deliver each transaction through “commit” transaction and the whole procedure can be completed in nearly real time when both parties are online. It is a huge improvement compared to the 10-minutes’ wait on blockchain.
As shown in Figure 3, Alice and Bob initiate a new transaction in State 2. Bob paid Alice 4 BTC by swapping the signed “commit” transactions, C2a and C2b. Particularly, when exchanging contracts, Alice and Bob announced the withdraw keys AliceR1 and BobR1 to declare the previous C1a and C1b invalid. The fund allocation in State 2 depends on C2a and C2b.
Alice and Bob exchange funds in the payment channel according to this rule. Unlike the micropayment channel, RSMC has no time lock so that it can theoretically exist forever until one of the transaction parties close the channel.
2.2.2 Normal close of a payment channel
When Alice and Bob intend to retrieve their funds in the double-signature wallet, they can broadcast the latest “commit” transaction on blockchain to distribute the funds.
Take Alice as an example in Figure 4, if she can broadcast C2a, then the output script in C2a will be executed to trigger the “delivery” transaction in D2a. In this process, Bob will immediately retrieve 4 BTC while Alice will have to wait for 100 blocks. This is a “penalty” for the users who firstly quit from the transaction in RSMC.
After “delivery”, Alice and Bob close the payment channel and update their final fund status to Bitcoin network.
Figure 4 Normal close of a payment channel
Resource：Dryja’s lecture in MIT，Huobi research
2.2.3 Breach remedy in RSMC
Since the payment channel based on RSMC doesn’t invalid historical transactions physically, participants theoretically can deny the subsequent payment by broadcasting historical transactions. However, RSMC amazingly prevent this by a penalty mechanism.
Figure 5 Breach remedy in RSMC
Resource：Dryja’s lecture in MIT，Huobi research
As shown in Figure 5, if Bob attempts to deny the transaction and close the payment channel in State 2 by publishing C1b in State 1, D1b will be triggered. As a result, the balance 2 BTC in State 1 for Alice will be immediately returned to her. While the remaining 8 BTC will be allocated to Bob through “revocable delivery” RD1b after waiting for 100 blocks. However, the generation of 100 block is too long. When noticing the cheat, Alice can use the BobR1 withdraw key to broadcast a “Breach remedy” transaction BR1b. In this way, Alice withdraws all 8 BTC left and makes RD1b invalid. Generally, breach remedy eliminates the counterparty risk of transactions within the payment channel.
Particularly, “watch tower” has been gradually applied to lightning network. Even if users are offline, they entrust watch tower to monitor if their funds are safe. Once the fund is stolen, watch tower will broadcast “breach remedy” for users. It will greatly improve the usability lightning network, because users no longer need to check at intervals. Watch tower will be discussed more deeply in section 5.1.
2.3 HTLC
Based on micropayment channel, RSMC, introduces a long-term and efficient solution for transaction between each pair of users. However, it will greatly increase the number of connections if every pair of users establishe a new payment channel for themselves. Furthermore, it is not cost-effective because the establishment of each channel requires transactions on the Bitcoin network (which involves watiting time and transaction fee). HTLC (Hashed Time Lock Contract) is a contract that allows transactions to be routed across parties who are not directly connected. A transaction is enabled as long as there exists at least one routable path in the network between both sides of the transaction, which greatly improves the scalability of Bitcoin.
2.3.1 Problem of multi-party participation
Figure 6 explains a non-HTLC transaction situation with multiple parties involved. If Alice, who has not established a payment channel with Carol, wants to transfer 1 BTC to Carol, she needs to transfer her funds through other participants of the network (Bob in this case, who has established payment channels with both of them). Alice first transfers 1 BTC to Bob, then Bob transfers it to Carol. In the case that Bob is a dishonest intermediary, the procedure could fail. Even if Bob is honest, it is still undesired for Bitcoin to create a transaction relying on a third party.
Figure 6 Multi-party participation
Resource：Dryja’s lecture in MIT，Huobi research
2.3.2 The process of HTLC
Based on the design of hashed time lock, HTLC is able to guarantee that any routed payment will need no trusted third-parties for assurance and cannot be taken by intermediate nodes. Figure 7 shows the workflow of HTLC.
Initiation of a transaction. Before the transaction, Carol prepares a value R as a seed to generate the hash value H. Particularly, R cannot be known given H. After that she delivers H to Alice.
Establish an HTLC by the delivery of H. After Alice gets H, she sends H to Bob and initiates an HTLC. If Bob can reveal the value of R from a known hash H, before 15:00 (it’s just a supposed time), then Alice will settle the contract by paying Bob 1 BTC. Otherwise, Alice redeems 1BTC. After Bob gets H, he will do the same to Carol but set an earlier due time, e.g. 14:00 .
Clear HTLC by the reverse delivery of H. If Carol finds that the H held by herself matches the value sent from Bob, she can clear the HTLC and receive 1 BTC by giving R to Bob. In the same way, Bob is able to get 1 BTC from Alice with R to complete the entire transaction.
In this procedure, if the routing node Bob, wants to receive 1 BTC from Alice through R, he must transfer 1 BTC to Carol first to get R. Thus, Bob has no chance to steal the fund and the problem caused by untrusted intermediary is solved.
Figure 7 The process of HTLC
Resource：Dryja’s lecture in MIT，Huobi research
Particularly, we should mention that the lock time must be descending along the routing path. If the due time agreed by Alice and Bob is 15:00 while Bob and Carol agree on 16:00, it is theoretically possible for Carol to take away the 1 BTC at 15:30, and Alice take her 1 BTC back at 15:00. As a result, Bob gets nothing in this case. To avoid his loss, Bob should specify a due time with Carol no earlier than 15:00.
Specifically, RSMC and HTLC can be created in one “commit” transaction, as is shown in Figure 8.
Figure 8 RSMC and HTLC
Resource: Lightning Network whitepaper, Dryja’s lecture in MIT
2.3.3 Routing and Fee
The routing and transaction fee mechanism of HTLC explains why Alice knows that Bob is connected to Carol and that Bob is willing to help Alice transfer funds to Carol.
Routing
HTLC uses two routing mechanisms, i.e., source routing and onion routing. All nodes on the network publish their own routing information and fund restrictions to form a payment channel table. When creating a payment on HTLC from the sender to a receiver, a feasible route is calculated by the payment sender (source routing) through the table. Onion routing means that each node only sees the its direct predecessor and successor. The combination of source routing and onion routing protects the identities of payment senders and receivers so as to enhance user privacy in lightning network.
Fee
In fact, Bob can set a routing fee (e.g.,0.01 BTC) to provide routing service. In this case, when Alice transfers 1 BTC to Carol, she needs to pay 1.01BTC to Bob. After transferring 1 BTC to Carol, Bob earns 0.01BTC. Surely, Alice will exclude Bob if the fee he sets is unreasonably high.
2.4 Lightning Network
In summary, RSMC solves the restriction of one-way fund flow in the channel; HTLC safely enables multi-party participation. The combination of RSMC and HTLC forms the core of lightning network, a payment channel on layer 2, greatly increase the scalability of Bitcoin
