Introduction
Cryptocurrencies have several unique properties: they cannot be easily hacked or disabled, and anyone can use them to transfer funds around the world without any intermediaries.
The safety of these functions is guaranteed by certain compromises: since many nodes are responsible for the operation of the cryptocurrency network, its throughput is limited. Because of this, the number of transactions per second (TPS) that a blockchain network can handle is relatively low for a technology that is aiming for mass adoption.
To overcome these limitations and increase network throughput, a number of scalability solutions have been proposed. In this article we will look at one of the extensions of the Bitcoin protocol - the Lightning Network.
What is Lightning Network?
The Lightning Network is a network deployed on top of the blockchain to enable fast peer-to-peer (P2P) transactions. This solution is not only available for Bitcoin: other cryptocurrencies, such as Litecoin, can also integrate it.
What does “deployed on top of the blockchain” mean? Lightning Network is an off-chain solution, or a second-layer solution. It allows you to make transfers 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, but still must communicate with the main chain. To enter or leave the Lightning Network, you need to create special transactions on the blockchain.
What happens with your first transaction is the creation of some sort of smart contract with another user. We'll sort out all the details soon. For now, imagine a smart contract that forms a private ledger with another user. In this ledger, you can record many transactions, and they will be visible only to you and your partner, but neither of you will be able to cheat the system due to some specific features.
This mini-register is called a channel. Let's say Alice and Bob each deposit 5 BTC into the smart contract. The balance on their channel is 5 BTC each. Alice can then enter into the register to transfer 1 BTC to Bob. Bob will now have 6 BTC and Alice will have 4. Bob then sends Alice 2 BTC, updating the balances to 6 BTC for Alice and 4 BTC for Bob. This may continue for some time.
At any time, any of them can publish the current state of the channel on the blockchain. At this point, the balances on each side of the channel will be distributed to the corresponding parties in the chain.
Transactions on the Lightning network occur at lightning speed (its very name means lightning). Since there is no need to wait for block confirmation, payments can be made at the maximum speed that the Internet connection supports.
What is the need to implement Lightning Network?
The Lightning Network (LN) is currently the most sensible approach to scaling the Bitcoin blockchain. Coordinating changes in such a huge ecosystem is quite difficult, as there is a risk of hard forks and potential errors. For these and other reasons, conducting any experiments online is extremely dangerous.
If you conduct similar experiments outside the blockchain, you can get much more flexible solutions. In this case, errors and failures will not affect the Bitcoin network. Second-layer solutions do not undermine the security foundations on which the protocol has been operating for more than 10 years.
There is also no need to switch from the old way of doing things. On-chain transactions (within the network) continue to operate as normal for all end users, but in addition, the ability to perform transactions off-chain (outside the network) will also be available.
There are several benefits to using the Lightning Network. We will look at some of the main ones below.
Scalability
Bitcoin blocks are created every ten minutes and can contain a certain number of transactions. Space within a block is limited, so users place bets to move their transactions forward. Since miners are primarily interested in income, they process transactions with the highest rates first.
When a small number of users send funds at the same time, this is not a problem. If there is little activity, even a transaction with a low commission will most likely be included in the next block. But if many people make transfers, the average commission will increase significantly. Throughout history, the fee has exceeded $5 several times, and at the peak of the bull market in 2017, it rose above $50.
Average Bitcoin transaction fee (in USD)
This may seem insignificant for transactions of several thousand dollars, but for small transfers it is a critical factor. Who wants to pay for a $3 coffee with a $5 transfer fee?
With the Lightning Network, you still pay two fees: one for opening a channel and one for closing it. But you and your counterparty get the opportunity to make thousands of transactions absolutely free within the open channel. Once you've completed all the necessary operations, you simply need to publish the final state of your balances to the blockchain.
Globally, the more users rely on autonomous solutions like the Lightning Network, the more efficient the use of block space will become. Low-frequency and high-frequency transfers can be made within payment channels, while block space will be used for larger transactions and opening/closing of such channels. This will make the system available to a wider user base and allow the network to scale in the long term.
Micropayments
In Bitcoin, the minimum transaction size is 0.00000546 BTC - at the time of writing this is about four cents. This is a small amount, but you can send as little as 0.00000001 BTC to the Lightning Network, which is one Satoshi.
When it comes to micropayments, Lightning is the most viable option in this context. Paying fees for regular transactions makes it impractical to send small amounts on the main chain, but within the channel, you can move small pieces of Bitcoin absolutely free.
Micropayments are suitable for a variety of use cases. Some believe they could be a viable replacement for the signature-based model, where users instead pay a small fee each time they use a given service.
Confidentiality
The second advantage of the Lightning Network is the high degree of user privacy. Parties do not need to publish information about their channels online. The blockchain is only provided with the information that a particular transaction opened the channel, but the details remain unknown. If members make their channel private, then only they will know what transactions are taking place within it.
If Alice has a channel with Bob and Bob has a channel with Carol, Alice and Carol can send funds to each other through Bob. If Dan is connected to Carol, Alice will also be able to transfer funds to him. You can think of it as an ever-expanding, extensive network of interconnected payment channels. With this setup, you cannot be sure who Alice sent the funds to after the channel is closed.
How it works?
So, above we have already looked superficially at how the Lightning Network relies on channels between nodes. Let's now look at how the system works from the inside.
Multi-signature addresses
A multi-signature address involves the use of several private keys to complete the transfer. When it is created, the number of private keys that can spend funds and are required to sign the transaction is indicated. For example, a 1 of 5 scheme means that five keys can create a valid signature, but only one is required to complete the transfer. Scheme 2 of 3 will mean that out of three possible keys, two are needed for translation.
To create a Lightning channel, participants lock funds in a 2 out of 2 scheme. Only two private keys can create a signature, and both of them are needed to move coins. Let's look at this using the example of Alice and Bob. They expect to be making a lot of transfers in the coming months, so they are creating a channel on the Lightning Network.
This starts with both of them depositing, say, 3 BTC each, to their shared multisig address. It is worth noting again that Bob cannot withdraw funds from such an address without Alice's consent or vice versa.
This is equivalent to having a piece of paper that adjusts the balance of each side. For example, if they have a starting balance of 3 BTC and Alice wants to make a payment of 1 BTC to Bob, why not just note that Alice now owns 2 BTC and Bob now owns 4 BTC? Such balances can be monitored until the parties make a mutual decision: to withdraw funds.
It's possible, but what could be the catch? More importantly, isn't this simplicity a reason for someone not to cooperate? If Alice receives 6 BTC and Bob receives none, Bob has nothing to lose (other than his friendship with Alice) by refusing to release the funds.
Hash Timelock Contracts (HTLC)
The above system is simple and does not offer rich functionality compared to other modern configurations. Things get a lot more interesting when we introduce a mechanism that provides a “contract” between Alice and Bob that allows for the return of funds from the channel if one of the parties does not want to play by the rules.
This mechanism is called Hash Timelock Contract (HTLC). Its concept is quite simple. It combines two technologies - hash lock and time lock - to prevent unwanted activities in payment channels.
A hash lock is a condition for a transaction under which funds can only be spent by a person who knows certain data (the secret). The sender hashes a portion of the data and includes the hash in the transaction for the recipient. You can unlock funds by providing the sender with the original data (secret) corresponding to the specified hash.
A time lock is a condition that does not allow you to spend funds before a certain time. The time period is specified as either actual time or block height.
HTLCs are created by combining hashlocks and timelocks. In practice, HTLCs can be used to create conditional payments: the recipient must provide the secret before a certain time, or the sender becomes entitled to a refund. The next part is best seen using our popular example, so let's go back to Alice and Bob again.
Opening and closing channels
Consider an example: Alice and Bob have just created transactions that fund a multisig address. They plan to use this address in the near future, but so far these transactions have not yet been published on the blockchain. First you need to do one more thing.
Bob's three coins and Alice's three coins
Remember that the only way to extract coins from a multisig wallet is for both parties to co-sign the transaction, meaning she would need Bob's approval to send all six of Alice's coins to an external address. In this case, she will have to create a transaction (six bitcoins to a specific address) and add her own signature.
Alice can immediately try to broadcast the transaction, but it will be invalid because Bob did not sign. Alice must provide him with the pending transaction, and once he signs it, the transaction becomes valid.
However, in this case, there is not yet a process obliging 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 be the 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 revealed them, they would be bad secrets, 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 need to agree on certain transaction obligations before sending transfers to a multisig address. This allows for security in case someone decides to embezzle funds.
If you think about a channel like the mini ledger we referred to earlier, transaction commitments are the updates you make to the ledger. Every time you create a new pair of transaction obligations, you are rebalancing the funds between the two participants.
Alice will have two outputs: the first address she replenishes, and the other one she binds to the new multi-signature address. She signs the second address and gives it to Bob.
Alice's transaction with two outputs: one depositing to her own address and one depositing to a new multisig address. However, the latter still requires Bob's signature to make the transaction valid.
Bob does the same: one address is his personal one, and the other is multi-signature. He signs it and gives it to Alice.
We have two pending transactions that are very similar.
Alice can add a signature to Bob's transaction, thereby approving it. It should be noted that these funds are spent from a multi-signature 2 of 2 scheme, which has not yet been funded. It's like trying to cash a check with a zero balance. Thus, these partially signed transactions can only be used after the multisig has been launched.
The new multisig addresses (which have 3 BTC output) have some specific properties. Let's look at the pending transaction that Alice signed and submitted to Bob. A multi-signature inference can be enforced if the following conditions are met:
Both parties perform a joint signature.
Bob makes the translation himself after a certain period of time (due to time lock).
Alice can spend the balance if she finds out Bob's secret: Bs.
For the transaction, Bob asks Alice to implement the following:
Both parties perform a joint signature.
Alice makes the transfer on her own after a certain period of time.
Bob can spend the balance if he finds out Alice's secret: As.
Keep in mind that neither party knows the other's secret, so point 3 is not yet possible. It should also be noted that if you sign a transaction, your counterparty can spend the money immediately, since there are no special conditions on its withdrawal. You can wait until the time is up to spend the funds yourself, or you can cooperate with the other party to withdraw them at the same time.
So, now you can publish transactions to the original address with a multisig in a 2 of 2 scheme. As a result, it is safe because you can receive your funds if your counterparty leaves the channel.
After the transaction is confirmed, the channel starts processing the transactions. This first pair of transactions shows us the current state of the mini-ledger. At this stage, payments 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 pair will need to create two new transactions to replace the first set. The practice remains the same: deals 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.
If Alice wants to pay Bob 1 BTC, then two new transactions credit Alice and Bob with 2 and 4 BTC, respectively. This way the balance is updated.
Each party can sign and transfer the latest transactions to the other at any time in order to settle the settlement, i.e. record the final information in the blockchain. The one who does this will have to wait for the time lock to expire, while the other party can spend the funds immediately, at the time they receive them. It is worth noting that if Bob signs and broadcasts the transaction to Alice, she has the opportunity to exit without any additional conditions.
Both parties can close the channel together (perform a cooperative closure) - this is the easiest and fastest way to return funds back to the network. But even if one of the parties stops responding to requests or refuses to cooperate, the other can return their funds after the time-lock expires.
Are you wondering how to get started with cryptocurrencies? Buy Bitcoin on Binance!
Preventing Fraud on the Lightning Network
You may have already recognized a possible attack vector. If Bob's balance is now 1 BTC, what would prevent him from choosing an old transaction where he has more coins? He has already received a signature from Alice, and all he needs to do is add his signature and send the transaction to the blockchain, right?
What keeps him from taking such actions is the risk of losing his entire balance. Let's say he decides to do this and sends his old transaction, which gives Alice one coin and sends five to the multisig address mentioned earlier.
Alice receives one coin immediately. In turn, Bob must wait until the time-lock expires to spend the balance of the multisig address. If you remember the other condition that was mentioned above, then you can probably guess that it will allow Alice to immediately spend the same balance. She needs a secret that she didn't have then. She has had this opportunity since the second round of transactions was created, because Bob gave her this secret.
While Bob is waiting for the time lock to expire, unable to do anything, Alice can move these funds. This sanction-based mechanism assumes that the participant is unlikely to want to attempt to cheat, for the simple reason that in this case, the other party immediately has access to their shared coins.
Payment routing
We previously touched on this topic: channels can contact each other. Otherwise, the Lightning Network would not be as useful for various payments. You're not going to lock in $500 in the cafe channel to get daily commits for the next few months, are you?
But you don't have to do that. If Alice opens a channel with Bob and he has a channel with Carol, Bob is able 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 a similar path exists.
In this scenario, Alice can take several routes to get to Frank. In practice, this path will always be the shortest.
Intermediaries may charge a small fee (optional) for their role in routing. Because the Lightning Network is a relatively new concept, the fee market has not yet matured. Many expect to see fees based on the liquidity of the providers.
On the underlying chain, your fee depends on where your transaction ranks in the block. The transaction amount does not matter: the commission for transfers from $1 to $10,000,000 will be the same. By comparison, the Lightning Network has no such thing as block space.
Instead, it uses the concept of local and remote balances. The local balance is the amount that can be “pushed” to the other end of the channel, and the remote balance is the amount that the counterparty can push to you.
Let's look at another example. Let's explore one of the following paths: Alice <> Carol <> Frank.
User balances before and after the transfer of 0.3 BTC from Alice to Frank.
Alice <> Carol and Carol <> Frank have a total throughput of 1 BTC. Alice's local balance is 0.7 BTC. If they decided to settle on the blockchain now, she would receive 0.7 BTC and Carol would receive her remote balance (i.e. 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 to the channel with Frank. As a result, Carol's balance remains the same: +0.3 BTC for Alice and -0.3 BTC for Frank, excluding all third-party transactions.
Carol loses nothing by acting as Frank's liaison, but she does make herself less flexible. You see, she can now spend 0.6 BTC in her channel with Alice, but only 0.1 BTC in her channel with Frank.
You can imagine a situation where Alice is only connected to Carol and Frank is connected to a much wider network. Previously, Carol could send a total of 0.4 BTC to others through Frank, but now she can only offer 0.1 BTC because all her funds are on the other end of the channel.
In this case, Alice successfully absorbs Carol's liquidity. Carol, in turn, does not want to further weaken her position, so she sets a condition: to send every 0.01 BTC with a commission of ten satoshi. Thus, the more local balances that transact on Carol's terms, the more profitable her position will be.
We mentioned earlier that there are no actual commission requirements. Some may not worry about reduced liquidity, while others will open channels solely to collect fees.
Disadvantages of Lightning Network
It would be great if the Lightning Network became the solution to all Bitcoin scalability problems. Unfortunately, the concept has its drawbacks that may prevent this from happening.
Ease of use
Bitcoin is not the most intuitive system for newbies: addresses, fees and everything else can be confusing when first introduced, but wallets can save you from such complicated things and offer something similar to existing payment systems: download a wallet for your smartphone, add it to it coins, and you can start working.
This is currently not possible for the Lightning Network. The use cases are currently very limited, especially when it comes to smartphone apps. The reason is that Lightning nodes require access to a Bitcoin node to function properly.
After installing the client, users also need to start opening channels before they can make payments. This can be time-consuming and will likely be difficult for a newbie due to the many terms involved, including incoming/outgoing bandwidth.
However, technologies are constantly improving, reducing the barrier to entry, and becoming more accessible to users.
Liquidity
One of the main problems with the Lightning Network is that your financial options are limited. You cannot spend more than what is locked in the channel. If all funds are distributed to remote balances, you will most likely have to close the channel. Alternatively, you can wait for someone to pay you, but this is far from an ideal solution.
Paths may also be limited by the overall capacity of the link. Consider this using the previous example: Alice <> Carol <> Frank. If Alice and Carol's channel has 5 BTC, but Carol and Frank's channel only has 1 BTC, Alice will not be able to send more than 1 BTC through them. However, even in this case, the balance must be shifted to Carol's side in the channel Carol <> Frank. This drawback can seriously limit the throughput of LN channels, which will affect usability.
Centralized hubs
Due to the problem mentioned in the previous section, there is some concern that the network will encourage the development of large "hubs". This suggests the emergence of closely related entities with plenty of liquidity, where any significant payments will be routed through some of them.
Obviously, this scenario is not favorable. This will weaken the system, since the departure of such providers into offline mode will lead to a significant disruption of the relationships between elements of the system. There is also an increased risk of censorship due to the multiple points through which transactions pass.
Current stage of Lightning Network development
As of April 2020, the Lightning Network is developing quite successfully. The network has 12,000+ nodes online, 30,000+ active channels and just over 920 BTC in circulation.
Map of the location of current nodes in the Lightning Network. Source: explorer.acinq.co
There are several different implementations for running a node - some of the most popular are c-lightning from Blockstream, Lightning Network Daemon from Lightning Labs, and Eclair from ACINQ. Users who do not want to delve into technical aspects can use Plug-and-Play nodes. All they need to do is turn on the device and work freely on the Lightning Network.
Summary
Since the launch of the mainnet in 2018, the Lightning Network has expanded significantly, despite popular belief that it is still in beta.
At this stage of development, there are some limitations in ease of use, for example: to operate a Lightning node you will need some technical competence, but as development progresses, the threshold for entry is expected to decrease.
If all of the issues mentioned can be resolved, the Lightning Network could become an integral part of the Bitcoin ecosystem, greatly increasing scalability and transaction speed.
