Huge circuits processing

[tyrysh-malay]

Team or Project

No response

ZK chain

Era

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 have kinda general questions. How does zkSync handle massive programs, like tens of millions constraints? It seems that it leverages recursion. I found one mention of recursion in docs, https://docs.zksync.io/zksync-protocol/circuits/circuits#public-input-structure but as for quick research, the recursion topic is never discussed further. Also, there is Recursion tip mentioned in upgrade v24, from May, 2024, but I guess that's the only specification of recursion and the rest is just pure implementation. So, my questions are:

1. Is it feasible to prove big circuits on zkSync (tens to thousands of millions of constraints)?
2. How can I find docs related to recursion?

Repo Link (Optional)

No response

Additional Details

No response

[ly0va]

Hi @tyrysh-malay!

1. Just to avoid any misunderstanding, when you refer to "proving big circuits on zkSync", what exactly do you mean? zkSync is not a proof system by itself, rather, it uses Boojum proof system to prove the state transitions of its blockchain state after every block. You cannot access the Boojum provers/verifiers directly from zkSync, rather, they are used implicitly and indirectly to verify all executions and state changes from users' transactions. Generally, the more operations are executed in a block, the more constraints are proven for that block. So is your question about the limit on constraints that we have for each block that we prove, or something else?
2. Generally, when we refer to recursion in this context, we mean the ability of the verifier program to be a circuit itself, and thus the ability to prove that a certain ZK proof (or multiple) was verified as part of another proof. This way we can aggregate multiple different ZK proofs into one, and potentially do this trick multiple times (having multiple recursion layers). For each base layer circuit, we aggregate them via a Leaf aggregation circuit, which are subsequently aggregated via Node aggregation circuits, aggregated by the Scheduler circuit, which is then wrapped into a PLONK proof and sent to the settlement layer: diagram. If you are interested to learn more about the proof systems that we use, check out additional resources from our docs.

[tyrysh-malay]

Hi @ly0va!

1. Yeah, exactly that! So, the idea is that I want to prove a huge amount of computations that have the same repetitive pattern, and the problem is that I don't really know what amount of computation a block and batch can hold. If you would help with that, that would be just perfect.
2. Thank you for sharing the links! Will use those for future references:)

[ly0va]

@tyrysh-malay there are multiple seal criteria that influence when a block is sealed. This includes, but is not limited to:

• Amount of pubdata to publish on the settlement layer
• Number of L2->L1 logs
• Amount of certain types of circuits included (i.e. circuit geometry)
• Gas limit

Whether or not any of these get triggered depends on different factors, such as where your transaction is in a block, what kind of transactions precede it, etc.

But if you indeed intend to execute "a huge amount of computations" on ZKsync, it might be worth checking if it fits into ZKsync's MAX_TRANSACTION_GAS_LIMIT which currently is set to 80_000_000 L2 gas.

Feel free to unmark this discussion as answered if you have further questions.

[tyrysh-malay]

@ly0va That's very much what I needed! Thank you for guidance, appreciate that :)