Relaxing the prover hardware requirements for the next few years

[tim-clancy.eth]

@dankrad

For good reasons, we started discussing the limits: Formalizing decentralization goals in the context of larger L1 gaslimits and 2020s-era tech (https://ethereum-magicians.org/t/formalizing-decentralization-goals-in-the-context-of-larger-l1-gaslimits-and-2020s-era-tech/23942)

I am glad that we are already thinking of what limits are reasonable and formally defining them; being rigorous about requirements for solo stakers (https://hackmd.io/DsDcxDAVShSSLLwHWdfynQ?view) (local and non-local block building) is long overdue.

@dankrad

I think while these are good goals for the Ethereum network to have, we should “suspend” the strict decentralization limits for proving for the next few years.

Which of @vbuterin’s suggested requirements are you proposing suspending?

1. We still need to demonstrate real-time proving of the worst-case block anyways. If it’s much worse than the average case this seems like a good motivation to do some repricing.
2. We also need to formally verify anyways.
3. This seems to be the only limit to consider.
4. Whatever the gas limit ends up being will also heavily impact the limit.

I’ll add a requirement of my own. It goes without saying that the prover must be fully Free Software (https://www.gnu.org/philosophy/free-sw.en.html#fs-definition) as well; i.e. the SP1 CUDA prover is currently distributed as an unlicensed binary. It would not be tolerable for Ethereum to rely at its core upon something closed source.

So it all boils down to the kW. This specific mostly-realtime demo was 160x4090s for that under ~100kW figure. Even though we only need a single honest, parallelizable prover I don’t want to go nuts with this. I don’t have enough faith that if we start at 1MW we won’t decide to 10x throughput instead of making proving 10x cheaper the next time proving undergoes a 10x in performance.