Explore the specialization of major chains from a native orientation

Native-oriented exploration of major chain specialization

Author: Haotian

Each chain has its own inherent issues. For example, Ethereum prefers mature transaction settlement systems and is suitable for building complex financial applications. BSC favors the deployment of arbitrage robots and other programs, with almost zero Gas fees, making it highly profitable for high-frequency trading among many altcoins. Cosmos is suitable for safe and seamless cross-chain transactions within a multi-chain ecosystem. Solana, with its high TPS in the thousands, is suitable for gaming applications.

It seems that few people consider the inherent issues of a chain. For example, we replicated a large number of DEX, Lending, and Derivative platforms as trading systems on ZK-Rollup, only to find that there were significant trading slippage losses, unstable liquidity, vulnerability to attacks, and insufficient MEV incentives, resulting in a poor overall experience. Is it because the underlying infrastructure of the chain is inadequate, or is the direction of the applications built on top of it wrong? It begs the question, is ZK really suitable for “trading” scenarios?

ZK-Rollup essentially “pre-processes” a large batch of transactions on the scaling chain before batching them on the mainnet for state transition. During this process, there are two uncertainties:

1) The speed of aggregating and batching transactions on L2 varies greatly during peak and off-peak periods, depending on the rate and allocation of computational resources.

• Move Wars What are the independent innovations of the Aptos and Sui...
• Buidler DAO Understanding Curve Technology Details and Governance C...
• IOSG Weekly Report On-chain Game Technology Stack How to Synchroniz...

2) The congestion and gas fees on the L1 mainnet can cause the benchmark fees and shared gas fees provided to L2 by the oracle to be unstable.

This means that the ZK-Rollup model is inherently unfriendly to trading. Trading is an immediate business that cannot tolerate uncertainty in transaction status and results. Previously, zkSync and Starknet were complained about for significant trading slippage losses, and many people blamed DApp projects for this. However, the root cause may lie in the uncertainty of the transaction benchmark fees in Rollup. Even with sufficient pool liquidity, abnormal losses can still occur.

L2 transaction fees consist of L2 resource consumption benchmark fees and L1 shared gas fees. The benchmark fees are obtained from the L1 mainnet Oracle, and the Rollup transaction model determines the inherent lag in benchmark pricing, which makes the benchmark fees unreasonably priced. In addition, if the current batch has a small transaction volume and the L1 mainnet is extremely congested, the shared gas fees will also be higher. If high benchmark fees coincide with high shared fees, how can transaction costs not be significant?

To compensate for the losses caused by this unstable gas fee issue, zkSync has a gas refund mechanism. Usually, after the transaction is completed, the system will refund the excess gas fee paid by the user based on the actual gas consumption and resource savings generated by system optimization. However, this is only a remedial measure and it is difficult to balance the experience gap caused by transaction costs for users. However, perhaps this problem will be significantly resolved after the upgrade to Ethereum’s Cancun version.

As for the issue of insufficient liquidity:

1) Significant trading losses are not friendly to mainstream large capital seeking capital efficiency, which limits the inflow of institutional funds;

2) zk-Rollup naturally squeezes the survival space of MEV, because the transactions announced to the Mempool are all SNARK encrypted proofs. Just imagine, in the early ecosystem of a public chain, without large funds and the active presence of MEV arbitrageurs, only relying on the “mooning” community, how much TVL can be supported?

As a Rollup mechanism, OP-Rollup is superior to ZK-Rollup in terms of transaction preference:

1) Its relatively centralized Sequencer transaction system can efficiently sort and match transactions;

2) The fraud proof system is a retrospective punishment mechanism, which does not have much impact on the matching efficiency of current transactions;

3) The Sequencer can provide real-time GAS benchmark fees, smoothing out any lag.

In comparison, ZK-Rollup has inherent weaknesses in transaction matching due to the generation, verification, and algorithmic complexity of SNARK proofs. Of course, this is just a preference, and it cannot be directly asserted that ZK is not suitable for transactions. Preference implies the innovation factor and active factor of the chain itself. It can only be said that the lack of transaction preference in zk-Rollup greatly limits the transaction activity and the possibility of the birth of excellent transaction projects.

In fact, each chain has its own native tendency issues. For example, Ethereum prefers mature transaction settlement systems and is suitable for building complex financial applications; BSC prefers the deployment of arbitrage robots and other programs, with almost 0 Gas and the thrill of profiting from many altCoins at high frequency; Cosmos is suitable for secure cross-chain transactions in a multi-chain system; Solana’s TPS of tens of thousands per second is suitable for gaming applications.

Where is the native preference track for ZK-Rollup? Projects with high concurrency, high TPS, and less sensitivity to transaction matching lag: gaming and social applications.

1) The larger the transaction volume processed by ZK-Rollup, the cheaper the fees.

2) Starknet’s latest experimental test shows a TPS of up to 890K/s, and zkSync has also attracted Blizzard executives. Don’t prematurely dismiss the development potential of ZK native chains based solely on the poor experience of DEX, lending, and other financial applications.