Introduction
Cryptocurrencies have some pretty unique properties. These cannot easily be hacked or closed easily, and anyone can use them to transmit value around the world without third party intervention.
To ensure these characteristics are maintained, significant compromises must be made. Because many nodes are responsible for running a cryptocurrency network, throughput is limited. Thus, the number of transactions per second (TPS) that a blockchain network can process is relatively low for a technology intended for mainstream adoption.
To overcome the inherent limitations of blockchain, a number of scalability solutions have been proposed to increase the number of transactions that the network can process. In this article, we will discuss one of the extensions of the Bitcoin protocol, the Lightning Network.
What is the Lightning Network?
The Lightning Network is a network located on top of a blockchain allowing rapid peer-to-peer transactions. This is not exclusive to Bitcoin: other cryptocurrencies such as Litecoin have also integrated it.
You may be wondering what we mean by “sitting on top of a blockchain”. The Lightning Network is what we call an off-chain or layer-2 solution. It allows users to make transactions without having to record each transaction in the blockchain.
The Lightning Network is separate from the Bitcoin network – and has its own nodes and software, but still communicates with the main chain. To enter or exit the Lightning Network, you must create special transactions on the blockchain.
What you are actually doing with your first transaction is creating a sort of smart contract with another user. Before we get into details – imagine that the smart contract owns the private ledger with the other user. You can enter many transactions on this register. These are only visible to you and your counterpart, but neither of you can cheat due to specific features.
This mini-register is a channel. Let's say Alice and Bob each put 5 BTC into the smart contract. In their channel, they now have a balance of 5 BTC each. Alice can now write in the ledger that she pays 1 BTC to Bob. Bob now has 6 BTC and Alice has 4. Bob can then decide to send 2 BTC back to Alice, updating the balances to 6 BTC on Alice's side and 4 BTC on Bob's side. They may continue to do this for a while.
At any time, one of them can publish the current state of the channel on the blockchain. At this point, the balances on each side of the channel are assigned to their respective parties on the chain.
True to their name, Lightning transactions are fast. There is no block confirmation to wait for payments to go through as quickly as your Internet connection allows.
Why is the Lightning Network necessary?
So far, the Lightning Network (or LN) seems to be the most realistic approach to improving the scalability of the Bitcoin blockchain. Coordinating changes in such a large ecosystem is very tricky due to the risks of hard forks and potentially catastrophic bugs. With so much value at stake, experimentation is incredibly dangerous.
When this experimentation takes place away from the blockchain, flexibility increases. If something goes wrong, it will have no impact on the Bitcoin network. Layer 2 solutions do not call into question the security assumptions that have allowed the protocol to operate for more than 10 years.
There is also no obligation to change the old way of doing things. On-chain transactions continue to work for the end user, but the end user now has the option to perform off-chain transactions.
There are several benefits to using the Lightning Network. Here are a few.
Scalability
Bitcoin blocks are typically created every ten minutes and cannot store many transactions. Space in blocks is a scarce resource up for auction. You are in effect competing against other users to have your transactions included. Since miners are primarily concerned with getting paid, they will prioritize transactions with the highest fees.
When few users are trying to send funds at the same time, this isn't really a problem. You can set a low fee and you have every chance of seeing the transaction included in the next block. But when everyone broadcasts trades at the same time, average fees can increase significantly. On some occasions these have exceeded $5. At the peak of the 2017 buyer's market, they even exceeded $50.
Average Bitcoin Transaction Fee (in USD)
This may seem insignificant for transactions of several thousand dollars in Bitcoin, but it is not viable for small payments. Who wants to pay $5 fees for a $3 coffee?
With the Lightning Network, you will have to pay two fees: one to open the channel and the other to close it. But you and your counterparty can make thousands of trades for free once the channel is open. Once you're done, you simply publish the final state to the blockchain.
Overall, if more users use off-chain solutions like the Lightning Network, block space will be used more efficiently. Low-value, high-frequency transfers could be done 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.
Micropaiements
The minimum amount of Bitcoin you can send in a transaction is approximately 0.00000546 BTC. At the time of writing, that works out to about four cents. It's a small amount, but the Lightning Network allows you to push the limits down to the smallest possible unit (0.00000001 BTC: the satoshi).
The Lightning network is much more interesting for micropayments. Fees on normal transactions make it impractical to send small amounts to the main chain. In one channel, however, you are free to send a fraction of a fraction of Bitcoin for free.
Micropayments are suitable for many use cases. Some consider that they could be a replacement for the subscription model, with users paying very, very small amounts each time they use a service instead of a monthly subscription.
Confidentiality
Another advantage of the Lightning Network is that it can provide its users with a high degree of privacy. Parties do not need to publicize their channels to the wider network. If you can look at the blockchain and say this transaction opened a channel, you won't necessarily be able to tell what's happening in the channel. If participants decide to make their channel private, they will in fact be the only ones to know the transactions that have taken place.
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. The Lightning Network can be seen as a sprawling network of interconnected payment channels. In such a setup, you could not be sure who Alice sent funds to once the channel is closed.
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 take a look under the hood.
Multisignature addresses
A multisignature (or multisig) address is an address from which multiple private keys can spend. When creating a multisig, you must indicate how many private keys can spend the funds and how many are required to sign a transaction. For example, a 1-5 scheme means that five keys can produce a valid signature and only one is needed. A 2-3 diagram indicates that of the three keys, two are required to spend the funds.
To initialize a Lightning channel, participants lock up funds in a 2-2 pattern. There are only two keys capable of signing, and these are needed to move their funds. Let's bring back our friends Alice and Bob. As they will have to make numerous payments in the coming months, they decide to open a Lightning Network channel.
To start, they each deposit 3 BTC into the jointly owned multisig address. It is important to reiterate that Bob cannot withdraw funds from the address without Alice's approval, and vice versa.
Now they could just keep a piece of paper that would adjust everyone's balances. Their respective starting balance is 3 BTC. If Alice wants to make a payment of 1 BTC to Bob, why not make a note stating that Alice now has 2 BTC and Bob 4? Balances can be tracked like this until they decide to withdraw the funds.
It's possible, but where's the fun in it? More importantly, doesn't this make it easy for one party to refuse cooperation? If Alice ends up with 6 BTC and Bob 0, nothing prevents Bob from refusing to release the funds (except perhaps his friendship with Alice).
Contrats Hash Timelock (HTLC)
The above system is boring and doesn't offer much more than today's reliable setups. The situation becomes much more interesting when we introduce a mechanism that enforces the “contract” between Alice and Bob. If one party decides not to play by the rules, the other still has recourse to withdraw its funds from the channel.
This mechanism is the Hash Timelock Contract (or HTLC). While the term can be scary, it is a relatively simple concept to understand. This uses two technologies (hashlock and timelock) to address any uncooperative behavior in the channel.
A hashlock is a condition placed on a transaction that you can only spend funds by proving you know a secret. The sender hashes a set of data and includes the hash in the recipient’s transaction. The receiver can only spend it if it provides the original data (the secret) that matches the hash. And the only way they can provide that data is if the sender gives it to them.
A timelock condition prevents funds from being spent before a certain date. This is defined as a real time or as a block height.
HTLCs represent the combination of hashlocks and timelocks. In practice, HTLCs can be used to create conditional payments: the recipient must provide a secret by a certain date, otherwise the sender will be able to recover the funds. We can probably explain the next section better with an example, so let's get back to Alice and Bob.
Open and close channels
We gave the example of Alice and Bob who have just created transactions financing the multisignature address they are going to share. But these transactions are not yet published on the blockchain! There is indeed one thing left to do first.
Three corners from Bob and 3 corners from Alice.
Remember that the only way for these coins to exit the multisig is for Alice and Bob to jointly sign a transaction. If Alice wants to send the six coins to an external address, she will need Bob's agreement. She first completed a transaction (six bitcoins at this address) and added her own signature.
She could try to broadcast the transaction immediately, but it will not be valid because Bob did not sign it. Alice must first give him the incomplete transaction. Once Bob adds his signature, the transaction becomes valid.
We still do not have a mechanism in place that allows everyone to collaborate honestly. As said above, if your counterparty refuses to cooperate, your funds will effectively be trapped. Let's see together the mechanism that prevents this. There are several parts to study, so please follow along.
Each party must come forward with a secret – let's just call them As and Bs. They'd be lousy secrets if Alice and Bob revealed them, which is why they're keeping them hidden for now. The pair will generate the hash of the respective secrets: h(As) and h(Bs). Instead of sharing their secret, they share their hash.
Alice and Bob share the hash of their secret.
Alice and Bob must also create a set of commitment transactions before posting their first transaction to the multisignature address. This will allow them to have recourse in case the other decides to keep the funds hostage.
If you think of a channel like the mini ledger we talked about earlier, commitment transactions are the updates you make to the ledger. Each time you create a new pair of commitment transactions, you rebalance the funds between the two participants.
Alice's will have two outputs: one that pays for an address she owns, and another that is locked into a new multisig address. She signs and gives it to Bob.
Alice's transaction with two outputs: one to her own address and another to a new multisig. Alice still needs Bob's signature to make it valid.
Bob does the same: one exit pays for itself, the other pays for another multisig address. He signs it and gives it to Alice.
We have two incomplete, but similar transactions.
Alice could normally add a signature to Bob's transaction to make it valid. You will note however that these funds are being spent from the 2 of 2 multisig, which we have not yet funded. It's a bit like trying to spend a check from an account that doesn't have the necessary balance. Therefore, these partially signed transactions can only be used once multisig is operational.
The new multisignature addresses (where the 3 BTC are intended) have certain specific properties. Let's take a look at the incomplete transaction that Alice signed and delivered to Bob. Multisig output can be spent under the following conditions:
Both parties can sign it cooperatively.
Bob can then spend them himself after a certain period (due to the timelock).
Alice can spend them if she knows Bob Bs' secret.
For the transaction where Bob gave Alice:
Both parties can sign it cooperatively.
Alice can spend them on her own after a certain period of time.
Bob can spend them if he knows Alice Ace's secret.
Keep in mind that neither party knows the other's secret, so 3) is not possible yet. Another thing to note is that, if you sign a transaction, your counterparty can spend the funds immediately, as there are no special conditions on their release. You can either wait for the timelock to expire to spend the funds on your own, or cooperate with the other party to be able to spend them directly.
GOOD ! You can now post transactions to the 2-2 multisignature address. It is finally possible to do this safely, because you can recover your funds if your counterparty abandons the channel.
Once transactions are confirmed, the channel is operational. This first pair of transactions shows us the current state of the mini-register. Currently, he will pay 3 BTC to Bob and 3 BTC to Alice.
When Alice wants to make a new payment to Bob, the pair creates two new transactions to replace the first set. The principle is the same: they are only half signed. However, Alice and Bob must first give up their old secret and exchange new hashes for the next round of transactions.
If Alice wants to pay 1 BTC to Bob, the two new transactions will credit 2 BTC to Alice and 4 BTC to Bob. The balance is thus up to date.
Each party can sign and broadcast even one of the recent transactions to “settle” it on the blockchain. However, whichever party does this will have to wait for the timelock to expire, while the other can spend the funds immediately. Remember that if Bob signs and broadcasts Alice's transaction, she now has an unconditional exit.
Both parties can decide to close the canal together (a cooperative closure). This is probably the easiest and fastest way to get funds back on-chain. If one party does not respond or refuses to cooperate, the other can still recover its funds while waiting for the timelock.
Do you want to get started with cryptocurrencies? Buy Bitcoin on Binance!
How does the Lightning Network prevent cheating?
You may have already identified an attack vector here. If Bob has a 1 BTC balance, what's stopping him from broadcasting an older transaction showing he owns more than 1 BTC? He has already received the semi-signed transaction from Alice, isn't it enough for him to add his signature before broadcasting the transaction?
Nothing stops him from doing so, except perhaps the fact that he could lose his entire balance. Let's say he goes all the way and broadcasts an old transaction where he pays one BTC to Alice and five to the multisig address we mentioned earlier.
Alice receives her BTC immediately. Bob, on the other hand, must wait for the timelock to expire to spend from the multisig address. Remember the other condition we mentioned that allows Alice to spend these funds immediately? She needs a secret that she doesn't yet have. She does it now: as soon as the second set of transactions was created, Bob gave her this secret.
While Bob waits, unable to do anything while waiting for the timelock to expire, Alice can move these funds. This punishment-based mechanism prevents participants from cheating or risk losing access to their coins.
Payment routing
We indicated earlier that channels can be connected. If this were impossible, the Lightning Network would not be useful for payments. Are you really going to lock in $500 on a channel with a coffee shop, just to get your daily fix for the next few months?
Nobody does that. If Alice opens a channel with Bob and Bob has a Channel with Carol, Bob can route payments between the two. This can work over multiple "hops", so Alice can pay anyone on that route.
In this scenario, Alice can take several connections to get to Frank's house. In practice, she will always take the easiest one.
For their role in delivery, intermediaries may charge a small fee (but this is not obligatory). As the Lightning Network is relatively new, the fee market has not yet materialized. What many expect is a fee based on the liquidity provided.
On the base chain, your fees are based solely on the space your transaction takes up in a block – the value transmitted does not matter – payments of $1 or even $10,000,000 cost the same . In contrast, there is no block space in the Lightning Network.
Instead, there is a concept of local and distant equilibria. Local equilibrium is the amount you can "push" toward the end of the channel. The distant balance is the balance that your counterparty can push to you.
Let's see another example. Let's take a closer look at the route above: Alice <> Carol <> Frank.
User balance before and after a transfer of 0.3 BTC from Alice to Frank.
Transactions Alice <> Carol and Carol <> Frank each have a total capacity of 1 BTC. Alice's local balance is 0.7 BTC. If the transactions were settled now on the blockchain, Alice would have 0.7 BTC and Carol would receive the remote balance (0.3 BTC).
If Alice wants to send 0.3 BTC to Frank, she just needs to transmit 0.3 BTC to Carol through the channel. Carol then transmits 0.3 BTC from her local balance to Frank through the channel. Thus, Carol's balance remains the same: Alice's +0.3 BTC and Frank's -0.3 BTC cancel out.
Carol does not lose value by acting as a connection between Frank and Alice, but she does lose flexibility. You see, she can now spend 0.6 BTC in her channel with Alice, but only 0.1 BTC in the channel with Frank.
We can also imagine a situation where Alice is only connected to Carol, while Frank is connected to a much larger network. Carol, who previously could send a total of 0.4 BTC to other people through Frank, can now only send 0.1 BTC because that's all she has on her end of the channel.
In this scenario, Alice is effectively draining Carol's cash flow. Without any rewards, Carol may not want to weaken her own position. So instead she could simply say: I will route each 0.01 BTC at a rate of ten satoshis. This way, the more Carol sacrifices her local balance in "stronger" paths, she benefits.
As said before, there is no de facto obligation to charge fees. Some may not be concerned about reduced liquidity. Others may simply open channels directly to the receiver.
Limites du Lightning Network
It would be simply fantastic if the Lightning Network turned out to be the solution to all of Bitcoin's scalability problems. Unfortunately, it also has its own flaws.
Usability
Bitcoin is not the most intuitive system for beginners: addresses and fees are difficult concepts to approach. But wallets can cut through the complicated aspects to offer users something that vaguely resembles existing payment systems. But you can get someone to download a smartphone wallet, send funds, and be ready for what's next.
This is currently impossible for the Lightning Network. The options are still very limited when it comes to smartphone apps: in general, Lightning nodes require access to a Bitcoin node in order to be used.
Once a customer has setup, users must begin opening channels before they can make payments. In addition to being time-consuming, it quickly becomes overwhelming for a beginner to have to understand concepts such as inbound/outbound capacity.
That said, improvements are constantly being made to lower the barriers to entry to provide users with a simpler experience.
Liquidity
One of the main criticisms of the Lightning Network is that your ability to transact is limited. You cannot spend more than you have locked into a channel. If you spend all your funds so that the remote balance has all the funds in the channel, you will need to close it. You can also wait for someone to pay you to do it, but that's not ideal.
Your connections are also limited by the total channel capacity. Let's return to our example of the Alice <> Carol <> Frank connection. If Alice and Carol have 5 BTC capacity on their channel, but Carol and Frank only have 1 BTC capacity, Alice will never be able to send more than 1 BTC. Even then, the entire balance would need to be on Carol's side (on the Carol<>Frank channel) for this to work. This can significantly limit the amount of funds that can be transmitted through LN channels and therefore impacts its practicality.
Centralization of hubs
Due to the problem mentioned in the previous section, there is also a fear that the network will facilitate the creation of large “hubs”. That is, large, highly connected entities with lots of liquidity. Any large payments will need to be routed through some of these entities.
This is obviously not a positive thing. Indeed, this would weaken the system, because simply taking these entities offline would greatly impact all relationships between peers. The risk of censorship is also increased, with transactions only circulating through a few entities.
Current Status of the Lightning Network
Since April 2020, the Lightning Network seems to be doing well. It has more than 12,000 active nodes, more than 30,000 open channels and more than 920 BTC of capacity.
Global distribution of Lightning Network nodes. Source: explorer.aquin.co
There are several node implementations: c-lightning from Blockstream, Lightning Network Daemon from Lightning Labs, and Eclair from ACINQ are among the most popular. Many companies offer ready-made nodes for less experienced users. The only thing you need to do with these devices is turn them on and you're ready to use the Lightning Network.
To conclude
Since the launch of its mainnet in 2018, the Lightning Network has seen impressive growth. However, many people consider it to be still in the beta phase.
There are still some hurdles to overcome on the utility front, with using a Lightning node currently requiring a certain degree of technical skill. But given the scale of development underway, we may well see barriers to entry reduced in the coming years.
If these issues can be resolved, the Lightning Network could become an integral part of the Bitcoin ecosystem and significantly improve its scalability and transaction speed.