spec: proposal for terminology

[ehildenb]

@axic, @chfast, and @poemm, I've tried to specify the terminology we've discussed. Need feedback on the EVMC bullet point, and on the overall naming of things.

[poemm]

More generally, it seems that we want Clients and VMs to both be swappable by each exposing only an API. I can envision three common cases, which follow.

1. Client <--API--> VM
   The VM provides all behavior required by the system, and can communicate over the two-way API exposed by both the client and VM. This is the case with EVM.

2. Client <--API--> VM extension <--API--> VM
   The VM can't provide all behavior required by the system, or it can't call/expose the API. Then it needs an extension glued on which can do this. This the case with Wasm, since Wasm exposes a embedding API and can call host functions in the extension.

3. Client <--API--> VM+extension
   This is a mixture of the two above cases. The VM alone does not include all desired behavior/interfaces, but it has mechanisms to be internally extended to a state in which it does. This is the case for a Wasm VM containing an EEI module instance, and which exposes the Wasm embedding API to the client.

@ehildenb Are you trying to model one of these cases?

[ehildenb]

Note, I think we have agreed prior to call the actual underlying computational thing the "execution engine", and the combination of that + the client the "VM".

So, I would say it's closer to:

Client + EEI method implementations <--EEI--> execution engine

[chfast]

I wander maybe "function" would be more familiar name.

[ehildenb]

I wanted to avoid the word "function" because they aren't functions in the mathematical sense. I think "method" or "procedure" is closer, in the sense of methods from OOP languages like Java which can alter the state of the surrounding context.

[chfast]

It's API (C language) containing both API for VM and EEI.

Maybe I should physically separate both for clarity?

[poemm]

Also, the full name for acronym EVMC is here: https://github.com/ethereum/evmc

[ehildenb]

Ok, so would:

EVMC: The Ethereum Client-VM Connector API is the C implementation of the EEI.

be an accurate description?

[ehildenb]

Also, good idea @poemm, I'll make all these definitions links when appropriate.

[poemm]

A comment which may confuse the conversation. Feel free to ignore.

When someone reads "Ethereum Environment Interface", it needs explanation. "Ethereum Client-VM Connector API" is more self-explanatory, but the word "Connector" is unnecessary and adds the confusing "C" into the acronym.

Generalizing the convention from EVMC, maybe we can consider using Client API for the Execution Engine, Execution Engine API for the Client, and Execution Engine Extension for the Client. Then we can substitute specific cases like Ethereum API for Wasm, EVM API for Ethereum, and Wasm Extension for Ethereum. Then we can say: EVMC implements the union of Ethereum API for EVM and Ethereum API for Wasm, and EEI specifies Wasm Extension for Ethereum.

This convention can include versions, e.g. Ethereum2.0 API for Wasm1.1.

I know these names need work, but they are more self-explanatory and future-proof.

[lrettig]

I like what @poemm says here because Acronyms Seriously Suck