As part of Ream’s (meta issue for zkVM integration), one of the goals is to run the full CL (Consensus Layer) state transition function within a zkVM. For this prototype, I'm using Jolt zkVM as the proving backend.
When attempting to prove minimal state transitions (specifically process_block) using Jolt, the guest panics, likely due to input size limitations. The current implementation attempts to load pre-state transition Beacon chain as input ( SSZ Snappy-decoded), which results in excessive memory use or constraints being hit inside the guest VM.
Here’s a brief outline of what the Ream STF prover does:
Deserialize BeaconState and SignedBeaconBlock using SSZ.
Run process_{functions} from the consensus logic.
Output the updated BeaconState root.
This works outside the zkVM, but fails when embedded inside Jolt as a guest program.
For reproducing the issue follow the steps in the README
I tried changing the input limits inside #[jolt::provable()] myself but even that didn't help
As part of Ream’s (meta issue for zkVM integration), one of the goals is to run the full CL (Consensus Layer) state transition function within a zkVM. For this prototype, I'm using Jolt zkVM as the proving backend.
When attempting to prove minimal state transitions (specifically process_block) using Jolt, the guest panics, likely due to input size limitations. The current implementation attempts to load pre-state transition Beacon chain as input ( SSZ Snappy-decoded), which results in excessive memory use or constraints being hit inside the guest VM.
Here’s a brief outline of what the Ream STF prover does:
Deserialize BeaconState and SignedBeaconBlock using SSZ.
Run process_{functions} from the consensus logic.
Output the updated BeaconState root.
This works outside the zkVM, but fails when embedded inside Jolt as a guest program.
For reproducing the issue follow the steps in the README
I tried changing the input limits inside #[jolt::provable()] myself but even that didn't help