Clarify the difference between code and recipient

[yperbasis]

An evmc_message contains only two addresses (sender and "destination").
However, in case of DELEGATECALL we need 3 addresses (sender, recipient, and code), so we recover the missing 3rd address from the address_stack_.

See Section 8 "Message Call" of the Yellow Paper.
destination in evmc_message can mean either code or recipient, depending on the context.

[chfast]

This issue was brought up some other time (cannot find it now): the single DELEGATECALL case requires the evmc::Host to track the recipient address because this information cannot be recovered from the evmc::message. Otherwise the Host implementation can be "stateless".

I think it is time to solve it on EVMC level by adding one more evmc::address field.
If you have good spec insights, can you suggest names for these?

[chfast]

This seems to be fixing a consensus bug. Are there any tests failing?

[yperbasis]

This seems to be fixing a consensus bug. Are there any tests failing?

Not really because this code is executed only when message.kind == EVMC_CALL

[yperbasis]

This issue was brought up some other time (cannot find it now): the single DELEGATECALL case requires the evmc::Host to track the recipient address because this information cannot be recovered from the evmc::message. Otherwise the Host implementation can be "stateless".

I think it is time to solve it on EVMC level by adding one more evmc::address field.
If you have good spec insights, can you suggest names for these?

I'd suggest to split "destination" into "recipient" and "code", in line with Section 8 "Message Call" of the Yellow Paper.

[chfast]

This is similar code for it in Aleth: https://github.com/ethereum/aleth/blob/master/libevm/ExtVMFace.cpp#L206-L208

I'm usually confused by this, but it seems that for the CALLCODE the answer is also message.destination.

[chfast]

I'd suggest to split "destination" into "recipient" and "code", in line with Section 8 "Message Call" of the Yellow Paper.

Sounds good except I cannot name it "code" :). Then code_address, recipient_address, sender_address? Or code_address, recipient, sender? Or code_account?

[codecov]

Codecov Report

Merging #286 (5cd5ac9) into master (6995360) will increase coverage by 0.03%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #286      +/-   ##
==========================================
+ Coverage   81.14%   81.18%   +0.03%     
==========================================
  Files          82       82              
  Lines        7334     7349      +15     
==========================================
+ Hits         5951     5966      +15     
  Misses       1383     1383              

Impacted Files	Coverage Δ
core/silkworm/execution/evm.hpp	100.00% <ø> (ø)
core/silkworm/execution/evm.cpp	97.29% <100.00%> (+0.08%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6995360...5cd5ac9. Read the comment docs.

[yperbasis]

I'd suggest to split "destination" into "recipient" and "code", in line with Section 8 "Message Call" of the Yellow Paper.

Sounds good except I cannot name it "code" :). Then code_address, recipient_address, sender_address? Or code_address, recipient, sender? Or code_account?

My preference would be code_address, recipient, sender

[yperbasis]

@chfast I think a better idea would be not to change evmc::message, but to add code_address as an argument to evmc_host_interface::call. I'll quickly try if it works.

[yperbasis]

@chfast Oh well, extending evmc_host_interface::call seems to be too much work on the evmc side.

I've created ethereum/evmc#611, ethereum/evmone#360, and #288 that add code_address to evmc_message.