Key points:
Layer 2 solutions were created to address the scalability limitations inherent in blockchain technology.
The Lightning Network is a layer 2 scaling solution that offers fast transactions without block confirmation, enabling efficient micropayments.
It provides secure and scalable payments through multi-signature addresses and Hash Timelock contracts.
Introduction
Cryptocurrencies have some pretty unique properties. They cannot be easily hacked or disabled, and anyone can use them to transfer value around the world without third-party intervention.
To guarantee the preservation of these functions, it is necessary to resort to significant compromises. Since many nodes are responsible for the operation of the cryptocurrency network, bandwidth is limited. As a result, the number of transactions per second (TPS) that a blockchain network can handle is relatively small for a technology that is aimed at mass adoption.
To overcome the limitations of blockchain technology, a number of scalability solutions have been proposed to increase the number of transactions that the network can handle. In this article, we will delve into the Lightning Network, one such extension of the Bitcoin protocol.
What is Lightning Network?
The Lightning Network is a network that sits on top of the blockchain to facilitate fast P2P transactions. This is no exception for Bitcoin. Other cryptocurrencies have also integrated this solution.
You may be wondering what we mean by "on top of the blockchain". Lightning Network is what is called an off-chain or second-tier solution. It allows people to make transactions without having to record each transaction on the blockchain.
The Lightning Network is separate from the Bitcoin network - it has its own nodes and software, but it interacts with the main blockchain. To enter or leave the Lightning Network, special transactions must be created in the blockchain.
What you're actually doing with your first transaction is creating a kind of smart contract with another user. We'll get into the details shortly, but for now, imagine a smart contract that stores a private ledger for you and another user. You can write many transactions to this ledger. They are visible only to you and your counterparty, but neither of you can deceive anyone due to the specifics of the setting.
This mini-registry is called a channel. Let's say Alice and Bob invested 5 BTC each in a smart contract. Now they both have 5 BTC balance in their channel. Alice can write "pay 1 BTC to Bob" in the register. Bob now has 6 BTC and Alice has 4. Bob can then send 2 BTC back to Alice, updating the balance to 6 BTC on Alice's side and 4 BTC on Bob's side. They may continue to do so for some time.
At any moment, someone with it can publish the current state of the channel to the blockchain. At this point, the balances on each side of the channel will be distributed between the respective sides of the network.
As the name suggests, Lightning transactions are executed at lightning speed. Block confirmation is not required to wait for payment - payments can be made as fast as your internet connection allows.
Why a Lightning Network solution?
So far, the Lightning Network (or simply LN) seems to be the smartest approach to scaling the Bitcoin blockchain. It is not easy to coordinate changes in such a large ecosystem - there is a risk of hard forks and potentially catastrophic errors. When there's a lot of money at stake, it's incredibly dangerous to experiment.
When you experiment off the blockchain, you get a lot more flexibility. If something goes wrong, it won't affect the real Bitcoin network. Layer 2 solutions do not undermine any of the security keys that have supported the protocol for more than 15 years.
There is also no obligation to abandon the old way of doing things. On-chain transactions on the network continue to work for the end user as normal, but they now have the ability to make off-chain transactions.
Using the Lightning Network has several advantages. We'll cover some of the main ones below.
Scalability
Bitcoin blocks are created approximately every ten minutes and can contain a limited number of transactions. Block space is a scarce resource, so you must bid against other users to add your block in time. Miners care about getting paid, so they will add transactions with higher fees first.
If few users are trying to send funds at the same time, this is not a problem. You can set a low fee and most likely the transaction will be added to the next block. But when too many users broadcast transactions at the same time, the average fee can increase significantly. There were several cases when it exceeded $10. During the bull market of 2017, fees exceeded $50. In April 2021, the average fee for a Bitcoin transaction exceeded $60.
This may seem insignificant for transactions moving thousands of dollars in Bitcoin, but for small payments it is unacceptable. Who wants to pay a $10 fee for a $3 coffee?
In the Lightning Network, you still pay two commissions – one for opening a channel and one for closing it. But you and your counterparty can make thousands of transactions for free once the channel is open. When you're done, you just need to publish the final state to the blockchain.
Overall, if more users rely on off-chain solutions such as the Lightning Network, block space will be used more efficiently. Small but frequent transfers can be made in payment channels, while block space is used for larger transactions and channel opening/closing. This would make the system accessible to a much wider user base, allowing it to scale in the long term.
Micropayments
The minimum amount of Bitcoin you can send in a transaction is approximately 0.00000546 BTC. At the time of writing, that equates to about 38 cents. It's a small amount, but the Lightning Network allows you to push the limits to make a transaction with the smallest unit available - 0.00000001 BTC or one satoshi.
Lightning is much more attractive for micropayments. Regular transaction fees make it impractical to send tiny amounts to the main blockchain. However, within the channel you can send a share of Bitcoin for free.
Micropayments are suitable for many use cases. Some users speculate that they could be a viable replacement for subscription-based models, where users instead pay small amounts each time they use a service.
Privacy
A second advantage of the Lightning Network is that it can offer users a high level of privacy. Parties do not need to report their wider network channels. While you can look at the blockchain and say that this transaction opened a channel, you can't tell what's going on inside it. If members decide to make their channel private, only they will know what transactions are taking place in it.
If Alice has a channel with Bob and Bob has a channel with Carol, Alice and Carol can send payments to each other through Bob. If Dan is connected to Carol, Alice can send him payments. You can imagine how this extends to a sprawling network of interconnected payment channels. In this case, you can't be sure who Alice sent the funds to after closing the channel.
How does the Lightning Network work?
We explained how Lightning Network uses channels between nodes at the highest level. Let's consider the principle of operation of the system from the inside.
Addresses with multi-signature
A multi-signature (or multisig) address is an address that involves the use of multiple private keys to make a transfer. When creating it, you specify how many private keys can spend funds and how many of these keys are needed to sign the transaction. For example, a "1 of 5" scheme means that five keys can create a valid signature and only one is needed to form a transfer. Scheme 2 out of 3 would mean that out of three possible keys, any two are needed to transfer funds.
To initialize the Lightning channel, participants block funds in a 2-of-2 scheme. There are only two private keys to sign with, and both are required to move coins. Let's go back to our friends Alice and Bob. They will be making a lot of payments to each other in the coming months, so they decide to open a Lightning Network channel.
It starts with both of them contributing, say, 3 BTC each to a shared multi-signature address. It is worth repeating that Bob cannot transfer funds from an address without Alice's consent or vice versa.
This is equivalent to having a sheet of paper in which the balance of each party is regulated. Both have a starting balance of 3 BTC. If Alice wants to pay Bob 1 BTC, why not just note that Alice now owns 2 BTC and Bob 4 BTC? Balances could be tracked this way until they decide to withdraw.
It is possible, but what is wrong here? More importantly, isn't this simplicity an excuse for someone to refuse to cooperate? If Alice gets 6 BTC and Bob gets none, Bob has nothing to lose by refusing to transfer the funds (except his friendship with Alice).
Hash Timelock Contracts (HTLC)
The above system is simple and does not offer rich functionality compared to other modern configurations. Things get much more interesting when we introduce the mechanism that enforces the "contract" between Alice and Bob. This provides for the possibility of a refund from the channel if one of the parties does not want to play by the rules.
This mechanism is called Hash Timelock Contract (or HTLC). This term may sound complicated, but the concept is actually very simple and straightforward. It combines two other technologies (hash lock and time lock) to eliminate the possibility of conflicting behavior in payment channels.
A hash lock is a condition for a transaction where funds can only be spent if you know the secret. The sender hashes a piece of data and includes the hash in the transaction for the recipient. The only way the recipient can unlock them is to provide the original data (the secret) that matches the given hash. The only way to provide this data is to obtain it from the sender.
A time lock is a condition that does not allow you to spend funds until a certain time. The time period is specified as actual time or block height.
HTLCs are created by combining hash locks and time locks. In practice, HTLC can be used to create conditional payments - the recipient must provide the secret by a certain time, or the sender can return the money. The next part is probably best explained with an example, so let's go back to Alice and Bob.
Opening and closing channels
Consider an example: Alice and Bob have just created transactions that fund a multi-signature address. They are going to use this address in the near future, but so far these transactions have not been published on the blockchain yet! There is one more thing to do first.
Bob's three coins and Alice's three coins.
Remember that the only way to get these coins out of a multi-signature wallet is if Alice and Bob jointly sign the transaction. If Alice wants to send all six coins to an external address, she will need Bob's approval. First, it forms a transaction (specifies an amount of six Bitcoins to be sent to another address) and adds its own signature.
Alice can immediately try to broadcast the transaction, but it will be invalid because Bob has not signed it. Alice has to give him the unfinished business. As soon as he signs it, the transaction becomes valid.
However, in this case, there is still no process that obliges the participants to act honestly. As we mentioned earlier, if your counterparty refuses to cooperate, your funds are effectively trapped. Let's move on to the mechanism that prevents this. For this, there are several driving elements that will become a solution to such a problem.
To avoid such an unfavorable situation, each side must come up with a secret, let's call them: As and Bs. If Alice and Bob reveal them, they will lose the funds, so they keep them secret for now. The pair then generates hashes of the corresponding secrets: h(As) and h(Bs). So instead of sharing their secrets, they exchange hashes.
Alice and Bob exchange hashes of their secrets.
Alice and Bob also need to create a set of transaction commitments before they post their first transfers to the multisignature address. This involves certain security measures, in case someone decides to hold funds "hostage".
If you think of a channel like the mini-ledger we referred to earlier, then transactional commitments are the updates you make to the ledger. Every time you create a new pair of transaction commitments, you rebalance the funds between the two participants.
In the case of Alice, she will have two exits: the first address is her personal one, which she added, and the second one is tied to a new multi-signature address. She signs the latter and hands it to Bob.
Alice's transaction has two outputs, one with a deposit to her own address and one with a deposit to a new multi-signature address. However, the latter still requires Bob's signature to make the transaction valid.
Bob does the same: one address is his personal and the other is multi-signed. He signs it and hands it to Alice.
We have two pending transactions that are very similar.
Alice can usually add a signature to Bob's transaction to make it valid. But you may notice that these funds are being spent from the 2 out of 2 multi-subscription, which is not yet funded. It's like trying to spend a check with a zero balance. Therefore, these partially signed transactions can only be used after multisignature is triggered.
The new multi-signature addresses (for which the 3 BTC output is allocated) have some specific properties. Let's look at the pending transaction that Alice signed and gave to Bob. An exit based on multi-signature can be activated if the following conditions are met:
Both parties implement a joint signature.
Bob makes the transfer on his own after a certain period of time (due to the time lock).
Alice gets to spend the balance if she learns Bob's secret: B.
For the transaction, Bob asks Alice to implement the following:
Both parties implement a joint signature.
Alice makes the transfer on her own after a certain period of time.
Bob gets the opportunity to spend the balance if he learns Alice's secret: A.
Keep in mind that neither party knows the other's secret, so point#3is not yet possible. It should also be noted that if you sign the transaction, your counterparty can immediately spend the money, since there are no special conditions for their exit. You can wait until the time has passed to spend the funds yourself, or you can partner with another party to spend them in full.
Perfectly! You can now post transactions to the original address with a multi-signature "2-2" scheme. It is safe at this stage as you can get your funds if your counterparty leaves the channel.
After confirming the transaction, the channel starts operations for processing. This first pair of transactions shows us the current state of the mini-ledger. At this point, the payouts will be distributed in the order: 3 BTC to Bob and 3 BTC to Alice.
When Alice wants to make a new transfer to Bob, the couple will need to create two new transactions to replace the first set. The practice remains the same: agreements are only half signed. However, Alice and Bob will have to give up their old secrets and exchange new hashes for the next round of transactions.
For example, if Alice wants to pay Bob 1 BTC. Two new transactions credit 2 BTC to Alice and 4 BTC to Bob. Thus, the balance is updated.
Each of the parties can at any time sign and transfer the last transactions to the other party in order to "settlement", that is, to record the final information in the blockchain. Whoever does this will have to wait for the end of the time lock, while the other party can spend the funds immediately, the moment they are received. It is worth noting that if Bob signs and broadcasts the transaction to Alice, she has the option of exiting without any additional conditions.
Both parties can agree to close the channel together (cooperative channel closing). This is probably the easiest and fastest way to get your funds back into the network. However, even if one of the parties stops responding to requests or refuses to cooperate, the other can still get their funds back after the time-lock expires.
How does Lightning Network prevent fraud?
You may have already identified a possible attack vector. If Bob currently has a balance of 1 BTC, what would stop him from broadcasting an older transaction when he had more coins? It's already got a signature from Alice, and all it needs to do is add your signature and broadcast the transaction to the blockchain, right?
No one prevents him from doing this, except that he may lose his entire balance. Suppose he decides to do so and broadcasts his old transaction, which gives Alice one coin and five go to that multi-signature address we mentioned earlier.
Alice gets one coin instantly. And Bob must wait until the time-lock expires to spend the balance of the multi-signature address. Remember the condition above that would have allowed Alice to spend the same funds immediately? She needs a secret that she didn't have then. She can do this from the moment the second round of transactions is created, because Bob has given her this secret.
While Bob is waiting for the time-lock to expire, and is unable to do anything, Alice can move these funds. Such a sanction-based mechanism assumes that a participant is unlikely to attempt to commit fraud, for the simple reason that in such a case, the other party immediately gains access to their shared coins.
Payment routing
We touched on this topic earlier: channels can communicate with each other. Otherwise, the Lightning Network wouldn't be as useful for payments. After all, you're not going to block $500 in a channel from a coffee shop to get your daily dose of caffeine for the next few months?
You don't have to do this. If Alice opens a channel with Bob, and he has a channel with Carol, Bob gets the ability to send payments using the connection between them. This mechanism works in several "hops", which means that Alice can quickly transfer funds to anyone to whom such a path exists.
In this scenario, Alice can take several routes to reach Frank. In practice, this path will always be the shortest.
For their routing role, intermediaries may charge a small fee (optional). Since the Lightning Network is a relatively new concept, the commission market has not yet formed. Many expect to see a fee based on the liquidity provided.
In the underlying blockchain, your fee depends on where the transaction is in the block. The amount of the transaction does not matter: transfers from $1 to $10,000,000 will have the same fee. In comparison, the Lightning Network has no such thing as a place in a block.
Instead, there is the idea of local and remote balances. The local balance is the amount you can "push" to the other end of the channel, while the remote balance is the balance your counterparty can give you.
Let's consider another example. Let's take a closer look at one of the paths above: Alice <> Carol <> Frank.
User balance before and after transfer of 0.3 BTC from Alice to Frank.
Alice <> Carol and Carol <> Frank have a total capacity of 1 BTC. Alice's local balance is 0.7 BTC. If they now decided to perform the calculation and display the latest information on the blockchain, Alice would receive 0.7 BTC and Carol her remote balance (ie 0.3 BTC).
If Alice wants to send 0.3 BTC to Frank, she sends 0.3 BTC to Carol. Carol then withdraws 0.3 BTC from her local balance into the channel with Frank. As a result, Carol's balance remains the same: +0.3 BTC from Alice and -0.3 BTC for Frank, which are mutually exclusive.
Carol loses nothing by acting as a liaison between Alice and Frank, but she makes herself less flexible. As you can see, she can now spend 0.6 BTC in her channel with Alice and only 0.1 BTC in the channel with Frank.
You can imagine a situation where Alice is connected only to Carol and Frank to a much wider network. Carol used to be able to send a total of 0.4 BTC to other participants, via Frank, but now she can only offer 0.1 BTC because all her funds are at the other end of the channel.
In this scenario, Alice is effectively absorbing Carol's liquidity. Without any incentive, Carol may be unwilling to further weaken her own position. Instead, she could simply say, I'll send every 0.01 BTC with a fee of ten satoshis. Thus, the more local balances will use Carol's services on "stronger" routes, the more profitable her position will become.
We mentioned earlier that there are no actual requirements for the commission. Some users may not worry about a decrease in liquidity. Other users will simply open channels exclusively for the recipient.
Lightning Network Limitations
It would be great if the Lightning Network became the solution to all of Bitcoin's scalability problems. Unfortunately, the concept has its own shortcomings that can prevent this.
Ease of use
Bitcoin is not a very intuitive system for beginners: addresses, fees, etc. can be confusing during the first user experience. After setting up the Lightning client, users also need to start opening channels before they can make payments. This can take a long time and is likely to be difficult for a novice as there is a lot of terminology involved, including input/output bandwidth.
However, technology is constantly improving, lowering the barrier to entry and providing a more streamlined user experience.
Liquidity
One criticism of the Lightning Network is that your ability to transact may be limited. You cannot spend more than is blocked in the channel. If all funds are distributed on remote balances, most likely you will have to close the channel. Or you can wait for someone to pay you, but this is not an ideal solution.
Your paths may be limited by the total bandwidth of the channel. Look at our past example: Alice <> Carol <> Frank. If Alice and Carol's channel has 5 BTC and Carol and Frank only have 1 BTC, Alice will never be able to send more than 1 BTC through them. Even then, the entire balance must be on the Carol <> Frank side of the channel for this to work. This shortcoming can seriously limit the amount of funds passing through LN channels, directly affecting the usability.
Centralized hubs
Because of the problem mentioned in the previous section, there is some concern that the network will facilitate the development of large "hubs". This implies the emergence of closely related organizations with great liquidity. Any significant payments will need to be routed through some of these organizations.
It is clear that this is not the best situation. This will weaken the system, since the exit of such providers into autonomous mode will lead to a significant disruption of relations between nodes. There is also an increased risk of censorship due to the presence of multiple points through which transactions pass.
The current stage of development of the Lightning Network
As of March 2024, the Lightning Network is showing good development. The network has 13,000+ nodes online, 52,000+ active channels, and just over 4,570 BTC in circulation.
Global distribution of Lightning Network nodes.
There are several different implementations of nodes. The most popular of them are: c-lightning from Blockstream, Lightning Network Daemon from Lightning Labs and Eclair from ACINQ. For users who are not inclined to use technically heavy approaches, many companies offer Plug-and-Play nodes. In this case, the only thing you need to do is to turn on the device. After that, you will be ready to work with Lightning Network.
Results
Since the launch of the mainnet in 2018, the Lightning Network has seen significant growth. At this stage of development, there are some limitations in usability, for example, you will need some technical competence to operate the Lightning node. But as technology develops, we will see a decrease in the barrier to entry.
Related articles
Blockchain scalability – sidechains and payment channels
What are nods?
What are smart contracts and how do they work?
Disclaimer: This content is provided to you "as is" for general information and educational purposes only, without any representations or warranties. It should not be considered as financial, legal or other professional advice and is not intended to recommend the purchase of a particular product or service. You should seek advice from appropriate professional advisors. If the article is written by a third-party author, please note that the opinions expressed are those of the third-party author and do not necessarily reflect the opinions of Binance Academy. For more information, please see our disclaimer. Digital asset prices can be volatile. The value of your investment may go down as well as up, and you may not get back the amount you invested. You are solely responsible for your investment decisions and Binance Academy is not responsible for any losses you may incur. For more information, please see our Terms of Use and Risk Warning.