What to do with EOF implementation?

[chfast]

Options:

1. Move to some future EVM revision (e.g. EVMC_EOF).
2. Remove.

[pdobacz]

Depends.

1. if we want evmone to be more tooling/experimentation/benchmark oriented and if it's not terribly hard to maintain.
2. if we want to evolve evmone into a more prod-oriented implementation

Ideally we could have an EVMC_EXPERIMENTAL fork always after the last mainnet fork and control what that is via a feature flag system, EOF being only one of the choices there. But then I suppose there's a problem with opcode tables (and potentially performance, if feature flag checks are in runtime end up on a hot path)?

[pdobacz]

It might actually be useful to have the EOF implementation around to make comparison benchmarks against non-EOF workarounds for requested EVM features (like SWAPN/DUPN etc). Not a must-have probably, because an EOF instruction can be hacked good enough for the sake of a comparable benchmark without the entire EOF support, but still a nice-to-have.

Anybody else has thoughts on this?

[chfast]

I already introduced a bug in EOF and it was only caught by EEST/EOF tests. After moving to Osaka we will loose compatibility with these tests. I'm rather for removing these. If you want some comparison, you can likely check out some older version of evmone.