EVM-C: Classification of external data for EVM

[chfast]

This document tries to organize external data needed to perform any execution in EVM. The hypothesis is:

• Message data should be always provided to the EVM (as function argument),
• Transaction and block data should be provided to the EVM on demand. Good EVMs should request it at most once per transaction.
• Information about accounts should be requested every time needed. Smart EVMs might try to avoid redundant queries, but this is hard and probably will duplicate efforts in high level languages.

Message

Immutable data:

• GAS
• ADDRESS
• CALLER (aka sender)
• VALUE
• CALLDATA (aka input data)
• CALL DEPTH

Functions:

• log(data, topics)

The message contains immutable data valid for the current call. ~112 bytes in total, but might be bigger if extended by code and code hash.
The log() function attaches logs to the current message. All logs attached should be discarded if the message execution fails.

Transaction & Block

Immutable data:

• ORIGIN
• GAS PRICE
• COINBASE
• GAS LIMIT
• NUMBER
• TIMESTAMP
• DIFFICULTY

Functions:

• blockhash(number)

Information about the current transaction and block is mostly immutable data that are valid for the whole transactions (all calls in it). ~136 bytes in total.
The blockhash() function provides hashes of 256 recent blocks (8192 bytes of information in total).

State (accounts)

Query functions:

• balance(address)
• get_storage(address, key)
• exists(address)
• code(address)
• code_size(address)

Update functions:

• set_storage(address, key, value)
• selfdestruct(address, beneficiary)
• create(creator, code)

This provides information about accounts in the state, so address is always a required argument.

[chfast]

Python implementation might be closest to this, C++ on the other hand has additional abstraction layer that flattens account access (no address argument required). Go is somewhere in the middle, probably closer to Python anyway.

[gcolvin]

So in C++ you have an Address class with balance() and kin as member functions?

[chfast]

In C++ we have ExtVM (overdesigned) interface: https://github.com/ethereum/cpp-ethereum/blob/develop/libethereum/ExtVM.h#L54.

[chriseth]

What is the overhead of just providing all the immutable data at the point of the call in a flat byte array?

[chfast]

In case of transaction & block data it is the cost of the accesing and coping the data -- ~136 bytes (no matter if the application has the data in already in the single array or not). I'm gessing it is the same order of cost as the call itself. Because it is immutable per transaction the EVM will not need to ask for it in the same call/transaction again.

I can do some microbenchmarks if needed.

[chriseth]

Ok, looks good to me!

[axic]

I think this is closed now?