Introduction
Cryptocurrencies have significant properties that make them less susceptible to hackers or shutdowns. Everyone can transfer value around the world through cryptocurrencies without the need for third parties to intervene.
Ensuring these characteristics remain intact comes at a great cost. The throughput is limited by the large number of nodes running the cryptocurrency. As a result, despite being a technology designed to be accessible to the general public, the number of transactions per second (TPS) that blockchain networks can handle is relatively low.
To overcome the inherent limitations of blockchain technology, various scalability solutions have emerged to increase the number of transactions that the network can process. In this article, we will take a deep dive into one of the extensions to the Bitcoin protocol, the Lightning Network.
What is the Lightning Network?
The Lightning Network runs on top of the blockchain and is designed to speed up peer-to-peer transactions. Its use is not limited to Bitcoin, but also includes cryptocurrencies such as Litecoin.
We may be confused, what does "on top of the blockchain" mean? The Lightning Network is a so-called off-chain or Layer 2 solution. Individuals can transact through this network without having to record each transaction in the blockchain.
The Lightning Network is independent of the Bitcoin network and has its own nodes and software, but it still needs to communicate with the main chain. To enter and exit the Lightning Network, special transactions need to be created in the blockchain.
Your first transaction is actually establishing a smart contract with other users. We will explain this in more detail later. For now, let’s think of a smart contract as a private ledger shared with other users. Users can write multiple transactions to this ledger. These records are only visible to the user and the counterparty, and due to the nature of the settings, neither party can falsify them.
This mini-ledger is called a "channel". For example, Alice and Bob each put 5 BTC into the smart contract. Their channels now each have a balance of 5 BTC. Then, Alice writes to the ledger "pay Bob 1 BTC". Now, Bob has 6 BTC and Alice has 4 BTC. Bob later returns 2 BTC to Alice. After the balance is updated, Alice has 6 BTC and Bob has 4 BTC. They can continue this operation for a while.
Either party can publish the current status of the channel to the blockchain at any time. At that time, the balances at both ends of the channel will be allocated to the respective on-chain addresses of both parties.
As the name suggests, Lightning transactions are lightning fast. No need to wait for block confirmations, payments can be made as quickly as the internet connection allows.
Why is Lightning Network necessary?
As of now, the Lightning Network (or “LN” for short) seems to be the most logical way to deal with scalability on the Bitcoin blockchain. Coordinating changes in such a large ecosystem is tricky, with risks such as hard forks and potentially catastrophic vulnerabilities. Protecting the vast value of the blockchain is a top priority, and experimentation is extremely dangerous.
If experiments are to be removed from the blockchain, there has to be more flexibility so that if something goes wrong, it won’t have a real impact on the Bitcoin network. Layer 2 solutions won’t undermine any of the security assumptions that have kept the protocol running for more than 10 years.
Moreover, there is no need to change the conventional operation mode. In this way, the end user's on-chain transactions can proceed as usual, and now there is an additional off-chain transaction option.
There are many benefits to using the Lightning Network. We’ll highlight a few below.
Scalability
Bitcoin blocks are created approximately every ten minutes and can hold a limited number of transactions. Block space is a scarce resource, so users must bid against each other to ensure that their transactions are included in the block space in a timely manner. Miners are most concerned about getting paid, so they will prioritize transactions with higher fees.
Assuming that there aren't multiple users trying to send funds at the same time, this isn't really a problem. You can set the fee low so that the transaction might get included in the next block. However, when everyone posts transactions at the same time, the average fee can rise dramatically, occasionally exceeding $5. At the height of the 2017 bull run, fees even topped $50.
Average Bitcoin transaction fees (in USD)
This may seem insignificant for bitcoin transactions worth thousands of dollars, but micropayments are difficult. Who wants to pay an extra $5 for a $3 cup of coffee?
There are still two fees to use the Lightning Network, namely the fee for opening and closing the channel. Once the channel is open, users and counterparties can conduct thousands of transactions for free. After the transaction is completed, only the final state needs to be published to the blockchain.
From a macro perspective, if more people choose off-chain solutions such as the Lightning Network, block space will be used more efficiently. Small, high-frequency transfers are made through payment channels, while block space is used for large transactions and channel opening/closing. This will increase the number of user groups accessing the system and achieve long-term scalability.
Micropayments
Bitcoin has a minimum transaction amount of about 0.00000546 BTC. As of this writing, that’s about four cents. That’s a small amount, but the Lightning Network pushes the transaction limit even lower, to the smallest unit currently, 0.00000001 BTC, or one satoshi.
The Lightning Network is more attractive for small payments. With regular transaction fees, sending small amounts on the main chain is impractical. However, within a channel, tiny fractions of a bitcoin can be sent for free.
Micropayments are applicable to a wide range of use cases. Some predict that micropayments will become an effective alternative to the subscription model for services, where users only pay a small amount each time they use a service.
privacy
The second benefit of the Lightning Network is that user information is more confidential. Parties do not need to spread their channel information on the network. The blockchain may show "this transaction opened a channel", but the transaction details will not be revealed. If a participant chooses to make the channel private, the transaction progress is only visible to the participant.
Assuming Alice and Bob share a channel, and Bob shares another channel with Carol, Alice and Carol can send payments to each other through Bob. If Dan connects to Carol, Alice can also send payments to him. Imagine expanding this model to a large network of interconnected payment channels. With this setup, once the channel is closed, it is impossible to determine who Alice sent the funds to.
How does the Lightning Network work?
We’ve explained how the Lightning Network relies on channels between nodes at a high level. Now let’s look at the underlying details.
Multi-signature address
A multi-signature (or "multisig" for short) is an address that can be spent by multiple private keys. Once a user creates a multi-signature, they can specify the number of private keys needed to spend funds and sign transactions. For example, a 1-out-of-5 scheme means that five keys generate a valid signature, and only one key is needed to sign a transaction. A 2-out-of-3 scheme means that if there are three keys, two of them are required to pay the fee.
To provision a Lightning Network channel, participants need to lock funds in a 2-out-of-2 scheme, which means that only two private keys are needed to sign transactions, and two private keys are also needed to transfer tokens. Let's go back to the example of Alice and Bob. In the next few months, they need to pay each other a large amount of fees, so they decide to open a Lightning Network channel.
First, they each deposit 3 BTC into a shared multi-signature address. It should be emphasized that Bob cannot transfer funds out of the address without Alice’s consent, and vice versa.
They just need to keep a record when they adjust the balances. Both parties have an initial balance of 3 BTC each. If Alice wants to pay Bob 1 BTC, why not just record that Alice has 2 BTC and Bob has 4 BTC? This record can track the balances before deciding to actually transfer the assets.
This works, but what’s the secret? More importantly, doesn’t it make cooperation a breeze? If Alice ends up with 6 BTC and Bob has nothing, then Bob has nothing to lose by refusing to release the funds (maybe all he loses is his friendship with Alice).
Hashed Time Lock Contract (HTLC)
The above system is boring and does not offer any advantages over the current trusted setup. It will be much more interesting if we introduce a mechanism to enforce the “contract” between Alice and Bob. If one party does not play by the rules, the other party can take remedial measures and withdraw the funds from the channel.
This mechanism is called a “Hash Time Lock Contract”, or “HTLC” for short. The term may sound intimidating, but it’s actually a very simple concept that’s easy to understand. It combines the two technologies of hash lock and time lock to provide remedial measures for various uncooperative operations in the payment channel.
A hash lock is a condition added to a transaction, specifically requiring proof that one knows a secret before using funds. The sender hashes a piece of data and sends the transaction with the hash value to the receiver. The receiver can only use funds if they provide the initial data (i.e. the secret) that matches the hash value. The only way to obtain the data is to be informed by the sender.
A time lock is a restriction that prevents the use of funds before a certain time, either at a specific time or a specific block height.
The Hash Time Lock Contract (HTLC) is created by combining a hash lock and a time lock. In practice, the Hash Time Lock Contract (HTLC) can be used to create conditional payments, where the receiver must provide a secret before a certain time, otherwise the sender will take back the funds. The following example will make it easier to understand. So, let's go back to Alice and Bob.
Opening and closing channels
In our previous example, imagine Alice and Bob have just created a transaction where they deposited funds into a shared multi-signature address. But these transactions have not yet been published to the blockchain! We need to do one thing first.
Three tokens come from Bob, and three tokens come from Alice.
Remember, the only way to get these tokens out of the multisig is for Alice and Bob to sign a transaction together. If Alice wants to send all six tokens to an external address, she needs Bob’s approval. She first initiates a transaction that specifies “send six bitcoins to this address” and then adds her signature.
If she tries to publish the transaction immediately without Bob's signature included in it, the transaction will be invalid. Alice must first give the incomplete transaction to Bob. After he signs it, the transaction will become valid.
So far, we have not established a mechanism to encourage everyone to trade honestly. As mentioned above, if the counterparty refuses to cooperate, the funds will be completely trapped. Let's understand the mechanism to prevent such situations. This mechanism involves multiple steps, please listen patiently as we introduce them one by one.
Each party provides a secret, which we call "As" and "Bs". If the two parties reveal the secret, the consequences will be disastrous. Therefore, they have to keep the secret for the time being. The two secrets generate their own secret hash values, namely h(As) and h(Bs). In this way, the two parties do not need to share secrets, but only need to share hash values with each other.
Alice and Bob share the secret hash value with each other.
Before Alice and Bob can issue their first transaction to the multi-signature address, they must create a series of commitment transactions, which are remedies to prevent the other party from seizing funds.
If you think of the channel as the mini-ledger we mentioned earlier, then commitment transactions are updates to the ledger. Every time a new set of commitment transactions is created, the funds of the two participants are rebalanced.
Alice's transaction has two outputs, one paying an address she owns and the other locked into a new multi-signature address. She signs it and gives it to Bob.
Alice's transaction has two outputs, one to her own address and the other to a new multi-signature that requires Bob's signature to take effect.
Same as Bob, one output pays himself and another pays the other multi-signature address. He signs and gives it to Alice.
Two incomplete transactions that are similar.
Normally, Alice could add her signature to her transaction to Bob and make it work. But notice that these spending funds are coming from a 2-out-of-2 multisig that has not yet been allocated. This is similar to trying to spend a check from an account that currently has a zero balance. Therefore, these partially signed transactions can only be used after the multisig is up and running.
The new multi-signature address, the destination of the 3 BTC output, has some properties. Let's look at the incomplete transaction signed by Alice to Bob. The multi-signature output can be used under the following conditions:
Both parties can collaborate to sign a transaction.
Because of the time lock, Bob can only spend it after a period of time.
If Alice knows Bob's secret Bs, she can use the funds.
For the transaction from Bob to Alice:
Both parties can collaborate to sign a transaction.
Alice can spend the money on her own after a period of time.
If Bob knows Alice's secret As, he can use the funds.
Remember, neither party knows the other's secret, so point 3 is not possible for now. Another thing to note is that if one party signs the transaction, the counterparty can immediately use the funds because there are no conditions set on their output. The signatory needs to wait until the time lock expires before they can spend the funds themselves, or work with the other party to spend them directly.
All is well! Now you can publish the transaction to the initial 2-out-of-2 multisignature address. This is safe because you can recover the funds if the counterparty abandons the channel.
Once the transaction is confirmed, the channel will be up and running. The first pair of transactions shows the current state of the mini-ledger. At this time, the ledger pays 3 BTC to Bob and also pays 3 BTC to Alice.
When Alice wants to make a new payment to Bob, they create two new transactions to replace the first set of transactions. It works the same way, with each party signing half of the transaction. However, Alice and Bob first give up their old secrets and exchange new hashes for the next round of transactions.
For example, Alice wants to pay Bob 1 BTC, two new transactions will deposit 2 BTC to Alice and 4 BTC to Bob. In this way, the balance will be updated.
Both parties can sign and publish the most recent transaction at any time and complete the "settlement" on the blockchain. However, the party that signs and publishes must wait for the time lock to expire, while the other party can spend the fee immediately. Remember, if Bob signs and publishes Alice's transaction, she will have an unconditional output.
Both parties can reach a consensus and close the channel at the same time, which is a cooperative closure. This is the most convenient way for funds to return to the chain. However, if one party does not respond or refuses to cooperate, the other party can recover the funds after the time lock expires.
Want to start your cryptocurrency journey? Buy Bitcoin on Binance now!
How does the Lightning Network prevent fraud?
We might notice an attack vector here. Assuming Bob has an existing balance of 1 BTC, what’s stopping him from publishing an old transaction with a higher balance? After all, he already has the half-signed transaction from Alice, so he only needs to add his own signature to publish it, right?
There is nothing stopping him from doing this. But if he does, he could lose his entire balance. Suppose he does publish the old transaction, which pays 1 coin to Alice and 5 coins to the multi-signature address we mentioned earlier.
Alice will receive the tokens immediately, but Bob must wait until the time lock expires before he can spend from the multi-signature address. Remember above, there is another condition that must be met before Alice can spend the same funds immediately? She needs a secret that she didn't know at the time. But now she knows this secret - Bob leaked the secret when the second round of transactions was just created.
While Bob can only wait for the time lock to expire, Alice can take all the funds away. This punitive mechanism ensures that participants will not try to cheat, otherwise the counterparty will get their tokens.
Channel Payment
We have talked about this issue before. Channels can be connected, otherwise the Lightning Network cannot effectively support payment functions. Imagine if we really deposit $500 to the same coffee shop just to have a cup every day for the next few months?
In fact, there is no need to do this. Alice and Bob have opened a channel, and Bob and Carol have also established a channel, so Bob can pay both of them through the channel. In this way, Alice can pay everyone in the path across multiple "hops".
In this case, Alice can reach Frank through multiple channels. In practice, she will definitely choose the most convenient channel.
Intermediaries play a role in the channel and charge a small fee, but it is not mandatory. The Lightning Network is still in its infancy and the fee market has not yet taken shape. Many people expect to be able to charge fees based on liquidity.
In the base chain, users pay fees based on the block space occupied, but have nothing to do with the value transferred. That is, paying $1 is the same as paying $10 million. In contrast, the Lightning Network has no block space.
However, there is the concept of local balances and remote balances. Local balances are the amount that a party can "push" to the other end of the channel, while remote balances are the amount that the counterparty can push back to the local party.
Let's take another example. Let's take a closer look at one of the paths above: Alice <> Carol <> Frank.
The balances of each user before and after Alice transfers 0.3 BTC to Frank.
Alice <> Carol and Carol <> Frank have a total capacity of 1 BTC each. Alice's local balance is 0.7 BTC. Everyone settles in the blockchain at this time, and Alice receives 0.7 BTC and Carol receives a remote balance of 0.3 BTC.
Assuming Alice wants to send 0.3 BTC to Frank, she pushes 0.3 BTC to Carol's side of the channel. Then Carol pushes 0.3 BTC from her local balance to Frank through the channel. In the end, Carol's balance remains unchanged: the +0.3 BTC from Alice and the -0.3 BTC sent to Frank cancel each other out.
Carol does not lose value by acting as Frank's intermediary, but her flexibility in disposing of funds becomes worse. It can be seen that she can currently spend 0.6 BTC in the channel with Alice, but can only dispose of 0.1 BTC in the channel with Frank.
Let’s imagine a situation where Alice is only connected to Carol, while Frank is connected to a wider network. Previously, Carol could send a total of 0.4 BTC to others through Frank, but now she only has 0.1 BTC on her end of the channel to push out.
In this case, Alice is effectively cannibalizing Carol’s liquidity. Without any incentive, Carol doesn’t want to put herself at a disadvantage. So she might offer “I’ll charge a 10 satoshi fee for every 0.01 BTC output from my channel.” This way, the higher the local balance Carol discards in the “stronger” path, the more she earns.
As mentioned before, there is no de facto fee requirement. Some people are not worried about liquidity loss, while others just want to open a channel directly with the receiver.
Limitations of the Lightning Network
If it turns out that the Lightning Network solves all of Bitcoin’s scalability issues, everyone will be happy. Unfortunately, the Lightning Network has shortcomings that hold it back.
Availability
Bitcoin is not the most intuitive system for beginners, addresses, fees, etc. can be confusing. But wallets abstract away all that complexity and provide users with an operation that is more similar to existing payment systems. We can have someone download a smartphone wallet and send them tokens. They will be happy to complete the operation.
The Lightning Network currently cannot do this, and its smartphone app selection is very limited. Generally speaking, Lightning Network nodes need access to Bitcoin nodes to fully use them.
After setting up the client, users still need to open the channel to make payments. This process is very time-consuming, especially when newcomers are exposed to concepts such as "inbound/outbound capacity", they are even more confused.
Therefore, the Lightning Network needs to continue to improve, lower the entry threshold, and allow users to have a smoother experience.
fluidity
One of the biggest criticisms of the Lightning Network is that users are limited in their ability to transact. Individuals cannot spend more than the amount locked in the channel. If someone wants to spend all the funds, transferring all the funds in the channel to the remote balance, they must close the channel. Alternatively, they can passively wait for others to pay through the channel, which is not ideal.
Individual paths are limited by the total channel capacity. Take the previous Alice <> Carol <> Frank example. If Alice and Carol’s channel has a capacity of 5 BTC, and Carol and Frank’s capacity is only 1 BTC, then Alice will never be able to send more than 1 BTC. Even so, all balances must be on Carol’s side of the Carol <> Frank channel to ensure the normal operation of the Lightning Network. This will severely limit the amount of funds that can be transmitted through the Lightning Network channel, which in turn affects the practicality of the network.
Centralized Hub
Based on the issues mentioned above, some worry that such a network will give rise to a large number of "hubs", that is, large entities with strong liquidity and close connections, through which all large payments pass.
Obviously, this development is not a good sign. Centralized hubs weaken the system because taking these entities offline can severely disrupt relationships between users. Additionally, with only a few points to conduct transactions, the risk of censorship increases.
Current Status of Lightning Network
As of March 2022, the Lightning Network is operating normally, with more than 35,000 online nodes, more than 85,000 active channels, and a capacity of over 3,570 BTC.
Global distribution of Lightning Network nodes. Source: explorer.acinq.co
Among the many different node implementations, Blockstream's c-lightning, Lightning Labs' Lightning Network Daemon, and ACINQ's Eclair are particularly popular. For less tech-savvy users, many companies have launched plug-and-play nodes. Users only need to plug in the device to start using the Lightning Network.
Summarize
The Lightning Network mainnet went live in 2018, and although many believe it is still in the testing phase, the network has already seen incredible momentum.
Currently, only users with a certain level of technical proficiency can operate Lightning Network nodes, so the network still needs to overcome some usability hurdles. As the network is vigorously developed, the entry threshold is gradually lowering.
As long as the problem can be solved smoothly, the Lightning Network will become an indispensable part of the Bitcoin ecosystem, greatly improving scalability and transaction speed.
