Key aspects
Layer 2 solutions were created to address the scalability limitations inherent to blockchain technology.
The Lightning Network is a Layer 2 scalability solution that offers fast transactions without the need for block confirmation, enabling efficient micropayments.
Ensures secure and scalable payments through multi-sig addresses and Hash Timelock Contracts.
Introduction
Cryptocurrencies have some pretty unique properties. They cannot be easily hacked or tapped, and can be used by anyone to transmit value to and from anywhere in the world without the involvement of a third party.
To ensure that these features are maintained, significant trade-offs must be made. Since many nodes are responsible for running a cryptocurrency network, processing power is limited. As a result, the number of transactions per second (TPS) that a blockchain network can process is relatively low for a technology that aims to be widely adopted.
To overcome the limitations inherent to blockchain technology, several scalability solutions have been proposed that seek to increase the number of transactions a network can handle. In this article, we will delve into the Lightning Network, one of the extensions of the Bitcoin protocol.
What is Lightning Network?
Lightning Network is a network that runs on a blockchain to facilitate fast Peer-to-Peer transactions. It is not exclusive to Bitcoin, since other cryptocurrencies have integrated it.
You might be wondering what we mean by "runs on a blockchain." The Lightning Network is what we call an off-chain or Layer 2 solution. It allows people to make transactions without having to record every transaction on the blockchain.
The Lightning Network is separate from the Bitcoin network: it has its own nodes and software, however it communicates with the main chain. To enter or leave the Lightning Network, you must create special transactions on the blockchain.
What you actually do with your first transaction is create a kind of smart contract with another user. We will delve into this later. For now, just think about the smart contract that has a private ledger for you and another user. In this ledger, you can write many transactions. They are only visible to you and your counterpart, but neither of you can cheat due to some peculiar features of the setup.
This miniledger is called a channel. Suppose Alice and Bob put 5 BTC each into the smart contract. On their channel, they would both now have a balance of 5 BTC. Alice could then write to the ledger “pay 1 BTC to Bob.” Now, Bob has 6 BTC on his side and Alice has 4. Bob could then send 2 BTC to Alice at a later date, which would update the balances to 6 BTC on Alice's side and 4 BTC on Bob's side. They can continue doing this for a while.
At any time, either of them will be able to publish the current state of the channel on the blockchain. At that point, the balances on each side of the channel will be assigned to their respective parts in the chain.
As the name suggests, Lightning transactions are fast as lightning. There's no waiting for block confirmations – payments can be made as fast as your internet connection allows.
Why is Lightning Network necessary?
So far, the Lightning Network (or simply, LN) seems to be the most sensible approach to scalability of the Bitcoin blockchain. Coordinating changes in such a vast ecosystem is complicated: there is a risk of hard forks and potentially catastrophic errors. With so much value at stake, experimentation is incredibly dangerous.
When you move that experimentation off the blockchain, you have a lot more flexibility. If something goes wrong, it will have no impact on the actual Bitcoin network. Layer 2 solutions do not undermine any of the security assumptions that have sustained the protocol for more than 15 years.
There is also no obligation to replace the old way of doing things. On-chain transactions will continue to function as usual for the end user, only now they will also have the option to perform off-chain transactions.
Using the Lightning Network has several advantages. Next, we will see some of the main ones.
Scalability
Bitcoin blocks are created approximately every ten minutes and can only contain a set number of transactions. Block space is a scarce resource, so you must bid against other users to get yours included in a timely manner. Miners care about payment first, so they will include transactions with higher fees first.
When there are not many users trying to send funds at the same time, this is not really a problem. You can set a low fee and the transaction will likely be included in the next block. But when too many users transmit transactions simultaneously, the average commission can increase significantly. There have been multiple occasions where it has exceeded $10. At the height of the 2017 bull market, it surpassed $50. In April 2021, the average Bitcoin transaction fee exceeded $60.
This may seem insignificant for transactions moving thousands of dollars in Bitcoin, but for smaller payments, it is not sustainable. Who wants to pay for a $3 coffee with a $10 commission?
With the Lightning Network, you still pay fees, one to open your channel and one to close it, but you and your counterparty can make thousands of transactions for free once the channel is open. When you finish trading with it, you only need to publish the final state on the blockchain.
On a general level, if more users rely on off-chain solutions like the Lightning Network, block space will be used more efficiently. Low-value, high-frequency transfers could be made in payment channels, while block space would be used for larger transactions, as well as opening or closing channels. This would make the system accessible to a much broader user base and allow for long-term scalability.
Micropagos
In one transaction, a minimum amount of Bitcoin can be sent: approximately 0.00000546 BTC. At the time of writing, this is equivalent to about 38 cents. It's a small amount, but the Lightning Network allows you to push the limits to transact with the smallest unit currently available: 0.00000001 BTC or one satoshi.
Lightning is much more attractive for micropayments. Regular transaction fees make it impractical to send small amounts on the main chain. However, within a channel, you can send a fraction of a fraction of Bitcoin for free.
Micropayments are ideal for many use cases. Some people speculate that they may be a viable substitute for subscription-based models, in which users pay very small amounts each time they use a service.
Privacy
A secondary benefit of the Lightning Network is that it can offer users a high degree of confidentiality. The parties do not need to make their channels known to the wider network. While you may be able to look at the blockchain and say that this transaction opened a channel, you won't necessarily be able to know what is happening within that channel. If participants choose to make their channel private, only they will know what transactions are taking place.
If Alice has a channel with Bob, and Bob has a channel with Carol, Alice and Carol will be able to send payments to each other through Bob. If Dan is connected to Carol, Alice will be able to send him a payment. And so, the reach expands into an extensive network of interconnected payment channels. In such a context, you will not be able to know for sure who Alice has sent funds to once the channel has been closed.
How does Lightning Network work?
We have explained how the Lightning Network is based on channels between high-level nodes. Now let's look at this in more depth.
Multi-signature addresses
A multisignature (or multisig) address is one from which multiple private keys can make expenditures. When you create an address, you specify how many private keys funds can be spent on and how many of those keys are required to sign a transaction. For example, a 1-of-5 scheme means that five keys can produce a valid signature and only one is needed. A 2 of 3 scheme would indicate that, of the three possible keys, two are required to spend the funds.
To start a Lightning channel, participants lock funds in a 2-of-2 scheme. There are only two private keys capable of signing, and both are required to move coins. To understand it, let's go with another example from our friends Alice and Bob. In the coming months they will make many payments between themselves, so they decide to open a Lightning Network channel.
The relationship begins with both of you depositing, for example, 3 BTC each into the multi-signature address you share. It is necessary to reiterate that Bob will not be able to withdraw funds from the management without Alice's approval, and vice versa.
Of course, they could simply write down each side's adjusted balances on a piece of paper. Both have a starting balance of 3 BTC. If Alice wanted to send Bob a transfer of 1 BTC, why not note on the sheet that Alice now owns 2 BTC and Bob now owns 4 BTC? Balances could be tracked in this way until they decided to withdraw the funds.
It can be done that way, but where would the fun be? And more importantly, wouldn't that cause one of them to simply decide not to cooperate? If Alice is left with 6 BTC and Bob is left with zero, Bob would lose nothing by refusing to release the funds (except, perhaps, his friendship with Alice).
Hash Timelock Contracts (HTLC)
The system we described above is boring and does not offer great advantages over current configurations involving trust. Everything becomes much more interesting when we introduce a mechanism that is responsible for enforcing the “contract” between Alice and Bob. If one party decides not to follow the rules, the other party will still have recourse to withdraw their funds from the channel.
That mechanism is a Hash Timelock Contract (or HTLC). The term may sound complicated, but it is actually a fairly simple concept to understand. It combines two other technologies, (hashlocks and timelocks), to remedy any uncooperative behavior in payment channels.
A hashlock is a condition applied to a transaction that allows you to spend funds only if you prove you know a secret. The sender obtains the hash of a piece of data and includes that hash in the transaction to the receiver. The only way the receiver can spend it is if you provide the original data (the secret) that matches the hash. And the only way you can provide that data is if the sender gives it to you.
A timelock is a condition that prevents you from spending funds before a certain time. It is specified as a real time or a given block height.
HTLCs are created by combining hashlocks and timelocks. In practice, HTLCs can be used to create conditional payments: the recipient must provide a secret before a certain time or the sender can recover the funds. This next part is probably best understood with an example, so let's turn to Alice and Bob again.
Open and close channels
Before we gave the example of Alice and Bob, who had just generated the transactions that finance the multisignature address that they both share. These transactions will not yet be published on the blockchain. First, we must do something else.
Three coins from Bob and three coins from Alice.
Remember, the only way those coins can leave the multisig is if both Alice and Bob co-sign a transaction. If Alice wanted to send the six coins to an external address, she would need Bob's approval. You must first create a transaction (six bitcoins to this address) and then add your own signature.
You could try to transmit it immediately, but it would be invalid because Bob hasn't included his signature yet. First, Alice must deliver the incomplete transaction to Bob. And once he adds his signature, the transaction will be valid.
We have not yet established a mechanism to make everyone respect the rules. As we have said before, if your counterparty refuses to cooperate, in practice, your funds would be trapped. So let's look at the mechanism that prevents this, which is made up of a few different gears, so pay attention.
Each party must propose a secret. Let's call those secrets As and Bs. They wouldn't be secrets if Alice and Bob revealed them, so they'll keep them hidden for now. The peer will generate the hashes of the respective secrets: h(As) and h(Bs). So instead of sharing their secrets, they share those hashes with each other.
Alice and Bob exchange the hashes of their secrets.
Alice and Bob must also create a commit transaction set before publishing their first transactions to the multisignature address. This will give them a solution in case one of the parties decides to withhold the funds.
If you imagine the channel like the miniledger we explained before, commitment transactions would be the updates you make to the ledger. Every time you create a new pair of commitment transactions, you are realigning the funds between the two participants.
Alice's transaction will have two outputs: one that pays an address she owns and one that is locked to a new multi-signature address. She signs it and gives it to Bob.
Alice's transaction with two outputs: one for her own address and one for a new multi-signature address. Alice still needs Bob's signature for it to be valid.
Bob does the same thing: one output paying to himself, the other paying to another multi-signature address. He signs it and gives it to Alice.
We have two incomplete transactions that are very similar.
Normally, Alice could add a signature to Bob's transaction to make it valid. But you'll notice that these funds are being spent from the 2 of 2 multisignature that we haven't funded yet. It's a little like trying to spend a check from an account that currently has a zero balance. Therefore, these partially signed transactions will only be usable once multi-signature is up and running.
The new multi-signature addresses (where the 3 BTC outputs go) have some peculiar properties. Let's take a look at the incomplete transaction that Alice signed and gave to Bob. Multi-signature output can be spent under the following conditions:
Both parties can sign cooperatively.
Bob can spend it only after a certain period of time (due to our timelock).
Alice can spend it if she knows Bob's secret Bs.
For the transaction that Bob gave to Alice:
Both parties can sign cooperatively.
Alice can spend it only after a certain period of time.
Bob can spend it if he knows Alice's Secret Ace.
Note that neither party knows the other's secret, so condition 3 is not yet a possibility. Another thing to keep in mind is that if you sign a transaction, your counterparty can spend immediately because there are no special conditions on their exit. You can wait for the timelock to expire to spend the funds on your own, or you can cooperate with the other party to spend them immediately.
Good. You can now post transactions to the original 2 of 2 multisignature address. Finally, it is safe to do so because you can recover your funds if your counterparty leaves the channel.
Once transactions are confirmed, the channel is up and running. That first pair of transactions shows us the current state of the miniledger. Currently, you will pay 3 BTC to Bob and 3 BTC to Alice.
If Alice wants to make a new payment to Bob, the peer creates two new transactions to replace the first set. The exercise is the same: they are only half signed. However, Alice and Bob first give up their old secrets and exchange new hashes for the next round of transactions.
If, for example, Alice wanted to pay 1 BTC to Bob, the two new transactions would credit 2 BTC to Alice and 4 BTC to Bob. In this way the balance is updated.
Either party can sign and transmit one of the most recent transactions at any time to “settle” it on the blockchain. But the party doing so must wait until the timelock has expired, while the other party can spend immediately. Remember, if Bob signs and transmits Alice's transaction, she now has an unconditional exit.
Both parties can agree to close the channel together (cooperative closure). This is probably the easiest and fastest way to return your funds to the chain. However, even if one party stops responding or refuses to cooperate, the other can still claim your funds by waiting for the timelock.
How does the Lightning Network prevent cheating?
You may have identified an attack vector here. If Bob currently has a balance of 1 BTC, what's stopping him from passing on an older transaction where he had more? You already have Alice's half-signed transaction, you just need to add her signature and transmit it, right?
Nothing stops you from doing that except the fact that you could lose your entire balance. Let's say you go through with it and transmit an old transaction that pays one coin to Alice and five to that multi-signature address we mentioned earlier.
Alice receives her coin immediately. On the other hand, Bob must wait until the timelock expires to spend from the multi-signature address. Remember the other condition we mentioned that would allow Alice to spend those same funds immediately? He needs a secret that he didn't have before. Now you have it: As soon as the second round of transactions was created, Bob revealed that secret.
While Bob waits, unable to do anything until the timelock is up, Alice can move those funds. This punishment-based mechanism makes it unlikely that participants will attempt to cheat because the other party will have access to their coins.
Payment routing
We talked about this before: channels can be connected. Otherwise, the Lightning Network wouldn't be as useful for payments. Would you really lock down $500 on a channel with a coffee shop just so you can get your daily caffeine fix for the next few months?
You don't have to do that. If Alice opens a channel with Bob and Bob already has one with Carol, Bob can route payments between the two. This can work across multiple "hops", meaning that Alice can effectively pay anyone for whom a path exists.
In this scenario, Alice can travel multiple routes to reach Frank. In practice, she will always take the easiest one.
For their role in routing, intermediaries may charge a small commission (although there is no obligation to do so). The Lightning Network is still relatively new, so a commission market has not yet materialized. What many expect to see are fees based on the liquidity provided.
On the base chain, your fee is based solely on the space your transaction takes up in a block (the value being transmitted does not matter). Payments of $1 and $10,000,000 cost the same. In contrast, within the Lightning Network there is no block space.
Instead, there is the idea of local and remote balance sheets. The local balance is the amount you can "push" to the other end of the channel, while the remote balance is the amount your counterpart can push towards you.
Let's look at another example. Let's take a closer look at one of the above paths: Alice <> Carol <> Frank.
User balances before and after a 0.3 BTC transfer from Alice to Frank.
Both Alice <> Carol and Carol <> Frank have a total capacity of 1 BTC. Alice's local balance is 0.7 BTC. If they settled on the blockchain now, Alice would receive 0.7 BTC, and Carol would receive the remote balance (i.e. 0.3 BTC).
If Alice wants to send 0.3 BTC to Frank, she pushes 0.3 BTC to Carol's channel side. Carol then pushes 0.3 BTC of her local balance into the channel with Frank. As a result, Carol's balance remains the same: Alice's +0.3 BTC and Frank's -0.3 BTC cancel each other out.
Carol isn't losing value by acting as a connection between Alice and Frank, but she is becoming less flexible. You can now spend 0.6 BTC on your channel with Alice, but only 0.1 BTC on the channel with Frank.
You can imagine a situation where Alice is only connected to Carol, while Frank is connected to a much wider network. Carol previously could send a total of 0.4 BTC to others through Frank, but now she can only push 0.1 BTC because that's all she has on her end of the channel.
In this scenario, Alice is effectively consuming Carol's liquidity. Without any incentive, Carol may not want to weaken her own position. So instead, you could say, I will route every 0.01 BTC to a fee of ten satoshis. This way, the more local balance Carol sacrifices on "stronger" paths, the more profit she will make.
As we mentioned before, there is no de facto requirement to charge a commission. Some might not be worried about reduced liquidity. Others may simply open channels directly to the receiver.
Lightning Network Limitations
It would be great if the Lightning Network proved to be the solution to all of Bitcoin's scalability problems. Unfortunately, it has its own shortcomings that can interfere.
Usability
Bitcoin is not the most intuitive system for beginners: the addresses, fees, etc., can be confusing to get familiar with. After setting up a Lightning client, users must also start opening channels before they can make payments. This can be a time-consuming process, and could be overwhelming for someone new to concepts like input and output capabilities.
That said, improvements are constantly being made to lower barriers to entry and provide users with a more streamlined experience.
Liquidity
One of the biggest criticisms of the Lightning Network is that your ability to make transactions could be limited. You cannot spend more than what you have blocked on a channel. If you spend all your funds so that the remote balance has all the channel's funds, you will have to close the channel. Alternatively, you can wait until someone pays you through it, but that's not ideal.
Your routes may also be limited by the total channel capacity. Let's take the example of Alice <> Carol <> Frank above. If Alice and Carol have 5 BTC capacity on their channel, but Carol and Frank only have 1 BTC capacity, Alice can never send more than 1 BTC. Even then, the entire balance would have to be on Carol's side of the Carol <> Frank channel for that to work. This can severely limit the amount of funds that can be passed along LN channels and therefore has a knock-on effect on usability.
Centralized hubs
Due to the problem mentioned in the previous section, there is some concern that the network will facilitate the creation of massive "hubs." That is, large entities, very connected and with a lot of liquidity. Any significant payments should be sent through some of these entities.
Obviously, that wouldn't be a great situation. It would weaken the system, as these entities going offline would disrupt peer relationships. There is also a higher risk of censorship, as there are only a few points through which transactions flow.
Lightning Network Current Status
As of March 2024, the Lightning Network looks healthy. It has over 13,000 online nodes, over 52,000 active channels, and just over 4,570 BTC in capacity.
Global distribution of Lightning Network nodes.
There are a handful of different node implementations: Blockstream's c-lightning, Lightning Network Daemon from Lightning Labs, and ACINQ's Eclair are a few examples. For users who are less technically proficient, many companies offer plug-and-play nodes. All you have to do is turn on the device and you're ready to go with the Lightning Network.
Conclusions
Since its mainnet launch in 2018, the Lightning Network has seen significant growth. There are still some usability hurdles to overcome, as a certain degree of technical proficiency is currently required to operate a Lightning node. But, with the amount of development taking place, we may see the barriers to entry lower over time.
Further reading
Blockchain scalability: sidechains and payment channels
What are nodes?
What are smart contracts and how do they work?
Legal Notice and Risk Warning: This content is presented "as is" for general information and educational purposes only, without representation or warranty of any kind. It should not be construed as financial, legal or other professional advice nor is it intended to recommend the purchase of any specific product or service. You should seek individual advice from suitable professional advisors. As this article is contributed by third parties, please note that the opinions expressed are those of the third party contributor and do not necessarily reflect those of Binance Academy. For more information, read our full legal notice here. Digital asset prices can be volatile. The value of an investment can go down as well as up, and you may not get back the amount invested. Only you are responsible for your investment decisions. Binance Academy is not responsible for any losses you may incur. This material should not be construed as financial, legal or other professional advice. For more information, please see our Terms of Use and Risk Warning.
