Author: Haotian
It seems that few people think about the native tendency of a chain. For example, we replicated a large number of DEX, Lending, and Derivative platforms on ZK-Rollup to build a trading system, but we found that there is a large slippage loss in transactions, the liquidity is unstable and vulnerable to attacks, the driving force for MEV is insufficient, and the overall experience is very bad. Is it because the underlying Infra of the chain is not good, 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?
The essence of ZK-Rollup is to “pre-process” a large number of transactions on the scaling chain and then batch them to the mainnet to convert the state. There are two uncertainties in this process:
1) The speed sorting and batching of L2 transactions, which varies greatly in terms of transaction peak and off-peak periods, rate, and computational resource input;
- LianGuai Daily | Animoca Brands invests $30 million in Hi; Eco, supported by a16z, launches encrypted wallet Beam
- Project Research | Stacks – Expanding the New Chapter of Bitcoin Smart Contracts and DApps
- The ‘Waterloo’ Incident on zkSync Era? A Brief Analysis of the EraLend Flash Loan Attack
2) The congestion status of the L1 mainnet and the gas fee rate can cause the benchmark fee rate and the shared GAS fees fed to L2 by the oracle to be unstable.
This means that the native nature of the ZK-Rollup model is not friendly to trading. Because trading is an immediate business, uncertainty in the transaction state and results is the biggest taboo. Previously, zkSync and Starknet were once complained about having a large slippage loss in transactions, and many people complained that it was caused by DApp projects. However, the more fundamental reason may be the uncertainty of the transaction benchmark fee rate in Rollup. Even with sufficient pool liquidity, abnormal losses may still occur.
L2 transaction fees are composed of the L2 resource consumption benchmark fee rate + the shared Gas fee on L1. The benchmark fee rate is obtained from the L1 mainnet Oracle price feed, and the Rollup transaction model determines the natural lag in the price feed, which makes the benchmark fee rate pricing unreasonable. In addition, if the current batch of transactions is small and the L1 mainnet is extremely congested, the shared Gas fee will also be higher. If the benchmark fee rate is high and the shared fee is also high, how can transaction wear and tear not be large?
In order to compensate for the loss caused by the instability of Gas, zkSync has a Gas refund mechanism. Usually, after the transaction is completed, based on the actual Gas consumption and the resource savings generated by system self-optimization, the excess Gas Fee paid by the user will be refunded. However, this is only 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 Cancun upgrade.
As for the issue of insufficient liquidity:
1) The high transaction cost is not friendly to mainstream large funds pursuing capital efficiency, which restricts the inflow of institutional funds;
2) zk-Rollup inherently squeezes the living space of MEV, because the transactions announced to the Mempool are all SNARK encrypted proofs. Imagine, in the early ecology of a public chain, if there is a lack of large funds and the active presence of MEV arbitrageurs, and only a few small-scale participants are left, 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 that does not have much impact on the matching efficiency of current transactions;
3) Sequencer can provide real-time GAS benchmark fees, smoothing out lags.
In comparison, ZK-Rollup has inherent weaknesses in transaction matching, such as the generation, verification, and algorithm complexity of SNARK proofs. Of course, this is just a preference and cannot directly assert that ZK is not suitable for transactions. Preference means the innovation and activity 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 projects.
In fact, each chain has its own inherent problems. 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 nearly zero Gas, making it exciting to scalp in many altcoins; Cosmos is suitable for secure cross-chain transactions in a multi-chain system; Solana’s TPS of tens of thousands of transactions per second is suitable for gaming applications.
Where is the native preference track of ZK-Rollup? Projects with high concurrency, high TPS, and less sensitivity to transaction matching latency: gaming and social applications.
1) The larger the transaction volume handled by ZK-Rollup, the cheaper the fees.
2) Starknet’s latest experimental test TPS can reach 890K/s, and zkSync has also attracted Blizzard executives. Don’t prematurely deny the development potential of ZK’s native chain based solely on the poor experience of DEX, lending, and other financial gameplay.
Like what you're reading? Subscribe to our top stories.
We will continue to update Gambling Chain; if you have any questions or suggestions, please contact us!
