State transition function snarkification

[unnawut]

This is the overarching pm issue to track the efforts to prototype the CL's STF (state transition function) snarkification using different ZK architectures.

Scope of work

1. Get current beacon state from testnet (or ephemery)
2. Snarkify block and slot processing
3. See the result (state root i guess?)

Additional: Justin mentioned preliminary work with hints could also be beneficial.

Targets

• SP1: https://github.com/ReamLabs/consensp1us
• risc0: https://github.com/unnawut/consenzero

References

• https://github.com/succinctlabs/sp1-helios - A wrapper project of helios(light client impl by a16z) by sp1, I thought developing CL version like this could work
• https://github.com/succinctlabs/sp1-reth
• See https://github.com/ethproofs/ethproofs for the current efforts to benchmark ZK proving of the execution layer

[KolbyML]

https://github.com/ReamLabs/ream/tree/master/crates/runtime

The zkVM's and abstraction should go in this area, we can make new crates likely within the runtime folder ad hoc.

I think it makes sense to support powdr and sp1 possing making an abstraction so we can choose which one we want to use. We can start with one zkVM starting out, then add support for another after.

[pmuens]

As we discussed in our call today I'll be looking into Powdr as @syjn99 is already working on an SP1 PoC and @unnawut is working on one in RiscZero.

[unnawut]

Just noting down for later recalls:

While today generating a proof for an Ethereum block takes many minutes or hours, we know that there is no theoretical reason preventing massive parallelization: we can always put together enough GPUs to separately prove different parts of a block execution, and then use recursive SNARKs to put the proofs together. Additionally, hardware acceleration through FPGAs and ASICs could help optimize proving further. However, actually getting to this point is a significant engineering challenge that should not be underestimated. - https://notes.ethereum.org/@vbuterin/enshrined_zk_evm

Once sufficiently advanced enough we should look into how the proving work can be parallelized.

[unnawut]

Some notes from Justin:

Loading the full state is suboptimal. State reads and write are better to be done statelessly

no need to commit to the whole beacon state (except maybe once at genesis)

First load the state root. Then:

• for reads: load the Merkle path from the leaf being read and authenticate the Merkle path to the state root
• for writes: first read, then update the value, then remerkleise the Merkle path to get a new state root

Some SSZ libraries should have all this implemented.