Cobo Ventures: In-Depth Analysis of Off-Chain Scaling
TechFlow Selected TechFlow Selected
Cobo Ventures: In-Depth Analysis of Off-Chain Scaling
How to improve blockchain throughput and transaction speed while ensuring decentralization and security?
Navigating Web3 tides with focused insightsAuthors (in alphabetical order): Ellaine Xu, Hettie Jiang, June Wang, Walon Lin, Yiliu Lin
Table of Contents
1. The Need for Scalability
2. Categories of Scaling Solutions
3. Off-Chain Scaling Solutions
4. Summary and Outlook
1. The Need for Scalability
The future of blockchain is an ambitious vision: decentralization, security, and scalability; however, typically only two out of the three can be achieved simultaneously. This limitation is known as the "impossible trilemma" of blockchain (as shown in the diagram below).
For years, researchers have been exploring ways to resolve this dilemma—how to improve throughput and transaction speed while maintaining decentralization and security. Solving scalability has become one of the most discussed topics in the current development of blockchain.
Let us broadly define decentralization, security, and scalability in the context of blockchain:
-
Decentralization: Anyone can become a node to participate in the production and validation of the blockchain system. The greater the number of nodes, the higher the degree of decentralization, ensuring the network is not controlled by a small group of centralized participants.
-
Security: The higher the cost required to gain control over the blockchain system, the higher the security level. A secure chain can resist attacks from a large proportion of malicious participants.
-
Scalability: The ability of a blockchain to process a large volume of transactions.
Bitcoin's first major hard fork stemmed from scalability issues. As Bitcoin's user base and transaction volume grew, the 1MB block size limit began causing congestion on the network. Starting in 2015, the Bitcoin community was divided on scaling solutions: one side, represented by Bitcoin ABC, advocated increasing the block size, while the other, represented by Bitcoin Core, favored Segregated Witness (SegWit) to optimize the main chain structure. On August 1, 2017, Bitcoin ABC launched its own 8MB client, resulting in Bitcoin’s first significant hard fork and the birth of a new cryptocurrency, BCH.
Similarly, Ethereum chose to sacrifice some scalability to preserve network security and decentralization. Although Ethereum does not limit block size like Bitcoin, it instead caps the gas per block. The goal remains the same: achieving trustless consensus and ensuring broad node distribution (removing or raising limits would eliminate many smaller nodes with limited bandwidth, storage, and computational capacity).
From CryptoKitties in 2017, DeFi summer, to the rise of GameFi and NFTs, demand for higher throughput has continuously increased. Yet even Turing-complete Ethereum can only handle 15–45 transactions per second (TPS). This results in rising transaction costs, longer settlement times, unaffordable operating expenses for most DApps, and a slow and expensive experience for users. Scalability is thus urgently needed. The ideal scaling solution should increase transaction speed (shorter finality time) and throughput (higher TPS) without sacrificing decentralization and security.
2. Categories of Scaling Solutions
We categorize scaling solutions into on-chain scaling and off-chain scaling, based on whether they alter Layer 1 (L1) protocols.
2.1 On-Chain Scaling
Core Concept: Achieving scalability by modifying L1 protocols. The primary approach today is sharding.
There are multiple on-chain scaling approaches, but we will briefly introduce two here:
-
Solution 1: Increase Block Size—increasing the number of transactions per block. However, this raises hardware requirements for nodes, increases entry barriers, and reduces decentralization.
-
Solution 2: Sharding—dividing the blockchain ledger into shards, where different nodes handle separate ledgers and perform parallel computation. This reduces node load and entry barriers, improving transaction speed and decentralization. However, network-wide computing power becomes fragmented, reducing overall network security.
Modifying L1 protocol code may lead to unforeseen consequences, as even minor vulnerabilities at the base layer could severely compromise network security, potentially forcing forks or emergency upgrades. For example, in 2018, Zcash discovered a critical inflation bug in its codebase—a copy of Bitcoin 0.11.2—which allowed unlimited minting. The team spent eight months secretly fixing it before disclosing the issue.
2.2 Off-Chain Scaling
Core Concept: Scaling solutions that do not modify existing L1 protocols.
Off-chain scaling can be further divided into Layer 2 and other solutions:
Note: Definitions in the table are sourced from the Ethereum Foundation website, content summarized by Cobo Ventures.
We will now introduce mainstream off-chain scaling solutions in terms of development timeline, technical principles, advantages/disadvantages, and application comparisons.
3. Off-Chain Scaling Solutions
3.1 State Channels
3.1.1 Overview
State channels require users to interact with the main chain only when opening, closing, or resolving disputes. User interactions occur off-chain, reducing transaction time and cost while enabling unlimited transactions.
State channels are simple peer-to-peer protocols suitable for "turn-based applications," such as a two-player chess game. Each channel is managed by a multi-signature smart contract on the main chain, which controls deposited assets, validates state updates, and arbitrates disputes using signed, timestamped fraud proofs. After deploying the contract and depositing funds, both parties sign to open the channel. Participants can conduct unlimited free off-chain transactions as long as net transfers do not exceed their deposited balances. Users exchange signed state updates; once confirmed, the update is finalized. Normally, agreed-upon states remain off-chain. Only during disputes or channel closure is the main chain involved. To close, any participant submits a withdrawal request on-chain. If all approve via signatures, funds are immediately released according to final balances. Otherwise, a "challenge period" must expire before withdrawals proceed.
In summary, state channels significantly reduce mainnet computation, enhance transaction speed, and lower costs.
3.1.2 Timeline
The above timeline highlights key milestones in the evolution of State Channels.
-
Feb 2015: Joseph Poon and Thaddeus Dryja release the Lightning Network whitepaper draft.
-
Nov 2015: Jeff Coleman systematically defines State Channel concepts, noting Bitcoin Payment Channels as a subset.
-
Jan 2016: Joseph Poon and Thaddeus Dryja publish “The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments,” introducing Payment Channels for Bitcoin payments.
-
Nov 2017: Sprites, a framework under Payment Channels, is proposed.
-
Jun 2018: Counterfactual proposes Generalized State Channels—the first fully dedicated design.
-
Oct 2018: “Generalised State Channel Networks” introduces Virtual Channels.
-
Feb 2019: Nitro introduces State Channels for N-party use.
-
Oct 2019: Pisa extends Watchtowers to address online availability.
-
Mar 2020: Hydra proposes Fast Isomorphic Channels.
3.1.3 Technical Principles
Source: L. D. Negka and G. P. Spathoulas, "Blockchain State Channels: A State of the Art" in IEEE Access, vol. 9, pp. 160277-160298, 2021, doi: 10.1109/ACCESS.2021.3131419.
Figure 1 shows traditional on-chain workflows: Alice and Bob interact directly with a smart contract deployed on the mainnet, changing its state via transactions. This incurs the time and cost drawbacks previously discussed.
Source: L. D. Negka and G. P. Spathoulas, "Blockchain State Channels: A State of the Art" in IEEE Access, vol. 9, pp. 160277-160298, 2021, doi: 10.1109/ACCESS.2021.3131419.
Figure 2 illustrates the general workflow followed by most state channel protocols: Optimistically, Alice and Bob execute the same operations as before but use a state channel instead of interacting directly with the on-chain contract.
Step 1: Alice and Bob deposit funds from their EOA addresses into the on-chain contract (interactions 1, 2), locking them until channel closure. After mutual signature confirmation, the channel opens.
Step 2: Alice and Bob conduct unlimited off-chain transactions (blue dashed lines). They communicate via encrypted signed messages (not with the blockchain). Both parties must sign each transaction to prevent double-spending. They propose and accept state updates through these messages.
Step 3: If Alice wants to close the channel, she submits her final state to the contract (interaction 3). If Bob approves via signature, funds are released (interactions 4, 5). If Bob doesn't respond, funds are released after the challenge period.
Source: L. D. Negka and G. P. Spathoulas, "Blockchain State Channels: A State of the Art" in IEEE Access, vol. 9, pp. 160277-160298, 2021, doi: 10.1109/ACCESS.2021.3131419.
Figure 3 shows the pessimistic workflow: Initially, both deposit funds (interactions 1, 2), then exchange state updates (blue dashed lines).
Suppose at some point Bob fails to respond to Alice's state update (interaction 3). Alice can then submit her latest valid state to the contract (interaction 4), including Bob’s prior signature proving approval. The contract allows Bob a window to respond with the next state. If he does, they continue within the channel. If not, the contract automatically closes the channel and returns funds to Alice (interaction 5).
3.1.4 Advantages and Disadvantages
3.1.5 Applications
- Bitcoin Lightning Network
Overview:
The Lightning Network is a micropayment channel for Bitcoin. Its technology evolved from 2-of-2 multisig unidirectional channels to bidirectional channels with RSMC (Revocable Sequence Maturity Contract), then to multi-party networks via HTLC (Hash Time-Locked Contracts). By creating off-chain payment channels connected via intermediaries, it solves Bitcoin’s scalability issues. The process follows: deposit (open channel) → Lightning Network transactions (update state) → refund/settlement (close channel). Theoretically, the Lightning Network can handle up to one million transactions per second.
Timeline:
-
February 2015: Joseph Poon and Thaddeus Dryja release the Lightning Network whitepaper draft.
-
January 2016: Official whitepaper published; Lightning Labs founded.
-
March 15, 2018: Lightning Labs launches the first mainnet version, LND 0.4.
-
Early 2021: Public capacity (~$40M TVL), fewer than 100,000 users.
-
June 2021: El Salvador adopts Bitcoin as legal tender; Chivo wallet based on Lightning Network launched in September.
-
2022: Cash App and 26 exchanges (including OKX, Kraken, Bitfinex) support Lightning Network for instant, low-cost BTC deposits, withdrawals, and transfers.
-
October 2022: Lightning Labs releases Taro Protocol (alpha) based on Taproot, currently testing. It will enable asset issuance, sending, receiving on Bitcoin, and high-volume, low-fee transactions via Lightning Network.
-
November 23, 2022: According to 1ml.com, 76,236 payment channels with 5,049 BTC (~$81.8M).
Ecosystem Development:
As shown above, the BTC Lightning ecosystem consists of: underlying BTC network → core infrastructure → various DApps.
Core Infrastructure includes:
-
Lightning Network Solutions: Software allowing individuals and businesses to run and connect to the Lightning Network. Lightning Labs holds the largest market share.
-
Node and Liquidity Services: Since running independent nodes is complex, user-friendly interfaces help manage Lightning payment channels.
Above core infrastructure are various payment, financial services, and applications. For example, Strike, built on LND, enables buying/selling BTC, tipping creators on Twitter, and Shopify merchants accepting BTC.
By November 2022, over 100 apps across more than 20 categories were built on Bitcoin Lightning, including payments, wallets, node management, browser extensions, podcasts, and streaming. With mature node infrastructure, growing wallet support, expanding payment integration, and emerging entertainment apps, the Lightning Network ecosystem is thriving.
- Ethereum Raiden Network
Overview:
Raiden Network is a micropayment channel for Ethereum, very similar to the Lightning Network. It uses state channels to extend on-chain transactions, aiming for near-instant, low-cost, scalable ERC20 token payments on Ethereum.
Timeline:
-
2017: Founded by Heiko Hees, former Ethereum core developer and advisor.
-
October 17, 2017: ICO via Dutch auction raised over $30M for $RDN token.
-
May 2020: First Raiden Light Client - Alderaan launched on Ethereum mainnet—an implementation in Typescript.
-
End of 2021: Due to prolonged lack of progress, disclosure, and user adoption, multiple exchanges delisted $RDN, including Bitkub, NiceHash, and Binance.
Reasons for limited adoption:
1) High entry barrier: High Ethereum gas fees make opening channels costly.
2) Emergence of superior scaling tech: Raiden was developed starting in 2015 as Ethereum’s sole scaling option. Now better solutions like Rollups exist, limiting Raiden’s use cases.
Ecosystem Development:
Currently, Raiden’s ecosystem develops slowly. The team is rebuilding Raiden to operate on Ethereum L2 Rollup networks, lowering Gas fees for creating State Channels. In May 2022, Raiden announced deployment on Arbitrum, becoming a rollup-native protocol—a Layer 2 running atop another Layer 2. This reduced initial channel creation costs by 35%, making it suitable for high-frequency micropayments. Raiden plans to transition toward Rollups, serving as a complementary coexisting solution.
- Celer Network
Overview:
Celer Network is essentially Lightning Network enhanced with an incentive layer ($CELR token), using off-chain expansion and economic models to build fast, easy-to-use, low-cost, secure blockchain DApps for high-interaction applications like esports platforms. Frequent entry fee and prize payout demands suit state channel technology perfectly.
Imagine Alice and Carl playing a chess game via a state channel. Both deposit funds into a mainnet-deployed channel. An off-chain contract governs game rules and is referenced conditionally in payments (e.g., “If the contract determines Carl wins, Alice pays him $1”). Each off-chain contract has a unique off-chain address, only deployed on-chain if needed, assigned an on-chain address via an internal off-chain address translator (OAT). All game state transitions (account balances), signed by both parties, occur off-chain and can be verified on-chain if disputed. Via Celer’s OAT, every off-chain address maps uniquely to an on-chain smart contract. Thus, as long as both cooperate without dispute, the entire game (contract + state) stays off-chain.
As shown above, Celer Network’s off-chain scaling framework comprises three layers:
-
cChannel: Suite of generalized state channels and sidechains
-
cRoute: Off-chain payment routing with innovative DBR (Distributed Balanced Routing) algorithm enhancing performance
-
cOS: Development framework and runtime environment for off-chain applications
Timeline:
-
2018: Founded by PhDs from MIT, Princeton, UC Berkeley, and UIUC.
-
March 2019: $CELR token launched on Binance Launchpad.
-
July 2019: Celer Network launched on Ethereum mainnet, releasing the world’s first Generalized State Channel Network. Simultaneously, esports platform CelerX launched on iOS and Android—the first L2 DApp enabling instant zero-fee payments via Celer Pay for skill-based games.
Ecosystem Development:
As the blockchain ecosystem evolves multi-chain, state channels gain new roles bridging L1 and L2. Celer Network expanded its core generalized state channel technology into a cross-chain L2 scaling aggregation platform. Current products include DeFi protocol Layer2.finance, cross-chain messaging protocol Celer IM, and asset bridge cBridge. cBridge supports up to 139 tokens and 38 chains.
On November 11, 2022, MetaMask Bridges Beta integrated cBridge. On November 17, cBridge reached 1M total transactions and simultaneously announced integration with zkSync 2.0 testnet.
3.1.6 Application Comparison
3.2 Sidechains
3.2.1 Overview
The concept of sidechains was first mentioned in 2012 in a Bitcoin developers’ chat room. The first paper on Bitcoin sidechains was written by a Blockstream researcher and published in 2014.
The 2014 paper proposed sidechains as a blockchain variant designed to accelerate Bitcoin transactions, supporting more complex contracts or improved consensus mechanisms (like PoS), or optimized block parameters for specific purposes. Sidechains ultimately record transaction results back onto the main chain via validators. This model isn’t a new blockchain type but rather foundational infrastructure attached to and assisting the main chain.
3.2.2 Timeline
-
Jan 2012: Sidechain concept introduced in chat room
-
Oct 2014: First Bitcoin sidechain paper published: Symmetric Pegged and Asymmetric Pegged
-
Apr 2017: POA Network, a Proof-of-Authority sidechain for Ethereum, launched testnet
-
Oct 2017: Matic Network launched
-
Dec 2017: POA Network mainnet launched
-
Jan 2018: Skale testnet launched
-
Oct 2018: xDai Chain testnet launched
-
Jun 2020: Skale mainnet launched
-
Jun 2020: Ethereum
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
Cobo
