Tracking Issue: Optional Execution Proofs

[kevaundray]

Optional Execution Proofs

Rationale

We want to reduce the resource requirements for attesters, however as the gas limit for the execution payload increases, so does resource consumption. There are proposals to reduce the consumption or have more efficient use of resources like gas repricing and RLNC.

zkEVMs - Prover and Verifier

These fall under the general class of solutions where you add asymmetry into the system to make one entity do less, while needing another entity to do more. Proof generation is usually resource intensive, but proof verification is usually an order of magnitude cheaper.

zkEVMs introduce an entity called a prover who is responsible for generating proofs of execution for the "EL block"/execution payload. ie instead of executing the block and seeing that it was valid via re-execution, one can verify a proof and it will be as if you had executed the execution payload using the El state transition function.

The verifier in this case would be attester.

Tradeoff

Ultimately, the tradeoff is that we can have resource constrained attesters by introducing more powerful provers. The changes in gas limit and mispriced opcodes affect the prover(builders) and not the verifier(attesters).

Progress so far

We have a spec here and Teku is interoperating with the LH POC.

To see what the full diff of changes may look like, we have this PR with Kurtosis configs.

Notable changes

Fork choice

A block is not imported into forkchoice until all blobs are available, similarly a block is not importable into forkchoice until all the proofs for that block have been received.

Networking

When syncing a block, if the block is within the blob retention window, one tries to sync the blo. Similarly, but this may change, proofs are kept until the block has been finalized, ie there is a 2 epoch retention window.

Subnets

Blobs have multiple subnets. One difference here with execution proofs (currently) is that there is one topic/subnet and all proofs are received on that subnet. Currently this is because attesters see different execution proofs as fungible. They only need a k of them.

Proof generation

Currently this is different to blobs in that it requires GPUs, so it cannot be done by the validator. We have a ProofGenerationService for this, so its not extra code for the lighthouse node

Proof Arrival

Another notable difference is that proofs arrive or are even only available after the block has been made, whereas blobs may be in a particular validators EL well before they receive the block. This feature therefore has a dependency on delayed execution/ePBS.

Proof size

Also note that the size of proofs currently are quite large. On the order of 300KB (this can be configured with tradeoffs in proof generation time), but its a new thing that the networking stack may not be accustomed to (h/t dapplion)