Initcode transaction (TXCREATE) support

[gumb0]

Requires #681

[gumb0]

Not sure it makes sense to support it, example.c only sends EVMC_CALL message anyway.

[pdobacz]

feel free to drop the comment like this, if you feel like nothing needs to be done. I was very generous when adding them in

[codecov]

Codecov Report

Attention: Patch coverage is 5.88235% with 16 lines in your changes are missing coverage. Please review.

Project coverage is 93.11%. Comparing base (f89284f) to head (7241cc5).

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #702      +/-   ##
==========================================
- Coverage   93.49%   93.11%   -0.39%     
==========================================
  Files          25       25              
  Lines        3861     3878      +17     
  Branches      396      397       +1     
==========================================
+ Hits         3610     3611       +1     
- Misses        139      155      +16     
  Partials      112      112              

[pdobacz]

feel free to drop the comment like this, if you feel like nothing needs to be done. I was very generous when adding them in

[chfast]

I don't want to spoil the party, but I think the simpler API would be to extend the evmc_tx_context with

hashed_initcode* initcodes;
size_t initcodes_count;

where

struct hashed_initcode {
    evmc_bytes32 hash;
    const uint8_t* code;
    size_t code_size;
};

[pdobacz]

I don't want to spoil the party, but I think the simpler API would be to extend the evmc_tx_context with

Indeed simpler but makes problematic:

1. Optimizing initcode lookup (unless we require the initcodes are sorted I suppose)
2. Any usecases where the initcode is fetched not from the TX, for which the fetch-by-hash was introduced in the first place

Neither is maybe big deal but sth to keep in mind.

[gumb0]

Indeed simpler but makes problematic:

1. Optimizing initcode lookup (unless we require the initcodes are sorted I suppose)

I don't think this variant changes much, it only changes where lookup by hash is happening.

• With current API, Host gets initcodes array from transaction and hashes them and puts them into unordered_map to later serve get_tx_initcode_by_hash() requests.
• With this new API, Host will get initcode array from transaction, hash them once and serve as array in tx_context, then EVM will get them and put into unordered_map on EVM side (in evmone it will be in ExecutionState).

2. Any usecases where the initcode is fetched not from the TX, for which the fetch-by-hash was introduced in the first place

For something other than transaction, it will be some other different API? But I think fetch-by-hash is mainly for easier aggregating several transactions (or AA-transactions) into one batch transaction (merging their initcodes without changing TXCREATE instances). I don't think this usecase is in any way affected.

[gumb0]

Anyway I plan to try this in a different PR.

[pdobacz]

Makes sense!

[chfast]

The other approach can be implemented as a "flat map": vector of already sorted (hash, initcode) pairs. EVM only need to read it and can lookup values by binary search.

But I'm not insisting on sorting values right now. Linear search should be fine as the start.

[gumb0]

The other approach can be implemented as a "flat map": vector of already sorted (hash, initcode) pairs. EVM only need to read it and can lookup values by binary search.

ethereum/evmone@55a7102
EVM puts them into unordered_map.

[gumb0]

Replaced by #709