Author: Haotian, source: author twitter@tmel0211

It seems that few people think about the original sexual orientation of a chain. For example, we replicated a large number of DEX, Lending, and Derivative platforms for trading systems on ZK-Rollup, but found that trading slippage was high, liquidity was unstable and vulnerable to attacks, MEV source power was insufficient, and the overall experience was poor. Is it because the underlying Infra of the chain is not working, or is the application direction of the upper layer build wrong? I can't help but ask, is ZK really suitable for "trading" scenarios?

The essence of ZK-Rollup is to "preprocess" the large-scale transactions of the extended chain first, and then concentrate the batch to the main network to convert the state. In this process, there are two uncertainties:

1) L2 transaction pooling speed sorting and batching problems, the speed and computing resources input vary greatly during the peak period and the trough period of the transaction;

**2) The congestion of the L1 main network and the Gas rate will cause the base rate fed to L2 by the oracle machine and the amortized GAS fees to be unstable. **

**This means that the native nature of the ZK-Rollup model is not friendly to Trading. Because the transaction is an instant business, the uncertainty of the transaction status and results is taboo. ** Previously, zkSync and Starknet were once complained about the loss of transaction slippage, and many people complained that DApp projects were causing trouble, but the core reason may be that Rollup’s transaction benchmark rate is uncertain. Even under the premise of sufficient pool liquidity, abnormal loss may occur.

The L2 transaction fee is composed of the L2 resource loss base rate + the L1 apportioned Gas fee. The base fee rate is obtained from the L1 main network Oracle price feed. The Rollup transaction model determines that there is a natural lag in the price feed, which makes the base rate pricing unreasonable; in addition, if the current batch transaction volume is small, it coincides with the extreme congestion of the main network L1 , the Gas fee under the apportionment will also become higher. If the base fee rate is high and the apportionment fee is high, how can the transaction wear be small?

In order to make up for the loss caused by such unstable Gas, zkSync has a set of Gas refund mechanism. Usually, after the transaction is completed, it will refund the extra payment to the user based on the actual Gas consumption and the resource saving caused by system self-optimization. Gas Fee, but after all, it is a remedial measure, and it is difficult to balance the experience gap brought by its transaction wear and tear to users. However, perhaps this problem will be significantly resolved after the Ethereum Cancun upgrade.

As for the illiquidity issue:

1. The loss of transactions is large, and it is not friendly to the mainstream big funds that pursue capital efficiency, which limits the inflow of institutional funds;

2. zk-Rollup natively squeezes the living space of MEV, because the transactions announced to Mempool are all SNARK encrypted proofs. Just imagine, how much TVL can an early public chain ecology be able to support without large funds, without active figures of MEV arbitrageurs, and with only masturbation parties left?

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

1. Its relatively centralized Sequencer trading system can efficiently sort and match transactions;

2. The fraudsters prove that the system is a punishment mechanism after the event, which has little impact on the matching efficiency of the current transaction;

3. Sequencer can instantly give the base rate of GAS to smooth out the lag.

**In contrast, ZK-Rollup's SNARK proof generation, verification, and algorithm complexity naturally have certain weaknesses in transaction matching. ** Of course, this is just a preference, and it cannot be directly asserted that ZK is not suitable for trading. Preference means the innovation factor and activity factor 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 tendency. For example, Ethereum prefers a mature transaction settlement system, which is suitable for building complex financial applications; Don’t be too addicted to the wool in the middle; Cosmos is suitable for free and safe cross-chain in a multi-chain system; Solana’s TPS of 10,000 per second is suitable for game applications.

**Where is the original preference track of ZK-Rollup? Projects with high concurrency, high TPS, and not sensitive to transaction lag: games and social networking. **

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

2. Starknet's latest experimental test TPS can reach 890K/s, and zkSync is also joined by Blizzard executives. Don’t prematurely deny the development potential of the ZK protochain just based on the bad experience of DEX, Lending and other financial games.