design

design copied to clipboard

The word ABI is overused in ethereum and I think there are several levels to it. Not all of them are properly documented:

• the way contracts pass data between themselves (was depending on the language, now it seems to be converging), this includes precompiled contracts
• the way external inputs are entered to the contract (both during calls and creation) - it is defined in the Contract ABI
• the way storage is used (specific to the language)

Since eWASM changes the word size from 256 bit to at most 64 bit, it is important to state whether it will follow the same ABI for contract data passing or define a new one, more appropriate to its word size.

Why not fixing word size with 64-bit?

For case 2) it is a question of compatibility - does it want to be compatible with the current Contract ABI (and therefore web3.js and client apps).

For the other cases it is only about actually writing a specification down as we don't have any even for EVM1 on that matter.

See also #2

Can WASM code export multiple methods?

Each of the ABI signatures could be an exported method and this removes the need of writing a dispatcher as we have in current EVM/Solidity.

Example set of ABI methods:

5c19a95c delegate(address)
9e7b8d61 giveRightToVote(address)
b3f98adc vote(uint8)
609ff1bd winningProposal()

would become:

(func $5c19a95c (param ...
(func $9e7b8d61 (param ...

Update: well, I guess it really has to stay within a dispatcher given this is part of the calldata. Well at least proper methods can be defined in WASM.

one problem with that @axic is that funcs in wasm can only return a single parameter