I think the simplicity argument makes a lot of sense.
But, taking a step back, I think it raises the question of what is Ethereum’s priority purpose right now?
L1 execution, simplicity, decentralization, or L2 enablement?
This would be great for L1 execution, but that lowers the value add of L2s, competing against ourselves, and doesn’t add much value to that roadmap in exchange for a huge technical lift.
It seems like there are a lot of other ambitious pie in the sky efforts that could either improve drastically the execution for L2s or have more moderate boosts for both L1 & L2
-
Blob‑only data model + mandatory danksharding
-
Recursive‑proof aggregation precompile (“VERIFY_RECURSIVE” / “AGGREGATE_SNARKS” – folds N rollup proofs into one SNARK so the slot verifies a single proof)
-
Unified prime‑field crypto stack & BLS signatures (Adopt a single curve—e.g., BLS12‑381—for user sigs, KZG commitments, and SNARK verifiers. + Poseidon/Rescue hash precompile in the same field.)
-
Stateless KZG / IPA commitment root (Replace the Merkle Patricia/Verkle tree with a polynomial commitment of the full state vector)
-
Enshrined global message bus (native inbox/outbox for all L2s)
-
Sequencer‑level PBS (proposer‑builder separation at the rollup block level)
-
BLS aggregate‑signature mempool (Mempool nodes accept only bundles where thousands of user or rollup signatures are pre‑aggregated into one BLS sig)
Where as RISC-V move seems to 50x - 100x L1 execution, but very little benefit for the L2 model.
TL;DR:
-agree it seems like a good idea for the L1 that solves points 2 and 3 of the L1 bottlenecks.
-but is this the set of priorities we want to solve for, especially given the scale of technical cost here?
That I don’t have the answer for, but thought it was worth raising the question!