The views below represent the Reth team's current view, and not necessarily the broader Paradigm team.
We think it is necessary for Ethereum to ship Fusaka in Q3 2025 and focus its scope on scaling L2s. We also ask every EL team to promptly publish their official view on what should go in Fusaka.
Dos:
- PeerDAS & increase blobs to at least 12 (if not higher), to enable L2s to scale 2x from Pectra. This must be the top priority for this upgrade, alongside any EL changes needed to support that (e.g. on the transaction pool).
- EOF, to make the EVM faster, easier to use and future proof. It is a desired EVM upgrade that is already implemented, tested, and integrated in clients and tooling. There are also multi-client EOF devnets running stable.
- EIP7883 aka ModExp repricing is important to avoid DoS on the L1 (we also think high throughput L2s should implement this).
- RIP7212 to make Ethereum easier to use by making verification of secure enclave signatures cheaper. It is already widely deployed on L2s and other L1s.
Dont’s:
- Large “system-wide” changes which are disconnected from the current L1 competitive landscape like ePBS, FOCIL, or statelessness. We still think these matter for the long term success of Ethereum, but not for Fusaka.
- EVMMAX/SIMD doesn’t make sense to us ROI-wise, as we believe that we get most of the UX benefits of new curves already post-RIP7212.
- Ossifying the EVM doesn’t make sense to us, we believe the EVM should continue evolving. We like the idea of exploring native account abstraction with EOF but we don’t love the EIP7701/7560 designs as we dislike their proximity to ERC4337 as a suboptimal account abstraction standard.
- RISC-V as an alternative VM. We like RISC-V and are experimenting with it as an alternative VM via the R55 project. We don’t think the time is right yet.
We think Ethereum Core Development should aspire to 1-2x hardforks/yr in the current competitive landscape. For that, we should decouple shipping, scoping & research:
- Core Dev teams should be able to ship Pectra AND simultaneously decide on the Fusaka scope.
- Ethereum research teams should be able to surface ideas to be added in Amsterdam (the hard fork after Fusaka) scope and not rush inclusion of ideas in Fusaka.
We are open to a CL-only hardfork if that means we’d ship Fusaka in Q3 2025, but we would consider that a failure of the EL teams and have an open-minded conversation about what should the shipping bar be for a client team.
Post-Fusaka, we think the research and engineering focus should continue being scale. Here are some ideas which we think are interesting that research could help with:
- Further help scale L2s by upping the blob count via blob-parameter-only hard-forks.
- Scale the L1 by bumping the gas limit post EIP-4444, gas repricing & block-level warming.