zkEVM Rollup: the gap between technology vision and project

In order to solve the expansion problem of the blockchain Layer 1 network, the Rollup solution came into being. Combined with ZK technology, ZK Rollup has become the new darling of the Layer 2 track. However, for most people, related concepts such as ZK, Rollup, and EVM may have a certain threshold of understanding. Therefore, the goal of this research report is to systematically sort out a series of concepts of zkEVM Rollup for you in a concise and easy-to-understand language, deeply analyze the evolution and development status of zkEVM Rollup technology, and interpret the main ecological projects in detail. It is designed to help you fully understand and judge the development trend of the zkEVM Rollup track.

PART 1 Understanding ZK

ZK (or ZKP), the full name is Zero-Knowledge Proof, that is, zero-knowledge proof. In cryptography, zero-knowledge proof or zero-knowledge protocol is a method through which one party (the prover) can submit to the other party (verification certifier) to prove a fact without disclosing the specific information of the fact, that is to say, one party (prover) can let the other party know whether the fact is correct without disclosing any "specific information" of the fact, so ZK technology can be used in privacy The field of protection brings us a lot of room for imagination.

Of course, in addition to the benefits of privacy protection that ZK technology can bring, in ZK Rollup, ZK technology is more important to solve the problem of "difficult verification". The process of "verification" is very important to the blockchain. Most of the calculation process in Ethereum is to meet the requirements of verification, and ZK Rollup can greatly reduce the time spent on verification by the entire node network. For example, if a block takes a long time to verify that it satisfies the rules of the entire network when the block was generated, there can be one prover who first verifies it and generates a "proof" of the calculation result of this block, and the rest The purpose of verifying the block can be achieved by quickly verifying this "proof" instead of the original block with a huge amount of calculation.

A simple ZK protocol is divided into the following steps, key generation, proof and verification, and I will disassemble them for you one by one.

01 Key generation, proof and verification

In ZK, we need to first convert the problem to be verified into a mathematical expression, and then into a polynomial, and express it in the form of an arithmetic circuit. When a program is converted into an arithmetic circuit, it is broken down into individual steps consisting of basic arithmetic operations such as addition, subtraction, etc. As a function that will be output, it can be transformed into the following circuit diagram, see Figure 1.

Figure 1 An example of a circuit diagram, it can be noticed that all operations in the circuit are split into the simplest basic operations | Source

Using this circuit and some random numbers as input, we can generate a proving key (pk, proving key) and verification key (vk, verification key) for the subsequent verification process, the schematic diagram is shown in Figure 2.

Figure 2 Generation of "public parameters"

Our proof system also requires two types of inputs - private and public, together with the proof key to generate the proof. Among them, the private input (witness) is the secret we want to hide, and the public input is the information that can be made public. For example, in the equation X+Y*Z=OUT, X and OUT are public inputs, while Y and Z have values that we do not want to be public to the validator. Although the value of Y*Z can be deduced based on public input, the specific values of Y and Z are still uncertain.

Figure 3 The proof process and verification process of ZK-SNARKs

When the verifier receives the proof, it uses the public input, proof and verification key to verify the proof, and returns the verification result (ie, whether the verification is successful).

After understanding the above process, we can apply this technology to block verification to realize a small ZK-SNARK, as shown in Figure 3. There are many protocols and methods to realize zero-knowledge proof. SNARK is relatively easy to understand, and it is also the choice of most projects at this stage. In the paragraph "From ZK-SNARKs to ZK-STARKs" we will talk about the advantages and disadvantages of SNARKs.

02 Try a little SNARK

Let's take a zero-knowledge proof of a Merkle Tree that records account status as an example to practice. The Merkle Tree records the address and balance of the account. When there is a new transaction that needs to update the Merkle Tree, we need to perform the following operations:

1. Verify that the sender and receiver of the transaction are on the leaf nodes of the tree.

2. Verify the sender's signature.

3. Update the sender's and receiver's balances.

4. Update the root node of the Merkle Tree (ie Merkle Root) and use it as the final output.

In the absence of zero-knowledge proofs, the verifier needs to repeat these steps to ensure the accuracy of the calculation. But after using zero-knowledge proof, the situation is different. First, we need to identify two types of inputs:

During this process, only the new transaction information, the original Merkle Root and the updated Merkle Root are public inputs.

The Merkle Tree itself acts as a witness (witness) and does not need to be read or processed by the verifier.

Second, we need to generate keys and compute circuits. We build calculation processes such as Merkle Tree update and input and output address verification into calculation circuits to obtain proof keys and verification keys. This circuit has nothing to do with the input transaction information, nor with the existing Merkle Root, because the calculation method of the Merkle Tree is fixed.

In the stage of generating proofs, we take the two Merkle Trees and transaction information as input. In the verifier stage, the verifier can ensure the reliability of the update without obtaining the Merkle Tree, that is, without knowing the account information. The circuit is like a solid black box, as long as the input is correct, it will get the correct output.

Using zero-knowledge proof, other verifiers can quickly verify that the Merkle Tree generation process is credible, thereby reducing the time for repeated verification on the network, and the information of the Merkle Tree does not need to be disclosed to the verifier.

03 From ZK-SNARKs to ZK-STARKs

The proof protocol mentioned above is ZK-SNARKs. SNARK stands for succinct non-interactive arguments of knowledge, where succinct refers to the simplicity of this method, and non-interactive refers to that compared to other proof methods, SNARKs are non-interactive proofs, that is, the verifier only needs to use the succinct The generated proof can obtain the verification result. However, there are some problems with ZK-SNARKs. In the key generation stage, the circuit and the random number are equivalent to a set of initial public parameters, and there is an inevitable centralization problem in the generation process of this public parameter.

ZK-STARKs have a different approach based on SNARKs, where "s" stands for scalability, which proves that the generation time and the original calculation time are quasi-linear, while the verification time is logarithmic in the original calculation, which means In the case of a large data set as data, the verification time required by the verifier is greatly shortened.

At the same time, as an upgraded version of ZK-SNARKs, ZK-STARKs can not only improve the verification efficiency (theoretical efficiency is 10 times), but also does not rely on elliptic curves or trusted settings, and does not require the process of generating initial public parameters (letter "T ” stands for transparency), which removes the need for a centralized trusted setup. Some developers believe that the hash function in ZK-STARK can help resist quantum attacks.

However, ZK-STARKs was introduced late, the current technology is not mature enough, and it relies on hash functions, which limits its versatility. ZK-SNARKs is still a general proof algorithm. Some examples of STARK-based algorithms include Fractal, SuperSonic, etc., and related projects include StarkWare, Polygon Miden, etc.

PART 2 Understanding Rollup

In addition to ZK, another concept we need to understand is Rollup. The significance of Rollup is to solve the congestion problem of the layer-1 network.

Take Ethereum as an example, it currently has the problem of transaction congestion. There are two ways to solve this problem: one is to increase the transaction capacity of the blockchain itself, such as expanding the throughput of the blockchain through technologies such as sharding. Another approach is to change the way the blockchain is used, that is, to perform most activities in the second layer (Layer 2, hereinafter referred to as L2), rather than directly on the chain. In this case, a smart contract is often deployed on the chain, which is only responsible for processing deposits and withdrawals, and uses various methods to read off-chain data to verify that everything that happens off-chain complies with the rules. This is equivalent to erecting a highway next to a small road, that is, through L2 expansion to solve the congestion problem.

Currently, the three main types or solutions for L2 expansion are state-channels, Plasma, and Rollup. They are three different paradigms, each with advantages and disadvantages. All L2 extensions can be roughly classified into these three categories (although there are some disputes about naming, such as validium), among which Rollup has its own advantages.

Rollup and Data Availability

Compared with other expansion solutions, Rollup has certain advantages. One of the more intuitive advantages is that it solves the problem of Plasma data availability (mentioned in the chapter "Data Availability" of Mr. Darren's article), and here I will also do some supplement.

The fact that the data is on-chain is very important (note: putting data "on IPFS" will not work, because IPFS does not provide consensus level verification that there is no guarantee that a given data is available, i.e. the data must be stored in blocks ). In the two expansion schemes of Plasma and the previous Channel, data and calculations are completely placed in the second-layer network. When the second-layer network interacts with Ethereum, all transaction data on the second-layer chain is not included. From the state From the perspective of the machine, that is, every state change of the Plasma chain is not included. This will lead to the fact that if Ethereum is separated from the second-tier network such as Plasma, it will not be able to restore the previous state changes. Therefore, the availability of Ethereum data is very dependent on the protection of Plasma data.

Rollup Mechanism

In order to ensure data availability, the market chooses Rollup, so how does Rollup work?

Figure 4 State Root in the L1 contract | Source

In the Rollup design, there is a Rollup contract on the main chain, which stores a state root. This state root can be regarded as an upgraded version of the Merkle root of the Merkle Tree, which stores account balance (that is, a kind of state), contract code and other information. Figure 4 shows the state root stored in the Rollup contract.

The L2 node has three main functions: first, determine which transactions should be packaged first (usually this type of node or client is called a sequencer Sequencer), secondly, it needs to provide a proof for each packaged data, and finally submit it to the L1 The Rollup contract is verified by this contract. Figure 5 shows the role of the sequencer in L2.

Figure 5 Sequencing, proving and submitting Batch are the main functions of the L2 phase | Source

Specifically, L2 can transfer a batch of data (batch) to L1. These data can be highly compressed transaction collections or state changes after the contract runs, and also include the state root stored in the L1 contract and The new post-state root (post-state root) obtained after L2 processes the data. The contract verifies the correctness of the post-state root based on these data. Once the verification is passed, the batch of data will be confirmed at the L1 layer, completing the on-chain process from L2 to L1.

The post-state root (post-state root) is calculated from the original data. To ensure that the new post-state root in the submitted data is correct, the most straightforward way is to let L1 recalculate once. However, doing so will undoubtedly put a lot of pressure on L1. To solve this critical problem, there are two completely different optimization schemes, Optimistic Rollup and ZK Rollup.

ZK Rollup and Optimistic Rollup

ZK Rollup uses cryptographic protocol proofs such as ZK-SNARKs or ZK-STARKs to verify the correctness of the post-state root after executing the batch. Regardless of the amount of calculation in L2, ZK Rollup can quickly verify on the L1 chain.

Another type of proof is Optimistic Rollup, which uses fraud proofs. There is a vivid analogy here. It is like a mother who does not check her son's homework often, but as long as the homework is not completed once, she will be severely punished. Under this mechanism, the Rollup contract keeps track of the full history of the state root and hashes of each batch. If someone discovers that a batch has an incorrect post-state root, they can publish a proof that the batch was computed incorrectly. The other nodes together verify the proof and restore the batch and all subsequent batches.

Figure 6 summarizes the comparison of the advantages and disadvantages of Optimistic Rollup and ZK Rollup. It is important to note here that ZK Rollup excels in TPS and has a significant advantage in refund cycles. However, its disadvantages are EVM compatibility and computational consumption at the L2 layer:

1. Optimistic Rollup projects, such as Optimism and Arbitrum, use OVM and AVM respectively, and their virtual environments are basically the same as EVM, so they can directly migrate L1 contracts to L2 for deployment. However, in ZK Rollup, it is quite difficult to use ZK-SNARK to prove general EVM execution, because EVM is not developed according to the mathematical requirements of ZK proof calculation, so it is necessary to transform a certain type of EVM client to Use ZK technology to verify transactions and contract operations.

2. At the same time, even after corresponding conversion, ZK operation still requires a lot of computing power input, so ZK Rollup is not as efficient as Optimistic Rollup in L2 layer efficiency.

3. ZK Rollup provides better data compression than Optimistic Rollup, so it can submit smaller data on L1.

4. Since the proof verification process in ZK is faster and has a higher batch density, ZK Rollup is lower in the calculation consumption of the L1 layer. It can be understood that the node payment on L2 greatly reduces the requirements for L1 nodes, thereby significantly improving the scalability of the L1 layer.

Figure 6 Comparison of two rollup methods | Source:

**ZK Rollup or zkEVM Rollup? **

Although ZK Rollup looks attractive, there are many difficulties in actual deployment. At present, ZK Rollup still has considerable limitations, while Optimistic Rollup is still the mainstream solution. Most implemented ZK Rollups are also custom-made for some specific applications.

How to understand customized ZK Rollup? Developers build application-specific circuits (“ASICs”) for different DApps, such as Loopring, StarkEx rollup, and zkSync 1.0, which support specific types of payment, Token exchange, or NFT casting. However, their circuit design requires a high degree of technical knowledge, which This leads to poor developer experience. Taking a specific type of payment data as an example, the node submits the transaction data to the sequencer, and the sequencer packs it into a batch and submits it to the node that submits the proof as the public input, the proof process and the contract execution process on the virtual machine It has nothing to do, ZK is only responsible for proving the rollup calculation and compression process of a specific execution result.

And zkEVM Rollup represents the ability to rollup the running results of the virtual machine. When running a general-purpose smart contract on the L2 layer, it is necessary to prove the validity of the state transition before and after the contract runs, and a virtual environment is required to support the operation of the ZK algorithm. Therefore, it is the meaning of zkEVM to run the contract, output the final state, prove the validity of the contract execution process, and submit the transaction records, account records, and state change record data together in rollup. The L1 layer only needs to quickly verify the proof, the overhead is small, and there is no need to run the contract again. Figure 7 vividly illustrates the role of zkVM. It should be noted that zkEVM is actually an EVM-like virtual machine running on the L2 layer, so a more accurate term is Zero Knowledge Virtual Machine, zkVM, but everyone emphasizes that it is compatible with Ethereum and calls it zkEVM.

Figure 7 A diagram illustrating zkVM | Source

Existing projects are also considering gradually abandoning optimization for specific applications, and upgrading to support running general-purpose contracts, that is, zkEVM Rollup. Therefore, although zkEVM Rollup is a subordinate concept of ZK Rollup, in most cases, when ZK Rollup is mentioned, it refers to zkEVM rollup.

PART 4 zkEVM Rollup Project Overview

In the first half of 2023, various zkEVM projects will emerge in a spurt. When paying attention to these projects, the author mainly focuses on the following aspects:

1. Current project progress: including the current project stage, and the expected launch time of the test network and the main network, and whether it is consistent with the development roadmap.

2. The actual interaction of the project: Through the interaction with the test (main) network, etc., subjectively feel the network TPS, the confirmation time of a single transaction, etc., and have an intuitive feeling of network performance.

3. zkEVM compatibility: This is the most core technical point and the most difficult to judge. Even if some projects are open source, the technology at the VM level is the hardest and involves more ZK protocols. Specifically, it is necessary to pay attention to the ZK protocol, VM security, compatibility, etc.

4. zkEVM Rollup architecture: Compared with zkEVM, general projects will disclose their Rollup architecture in white papers and other technical documents, and the overall difference is less, but attention should be paid to its overall degree of decentralization.

5. Ecological operation: The number of project users, the degree of activity, the operation and incubation of the application ecology on the chain, and the maintenance of the developer community are indicators that softly reflect the operation of the project.

6. Investment and financing situation.

This article considers the project more from the perspective of the first four points, and pays more attention to the overall architecture of zkEVM Rollup from the technical level.

Scroll

Founded in 2021, the Scroll team is committed to developing the EVM equivalent of ZK Rollup for scaling Ethereum. For nearly two years, Scroll has been working with the Privacy and Scaling Explorations team and other open source contributors to publicly build a bytecode-compatible rollup. zkEVM. At the end of February, Scroll announced that its Alpha test network is now live on Goerli. Any user can participate in technical testing without permission. The average block time of the test network is 3 seconds. There are already more than 20 million transactions and more than 1.5 million blocks. And more than 4 million interactive addresses. At the same time, Scroll also opened the website ecosystem interface on April 11.

Judging from the recent information disclosure, Scroll is constantly moving forward on the road of Type 2 EVM equivalence. Recently, Scroll has completed the compatible development of all EVM opcodes, and is in the process of auditing. At the same time, the next goal is to be compatible with EIP2718 transactions.

In terms of technical architecture, the architecture of Scroll is relatively traditional, so it will be introduced in detail here. As shown in Figure 8, it is mainly divided into two parts: the core part is zkEVM, which is used to prove the correctness of EVM execution in L2; but to turn zkEVM into a complete ZK Rollup on Ethereum, a complete L2 needs to be built around zkEVM architecture. Specifically, the existing Scroll Alpha testnet consists of Scroll Node, Bridge Contract and Rollup Contract:

Figure 8 Scroll rollup overall architecture | Source

1. Scroll Node: composed of Sequencer, Relayer and Coordinator.

a) Sequencer, the so-called sequencer, opens JSON-RPC to users and applications, reads transactions in the transaction pool and generates L2 blocks and state roots. At this stage, the Sequencer nodes of Scroll are centralized, and will be gradually decentralized in future upgrades.

b) The Coordinator is responsible for communicating between the Roller and the Scroll Node. When a new block is generated in the Sequencer, the Roller in the pool is randomly selected for proof generation.

c) The Relayer monitors the Bridge Contract and Rollup Contract on the Ethereum and Scroll chains. The Rollup Contract guarantees the data availability of L2 data at the L1 level, and ensures that the L2 block can be restored at the L1 layer. Once the block submitted by the L2 layer is verified by the Rollup Contract on the L1 layer, the block will reach finality at the L2 layer. The immutable state of . The Bridge Contract is responsible for communicating between the dual-chain contracts when crossing chains, sending arbitrary messages in both directions or completing asset pledge and withdrawal operations when crossing chains.

Figure 9 2. Roller Network | Source

1. Roller Network: Roller has a built-in zkEVM, which acts as a prover in the network and is responsible for generating validity proofs for ZK Rollup, as shown in Figure 9.

a) Roller first converts the action trace received from the Coordinator (that is, what specific operations the contract has done and which addresses are involved) into circuit witnesses.

b) It generates proofs for each zkEVM circuit and finally aggregates these proofs from multiple ZK circuits.

StarkWare

StarkWare provides a STARK-based scaling solution to ensure L2 security, speed and seamless user experience. They support multiple data availability modes. StarkNet is their L2 network, while StarkEx is a Rollup verification service for enterprise users, and DApps can be built on StarkEx services. However, currently only customized circuits can be written for specific DApps, not the general zkEVM Rollup. StarkEx supports a series of plug-and-play services, including NFT minting and trading, derivatives trading, etc. In terms of ecology, the decentralized futures contract trading platform DYDX is a loyal user of StarkWare.

StarkNet, strictly speaking, is zkVM. Instead of doing ZK circuits for Ethereum opcodes, it has made a set of more ZK-friendly assembly language, AIR (Algebraic Intermediate Representation) and high-level language Cairo. Although StarkNet itself is not compatible with EVM, it can still be compatible with Ethereum through other methods including Kakarot (Kakarot is a zkEVM written in Cairo, which is a zkEVM whose bytecode is equivalent to EVM). According to my understanding, StarkNet is relatively a centralized project, one of which is that it cannot be synchronized with the security upgrade of Ethereum. Therefore, it is necessary to concentrate R&D personnel to make up for the shortcomings in security and follow the development and adaptation of ETH. new agreement.

StarkNet uses STARK as its proof system. Compared with SNARK, STARK has more innovations. It does not need to rely on "trusted settings" like SNARK. Moreover, it also has simpler cryptographic assumptions, avoids the need for elliptic curve, pairing, and exponential knowledge assumptions, and relies purely on hashing and information theory, so it is more resistant to quantum attacks. Overall, STARKs are more secure than SNARKs. In terms of expansion capabilities, STARK has a significant marginal effect, and the greater the proof, the lower the total cost.

However, in terms of architecture, there is currently only one Sequencer (sequencer) in the system, which is controlled by StarkWare, and there is only one Prover (that is, the prover who generates ZK Proof), which not only generates proofs for StarkNet, but also runs on their own. Proof of generation for all other apps on the StarkEx rollup.

Variants of ZK Rollup: Validiums and Volitions

Validium is also an L2 scaling solution that uses proof of computation such as ZK Rollup to enforce the integrity of the transaction process. Unlike ZK Rollup, Validium does not store transaction data on the Ethereum mainnet. Sacrificing on-chain data availability is a trade-off that can lead to huge improvements in scalability, the most immediate point being that Validiums can process about 9,000 transactions per second.

But in the author's eyes, Validium cannot be regarded as a strict ZK Rollup. This solution is similar to Plasma, and it does not achieve data availability at the L1 layer, so it cannot be counted as a Rollup. The difference with Plasma is that Plasma has set up a "seven-day exit mechanism" similar to OP Rollup in the L2 layer, while Validium uses and ZK means to shorten the verification time of the data at the L2 layer and does not synchronize the data to the L1.

Volition, pioneered by StarkWare, allows users to easily switch between ZK Rollup and Validium. For example, some applications, such as decentralized derivatives exchanges, may be more suitable for Validium, while still wanting to be interoperable with applications on ZK Rollup, then Volition provides this switchability.

zkSync

Similar to StarkNet, zkSync has always insisted on choosing zkVM, which is equivalent to a high-level language, and has attracted much attention, with a very high popularity and lock-up volume. zkSync 1.0 (zkSync Lite) was launched on the Ethereum mainnet on June 15, 2020, achieving a transaction throughput of about 300 TPS, but it is not compatible with EVM. And zkSync 2.0 (zkSync Era) will be launched on March 24, 2023.

The goal of zkSync Era is to generate proofs faster by using their custom VM for optimization rather than chasing EVM equivalence. It supports Solidity, Vyper, Yul and Zinc (rollup's internal programming language) through a powerful LLVM compiler to implement most of the smart contract functions. Due to the self-developed VM, zkSync Era supports native account abstraction, so that any account can use any Token to pay.

In addition, through the application of the zkPorter protocol, combined with ZK Rollups and fragmentation technology, the network throughput has been increased exponentially, reaching 20,000+ TPS (similar to the data availability switching of Volitions).

Overall, zkSync is an ecologically rich L2 project that has attracted the attention of developers and investors. Although there have been some recent cases of completely failed projects on zkSync, there is still a question of whether developers can get a good development and migration experience on the high-level language equivalent of zkVM. There is currently a lack of exact usage reports at the developer level. If developers have a good experience, what is the point of other types of zkVM that strive to be close to the EVM? We still need more time to observe.

Polygon zkEVM

Polygon launched the beta version of the zkEVM Rollup main network on March 27, which is also the equivalent virtual machine of Ethereum, and open sourced all zkEVM code. Compared with zkSync, the locked amount of polygon zkEVM is much smaller, but there are also many interesting and dynamic projects in the ecology.

In terms of Rollup design, Polygon differs from Scroll in that it uses a Proof of Efficiency (PoE) model to motivate the Sequencer and Aggregator to solve some of the challenges of decentralization and permissionless validators. In the permission-free two-step model of sorter-aggregator, any sorter can submit an application for packaging batches in order to obtain the packaging fee, but it needs to pay the Gas fee of the L1 layer and deposit a certain amount of Token; at the same time, the aggregation Tokens need to set their own goals to maximize the guaranteed profit for each proof generation. In addition, Polygon and Volition (ZK Rollup and Validium) modes also have deeply compatible data availability models to provide users with different levels of services.

In addition, Polygon has also invested a considerable amount of work in the ZK protocol, and the effect is also remarkable. In the document, they summarize their technical advantages, mainly including the following points:

1. More compatible: Polygon has always insisted on using zkVM, which is equivalent to EVM, to reduce the cost of developers migrating dApps. At the same time, although Polygon Miden adopts the ZK-STARK protocol, it still supports running Solidity contracts.

2. Easier verification: The reason why ZK Rollup is often criticized is that generating proofs of validity requires expensive specialized hardware that vendors run and pass the cost on to users. Polygon ZK Rollup (like Polygon Zero) aims to simplify proof schemes so that lower-level devices can participate, for example, Plonky2 proof generation tests on consumer-grade PCs.

3. Faster proof generation and verification process: Polygon Zero can generate a 45kb proof in 170 milliseconds.

PART 5 Gap between theoretical technology and practical projects

This research report mainly carried out the science popularization of ZK technology and the introduction of the Rollup mechanism, emphasizing the importance of data availability, and made a certain distinction on the issue of ZK or zkEVM Rollup. In addition, on the basis of distinguishing zkVM and zkEVM, it also sorts out in detail the differences between the three types of zkEVM and the different types and related ZK tracks. Finally, combined with several advantageous projects, they reviewed their respective technical frameworks and existing ecology.

However, in terms of specific projects, projects that choose equivalent high-level languages occupy the mainstream position in the market, and some products with serious centralization such as StarkWare can also win the favor of the market. Even though the first type of VM mentioned in theoretical research has strong limitations, under the limited market customers, "universality" seems to be a burden, and we cannot distinguish which problems "efficient expansion" has broken through and Realized the effect beyond the theory. Of course, in fact, many people don't pay attention to technical features, so this seems not very Web3, but also very Web3.

The purpose of Rollup technology is to further tap the value of the blockchain, but often because of the urgent need to become an "innovative concept" in the market, there is a phenomenon of "backtracking" and returning to centralization. This is the problem with the current market.

The value of the blockchain is easy to see, who wouldn't want to have an eternal computer? But the core problem is that when the running capacity of this computer is far lower than that of any server around us and requires a lot of resource investment, even if the use value is far lower than our input cost, as a "public product", it is still Can everyone get involved?

When we already have products from many countries, societies and even individuals, under what circumstances are we willing to ignore the high cost of use and pursue the result of "always online, always correct"? I think this is something that the blockchain industry needs to think about today. Rollup technology can technically improve this problem, but there are still a large number of problems that need to be left to the impetuous market to solve.