LD Research: A detailed explanation of the full solution of Ethereum expansion
Original author: 0xRJ_eth (Twitter: @0xRJ_eth)
Today, I mainly sort out the Ethereum expansion plan 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 have been heard of. But I think it is very important to clarify the big framework and mutual logic. This will help us understand what innovations and combinations have been experienced in the development of expansion, what problems have been encountered, what are the concerns of the market in different periods, and why Rollup is currently The solution wins. These also help us see the general direction.
first level title
1. Cause
On the first layer of the Ethereum blockchain, the ever-increasing demand for network usage has led to network congestion and pushed up transaction costs. Improving storage, network speed, and throughput is fundamental to meaningful mass adoption of Ethereum.
first level title
2. Purpose
first level title
3. Expansion plan
Expansion solutions: can be divided into two categories - On-Chain (layer 1) and Off-Chain (side chain + layer 2)
On-chain, expansion on the chain
Improvement of the performance of the blockchain itself, which requires changes to the first layer 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 the layer1 protocol because they are the main network in the ecosystem. The Layer 1 protocol can process and complete transactions on its own blockchain, and at the same time comes with native tokens for payment of transaction fees.
(The entire Layer 1 expansion is a very important part of the Ethereum upgrade. This part can be elaborated in the Ethereum upgrade compilation and sharing in the future. Today, Layer 1 will briefly summarize the concept, so I won’t go into details)
Options for On-Chain Layer 1 expansion include:
a. Change the consensus mechanism. The Ethereum upgrade adopts this solution. A few weeks ago, the successful merger of the beacon chain and the main network completed the conversion of the consensus mechanism from pow to pos.
b. Implement sharding. Sharding is a common Layer 1 scaling solution, mainly used to increase transaction throughput. This is a database segmentation technology in computer science. The network and the nodes above are divided into different shards to share the workload and increase the transaction speed. Each shard handles a portion of the activity of the entire network, i.e. each shard has its own transactions, its own nodes, and its own independent blocks.
Sharding also reduces the burden on each validator (as 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. Increase the block size. Make each block able to handle more transactions (the current Ethereum upgrade proto-danksharding is a similar solution, after upgrading this part, there will be a single share).
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 is the consequence of a hard fork)
Off-chain, expansion under the chain
secondary title
Ⅰ. Sidechain
The side chain is an independently operated blockchain, and its security depends entirely on its own protocol mechanism. This is also the biggest difference between the side chain and the current mainstream off-chain expansion solution layer2.
The difference between the side chain as an independent chain and some layer1 public chains is that the side chain is dedicated to dealing with the excess capacity of Ethereum, rather than competing with the entire Ethereum. These ecosystems are tightly integrated with the Ethereum community, hosting Ethereum applications in a complementary manner.
Regarding this part of classification, I found that many articles on the Internet are quite confusing, and they will classify side chains in layer2. In this part, I mainly refer to the definition of side chains from the Ethereum Foundation and the side chain white paper.
https://ethereum.org/en/developers/docs/scaling/sidechains/
The second type of off-chain expansion is the layer 2 solution mentioned just now and often heard by everyone: the basic idea is to calculate/execute off-chain, and upload the results to the chain; offline batch processing. Gain security directly from the first-layer Ethereum consensus. The different layer2 solutions will find a balance between security, expansion efficiency, degree of decentralization, and versatility.
Let’s talk about the side chain first:
Side chain Side Chainsis an independent blockchain that runs in parallel and independently of the Ethereum mainnet.
They are usually designed for efficient processing of transactions. The biggest difference from the second-level scaling solution 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 achieve high throughput at the expense of some decentralization or security.
The side chain mainly realizes the link with the main network and interoperates with the main network through the two-way pegged cross chain bridge (we will elaborate on this concept soon). 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 needs to be noted here that in fact, assets are not transferred in a real sense, but "cross-chain" through the method of "locking in one chain and casting assets of the same denomination in another chain". However, any project that erects a two-way anchor cross-chain bridge can be regarded as a side chain.
Let's first understand what is a two way pegged cross chain bridge:
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, an equivalent amount of digital assets will be in the form of wrapped tokens For example, 10 weth is minted on the side chain, and now the 10 weth can be traded on the side chain. Vice versa, when the user wants to withdraw eth from the main chain, he can destroy the remaining wrapped eth of the same denomination on the side chain.
Lock (lock) tokens on the main chain, mint (mint) (wrapped) tokens on the side chain. Destroy/burn tokens on the side chain and extract tokens on the main chain.
https://medium.com/techskill-brew/layer-2-blockchain-scaling-solutions-channels-sidechains-rollups-and-plasma-part-16-79819e058ef6
The working environment of the side chain is the same as that of the main chain, and it is also based on EVM (Ethereum Virtual Machine). However, the side chain has its own ledger system, consensus algorithm (such as proof of authority, delegated proof of equity, Byzantine fault tolerance) script contracts, etc. But they also achieve security in different ways in order to achieve various goals.
Here are a few examples:
Single escrow mode Centralized (basic third party authority): This is the easiest way to transfer digital assets between blockchains at this stage - sending 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 approach is that it is too centralized.
Federation model Federation - multisig federation: The federation model uses a notary alliance to replace a single custodian, and uses the multi-signature of the notary alliance to confirm the flow of digital assets in the side chain. In this model, if you want to steal the frozen digital assets 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.
SPV (simple payment verification) mode: The above two schemes are secured through an intermediary, and both 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" if you are interested, you can read it, 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 transactions. Its characteristic is that it can verify the existence of transactions in a specific block with only a small amount of data. In SPV mode:
1. The user sends the asset to a special address on the main chain to lock the asset on 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 acknowledgment period is to generate enough work to make denial-of-service attacks during the next waiting period more difficult. 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 covered by sufficient workload on the parent chain, The confirmation period is a security parameter that depends on the side chain, and it is a trade-off between the speed and security of cross-chain transactions.
3. After the confirmation period of the main chain is over and the assets are determined to be locked, an SPV certificate will be created and sent to the side chain. Then a corresponding transaction with this SPV proof will appear on the side chain, and this transaction will generate a side chain token asset of the same value on the side chain.
4. The generated sidechain assets are first locked, and then the user must wait for a competition period. During this period, newly transferred coins cannot be spent on the sidechain. The purpose of the competition period is to prevent double spending during reorganization, and to transfer previously locked coins during reorganization. At any point during this delay period, if a new proof-of-work is issued corresponding to a chain with more accumulated work that does not contain the block that generated the locked output, then the transition will be retroactively invalidated. We call this a proof of reorganization, and it requires a contention period to prevent double spending. If during the competition period, the user transfers the locked coins on the main chain, and other users can use the latest SPV to prove this, the side chain minting transaction will become invalid, and this proof is called a reorganization proof.
Whenever possible, all users on the sidechain will have an incentive to issue proofs of reorganization, since the recognition 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 is over, 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 the coin from the side chain back to the parent chain, the process repeats the above steps: send the coin 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 par-value output that was previously locked on the parent chain.
(Less important) Drive chain mode Drivechain: The concept of drive chain was proposed by Paul Sztorc, the founder of Bitcoin Hivemind. In the drive chain, miners act as 'algorithm proxy guardians' to detect the current state of the side chain. The miners are the custodians of the funds, and the drive chain issues the supervision rights of the locked assets to the miners, and allows the miners to vote when to unlock 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.
(Less important) Hybrid mode: drive chain + notary/side chain and hybrid mode is a mode that effectively combines the above methods of obtaining two-way anchoring. Due to the fundamental difference in the implementation mechanism of the main chain and the side chain, the symmetrical two-way anchor model may not be perfect. The hybrid mode is to use different unlocking methods on the main chain and the 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 sidechain says that the data is stored on the sidechain and is not anchored back, it can only be guaranteed by the validator of the sidechain itself, and the security is much weaker.
Side chain project:
Polygon- The project ranged from a single Layer 2 plasma solution (formerly known as Matic Network), and eventually expanded to the 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 create 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 value storage, while daily transactions will be transferred to Polygon's low-cost blockchain. Therefore, the polygon pos side chain provides value by assisting the expansion of Ethereum, rather than directly competing with the Ethereum main network to grab the market.
Gnosis Chain- It was formerly known as the xDai side chain, and later merged with Gnosis to develop the Gnosis Chain. Low cost and Ethereum compatibility are the two main selling points of gnosis chain.
Skale - Positioning game 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- Ethereum co-creator Joseph Lubin, ConsenSys founder, film producer and owner of Heyday Films David Heyman, art technology group HENI Group founder Joe Hage. This is an Ethereum sidechain that allows users to create NFTs.
Ronin- A chain game-based side chain launched by Sky Mavis, the developer of the chain game Axie Infinity. Because the game requires fast interaction and low transaction fees to expand and facilitate the tens of thousands or even millions of transaction activities that occur every day. User experience must be friendly and silky. So the team simply did it themselves.
Fragment chain - the fragment chain in the original eth upgrade plan (eth 2.0), also belongs to eth's own side chain variant.
Advantages and disadvantages:
+ve：
1) The compatibility of the side chain is very good, it supports general computing, EVM is compatible, and it can support smart contracts.
2) When it comes to 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 blockchain impossible triangle).
3) The main purpose of setting up the side chain is to reduce the congestion on the main chain, reduce the cost for everyone, 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 Bitcoin core development team was considering how to safely upgrade the Bitcoin protocol to add new functions, but worried that it would be dangerous to add functions directly on the Bitcoin blockchain, because if the new functions were implemented in practice If a software failure occurs in the network, it will have a serious impact on the existing Bitcoin network. In addition, due to the characteristics of Bitcoin's network structure, if large-scale changes are made, the support of the majority of Bitcoin miners is required. At this time, Bitcoin core developers proposed a side chain solution.
So the earliest side chain was to allow developers to explore and attach new functions to other blockchains, and then attach these side chains to the existing Bitcoin blockchain. To protect the Bitcoin parent chain network.
-ve:
1) The main difference between sidechains and rollups and channels is that both rollups and channels 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 speaking, the side chain solution does not belong to layer2.
2) The degree of decentralization is low.
secondary title
Ⅱ. Layer2 Layer 2 Solution
The basic idea is to calculate/execute off-chain, and upload the result to the chain; data is processed offline in batches. This method obtains security directly from the consensus of the first layer of Ethereum, and the scheme includes:
A. Channel channel
This is a very early, long-standing blockchain scaling solution, best known for its use in Bitcoin's Lightning Network. Focus more on security than usability.
Participants must lock a portion of Ethereum's state, such as ETH deposits, in a multisig contract. Locking the initial state is the first transaction and opens the channel. Participants can then conduct transactions 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 build a multi-signature contract address on the main chain. For example, A and B create such a multi-signature contract, and the funds can only be transferred with their mutual consent. Deposit their own money, assuming that A and B each deposit 10eth, this initial state is equivalent to opening a payment channel. Then there are dozens or even thousands of transactions between them under the chain, and both parties of each transaction need to sign and stamp it. Finally, A has 5eth and B has 15eth. But instead of recording so many transactions on the blockchain, they only record two — the initial funding transaction and the final balance distribution after all transactions are concluded. When they upload the final balance to the main chain, it is equivalent to closing the payment channel.
For A and B, those transactions under the chain have no handling fee and are almost instantaneous. Both parties do not have to pay miners fees and do not have to wait for block confirmations.
State Channel: This is actually a derivative of Payment Channel. Judging from the name, this solution is based on "state", that is to say, not only the transaction state, but also the game state, activity state, etc. For example, to start a backgammon game, they need to create a new "judgment" program and provide it with an initial bet, so that the state channel is opened. Their moves are not submitted to the blockchain as transactions. But at each step, both parties need to sign and attach a timestamp before taking the next step. Only when the program determines that one side wins according to the rules, the game ends, a and b sign a status update, and the bets are simply distributed according to the outcome of the game. This is equivalent to closing the state channel.
Data Availability Data Availability (DA):
All data is stored in Layer 2, and DA is guaranteed by both Channel parties (the entire process of transfer or game needs to be maintained by participants a and b themselves)
State Validity State Validity (SV):
After the end of the Channel, any party can submit the final state to Layer1, but Layer1 will not verify, but will first ask the submitter to pledge. Then there will be a week for Fraud Proof, and anyone can settle doubts against the pen and submit a proof (proving that the status is wrong). This challenge is verifiable. As mentioned just now, every offline transfer and behavior requires both parties to sign and add a time stamp. Therefore, whenever the fraud proof provided by the questioner shows that it is signed and **time is newer than before,** this is a verifiable fraud proof. This proof will become the latest state, and the coins pledged by the person who submitted the state will be deducted.
Channel items:
BTC's Lightning Network lighting network
Advantages and disadvantages:
+ve：
1) The channel is mainly for high-frequency and small-amount payments.
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 the chain.
3) State validity SV can be well guaranteed by fraud proofs.
4) The state channel has strong privacy performance - because everything happens in the channel, rather than publicly broadcast and recorded on the chain. Only opening and closing transfers must be public. But in the side chain system, each transfer is published on the side chain, and then every participant on the side chain will receive it,
5) State channels have instant finality - that is, as soon as two parties sign a state update, the state can be considered complete.
-ve：
1) Withdrawing coins is slow, and it will take 1 week for fraud proof to withdraw coins
2) For users who occasionally transfer money to the other party, the time and economic costs of creating and settling channels are relatively high, which is not very friendly. Because you still need to create multi-signature contracts, sign, design judging procedures...
3) Open participation is not supported. Channels cannot be used to send funds off-chain to people who are not yet participating
4) TPS is average and more suitable for a small number of participants. If it is a large-scale and complex transaction, the performance will not be able to keep up.
5) Smart contracts are not supported, after all, it is not a chain.
6) The status channel requires all participants to be 100% online, and the pledged tokens will be deducted if the participant leaves halfway.
7) Channels cannot be used to represent objects that do not have a clear logical owner (eg Uniswap). Therefore, channels and only channels 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 is necessary to update the contract every time. Make changes.
B. Plasma
Due to the limitations of Channel "unable to support large-scale, large-scale and complex transactions", the Plasma solution came into being. It combines some designs of the side chain, which solves the problem of sending assets to any target person, and can also ensure the improvement of TPS. In fact, Plasma was once considered "the right one" for a long time when developers began to study 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 sidechain. It can be expanded through off-chain transactions, and at the same time, it can solve the security problem of the sidechain itself to a certain extent (that is, when the subchain encounters When attacking, the assets stored on the sub-chain are always safe) Therefore, some performance of the side chain (such as executing smart contracts, etc.) is given up after the trade-off, but the security is increased by anchoring the block back to the main network. The two biggest differences between him and the side chain are:
1) The side chain uses a bridge to interact 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. However, 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 mainnet (but 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 verifier, so its security level is poor). Therefore Plasma chains are also called"son"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, and only basic token transfers, exchanges, and some other transaction types are supported.
Unlimited creation of "chains within chains":
Each Plasma can infinitely create more sub-chains to reduce the workload of the parent chain, and each sub-chain has a role called "Operator".
The operator's periodic "status commitment":
All off-chain transactions will be aggregated to the operator of the sub-chain first, and then (because the sub-chain needs to be anchored back to the main chain) the operator periodically summarizes the calculation results of the sub-chain, and packs and compresses them into a block in the form of a Merkle tree. The block root, and finally submit the block back to the main chain for state records. This is the so-called periodic submission of "status commitments". In this way, no matter how many transactions occurred on the sub-chain during the two submissions, the sub-chain only needs to submit the state 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 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:
Then when launching the plasma chain, that is, when withdrawing money, plasma introduced the "challenge period" mentioned earlier, punishing dishonesty and ensuring the validity of the state through fraud proofs. This master contract is also responsible for keeping track of state commitments (explained earlier) and penalizing dishonesty through fraud proofs. "Fraud Proof" means that within this challenge period (usually 7 days or longer), anyone can submit a Merkle tree verification method to prove that the withdrawal of user assets is illegal.
Drawn by RJ
State Root State Root:
First of all, I just mentioned that Plasma has a contract (or a series of interrelated) contracts on the main chain to maintain the status record in the plasma sub-chain. This status record is actually stored by the root node of a Merkle tree. Hash value, this hash value is called the state root.
Specific explanation: Merkle tree (a binary tree), the status information of the current rollup layer account is recorded 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 father of these two leaf nodes Nodes, one by one, and so on, and finally 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 exactly the same (so you only need 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 rollup, a new state root will be 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 it was mentioned just now, as long as the recorded transactions/leaf nodes are completely consistent, the root hash value must be the same.
In order to keep their funds completely safe, users (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 makes sure everything works as expected. Users should run the software at least every few days, but the exact timing depends on the parameters set by the Plasma MVP smart contract.
If the PlasmaChain is functioning properly, then 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 automated 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 proofs effectively prevent users from doing evil, and can also ensure 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 user can submit a fraud proof, the premise is that the user has recorded the transaction data on the sub-chain + the operator has packaged all the real transaction data on the main chain, so when the operator submits invalid data maliciously, as long as the relevant information required for fraud prevention With information hiding, users in the network cannot obtain real information to prove that the transaction is invalid.
Mass exit:
Since the problem of "operators doing evil" cannot be effectively prevented in the plasma solution, we can only think of a solution. Plasma has designed a "mass exit" plan, but this plan may cause Ethereum's own network congestion...
Plasma project:
Matic used plasma from its earliest days, and blockchain researchers discovered data availability issues shortly thereafter (discussed further in this report), causing Plasma to be deprecated by other solutions. After the name change, the polygon project has been transformed into a comprehensive, all-stop expansion solution.
Advantages and disadvantages:
+ve:
1) Provides high throughput and
2) Low cost per transaction.
3) Applicable to transactions between any users. People who use it can send assets to people other than plasma, and the payee can return to plasma at any point in time as long as they have 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 of the state tree to the main chain, but the main chain does not verify, allowing anyone to submit a challenge and a fraud proof within a week. In this way, the validity of the sv state is guaranteed.
-ve:
1) Smart contracts cannot be run. Plasma only supports basic token transfers, swaps, and a few other transaction types.
2) Fixed submission period, if you pay within this period, the payment will not be confirmed, you need to wait until the period is up.
3) Withdrawals are slow and usually require a 7-day wait to allow submission of challenges and proof of fraud.
4) Need to regularly observe the network (activity requirement) or delegate this responsibility to others to ensure the safety of funds
5) Rely on one or more operators to store data and provide services on request.
6) The Ethereum mainnet can become congested if too many users try to exit at the same time.
So it can be seen here that the core advantage of Plasma compared with Channel is that users can send assets to participants who have never participated in the system, and the capital requirements are much lower. But there’s a tradeoff: Channels don’t require any data to run on-chain, but Plasma requires each chain to periodically publish a hash. Also, Plasma transfers are not instant: users have to wait for the challenge to end.
But the core problem of plasma itself is that in order to improve efficiency, the Plasma sub-chain will only periodically submit its status results to the main chain instead of all transaction data. But the price of doing this is that Plasma cannot establish the same level of trust as the Ethereum main chain, because the burden of ensuring "data validity" falls on the "operator", not the Ethereum main network. But operators have motives to do evil.
Ever since, there is a roll-up solution...
C. Roll-Up:
Rollup is currently the most mainstream expansion solution, which 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, the first layer), and then batches multiple transactions together, and finally send their state back to the Ethereum main network. But the difference is that 1) roll-up will also submit the transaction data to the main chain, 2) rollup will compress the transaction data to the maximum, and at the same time delete and reduce some data appropriately based on the characteristics of Rollup itself, as long as the final submission is guaranteed It can be verified by anyone on the main chain. (Both roll-ups are based on plasma and provide different proof schemes for transaction data.)
Therefore, Rollup is more secure than Plasma. And its core advantage is to ensure state validity + data availability at the same time.
How is Roll-up implemented?
State Root (mentioned earlier):
First, Rollup has a contract (or a series of interrelated) contracts on the main chain to maintain the status record in the Rollup layer. This status record is actually a 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), the status information of the current rollup layer account is recorded 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 father of these two leaf nodes Nodes, one by one, 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 only 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 exactly the same (so you only need 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 rollup, a new state root will be generated.
However, if every 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 Layer1.
Therefore, the transactions generated in the rollup are packaged and aggregated in batches, and a new state root will be generated according to the state after all the transactions in this batch are executed. No matter who submits the transaction package to the smart contract on the main chain, he needs to calculate this 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 the state transfer confirmation in a rollup.
Therefore, the essence of Rollup is to aggregate a large number of transactions actually generated into a transaction on the main chain. These transactions are executed and calculated by the Rollup chain, but the data will be submitted to the main chain. This not only makes use of 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 achieve expansion, 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 can be submitted to the main chain at one time, and the lower the amortized cost. 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 a 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 encoding is adopted, and on the other hand, there are some clever compression techniques.
This chart is very interesting. Regardless of rollup, these parameters are generally 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 nonce in the account will increase 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: It is a number in units of 10 to the negative 18th power, and it is 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, the gas of a transfer transaction is about 20,000, and the gas of a contract is about 100,000-200,000, at most hundreds of thousands. So the average here is almost 3 bytes
To: An address on Ethereum is almost 21 bytes, and the address range of Ethereum is very large
Value: Refers to the amount of money when transferring money. In many cases, the contract value is 0, because you do not need to transfer money into the contract. But for example, if I transfer 5eth to you, then the value will have a value. The unit is also 10 to the negative 18th power, rlp encoding, almost 9 bytes
Signature: The signature is relatively fixed, almost 68 bytes
So calculated in this way, one eth transaction is almost 112. Because the roll-up is sent to L2, as long as the complete information can be expressed, the format of the L2 solution can be customized. But he can select and compress this information. for example:
Nonce: The nonce can be completely omitted in rollup. Because the nonce can be recovered from the pre-state.
GasPrice: It is possible to set a fixed fee level in each batch, or even move the gas payment completely out of the aggregation protocol and let traders pay the batch creator through channels.
Gas: You can set the gas limit at the batch level, select some specific values,
To: A 20-byte address can be replaced by an index on the Merkle tree (for example, if the address is the 4527th address added to the tree, we can simply refer to it using the index "4527". You can limit to 4 bytes
Value: Change the unit of the amount of money, or use other technical methods to store it.
Signature: Use BLS aggregate signature to integrate multiple signatures into one. The signature can then be verified against the entire "batch" of messages at once. Because the upper limit of verifiably aggregated signatures per block is 100, even large batches of 100 signatures can be aggregated into one signature.
In the end it saved almost 12 bytes. In fact, it is equivalent to limiting the accuracy, but the information range remains unchanged, and it still almost expresses complete information. This is the key point of why roll up can expand. But the reason for this expansion is mainly because on the main chain, calldate is limited, because each byte of calldate consumes a little gas on the main network, and the total gas amount of a block on the main chain is limited. Therefore, the total number of bytes that calldata can include is limited.
These compression techniques are the key to rollup expansion. If we do not compress transaction data, rollup may only be able to improve efficiency by about 10 times on the basis of the main chain, but with these compression techniques, we can achieve 100 times or even more High compression efficiency.
Data availability ：
How can I verify that the submitted information is correct and available?
The 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 involves how to verify that the submitted information is correct and available?
For this problem, there are generally two solutions, and according to different solutions, rollup is also divided into two categories: Optimistic rollup and Zero-knowledge (ZK) rollup.
a) Optimistic rollups As the name suggests, they optimistically assume all transactions are valid and commit batches without any initial proof. Anyone can detect and prove that some data is false during the challenge period.
Drawn by RJ
If the batch proves to be fraudulent, Optimistic rollps perform a fraud proof and run the correct transaction calculations using data available on the Ethereum main chain.
You can also use the picture just now (below) to explain the fraud proof construction in optimistic roll-up:
The information contained in the batch includes pre-state root, post state root, and transaction information.
According to the part of pre-state root, a complete Merkle tree can be constructed.
According to the transaction information, we can simulate the execution of the transaction submitted in the batch, so as to obtain a new account state, a new Merkle tree, and a new state root.
Compare the state root obtained in the previous step with the state root in the batch to verify that 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. When his submission is verified as wrong, part of the pledged funds will be deducted as a punishment. At the same time, the verifier who submits the corresponding fraud proof will get a deducted deposit to incentivize the behavior of monitoring and submitting fraud proof.
If we compare OR and Plasma, we will find some similarities, for example, they both use a fraud proof mechanism and need a validator role to monitor the submission of OR to the main chain. However, since OR submits transaction data to the main chain at the same time, verifiers on OR do not need to save and record transactions on OR.
Drawn by RJ
Advantages and disadvantages:
+ve：
1) Provide high throughput
2) and low transaction costs
3) The roll-up transaction data is stored on the first layer chain, which improves transparency, security, anti-censorship and decentralization. Provides massive improvements in scalability without sacrificing security or trustlessness.
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 (theoretically, even one honest node can guarantee the security of the entire chain)
5) Optimistic rollup also ensures the availability of data by uploading transaction data to 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) Withdrawals are slow and usually require a 7-day wait to allow submission of challenges and proof of fraud
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 type of Roll-up solution is Zero-Knowledge rollup (ZK rollup)
First, what is a zero-knowledge proof ZKP?
Zero-knowledge proof (ZKP) is an important part of modern cryptography. It refers to the fact that the prover can convince the verifier that a certain assertion is correct without providing any useful information to the verifier.
The prover proves to the verifier and makes him believe that he knows or has a certain message, but the proof process cannot leak any information about the proven message to the verifier. In layman's terms:
It not only proves what it wants to prove, but also discloses the information to the verifier as"zero". eg sudoku
reliability
reliability
zero-knowledge
Different from Optimistic Rollup, ZK Rollup requires submitters to carry a " Evidence of validity". After the validity proof is submitted to the roll-up contract of the main network, anyone can use it to verify whether the transaction of a specific batch in the zk Rollup layer is correct. The proof can be completed within a few minutes of submitting the batch. 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 validator's work and completing the verification at the same time as submission.
This means: 1. zk Rol-Up omits the link where the verifier saves the data and submits the fraud proof 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. Therefore, the transaction speed is much faster than other L2 solutions.
Drawn by RJ
There are currently two zero-knowledge proof solutions on the market:
zk-SNARK (Succinct Non-Interactive Argument of Knowledge) is an acronym for Succinct Non-Interactive Argument of Knowledge. The characteristics of this scheme are simplicity, 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 will not increase exponentially with the computing throughput.
zk-STARK (Scalable Transparent Argument of Knowledge) is a scalable transparent argument of knowledge, created as an alternative version of SNARK. Different from the "S" of Succinct in SNARK, the "S" in STARK stands for Scalable (scalability), which is mainly reflected in the fact that the time complexity of STARK generation proof (Proof) is similar to the complexity of calculation (in a quasi-linear relationship), The time complexity of Verify Proof is far less than the computational complexity. That is to say, as the scalability of STARK increases, the complexity of STARK's proof does not increase accordingly.
However, since the zero-knowledge proof part involves very complex underlying technologies and cryptography concepts, it 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 a few important compression tricks specific to ZK rollups are:
1. The volume of the generated proof is much smaller than the volume of the content of the proof (so it is much smaller than the bytes uploaded to the main network by op).
2. If a part of the 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, because that data still needs to be included on-chain in case it needs to be checked later in a fraud proof (comparing zk does not require a challenge period and a 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 development progress and practical application of ZK-Rollup 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 makes the zk project inherently It is difficult to be compatible with evm (this part is also, you can talk about the sharing of zk in the future).
Here is a cost and TPS comparison of a different scheme 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 the validator's work and the concept of a challenge period, once the validity proof is verified on L1, the state update is approved, thus providing faster transaction finality. (No need to wait another 7-14 days)
3) Data availability for OR comes from economics. In order to work well, OR must design a reasonable incentive mechanism to drive a group of verifiers on the main chain to monitor submitters at any time and prepare to submit fraud proofs, and the availability of zk data depends on cryptography and codes.
4) Security depends on the security and consensus of the main network. Because the data needed to restore the off-chain state is stored on L1, it guarantees security, censorship resistance, and decentralization.
5) Better data compression helps reduce the cost of calldata publishing on Ethereum and minimizes aggregation fees for users. It is currently the solution with the strongest compression capability and the highest efficiency
6) Therefore, user transaction fees are also low.
-ve:
1) Due to the large amount of calculation and high complexity required for its effective proof, the development speed is slow
2) Therefore, it is not widely used. not as many shoulds 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 and DeFi protocols.
4) Centralization risk in hardware. Generating proofs of validity requires specialized hardware, and a hardware monopoly could lead to centralized control of the chain.
ZK Roll-Up project:
data from https://l2beat.com/scaling/tvl/, 22/09/2022
Rollup summary:
Now you can understand why the Roll-Up scheme can replace the Plasma scheme:
1) Efficiency - zk-rollup generates proofs of validity for off-chain transaction processing. It directly omits the links of operators packaging data, issuing "state commitments" and submitting user fraud proofs, thereby eliminating the need for challenge periods and exit mechanisms. It also means that users don't have to watch the chain regularly to protect their funds.
2) Support for smart contracts - Another problem with Plasma is that it cannot support the execution of Ethereum smart contracts. Optimistic roll-up is compatible with the Ethereum Virtual Machine, and even now many zk projects (zkSync, StarkWare, etc.) are promoting the realization of zkEVM. Making it a more ideal, safe and useful decentralized expansion solution.
Data unavailability - 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 proof of fraud. 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 exit problem - Both ZK-rollups and Optimistic Rollups solve the mass exit problem of Plasma in different ways. For example, ZK-rollup’s encryption mechanism ensures that operators cannot steal user funds under any circumstances.
Likewise, optimistic rollups impose 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 "mass rollout" that would potentially damage the main network.
In the past few years, V God has also emphasized that the future development of Ethereum will be centered on roll up. The underlying chain provides guarantees for the data availability of blocks, and Rollup provides guarantees for the expansion and validity of blocks.
However…
With the advancement of large-scale migration to layer2, even rollups with strong compression capabilities will eventually return to the same expansion problem-because rollup transaction data must still be propagated to all full nodes, the degree of expansion is still limited by Ethereum data. processing power limitations.
Compared with the main network, Optimistic rollup can achieve 25 times the scalability upgrade, zk rollup can achieve 100 times, about 3000 TPS.
It can be said that the Rollup schemes provide linear growth rather than exponential growth in terms of capacity expansion. Is it possible to guarantee performance while providing exponential expansion growth?
secondary title
D. Validium Chain
It operates similarly to ZK rollup and also verifies Ethereum off-chain transactions 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, it can improve scalability, transaction speed, and reduce user fees (the release cost of calldata is lower).
Deposits and withdrawals:
Deposits and withdrawals are also similar to rollup, and 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, the user mints 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 proof of validity of the batch is verified, the user can call the main contract to make a withdrawal by providing a merkle proof. So like zk-rollup, Validiums offer 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. The batch includes state root/merkle root and proof of validity. To perform a state update, an operator must compute a new state root (after executing a transaction) and submit it to a contract on the main chain. If the validity proof passes, it will switch to the new state root.
Unlike ZK-rollup, operators on validium do not need to publish transaction data. This makes validium a purely off-chain scaling protocol.
Drawn by RJ
The main benefits of Validium's off-chain data storage are to further improve scalability (throughput is not limited by Ethereum's data processing capabilities), increase transaction speed, reduce user fees (the release cost of calldata is lower), and protect privacy, because the public cannot Access transaction data on-chain.
Data availability:
However, the availability of off-chain data poses a problem - if the operator hides the off-chain state data from the user, and the user cannot access the transaction data, then the user cannot calculate the Merkle proof needed to perform the withdrawal, and the user's funds will be frozen.
As shown in the figure below: If the operator changes trasaction 6, the owner of transaction1 will not be able to prove his account ownership, because the node hash (5, 6, 7, 8) information required in the proof process is lost.
(Sounds better than plasma. In the plasma scheme, the operator can steal user funds by doing evil. In validium, because the fraud proof is not used, but the validity proof, the worst case for the operator to hide data is Freezing user funds so that they cannot be withdrawn...)
Drawn by RJ
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’ approach 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 the task.
The first category: Data Availability Committee (DAC)
In order to solve this problem, StarkWare proposed the concept of Data Availability Committee (DAC) to eliminate users' trust dependence on operators.
By designating a set of trusted entities (collectively known as the Data Availability Committee) to store copies of off-chain data and make them (off-chain data copies) publicly available in the event of an emergency where the operator does not service a user's withdrawal request access. With fewer members, DACs are easier to implement and require less coordination. But with that comes centralization risk.
Sign out directly without going through your carrier.
In an emergency, the application smart contract (ASC) on the mainnet will no longer accept new state updates, and instead only allow users who can provide merkle proofs for the latest state 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 an incorrect state.
However, users must trust the DAC to provide data when needed (for example, to generate Merkle proofs). Members of the Data Availability Committee have the potential to be compromised by malicious actors who can then withhold off-chain data.
The second category: 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 serves as a "bond" to guarantee honest behavior among data availability managers and reduce trust assumptions. If these participants fail to demonstrate data availability, the bond will be slashed.
In the bonded data availability scheme, once the required tokens are staked, anyone can be assigned to store off-chain data. This expands the pool of qualified data availability managers and reduces centralization risks affecting the Data Availability Council (DAC). What's more, this approach, which relies on cryptoeconomic incentives to prevent malicious activity, is more secure than designating trusted parties to protect offline data.
Pros and cons of Validium:
+ve: Many advantages and disadvantages of zk roll-up validium also has:
1) Validity proofs enforce the integrity of off-chain transactions and prevent operators from updating with invalid states
2) Fast transaction speed. No delay when withdrawing funds back to Ethereum (no fraud proof required)
3) Suitable for specific use cases, such as transactions or blockchain games where privacy & scalability are prioritized. (For example, DeversiFi is a decentralized *exchange that uses a second-layer network (Validium) to achieve private transactions and scalability. * One of the main reasons for DEX V1.0 to choose off-chain data solutions is because their customers - Professional traders - cannot record 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 DEX
-ve:
1) Due to the large amount of calculation and high complexity required for its 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 and DeFi protocols.
4) Centralization risk in hardware. Generating proofs of validity requires specialized hardware, and a hardware monopoly could lead to centralized control of the chain.
5) The model relies on trust assumptions and encryption economic incentives, unlike ZK-rollups that rely purely on encryption and cryptography 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 acting maliciously. 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
image description
https://medium.com/starkware/volition-and-the-emerging-data-availability-spectrum-87e8bfa09bb
first level title
4. Summary:
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 leader in the field of expansion.
In the roll-up scheme, in the short term, optimistic rollup technology is more mature and widely used, op roll-up may win in general EVM calculations, and ZK roll-up may win in 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 issues. With a large number of excellent developers investing in related research, ZK Rollup will be a better expansion solution in the future. The basic principle of ZK-Rollup technology will enable it to replace Optimistic Rollups, with the ability to achieve faster speed, higher security, and more comprehensive performance, thus bringing about wider adoption. At present, many Layer 2 projects such as Scroll, zkSync and Polygon are already trying to introduce the computing environment of zk-EVM, which will enable 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 process of the expansion plan, the expansion of Ethereum is not a single solution that can be done once and for all. Many solution providers are also exploring and deploying on multiple paths. I personally believe that this will inevitably lead to more fusion solutions (eg. Optimism's "Bedrock"; StarkEx's Volition; Polygon)
After reading this article, you should be able to intuitively feel that the development iteration of the expansion solution is often realized after the limitations of a solution, and then use another better solution to retain the advantages as much as possible, solve the shortcomings, and break through the limitations . Just like developers thought that Plasma was "the right one" for a long time, until they realized that its limitations could not be broken through, so they explored roll-up; at present, roll-up seems to be the accepted answer Yes, but maybe with the deepening of exploration, there will be a better solution to subvert roll-up?
In the end, after sorting out, I feel that there are countless directions for these expansion plans. For self-employed individuals with secondary investment like me, I feel that I can take my time and wait for the project to come out to do right-hand transactions. Because the changes are too fast, it may be hard to figure it out. , they found it impossible to go, and changed direction (like plasma). Then it is judged that a general trend is spreading the net widely, and betting widely may be a stupid but more effective way haha. But this is a second-level idea that does not apply to the first-level. At the end of the first-level, we still look at the team, the network and resources behind the project.
This article is only for personal learning and sharing, and does not constitute any investment advice.
