New API for EVM

[chfast]

Starting point: EVMC

EVMC was created long time ago to support some use-cases which are less relevant nowadays. In was used in cpp-ethereum client to support multiple EVM implementations. Therefore EVMC is as low level as possible to leave only instructions execution to EVM implementations. Any other EVM property was abstracted if possible, in particular:

• only supports execution of individual internal calls (not whole transactions),
• gas refunding was counted outside of EVM until recently because refunds are related to state access only,
• housekeeping of many state access aspects is in responsibility of a client: e.g. hot/cold access information, state changes,
• state API is tight-tailored to what EVM needs, e.g. account nonce is invisible to EVM.

Moreover, EVMC is "polymorphic" API allowing easily using multiple EVM implementations with the single unified API.

Design goals

1. Limit number of required EVM-Host interactions during execution.
2. Make the API smaller.

Design

Execute transaction

Instead of executing individual internal calls focus on executing whole transactions. This should hide many internals of EVM from Client:

• No direct visibility of contracts interactions: CALL and CREATE instructions.
• Hides call depth parameter and leaves call stack implementation to EVM.
• Potentially leaves state changes reverts implementation to EVM.

Only access cold state

Transaction execution has notion of cold/warm state access. EVM should only ask Client about cold items and keep the already accessed values in a transaction-level state cache. This may play nicely with the gas schedule where cold access is more expensive: EVM implementation will call Client (possibly an expensive FFI call) only in case of cold access.

Receipt + State changes

In EVMC state changes are kept by the Client. Client is also responsible of state changes reverts. If we move the state journal / reverts to EVM it can easily keep the record of all changes made to the state by the current transaction. The transaction receipt (gas cost + logs) and state diff (unified state journal) may be the result of the transaction execution API.

Reusable ExecutionContext

The ExecutionContext is an object allowing thread-safe EVM execution. It is owned but opaque to Client. Can be reused for serial transactions execution or multiple ExecutionContext can be created to support parallel execution.

It allows cross-call optimizations, e.g. #481.

Rollout in stages

1. Start with non-polymorphic C++ API for evmone. This can be used and tested in Silkworm and evmone's tools.
2. Create some foreign languages bindings in evmone to test it in some other projects.
3. Consider standardized C API, possibly supporting integration of multiple EVM implementations. Check also approaches by OpenGL, Vulkan, etc.

[Moameri55]

Very good thanks 👍

[Moameri55]

b3d1ea3