Off-chain Scalability Depth Analysis

Author: Cobo Ventures

1. The Necessity of Expansion

The future vision of blockchain is decentralization, security, and scalability, but usually only two of these can be achieved, which is known as the blockchain trilemma. For years, people have been exploring how to solve this problem, how to improve the throughput and transaction speed of blockchain while ensuring decentralization and security, that is, addressing the scalability issue, which is one of the hot topics in the current blockchain development process.

Definition of 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, 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 process a large number of transactions.

The first significant hard fork of the Bitcoin network originated from the scaling issue. As the number of users and transaction volumes increased, the Bitcoin network, with a block size limit of 1MB, began to face congestion problems; starting in 2015, the Bitcoin community had disagreements over scaling issues, with one side supporting the expansion of block sizes and the other side supporting the use of the Segregated Witness (Segwit) proposal for smaller blocks. On August 1, 2017, the scaling faction independently developed a client system with a size of 8MB, leading to the first significant hard fork in Bitcoin's history and the birth of the new cryptocurrency BCH.

The Ethereum network has also chosen to sacrifice some 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 by setting a cap on the gas fee that a single block can accommodate, but the goal is still to achieve trustless consensus and ensure the broad distribution of nodes.

Since the emergence of CryptoKitties in 2017, the DeFi summer, and later the rise of on-chain applications such as GameFi and NFTs, the market's demand for throughput has been continuously increasing. However, even the Turing-complete Ethereum can only process 15-45 transactions per second ( TPS ), leading to rising transaction costs, longer settlement times, and most Dapps struggling to bear operating costs. The entire network has also become slow and expensive for users, making the blockchain scalability issue urgent to solve. The ideal scalability solution is to improve the transaction speed and throughput of the blockchain network as much as possible 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 scaling

Core concept: A solution to achieve scaling effects 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 but briefly list two solutions:

• Option one is to expand block space, that is, to increase the number of transactions packed in each block, but this will raise the requirements for high-performance node devices, increase the entry threshold for 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 bookkeeping, different shards, or different nodes, are responsible for different bookkeeping. Parallel computing can process 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 computing power of the network is dispersed, which may reduce the "security" of the entire network.

Changing the code of a layer 1 mainnet protocol can have unpredictable negative consequences, 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. For example, the Zcash inflation bug incident 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 that allowed tokens to be minted infinitely. The team then spent 8 months secretly patching the issue and only disclosed the incident after the bug 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:

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 the channel is opened, closed, or to resolve disputes, and that interactions between users are conducted off-chain, thus 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 in the channel, verifies state updates, and arbitrates disputes between participants based on fraud proofs with signatures and timestamps. After the participants deploy the contract on the blockchain network, they deposit a sum of funds and lock it; after 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, 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 the event of a dispute or when closing the channel. When it is necessary to close the channel, either participant can submit a transaction request on the mainnet. 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 have not signed 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 computational load on the mainnet, 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 systematically summarized the concept of State Channel for the first time, proposing 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 scalability solution for the Bitcoin Lightning Network Payment Channel) payment channel(, which is used solely 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 very detailed design for Generalized State Channels, which is the first design completely 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.

• March 2020, Hydra proposed Fast Isomorphic Channels.

)# 3.1.3 Technical Principles

Figure 1 shows the workflow on a traditional chain: Alice and Bob interact with a smart contract deployed on the mainnet, and users change the state of the smart contract by sending transactions to the chain. The downside is that it brings the time and cost issues discussed above.

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

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 to 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 to confirm, the state channel between them is officially opened.

• In the second step, 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 three, 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 and approves, the contract will release the locked funds back to the corresponding user based on 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.

Figure 3 shows the workflow of a state channel under pessimistic circumstances: initially, the two participants deposit funds ( interaction 1, 2), and then start exchanging state updates ( blue dashed line ). Suppose at a certain point in time, 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 has received Bob's approval and the final state has been confirmed by Bob. Then, the contract allows Bob to respond within a certain 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).

(# 3.1.4 Advantages and Disadvantages

Advantages:

• Instantaneous Certainty
• Extremely low fees
• Good privacy
• High scalability
• Strong flexibility

Disadvantages:

• All parties need to be continuously online
• Not suitable for complex calculations
• The initial cost of establishing a channel is high.
• Poor scalability
• Need to pre-store locked funds

)# 3.1.5 Application

Bitcoin Lightning Network

Overview:

The Lightning Network is a micropayment channel on the Bitcoin network, and its overall technological evolution has gone through: 2/2 multi-signature to build a unidirectional payment channel, then adding RSMC( Revocable Sequence Maturity Contract) allows for the construction of a bidirectional payment channel, and after adding HTLC### Hash Time Lock Contract###, it can connect payment channels to expand to multi-party payments, ultimately constructing the payment network known as the Lightning Network. By utilizing off-chain micropayment channels, and then forming a transaction network through intermediaries, it can solve the scalability problem of the Bitcoin network. The overall use of the Lightning Network follows the process of "Deposit( 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, Lightning Network Daemon (LND) version 0.4.
• In early 2021, the public capacity of the Lightning Network was only about 40 million USD, with approximately less than 100,000 users using the Lightning Network.