This article explains the full plan for the expansion of Ethereum

Today, I mainly sorted out the expansion plans of Ethereum from a top-down perspective combined with time development. The content covers some old plans that are no longer mentioned in the market today, and some of them may not be heard of by everyone. But I think it is very important to clarify the big framework and mutual logic, which helps us understand what innovations and combinations have been experienced in the development of expansion, what problems have been encountered, what are the market concerns in different periods, and why the current Rollup The plan wins. These also help us see the general direction.

When I was doing research, I found that there are basically not many articles on the Internet that comprehensively summarize and compare from this perspective. At first, it was purely because I didn’t understand expansion at all, and I felt that there were many solutions, each with its own advantages and disadvantages, some of which were very similar, and I didn’t understand why, so I spent a lot of time digging for articles from different periods. But in the past two weeks, I realized that organizing with a time perspective has helped me a lot. However, the amount of information today should be very large, because it will inevitably involve a lot of technologies and concepts. If you can read it patiently, I believe it will be very helpful to build a large framework and logical sorting of the entire expansion track.

1. Cause

On the first layer of the Ethereum blockchain, the ever-increasing demand for network usage has led to network congestion, driving up transaction costs. Increased storage, network speed, and throughput are fundamental to meaningful mass adoption of Ethereum.

• What’s Layer3? Discover the evolution of Layer1 to Layer3 in this article
• Blockchain and Interoperability: Globalization 3.0

Therefore, scaling is required.

2. Purpose

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

3. Expansion plan

Expansion scheme: can be divided into two categories – On-Chain (layer 1) and Off-Chain (side chain + layer 2)

• On-chain, on-chain scalingImprovements to the performance of the blockchain itself, which require changes to the Layer 1 mainnet/Ethereum protocol: this involves “Layer 1”. Layer 1 network is another name for the underlying blockchain. In addition to Ethereum (ETH), Bitcoin (BTC), Solana, Polkadot, Near, Cosmos, Aptos, Sui, etc. all belong to layer1 protocols because they are the main networks in the ecosystem. Layer 1 protocols are able to process and complete transactions on their own blockchains, with native tokens for paying transaction fees.(The expansion of the entire Layer 1 is a very important part of the Ethereum upgrade. This part can be detailed in the Ethereum upgrade and sharing in the future. Today, Layer 1 will briefly summarize the concepts, and will not go into details.)

Options for On-Chain Layer 1 expansion include:

a. Change the consensus mechanism . The Ethereum upgrade took this approach. The successful merger of the beacon beacon chain and the main network a few weeks ago completed the conversion of the consensus mechanism from pow to pos.

b. Implement sharding. Sharding is a common Layer 1 scaling solution primarily used to increase transaction throughput. This is a database partitioning technique in computer science. The network is divided into different shards together with the above nodes to spread the workload and improve the transaction speed. Each shard handles a part of the activity of the entire network, i.e. each shard has its own transactions, its own nodes and independent blocks.

Sharding also reduces the burden on each validator (since they no longer need to process and save all transactions for the entire network). Each node will write the completed work to the main chain and share local data in real time. This is the expansion plan involved in the original upgrade plan of eth 2.0, which has been replaced by danksharding.

c. Expand the block size. Enable each block to process more transactions (currently, Ethereum upgrade proto-danksharding is a similar solution, and a single share will be issued after the upgrade).

Layer 1 expansion requires a lot of trouble. In many cases, not all Internet users will agree to such changes. This may lead to community splits and even hard forks. (Bitcoin split into Bitcoin Cash in 2017 as a consequence of the hard fork)

• Off-chain, off-chain scalingAll off-chain scaling is implemented separately from the Layer 1 mainnet without changing the existing Ethereum protocol. Rollup can be roughly divided into two categories: Ⅰ. Side chain; Ⅱ. Layer2 solution.

Ⅰ. Side chain

Sidechains are independent blockchains whose security depends entirely on their own protocol mechanisms. This is also the biggest difference between the sidechain and the current mainstream off-chain scaling solution layer2.

Compared with some layer1 public chains as an independent chain, the difference between the side chain is that the side chain is specially used to deal with the excess capacity of Ethereum, rather than competing with the entire Ethereum. These ecosystems are tightly integrated with the Ethereum community to host Ethereum applications in complementary ways.

Regarding this part of the classification, I found that many articles on the Internet are quite confusing, and the sidechains are classified in layer2. In this part, I mainly refer to the definition of the side chain by the Ethereum Foundation and the side chain white paper.

The second type of off-chain scaling is the layer2 solution mentioned just now and often heard of: the basic idea is off-chain calculation/execution, and the result on-chain; offline batch processing. Get security directly from the first layer of Ethereum consensus. The different layer2 solutions will find a balance between security, scalability efficiency, decentralization, and versatility.

Let’s talk about sidechains first:

Side Chains is an independent blockchain that operates in parallel and independently of the Ethereum mainnet.

They are usually designed to process transactions efficiently. The biggest difference from the second layer scaling scheme is that sidechains do not publish state changes and transaction data back to the Ethereum mainnet, which is why they do not inherit the security properties of Ethereum.

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

Sidechains are mainly linked to and interoperable with the mainnet through a two-way pegged cross-chain bridge (a concept we will discuss in detail shortly). The so-called two-way anchoring here mainly refers to the two-way anchoring of supporting assets , that is, the mutual transfer of assets between the main chain and the side chain. However, it should be noted here that in fact, the assets are not transferred in the true sense, but are only “cross-chain” through the method of “locking in one chain and casting assets of the same denomination in the other chain”. Any project that erects a two-way anchored cross-chain bridge can be regarded as a side chain.

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

This concept was proposed by BlockStream in the sidechain white paper published in 2014. Two-way anchoring refers to locking an asset on the main chain, such as 10eth, to a specific address; at the same time, providing evidence of this “locked transaction” on the side chain, the same amount of digital assets will be in the form of wrapped tokens. Mint on the side chain, for example, mint 10 weth on the side chain, and now this 10 weth can be traded on the side chain. Vice versa, when users want to withdraw eth from the main chain, they can destroy the remaining wrapped eth of the same denomination on the side chain.

The token is locked in the main chain, and the token is minted (wrapped) in the side chain. Destroy/burn tokens on the side chain and withdraw tokens on the main chain.

The working environment of the side chain is the same as that of the main chain, which is also based on EVM (Ethereum Virtual Machine). But sidechains have their own ledger systems, consensus algorithms (such as Proof of Authority, Delegated Proof of Stake, Byzantine Fault Tolerance) script contracts, etc. But in order to achieve a variety of different goals, they also achieve security in different ways.

Here are a few examples:

1. Single escrow model Centralized (basic third party authority) : This is the easiest way to transfer digital assets between blockchains at this stage – send the assets on the main chain to a single custodian (such as a trading platform), escrow After receiving the asset, the party activates the equivalent asset on the side chain, and the asset can be circulated on the side chain. The biggest disadvantage of this method is that it is too centralized.
2. 
3. Federation mode Federation – multisig federation: The federation mode uses a notary alliance to replace a single custodian, and uses the notary alliance’s multi-signature to confirm the flow of digital assets on the side chain. In this model, if you want to steal the digital assets frozen on the main chain, you need to break through more institutions, but the security of the side chain still depends on the honesty of the notary alliance. This method is still centralized.
4. SPV (simple payment verification) mode : The above two schemes are both guaranteed by intermediaries and are centralized.SPV (Simplified Payment Verification), that is, simple payment verification is a more secure decentralized method.SPV is a concept mentioned by Nakamoto in the “Bitcoin White Paper” (“Enabling Blockchain Innovations with Pegged Sidechains” everyone is interested to read, I put the link below). This is also a very important concept in the underlying technology of Bitcoin.SPV is a method for proving the existence of a transaction, which is characterized by the fact that a small amount of data can be used to verify the existence of a transaction in a particular block. In SPV mode:1. The user sends the asset on the main chain to a special address on the main chain to lock the asset in the main chain.2. Waiting for a confirmation period on the main chain refers to the period during which coins must be locked on the parent chain before being transferred to the side chain. The purpose of this confirmation period is to generate enough workload to make denial of service attacks more difficult during the next waiting period. A typical confirmation period can be on the order of one or two days.When a special output is generated on the parent chain, the user waits for the confirmation period to end, and then generates a transaction on the side chain that references the output, providing an SPV proof that it has been created and is covered by sufficient work on the parent chain, The confirmation period is a security parameter that depends on the side chain, and there is a trade-off between cross-chain transaction speed and security.3. After the main chain confirmation period ends and the assets are determined to be locked, an SPV proof will be created and sent to the side chain. Then a corresponding transaction with this SPV certificate will appear on the side chain, and this transaction will generate the same value of the side chain token asset on the side chain.4. The generated sidechain assets are locked first, and then users must wait for a competition period . During this period, newly transferred coins cannot be spent on the sidechain. The purpose of the contest period is to prevent double-spending during reorganization, and transfer previously locked coins away during the reorganization. At any point during this delay period, if a new proof of work is issued and the corresponding chain with more accumulated work does not contain the block that generated the locked output, then the transition will be retroactively invalidated. We call this proof of reorganization and need to wait for a contention period to prevent double spending. If during the competition period, the user transfers the coins locked on the main chain, and other users can prove this with the latest SPV, the side chain minting transaction will be invalid, which is called the reorganization proof.Whenever possible, users on all sidechains will have an incentive to issue proofs of reorganization, as the admission of bad proofs will dilute the value of all coins.5. A typical contest period is also one or two days. After the competition period ends, sidechain tokens are generated and can be freely transferred within the sidechain without further interaction with the parent chain. However, it still retains the identity of the parent chain coin and can only be transferred back to the chain it came from.6. When the user wants to transfer coins from the side chain back to the parent chain, the process repeats the above steps: send coins to an SPV-locked output on the side chain, generate a sufficient SPV proof to indicate that the output has been completed, use This proof unlocks the previously locked equivalent output on the parent chain.
5. 
6. (Less important) Drivechain model Drivechain : The drivechain concept was proposed by Bitcoin Hivemind founder Paul Sztorc. In the drive chain, the miner is the ‘algorithm agent guardian’, which detects the current state of the side chain. Miners are equivalent to the custodian of funds, and the drive chain will release the custody of the locked assets to the miners, and allow the miners to vote when to resolve and where to send the unlocked assets. Miners observe the state of the sidechain, and when they receive a request from the sidechain, they execute a coordination protocol to ensure they agree on the authenticity of the request. The higher the participation of honest miners in the drive chain, the greater the overall system security.
7. (Less important) Hybrid mode: drive chain + notary/side chain and hybrid mode is a mode that effectively combines the above methods of obtaining bidirectional anchoring. Because the main chain and the side chain are fundamentally different in the realization mechanism, the symmetrical two-way anchoring model may not be perfect. The hybrid mode is to use different unlocking methods on the main chain and side chain, such as using the SPV mode on the side chain, and using the drive chain mode on the main chain network.

• Data Availability (DA):In terms of data validity, because the side chain says that the data is stored on the side chain and not anchored back, it can only be guaranteed by the side chain’s own validator, and the security is much weaker.

Sidechain project:

Polygon – Projects range from a single Layer 2 plasma solution (formerly Matic Network) to eventually expanding into a current scaling framework that can be used to create Ethereum-compatible blockchain networks and scaling solutions. (It’s more of a protocol than a single solution.) Its goal is to build a polygon-like multi-chain network around Ethereum development kit). Among them, the Polygon POS side chain is regarded as the leader of the track. The Polygon team believes that in the future, Ethereum will remain the dominant blockchain for high-value transactions and stores of value, while day-to-day transactions will move to Polygon’s low-cost blockchain. Therefore, the polygon pos sidechain provides value by assisting the expansion of Ethereum, rather than directly competing with the Ethereum main network to grab the market.

Gnosis Chain – Formerly known as the xDai side chain, Gnosis Chain was later developed by merging with Gnosis. Low cost and Ethereum compatibility are the two main selling points of gnosis chain.

Skale – Positioning Competition as Ethereum ‘s “elastic sidechain network” capable of supporting thousands of independent blockchains, sidechains, storage chains and other types of subchains. These blockchains are all connected to the Ethereum mainnet and are fully compatible with the Ethereum ecosystem.

Palm – Joseph Lubin, co-creator of Ethereum, David Heyman, founder of ConsenSys, filmmaker and owner of Heyday Films, and Joe Hage, founder of art technology group HENI Group. This is an Ethereum sidechain that allows users to build NFTs.

Ronin – A chain game-based sidechain launched by Sky Mavis, the developer of chain game Axie Infinity. As games require fast interactions and low fees to scale and facilitate the thousands or even millions of transactions that take place every day. The user experience has to be friendly and silky. So the team simply did it themselves.

Sharded chain – The sharded chain in the original eth upgrade scheme (eth 2.0) is also a sidechain variant of eth itself.

Advantages and disadvantages :

+ve:

1) The compatibility of the side chain is very good, it supports general computing, is EVM compatible, and can support smart contracts.

2) Involving large-scale and complex transactions, the tps of the side chain can reach very high. The design of the comparative side chain is to sacrifice some decentralization or security measures to achieve high throughput (this part can refer to the impossible triangle of blockchain).

3) The main purpose of the side chain is to reduce the congestion on the main chain, reduce the cost of each person, and increase the usability 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 the earliest side chain appear? It was 2012, when the core development team of Bitcoin was considering how to safely upgrade the Bitcoin protocol to add new functions, but was worried that it would be dangerous to add functions directly on the Bitcoin blockchain, because if the new functions were implemented in practice A software glitch occurs in the existing Bitcoin network, which can have serious consequences. In addition, due to the characteristics of Bitcoin’s network structure, if a large-scale change is made, it is necessary to obtain the support of the majority of Bitcoin miners. At this time, Bitcoin Core developers proposed a sidechain solution.

Therefore, the earliest sidechains are to allow developers to explore the nature of adding new functions to other blockchains, and then attach these sidechains to the existing Bitcoin blockchain. To protect the Bitcoin parent chain network.

-ve:

1) The main difference between sidechains and rollup and channel is that both rollup and channel inherit the security of the Ethereum main network, but sidechains are usually designed for specific types of transactions because they use their own consensus mechanism ( The purpose is to make transactions faster and more affordable), which also means that they generally do not inherit the security properties of Ethereum. Technically, sidechain solutions are not part of layer2.

2) The degree of decentralization is low.

3) Compared with the channel scheme, the privacy of the side chain is weaker, because on the side chain, every transaction will be published on the side chain, regardless of whether it interacts with all participants on the side chain, the transaction will be published on the side chain Each participant receives.

Ⅱ. Layer2 solution

The basic idea is to calculate/execute off-chain and upload the results to the chain; batch data offline. In this way, security is directly obtained from the first layer of Ethereum consensus, and the scheme includes:

A. Channel channel

This is a very early and long-standing blockchain scaling solution, and its most famous application is Bitcoin’s Lightning Network. Focus more on security than usability.

Participants must lock a portion of the Ethereum state, such as ETH deposits, in a multisig contract. Locking the initial state is the first transaction and opens the channel. Participants can then transact quickly and freely off-chain. When the interaction is over, submit the final state to the chain and close the channel.

This can be subdivided into two payment channels, Payment Channel and State Channel:

• Payment Channel : Now a multi-signature contract address is built on the main chain. For example, A and B have created such a multi-signature contract, and funds can only be transferred with their mutual consent. Deposit their respective money, assuming that A and B each deposit 10eth, this initial state is equivalent to opening a payment channel. Then off-chain they conduct dozens or even thousands of transactions, each of which needs to be signed and time-stamped by both parties. Finally A has 5eth B has 15eth. But instead of recording so many transactions on the blockchain, they only need to record two—the initial funding transaction and the final balance distribution after all transactions are closed. When they upload the final balance to the main chain, it is equivalent to closing the payment channel.For A and B, those transactions off-chain have no fees and are almost instant. Both parties do not have to pay miner fees and do not have to wait for block confirmation.
• State Channel : This is actually a derivation of the Payment Channel. Judging from the name, this solution is based on “state”, that is, not only the transaction state, but also the game state, the active state, etc. For example, to start a game of backgammon, they need to create a new “judging” program and provide it with an initial wager, so that the state channel is turned on. The process of their moves is not submitted to the blockchain as a transaction. But each step needs to be signed and timestamped by both parties before taking the next step. Only when the program decides one side wins according to the rules, the game is over, a and b sign a state update that simply allocates bets based on how the game ends. This is equivalent to the state channel being closed.
• Data Availability Data Availability (DA):

All data is stored in Layer 2, and DA is guaranteed by both Channel parties (the whole process of transfer or game needs to be maintained by the participants a and b themselves)

• State Validity (SV):

After the channel ends, either party can submit the final state to Layer 1, but Layer 1 does not verify, but first requires the submitter to pledge. Then there will be a week of Fraud Proof, where anyone can settle doubts on the pen and submit a proof (prove the status is wrong). This question is verifiable. As mentioned just now, each offline transfer and behavior requires both parties’ signatures and a timestamp. Therefore, as long as the fraud proof provided by the questioner shows that it is signed and updated more than before, this is a verifiable fraud proof. This proof becomes the latest state, and the coins pledged by the person who previously submitted the state are deducted.

Channel item :

BTC’s Lightning Network lightening network

Advantages and disadvantages:

+ve:

1) The channel is mainly for high frequency and small payment.

2) Save a lot of transaction time and fees. Especially in terms of transaction fees, there is an initial cost to create a channel. But once deployed, every state update inside the channel is very cheap. Only two transactions are actually recorded on-chain.

3) State validity SV can be well guaranteed by fraud proofs.

4) State channels have strong privacy properties – because everything happens in the channel instead of being broadcast publicly and recorded on-chain. Only opening and closing transfers must be public. But in the sidechain system, every transfer is posted on the sidechain, and then every participant on the sidechain receives it,

5) State channels have instant finality – that is, as long as two parties sign the state update, the state is considered complete.

-ve:

1) The withdrawal of coins is slow, and it takes 1 week for fraud proof to be able to withdraw coins

2) For users who occasionally transfer money to the other party, the time and economic cost of creating and settlement channels are relatively high, which is not very friendly. Because you also need to create multi-signature contracts, sign, design judging procedures…

3) Open participation is not supported. Channels cannot be used to send off-chain funds to people who have not participated

4) TPS is average, more suitable for a small number of participants, if it is a large-scale complex transaction, the performance cannot keep up.

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

6) The state channel requires all participants to be 100% online, and the pledged tokens will be deducted if the participant leaves midway.

7) Channels cannot be used to represent objects without a clear logical owner (e.g. Uniswap). Therefore, the channel-only channel cannot be used to represent objects without a clear logical owner (such as Uniswap). It is suitable for applications with a defined set of participants. Although participants can be added and removed, it needs to be used for the contract every time. make changes.

B. Plasma

Due to the limitation of Channel’s “inability to support large-scale, large capital and complex transactions”, the Plasma solution came into being. It combines some designs of the side chain, solves the problem of sending assets to any target person, and also ensures the improvement of TPS. In fact, Plasma was considered “the right one” for a long time when developers started working on Layer2 solutions.

But as it was later replaced by Layer 2 due to some flaws, here is a brief introduction to everyone:

Plasma is an independent blockchain. The original design also wanted to retain the main purpose of the side chain. It can be expanded through off-chain transactions, and at the same time, it can solve the security problem of the side chain itself to a certain extent (that is, when the sub-chain encounters When attacked, the assets stored on the sub-chain are always safe), so some performances of the side chain (such as executing smart contracts, etc.) are given up after the trade-off, but the block is anchored back to the main network to increase security. The two biggest differences between him and the side chain are:

1) The side chain uses the bridge method to exchange assets with the main chain, but the security of the side chain depends on its own consensus mechanism. And sidechains tend to be much smaller than the mainnet. But plasma publishes the state information of each block of itself to the Ethereum main network in the form of block root. Therefore, the status information on the plasma chain can be confirmed on the Ethereum main network (only the specific transaction data storage on the sub-chain needs to be downloaded and saved by the user. The Ethereum main chain only assumes the role of the confirmer in this process, not the validator, so its security level is poor). Therefore Plasma chains are also called “child” chains because they are essentially smaller copies of the “parent” Ethereum chain. This means that it inherits part of the security of the main chain, so it also belongs to the layer2 scheme .

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

• Unlimited creation of “chain-in-chain”:

Each Plasma can create infinitely more sub-chains to reduce the workload of the parent chain. Each sub-chain has a role called “Operator”.

• Operator periodic “state commitments”:

All off-chain transactions are first aggregated to the operator of the sub-chain, and then (because the sub-chain is to be anchored back to the main chain) the operator periodically aggregates the calculation results of the sub-chain, and packs and compresses them into a block in the form of a Merkle tree. Block root, and finally submit the block back to the main chain for status record. This is the so-called periodic commit “state commitment”. In this way, no matter how many transactions occur on the sub-chain during the two submission periods, the sub-chain only needs to submit the status information caused by the transaction execution to the main chain. The transaction data will not be submitted to the main chain.

• Entrance – Mainnet Contract:

Like sidechains, Plasma uses a main contract running on Ethereum to handle user entry and exit. Users must deposit ETH or any ERC-20 token in the main contract. The Plasma operator monitoring the contract deposits 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:

Then, when launching the plasma chain, that is, when withdrawing money, plasma introduced the previously mentioned “challenge period” to punish dishonesty and ensure the validity of the state by means of fraud proof. This main contract is also responsible for keeping track of state commitments (explained earlier) and punishing dishonesty with fraud proofs. “Fraud proof” means that anyone during this challenge period (usually 7 days or more) can submit a proof that the withdrawal of user assets is illegal through Merkle tree verification.

Drawn by RJ

• State Root State Root:

First of all, I just mentioned that Plasma has a (or a series of interrelated) contracts on the main chain to maintain the state record in the plasma sub-chain. This state record is actually stored by the root node of a Merkle tree. Hash value, this hash value is called state root.

Specific explanation: Merkle tree (a binary tree), which records the status information of the current rollup layer account on the leaf node of the binary tree.

For every two state information (such as State 1/State 2), we can calculate a unique hash value (eg: Hash(1,2) ) according to a certain hash formula as the parent of these two leaf nodes Nodes, layer by layer, and so on, eventually get 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 cause the Root hash to change.

2) If the root hash values ​​of the two trees are the same, it means that the information stored in their leaf nodes is completely consistent (so it is only necessary to compare the hash values ​​of the two root nodes to confirm the consistency of the underlying state information).

3) According to the hash value of the root node and the downloaded adjacent hash value, we can confirm that a certain state information exists in this hash tree.

Drawn by RJ

When a transaction occurs on the rollup, a new state root is generated. At this time, users of any sub-chain can compare and prove whether the new state root is correct according to the transaction information downloaded and recorded on the sub-chain. (Because I mentioned just now, as long as the recorded transactions/leaf nodes are completely consistent, the root hash value must be the same.

To keep their funds completely safe, users (aka potential “validators”) need to observe the Plasma chain at regular intervals to record transactions on the chain. This includes running a software that automatically syncs (downloads) the plasma chain and ensures that everything works as expected. Users should run the software at least every few days, but the exact time depends on the parameters set by the Plasma MVP smart contract.

If the plasma chain is functioning properly, the user does not need to do anything else. However, in the event of an irreversible error (hopefully rare), the user’s wallet will automatically start withdrawing funds from the Plasma chain. This automatic withdrawal keeps user funds safe, even in the worst-case scenario, when malicious operators try to steal funds.

• Data not available:

But Plasma has a big problem, which is the unavailability of data. Fraud proof effectively prevents users from doing evil, and also ensures that as long as there is even one honest node, the security of the chain can be guaranteed. But what if the operator is doing evil, and the user/verifier has no relevant transaction information that can prove the authenticity? Since the premise that the user can submit the fraud proof is that the user has recorded the transaction data on the sub-chain by himself + the operator has packaged all real transaction data on the main chain, so when the operator submits invalid data maliciously, only the relevant information required for fraud prevention needs to be included. With information hiding, users in the network cannot get real information to prove that the transaction is invalid.

• Mass Exit:

Since the problem of “the operator is evil” cannot be effectively prevented in the plasma solution, we can only find a solution. Plasma has designed a “mass exit” plan, but this plan may cause the entire network congestion of Ethereum itself…

Plasma project:

Matic used plasma in its earliest days, and blockchain researchers discovered data availability issues (discussed further later in the report) shortly thereafter, causing Plasma to be deprecated by other solutions. After the name change, the polygon project has been transformed into an all-round, full-site expansion plan.

Advantages and disadvantages:

+ve:

1) Provide high throughput and

2) Low cost per transaction.

3) Applicable to transactions between any user. The user can send the asset to someone other than plasma, and the recipient can go back to plasma at any point in time as long as he has the proof of receipt and cash it out. Whereas if both are built on the Plasma chain, there is no overhead per user pair. So plasma can also be adapted to specific use cases that are not related to the main chain. Anyone, including businesses, can customize Plasma smart contracts to provide a scalable infrastructure that works in different environments.

4) There is no need to lock funds in advance like channels.

5) High security, the security of plasma depends to some extent on the main network. (fraud prove fraud proof) The validator of the side chain regularly transmits the state root state root to the main chain, but the main chain does not verify it, allowing anyone to submit challenges and fraud proofs within a week. This ensures the validity of the sv state.

-ve:

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

2) Fixed submission period, if you pay within this period, the payment will not be confirmed, you need to wait for the period to arrive.

3) Withdrawals are slow and usually take 7 days to allow for challenge and fraud proofs to be submitted.

4) Need to regularly observe the network (activeness requirement) or delegate this responsibility to someone else to keep funds safe

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

6) The Ethereum mainnet could become congested if too many users try to exit at the same time.

Therefore, it can be seen here that the core advantage of Plasma and Channel channels is that users can send assets to participants who have never participated in the system, and the capital requirements are much lower. But the price is: Channel channels do not require any data to run on-chain, but Plasma requires each chain to publish a hash value periodically. Furthermore, Plasma transfers are not instant: the user must wait for the challenge right to end.

However, the core problem of plasma itself is that in order to improve efficiency, the Plasma sub-chain will only regularly submit its status results to the main chain instead of all transaction data. But the price of this is that Plasma cannot establish the same level of trust as the Ethereum main chain, because the responsibility of ensuring “data validity” falls on the “operator”, not the Ethereum main network. But operators have motives to do evil.

So, there is a roll-up plan…

C. Roll-Up:

Rollup is currently the most mainstream scaling solution. It can be regarded as a compromise between the original main chain processing method and the Plasma method: like plasma, it executes transactions outside the Ethereum main chain (that is, one layer), and then batches multiple transactions into batches. together, and finally send their state back to the Ethereum main network. But the difference is that 1) rollup will also submit transaction data to the main chain, 2) rollup will compress these transaction data to the maximum extent, and at the same time delete and reduce part of the data appropriately based on the characteristics of rollup itself, as long as the final submission is guaranteed It can be on the main chain for anyone to verify. (The two roll-ups are based on plasma and provide different proof schemes for the transaction data part.)

Therefore, Rollup is more secure than Plasma. And his core advantage is to ensure state validity + data availability at the same time .

How exactly is Roll-up implemented?

• State Root (mentioned earlier):

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

Specific explanation: Merkle tree (a binary tree), which records the status information of the current rollup layer account on the leaf node of the binary tree.

For every two state information (such as State 1/State 2), we can calculate a unique hash value (eg: Hash(1,2) ) according to a certain hash formula as the parent of these two leaf nodes Node, layer by layer, and so on, and finally get a hash value stored in the root node: we don’t need to know how to calculate the hash value, we just need to remember a few things.

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

2. If the root hash values ​​of the two trees are the same, it means that the information stored in their leaf nodes is completely consistent (so it is only necessary to compare the hash values ​​of the two root nodes to confirm the consistency of the underlying state information;

3. According to the hash value of the root node and the downloaded adjacent hash value, we can confirm that a certain state information exists in this hash tree.

Drawn by RJ

• Batch (this is also a great improvement of rollup):

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

However, if each transaction is signed and the state root is updated on the main chain, the cost will be higher than that of executing these transactions on Layer 1.

Therefore, the transactions generated in the rollup are packaged and summarized in batches, and a new state root will be generated according to the status of all the transactions after the execution of this batch of transactions. Whoever packages the transaction and submits it to the smart contract on the main chain needs to calculate the new state root and submit it together with the previous state root and transaction data.

This part of the packaging is called a “batch”. After the operator submits the batch to the Rollup contract, the main chain will verify whether the new state root is correct. If the verification is passed, the state root will be updated to the latest submitted state root. And finally complete a state transition confirmation within a rollup.

Therefore, the essence of Rollup is to aggregate a large number of actually generated transactions into a transaction on the main chain. These transactions are executed and calculated by the Rollup chain, but the data is submitted to the main chain. This not only utilizes the consensus and security of the main chain, but also improves the actual transaction efficiency and reduces transaction costs.

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

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

• compression:

These two technical solutions can be expanded, and the core is the compression and packaging of transaction data (as mentioned earlier, a major improvement of rollup is to upload transaction data to the chain, so “compression” is for this part). This is because the block gas limit of Ethereum has an upper limit. The smaller the compressed transaction, the more transactions that can be submitted to the main chain at one time, and the lower the amortized fee. So how to do this?

The following is a zk compression mode described by Vitalik in his article, as an example to help us understand:

A simple transaction on the Ethereum main chain (such as sending ETH) 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 such a compression effect, on the one hand, simpler and advanced coding is used, and on the other hand, there are some clever compression techniques.

This chart is very interesting. Regardless of rollup, transactions on the Ethereum network generally involve these parameters:

Nonce: The purpose of this parameter is to prevent replay. If an account’s current nonce is 5, the nonce in the account will be increased to 6 after the next transaction from that account is processed. Generally speaking, the nonce can reach tens of thousands, but it can dynamically shorten the bytes through rlp encoding, so the nonce on the Ethereum network is about 3 bytes.

Gasprice: a number in the unit of 10 to the negative 18th power, also rl-encoded, about 8 bytes

Gas: This refers to the amount of gas you are willing to pay, which is generally not much. Generally, the gas limit of a block in Ethereum is 20 million gas. Generally, a transfer transaction gas is about 20,000, and a contract is about 100,000-200,000, at most hundreds of thousands. So the average here is about 3 bytes

To: An address on Ethereum is almost 21 bytes, and the Ethereum address range is very large

Value: Refers to the amount of money when transferring. In many cases, the value of the contract is 0, because you do not need to transfer money to the contract. But for example, if I transfer 5eth to you, then the value has a value. The unit is also the negative 18th power of 10, rlp encoding, almost 9 bytes

Signature: The signature is relatively fixed and about 68 bytes

So in this calculation, there are about 112 eth transactions. Because the roll-up is sent to L2, as long as the complete information can be expressed, the L2 scheme can be customized. But this information he can pick, and compress. for example:

Nonce: The nonce can be completely omitted in the rollup. Because the nonce is completely recoverable from pre-state.

GasPrice: It is possible to set a fixed fee level per batch, or even move gas payments completely out of the aggregation protocol and let traders pay the batch creator through the channel.

Gas: You can set the gas limit at the batch level, choose some specific values,

To: A 20-byte address can be replaced by an index on the Merkle tree (e.g. if the address is the 4527th address added to the tree, we simply use the index “4527” to refer to it. It can be limited to 4 bytes

Value: Change the unit of money, or use other technical methods to store it.

Signature: Aggregate signatures using BLS, combining multiple signatures into one. The signature can then be verified against the entire “batch” of messages at once. Since the maximum number of verifiable aggregated signatures per block is 100, even a large batch of 100 signatures can be aggregated into one signature.

In the end, it saves about 12 bytes. In fact, it is equivalent to limiting the accuracy, but the information range remains unchanged, and almost complete information is still expressed. This is the point of why roll up can expand. But the reason for this expansion is mainly because on the main chain, the calldate is limited, because each byte of the calldate consumes a little gas on the main network, and the total gas amount of a blcok on the main chain is limited. So it limits the total number of bytes that calldata can include.

These compression techniques are the key to the expansion of rollup. If we do not compress the transaction data, the rollup may only be able to improve the efficiency by about 10 times on the basis of the main chain, but with these compression techniques, it is possible to achieve 100 times or more. High compression efficiency.

• Data availability:

How can I verify that the submitted information is available correctly?

A big difference between Roll-up and plasma is that it also submits transaction data to the main chain to ensure that anyone can verify it. So now it comes to how to verify that the submitted information is correct and available?

For this problem, there are generally two solutions, and according to the different solutions, rollup is also divided into two categories: Optimistic rollup optimistic rollup and Zero-knowledge (ZK) rollup zero-knowledge proof rollup.

a) Optimistic rollups , as the name suggests, they optimistically assume that all transactions are valid and commit batches without any initial proof. Anyone can detect and prove that data is fake during the challenge period.

Drawn by RJ

If the batch turns out to be fraudulent, Optimistic rollps performs the fraud proof and runs the correct transaction computation using the data available on the Ethereum main chain.

Fraud proof construction in optimistic roll-up can also be explained with the diagram just now (below):

The information contained in the batch includes pre-state root, post state root, and transaction information.

According to this part of the pre-state root, a complete Merkle tree can be constructed.

According to the transaction information, we can simulate and execute the transactions submitted in the batch, thereby obtaining the new account state, the new Merkle tree, and the new state root.

Compare the state root obtained in the previous step with the state root in the batch to verify whether the batch is correct.

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

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

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

In order to deter the submitter from doing evil, the submitter often needs to pledge funds, and when his submission is verified as wrong, a part of the pledge funds will be deducted as a penalty. At the same time, validators who submit the corresponding fraud proofs will receive a deducted deposit to incentivize the behavior of monitoring and submitting fraud proofs.

If we compare OR and Plasma, we will find some similarities, for example they both use a fraud proof mechanism, which requires a validator role to monitor the submission of OR to the main chain. However, since the OR submits transaction data to the main chain at the same time, the verifier on the OR does not need to save and record the transaction on the OR.

Drawn by RJ

Advantages and disadvantages:

+ve:

1) Provide high throughput

2) and low transaction costs

3) Roll-up transaction data is stored on the layer 1 chain, improving transparency, security, censorship resistance and decentralization. Provides a huge improvement in scalability without sacrificing security or trust.

4) The fraud proof of optimistic rollup guarantees the finality of trustlessness, the validity of the state, and allows an honest minority to protect the chain (in theory, even only one honest node can guarantee the security of the entire chain)

5) Optimistic rollup also ensures the availability of data by putting transaction data on the main network.

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

-ve:

1) Slow withdrawals, usually take 7 days to allow for challenge and fraud proofs to be submitted

2) The security model relies on at least one honest node executing aggregated transactions and submitting fraud proofs to challenge invalid state transitions.

3) Optimistic roll-up must publish all transaction data on the chain, which also requires a certain cost.

Optimistic Rollup project:

b) Another class of roll-up solutions is Zero-Knowledge rollup (ZK rollup)

First of all, what is the zero-knowledge proof ZKP?

Zero-knowledge proof (ZKP) is an important part of modern cryptography, which refers to the ability of the prover to convince the verifier that a certain statement is correct without providing any useful information to the verifier.

The prover proves to the verifier and convinces it that it knows or possesses a certain message, but the proof process cannot reveal any information about the proved message to the verifier. In layman’s terms it is:

It not only proves what it wants to prove, but at the same time the information disclosed to the verifier is “zero”. eg Sudoku

• completeness
• reliability
• zero knowledge

Different from Optimistic Rollup, ZK Rollup requires the submitter to carry a ” Evidence of Validity”. After the proof of validity is submitted to the mainnet roll-up contract, anyone can use it to verify that a particular batch of transactions in the zk Rollup layer is correct. The proof can be completed a few minutes after the batch is submitted. After the verification is successful, the main chain rollup contract will update the State root to the latest submitted data. This is basically equivalent to omitting the work of the validator and completing the verification at the same time as the commit.

This means: 1. zk Rol-Up omits the link of verifiers saving data and submitting fraud proofs during the challenge period (as shown in the figure below); 2. It is no longer necessary to wait 7-14 days for verification after submission. So the transaction speed is also much faster than other L2 solutions.

Drawn by RJ

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

1. zk-SNARK (Succinct Non-Interactive Argument of Knowledge)  is an acronym for Succinct Non-Interactive Argument of Knowledge. The characteristics of this scheme are concise, that is, the verification process does not involve a large amount of data transmission and the verification algorithm is simple, which means that the verification time does not increase exponentially with the computing throughput .
2. zk-STARKs (Scalable Transparent Argument of Knowledge)  are Scalable Transparent Argument of Knowledge, created as an alternative to SNARKs. Different from the “S” of Succinct of SNARK, the “S” of STARK stands for Scalable (scalability), which is mainly manifested in the fact that the time complexity of STARK generation proof (Proof) is similar to the computational complexity (in a quasi-linear relationship), The time complexity of the verification proof (Verify Proof) is much smaller than the computational complexity. That is to say , as the scalability of STARK increases, the proof complexity of STARK does not increase accordingly.

However, since this part of zero-knowledge proof involves very complex underlying technologies and cryptographic concepts, this can be singled out and shared in the future. Today, I will briefly talk about it here, without going into specific details.

In summary, we know that several important compression techniques specific to ZK rollups are:

1. The size of the generated proof is much smaller than the size of the proof content (so much smaller than the bytes uploaded by the op to the mainnet).

2. If part of a transaction is only used for verification and has nothing to do with state updates, then that part can be off-chain, reducing bytes. But this cannot be done in an optimistic roll-up, as that data still needs to be included on-chain in case it needs to be checked later in a fraud proof (compare zk without a challenge period and fraud proof).

But the challenge of zk is that generating and verifying a zk proof itself requires very, very large and complex calculations, which is one of the reasons why the current ZK-Rollup development progress and practical application are very slow. And because of its technical complexity, not just any language, compilation environment, virtual machine, and instruction set can seamlessly support the completion of the above-mentioned process, and additional adaptation is required, which leads to the zk project being born with It is difficult to be compatible with evm (this part can also be discussed in detail in the sharing of zk in the future).

Here is the cost and TPS comparison of a different plan made by the @W3.Hitchhiker team:

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

Advantages and disadvantages:

+ve:

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

2) Due to the omission of validator work and the concept of a challenge period, once the proof of validity is verified on L1, the state update is approved, providing faster transaction finality. (No need to wait another 7-14 days)

3) The data availability of OR comes from economics. In order to operate well, OR must design a reasonable incentive mechanism to drive a group of validators on the main chain to monitor submitters at any time and prepare to submit fraud proofs, while the data availability of zk depends on cryptography and code.

4) Security depends on the security and consensus of the main network. Because the data needed to restore the off-chain state is all stored on L1, ensuring security, censorship resistance, and decentralization.

5) Better data compression helps reduce the cost of publishing calldata on Ethereum and minimizes the aggregate fees for users. It belongs to the most powerful and efficient solution at present.

6) So user transaction fees are also low.

-ve:

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

2) Therefore, it is not widely used. Not as many should and iterations as op

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

4) Centralization risk in hardware. Generating proofs of validity requires specialized hardware, and a hardware monopoly may lead to centralized control of the chain.

ZK Roll-Up Project:

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

Rollup summary:

It is now clear why the Roll-Up scheme can replace the Plasma scheme:

1) Efficiency – zk-rollup generates proof of validity of off-chain transaction processing. The steps of operators packing data, issuing “state commitments” and submitting user fraud proofs are simply omitted, thereby eliminating the need for challenge periods and exit mechanisms. It also means that users don’t have to regularly watch the chain to protect their funds.

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

Data Unavailable – As mentioned earlier, Plasma has 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 solve this problem by forcing operators to publish transaction data on Ethereum, allowing anyone to verify the state of the chain and create fraud proofs if necessary.

3) Mass dropout problem – Both ZK-rollups and Optimistic Rollups address Plasma’s mass dropout problem in different ways. For example, the encryption mechanism of ZK-rollup ensures that the operator cannot steal user funds under any circumstances.

Likewise, optimistic rollup imposes a delay period on withdrawals during which anyone can initiate a challenge and prevent malicious withdrawal requests. While this is similar to Plasma, the difference is that validators have access to the data needed to create fraud proofs. As such, the roll-up scenario would not involve a “massive rollout” that could damage the mainnet.

Buterin also emphasized in recent years that the future development route of Ethereum will be centered on roll up, the underlying chain provides guarantee for the data availability of the block, and the rollup guarantees the expansion and validity of the block.

However…

With the large-scale migration to layer 2, even rollups with strong compression capabilities will eventually return to the same scaling problem – because the rollup transaction data still has to be propagated to all full nodes, and its scaling is still limited by the data of Ethereum Processing power limitations.

Compared to the mainnet, Optimistic rollup can achieve 25x scalability upgrade, zk rollup can achieve 100x, about 3000 TPS.

It can be said that Rollup solutions provide linear growth, rather than exponential growth, in terms of capacity expansion. Is it possible to not only guarantee performance, but also provide exponential expansion growth?

So the StarkWare team created the Validium solution, an off-chain expansion solution that may reach 20,000-30,000 tps…

D. Validium Chain

It operates similarly to ZK rollup and also validates off-chain transactions on Ethereum by issuing zero-knowledge proofs, but the main difference is that Validiums data availability is off-chain. Because the throughput is not limited by the data processing capacity of Ethereum, so as to improve scalability, transaction speed, and reduce user fees (lower cost of publishing calldata).

• Deposits and withdrawals:

Deposits and withdrawals are also similar to rollups, where user deposits and withdrawals are controlled by smart contracts on Ethereum. By depositing ETH (or any ERC-compatible token) in the Ethereum main chain contract, users mint tokens equal to their deposit on the validium chain.

For withdrawals, validium users submit their withdrawal transactions to the operator. The user’s assets on the validium chain will also be destroyed before exiting the system. Once the validity proof of the batch is verified, the user can call the main contract to withdraw money by providing the merkle proof. So like zk-rollup, Validiums offers near-instant withdrawals.

• Batch batch:

Similar to rollup, users submit transactions to the operator, and the operator packages the transactions into batches and submits them to the main chain. Batches include state root/merkle root and proof of validity. To perform a state update, the operator must compute a new state root (after executing the transaction) and submit it to the contract on the main chain. If the validity proof passes, it will switch to the new state root.

Unlike ZK-rollup, operators on validium are not required to publish transaction data. This makes validium a pure off-chain scaling protocol.

Drawn by RJ

The main benefits of Validium’s off-chain data storage are further scalability (throughput not limited by Ethereum’s data processing capabilities), increased transaction speed, lower user fees (lower cost of publishing calldata), and protection of privacy since the public cannot Access transaction data on-chain.

• Data Availability:

However, the availability of off-chain data poses a problem – if the operator acts maliciously to hide off-chain state data from the user, and the user cannot access transaction data, then the user cannot calculate the Merkle proof needed to perform a withdrawal, the user’s funds will be frozen.

As shown in the figure below: If the operator changes trasaction 6, the owner of the transaction transaction1 will not be able to prove his account ownership, because the information of the node hash (5, 6, 7, 8) required in the proof process is lost.

(It sounds better than plasma. In the plasma scheme, the operator can steal user funds by doing evil. In validium, because it is not a fraud proof, but a validity proof, the worst case of an operator doing evil and hiding data is Freeze user funds so that they cannot be withdrawn…)

Therefore, it is necessary for Validium to adopt additional off-chain data management mechanisms to ensure that users can access off-chain transaction data when needed.

Validiums’ approaches to off-chain data availability management can be divided into two broad categories: some rely on trusted parties to store off-chain data; while others use randomly assigned validators to complete tasks.

Category 1: Data Availability Committee (DAC)

To solve this problem, StarkWare proposed the concept of Data Availability Council (DAC) to remove users’ trust dependence on operators.

By designating a set of trusted entities (collectively referred to as the Data Availability Council) to store off-chain data copies and make them publicly available in emergencies where the operator does not service users’ withdrawal requests access. With fewer members, a DAC is easier to implement and requires less coordination. But with it comes the risk of concentration.

Exit directly, without going through the carrier.

In an emergency, the mainnet Application Smart Contract (ASC) will no longer accept new status updates, instead allowing only users who can provide merkle proofs of the latest status to withdraw funds directly. That is to say, in this case, users can directly call the withdrawal function of the main contract to withdraw their funds without going through the operator.

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

However, users must trust the DAC to provide data when needed (eg, for generating Merkle proofs). Members of the Data Availability Council have the potential to be compromised by malicious actors who can then withhold off-chain data.

Category 2: Bounded Data Availability

This is to ensure the availability of off-chain data through economic incentives and decentralization. This scheme requires participants responsible for storing offline data to stake (i.e. lock) tokens in a smart contract before assuming their role. This token acts as a “bond” to guarantee honest behavior among data availability managers and reduce trust assumptions. If these participants fail to demonstrate data availability, the margin will be cut.

In a bound data availability scheme, anyone can be assigned to store off-chain data once the required tokens are staked. This expands the number of eligible data availability managers and reduces the risk of centralization affecting the Data Availability Council (DAC). What’s more, this approach relies on cryptoeconomic incentives to prevent malicious activity and is more secure than appointing trusted parties to protect offline data.

Pros and cons of Validium:

+ve: Many advantages and disadvantages of zk roll-up validium also have:

1) Proof of validity enforces the integrity of off-chain transactions and prevents operators from updating with invalid states

2) The transaction speed is fast. No delays when withdrawing funds to Ethereum (no fraud proof required)

3) Suitable for specific use cases such as transactions or blockchain games where privacy & scalability are a priority. (For example DeversiFi is a decentralized *exchange that uses a second layer network (Validium) for private transactions and scalability.* One of the main reasons for DEX V1.0 to choose an off-chain data solution is because of their customers – Professional traders – cannot keep their trading history on-chain as this would expose their strategies to competitors.

4) Off-chain data availability provides higher levels of throughput.

5) Reduce user gasfee by not publishing transaction data to the Ethereum mainnet

6) Exponential scalability growth will carry higher liquidity, which will be an important attribute of emerging DEXs

-ve:

1) Due to the large amount of computation and high complexity required for effective proof, the development speed is slow. Not cost effective for low throughput applications.

2) Therefore, it is not widely used. Not as many applications and iterations as op

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

4) Centralization risk in hardware. Generating proofs of validity requires specialized hardware, and a hardware monopoly may lead to centralized control of the chain.

5) The model relies on trust assumptions and cryptoeconomic incentives, unlike ZK-rollups that rely purely on cryptographic security mechanisms.

6) Issues with the availability of off-chain data: The data required to create or verify Merkle proofs may not be available. This means that users may not be able to withdraw funds from on-chain contracts if the operator is malicious. Even if there is a data availability committee, there is still a risk of centralization.

Validium project:

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

E. Volition

One more hybrid solution can be mentioned here – the concept of volition created by StarkWare: combining ZK-rollup and validium, and allowing users to switch between the two expansion solutions. With 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 gives users the freedom to choose trade-offs based on their unique situation.

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

Example: In zkSync2.0, the concept of volition is used. Their L2 state is divided into 2 aspects: zkRollup with on-chain data availability and zkPorter with off-chain data availability. The two parts will be composable and interoperable.

4. Summary:

1. Compared with various schemes, rollup effectively guarantees state validity + data availability, retains the advantages of previous schemes, and solves their limitations at the same time. Thus becoming the current leader in the expansion field.
2. In the roll-up scheme, in the short term, the optimistic rollup technology is more mature and widely used, the op roll-up may win in the general EVM calculation, and the ZK roll-up may be used in the simple payment, exchange and other specific wins in the application’s use case.But in the long run, the weaknesses of ZK Rollup are basically technical problems. With a large number of excellent developers investing in related research, ZK Rollup will be a better expansion solution in the future. The fundamentals of ZK-Rollup technology will enable it to replace Optimistic Rollups, with the ability to achieve faster speeds, higher security, and better performance, leading to wider adoption. There are already quite a few Layer 2 projects like Scroll, zkSync and Polygon trying to introduce the zk-EVM computing environment, which will enable ZK-Rollups to independently run all types of general smart contracts.
3. There will be more integrations in the future. From the perspective of the development process of the expansion plan, the expansion of Ethereum is not a single plan that can be done once and for all. Many solution providers are also exploring and laying out multiple paths. I personally believe that this will also lead to more fusion solutions (eg. “Bedrock” by Optimism; Volition by StarkEx; Polygon)
4. After reading this article, you should be able to feel intuitively: the development iteration of the expansion plan is often to use another better solution to retain the advantages as much as possible, solve the shortcomings, and break through the limitations after realizing the limitations of a solution. . Just like the developers thought Plasma was “the right one” for a long time, until they realized that its limitations could not be broken, so they explored roll-up; at present roll-up seems to be the accepted answer , but maybe with the deepening of exploration, there will be a better solution that subverts roll-up?
5. In the end, I feel that these expansion plans have countless trends. For a self-employed individual with secondary investment like me, I feel that I can take it slowly and wait for the project to come out and do the right-side transaction. Because the changes are too fast, it may be difficult to understand. , they found no way and changed direction (like plasma). Then judge a general trend and cast a wide net, betting widely may be a stupid but more effective way haha. But this is the second-level idea that does not apply to the first-level. The first-level finally depends on the team, the network and resources behind the project.

We will continue to update Gambling Chain; if you have any questions or suggestions, please contact us!

Follow us on Twitter, Facebook, YouTube, and TikTok.