off-chain Expansion Depth Analysis

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 referred to as the impossible triangle problem of blockchain. For years, people have been exploring how to solve this dilemma, improving the throughput and transaction speed of the blockchain while ensuring decentralization and security, namely addressing the scalability issue, which is one of the hot topics in the current development process of blockchain.

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

• 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 centralized participants.

• Security: The higher the cost required to gain control of 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 handle a large number of transactions.

The first major hard fork of the Bitcoin network stemmed from scalability issues. As the number of users and transaction volumes increased, the Bitcoin network, with a block size limit of 1MB, began to face congestion problems. Since 2015, there has been a division within the Bitcoin community regarding scalability; one side supports increasing the block size, while the other believes that the Segregated Witness solution should be used to optimize the main chain structure. On August 1, 2017, Bitcoin ABC's self-developed client system for 8MB blocks went live, leading to the first major hard fork of Bitcoin and the birth of a new cryptocurrency, BCH.

The Ethereum network also chooses to sacrifice a portion of scalability to ensure the security and decentralization of the network. Although it does not impose a block size limit like Bitcoin, it limits the transaction volume by restricting the gas fee that can be accommodated in a single block, aiming to achieve Trustless Consensus and ensure a wide distribution of nodes.

From CryptoKitties in 2017, to 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, leading to increased transaction costs and longer settlement times, making it difficult for most Dapps to bear operational costs, and the entire network has become slow and expensive for users. The blockchain scalability issue urgently needs to be addressed. The ideal scalability solution is to maximize the transaction speed and throughput of the blockchain network without sacrificing decentralization and security.

2. Types of Scalability Solutions

According to the standard of "whether to change a layer of the main network", the scalability solutions can be divided into two main categories: on-chain scalability and off-chain scalability.

2.1 On-chain Scaling

Core concept: A solution that achieves scalability by altering a layer of the mainnet protocol, with the current main approach being sharding.

There are various solutions for on-chain scalability, briefly listing two:

• Option one is to expand the block space and increase the number of transactions packaged in each block, but this will raise the requirements for high-performance node devices and reduce the degree of "decentralization."

• Option two is sharding, which divides the blockchain ledger into several parts, with different nodes responsible for different bookkeeping, 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 decentralization, but it may reduce the overall network's "security".

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 seriously threaten the security of the entire network, which may be forced to undergo a fork or interrupt for repair upgrades. For example, the 2018 Zcash inflation bug incident: Zcash's code is modified from Bitcoin version 0.11.2, and in 2018 an engineer discovered a high-risk vulnerability in the underlying code, which allowed for unlimited token issuance. The team then spent 8 months secretly patching it and only made the incident public after the vulnerability was fixed.

2.2 off-chain scaling

Core concept: Solutions for scaling without changing the existing Layer 1 mainnet protocol.

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

• Layer2: Building new layers on top of the main chain to handle most transactions and computations, interacting with the main chain only when necessary. Includes state channels, sidechains, Plasma, Rollups, etc.

• Other solutions: instead of building a new layer, scalability is achieved through other technical means, such as Validium, Volition, etc.

3. Off-chain scaling solutions

3.1 State Channels

3.1.1 Summary

State channels stipulate that users only need to interact with the mainnet when opening, closing, or resolving disputes in the channel, allowing interactions between users to take place off-chain, thereby reducing the time and monetary costs of transactions and enabling unlimited transaction frequency.

State channels are simple P2P protocols suitable for "turn-based applications," such as two-player chess games. 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, and 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 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 case of a dispute or when closing the channel will they depend on the mainnet for confirmation. When the channel needs to be closed, either participant can raise 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 at 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, state channel solutions can greatly 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 released a 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 a scaling solution for the Bitcoin Lightning Network, 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 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 be continuously online.

• 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 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 Scalability]###https://img-cdn.gateio.im/webp-social/moments-ead28de03be9fc22dcfe3f679ee36bc5.webp(

Figure 2 shows the general workflow followed by most state channel protocols: in an optimistic case, Alice and Bob need to perform the same operation 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 and will only be returned to the users when the channel is closed; after both parties sign and confirm, the state channel between them is officially opened.

• In the second step, Alice and Bob can theoretically conduct an unlimited number of 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 state updates proposed by the other party.

• 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 ) interaction 4,5( 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 Character Depth Research Report: Comprehensive Analysis of Off-Chain Scalability])https://img-cdn.gateio.im/webp-social/moments-ad088ac016d75b1ae0b0eda699e74709.webp(

Figure 3 shows the workflow of the state channel in a pessimistic scenario: Initially, the two participants deposit funds ) interaction 1, 2(, and then start exchanging state updates ) blue dashed line (. Suppose at some point, Bob does not respond to the state update signature sent by Alice in 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 contains Bob's previous signature, thus 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 trading 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 Characters Depth Research Report: Comprehensive Analysis of off-chain Scaling])https://img-cdn.gateio.im/webp-social/moments-815c5eb2bdba725e04eebe67b22d42aa.webp(

)# 3.1.4 Advantages and Disadvantages

Advantages:

• Instant confirmation of transactions
• High Throughput
• Low transaction costs
• Good privacy

Disadvantages:

• Need to lock funds
• All participants need to be online in real-time.
• Withdrawals are delayed
• High initialization cost of the channel
• Trouble reopening the channel
• The complexity of the channel network is high

3.1.5 Application

Bitcoin Lightning Network

Overview: The Lightning Network is a micropayment channel on the Bitcoin network. Its overall technological evolution has gone through: constructing one-way payment channels with 2/2 multi-signature, adding RSMC### Revocable Sequence Maturity Contract( to build two-way payment channels, and further adding HTLC) Hash Time Lock Contract( to connect payment channels to extend to multi-party payments, ultimately building the payment network, which is the Lightning Network. Through off-chain micropayment channels, and then utilizing 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) establishing channels( → Lightning Network transactions) updating channel status( → Refund/settlement) ending channels("; 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 Daemon )LND( version 0.4.
• In early 2021, the public capacity of the Lightning Network )TVL( was only about 40 million USD, with approximately less than 100,000 users utilizing the Lightning Network.
• In June 2021, El Salvador announced the adoption of Bitcoin as legal tender.