Off-chain Scalability Depth Analysis

1. The Necessity of Scalability

The future of blockchain is a grand vision: decentralization, security, and scalability; however, blockchain can typically only achieve two of these, and meeting all three requirements is known as the blockchain trilemma. For many years, people have been exploring how to solve this dilemma, specifically how to improve the throughput and transaction speed of blockchain while ensuring decentralization and security, which is one of the hot topics currently discussed in the development 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 verification of the blockchain system. The more nodes there are, the higher the degree of decentralization, thus ensuring that the network is not controlled by a small group of large centralized participants.
• Security: The higher the cost required to gain control of the blockchain system, the higher the security, allowing the chain to resist attacks from a larger proportion of participants.
• Scalability: The ability of a blockchain to handle a large volume of transactions.

The first significant hard fork of the Bitcoin network was due to scalability issues. 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 in the Bitcoin community regarding scalability issues. One side, represented by Bitcoin ABC, supports expanding the block size, while the other side, represented by Bitcoin Core, advocates for the use of the Segwit solution to optimize the main chain structure. On August 1, 2017, Bitcoin ABC launched its client system developed to 8MB, leading to the first significant hard fork in Bitcoin's history and the birth of the new cryptocurrency BCH.

Similarly, the Ethereum network also chooses to sacrifice a portion of 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 has instead indirectly transformed into setting a cap on the gas fees that a single block can accommodate, but the purpose is still to achieve Trustless Consensus and ensure the broad distribution of nodes. Whether to remove or raise the cap will eliminate many smaller nodes that lack sufficient bandwidth, storage, and computing power.

Since the rise of on-chain applications such as CryptoKitties in 2017, DeFi summer, and later GameFi and NFTs, the market's demand for throughput has been continuously increasing. However, even Turing-complete Ethereum can only handle 15 to 45 transactions per second ( TPS ), resulting in increased transaction costs, longer settlement times, and making it difficult for most Dapps 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 improve the transaction speed of the blockchain network ( shorter finality time ) and 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 scalability by changing a layer of the mainnet protocol, with the current main solution being sharding.

There are various solutions for on-chain scalability, and this article will not elaborate on them. Below are two solutions briefly listed:

• Option one is to expand the block space, which means increasing the number of transactions packaged in each block, but 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 the accounting, different shards, or different nodes, are responsible for different accounting, allowing for parallel computing that can handle multiple transactions simultaneously. This can reduce the computing pressure on nodes and lower the entry threshold, thereby improving transaction processing speed and the degree of decentralization. However, this means that the overall network's computing power is distributed, which may reduce the "security" of the entire network.

Changing the code of a layer one mainnet protocol can have unpredictable negative effects, as any subtle security flaws in the underlying system can seriously threaten the security of the entire network, which may be forced to fork or undergo emergency repair upgrades. For example, the inflation bug incident of Zcash in 2018: Zcash's code was modified from Bitcoin version 0.11.2, and in 2018, an engineer discovered a high-risk vulnerability in its underlying code, which allowed for unlimited token issuance. The team then spent 8 months secretly patching it, and only after the fix was implemented did they disclose the incident.

) 2.2 off-chain scaling

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

The off-chain expansion 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-7d930821d982f99c43cf5400e4db2175.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 mainnet when opening, closing, or resolving disputes in the channel, and that interactions between users are conducted off-chain, thereby reducing the time and monetary costs of user transactions, and allowing for an unlimited number of transactions.

State channels are simple P2P protocols suitable for "turn-based applications", such as a two-person 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 a sum of funds and lock it in; once both parties sign to confirm, the channel is officially opened. The channel allows for unlimited off-chain free transactions ( between participants 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, awaiting the other'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 the event of a dispute or when closing the channel. When the channel needs to be closed, any participant can propose a transaction request on the mainnet, and if the exit request receives unanimous signature approval, it is executed immediately on-chain, meaning the smart contract distributes the remaining locked funds based on each participant's balance at the final state of the channel; if other participants do not approve with their signatures, 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 computational load on the main network, improve transaction speed, and lower transaction costs.

(# 3.1.2 Timeline

• In February 2015, Joseph Poon and Thaddeus Dryja published a draft of the Lightning Network white paper.
• In November 2015, Jeff Coleman first systematically summarized the concept of State Channel and proposed that the Payment Channel of Bitcoin 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 a scaling solution for 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.
• In June 2018, 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 expanded 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 stay online continuously.
• 2020/03, Hydra proposed Fast Isomorphic Channels.

3.1.3 Technical Principles

Figure 1 shows the workflow on a 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 chain. The disadvantage is that it brings the time and cost issues discussed above.

Figure 2 shows the general workflow that most state channel protocols follow: 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 EOA 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 is returned to the users; after both parties sign to confirm, the state channel between them is officially opened.
• Step 2, Alice and Bob can theoretically conduct unlimited off-chain transactions through the channel ) blue dashed line (, 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 states and accept the updates proposed by each other.
• Step 3: If Alice wants to close the channel and end the transaction with Bob, Alice needs to submit the final state of her account ) interaction 3( to the contract. If Bob signs to approve, the contract will release the locked funds back to the corresponding user according to the final state ) interaction 4,5(. 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 Scalability])https://img-cdn.gateio.im/webp-social/moments-ead28de03be9fc22dcfe3f679ee36bc5.webp(

Figure 3 shows the workflow of the state channel in a pessimistic scenario: initially, two participants deposit funds ) interaction 1, 2(, and then begin exchanging 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 time, Alice can initiate a challenge by submitting her last valid state to the contract ) interaction 4(, which also includes Bob's previous signature, thus proving that the last transaction has received Bob's approval, and the final state has been confirmed by Bob. Then, the contract allows Bob to respond within a period by submitting the next state to the contract; if Bob responds, the two can continue trading within the state channel; if Bob does not respond within that time frame, the contract automatically closes the state channel and returns the funds to Alice ) interaction 5(.

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

)# 3.1.4 Advantages and Disadvantages

Advantages:

• Instantaneity: off-chain transactions can be confirmed immediately without waiting for block confirmation.
• High throughput: Interaction with the main network is only required when the channel opens and closes, greatly improving throughput.
• Low cost: off-chain transactions do not require paying miner fees, only a small fee is needed when opening and closing the channel.
• Privacy: Off-chain transaction details will not be recorded on the chain, only the final status will be submitted to the mainnet.

Disadvantages:

• Complexity: The implementation and use of state channels are relatively complex.
• Liquidity Lock: Requires a certain amount of funds to be locked in advance.
• Online Requirement: Participants need to stay online to respond to the latest status
• Limited scope: Mainly applicable to scenarios where both parties interact frequently.

(# 3.1.5 Application

Bitcoin Lightning Network:

Overview: The Lightning Network is a micropayment channel for the Bitcoin network, and its overall technological evolution has undergone: 2/2 multi-signature construction of one-way payment channels.