The progress made by @SuccinctLabs and @RiscZero toward real-time proving has been super impressive. QT-ing not to be critical but because I think these questions are really interesting (and I would like to see RTP hit Ethereum!). 1. Proving all historical Ethereum blocks within 12s is not sufficient to cover worst-case prover time. This is important because there are possible pathological ("prover-killer") blocks where proving cost >> gas cost (proving cost is a measure of latency or $). The first step is proving all historical blocks within 12s. But this isn't enough. We need to work to identify pathological cases that haven't shown up on Ethereum yet. Not sure what the cost schedule is for SP1, but something like an entire block full of extcodehash could be expensive in latency terms. 2. Formal Verification also needs to cover the compiler 😱 @argumentxyz had a good article about the frequency at which compiler bugs are found ( tl;dr there's a specific class of "mis-optimization bugs" that could potentially be exploitable in zkVMs to create soundness issues. These bugs are found fairly frequently. @drakefjustin has argued that we can get around this with many zkVM implementations. But that doesn't work if those zkVMs share the same compiler toolchain and are vulnerable to the same bugs. 3. At-home proving is not needed I think that I agree that at-home proving isn't necessary. We already rely on extra-protocol actors like builders to construct blocks. The guarantee that we want is that *someone* is always available to generate proofs. Deferring RTP for the WW3 scenario where all provers go offline seems like overkill. Maybe in this scenario, Ethereum could default back to a mode where the gas limit decreases and blocks are re-executed rather verified with ZKPs. 4. 100x-ing the gas limit could create issues Parallelized proving definitely helps, but timing is so tight that we need to consider witness generation (not parallelizable in many zkVMs) and recursion. Recursion overhead should scale logarithmically, but if the gas limit increases by 100x, proving times could exceed block times. Bonus - I'd argue that it's really important for Ethereum to reduce block times and time to finality, in order to help users onboard to L2s, bridge from CEXs, etc. This increases the latency demands on proving. It would be suboptimal if we're unable to move to 1s block times because the lower bound on worst-case RTP latency is 10s.