Memory limit exceeded error in zkVM integration with Grandine

[jimmychu0807]

Hi Brevis Pico team, I am in Ethereum Protocol Fellowship Cohort 6 and is working on integrating Pico in Grandine, an Ethereum client, to generate zk-proof on block state transition function. Here are the relevant repo & code.

When I run on a test case of mainnet without epoch transition, basically passing this state ssz and block ssz into the state transition function in emulation mode, the zkVM will eventually panicked and complain Memory limit exceeded (0x78000000).

The full log can be downloaded here.

For your info, we have also integrated r0vm to run the same test case, it will finish the test, in dev mode - no proof generation, in 3066.35s. Appreciate greatly if Pico dev team could look into this case. Eventually it is also good to have zkVM that is comparable to others.

I am happy to assist on how to run the test case. If you need any other info from my side, you could reply to this issue thread as I will be monitoring it. I am also in Brevis Network Discord server and could be reached with my ID: jimmychu0807

Thank you.

[will-brevis]

This is likely due to the chunk batch size being too high. Pico tries to prove multiple chunks in parallel and this has a high memory cost due to the expansion of events into trace matrices as well as just holding the entire execution history in memory. Try setting the environment variable CHUNK_BATCH_SIZE to a lower value, i.e. from 16 to 12. The automatic batch size detection uses a general memory heuristic and may underestimate the memory requirements for proving.

You can check the current batch size by examining EmulatorOpts::chunk_batch_size.

[will-brevis]

Looking deeper into the logs, it seems like the root cause is because the guest ran out of memory. In particular,

2025-09-11T07:46:48.029186Z  INFO 
thread '<unnamed>' panicked at /home/jimmychu/.cargo/git/checkouts/pico-12879671a3c04d08/79b10e6/sdk/sdk/src/riscv_ecalls/memory.rs:46:9:
Memory limit exceeded (0x78000000)
    
2025-09-11T07:46:48.029275Z  INFO Memory limit exceeded (0x78000000)    

thread 'main' panicked at /home/jimmychu/.cargo/git/checkouts/pico-12879671a3c04d08/79b10e6/vm/src/emulator/emulator.rs:109:49:
called `Result::unwrap()` on an `Err` value: HaltWithNonZeroExitCode(1)

this is a static limit imposed by the default guest allocator. free does not release any memory. our memory model also treats the address as a raw field element, meaning that for proofs using the babybear prover, addresses 0 and 2^31 - 2^27 + 1 are treated the same by the memory argument, so this limit must be imposed for soundness.

risc0 is able to provide a higher maximum address for their allocator, which is likely why it does not run out of memory. we share a similar memory argument with SP1, which shares this 0x78000000 limit, so the program must be memory optimized in order to be proven.

[jimmychu0807]

I see. Thank you for the explanation. That's helpful in understanding the max memory limit.