search

polkadot-evm / frontier

Ethereum compatibility layer for Substrate.
Apache License 2.0
574 stars 489 forks source link

revm support / evm abstraction #1495

Open MOZGIII opened 3 months ago

MOZGIII commented 3 months ago

Question

Frontier depends on evm crate heavily:

$ cargo tree -p evm --invert --depth 1
evm v0.41.1
├── fc-rpc v2.0.0-dev (.../frontier/client/rpc)
├── fp-evm v3.0.0-dev (.../frontier/primitives/evm)
│   [dev-dependencies]
├── pallet-ethereum v4.0.0-dev (.../frontier/frame/ethereum)
├── pallet-evm v6.0.0-dev (.../frontier/frame/evm)
├── pallet-evm-test-vector-support v1.0.0-dev (.../frontier/frame/evm/test-vector-support)
│   [dev-dependencies]
├── precompile-utils v0.1.0 (.../frontier/precompiles)
│   [dev-dependencies]
└── precompile-utils-tests-external v0.1.0 (.../frontier/precompiles/tests-external)

The only dependency that makes sense is at pallet-evm, the rest look like leaked abstraction. pallet-evm supports abstracting around the runner, but it doesn't really work the way the code is structured currently.

Why don't we make Frontier abstract around the evm implementation? That would be nice for supporting alternative EVM implementations.