Off-chain Scalability Depth Analysis

1. The Necessity of Scalability

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

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

• Decentralization: Anyone can become a node and 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 paid 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 number of transactions.

The first major hard fork of the Bitcoin network originated from 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; starting in 2015, there were disagreements within the Bitcoin community regarding scalability, with one side represented by Bitcoin ABC advocating for larger blocks, while the other side represented by Bitcoin Core, the small block faction, argued for optimizing the main chain structure using the Segwit solution. On August 1, 2017, the client system developed by Bitcoin ABC, with a capacity of 8MB, began operating, leading to the first major hard fork in Bitcoin's history, which also gave birth to 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 the transaction volume by restricting block size like the Bitcoin network, it has indirectly shifted to setting a cap on the gas fees that a single block can accommodate. However, the purpose is to achieve Trustless Consensus and ensure the widespread distribution of nodes. Whether the cap is removed or increased, it will eliminate many smaller nodes that lack sufficient bandwidth, storage, and computing power.

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 continuously increasing. However, even Ethereum, which is Turing complete, can only process 15 to 45 transactions per second ( TPS ). The result of this is that transaction costs continue to rise, settlement times extend, and most Dapps find it hard to bear operating costs. The entire network becomes 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 categorize the expansion plan into two main types: on-chain expansion and off-chain expansion, based on the criterion of "whether to change a layer of the mainnet."

( 2.1 on-chain scaling

Core concept: a solution that achieves 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 briefly listed two solutions:

• 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 devices, increase the entry threshold for nodes, and reduce the degree of "decentralization".

• Plan two is sharding, which divides the blockchain ledger into several parts, so that not every node participates in all bookkeeping, but rather different shards and different nodes are responsible for different bookkeeping. Parallel computing can handle multiple transactions simultaneously; this can reduce the computational pressure on nodes and the threshold for joining, improving transaction processing speed and the degree 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 lead to unpredictable negative impacts, as any subtle security vulnerabilities in the underlying layer can severely threaten the security of the entire network, which may be forced to fork or interrupt for repair upgrades. For example, the inflation vulnerability incident of Zcash in 2018: Zcash's code is modified from Bitcoin version 0.11.2, 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 the vulnerability, and only after the fix was completed did they disclose the incident.

) 2.2 off-chain scaling

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

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

• Layer2: State channels, sidechains, Plasma, Rollups

• Others: Validium, Volition

![Ten Thousand Characters 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 Summary

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 occur 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 the participants deploy the contract on the blockchain network, they deposit a sum of funds and lock it. 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, waiting for the other party's signature confirmation. Once the other party signs to confirm, this state update is considered complete. Normally, agreed state updates between both parties are not uploaded to the mainnet, and only rely on the mainnet confirmation in case of disputes or when closing the channel. When the channel needs to be closed, either participant can propose a transaction request on the mainnet, and 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 end of the "challenge period" to receive the remaining funds.

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

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

)# 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 the Payment Channel of Bitcoin is a sub-case within 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 a scalability 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 extended to N-Party Channels, with Nitro being the first protocol established based on this idea.

• In October 2019, Pisa expanded the concept of Watchtowers to address the issue of all participants needing to be continuously online.

• In March 2020, Hydra proposed Fast Isomorphic Channels.

)# 3.1.3 Technical Principles

The workflow of state channels is as follows:

1. Alice and Bob deposit funds from their personal EOA into an on-chain contract address, where the funds are locked in the contract and returned to the users only when the channel is closed; after both parties sign and confirm, the state channel between the two is officially opened.

2. Alice and Bob can theoretically conduct unlimited transactions off-chain through this channel, with participants communicating via 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 state 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 based on 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.

If at some point, Bob does not respond to the status update signature sent by Alice during his turn, Alice can initiate a challenge by submitting her last valid state to the contract, which also includes Bob's previous signature, thereby proving that the last transaction has been approved by Bob 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 to transact 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.

![Ten Thousand Words 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: Status updates are almost instantaneous, with no need to wait for block confirmation.
• Privacy: Only the final state will be on-chain, intermediate states are private.
• Scalability: Theoretically can be infinitely scalable as long as the participants' funds are sufficient.
• Low cost: off-chain transactions do not require gas fees.

Disadvantages:

• Low capital efficiency: funds need to be locked
• Online Requirement: Participants need to continuously monitor online
• Long exit time: Need to wait for the challenge period when closing the channel.
• Dependence on centralized nodes: requires third-party monitoring services ) such as Watchtowers (
• Status explosion: N users need N)N-1###/2 channels
• Limited liquidity: Funds are locked within a specific channel.

(# 3.1.5 Application

Bitcoin Lightning Network

Overview: The Lightning Network is a micropayment channel on the Bitcoin network, and its overall technological evolution includes: the construction of unidirectional payment channels via 2/2 multi-signatures, the ability to construct bidirectional payment channels after adding RSMC) Revocable Sequence Maturity Contract(, and further extending payment channels to multiple participants after adding HTLC) Hash Time Lock Contract###, ultimately forming the payment network known as the Lightning Network. Through off-chain micropayment channels, and by leveraging intermediaries to form a transaction network, it can address the scalability issues of the Bitcoin network. The overall use of the Lightning Network follows the process of "Deposit( Establish Channel) → Lightning Network Transaction( Update Channel State) → 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.
• At the beginning of 2021, the public capacity of the Lightning Network was only about 40 million USD, with around 100,000 users using the Lightning Network.
• June 2021, Salvador