off-chain Scalability Depth Analysis

1. The Necessity of Expansion

The future vision of blockchain is to achieve decentralization, security, and scalability. However, it is often only possible to achieve two of these, which is known as the impossible triangle problem of blockchain. For years, people have been exploring how to improve the throughput and transaction speed of blockchain while ensuring decentralization and security, that is, to solve the scalability problem.

The decentralization, security, and scalability of blockchain are defined as follows:

• Decentralization: Anyone can become a node to participate in the production and verification of the blockchain system. The more nodes there are, the higher the degree of decentralization.

• Security: The higher the cost to gain control of the blockchain system, the higher the security, and the chain can resist a larger proportion of participant attacks.

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

The first major hard fork of the Bitcoin network stemmed from the scalability issue. As the number of users and transaction volume increased, the Bitcoin network, with a block size limit of 1MB, began to face congestion. Starting in 2015, there were disagreements in the Bitcoin community regarding the scalability issue; one side supported expanding the block size, while the other believed that the Segregated Witness (Segwit) solution should be used to optimize the main chain structure. On August 1, 2017, the side that supported expanding the block size independently developed a client system with an 8MB limit, leading to the first major hard fork in Bitcoin's history and the birth of a new cryptocurrency, BCH.

The Ethereum network also chooses to sacrifice some scalability to ensure the security and decentralization of the network. Although Ethereum does not limit the transaction volume by restricting the block size like Bitcoin, it indirectly sets a cap on the gas fees that a single block can accommodate. However, the goal is the same: to achieve Trustless Consensus and ensure the widespread distribution of nodes.

Since the emergence of blockchain applications such as CryptoKitties in 2017, DeFi summer, and later GameFi and NFTs, the market's demand for throughput has continued to increase. However, even a Turing-complete Ethereum can only handle 15 to 45 transactions per second ( TPS ). This has led to rising transaction costs, longer settlement times, and most DApps struggling to bear operational costs. The entire network has become slow and expensive for users, and the blockchain scalability issue urgently needs to be addressed. The ideal scalability solution is to increase the transaction speed and throughput of the blockchain network as much as possible without sacrificing decentralization and security.

2. Types of Scaling Solutions

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

2.1 On-chain Scalability

Core concept: A solution to achieve scalability by changing a layer of the mainnet protocol, with the current main solution being sharding.

There are various solutions for on-chain scaling, this article will not elaborate, briefly listing two:

• Option one is to expand the block space, increasing the number of transactions packaged in each block, but this will raise the requirements for high-performance node devices, increase the threshold for node participation, and reduce the level of "decentralization."

• Option two is sharding, which divides the blockchain ledger into several parts, with different shards, that is, different nodes responsible for different bookkeeping. Parallel computation can handle multiple transactions simultaneously; this can reduce the computational pressure on nodes and lower the entry threshold, improving transaction processing speed and the degree of decentralization. However, this means that the overall network's computing power is dispersed, which will reduce the "security" of the entire network.

Changing the code of a layer 1 mainnet protocol may produce unpredictable negative effects, as any slight security vulnerability in the underlying layer can severely threaten the security of the entire network, which may be forced to undergo a fork or interrupt repair upgrades.

2.2 off-chain scaling

Core concept: A scaling solution that does not change the existing Layer 1 mainnet protocol.

The off-chain scaling solutions can be further divided into Layer2 and other solutions:

• Layer2: State Channels, Plasma, Rollups ( Optimistic Rollups and ZK Rollups )

• Others: Sidechains, Validium

3. off-chain scaling solutions

3.1 State Channels

3.1.1 Overview

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

State channels are simple P2P protocols suitable for "turn-based applications", such as two-player 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. After participants deploy the contract on the blockchain network, they deposit and lock funds, and after both parties sign to confirm, the channel is officially opened. The channel allows participants to conduct an unlimited number of off-chain free transactions ( as long as the net transfer value does not exceed the total amount of tokens deposited ). Participants take turns sending state updates to each other, waiting for the other party's signature confirmation. Once the other party signs to confirm, the state update is considered complete. Under normal circumstances, state updates agreed upon by both parties will not be uploaded to the mainnet; they will only rely on the mainnet confirmation in the event of a dispute or when closing the channel. When it is necessary to close the channel, any participant can submit a transaction request on the mainnet, and if the exit request receives unanimous signature approval, it will be executed on-chain immediately, with the smart contract distributing the remaining locked funds based on each participant's balance at the final state of the channel; if other participants do not sign to approve, everyone must wait for the "challenge period" to end before receiving the remaining funds.

In summary, the state channel solution can significantly reduce the computational load on the mainnet, improve transaction speed, and lower transaction costs.

3.1.2 Timeline

• In February 2015, Joseph Poon and Thaddeus Dryja released a draft of the Lightning Network white paper.

• In November 2015, Jeff Coleman systematically summarized the concept of State Channel for the first time, proposing that Bitcoin's Payment Channel is a sub-case of the State Channel concept.

• In January 2016, Joseph Poon and Thaddeus Dryja officially published the white paper "The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments" proposing the scaling solution for the Bitcoin Lightning Network Payment Channel( payment channel), which is only used for processing transfer payments on the Bitcoin network.

• In November 2017, the first design specification for State Channels based on the Payment Channel framework, called Sprites, was proposed.

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

• In October 2018, the article "Generalised State Channel Networks" introduced the concepts of State Channel Networks and Virtual Channels.

• In February 2019, the concept of state channels was extended to N-Party Channels, with Nitro being the first protocol built on this idea.

• 2019/10, Pisa expanded the concept of Watchtowers to address the issue of continuous online presence required by all participants.

• 2020/03, Hydra proposed Fast Isomorphic Channels.

3.1.3 Technical Principles

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

The general workflow followed by most state channel protocols:

1. Alice and Bob deposit funds from their personal EOA to an on-chain contract address, where these funds are locked in the contract until they are returned to the user when the channel is closed; after both parties sign their confirmation, the state channel is officially opened between them.

2. Alice and Bob can theoretically conduct an unlimited number of off-chain transactions through this channel, with participants communicating with each other via encrypted signed messages. Both users need to sign each transaction to prevent double-spending. Through these messages, they propose updates to their account states and accept the updates proposed by the other party.

3. If Alice wants to close the channel and end the transaction with Bob, Alice needs to submit the final state of her account to the contract. If Bob signs and approves, the contract will release the locked funds back to the corresponding user according to 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.

The workflow of the state channel in pessimistic cases: at first, two participants deposit funds and then start exchanging state updates. Suppose that at some point in time, Bob does not respond to the state update signature sent by Alice in his round, at this point, Alice can challenge by submitting his last valid state to the contract, which also includes Bob's previous signature, to prove that the last transaction has been approved by Bob, and the last state has been confirmed by Bob. The contract then allows Bob to respond within a period of time by submitting the next state to the contract; If Bob responds, the two can continue to trade in the state channel; If Bob does not respond within that time period, the contract automatically closes the state channel and returns the funds to Alice.

3.1.4 Advantages and Disadvantages

Advantages:

• Instantaneity: Transactions are completed almost instantly.
• High throughput: theoretically infinitely scalable
• Low cost: off-chain transactions have almost no cost
• Privacy: Interaction on-chain is only required when opening and closing the channel.

Disadvantages:

• Low capital efficiency: funds need to be locked.
• Online Requirement: Participants need to stay online continuously.
• Limited application scenarios: more suitable for frequent interactions among fixed participants
• The complexity of channel closure and dispute resolution
• Channel network liquidity issues

3.1.5 Application

Bitcoin Lightning Network:

Overview: The Lightning Network is a small payment channel on the Bitcoin network, and its overall technological evolution has experienced: the construction of unidirectional payment channels with 2-of-2 multi-signature, the addition of RSMC allows for the construction of bidirectional payment channels, and with the addition of HTLC, payment channels can be connected to expand to multi-party payments, ultimately forming a payment network known as the Lightning Network. Through off-chain small payment channels, and then leveraging intermediaries to form a transaction network, it can solve the scalability problem of the Bitcoin network. The overall usage of the Lightning Network follows the process of "Deposit ( to establish channel ) → Lightning Network transaction ( update channel status ) → Refund/Settlement ( end channel )"; theoretically, the Lightning Network can handle one million transactions per second.

Timeline:

• In February 2015, Joseph Poon and Thaddeus Dryja released a draft of the Lightning Network white paper.
• The official version of the white paper was released in January 2016 and Lightning Labs was established.
• On March 15, 2018, Lightning Labs released the first mainnet version of the Lightning Network, LND version 0.4.
• At the beginning of 2021, the public capacity of the Lightning Network was only about $40 million, with approximately less than 100,000 users.
• In June 2021, El Salvador announced the adoption of Bitcoin as legal tender, and in September, it launched the Chivo wallet based on the Lightning Network.
• In 2022, Cash App and 26 cryptocurrency exchanges including OKX, Kraken, and Bitfinex announced support for the Lightning Network.
• In October 2022, Lightning Labs released the new protocol Taro protocol( alpha version) based on Taproot, which is currently being tested on the testnet.
• On November 23, 2022, the Lightning Network had a total of 76,236 payment channels, with channel funds of 5049 $BTC($81.8M)

Ecological Development: The BTC 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: Individuals and businesses can run software programs that connect to the Lightning Network, with the largest market share held by Lightning Labs.
• Node and liquidity services: Because it is relatively complex for users to run their own nodes independently, it is necessary to provide a user-friendly interface to help manage Lightning payment channels.

On top of the core infrastructure are various payment and financial services as well as applications, such as Strike built on the LND solution that allows users to buy and sell BTC, use BTC to tip creators on Twitter, and enable Shopify merchants to accept BTC, among others.

As of November 2022,