clarify what the malformed WASM test is testing

[gballet]

In order to find the proper interpreter, the go-ethereum client tells wagon to load the WASM contract; if it succeeds then the file is assumed to be an eWASM file, otherwise it is assumed to be an EVM contract. The "malformed ewasm" test assumes that wagon should accept a malformed ewasm as long as the header signature is present.

The way I see it, EVMC/hera should not load the file either and consider it to be an EVM file. Please clarify what the criteria are to select an interpreter based on a binary blob (just having the \0asm signature? Ability to fully load the file?) @axic

[axic]

In EVMC (Aleth), this is driven by the VM as opposed to the client.

Whatever VM is selected by the user is invoked for every single input. An EVMC execution may come back with EVMC_REJECTED, which means the VM rejected execution of that contract.

A concrete example in Aleth:

• for every input Hera is invoked
• for wasm input it just does whatever it does
• for evm input it returns EVMC_REJECTED and aleth invokes the EVM interpreter (however, if Hera is not run with evm1mode=fallback, then instead of EVMC_REJECTED it will return a failure code and Aleth will not try to execute it via the EVM interpret)

The test suite is currently implicitly assumed to be ran without evm1mode=fallback, that is all input is consumed by the wasm VM.

[chfast]

Simple change we could do in EVMC is to along the name and version to return a set of features (similarly to OpenCL, CPU features, etc). Here it could be {evm, ewasm, interpreter, jit}.
This however will not fully work for Hera which is able to execute EVM conditionally only when proper options are specified.

[axic]

@gballet can we close this issue/

[gballet]

It's been clarified and geth+wagon now models the behavior of geth+evmc/hera