Off-chain Scalability Depth Analysis

1. The Necessity of Scaling

The future vision of blockchain is to achieve decentralization, security, and scalability, but it is often only possible to satisfy two of these simultaneously, which is known as the impossible triangle of blockchain. For years, people have been exploring how to improve the throughput and transaction speed of blockchain while ensuring decentralization and security, which means addressing the scalability issue, and this is one of the hot topics in the current development of blockchain.

Definition of decentralization, security, and scalability:

• Decentralization: Anyone can become a node and participate in the blockchain system. The more nodes there are, the higher the degree of decentralization, ensuring that the network is not controlled by a few large centralized participants.

• Security: The higher the cost of obtaining control over the blockchain system, the higher the security, and the chain can resist attacks from a larger proportion of participants.

• Scalability: The ability of a blockchain to handle a large number of transactions.

The first major hard fork of the Bitcoin network originated from the scalability issue. As the number of users and transaction volume increased, the Bitcoin network with a 1MB block limit began to face congestion. Since 2015, the Bitcoin community has had disagreements over the scalability issue, with one side supporting larger blocks and the other side supporting the use of the Segregated Witness proposal to optimize the main chain structure. On August 1, 2017, the side supporting larger blocks independently developed a client system for 8MB blocks, leading to the first major hard fork of Bitcoin, resulting in the creation of the new cryptocurrency BCH.

Similarly, the Ethereum network also chooses to sacrifice a portion of scalability to ensure network security and decentralization, by setting a cap on the gas fees that can be accommodated by a single block to limit the transaction volume. The goal is to achieve trustless consensus and ensure the widespread distribution of nodes.

From the emergence of CryptoKitties in 2017 to the rise of on-chain applications such as DeFi summer, GameFi, and NFTs, the market's demand for throughput has been continuously increasing. However, Ethereum can only process 15-45 transactions per second, leading to rising transaction costs, longer settlement times, and making it difficult for most DApps to bear operational costs, resulting in the entire network becoming slow and expensive for users. The blockchain scalability issue urgently needs to be addressed. The ideal scalability solution is to maximize the transaction speed and throughput of the blockchain network without sacrificing decentralization and security.

2. Types of Expansion Solutions

We categorize the scaling solutions into two main types: on-chain scaling and off-chain scaling, based on the criterion of "whether to change a layer of the mainnet."

2.1 On-chain Expansion

Core concept: A solution that achieves scalability by altering a layer of the mainnet protocol, with the current main solution being sharding.

There are various solutions for on-chain scalability, this article will not elaborate, but will briefly list two solutions:

• Option one is to expand the block space, which means increasing the number of transactions packed into each block. However, this will raise the requirements for node devices, increase the entry threshold, and reduce the level of decentralization.

• Scheme two is sharding, which divides the blockchain ledger into several parts, with different shards responsible for different accounting, allowing parallel processing to handle multiple transactions simultaneously; this can reduce node pressure and lower the entry threshold, improve transaction speed and the degree of decentralization; however, it means that the overall network computing power is dispersed, which will lower the overall network security.

Changing a layer of the mainnet protocol can have unpredictable negative impacts, as any subtle vulnerabilities in the underlying system can seriously threaten the entire network's security. The network may be forced to fork or interrupt for repair upgrades. For example, the inflation vulnerability incident of Zcash in 2018: its underlying code had a critical vulnerability that allowed for unlimited token issuance. The team spent 8 months secretly fixing it and only disclosed the incident after the repair.

2.2 off-chain scaling

Core concept: a scalability solution that does not change the existing Layer 1 mainnet protocol.

Off-chain scaling solutions can be further divided into Layer 2 and other solutions:

• Layer2: State Channels, Sidechains, Plasma, Rollups
• Other: Validium

3. off-chain scaling solutions

3.1 State Channels

3.1.1 Summary

State channels stipulate that users only need to interact with the mainnet when opening, closing, or resolving disputes in the channel, allowing interactions between users to be conducted off-chain, thereby reducing transaction time and costs, and enabling unlimited transaction frequency.

State channels are simple P2P protocols suitable for "turn-based applications" such as two-person chess games. Each channel is managed by a multi-signature smart contract running on the mainnet, which controls the assets deposited into the channel, verifies state updates, and arbitrates disputes between participants. Participants deposit and lock funds after deploying the contract, and the channel officially opens after both parties sign to confirm. The channel allows participants to conduct unlimited off-chain free transactions ( as long as the net transfer value does not exceed the total deposited amount ). Participants take turns sending state updates to each other, waiting for the other party to sign and confirm. Once the other party signs and confirms, the state update is considered complete. Under normal circumstances, agreed state updates by both parties are not uploaded to the mainnet, and confirmation from the mainnet is only relied upon in the event of disputes or when closing the channel. When closing the channel, either participant can make a transaction request on the mainnet, which will be executed immediately if approved by all signatures; otherwise, they must wait for the "challenge period" to end before receiving the remaining funds.

In summary, state channel solutions can greatly reduce the computation load on the mainnet, improve transaction speed, and lower transaction costs.

3.1.2 Timeline

• 2015/02: Joseph Poon and Thaddeus Dryja published the draft of the Lightning Network white paper.

• 2015/11: Jeff Coleman systematically summarized the concept of State Channel for the first time, proposing that the Bitcoin Payment Channel is a sub-case of State Channel.

• 2016/01: Joseph Poon and Thaddeus Dryja officially published the white paper "The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments" proposing the Payment Channel scalability solution for the Bitcoin Lightning Network, solely for handling transfer payments on the Bitcoin network.

• 2017/11: The first design specification for State Channels based on the Payment Channel framework, Sprites, was proposed.

• 2018/06: Counterfactual proposed a detailed design for Generalized State Channels, which is the first design fully related to state channels.

• 2018/10: The article Generalised State Channel Networks introduced the concepts of State Channel Networks and Virtual Channels.

• 2019/02: The concept of state channels was extended to N-Party Channels, and Nitro is the first protocol built on this idea.

• 2019/10: Pisa expanded the concept of Watchtowers to address the issue of all participants needing to be continuously online.

• 2020/03: Hydra proposed Fast Isomorphic Channels.

3.1.3 Technical Principles

Traditional on-chain workflow: Alice and Bob interact with the smart contract deployed on the mainnet, and users change the smart contract's state by sending transactions to the on-chain. The downside is that it brings time and cost issues.

State channel workflow:

1. Alice and Bob deposit funds from their personal EOAs to the on-chain contract address, locking the funds in the contract until they are returned to the users when the channel is closed; after the two sign and confirm, the state channel is officially opened.

2. Alice and Bob can conduct an unlimited number of transactions off-chain and communicate with each other through encrypted signed messages. Both parties need to sign each transaction to prevent double-spending fraud. Through these messages, they propose updates to their account statuses and accept status updates proposed by the other party.

3. If Alice wants to close the channel, she needs to submit the final state of her account to the contract. If Bob signs to approve, the contract will release the locked funds back to the corresponding user based on the final state. If Bob does not respond with a signature, the contract will release the locked funds back to the corresponding user after the challenge period ends.

Workflow under pessimistic conditions:

1. Two participants deposit funds and start exchanging state updates.

2. Suppose at some point Bob does not respond to the status update signature sent by Alice, Alice can challenge by submitting her last valid status to the contract, which includes Bob's previous signature.

3. The contract allows Bob to respond with the next state within a period of time; if Bob responds, the two can continue trading; if Bob does not respond, the contract automatically closes the state channel and returns the funds to Alice.

3.1.4 Advantages and Disadvantages

Advantages:

• Instantaneity: Transactions can be completed immediately without waiting for block confirmation.
• Privacy: Only the operations to open and close require on-chain actions, while other transactions are completed off-chain.
• Scalability: The number of off-chain transactions is unlimited
• Low cost: Only gas fees are required to open and close the channel.

Disadvantages:

• Fund Lock: A certain amount of funds needs to be locked in the channel.
• Stay Online: Participants need to remain online to respond to the latest status.
• Multi-party interaction is restricted: applicable only between predefined participants.
• Complexity of the channel network: funds need to find a path that connects both parties.
• Not suitable for complex calculations: only suitable for simple and frequent interaction scenarios

3.1.5 Application

Bitcoin Lightning Network

Overview: The Lightning Network is a micropayment channel for the Bitcoin network. The technological evolution includes: 2/2 multi-signature construction of one-way payment channels, the addition of RSMC allowing for the construction of two-way payment channels, and further addition of HTLC enabling the expansion of payment channels to support multiple payments, ultimately constructing a payment network. By using off-chain micropayment channels and then leveraging intermediaries to form a transaction network, the scalability issue of the Bitcoin network can be addressed. The process follows "Deposit ( to establish channel ) → Lightning Network transaction ( to update channel state ) → Refund/settlement ( to end channel )"; theoretically, it can handle one million transactions per second.

Timeline:

• February 2015: Joseph Poon and Thaddeus Dryja released a draft of the Lightning Network white paper
• January 2016: Released the official white paper and established Lightning Labs
• March 15, 2018: Lightning Labs released the first mainnet version LND 0.4
• Early 2021: Public capacity of about 40 million USD, approximately 100,000 users.
• June 2021: El Salvador adopted Bitcoin as legal tender, and in September released the Chivo wallet based on the Lightning Network.
• 2022: Cash App and 26 cryptocurrency exchanges announced support for the Lightning Network
• October 2022: Lightning Labs released the Taproot-based Taro protocol ( alpha version )
• November 23, 2022: The Lightning Network has a total of 76,236 payment channels, with channel funds of 5049 BTC($81.8M)

Ecological Development: The Lightning Network ecosystem is structured from bottom to top as follows: the underlying BTC network --- core infrastructure --- various Dapps.

Core infrastructure includes:

• Lightning Network Solutions: Software programs for individuals and businesses to operate and connect to the Lightning Network, with the largest market share being Lightning Labs.
• Node and liquidity services: Provide a user-friendly interface to help manage lightning payment channels.

Above the core infrastructure are various payment and financial services as well as applications, such as Strike that allows buying and selling BTC, Twitter tips, and Shopify merchants accepting BTC, etc.

As of November 2022, the number of Dapps based on the Lightning Network has increased to over 20 categories and more than 100 applications, including payments, wallets, node management, browser extensions, podcasts, and streaming, among others. The current technological foundation related to node infrastructure has basically matured, wallet support has increased, financial services and payment integrations continue to grow, and more entertainment applications are being developed, leading to a thriving ecosystem.

Ethereum Lightning Network

Overview: The Lightning Network is a micropayment channel based on Ethereum, very similar to the Lightning Network, both expanding on-chain transactions by establishing state channels, with the goal of achieving near-instant, low-cost, and scalable ERC20 token payments on Ethereum.

Timeline:

• 2017