Off-chain Scalability Depth Analysis

Authors: Ellaine Xu, Hettie Jiang, June Wang, Walon Lin, Yiliu Lin

1. The Necessity of Scaling

The future of blockchain is a grand vision: decentralization, security, and scalability; however, blockchain can typically only achieve two of these at a time, and meeting all three requirements is referred to as the blockchain's impossible triangle problem. For years, people have been exploring how to solve this dilemma, how to increase blockchain's throughput and transaction speed while ensuring decentralization and security, which is to address the scalability issue, and this has become one of the hot topics of discussion in the current development process of blockchain.

Let us 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, thereby ensuring that the network is not controlled by a small group of large centralized participants.
• Security: The higher the cost to gain control of the blockchain system, the higher the security, which allows the chain to 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 scalability issues. As the number of Bitcoin users and transaction volumes increased, the Bitcoin network, with a block size limit of 1MB, began to face congestion issues; since 2015, there have been disagreements within the Bitcoin community regarding scalability. One side, represented by Bitcoin ABC, supports expanding the block size, while the other side, represented by Bitcoin Core, believes that the Segregated Witness (Segwit) solution should be used to optimize the main chain structure. On August 1, 2017, the Bitcoin ABC client system, developed to 8MB, began operating, leading to the first significant hard fork in Bitcoin's history, and thus giving birth to a new cryptocurrency, BCH.

Similarly, the Ethereum network has also chosen to sacrifice some scalability in order 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 effectively transformed into setting a cap on the fuel fees that a single block can accommodate, but the goal is still to achieve Trustless Consensus and ensure the widespread distribution of nodes. Regardless of whether the cap is removed or increased, many smaller nodes with insufficient bandwidth, storage, and computing power will be eliminated.

From the 2017 CryptoKitties, DeFi summer, to the later rise of on-chain applications like GameFi and NFTs, the market's demand for throughput has been increasing. However, even Turing-complete Ethereum can only process 15~45 transactions per second ( TPS ), resulting in continuously 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 of the blockchain network ( shorter finality time ) and transaction throughput ( higher TPS ) without sacrificing decentralization and security.

2. Types of Scalability Solutions

We classify the scaling solutions into two main categories: on-chain scaling and off-chain scaling based on the criterion of "whether to change a layer of the main network."

( 2.1 on-chain scaling

Core concept: A solution to achieve scalability by changing a layer of the main network 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, that is, to increase the number of transactions packed in each block. However, this will raise the requirements for high-performance node devices, increase the entry threshold for nodes, and reduce the level of "decentralization."
• Option two is sharding, which divides the blockchain ledger into several parts, where not every node participates in all accounting. Instead, different shards, or different nodes, are responsible for different accounting, allowing parallel computation to handle multiple transactions simultaneously; this can reduce the computational pressure on nodes and lower the barrier to entry, improving transaction processing speed and the degree of decentralization. However, this means that the overall network's computing power is distributed, which can reduce the "security" of the entire network.

Changing the code of a layer 1 mainnet protocol can have unpredictable negative effects, as any slight security vulnerabilities in the underlying layer can severely threaten the security of the entire network, which may be forced to undergo a fork or interrupted repair upgrade. 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 critical vulnerability in its underlying code, which allowed for unlimited token issuance. The team then spent 8 months secretly patching it, and only revealed the incident after the vulnerability was fixed.

) 2.2 off-chain scaling

Core Concept: Scalability solutions that do not alter the existing layer 1 mainnet protocol.

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

![Ten Thousand Character 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 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-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 a sum of funds and lock it in. Once both parties sign to confirm, the channel is officially opened. The channel allows 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; only in the event of a dispute or when closing the channel will the mainnet confirmation be relied upon. When needing 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 on-chain immediately, meaning the smart contract distributes the remaining locked funds based on each participant's balance in the final state of the channel; if other participants do not provide signature approval, everyone must wait for the "challenge period" to end before receiving 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 Channel for the first time, proposing that Payment Channel in Bitcoin is a sub-case of the concept of State Channel.
• 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 for the Bitcoin Lightning Network Payment Channel### payment channel(, which is only used for handling 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.
• June 2018, Counterfactual proposed a very detailed Generalized State Channels design, which is the first design fully related to state channels.
• 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 be continuously online.
• 2020/03, Hydra proposed Fast Isomorphic Channels.

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

)# 3.1.3 Technical Principles

The general workflow of state channels is as follows:

1. Alice and Bob deposit funds from their personal EOAs into the on-chain contract address, where 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.

2. Alice and Bob can theoretically conduct an unlimited number of transactions off-chain through this channel, with participants communicating with each other using 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 the other party.

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 to approve, 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.

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

)# 3.1.4 Advantages and Disadvantages

Advantages:

• Fast transaction speed, almost instant confirmation
• Extremely low transaction fees
• High throughput, theoretically unlimited number of transactions
• Good privacy, only the final state is on-chain

Disadvantages:

• Need to lock up funds
• All participants need to be online continuously.
• Channel capacity is limited
• Establishing and closing channels requires transaction fees.
• Complex smart contracts are difficult to implement
• Liquidity issues

3.1.5 Application

Bitcoin Lightning Network

Overview: The Lightning Network is a micropayment channel of the Bitcoin network, and its overall technological evolution has undergone: 2/2 multi-signature construction of unidirectional payment channels, after adding RSMC, can construct bidirectional payment channels, and after adding HTLC, can connect payment channels to expand to multi-party payments, ultimately constructing a payment network, namely the Lightning Network. Through off-chain micropayment 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 ( establish channel ) → Lightning Network transaction ( update channel status ) → Refund / Settlement ### end channel ###"; theoretically, the Lightning Network can process 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, with approximately less than 100,000 users using the Lightning Network.
• In June 2021, El Salvador announced the adoption of Bitcoin as legal tender, and in September, the Chivo wallet based on the Lightning Network was released.
• In 2022, Cash App and 26 cryptocurrency exchanges including OKX, Kraken, and Bitfinex announced support for the Lightning Network, enabling instant and cheap BTC deposits, withdrawals, and transfers.
• In October 2022, Lightning Labs released a new protocol based on Taproot — Taro protocol( alpha version), which is currently being tested on the testnet and will eventually be used for minting, sending, and receiving assets on the Bitcoin network, as well as through the Lightning Network.