Lightning Network first appeared in the whitepaper proposed by Joseph Poon and Thaddeus Dryja in 2015. It generated huge responses and discussions among the Bitcoin community and has been widely regarded as the second most important whitepaper on Bitcoin behind Satoshi Nakamoto’s groundbreaking work.

As the Lightning Network relies on the protocol in Segregated Witness (SegWit), it has largely remained a concept and has been developing internally only. Ever since the Bitcoin SegWit fork in 2017, the development of Lightning Network has been steadily moving forward on the right track.

In March 2018, Lightning Labs developed and launched the initial test version. Later, ACINQ and Blockstream followed suit and launched a number of implementations on the Network. According to the data from 1ml, there are currently a total of 8,204 nodes and 37,901 payment channels on Lightning Network, with 1,021.37 BTC (approximately $5.34 million) on the payment channels, proving that Lightning Network has achieved significant growth in the past year.

Lightning Network aimed to address Bitcoin’s scalability. As we all know, Bitcoin was initially created as a peer-to-peer electronic cash system to provide a decentralized and 24/7 electronic payment network, yet Bitcoin’s scaling problem is far from satisfactory.

If we calculate based on an average of 300 nodes per trade, Bitcoin is only capable of handling 5.6 transactions per second, while Visa can handle 47,000 tps at its peak capacity. To reach this capacity, Bitcoin would need to expand its block size to around 8GB, with 400 TB new block data added each year, which is obviously unrealistic.

Lightning Network is just one of the many solutions the blockchain community proposed to solve Bitcoin’s scaling problem, such as large blocks, DPoS, DAG, sharding, two-way pegged sidechain, cross-chain communication, etc.

They proposed to optimize the basics of distributed ledger technology, e.g. adjusting the configuration parameters, optimizing data structures, modifying the consensus algorithms, ledger division processing, optimizing network resources, etc., but the result was not ideal and only very limited performance improvement was achieved after all the hard work (increase storage capacity, increase network traffic, increase logic complexity, decrease decentralization). Compared with Visa, Bitcoin is still lagging significantly.

It seems that Lightning Network is the ultimate solution.

Due to the complexity of Bitcoin smart contracts, it is difficult to understand the technical principles of Lightning Network. The OK Research team has therefore re-implemented the Lightning Network with Solidity language in order to understand the technology involved for implementing the Lightning Network. We have summarized the basic procedures and principles of Lightning Network for you below.

Key Technical Principle of Lightning Network

The core idea of Lightning Network is to create temporary off-chain payment channels that allow both parties to perform unlimited transactions off-chain with multiple payment channels, but only the final transaction will be recorded on the blockchain. In this way, transactions are much more efficient and instant, as they don’t need to wait for the block to update. Lightning Network is working on how to keep the off-chain transactions from being edited.

1. Lightning Network is built on three important concepts – virtual bank, commitment transactions, and payment channels.

a) Virtual Bank

Smart contract operates like a bank. Take Alice and Bob as an example, a virtual bank is –

• Scalable – There are only two accounts –  Alice’s and Bob’s
• Trustless – Open, transparent, cannot be tampered, forged or canceled
• User’s autonomy – Alice and Bob manage the assets together
• Multi-signature – Any reallocation of fund needs to be signed by both Alice and Bob

b) Commitment Transactions

A commitment transaction is when both parties reach an agreement on the distribution of funds and sign. The update is not immediately broadcasted to the blockchain, but is stored on the local network.

A commitment transaction expresses the true will of both parties. It is an agreement for the distribution of funds between them. The transaction –

• Cannot be tampered
• Cannot be forged
• Can be overwritten

c) Payment Channels

A payment channel is when both payment parties use the virtual bank to escrow their assets and redistribute the balance of their deposits through mutual agreement, so that value can be transferred.

Commitment transaction is divided into direct and indirect connection.

RSMC (Recoverable Sequence Maturity Contract) and HTLC (Hashed Timelock Contracts)

1. RSMC (Revocable Sequence Maturity Contract)

It includes the active party, who actively submits commitment transactions to the virtual bank for fund allocation, and the receiving party, who passively receives the allocation submitted by the active party.

RSMC prevents malicious motives through a trust deposit mechanism.

When the active party initiates a liquidation request, the receiving party’s fund, say $100, will be cashed out and returned to the receiving party’s account immediately. The active party’s asset ($100) will be locked as a security deposit. The lock time is determined by the freeze_time parameter set by the smart contract (freeze_time refers to the time active party’s asset being locked, which can be negotiated by both parties). If the receiving party found out that the commitment transaction requested by the active party has been revoked, the receiving party can unlock the revoking lock within the lock-up period and take the active party’s trust deposit as fine. On the contrary, after the lock-up period, the active party can retrieve their trust deposit.

RSMC is a dual commitment for both counterparties. Each party keeps a copy of the commitment and both copies are binding and effective to the virtual bank. The dual commitment allows the support of the bi-directional payment channels, avoiding a block in the payment channel because of an error from either side.

The common properties between the two commitments – commitment number, balance, freeze time.

The differences between the two commitments – active and receiving party, sign party, security deposit and revocation lock.

The settlement process of RSMC can be divided into three parts.

Opening a channel

• Alice and Bob create #1 RSMC and each of them contributes 100 BTC into a fund.

Creating a commitment transaction (payment)

• A new obligatory relationship is formed between Alice and Bob. They will create #2 RSMC and exchange signatures to update the ownership of the fund. Note that Alice and Bob hold the signature of the counterparty. Once they input their own signature into the transaction, it will become effective immediately.
• Both parties broadcast the private key for the revocation lock of #1 RSMC, which will become invalid at the same time. RSMC can be continuously replaced. The commitment number increases by one per replacement.

Closing a channel

• Alice signs on the #N RSMC, which already includes Bob’s signature, and submits a settlement request to the virtual bank.
• As the active party, Alice’s 50 BTC is frozen as a security deposit, while Bob’s 150 BTC is released immediately. When Alice’s funds are frozen, if Bob finds the commitment of funds re-allocation fails, e.g. #1 RSMC fails, he can trigger revocation at any time and claim also the security deposit, which he is legitimately entitled to.
• If the commitment stays valid throughout the funds freezing period, Alice will be able to reclaim the security deposit.

Although RSMC can fulfill the basic needs of the settlement process, it has obvious limitations. A channel must be open between both parties in RSMC for payment. To solve this limitation, the Hash Timelock Contract (HTLC) is proposed. HTLC makes payment routable across two or more payment channels.

2. Hash Timelock Contract (HTLC): solving the atomicity problems in payment channels

Two conditions are involved in the HTLC: Timelock and Hashlock.

• Timelock – requires the receiver to acknowledge the receipt within a period of time (T).
• Hashlock – one party generates a random number (H) and generate its hash (R), if the other part is able to prove Hash (R) = H, then the payment is valid.

In most cases, HTLC includes the properties of RSMC. It acts as a bridge between two always effective RSMCs. A new RSMC will be established if the timelock and hashlock conditions are met. Otherwise, the previous RSMC will be adopted instead.

HTLC payments process

From left to right, establishing a commitment forward; from right to left, sending a hashed number backward to complete the payment.

• Carol generates a random number (R), then generates its hash (H), and sends both to Alice;
• Alice sets up a HTLC with Bob. The timelock is set as 2T. Alice sends H to Bob.
• Bob sets up a HTLC with Carol. The timelock is set at T (must be shorter than 2T). Bob sends H to Carol.
• Carol sends H, the hashed R, to Bob for validation. If the number matches before expiration, an always effective RSMC will be established based on the HTLC, and the HTLC will be canceled at the same time, fulfilling its responsibility. But if the number R does not match or the payment expires, HTLC will fail and the payment will return to the last RSMC.
• Bob will send the number R from Carol to Alice for validation. And the above validation process repeats.

Among the three parties, Alice and Carol are the endpoints of the transaction, Bob is only a merchant to connect the other two parties. In fact, Bob can establish a payment relationship with either party. For example, the commitments established between Bob and Alice, and Bob and Carol can be different. Bob can pay Carol $9.9 and charge Alice $10. The $0.1 will be the transfer fee for Bob.

3. The risks that the two types of contracts are trying to solve – cheating and atomicity

• Cheating – what if the other party is devious and unprincipled?
• In RSMC, from #N-1 to #N commitments, the active party can benefit itself by not revoking #N-1 commitment. Therefore, an additional condition must be added for the active party for broadcasting the revocation lock.
• In HTLC, from #N-1 to #N commitments, only the receiving party can only broadcast the hashed number to receive the payment (same as revoking #N-1 commitment). If the active party does not revoke #N-1 commitment, the receiving party can still claim it through the virtual bank directly. To conclude, HTLC establishes a balanced all-or-nothing rule to avoid the participants from cheating.
• The risks of multiple payment channels: atomicity of neighboring channels
  In the payment path, the active party creates a HTLC to the receiving party. Then, the receiving party sends the hashed value backward. Payments on the left side must be completed before those on the right side.
• For any intermediaries, completing payments for nodes on the right side means receiving the hashed number within the timelock. And the timelock on the left side must be longer than the timelock on the right side. So, the intermediaries must be able to claim equal compensation from the nodes on the right side, implying that the benefits of intermediaries usually comes from the side with a shorter timelock. If we try to go in the backward direction, the nodes on the right side never complete any payment, and they can never receive the hashed number. So, the payment on the left side will also never complete. This is the atomicity of the neighboring channels.
• On the whole, the trust mechanism is built on top of the autonomy of both parties. In the decision-making stage, the receiving party signs before the active party does. Therefore, the active party has the right of initial review and the active party has the right of second review. In the execution stage, the active party has the right of submission, the virtual bank the right of execution, and the receiving party the right of review within a certain period of time.

Blockchain Trilemma and Lightning Network Solution

Bitcoin is a peer-to-peer electronic cash system. It is groundbreaking because it created a digital payment system with the unique feature of the cash payment system –  settling payment instantly. The exchange of value is done immediately with the exchange of “symbols of value”, along with the asset information and the transfer of creditor’s claims and liabilities. Digital payment has been struggling to achieve this because a digital file can be duplicated or falsified, which are the two most discussed issues in digital payments  – validation and double spending.

Validation – this problem was solved by Bitcoin using a digital signature. Whoever owns the private key, owns the Bitcoin.

Double Spending – as illustrated in the diagram below, when Bob accepts Alice’s transaction, he will have to confirm that the transaction is not duplicated by checking the whole ledger. Preventing double spending created a scalability problem.

As written by Satoshi Makamoto in Bitcoin – A Peer-to-Peer Electronic Cash System:

“We need a way for the payee to know that the previous owners did not sign any earlier transactions. For our purposes, the earliest transaction is the one that counts, so we don’t care about later attempts to double-spend. The only way to confirm the absence of a transaction is to be aware of all transactions.”

The only way to solve double spending is to acquire all the transaction records, on which Satoshi’s distributed ledger is based. But the cost is prohibitive.

• Storage – every node has to store a copy of the full ledger
• Validation – every node has to validate all transactions
• Communication – every node has to communicate with each other
• Consensus – every node has to provide hash power for consensus

For every transaction, the required storage, computation, and communication will be positively proportional to the number of validation nodes. To achieve consensus between scattered nodes requires more time. This is the Blockchain Trilemma we always hear about, the difficulty in achieving decentralization, security, and scalability at the same time.

Solutions are emerging to solve the scalability problem in recent years, such as larger block size, DAG network, new mechanisms (DPOS, PBFT), sharding, and sidechain. The consensus mechanisms like DPOS and PBFT are sacrificing a degree of decentralization for scalability, reducing the number of nodes for validation.

The trending sharding and sidechain proposals are more advanced. Although they are also reducing the validation nodes range to increase consensus efficiency, they integrated the idea of “grouping”, which avoided validation frequently being done on specific nodes, lowering the manipulation risks.

Nevertheless, sharding technology is still in its infancy. More exploration and experiments are yet to be performed on problems such as randomness, balance, and dependency. Simply put, there is no absolute resolution for the Blockchain Trilemma yet. But Lightning Network stands out amongst off-chain scalability solutions.

The logic behind Lightning Network is simple. It is not limited by the “peer-to-peer cash system”. Instead, it introduced a debt transfer mechanism which is very similar to wire transfer. The transfer between Alice and Bob is no longer the ownership of the asset, but the debt to a virtual bank. The double spending solution is simplified – Bob now only has to confirm with the virtual bank on the account balance, instead of confirming with the whole network on Alice’s transfer record. However, Lightning Network’s virtual bank does not involve the idea of a centralized middleman, a smart contract is used instead to guarantee the debt settlement by the virtual bank.

Anyway, Lightning Network achieved reducing a significant number of transactions which require full consensus. By building an off-chain payment channel, it fulfills validation and double-spending prevention with infinite groups. As there is no dependency between the off-chain groups, it minimizes the risk that a part of the network imposes to the entire network.

Advantages of Lightning Network

Five main advantages of the lightning network:

Low Transaction Fees

• Miners are not required. Small fees are levied for using the payment channels between nodes.

Real-time Confirmation

• A smaller number of nodes in participation. Transactions are generally completed between hundreds of milliseconds to a few seconds.

High Parallel Processing Capacity

• Channel Capacity = Bitcoin TPS x 3,600 x 24 x Average Channel Age / 4 = 3,952,800
• Parallel Processing Capacity = Channel Capacity / Channels Occupied per Transaction = 658,880
  *the average channel age is sourced; channels occupied per transaction is defaulted as 6 based on the six degrees of separation.

Small Size

• Most data are stored off-chain, freeing up storage space on the blockchain.

Anonymity

• Transactions are off-chain and are almost impossible to trace.

In the next chapters, we will dive deeper and explore why debt settlement model would be more efficient, and also the cons of Lightning Network and emerging solutions.

This post originally appeared on Medium. Read more.

---

Disclaimer: Opinions expressed at The Daily Hodl are not investment advice. Investors should do their due diligence before making any high-risk investments in Bitcoin, cryptocurrency or digital assets. Please be advised that your transfers and trades are at your own risk, and any loses you may incur are your responsibility. The Daily Hodl does not recommend the buying or selling of any cryptocurrencies or digital assets, nor is The Daily Hodl an investment advisor. Please note that The Daily Hodl participates in affiliate marketing.