System Performance
ZK Rollup’s advantage over Optimistic Rollup is that it adopts zero-knowledge proof to verify the validity of the transaction. As long as the zero-knowledge proof of each block is verified in the Layer 1 contract, it means that every transaction in the block is valid. It is worth mentioning that when a user withdraws tokens from Layer 2 to Layer 1, the tokens will be received only after the zero-knowledge proof is verified. Therefore, the generation time of zero-knowledge proofs directly affects the user's withdrawal time.
With traditional ZK protocols, it takes 6 to 8 hours to withdraw. This is partly because that the transaction volume is not saturated and the block waits for a long time for processing. However, the main reason is that it takes a long time to generate the zero-knowledge proof. Therefore, how long it takes to generate zero-knowledge proofs directly affects the user experience of ZK Rollup products.
First, we define the TPS model (transactions per second) of the ZK Rollup production system.
Usually, we can find a theoretical performance formula based on ZK Rollup:
block_gas_limit is the maximum gas of each block. For example, the current gas limit of each block in Ethereum is 15 M.
tx_calldata_gas is the on-chain gas consumption of Rollup transaction information. For example, calldata is 30 bytes long and gas consumption is 30*16=480 gas.
block_interval is the block interval, which is 13 to 15s on Ethereum.
According to this calculation method, a theoretical TPS of 2 to 3 k (or even higher) can usually be obtained.
However, this calculation method ignores the following issues:
1) The actual proof generation time (latency) is not considered.
2) The amortization of gas consumed by block information and proof verification is not considered.
3) The difference in gas consumption of different transaction types is not considered (the layer 2 transaction information that supports EVM cannot be compressed very effectively).
When building a production system, we believe that the TPS model should be defined as:
Where:
TXs_per_block is the maximum number of transactions that can be accommodated in each Layer 2 block.
N_proof_parallel is the degree of parallelism of proof generation, indicating how many provers are simultaneously generating proofs.
T_proof represents the time required for a single proof.
By increasing the parallelism of proof tasks, TPS can be effectively increased, but this significantly increases the cost of generating proofs off-chain. According to our TPS formula, under the premise that the number of transactions in each layer 2 block is certain, TPS can also be improved by reducing the generation time of a single proof apart from the above mentioned approach. Therefore, we have done a lot of work in accelerating zero-knowledge proofs.
Last modified 1yr ago