"Off-chain Scalability Depth Analysis"

Author: Research Team

1. The Necessity of Expansion

The future of blockchain is a grand vision: decentralization, security, and scalability; however, blockchain can usually only achieve two of these, and meeting all three requirements is known as the blockchain trilemma. For years, people have been exploring how to solve this problem, focusing on how to increase the throughput and transaction speed of blockchain while ensuring decentralization and security, which means addressing scalability issues, and this is one of the hot topics discussed in the current development process of blockchain.

Let's first broadly define the decentralization, security, and scalability of blockchain:

• Decentralization: Anyone can become a node to participate in the production and validation of the blockchain system. The more nodes there are, the higher the degree of decentralization, thereby ensuring that the network is not controlled by a small group of large centralized participants.
• Security: The higher the cost incurred to gain control of the blockchain system, the greater the security, which allows the chain to 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 Bitcoin users and transaction volume increased, the Bitcoin network, with a block size limit of 1MB, began to face congestion problems; since 2015, there have been disagreements within the Bitcoin community regarding scalability issues. One side, represented by Bitcoin ABC, supports increasing the block size, while the other side, represented by Bitcoin Core, believes that the Segregated Witness (Segwit) proposal should be used to optimize the main chain structure. On August 1, 2017, Bitcoin ABC launched its client system, developed to 8MB, resulting in the first major hard fork in Bitcoin's history, which also led to the birth of the new cryptocurrency BCH.

Similarly, the Ethereum network has also chosen to sacrifice a portion of its scalability to ensure the security and decentralization of the network; although the Ethereum network does not limit transaction volume by restricting block size like the Bitcoin network, it effectively transforms this into setting a cap on the gas fees that can be accommodated in a single block, but the goal is to achieve Trustless Consensus and ensure a wide distribution of nodes. Regardless of whether the cap is removed or increased, many smaller nodes with insufficient bandwidth, storage, and computational power will be eliminated.

Since the emergence of on-chain applications such as CryptoKitties in 2017, DeFi summer, and later GameFi and NFTs, the market's demand for throughput has been increasing. However, even the Turing-complete Ethereum can only process 15 to 45 transactions per second ( TPS ), resulting in rising transaction costs, longer settlement times, and making it difficult for most Dapps to bear operating 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 of the blockchain network ( shorter finality time ) and higher transaction throughput ( higher TPS ) without sacrificing decentralization and security.

2. Types of Scalability 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 Scalability

Core concept: A solution to achieve scaling effects by altering a layer of the mainnet protocol, with the current main proposal being sharding.

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

• Option one is to expand the block space, which means increasing the number of transactions packed in each block. However, this will raise the requirements for high-performance node equipment, increase the threshold for joining nodes, and reduce the degree of "decentralization".
• Option two is sharding, which divides the blockchain ledger into several parts. Instead of every node participating in all accounting, different shards, or different nodes, are responsible for different accounting. Parallel computing can handle multiple transactions simultaneously; this can reduce the computational pressure on nodes and lower the barrier to entry, improving transaction processing speed and the level of decentralization. However, this means that the total computing power of the network is dispersed, which may reduce the overall "security" of the network.

Changing the code of a layer 1 mainnet protocol can have unpredictable negative effects, as any slight security vulnerability in the underlying layer poses a serious threat to the overall security of the network, which may be forced to undergo a fork or interrupt for repair upgrades. For example, the inflation bug incident of Zcash in 2018: Zcash's code is modified from the Bitcoin version 0.11.2 code, and in 2018, an engineer discovered a critical vulnerability in its underlying code, namely that tokens could be minted infinitely. The team then spent 8 months secretly patching it, and the incident was only made public after the vulnerability was fixed.

) 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 Layer 2 and other solutions:

![Ten Thousand Words Depth Research Report: Comprehensive Analysis of off-chain Scaling]###https://img-cdn.gateio.im/webp-social/moments-087d35594a04d33375b8199b93eb355e.webp###

3. off-chain Scaling Solutions

( 3.1 State Channels

)# 3.1.1 Overview

State channels stipulate that users only need to interact with the main network when the channel is opened, closed, or disputes are resolved, and that interactions between users are conducted off-chain, thereby reducing the time and monetary costs of user transactions and allowing for unlimited transaction frequency.

State channels are simple P2P protocols suitable for "turn-based applications," such as a two-player chess game. 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 ### based on fraud proofs with signatures and timestamps ###. After participants deploy the contract on the blockchain network, they deposit and lock in a sum of 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 their 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. Normally, state updates agreed upon by both parties are not uploaded to the mainnet; they only rely on the mainnet for confirmation in case of disputes or when closing the channel. When needing to close the channel, any participant can submit a transaction request on the mainnet; if the exit request receives unanimous signature approval, it is executed on-chain immediately, with the smart contract distributing the remaining locked funds based on each participant's balance in the final state of the channel; if other participants do not sign to approve, everyone must wait for the end of the "challenge period" to receive the remaining funds.

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

(# 3.1.2 Timeline

• In February 2015, Joseph Poon and Thaddeus Dryja released the draft of the Lightning Network white paper.
• In November 2015, Jeff Coleman systematically summarized the concept of State Channels 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 scalability solution of the Bitcoin Lightning Network, Payment Channel), which is used solely for handling transfer payments on the Bitcoin network.
• In November 2017, the first design specification for State Channels based on the Payment Channel framework, Sprites, was proposed.
• 2018/06, Counterfactual proposed a very detailed Generalized State Channels design, 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, 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 remain online.
• 2020/03, Hydra proposed Fast Isomorphic Channels.

3.1.3 Technical Principles

Figure 1 shows the workflow on the traditional chain: Alice and Bob interact with the smart contract 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 the time and cost issues discussed above.

Figure 2 illustrates the general workflow followed by most state channel protocols: in an optimistic scenario, Alice and Bob need to perform the same operations as before, but this time they use a state channel instead of interacting with an on-chain contract.

• Step 1, Alice and Bob interact by depositing funds from their personal EOAs into the on-chain contract address ###, 1,2(, these funds are locked in the contract until the channel is closed, at which point the balance will be returned to the users; after both parties sign and confirm, the state channel is officially opened between them.
• Step 2, Alice and Bob can theoretically conduct unlimited transactions off-chain through the channel ) blue dashed line (, and participants communicate with each other through encrypted signed messages ) instead of communicating with the blockchain network (. Both users need to sign each transaction to prevent double spending. Through these messages, they propose updates to their account status and accept updates proposed by the other party.
• Step 3: If Alice wants to close the channel and end the transaction with Bob, she needs to submit the final state of her account ) to the contract. If Bob signs and approves, the contract will release the locked funds according to the final state and return them to the corresponding user (. 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.

![Ten Thousand Character Depth Research Report: Comprehensive Analysis of Off-Chain Scaling])https://img-cdn.gateio.im/webp-social/moments-ad088ac016d75b1ae0b0eda699e74709.webp(

Figure 3 shows the workflow of a state channel in a pessimistic scenario: Initially, two participants deposit funds ) interaction 1, 2(, and then begin to exchange state updates ) blue dashed line (. Suppose at some point, Bob does not respond to the state update signature sent by Alice during his turn ) interaction 3(. At this point, Alice can initiate a challenge by submitting her last valid state to the contract ) interaction 4(, which also includes Bob's previous signature, thereby proving that the last transaction had received Bob's approval and the final state had received Bob's confirmation. The contract then allows Bob to respond by submitting the next state to the contract within a certain period; if Bob responds, the two can continue to transact within the state channel; if Bob does not respond within that period, the contract automatically closes the state channel and returns the funds to Alice ) interaction 5(.

![Ten Thousand Words Depth Report: Comprehensive Analysis of off-chain Scaling])https://img-cdn.gateio.im/webp-social/moments-815c5eb2bdba725e04eebe67b22d42aa.webp(

)# 3.1.4 Advantages and Disadvantages

Advantages:

• The transaction immediacy is strong, suitable for high-frequency small payments.
• Low transaction fees
• Strong privacy, off-chain transactions will not be public
• Strong scalability, theoretically infinite TPS

Disadvantages:

• Need to lock funds
• Confirmation on-chain is required when the channel is closed.
• Participants need to stay online
• Not suitable for large amount or low frequency trading
• There is a risk of fund theft

(# 3.1.5 Applications

Bitcoin Lightning Network

Overview:

The Lightning Network is a micropayment channel for the Bitcoin network. Its overall technological evolution has undergone: 2/2 multi-signature construction of one-way payment channels, which can be constructed into two-way payment channels after adding RSMC) Revocable Sequence Maturity Contract(, and then adding.