I want to calculate how many groth16 proofs we can fit in a block

[guha-rahul]

Team or Project

No response

Environment

Testnet

L2 block number

No response

Provide a brief description of the functionality you're trying to implement and the issue you are running into.

I want to calculate how many groth16 proofs we can fit in a block but since zksync has variable block space. How should the calculation be done?

Repo Link (Optional)

No response

Additional Details

No response

[gleenai[bot]]

To calculate how many Groth16 proofs you can fit in a ZKsync block, you'll need to consider the variable block space of ZKsync, which can affect the number of proofs per block. Unfortunately, the specific details on the calculation method or the exact block space limits for Groth16 proofs on ZKsync are not provided in the documentation I have access to.

For a precise calculation, you might need to consider factors such as the size of each Groth16 proof and the current block size limits on the ZKsync network. If you need detailed guidance or specific parameters for ZKsync blocks, I recommend visiting the ZKsync developers discussions on Github where you can post your query and interact with the community or the ZKsync team for more tailored assistance.

Your feedback helps us serve you better. If this fully addresses your question, please give it a thumbs up. If it doesn't, please give it a thumbs down. This will inform the community and team so we can improve our support.

[popzxc]

ZKsync has several different criteria for sealing L1 batches, including L1 block capacity (mostly relevant for pubdata), crypto backend capabilities, and L2 gas. You can find the implementation details here.

I assume that for Groth16 the most relevant part would be L2 gas, so here some info:

• block.gaslimit is (1 << 50). block.gaslimit here stands for gas limit for L1 batch (e.g. it's the same across all the L2 blocks).
• Our API server is configured to limit gas available to a single transaction. Right now, the transactions with gas limit set to the values more than 4000000000 will be rejected by the API. It's not a protocol limitation though, just a preventive measure agains DoS.

I'm not sure if it's possible to calculate the exact number of proofs here, but hopefully these pointers should be enough to get you started.
For your use case, I'd suggest trying running a sequencer locally and writing a setup to measure that (probably for that you want to change the values for L1 batch / L2 block timeouts, so that the blocks are not sealed because of that -- see the node configuration for that).