A poster of the launch of Polygon zkEVM sparked a big discussion among the founders of the public chain about scalability

On February 26, a promotional poster announcing the launch of the mainnet of Polygon zkEVM sparked a debate about the use of the term “Ethereum” equivalence, and Ye Zhang, the founder of Scroll, solemnly pointed out that Polygon zkEVM does not have this feature. In hindsight, Ryan Wyatt, head of Polygon Labs, responded that this was more the result of poor communication between marketers and technicians within the team.

This is not a trivial matter, and the extent of effectiveness will even be directly related to L1/L2 performance and scalability, just two days ago, Solana co-creator Toly published an article that ZK L2s will not be the best solution to solve scalability.

On February 27th, the Polygon technical team, the protagonist of this event, also actively responded to the working principle of zkRollup, explaining where the scalability of zkRollup is pointing.

On March 1, Solana also announced a “plan to improve the network upgrade” to re-carry the banner of Ethereum’s killer, but its operating mechanism has not been fundamentally innovated after multiple outages, and it is more like a post-crisis optimization, which also casts a shadow on the replacement of Ethereum by high-performance L1.

This article will combine the tweets of several L1/L2 founders to reveal the ins and outs of the big discussion about the performance of public chains.

Origins: The Debate on EVM Equivalence

Polygon’s zkEVM, strictly speaking, is a zk VM mechanism, which is consistent with the Ethereum mainnet at the L2 level through mapping, and the introduction of zk technology is the reason why it is called zk VM, and in a non-strict sense, as long as it can maintain synchronization, then it is harmless to call it zk EVM.

However, according to Ye Zhang, the founder of Scroll, EVM equivalence is not exactly the same as Ethereum equivalence, because the latter needs to be at least consistent with the Ethereum mainnet in terms of data storage.

From a broader perspective, none of the current L2s or Ethereum cross-chain bridges can claim to be Ethereum equivalent, and Ethereum’s more modular and complex stacks will bring more difficult compatibility.

A simple example can be given to intuitively understand the difference between the two, Optimism deals with the difference between the two in product planning, in its opinion:

EVM equivalence: Mainly from the perspective of dApp developers, their experience on OVM is no different from that of developing dApps on the Ethereum mainnet, so OVM has EVM equivalence;

Ethereum equivalence: Mainly from the perspective of protocol developers, it is necessary to maintain a high degree of consistency with Ethereum in terms of client, communication layer, consensus layer and execution layer.

In addition to the EVM equivalence debate, it should also be noted that the controversy over scalability is currently the focus of the battle between Ethereum-based L2 and high-performance L1.

Antecedent: Solana’s Doubts about ZK Scalability

On February 24, two days before the launch of the Polygon zkEVM trailer, Solana co-creator Toly posted a post on Twitter questioning the ability of ZK L2s to solve the problem of public chain scaling, in order to offset the public’s doubts about the operation mechanism of Solana.

His main points are as follows:

• Real-time data uploading to the chain requires stable sequential execution capabilities;
• The ZK proof scheme is valid, provided that the sum of ZK proof generation time + verification time is less than the real-time execution time;
• The ZK solution cannot process large quantities of data in real time, and can only perform intermittent aggregation, but cannot maintain the real-time status of the on-chain state;

Therefore, the ZK solution is more suitable for single-time, low-frequency scenarios, such as batch settlement, while Solana is still required for the scalability of the public chain.

Unfortunately, Solana suffered a severe outage on February 25th, and the community, engineers, and validators regained mainnet after two reboots, and the house leak coincided with overnight rain, and the “do-gooders” took the opportunity to question Solana’s mechanism, with Twitter user DBCryptoX arguing that “90-95% of transactions on Solana contain validator messages and on-chain voting”.

Solana uses a PoS consensus mechanism, which calls itself a “Proof of History” mechanism. PoH enables the network to run faster because nodes do not need to communicate to validate a block, and PoH enables validators to pinpoint events at a certain point in time.

On the one hand, this mechanism brings a high degree of uniformity, bringing TPS far beyond the Ethereum mainnet, but on the other hand, it does take up a lot of on-chain block space, and once something goes wrong, it is difficult to reach consensus to restore the network. At least one mainnet outage event occurred per year for at least 2021-2023.

The outage event has contributed a negative lesson to Solana’s scalability. Solana co-creator Toly believes that the prover on ZK L2 cannot be executed in real time, so the final on-chain execution of ZK L2s will not be in the established order, so either users can run full nodes to increase the burden on the network, or rely on a few honest nodes to improve efficiency and go centralized.

However, it turns out that the high-performance L1 Solana does not seem to solve the real-time execution problem, after all, a collapsed network will eventually lose the established order, and the forcibly recovered data will become an artificial “consensus” rather than the spontaneous state of the network itself.

Consequences: Polygon’s Scalability Lies Critically

Polygon zkEVM was first questioned by Solana and then announced that there was an oolong incident, which was suspected of being unprofessional and misleading. So the developer, Jordi Baylina, jumped out and took on the challenge of professionalism, focusing on explaining that the prover is not the limiting factor for ZK L2s, and the real hindrance is DA (data availability).

The first is the operation process of zkRollup, which can be roughly divided into three steps, as shown in the figure below:

Keeping the network in sync, regardless of the architecture of the rollup, as long as the data on L2 is involved, it needs to prove the validity of the batch of messages so that they can be confirmed when they are finally returned to L1.

Aggregate proof generation requires the use of the zk proof scheme (ZKP), which can be accelerated by parallel processing, but the generation of batch proofs itself does take some time. It is even possible to design dynamic mechanisms where the number of network provers can be increased or decreased depending on the needs of the network.

Once ZKP is running, a complete tree-proof network is generated for the data, which allows different servers to verify the data and send the results to the L1 chain.

The second is the cost issue, the most critical of which is the proof cost, the software, hardware and time of ZK operation call will be included in the calculation factor by the TX (transaction) fee, and finally reflected in the gas fee of the network, and different algorithms, such as STARK/SNARK/FLONK, etc., will greatly optimize the cost of network use. The key point is that the loading of data does not need to be performed sequentially in order to facilitate parallelization.

Therefore, the Prover that Solana believes cannot hinder the operation of ZK proofs, and the real obstacle is data availability, which needs to be solved by ETH 2.0, DankSharding, EIP4844 and other solutions.

Conclusion: Where is scalability heading

The debate around Polygon zkEVM will continue, and the key will be to how well the zk EVM can solve the current scalability problem, which will be the next test for L1/L2s to face with large-scale dApps and users.