LD Research: A Comprehensive Guide to Ethereum Scaling Solutions
TechFlow Selected TechFlow Selected
LD Research: A Comprehensive Guide to Ethereum Scaling Solutions
What innovations and combinations have emerged in the development of Ethereum scaling? What challenges have been encountered?
Navigating Web3 tides with focused insights
Produced by: LD Capital Research
Author: 0xRJ_eth (Twitter: @0xRJ_eth)
Today’s article primarily organizes Ethereum scaling solutions from a top-down perspective combined with historical development. It covers some outdated schemes no longer discussed in the market today—some of which you may have never heard of.
However, I believe it's crucial to clearly understand the big picture and logical relationships among these approaches. This helps us comprehend what innovations and combinations have shaped the evolution of scaling, what challenges were encountered, what the market focused on during different periods, and why Rollup ultimately emerged as the leading solution. All of this also aids in understanding the broader direction forward.
When doing my own research, I found that there are almost no comprehensive online articles summarizing and comparing these aspects from such a holistic viewpoint.
Initially, I simply didn’t understand scaling at all—there seemed to be so many options, each with pros and cons, some appearing very similar, and I couldn't make sense of why. So I spent a significant amount of time digging into documents from various eras.
But after two weeks of this, I realized that organizing the information chronologically was especially helpful for me.
Still, expect a large volume of information today, since we’ll unavoidably touch on many technical concepts. If you can patiently read through it, I believe it will greatly help build your overall framework and logic for understanding the entire scaling landscape.
I. Origin
On the first-layer Ethereum blockchain, continuously growing network usage has led to congestion and rising transaction costs.
Improving storage capacity, network speed, and throughput is fundamental to enabling meaningful large-scale adoption of Ethereum.
Therefore, scaling is necessary.
II. Objective
The core objective of scaling is to increase transaction speed (faster finality) and transaction throughput (higher TPS), while maintaining decentralization and security.
III. Scaling Solutions
Scaling solutions fall into two main categories: On-Chain (Layer 1) and Off-Chain (Sidechains + Layer 2).
On-chain Scaling
Improvements to the blockchain itself require changes to the base layer/mainnet or Ethereum protocol: This involves "Layer 1." Layer 1 networks refer to underlying blockchains. Besides Ethereum (ETH), Bitcoin (BTC), Solana, Polkadot, Near, Cosmos, Aptos, Sui, etc., are all Layer 1 protocols because they serve as primary networks within their respective ecosystems. Layer 1 protocols process and finalize transactions independently and come with native tokens used to pay transaction fees.
(Full Layer 1 scaling is an important part of Ethereum upgrades—this topic will be covered separately in a future article. For now, we'll briefly summarize the concept without going too deep.)
Available On-Chain Layer 1 Scaling Options Include:
a. Changing the consensus mechanism. This approach was adopted in the Ethereum upgrade. The recent successful merge between the Beacon Chain and the mainnet completed the transition from PoW to PoS.
b. Implementing sharding. Sharding is a common Layer 1 scaling solution designed to increase transaction throughput. It's a database partitioning technique from computer science where the network—and its nodes—are split into different shards to distribute workload and accelerate transactions. Each shard handles a portion of the network’s activity, maintaining its own transactions, nodes, and blocks.Sharding also reduces the burden on individual validators (who no longer need to process and store every transaction). Nodes write their work results onto the main chain, sharing local data in real-time. This was part of the original Eth 2.0 upgrade plan but has since been replaced by danksharding.
c. Increasing block size. Enabling each block to process more transactions (currently, Ethereum's proto-danksharding upgrade follows a similar principle; details will be shared in a separate post later).Layer 1 scaling requires major effort. Often, not all network users agree on such changes, potentially causing community splits or even hard forks. (Bitcoin Cash splitting from Bitcoin in 2017 is an example of a hard fork consequence.)
Off-chain Scaling
All off-chain scaling solutions operate separately from the mainnet and do not require modifications to the existing Ethereum protocol.
Broadly speaking, off-chain scaling includes two types: I. Sidechains; II. Layer 2 solutions.
I. Sidechains
Sidechains are independent blockchains whose security relies entirely on their own protocol mechanisms. This is the key difference between sidechains and mainstream Layer 2 scaling solutions today.
Compared to other Layer 1 public chains, sidechains specifically handle excess capacity from Ethereum rather than competing directly with the entire Ethereum ecosystem. These ecosystems closely integrate with the Ethereum community, hosting Ethereum-based applications in a complementary manner.
Regarding classification, I find many online articles confusing—they often categorize sidechains under Layer 2. Here, I mainly follow definitions provided by the Ethereum Foundation and the official sidechain whitepaper.
https://ethereum.org/en/developers/docs/scaling/sidechains/
The second category of off-chain scaling refers to Layer 2 solutions—commonly known today. The basic idea is to perform computation/execution off-chain, then submit results on-chain via batched offline processing. These solutions derive their security directly from Ethereum's Layer 1 consensus. Different Layer 2 approaches strike varying balances between security, scalability efficiency, decentralization, and generality.
Let’s start with sidechains:
Sidechains are independent blockchains running parallel to and independently of the Ethereum mainnet.
They're typically designed for efficient transaction processing. Unlike Layer 2 solutions, sidechains do not publish state changes or transaction data back to the Ethereum mainnet, which is why they don’t inherit Ethereum’s security properties.
Sidechains usually sacrifice some degree of decentralization or security to achieve high throughput.
Sidechains connect to and interact with the mainnet primarily through a two-way pegged cross-chain bridge (a concept we'll explain shortly). The term “two-way peg” mainly refers to supporting bidirectional asset anchoring—enabling assets to move between the main chain and sidechain. Note that the assets aren’t truly transferred; instead, one chain locks the asset while the other mints an equivalent wrapped token. Any project implementing such a two-way bridge qualifies as a sidechain.
Let’s understand what a two-way pegged cross-chain bridge is:
This concept was introduced by BlockStream in a 2014 sidechain whitepaper. Two-way pegging means locking an asset (e.g., 10 ETH) on the main chain into a specific address. Then, evidence of this lock transaction is provided on the sidechain, prompting the minting of an equivalent amount of wrapped tokens (e.g., 10 wETH) on the sidechain, which can then be freely traded. The reverse works similarly: when a user wants to withdraw ETH from the main chain, they burn the corresponding amount of wrapped ETH on the sidechain.
Lock tokens on the main chain, mint (wrapped) tokens on the sidechain. Burn tokens on the sidechain, unlock tokens on the main chain.
https://medium.com/techskill-brew/layer-2-blockchain-scaling-solutions-channels-sidechains-rollups-and-plasma-part-16-79819e058ef6
Sidechains operate in a similar environment to the main chain, both based on EVM (Ethereum Virtual Machine). However, they have their own ledger systems, consensus algorithms (e.g., Proof-of-Authority, Delegated Proof-of-Stake, Byzantine Fault Tolerance), script contracts, etc. To achieve different goals, their methods of obtaining security vary.
Here are several examples:
1. Centralized (Basic Third-Party Authority): Currently the simplest method for transferring digital assets between blockchains—users send assets on the main chain to a centralized custodian (e.g., an exchange), who then activates an equivalent amount of assets on the sidechain. The biggest drawback is excessive centralization.
2. Federation (Multisig Federation): Replaces a single custodian with a federation of notaries using multi-signature to confirm asset movements on the sidechain. In this model, stealing frozen assets on the main chain would require compromising multiple institutions. However, sidechain security still depends on the honesty of the federation, making it still centralized.
3. SPV (Simple Payment Verification) Model: The above two models rely on intermediaries and are thus centralized.
SPV (Simplified Payment Verification) offers a more decentralized and secure alternative.
SPV is a concept mentioned by Nakamoto in the Bitcoin Whitepaper (“Enabling Blockchain Innovations with Pegged Sidechains”—recommended reading, link below). It's a crucial component of Bitcoin's underlying technology.
SPV is a method to prove the existence of a transaction by verifying only minimal data to confirm whether a particular transaction exists within a specific block.
In the SPV model:
1. Users send assets on the main chain to a special address, locking those assets on the main chain.
2. A confirmation period begins—the duration during which coins must remain locked on the parent chain before being transferred to the sidechain. This ensures sufficient work has been done, making denial-of-service attacks harder in the next waiting period. A typical confirmation period lasts about one to two days.
After generating the special output on the parent chain, users wait until the confirmation period ends, then create a transaction on the sidechain referencing this output, providing an SPV proof showing it was created and sufficiently secured by accumulated work on the parent chain. The confirmation period is a configurable security parameter balancing cross-chain speed and safety.
3. Once the main chain confirms the assets are locked, an SPV proof is sent to the sidechain. A corresponding transaction appears on the sidechain, minting an equivalent value of sidechain tokens.
4. The newly minted sidechain assets are initially locked. Next, users must wait a racing period. During this delay, newly transferred coins cannot be spent on the sidechain. This prevents double-spending during reorganizations—if a new proof-of-work emerges indicating the block containing the lock transaction is absent from the longest chain, the transfer becomes invalid. This is called a reorganization proof, requiring a racing period to prevent double-spends. If someone spends locked coins on the main chain during this window, others can provide a fresh SPV proof to invalidate the minting.
All sidechain users have an incentive to report reorganization proofs, as accepting fraudulent proofs dilutes everyone’s holdings.
5. A typical racing period lasts one to two days. After it ends, the sidechain tokens become spendable within the sidechain without further interaction with the parent chain. However, they retain their identity tied to the originating chain and can only be moved back to that same chain.
6. When users want to transfer coins back from the sidechain to the parent chain, the process repeats: send coins to an SPV-locked output on the sidechain, generate a valid SPV proof confirming completion, and use this proof to unlock the equivalent amount previously locked on the parent chain.
(Less Important) Drivechain: Proposed by Bitcoin Hivemind founder Paul Sztorc. In drivechains, miners act as “algorithmic custodians,” monitoring the sidechain’s state. Miners hold custody of locked assets and vote on when to release them and where to send them. Honest miner participation increases overall system security.
(Less Important) Hybrid Model: Drivechain + Notary/Sidechain combines the above bidirectional anchoring methods. Since main and sidechains fundamentally differ in implementation, symmetric bidirectional anchoring might be insufficient. Hybrid models use different unlocking methods—for example, SPV mode on the sidechain and drivechain mode on the main chain.
Data Availability (DA):
Regarding data validity, since sidechains store data independently without anchoring back, security relies solely on their own validators, significantly weakening overall security.
Sidechain Projects:
Polygon – Initially launched as a single Layer 2 Plasma solution (formerly Matic Network), it evolved into a comprehensive scaling framework for building Ethereum-compatible blockchain networks and expansion solutions. (It functions more like a protocol than a single solution.) Its goal is to create a polygon-like multi-chain ecosystem around Ethereum. Polygon is currently developing seven scaling solutions (including zk-Rollups, sidechains, SDKs). Among them, Polygon PoS sidechain leads the sector. The team believes Ethereum will remain dominant for high-value transactions and value storage, while daily transactions shift to Polygon’s low-cost blockchains. Thus, Polygon PoS supports Ethereum’s scalability rather than competing directly.
Gnosis Chain – Formerly xDai sidechain, later merged with Gnosis to form Gnosis Chain. Low cost and Ethereum compatibility are its main selling points.
Skale – Positioned as Ethereum’s “elastic sidechain network,” supporting thousands of independent blockchains, sidechains, storage chains, and other subchains—all connected to and fully compatible with Ethereum.
Palm – An Ethereum sidechain co-founded by Vitalik Buterin, ConsenSys founder Joseph Lubin, film producer David Heyman (Heyday Films), and Joe Hage (HENI Group). Designed for users to build NFTs.
Ronin – A gaming-focused sidechain developed by Axie Infinity’s Sky Mavis. Games require fast interactions and low fees to support thousands or millions of daily transactions. User experience must be smooth and seamless, prompting the team to build their own chain.
Shard Chains – In the original Eth upgrade (Eth 2.0), shard chains were considered variants of Ethereum’s own sidechains.
Pros and Cons:
+ve:
1) Excellent compatibility—supports general computation, EVM compatibility, and smart contracts.
2) High TPS achievable for large-scale, complex transactions. Sidechains are designed to sacrifice some decentralization or security measures to achieve high throughput (see blockchain trilemma).
3) Sidechains primarily reduce mainnet congestion, lower costs for everyone, and enhance Ethereum’s ecosystem availability and scalability.
4) Developers can use sidechains to explore and test new features and use cases unavailable on the main chain. How did sidechains originate? Back in 2012, Bitcoin’s core developers wanted to safely upgrade the Bitcoin protocol with new features but feared direct additions could risk the existing network if bugs occurred. Also, major changes required majority miner approval due to Bitcoin’s structure. Hence, the sidechain proposal emerged.
Thus, sidechains originally allowed developers to experimentally attach new functionalities to other blockchains linked to Bitcoin, protecting the parent chain.
-ve:
1) The key difference between sidechains and rollups/channels is that rollups and channels inherit Ethereum’s mainnet security, whereas sidechains use their own consensus mechanisms—typically optimized for faster, cheaper transactions—which means they generally don’t inherit Ethereum’s security attributes. Technically speaking, sidechains are not Layer 2 solutions.
2) Lower decentralization.
3) Weaker privacy compared to channel solutions—every transaction on a sidechain is broadcast and received by all participants, regardless of interaction.
II. Layer 2 Solutions
The basic idea is off-chain computation/execution with results posted on-chain; data processed offline in batches. These solutions derive security directly from Ethereum’s Layer 1 consensus. Main approaches include:
A. Channels
An early and long-standing blockchain scaling solution, best known through Bitcoin’s Lightning Network. Prioritizes security over usability.
Participants must lock part of Ethereum’s state (e.g., ETH deposits) into a multisig contract. Locking the initial state constitutes opening the channel. Then, participants conduct rapid, free transactions off-chain. Upon ending interaction, the final state is submitted on-chain, closing the channel.
Channels further divide into two types: Payment Channels and State Channels:
Payment Channel: First, establish a multisig contract address on the main chain. For instance, A and B create such a contract, where funds require mutual consent to move. Both deposit 10 ETH—this initial state opens the payment channel. They then conduct dozens or even thousands of off-chain transactions, each requiring signatures and timestamps. Eventually, A holds 5 ETH and B holds 15 ETH. They don’t need to record all intermediate transactions on-chain—only the initial deposit and final balance. Uploading the final balance closes the channel.
For A and B, off-chain transactions incur no fees and settle nearly instantly. Neither pays miners nor waits for block confirmations.
State Channel: An extension of Payment Channels. As the name suggests, it revolves around “state”—not just transaction states, but game states, event states, etc. Example: Starting a Gomoku game, players create a new “referee” program with an initial stake—this opens the state channel. Their moves aren’t submitted to the blockchain. Each move requires mutual signing and timestamping before proceeding. Only when the program determines a winner does the game end, and A/B sign a state update distributing the stakes accordingly—closing the state channel.
Data Availability (DA):
All data resides in Layer 2, with DA guaranteed by the channel participants themselves (the entire transfer or game process must be maintained by participants like A and B).
State Validity (SV):
After the channel closes, either party can submit the final state to Layer 1. However, Layer 1 doesn’t immediately validate—it requires the submitter to stake collateral first. Then comes a one-week fraud proof period, during which anyone can challenge the settlement by submitting a verifiable proof (showing the state is incorrect). Each off-chain transaction requires mutual signatures and timestamps. If the challenger provides a newer signed proof than previous records, it’s a valid fraud proof. This becomes the latest state, and the original submitter loses their staked tokens.
Channel Projects:
Bitcoin’s Lightning Network
Pros and Cons:
+ve:
1) Primarily suited for frequent, small payments.
2) Saves substantial time and fees. Creating the channel incurs an initial cost, but once deployed, updating internal states is extremely cheap. Only two transactions are recorded on-chain.
3) State validity (SV) is well-guaranteed via fraud proofs.
4) Strong privacy—everything happens inside the channel, not publicly broadcast or recorded on-chain. Only opening and closing transactions are public. In contrast, every transaction on a sidechain is visible to all participants.
5) Immediate finality—once both parties sign a state update, it’s considered finalized.
-ve:
1) Slow withdrawals—require a one-week fraud proof period before funds can be withdrawn.
2) High time and economic cost for infrequent users—creating and settling channels isn’t user-friendly (requires multisig setup, signing, referee programs, etc.).
3) No open participation—channels cannot send off-chain funds to uninvolved parties.
4) Moderate TPS—better suited for few participants; performance lags with large-scale, complex transactions.
5) No smart contract support—it’s not a full blockchain.
6) Requires all participants to stay 100% online—anyone leaving mid-process risks losing staked tokens.
7) Cannot represent objects without clear logical owners (e.g., Uniswap). Suitable only for applications with predefined participant sets (though adding/removing participants is possible, it requires constant contract updates).
B. Plasma
Due to limitations of Channels in handling large-scale, high-value, and complex transactions, Plasma emerged. Combining elements of sidechains, it solved the problem of sending assets to arbitrary recipients while improving TPS. For a long time during Layer 2 development, Plasma was widely believed to be “the right one.”
However, due to inherent flaws, it was later superseded by other Layer 2 solutions. Let’s briefly review:
Plasma is an independent blockchain. Originally intended to retain sidechain functionality—off-chain transactions for scaling—while addressing sidechain security issues (ensuring assets stored on child chains remain safe). After trade-offs, it sacrificed some sidechain performance (like smart contract execution) but increased security by anchoring blocks back to the mainnet. Key differences from sidechains:
1) Sidechains use bridges to interact with the main chain, relying on their own consensus for security. Plasma, however, publishes every block’s state information (as a block root) to the Ethereum mainnet. Thus, state information on Plasma chains is verifiable on Ethereum (though actual transaction data must be downloaded and saved by users). Ethereum acts only as a verifier, not validator, resulting in weaker security. Hence, Plasma chains are called “child” chains—smaller replicas of the “parent” Ethereum chain—meaning they inherit partial main chain security, qualifying them as Layer 2 solutions.
2) Plasma does not support smart contracts—only basic token transfers, swaps, and limited transaction types.
Infinite “Chains-in-Chains” Creation:
Each Plasma chain can infinitely spawn more sub-chains, reducing parent chain load. Each sub-chain has an “Operator” role.
Periodic “State Commitments” by Operators:
All off-chain transactions are first aggregated by the sub-chain operator. Then, since the sub-chain anchors to the main chain, the operator periodically summarizes results, compresses them into a block root via Merkle tree, and submits this root to the main chain as a state record—a periodic “state commitment.” This way, regardless of how many transactions occur between submissions, the sub-chain only needs to submit state changes—not raw transaction data—to the main chain.
Entry—Mainnet Contract:
Like sidechains, Plasma uses a main contract on Ethereum to manage user deposits and withdrawals. Users deposit ETH or any ERC-20 token into this contract. The Plasma operator monitors deposits, recreates the equivalent amount, and releases it to the user’s Plasma chain address.
Exit—Fraud Proofs:
When exiting the Plasma chain (i.e., withdrawing), Plasma introduces a “challenge period,” using fraud proofs to penalize dishonest behavior and ensure state validity. The main contract tracks state commitments (explained earlier) and punishes dishonest actions via fraud proofs. “Fraud proof” means anyone can, during the challenge period (usually 7+ days), submit proof via Merkle verification showing the withdrawal request is invalid.
Drawn by RJ
State Root:
As mentioned, Plasma maintains a (or series of interconnected) contract(s) on the main chain storing state records from the Plasma sub-chain. This record is actually the hash value stored in the root node of a Merkle tree—called the state root.
Explanation: A Merkle tree (a binary tree) stores account state information at leaf nodes.
For every two states (e.g., State 1/State 2), a unique hash (e.g., Hash(1,2)) is computed as their parent node, recursively up to the root node’s hash.
You don’t need to know how hashes are calculated—just remember:
1) Any state change alters the root hash.
2) Identical root hashes mean identical underlying data (so comparing roots verifies consistency).
3) With the root hash and adjacent hashes, one can verify a specific state exists in the tree.
Drawn by RJ
When transactions occur on the rollup, a new state root is generated. Any sub-chain user can compare this against their locally downloaded records to verify correctness (since identical records yield identical root hashes).
To ensure fund safety, users (potential “validators”) should periodically observe the Plasma chain and record transactions—running software that automatically syncs the chain and checks normal operation. Users should run this at least every few days, depending on Plasma MVP parameters.
If the chain operates normally, no further action is needed. But if irreversible errors occur (rare), wallets automatically initiate fund withdrawals from the Plasma chain—guaranteeing safety even if malicious operators attempt theft.
Data Unavailability:
A major flaw of Plasma is data unavailability. Fraud proofs effectively deter user malice and ensure security as long as at least one honest node exists. But if the operator acts maliciously and users lack the necessary transaction data to prove authenticity? Since fraud proof submission requires users to keep sub-chain records AND operators to publish true data, a malicious operator can hide critical data, preventing users from proving invalid transactions.
Mass Exit:
Since “operator malice” cannot be effectively prevented in Plasma, a workaround was devised—a “mass exit” mechanism—but this risks congesting Ethereum’s mainnet...
Plasma Projects:
Matic initially used Plasma, but researchers soon discovered data availability issues (discussed later), leading to abandonment in favor of other solutions. After rebranding, Polygon shifted toward comprehensive, full-stack scaling.
Pros and Cons:
+ve:
1) Provides high throughput and
2) Low cost per transaction.
3) Supports transactions between any users. Senders can transfer assets to non-users, who can claim them anytime by presenting proof. If both parties are on the Plasma chain, there’s no overhead. Thus, Plasma adapts to use cases independent of the main chain. Anyone—including enterprises—can customize Plasma smart contracts to build scalable infrastructure for various environments.
4) No need to pre-lock funds like in channels.
5) High security—Plasma security somewhat depends on the mainnet (via fraud proofs). Validators regularly submit state roots to the main chain, which doesn’t validate but allows anyone to challenge within a week, submitting fraud proofs to ensure state validity.
-ve:
1) Cannot run smart contracts—only supports basic token transfers, swaps, and limited transaction types.
2) Fixed submission cycles—if paying during the cycle, confirmation waits until the next cycle.
3) Slow withdrawals—typically require 7-day waiting period for challenges and fraud proofs.
4) Requires regular network monitoring (active participation) or delegation to ensure fund safety.
5) Relies on one or more operators to store data and provide services upon request.
6) Mass exits could congest the Ethereum mainnet.
Comparing Plasma to Channels, the core advantage is: users can send assets to previously uninvolved parties, with much lower capital requirements. The trade-off: Channels require no on-chain data, while Plasma requires periodic hash publication. Additionally, Plasma transfers aren’t instant—users must wait for the challenge window to close.
But Plasma’s fundamental issue is that to boost efficiency, sub-chains only periodically submit state results—not all transaction data—to the main chain. This means Plasma cannot achieve the same trust level as Ethereum’s main chain, placing responsibility for “data validity” on the operator rather than Ethereum itself—yet operators have incentives to misbehave.
Hence, roll-up solutions emerged…
C. Roll-Up:
Rollups are currently the dominant scaling solution—a compromise between original on-chain processing and Plasma: Like Plasma, they execute transactions outside Ethereum (Layer 1), batch multiple transactions, then send state updates back to the mainnet. The key differences are: 1) Rollups also submit transaction data to the main chain, and 2) Rollups maximally compress this data, deleting or trimming parts appropriately, ensuring final submissions are on-chain and verifiable by anyone. (These two Rollup types build on Plasma, offering different proof schemes for transaction data.)
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
Cycle Capital Research
