search

ewasm / design

Ewasm Design Overview and Specification
Apache License 2.0
1.02k stars 125 forks source link

spec: proposal for terminology #101

Open ehildenb opened 6 years ago

ehildenb commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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

poemm commented 6 years ago

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 commented 6 years ago

I like what @poemm says here because Acronyms Seriously Suck