Update 2025-08-27
Design
At this moment we’re still mainly working on the design. Part of the reasons is that we get other commitments, and part of the reasons is that we think it’s important to get it right before making a choice on the architecture.
In the past month, we have been researching several other already-established EVM/Ethereum-compatible chains (there are a lot of them, and one even already had RISC-V deployed). There is one important trend we are noticing – many of the chains started to reconsider the customization they made on top of EVM, and instead moving more and more back to “vanilla EVM”. This happens, even with teams with sufficient manpower.
We think there are several important reasons for this:
- The Ethereum network is now being developed at increased pace. AllCoreDevs of course still suffer from the old problems, but gradually a process is developed, which means now each upgrade contains more and more changes. This makes it increasingly difficult for “non-vanilla EVM” to keep up, regardless of manpower (no one has more manpower than the Ethereum community). Even if we can now keep up, the “prospect” of whether this is always possible in the future is questionable. The Ethereum project is gradually becoming like the browser project (of their maintenance burdens).
- Many of the customizations turned out to be unnecessary. There’s no reason to develop customized, complicated precompiles. Most of the features can be easily implemented in vanilla EVM, even with better security (because all the quirks of Solidity is already well understood, but not custom Rust code). Unless for those specific computationally intensive algorithms (for which the Ethereum community is also implementing new precompiles each year), performance is usually not the main concern. There’s also now the general purpose execution layer requests, which can be adopted, instead of precompiles, for async “system” calls. Many times they’re better suited for the situation because it’s specifically designed for it. Of course, those things are only available in the past years or so.
We’re therefore adopting our designs with those new insights. In particular, an “unmodified” Ethereum execution layer is likely our aim. This is a completely different path than Revive / Polkadot Hub – which is more similar to a complete customized re-implementation (than what is advertised of using REVM), because it re-implements all opcodes, gas metering, and even use its own custom call frame. We therefore will try to make our solutions generic so that it will be useful for other ecosystems.