NewsFlash Articles Data Fundraising BlockBeats Pro

LD Research: An In-Depth Look at Ethereum Scaling Solutions

Read this article in 115 Minutes

From the perspective of the scaling solution evolution, Ethereum's scalability is not something that a single solution can achieve once and for all. Many solution providers are also exploring and laying out multiple paths.

Original Title: "LD Research: A Comprehensive Explanation of Ethereum's Scaling Solution"

Original Author: 0xRJ_eth (Twitter: @0xRJ_eth)

Original Source: LD Capital Research

Today, the main focus is to organize Ethereum's scaling solutions from a top-down perspective combined with the progression of time. The content covers some old solutions that are no longer mentioned in the current market, some of which you may not have even heard of. However, I believe it is essential to clarify the overall framework and the logical connections, as this helps us understand the development of scaling, the innovations and combinations it has gone through, the problems encountered, the market's focus at different times, and why Rollup solutions are currently dominant. All of this helps us see the bigger picture.

While conducting research, I found that there were hardly any articles online that comprehensively summarized and compared these solutions from this perspective. Initially, I had no understanding of scaling, felt overwhelmed by the numerous solutions, each with its pros and cons, some very similar to each other, and couldn't grasp why. So, I spent a significant amount of time digging through articles from different time periods. Over the past two weeks, I realized that organizing based on a timeline was incredibly helpful for me. However, today's information may be quite extensive as it inevitably involves many technical aspects and concepts. If you can patiently read through it, I believe it will be very helpful in constructing the overarching framework and logical structure of the entire scaling track.

1. Origin

On the first layer of the Ethereum blockchain, the continuously growing network usage demand led to network congestion, driving up transaction costs. Improving storage, network speed, and throughput is crucial for the widespread adoption of Ethereum.

Therefore, scalability is needed.

II. Purpose

The core purpose of scalability is to increase transaction speed (faster transaction confirmation) and transaction throughput (higher transactions per second TPS) while maintaining decentralization and security.

III. Scalability Solutions

Scalability solutions can be divided into two main categories — On-Chain (Layer 1) and Off-Chain (sidechains + Layer 2).

On-Chain Scaling

Improving the performance of the blockchain itself requires changes to the Layer 1 mainnet/Ethereum protocol: This involves "Layer 1." The Layer 1 network is another term for the underlying blockchain. Besides Ethereum (ETH), Bitcoin (BTC), Solana, Polkadot, Near, Cosmos, Aptos, and Sui are all Layer 1 protocols because they are the primary networks in their ecosystems. The Layer 1 protocol can process and settle transactions on its own blockchain while having a native token for transaction fees.

(The entire Layer 1 scaling is a crucial part of Ethereum's upgrade, which can be discussed in detail in a future Ethereum upgrade summary. Today, we will briefly summarize the concept of Layer 1 without going into too much detail.)

Optional solutions for On-Chain Layer 1 scaling include:

a. Changing the consensus mechanism. Ethereum's upgrade has adopted this solution. The recent successful merge of the beacon chain and the mainnet was the transition of the consensus mechanism from PoW to PoS.

b. Implementing sharding. Sharding is a common Layer 1 scaling solution primarily used to increase transaction throughput. This is a database partitioning technique in computer science where the network, along with its nodes, is divided into different "shards" to distribute workload and improve transaction speed. Each shard processes a portion of the network's activity, meaning each shard has its transactions, nodes, and independent blocks.

Sharding can also reduce the burden on each validator (as they no longer need to process and store all transactions on the entire network). Each node will write the completed work to the main chain and actively share local data. This was the scalability solution previously involved in the eth 2.0 original upgrade plan and has now been replaced by danksharding.

c. Increase Block Size. Allowing each block to process more transactions (currently, the Ethereum upgrade proto-danksharding is a similar solution, and this part of the upgrade will be spun off into a separate shard).

Layer 1 scalability is a difficult process. In many cases, not all network users will agree to such changes. This could lead to community division and even a hard fork (the 2017 Bitcoin split into Bitcoin Cash was a result of a hard fork).

Off-chain Scaling

All off-chain scaling is implemented separately from the Layer 1 mainnet, without altering the existing Ethereum protocol. Rollups can be broadly divided into two categories: I. Sidechains; II. Layer 2 solutions.

I. Sidechains

Sidechains are independent blockchains that rely entirely on their own protocol mechanisms for security. This is also the key difference between sidechains and the current mainstream Layer 2 off-chain scaling solutions.

As an independent chain, sidechains differ from some Layer 1 mainnets in that sidechains are specifically designed to handle excess capacity from Ethereum, rather than compete with the entire Ethereum network. These ecosystems are closely integrated with the Ethereum community, hosting Ethereum applications in a complementary manner.

Regarding this classification, I found many online articles to be quite confusing, often categorizing sidechains under Layer 2. For this part, I mainly referred to the Ethereum Foundation and the Sidechains Whitepaper for the definition of sidechains.

https://ethereum.org/en/developers/docs/scaling/sidechains/

The second type of Layer 2 scalability is the previously mentioned and commonly heard of layer2 Layer 2 solution: The basic idea is off-chain computation/execution with on-chain settlement; offline batch processing. Security is directly derived from the Layer 1 Ethereum consensus. Different Layer 2 solutions will seek a balance between security, scalability efficiency, decentralization, and universality.

Let's first talk about Sidechains:

Sidechains are independent blockchains that run parallel and independently to the Ethereum mainnet.

They are usually designed for efficient transaction processing. The biggest difference compared to second-layer scalability solutions is that sidechains do not publish state changes and transaction data back to the Ethereum mainnet, which is why they do not inherit Ethereum's security properties.

Sidechains often choose to sacrifice some decentralization or security to achieve high throughput.

Sidechains are mainly connected to the mainnet and interact with each other through a two-way pegged cross-chain bridge (this concept will be explained in more detail shortly). The so-called two-way pegged mainly refers to supporting asset two-way pegging, meaning assets can be transferred between the main chain and sidechain. However, it's important to note that assets are not truly transferred but rather "crossed" by using the method of "locking on one chain and minting the same amount on the other chain." Any project that establishes a two-way pegged cross-chain bridge can be considered a sidechain.

Let's first understand what a two-way pegged cross-chain bridge is:

This concept was presented in Blockstream's 2014 Sidechains whitepaper. Two-way pegging refers to locking a certain asset on the main chain, for example, 10 ETH, to a specific address; simultaneously, providing evidence on the sidechain of this "locking transaction," an equivalent amount of digital asset in the form of a wrapped token will be minted on the sidechain. For example, if 10 WETH is minted on the sidechain, now this 10 WETH can be traded on the sidechain. Conversely, when a user wants to withdraw ETH on the main chain, they can destroy the equivalent remaining wrapped ETH on the sidechain.

Lock tokens on the main chain, mint (wrapped) tokens on the side chain. Burn tokens on the side chain, withdraw tokens to the main chain.

https://medium.com/techskill-brew/layer-2-blockchain-scaling-solutions-channels-sidechains-rollups-and-plasma-part-16-79819e058ef6

The side chain operates in an environment similar to the main chain, also based on the EVM (Ethereum Virtual Machine). However, the side chain has its own ledger system, consensus algorithm (such as Proof of Authority, Proof of Stake, Byzantine Fault Tolerance), script contracts, etc. However, to achieve various different goals, their ways of obtaining security are also different.

Here are a few examples:

a. Single Custodian Model Centralized (basic third party authority): This is the simplest current way to transfer digital assets between blockchains—sending assets on the main chain to a single custodian (such as an exchange), which then receives the asset and activates an equivalent asset on the sidechain, allowing the asset to circulate on the sidechain. The biggest drawback of this method is its excessive centralization.

b. Consortium Model Federation - multisig federation: The consortium model involves using a federation of notaries to replace a single custodian, using the federation's multi-signature to confirm the movement of digital assets on the sidechain. In this model, stealing frozen digital assets on the main chain would require breaking through more institutions, but the security of the sidechain still depends on the honesty of the federation of notaries. This method is still centralized.

c. SPV (Simple Payment Verification) Mode: Both of the above two solutions rely on intermediaries to ensure security and are considered centralized.

SPV (Simplified Payment Verification) is a more secure decentralized approach.

SPV is a concept mentioned by Nakamoto in the Bitcoin Whitepaper ("Enabling Blockchain Innovations with Pegged Sidechains" is an interesting read related to this concept, I have included the link below). This is also a very important concept in the underlying technology of Bitcoin.

SPV is a method of proving the existence of a transaction, characterized by the ability to verify whether a specific transaction exists in a particular block with only a small amount of data. In SPV mode:

1. Users send assets on the main chain to a special address on the main chain to lock up those assets.

2. Wait for a confirmation period on the main chain, where the coin must be locked on the parent chain before transferring to the sidechain. The purpose of this confirmation period is to generate sufficient work to make a denial of service attack in the next waiting period more difficult. A typical confirmation period may be on the order of a day or two.

After a special output is created on the main chain, users wait for the confirmation period to end, then generate a transaction on the sidechain referencing that output, providing a proof that it has been created and sufficiently covered by work on the main chain, the confirmation period being a security parameter depending on the sidechain, balancing cross-chain transaction speed and security.

3. Once the main chain's confirmation period ends and the asset's locking is confirmed, an SPV proof is created and sent to the sidechain. Subsequently, a corresponding transaction with this SPV proof appears on the sidechain, creating an equivalent amount of sidechain token asset on the sidechain.

4. The generated sidechain asset is initially in a locked state, and users must then wait for a contest period. During this period, the newly moved coins cannot be spent on the sidechain. The purpose of the contest period is to prevent double spending during a reorg, where previously locked coins could be spent during the reorg. At any point during this delay period, if a new proof of work is issued that does not include the block that generated the locked output on the chain with the most accumulated work, the transfer will be rolled back. This is referred to as a reorg proof, which requires waiting for a contest period to prevent double spending. If, during the contest period, a user moves the locked coins on the main chain, other users can prove this with the latest SPV proof, resulting in the invalidation of the sidechain minting transaction, known as a reorg proof.

Whenever possible, all users on the sidechain have an incentive to produce reorg proofs because acknowledging a bad proof would dilute the value of all coins.

5. The typical contest period is also one or two days. After the contest period ends, the sidechain token is generated and can be freely transferred within the sidechain without further interaction with the main chain. However, it still retains the identity of the main chain coin and can only be transferred back to the chain it originated from.

6. When users want to move coins from the sidechain back to the main chain, the process repeats the above steps: sending the coins on the sidechain to an SPV locked output, generating a sufficient SPV proof to demonstrate the completion of that output and using this proof to unlock the equivalent output previously locked on the main chain.

d. (Less Relevant) Drivechain Model: The concept of a Drivechain was proposed by Bitcoin Hivemind founder Paul Sztorc. In a Drivechain, miners act as 'algorithmic custodians' who monitor the current state of the sidechain. Miners act as fund custodians, and the Drivechain delegates custody of locked assets to miners, allowing them to vote on when to unlock and where to send the unlocked assets. Miners observe the sidechain's state, and when they receive requests from the sidechain, they execute a coordination protocol to ensure consensus on the validity of the requests. The higher the participation of honest miners in the Drivechain, the greater the overall system security.

e. (Less Relevant) Hybrid Model: The Drivechain + Notary/Sidechain hybrid model effectively combines the above bidirectional anchoring methods. Due to the fundamental differences in implementation mechanisms between the main chain and the sidechain, a symmetrical bidirectional anchoring model may not be sufficient. The hybrid model involves using different unlocking methods on the main chain and the sidechain, such as using the SPV mode on the sidechain and the Drivechain mode on the main chain network.

Data Availability (DA):

Regarding data validity, since the sidechain claims to store data on the sidechain without anchoring back, it can only be guaranteed by the sidechain's validators, making security much weaker.

Sidechain Projects:

Polygon - The project evolved from a single Layer 2 plasma solution (formerly Matic Network) to ultimately become a scaling framework that can be used to create Ethereum-compatible blockchain networks and scaling solutions. (It is more like a protocol than a single solution.) Its goal is to build a multichain network around Ethereum, currently developing seven scaling solutions (from zk-rollups, sidechains, software development toolkits). The Polygon POS sidechain is considered a frontrunner. The Polygon team believes that in the future, Ethereum will remain the dominant blockchain for high-value transactions and value storage, while day-to-day transactions will shift to Polygon's low-cost blockchain. Therefore, the Polygon POS sidechain aims to provide value by assisting Ethereum in scaling rather than directly competing with and capturing market share from the Ethereum mainnet.

Gnosis Chain - Formerly the xDai sidechain, Gnosis Chain is the result of a merger with Gnosis to develop Gnosis Chain. Low cost and Ethereum compatibility are the two main selling points of Gnosis Chain.

Skale - Positioned as Ethereum's "elastic sidechain network," it can support thousands of independent blockchains, sidechains, storage chains, and other types of subchains. These blockchains are all connected to the Ethereum mainnet and fully compatible with the Ethereum ecosystem.

Palm - Ethereum co-founder Joseph Lubin, ConsenSys founder, film producer, and Heyday Films owner David Heyman, and HENI Group founder Joe Hage. This is an Ethereum sidechain that allows users to create NFTs.

Ronin - A game-centric sidechain launched by Axie Infinity's game developer Sky Mavis. Due to the game's need for fast interaction and low fees to scale and drive the daily tens of thousands to even millions of transactions that occur. The user experience must be friendly and smooth. So the team took matters into their own hands.

Shard Chain - A shard chain in the original eth upgrade plan (eth 2.0), also a variant of eth's own sidechain.

Pros and Cons:

+ve:

1) The sidechain's compatibility is very good, supporting general computation, EVM compatibility, and smart contracts.

2) When it comes to large-scale complex transactions, the sidechain's TPS can be very high. Comparatively, designing a sidechain involves sacrificing some decentralization or security measures to achieve high throughput (this part can refer to the blockchain trilemma).

3) The establishment of sidechains is mainly to reduce congestion on the main chain, lower everyone's costs, increase the availability and scalability of the Ethereum ecosystem.

4) Developers can also use sidechains to explore and test new features and use cases that are not available on the main chain. For example, how did the concept of sidechains originally come about? It was in 2012 when Bitcoin's core development team was considering how to safely upgrade the Bitcoin protocol to add new functionality. However, they were concerned that directly adding functionality to the Bitcoin blockchain was risky because if the new feature malfunctioned in practice, it would seriously impact the existing Bitcoin network. Furthermore, due to the nature of Bitcoin's network structure, major changes would also require the support of a majority of Bitcoin miners. At this point, the Bitcoin core developers proposed the idea of sidechains.

Therefore, the earliest sidechains allowed developers to exploratorily attach new features to other blockchains and then peg these sidechains to the existing Bitcoin blockchain to safeguard the Bitcoin main chain network.

-ve:

1) The main difference between sidechains and rollups and channels is that while rollups and channels inherit the security of the Ethereum main network, sidechains, due to using their own consensus mechanism, are typically designed for specific types of transactions (aiming to make transactions faster and more cost-effective). This also means that they usually do not inherit Ethereum's security properties. Technically speaking, sidechain solutions do not fall under layer2.

2) Lower degree of decentralization.

3) Compared to channel schemes, sidechains have weaker privacy because on a sidechain, every transaction is published to the sidechain, and every participant on the sidechain receives the transaction, regardless of whether they interact with all participants on the sidechain.

II. Layer2 Solutions

The basic idea is off-chain computation/execution, on-chain settlement; data processed offline in batches. This way obtains security directly from the Ethereum Layer 1 consensus, and the solutions include:

A. Channels

This is a very early and long-standing blockchain scaling solution, with its most famous application being Bitcoin's Lightning Network. It focuses more on security rather than availability.

Participants must lock up part of Ethereum's state, such as an ETH deposit, in a multi-signature contract. The initial lockup state is the first transaction, which opens the channel. Participants can then freely transact off-chain at high speed. Once the interaction is complete, the final state is submitted to the chain to close the channel.

This can be further divided into two types of channels: Payment Channels and State Channels:

・Payment Channel: On the main chain, a multi-signature contract address is established. For example, A and B create such a multi-signature contract where funds can only be transferred with both parties' consent. They each deposit their funds, let's say A and B each deposit 10 ETH. This initial state is equivalent to opening a payment channel. Subsequently, off-chain, they conduct dozens or even thousands of transactions between themselves, with both parties needing to sign and timestamp each transaction. In the end, A has 5 ETH and B has 15 ETH. They do not need to record all these transactions on the blockchain; they only need to record two transactions—the initial funding transaction and the final balance distribution after all transactions are complete. When they submit the final balance to the main chain, it effectively closes the payment channel.

For A and B, the off-chain transactions incur no fees and settle almost instantly. Both parties do not have to pay mining fees or wait for block confirmations.

・State Channel: This is essentially a derivative of the Payment Channel. As the name suggests, this solution revolves around "state," which means it is not just transaction state but can also be game state, event state, etc. For example, starting a game of tic-tac-toe, they first need to create a new "arbiter" program and provide an initial bet, thereby opening a state channel. Their moves in the game are not submitted to the blockchain as transactions. However, each move requires both parties to sign and timestamp, and then they proceed to the next move. Only when the program determines a winner according to the rules, ending the game, A and B sign a state update to efficiently settle the bet based on the game outcome. This action effectively closes the state channel.

Data Availability (DA):

All data exists on Layer2, ensured by both Channel parties to ensure State Validity (the entire process of transfer or game needs to be maintained by participants a and b themselves)

State Validity (SV):

After the Channel is closed, either party can submit the final state to Layer1, but Layer1 does not validate it, instead, it requires the submitter to first stake some assets. Then there will be a week-long period for Fraud Proof, where anyone can challenge a settled transaction and submit evidence (proof that the state is incorrect). This challenge is verifiable. As mentioned earlier, each offline transaction and action requires signatures from both parties, along with a timestamp. So, any evidence of fraud provided by the challenger showing a signed **up-to-date** transaction is a verifiable proof of fraud. This proof will become the new state, and the assets staked by the person who submitted the previous state will be slashed.

Channel Project:

Bitcoin's Lightning Network

Pros and Cons:

+ve:

1) Channels are mainly focused on high-frequency, low-value payments.

2) Saves a significant amount of transaction time and fees. Especially in terms of transaction fees, there is an initial cost to open a channel. But once deployed, each state update within the channel is very cheap. On-chain, only two transactions are actually recorded.

3) State Validity (SV) can be well ensured through Fraud Proofs.

4) State channels have strong privacy features - because everything happens within the channel and is not publicly broadcasted or recorded on-chain. Only the opening and closing transactions must be public. However, in a side-chain system, each transfer is published on the side-chain, and then each participant on the side-chain receives it.

5) State channels have instant finality - meaning that once two parties sign a state update, the state can be considered final.

Cons:

1) Slow withdrawal process, requiring a week for fraud proofs before withdrawal

2) For users who occasionally transfer funds to each other, the time and cost to create and settle a channel are high and not very user-friendly. This is because you need to create a multi-signature contract, signatures, design adjudication processes...

3) Does not support open participation. Channels cannot be used to send off-chain funds to someone who has not participated

4) Average TPS, more suitable for a small number of participants; performance may not keep up with large-scale complex transactions.

5) Does not support smart contracts, after all, it is not a chain.

6) All participants in a state channel need to be 100% online, and if a participant leaves midway, their staked tokens will be deducted.

7) Channels cannot represent objects with no clear logical owner (e.g., Uniswap). Therefore, channels are only suitable for applications with a predefined set of participants. While participants can be added and removed, the contract needs to be changed each time.

B. Plasma

Due to the limitations of channels in supporting large-scale, high-value, and complex transactions, the Plasma solution emerged. It combines some design of sidechains, solving the problem of sending assets to any destination while also ensuring an increase in TPS. In fact, for a long time at the beginning of developers' research into Layer 2 solutions, Plasma was once considered "the right one."

However, as Layer 2 solutions replaced Plasma later due to some shortcomings, let me briefly explain here:

Plasma is an independent blockchain. Its initial design aimed to retain the main use case of sidechains, enabling scaling through off-chain transactions while also addressing certain security issues of sidechains (meaning that when a child chain is under attack, the assets stored on the child chain are always safe). Therefore, after weighing the options, it gave up some of the sidechain's performance (such as executing smart contracts, etc.) but increased security by anchoring blocks back to the mainnet. The two biggest differences between it and sidechains are:

1) A sidechain interacts with the main chain through a bridge, but its security relies on its own consensus mechanism. Sidechains are often much smaller than the main network. However, Plasma publishes the state information of each of its blocks in the form of a block root to the Ethereum mainnet. Therefore, the state information on the Plasma chain can be confirmed on the Ethereum mainnet (although the specific transaction data on the child chain needs to be downloaded and stored by users themselves. The Ethereum main chain only serves as a confirmator in this process, not a validator, so its security level is lower). Thus, Plasma chains are also referred to as "child" chains because they are essentially smaller replicas of the "parent" Ethereum chain. This means they inherit some security from the main chain, making them part of a layer 2 solution.

2) Smart contracts are not supported on Plasma, only basic token transfers, exchanges, and some other transaction types are supported.

・Endless creation of "chains within a chain":

Each Plasma chain can infinitely create more child chains to reduce the workload on the parent chain, with each child chain having an "Operator" role.

・Operator's periodic "state commitments":

All off-chain transactions are first aggregated to the operator of the child chain, and then (as the child chain needs to anchor back to the main chain) the operator periodically aggregates the result of the child chain's computation, compresses it into a block root in the form of a Merkle tree, and finally submits the block root back to the main chain for state recording. This is known as the periodic submission of "state commitments." Through this process, regardless of how many transactions occur on the child chain between two submissions, the child chain only needs to submit the state information resulting from transaction execution to the main chain. The transaction data is not submitted to the main chain.

・Entry – Mainnet Contract:

Similar to a sidechain, Plasma uses a mainnet contract running on Ethereum to handle user entry and exit. Users must deposit ETH or any ERC-20 Token into the main contract. The Plasma operator monitoring the contract deposit recreates an amount equal to the user's initial deposit and releases it to the user's address on the Plasma chain.

・Exit Fraud-proof:

Upon exiting the Plasma chain, i.e., when making a withdrawal, Plasma introduced the previously mentioned "challenge period" to punish dishonest behavior and ensure state validity through an exit fraud-proof mechanism. The root contract is also responsible for tracking state commitments (explained earlier) and punishing dishonest behavior through fraud proofs. "Fraud proof" means that anyone can, during this challenge period (usually 7 days or longer), submit proof through Merkle tree verification that a user's asset exit is illegitimate.

Drawn by RJ

・State Root:

As mentioned earlier, Plasma has a main contract (or a series of interconnected contracts) on the main chain to maintain the state record in the Plasma subchain. This state record is actually the hash value of the root node of a Merkle tree, and this hash value is called the state root.

Specific Explanation: A Merkle tree (a binary tree) holds the current state information of the accounts at the rollup layer on the leaf nodes of the binary tree.

For every two pieces of state information (e.g., State 1/State 2), we can calculate a unique hash value (e.g., Hash(1,2)) based on a certain hashing formula to serve as the parent node of these two leaf nodes. This process continues layer by layer, ultimately resulting in a hash value stored in the root node: You don't need to know how to calculate the hash value; you just need to remember a few things.

1) Any state change will result in a change in the Root hash.

2) If two trees have the same root hash value, it means that the information stored in their leaf nodes is exactly the same (thus, comparing the root hash values of the two trees is sufficient to confirm the consistency of the underlying state information).

3) Based on the root node's hash value and downloading neighboring hash values, we can confirm that a certain state information exists in this Merkle tree.

Drawn by RJ

When transactions occur on the rollup, a new state root is generated. At this point, users of any child chain can compare and prove the correctness of the new state root based on the transaction information they have downloaded on the child chain (as mentioned earlier, whenever recorded transactions/leaf nodes are identical, the root hash value will definitely be the same).

To ensure their funds are completely secure, users (potential "validators") need to periodically observe the plasma chain to record on-chain transaction information. This includes running an automatic sync (download) of the plasma chain and ensuring that the software is running as expected. Users should run this software at least every few days, but the specific timing depends on the parameters set in the Plasma MVP smart contract.

If the plasma chain is running smoothly, then users do not need to do anything else. However, in case of irreversible errors (hopefully very rare), the user's wallet will automatically begin to withdraw funds from the Plasma chain. This automatic withdrawal ensures the security of user funds, even in the worst-case scenario when a malicious operator attempts to steal funds.

・Data Unavailability:

However, Plasma has a significant issue, which is data unavailability. Fraud proofs effectively prevent user misconduct and can also ensure that as long as there is at least one honest node, the chain's security can be guaranteed. But what if it is the operator who is malicious, and users/validators do not have relevant transaction information that can prove the authenticity? Since the premise for users to submit fraud proofs is that users have independently recorded the transaction data on the child chain + the operator has included all genuine transaction data in the main chain, if the operator maliciously submits invalid data while hiding the necessary information for fraud prevention, users in the network will be unable to obtain the real information to prove that the transaction is invalid.

・Mass Exit:

Due to the issue of "operator misbehavior" being unable to be effectively prevented in the plasma solution, only mitigation strategies can be considered. Thus, plasma has designed a "Mass Exit" scheme, but this scheme could potentially lead to network congestion on the Ethereum main chain...

Plasma Project:

Matic initially used Plasma, but blockchain researchers soon discovered data availability issues (which will be further discussed in the report), leading to the abandonment of Plasma in favor of other solutions. After rebranding, the Polygon project shifted to a comprehensive, layer-2 scaling solution.

Pros and Cons:

+ve:

1) Provides high throughput

2) Low cost per transaction

3) Suitable for transactions between any users. Users can send assets to those outside Plasma, and the recipient can exit back to Plasma at any time by presenting the exit proof for redemption. If both parties establish on the plasma chain, each user incurs no expense. Thus, Plasma can also accommodate specific use cases unrelated to the main chain. Anyone, including enterprises, can customize Plasma smart contracts to provide scalable infrastructure that works in different environments.

4) No need to lock funds in advance as in channels.

5) High security; Plasma's security to some extent relies on the main chain (fraud proofs). Sidechain validators regularly submit the state root to the main chain, which does not validate it but allows anyone to raise challenges and submit fraud proofs within a week to ensure the state validity.

-ve:

1) Unable to run smart contracts. Plasma only supports basic token transfers, swaps, and some other transaction types.

2) Fixed submission period, where if you submit within that period, the payment will not be confirmed until the period is over.

3) Slow withdrawal process, usually taking up to 7 days to allow for challenges and fraud proofs.

4) Requires regular monitoring of the network (activity requirements) or delegating this responsibility to others to ensure fund security.

5) Relies on one or more operators to store data and provide services upon request.

6) If too many users attempt to exit at the same time, the Ethereum mainnet may become congested.

Therefore, the core advantage of Plasma compared to Channel is that users can send assets to participants who have never interacted with the system before, with much lower capital requirements. However, the trade-off is that while the Channel does not require any on-chain data to operate, Plasma requires each chain to periodically publish a hash value. Additionally, Plasma transfers are not instantaneous: users must wait for the challenge period to end.

However, the most significant issue with Plasma itself is that a Plasma child chain, for efficiency reasons, only periodically submits its state results to the main chain, not all transaction data. But by doing so, Plasma cannot establish the same level of trust as the Ethereum main chain because the responsibility of ensuring "data validity" falls on the "operators" rather than the Ethereum mainnet. However, operators have an incentive to misbehave.

And thus, the roll-up solution emerged...

C. Roll-Up:

Rollup is currently the most mainstream scaling solution, serving as a compromise between the original on-chain processing method and the Plasma approach: like Plasma, it executes transactions outside the Ethereum main chain (Layer 1), batch processes multiple transactions together, and finally sends their state back to the Ethereum main network. However, the differences are that 1) Roll-up also submits transaction data to the main chain, 2) Rollup aggressively compresses this transaction data while appropriately deleting and reducing some data based on the nature of Rollup itself, as long as the final submission can be made to the main chain for anyone to verify (These two kinds of roll-ups are both built on Plasma's foundation and provide different proof schemes for the transaction data part.)

Therefore, Rollup's security is higher than Plasma's. Its core advantage is to ensure both state validity and data availability simultaneously.

How is Rollup specifically implemented?

・State Root (previously mentioned):

First, Rollup has a contract on the main chain (or a series of interrelated contracts) to maintain the state record in the Rollup layer. This state record is actually the hash of the root node of a Merkle tree, which is called the state root.

Specifically, a Merkle tree (a binary tree) holds the current account state information of the Rollup layer on the leaf nodes of the binary tree.

For every two pieces of state information (e.g., State 1/State 2), we can calculate a unique hash value (e.g., Hash(1,2)) based on a certain hash formula to serve as the parent node of these two leaf nodes. This process continues layer by layer until a hash value stored in the root node is obtained. We don't need to know how to calculate the hash value; we only need to remember a few key points.

1. Any change in state will cause the Root hash to change;

2. If two tree root hash values are the same, it indicates that the information stored in the leaf nodes is identical (thus, comparing the two root node hash values is sufficient to confirm the consistency of the underlying state information);

3. Based on the root node's hash value and downloading adjacent hash values, we can confirm that certain state information exists in this hash tree.

Drawn by RJ

・Batch (another excellent enhancement of Rollup):

When a transaction occurs on a rollup, a new state root is generated.

However, if each transaction is signed and the state root is updated on the main chain every time a transaction occurs, the cost incurred would be higher than executing these transactions on Layer 1.

Therefore, transactions generated on rollup are batched and aggregated. Based on the state after executing this batch of transactions, a new state root is generated. Whoever packages the transactions and submits them to the smart contract on the main chain needs to compute this new state root, submit it along with the previous state root and the transaction data.

This packaging process is called a "batch." After the operator submits the batch to the Rollup contract, the main chain will verify the new state root. If the verification is successful, the state root is updated to the latest submitted state root, completing the state transition confirmation within a rollup.

Therefore, the essence of Rollup is to aggregate a large number of actual transactions into a single transaction on the main chain. These transactions are executed and computed by the Rollup chain but data is submitted to the main chain. This approach leverages the consensus and security of the main chain while improving transaction efficiency and reducing costs.

https://vitalik.ca/general/2021/01/05/rollup.html

・Compression:

Both of these technical solutions achieve scalability, with the core being the compression and packaging of transaction data (as mentioned earlier, a major improvement of rollup is to put transaction data on-chain, so "compression" is targeted at this part). This is because Ethereum's block gas limit is limited. The smaller the compressed transactions, the more can be submitted to the main chain at once, and the lower the spread-out fee. So how is this achieved?

The following is an example of a zk compression pattern described by Vitalik in his article to help us understand:

A simple transaction (such as sending ETH) on the Ethereum main chain typically consumes about 112 bytes. However, sending ETH on zk-Rollup can be reduced to about 12 bytes.

https://vitalik.ca/general/2021/01/05/rollup.html

To achieve this level of compression, on the one hand, a simpler high-level encoding is used, and on the other hand, there are some clever compression techniques.

This chart is very interesting. Excluding rollup, generally these parameters are involved in transactions on the Ethereum network:

Nonce: The purpose of this parameter is to prevent replay. If an account's current nonce is 5, then the next transaction from that account will increase the account's nonce to 6 after processing. Nonces can generally reach several thousand or even million, but they are RLP encoded and can dynamically shorten bytes. Therefore, the nonce on the Ethereum network is approximately around 3 bytes.

Gas Price: It is a number in units of 10 to the power of -18 and is also RLP encoded, occupying about 8 bytes.

Gas: Here, this refers to the amount of gas you are willing to pay, which is generally not much. Typically, an Ethereum block has a gas limit of 20 million gas. A regular transfer transaction uses around 20,000 gas, while calling a contract uses roughly 100,000 to 200,000 gas, at most several hundred thousand gas. Therefore, this part averages about 3 bytes.

To: An Ethereum address is approximately 21 bytes, and the Ethereum address space is very large.

Value: This refers to the amount of money transferred. Often, the value when calling a contract is 0 because you don't need to transfer money to a contract. But for example, if I transfer 5 ETH to you, then the value has a certain amount. The unit is also in 10 to the power of -18, RLP encoded, occupying about 9 bytes.

Signature: The signature is relatively fixed, around 68 bytes.

So, in this calculation, an ETH transaction is approximately 112 bytes. Since roll-up is moving to L2, as long as the complete information can be expressed, the L2 solution can have a custom format. However, this information can be selected and compressed. For example:

Nonce: Nonce can be completely omitted in rollup because it can be recovered from the pre-state.

Gas Price: A fixed fee level can be set for each batch in rollup, or even the gas payment can be moved entirely outside the aggregation protocol, allowing traders to pay fees to batch creators through channels.

Gas: The gas limit can be set at the batch level by choosing specific values.

To: The 20-byte address can be replaced with an index on the Merkle tree (e.g., if the address is the 4527th address added to the tree, we only need to use the index "4527" to reference it). This can be limited to 4 bytes.

Value: The monetary amount can be converted to a different unit, or other technical methods can be used for storage.

Signature: Using BLS aggregate signatures to combine multiple signatures into one. Then, the signatures can be batch-verified for the entire message batch at once. Since the maximum number of aggregated signatures that can be verified in each block is 100, even a large batch with 100 signatures can be aggregated into one signature.

This ultimately saves about 12 bytes. In reality, this limits the precision but maintains the informational scope, almost fully expressing the complete information. This is why rollup can achieve scalability. However, the primary reason for this scalability is that on the main chain, there is a limitation on calldata because each byte of calldata consumes a bit of gas on the mainnet, and there is a limit to the total gas in a block on the main chain. Therefore, the total number of bytes that calldata can include is limited.

These compression techniques are key to rollup scalability. Without compressing transaction data, rollup may only achieve about a 10x efficiency improvement based on the main chain. But with these compression techniques, it can achieve a 100x or even higher compression efficiency.

Data Availability:

How to verify that the submitted information is correctly available?

One major difference between Rollup and Plasma is that it also submits transaction data to the main chain to ensure that anyone can verify it. This now raises the question of how to verify that the submitted information is correctly available.

For this issue, there are generally two solutions, and depending on the solution, Rollup is also divided into two types: Optimistic Rollup and Zero-knowledge (ZK) Rollup.

a) Optimistic Rollup As the name suggests, they optimistically assume all transactions are valid and submit batches without any initial proofs. Anyone can detect and prove during the challenge period that some data is false.

Drawn by RJ

If a batch is proven to be fraudulent, Optimistic Rollups will execute a fraud proof and run correct transaction computation using available data on the Ethereum main chain.

You can also use the following diagram (next image) to explain the fraud proof construction in Optimistic Rollup:

The information included in the batch consists of the pre-state root, post-state root, and transaction data.

Based on the pre-state root, a complete Merkle tree can be constructed.

With the transaction data, we can simulate the execution of the submitted transactions in the batch, resulting in a new account state, a new Merkle tree, and a new state root.

By comparing the obtained state root from the previous step with the state root in the batch, the correctness of the batch can be verified.

https://vitalik.ca/general/2021/01/05/rollup.html

To deter submitters from misbehavior, submitters often need to stake funds, and when their submission is proven incorrect, a portion of the staked funds will be deducted as a penalty. Simultaneously, validators who submitted the corresponding fraud proof will receive the deducted deposit as a reward, thereby incentivizing the behavior of monitoring and submitting fraud proofs.

If we compare OR and Plasma, we will find some similarities, such as both using a fraud proof mechanism and requiring a validator role to monitor the submissions from OR to the main chain. However, since OR simultaneously submits transaction data to the main chain, validators on OR do not need to keep a record of OR's transactions themselves.

Drawn by RJ

Pros and Cons:

+ve:

1) Provides high throughput

2) and low transaction costs

3) roll-up transaction data is stored on Layer 1 chain, increasing transparency, security, censorship resistance, and decentralization. Provides a significant improvement in scalability without sacrificing security or trustlessness.

4) Optimistic rollup's fraud proof ensures trustless finality, state validity, and allows honest minority to secure the chain (in theory even a single honest node can secure the entire chain)

5) Optimistic rollup also secures data availability by anchoring transaction data on the mainnet.

6) Compatibility with EVM and Solidity allows developers to port Ethereum native smart contracts to the rollup or use existing tools to create new dapps.

-ve:

1) Slow withdrawals, typically taking 7 days to allow for submitting challenges and fraud proofs

2) Security model relies on at least one honest node executing the aggregation transactions and submitting fraud proofs to challenge invalid state transitions.

3) Optimistic roll-up must publish all transaction data on-chain, incurring a certain cost.

Optimistic Rollup Project:

b) Another type of Roll-up solution is the Zero-Knowledge Rollup (ZK Rollup)

First, let's talk about what Zero-Knowledge Proof (ZKP) is.

Zero-Knowledge Proof (ZKP) is an essential part of modern cryptography. It refers to a situation where a prover can convince a verifier that a particular statement is true without revealing any useful information to the verifier.

The prover proves to the verifier that they know or possess a certain message without disclosing any information about the message being proved. In simple terms:

They prove what they want to prove while revealing "zero" information to the verifier. e.g., Sudoku

・Completeness

・Soundness

・Zero-Knowledge property

Unlike Optimistic Rollup, ZK Rollup requires the submitter to include not only the transaction data and the post/previous state root when submitting a batch (ZK Rollup also batches transactions, executes them off-chain, and then submits them together on-chain) but also to carry a "validity proof." Once the validity proof is submitted to the mainnet's roll-up contract, anyone can use it to verify if the transactions in a specific batch in the ZK Rollup layer are correct. The proof can be completed a few minutes after submitting the batch, and upon successful verification, the main chain roll-up contract will update the State root to the latest submitted data. This is essentially equivalent to skipping the work of validators and completing verification at submission.

This means: 1. zk Rollup eliminates the need for validators to store data and submit fraud proofs during the challenge period (as shown below); 2. There is no need to wait another 7-14 days for validation after submission. Therefore, transaction speed is much faster than other L2 solutions.

Drawn by RJ

There are currently two types of zero-knowledge proof solutions on the market:

I. zk-SNARK (Succinct Non-Interactive Argument of Knowledge) is an abbreviation of Succinct Non-Interactive Argument of Knowledge. The characteristic of this scheme is succinctness, meaning that the verification process does not involve a large amount of data transfer, and the verification algorithm is simple. This means that the verification time does not increase exponentially with computational throughput.

II. zk-STARK (Scalable Transparent Argument of Knowledge) is a scalable transparent argument of knowledge created as an alternative to SNARK. Unlike the "S" in SNARK representing Succinct, the "S" in STARK stands for Scalable, mainly manifested in the fact that the proof generation time complexity of STARK is approximately linear with computational complexity, while the time complexity of verifying the proof is much smaller than the computational complexity. This means that as the scalability of STARK increases, the proof complexity of STARK does not increase proportionally.

However, because zero-knowledge proofs involve very complex underlying technology and cryptographic concepts, this part can be singled out for a separate discussion in the future. Today, we'll just briefly mention it without going into specific details.

In any case, we know that several key compression techniques unique to ZK rollups are:

1. The generated proof size is much smaller than the proof's content size (hence much smaller than the bytes uploaded to the mainnet).

2. If a part of a transaction is only used for verification and is unrelated to state updates, that part can be moved off-chain to reduce bytes. However, this cannot be achieved in an optimistic roll-up because this data still needs to be included on-chain in case it needs to be checked in a fraud proof later (unlike ZK, which does not require a challenge period and fraud proofs).

But the challenge with ZK is that generating and verifying a ZK proof itself requires a very, very large amount of complex computation, which is one of the reasons why the current ZK-Rollup research and practical applications are very slow. Moreover, due to its technical complexity, not just any language, compilation environment, virtual machine, or instruction set can seamlessly support the above process. Additional adaptation is needed, making it inherently difficult for ZK projects to be compatible with EVM. (This part can also be discussed in more detail in a future dedicated discussion on ZK).

Here is a fee and TPS comparison of a different solution created by the @W3.Hitchhiker team:

https://w3hitchhiker.mirror.xyz/7dwD76ZZIlR7ep731K6y9vTTuXGHOojxWSnkXKzqPzI

Pros and Cons:

+ve:

1) Proof of Validity ensures the correctness of off-chain transactions.

2) Due to the omission of the concept of validators' work and challenge period, once Proof of Validity is validated on L1, it will approve the state update, providing faster transaction finality. (No need to wait another 7-14 days)

3) OR's data availability comes from economics. In order to function well, OR must design a reasonable incentive mechanism to urge a set of validators on the main chain to monitor submitters at all times and be ready to submit fraud proofs, while zk's data availability relies on cryptography and code.

4) Security relies on the security and consensus of the mainnet. Because all the data needed to recover the off-chain state is stored on L1, security, censorship resistance, and decentralization are ensured.

5) Better data compression helps reduce the cost of calldata posted on Ethereum and minimizes user aggregation fees. It is currently the most powerful and efficient compression solution available.

6) Therefore, user transaction fees are also low.

-ve:

1) Due to the large computation and high complexity required for its proof of validity, development speed is slow.

2) Therefore, its applications are not widespread. Unlike Optimistic Rollup, it does not have as many use cases and iterations.

3) It is currently difficult to support the Ethereum Virtual Machine (EVM), making it challenging to run smart contracts, DeFi protocols, and other decentralized applications.

4) Centralization risks in terms of hardware. Generating a proof of validity requires specialized hardware, and hardware monopolies could lead to centralized control of the chain.

ZK Roll-Up Project:

data from https://l2beat.com/scaling/tvl/, 9/22/2022

Rollup Brief:

It's now clear why the Roll-Up solution can replace the Plasma solution:

1) Efficiency - zk-rollup generates a validity proof for off-chain transaction processing. This directly eliminates the need for operators to package data, publish "state commitments," and users to submit fraud proofs, thereby eliminating the need for challenge periods and exit mechanisms. This also means that users do not have to regularly monitor the chain to protect their funds.

2) Smart Contract Support - Another issue with Plasma is its inability to support the execution of Ethereum smart contracts. Optimistic roll-up is compatible with the Ethereum Virtual Machine, and many zk projects (zkSync, StarkWare, etc.) are also advancing the implementation of zkEVM. This makes it a more ideal, secure, and useful decentralized scaling solution.

Data Unavailability - As mentioned earlier, Plasma suffers from data availability issues. If a malicious operator submits invalid data on the Plasma chain, users will not be able to challenge and submit fraud proofs. Rollups address this issue by requiring operators to publish transaction data on Ethereum, allowing anyone to verify the chain's state and create fraud proofs when necessary.

3) Mass Exit Problem - ZK-rollups and Optimistic Rollups have both addressed Plasma's mass exit problem in different ways. For example, the encryption mechanism of ZK-rollup ensures that operators cannot steal user funds under any circumstances.

Likewise, Optimistic Rollup imposes a withdrawal delay during which anyone can initiate a challenge and prevent malicious withdrawal requests. While similar to Plasma, the key difference is that validators have access to the data needed to create fraud proofs. Therefore, roll-up schemes do not involve the possibility of a "mass exit" that could harm the main network.

Over the past few years, Vitalik Buterin has also emphasized that the future development path of Ethereum will be centered around rollups, with the underlying chain providing assurance of block data availability and rollups providing assurance of block scalability and efficiency.

However...

As the push towards a large-scale migration to layer 2 progresses, even rollups with strong compression capabilities will ultimately face the same scalability issues - because rollup transaction data still needs to be propagated to all full nodes, its scalability is still limited by Ethereum's data processing capacity.

Compared to the mainnet, Optimistic Rollup can achieve a 25x scalability upgrade, while ZK-Rollup can achieve 100x, approximately 3000 TPS.

It can be said that the scalability provided by the Rollup solutions is linear growth, not exponential. Is it possible to guarantee performance while providing exponential scalability growth?

So the StarkWare team has pioneered the Validium solution, another layer-2 scaling solution that could potentially achieve 20,000-30,000 transactions per second (tps) off-chain…

D. Validium Chain

It operates similarly to ZK Rollup, using zero-knowledge proofs to validate Ethereum transactions off-chain. However, the main difference is that Validium's data availability is off-chain. This design allows for higher throughput unconstrained by Ethereum's on-chain processing capabilities, thereby improving scalability, transaction speed, reducing user fees (lower calldata costs), among other benefits.

・Deposits and Withdrawals:

Deposits and withdrawals work similarly to rollups, where user funds are controlled by a smart contract on Ethereum. Users deposit ETH (or any ERC-compatible token) into the Ethereum main chain contract, which mints an equivalent amount of tokens on the Validium chain.

For withdrawals, Validium users submit their withdrawal transactions to the operator. The user's assets on the Validium chain are destroyed before exiting the system. Once a batch's validity proof is verified, users can initiate withdrawals by providing a merkle proof to the main contract. Similar to ZK Rollup, Validiums offer almost instant withdrawals.

・Batch Processing:

Similar to rollups, users submit transactions to the operator, who batches them and submits them to the main chain. Each batch includes a state root/merkle root and a validity proof. To update the state, the operator must compute a new state root (after processing transactions) and submit it to the main chain contract. Upon successful validation of the proof, the state transitions to the new root.

Unlike ZK Rollup, operators on Validium do not need to publish transaction data, making Validium a fully off-chain scaling protocol.

Drawn by RJ

The main advantage of Validium's off-chain data storage is to further improve scalability (throughput not limited by Ethereum's data processing capacity), increase transaction speed, reduce user fees (lower calldata publishing cost), and protect privacy, as the public cannot access transaction data on-chain.

Data Availability:

However, the availability of off-chain data brings about a problem—if operators act maliciously by hiding off-chain state data from users, and users cannot access transaction data, then users cannot compute the Merkle proof required to execute a withdrawal, leading to their funds being frozen.

As shown in the diagram below: if the operator altered transaction 6, then the owner of transaction 1 would be unable to prove ownership of their account because the information of the nodes' hashes (5, 6, 7, 8) required in the proof process is missing.

(Sounds better than plasma—in the plasma scheme, operator malfeasance can result in the theft of user funds; in Validium, because fraud proofs are not used but instead validity proofs, the worst-case scenario of operator malfeasance hiding data is freezing user funds, preventing them from withdrawing…)

Drawn by RJ

Therefore, Validium needs to adopt an additional off-chain data management mechanism to ensure that users can access off-chain transaction data when needed.

Validium's off-chain data availability management methods can be divided into two main categories: some rely on trusted parties to store off-chain data, while others use randomly assigned validators to accomplish the task.

Category One: Data Availability Committee (DAC)

To address this issue, StarkWare has proposed the concept of a Data Availability Committee (DAC) to eliminate user trust reliance on operators.

By specifying a set of trusted entities (collectively referred to as the Data Availability Committee) to store copies of off-chain data and making them (off-chain data copies) publicly accessible in emergency situations where the operator fails to serve users' withdrawal requests. With fewer members, DAC is easier to implement and requires less coordination. However, it comes with centralization risks.

Direct withdrawal without involving the operator.

In an emergency, the application smart contract (ASC) on the mainnet will no longer accept new state updates but will only allow users who can provide a Merkle proof for the latest state to directly withdraw funds. In other words, in this scenario, users can withdraw their funds directly by calling the main contract's withdrawal function without involving the operator.

Since it still uses zero-knowledge proofs, there is no risk of broadcasting incorrect states.

However, users must trust the DAC to provide data when needed (e.g., for generating Merkle proofs). Members of the Data Availability Committee may be vulnerable to malicious actors, who can then withhold off-chain data.

Category 2: Bounded Data Availability

This is achieved through an economic incentive mechanism and a form of decentralization to ensure the availability of off-chain data. This scheme requires participants responsible for storing offline data to stake (i.e., lock up) tokens in a smart contract before taking on their role. These tokens serve as a "bond" to guarantee honest behavior among data availability managers and reduce trust assumptions. If these participants fail to prove data availability, the stake will be slashed.

In a bounded data availability scheme, once the required tokens are staked, anyone can be assigned to store off-chain data. This expands the number of eligible data availability witnesses, reducing the centralization risk on the Data Availability Committee (DAC). More importantly, this approach relies on cryptographic economic incentives to deter malicious activities, making it more secure than relying on trusted parties to protect offline data.

Pros and Cons of Validium:

+ve: Validium shares many advantages and disadvantages of zk-rollups:

1) Validity proofs enforce the integrity of off-chain transactions and prevent operators from using invalid states to update

2) Fast Transaction Speed. No delays when withdrawing funds to Ethereum (no fraud proofs needed)

3) Suited for specific use cases, such as transactions prioritizing privacy & scalability or blockchain gaming. (For example, DeversiFi is a DEX V1.0 that uses a Layer 2 network (Validium) to achieve private and scalable off-chain transactions. One of the main reasons for choosing an off-chain data solution is that their clients — professional traders — cannot have their trading history on-chain as it would expose their strategies to competitors.)

4) Off-chain data availability enables higher throughput.

5) Reduces users' gas fees by not publishing transaction data to the Ethereum mainnet

6) Exponential scalability growth will support higher liquidity, becoming a key feature of emerging DEX platforms

-ve:

1) Slow development speed due to high computational and complexity requirements of Validium, making it not cost-effective for low-throughput applications.

2) Consequently, limited application adoption. Not as many applications and iterations as Optimistic Rollups.

3) Currently challenging to support the Ethereum Virtual Machine (EVM), making it difficult to run smart contracts, DeFi protocols, and other decentralized applications.

4) Centralization risks on the hardware side. Generating validity proofs requires specialized hardware, and hardware monopolies could potentially lead to centralized control of the chain.

5) Relies on trust assumptions and cryptographic-economic incentives, unlike ZK-Rollups, which rely purely on cryptographic security mechanisms.

6) Issue with off-chain data availability: Data required to create or validate Merkle proofs may be unavailable. This means that if an operator misbehaves, users may not be able to withdraw funds from on-chain contracts. Even with a data availability committee, there is still a risk of centralization.

Validium Project:

from https://l2beat.com/scaling/tvl/, 22/09/2022

E. Volition

Here an additional hybrid approach can be highlighted—the concept of volition established by StarkWare: combining ZK-Rollup and Validium, it allows users to switch between the two scaling solutions. Through Volition, users can leverage Validium's off-chain data availability for certain transactions while retaining the freedom to switch to an on-chain data availability solution (ZK-Rollup) when needed. This essentially enables users to make trade-offs based on their unique circumstances.

https://medium.com/starkware/volition-and-the-emerging-data-availability-spectrum-87e8bfa09bb

Example: The concept of volition is used in zkSync 2.0. Their L2 state is divided into two aspects: zkRollup with on-chain data availability and zkPorter with off-chain data availability. These two parts will be composable and interoperable.

IV. Summary:

Comparing various solutions, rollup effectively ensures state validity + data availability, retaining the advantages of previous solutions while addressing their limitations. Thus, it has become a leader in the current scalability field.

In the roll-up solution, in the short term, optimistic rollup technology is more mature and widely used. Optimistic rollup may prevail in general EVM computation, while ZK rollup may prevail in simple payments, exchanges, and other application-specific use cases.

However, in the long run, most of the weaknesses of ZK Rollup are essentially technical issues. With a large number of excellent developers involved in relevant research, ZK Rollup will be a superior scaling solution in the future. The fundamental principles of ZK-Rollup technology will enable it to replace Optimistic Rollups, with the ability to achieve faster speed, higher security, more complete performance, leading to wider adoption. Currently, many Layer 2 projects like Loopring, zkSync, and Polygon are already attempting to introduce the zk-EVM computational environment, allowing ZK-Rollups to independently run all types of general-purpose smart contracts.

There will be more integration in the future. From the perspective of the development of scaling solutions, Ethereum's scalability cannot be achieved by a single solution. Many solution providers are also exploring and laying out on multiple paths. I personally believe this will inevitably lead to more integrated solutions (e.g., Optimism's "Bedrock"; StarkEx's Volition; Polygon).

After reading this article, you should intuitively feel that the iterative development of scalability solutions often involves realizing the limitations of one solution and then proposing another solution that retains the strengths as much as possible, addresses the weaknesses, and breaks through the limitations. Just like how for a long time, developers believed that Plasma was "the right one" until they recognized its insurmountable limitations, leading to the exploration of roll-ups. Currently, roll-ups seem to be the universally acknowledged answer, but perhaps with further exploration, a superior solution that disrupts roll-ups may emerge?

Lastly, as I organize my thoughts, it seems that there are countless trajectories for these scalability solutions. For someone like me, an individual investor at the secondary level, it feels like I can take it slow, wait for projects to implement layer-two transactions. The pace of change is too rapid, and just when you think you've figured things out, they realize it's not working and change direction (like Plasma). Therefore, identifying a major trend, casting a wide net, and diversifying investments may be a somewhat naive but effective approach. However, this secondary-level thinking may not apply to the primary level, where ultimately it comes down to evaluating the team, the network behind the project, and available resources.