Thanks to Jochem Brouwer, Sina Mahmoodi, Thomas Thiery, Rahul Guha, Carlos Perez, Guillaume Ballet for their review and feedback.

TL;DR:

• This post provides a broad perspective on solutions for a well-known worst-case scenario involving L1 snarkification: bytecode chunking.
• Upcoming L1 scaling and other protocol changes exacerbate this worst-case scenario. While these changes must continue, it's important to start thinking about how to address future SNARKification challenges.
• As time passes and Ethereum evolves, there is increasing diversity of opinion among core developers and researchers regarding the risks associated with significant protocol changes, so it is important to deeply explore the nuances of every potential solution.
• The goal of this document is to:
  • Survey potential solutions to this problem, ranging from least to most complex, highlighting the distinct tradeoffs of each.
  • Raise awareness, encouraging more people to consider it and propose even better solutions.
• This doesn't require immediate action (e.g., "Glamsterdam") — even apparently simple solutions need thorough analysis to determine the best path forward.

This document explores solutions to the worst-case scenario for block proving: contract bytecode required in execution traces. This problem is longstanding, with various proposed solutions. As time passes, protocol changes are evaluated differently regarding UX impact and risk, so a more detailed understanding of tradeoffs is helpful.

Background & Motivation

This is an introductory section for readers unfamiliar with this issue. If you are already familiar with it, feel free to skip it.

Why block-execution proving?

A justification for why Ethereum needs more execution throughput can be found in a recent post from Vitalik. Raising the gas limit increases block verification load linearly, requiring more computational and storage resources from attestors, which conflicts with Ethereum's core values like decentralization and trustlessness.

Execution proofs change this relationship from linear to sub-linear, allowing safer gas limit increases without impacting attestors by shifting the workload to block proposers. This is a significant step toward safer execution throughput increases, though it doesn't solve all scaling issues, e.g., state growth.

Block proving hardware and proving efficiency

While block proofs offload work to block builders, minimal hardware requirements for provers have a limit. Block proving has a 1-out-of-N assumption (one honest prover ensures liveness and censorship resistance). As with any 1-out-of-N assumption, at some point, the Ethereum community should decide how many honest and independent provers are required to feel comfortable with this assumption.