Exploring the issue of chain nativity bias Is ZK really suitable for transactions?

Is ZK suitable for transactions with chain nativity bias?

Author: Haotian, Source: author’s twitter @tmel0211

It seems that few people think about the inherent tendency of a chain. For example, we have replicated a large number of DEX, Lending, and Derivative platforms on ZK-Rollup to build a trading system, but we found that there are significant slippage losses in transactions, unstable liquidity vulnerable to attacks, insufficient driving force for MEV, and overall poor user experience. Is it because the underlying infrastructure of the chain is not good enough, or is the direction of the applications built on top of it wrong? One cannot help but ask, is ZK really suitable for “trading” scenarios?

ZK-Rollup essentially pre-processes a large batch of transactions on the expansion chain and then batch converts them into the mainnet. There are two uncertainties in this process:

1) The speed sorting and batching of transactions on L2 vary greatly during peak and off-peak periods in terms of rate and computational resources;

• How did Futureverse build an AI metaverse with a financing of 54 million US dollars?
• Don’t worry! Withdrawing 1 million U safely is very simple!
• Raising $54 million in funding, how does Futureverse build an AI metaverse?

2) Congestion and gas fees on the L1 mainnet can cause the benchmark fees fed to L2 by the oracle and the distribution of GAS fees to be unstable.

This means that the ZK-Rollup model is inherently unfriendly to trading. This is because trading is an instantaneous business that abhors uncertainty in transaction status and results. Previously, zkSync and Starknet were also complained about significant slippage losses in transactions, and many people complained that DApp projects were to blame, but the more fundamental reason may lie in the uncertainty of the benchmark transaction fees of Rollup. Even with sufficient pool liquidity, abnormal losses may occur.

L2 transaction fees consist of the benchmark fees for L2 resource consumption and the distribution of gas fees on L1. The benchmark fees are obtained from the L1 mainnet oracle feed, and the Rollup transaction model determines the natural lag in the feeding of benchmark fees, making the pricing of benchmark fees unreasonable. In addition, if the current batch of transactions is small and the L1 mainnet is extremely congested, the distributed gas fees will also be higher. If the benchmark fees are high and encounter high distributed fees, how can transaction wear and tear be avoided?

To compensate for the loss caused by the instability of gas fees, zkSync has a gas refund mechanism. Usually, after the transaction is completed, based on the actual gas consumption and resource savings generated by system optimization, the excess gas fees paid by users are refunded. However, this is still a remedial measure and it is difficult to balance the experience gap caused by transaction wear and tear for users. However, perhaps this problem will be significantly resolved after the Ethereum Constantinople upgrade.

As for the issue of insufficient liquidity:

1) The significant transaction costs are not friendly to mainstream large funds pursuing capital efficiency, limiting the inflow of institutional funds;

2) zk-Rollup inherently squeezes the survival space of MEV, because the transactions announced to the Mempool are all SNARK-encrypted proofs. Imagine, in the early ecosystem of a public chain, without large funds and the active presence of MEV arbitrageurs, only the small retail investors are left, how much TVL can be sustained?

As Rollup mechanisms, OP-Rollup is superior to ZK-Rollup in terms of transaction preference.

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

2) The fraud-proof system is a mechanism for retrospective punishment, which has little impact on the matching efficiency of current transactions;

3) The Sequencer can provide instantaneous GAS benchmark fees, smoothing out lags.

In contrast, ZK-Rollup’s SNARK proof generation, verification, algorithm complexity, and other factors naturally have certain weaknesses in transaction matching. Of course, this is just a preference and cannot directly assert that ZK is not suitable for transactions. Preference means the innovative and active factors of the chain itself. It can only be said that the lack of transaction preference in zk-Rollup greatly limits the possibility of transaction activity and the birth of excellent transaction-oriented projects.

In fact, every chain has its own inherent bias. 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 zero Gas fees, making it very enjoyable for high-frequency arbitrage among many altcoins; Cosmos is suitable for free and secure cross-chain transactions in a multi-chain system; Solana’s TPS of tens of thousands per second is suitable for gaming applications.

Where does ZK-Rollup’s inherent preference lie? Projects with high concurrency, high TPS, and less sensitivity to transaction matching lags: gaming and social applications.

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

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

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