Make `EOFCREATE` address ASE compatible

[chfast]

If we are going to change the scheme by which the create address is computed in EOFCREATE, make sure the scheme is compatible with Address Space Expansion (ASE).

This can be done by considering addresses being 32-byte long?

[pdobacz]

Are we doing this while updating the hashing scheme anyway (ethereum/EIPs#9298) @gumb0 @chfast ?

[chfast]

This is more question to @shemnon . I think we should do it unless ASE support can be very easily added later if needed.

[pdobacz]

I also think we should just do it (and recheck no hash collision opportunities arise - which is the only concern I have). We've done ASE-compatibility for EXT*CALL, should do with EOFCREATE as well.

[chfast]

I quite scared seeing me figuring out cryptography, but here it is:

• as noted, null address is valid address in Ethereum, so maybe it is not the best placeholder for "no caller address",
• we want ASE compatibility,

The proposal then:

• make placeholder 32-byte long, I guess this is also how ABI for address works,
• if caller address is included, it should be left-padded with zeros,
• if caller address is not included, the value should be 0xff..ff (32 bytes).

[pdobacz]

* as noted, null address is valid address in Ethereum, so maybe it is not the best placeholder for "no caller address",

Hold on, aren't we confusing two issues here? In the context of EOFCREATE ASE compatibility I thought we were talking about the sender_address from the scheme:

keccak256(0xff | sender_address | salt)

And the ASE-compatible way to approach this seems to be to have sender_address be 32-byte wide and left-pad with zeros until ASE happens.

The proposal then:

* make placeholder 32-byte long, I guess this is also how ABI for `address` works,

* if caller address is included, it should be left-padded with zeros,

* if caller address is not included, the value should be `0xff..ff` (32 bytes).

This seems to be speaking to the Creator Contract scheme to hash final_salt e.g. this PR about CALLER specifically. I think it is a different topic. That also should be made ASE-compatible (if it isn't already), but it's independent from EOFCREATE / TXCREATE hashing scheme.

[chfast]

Oops 😳

[chfast]

Anyway, let's extend the sender address to 32-bytes for ASE, i.e. let's change it from keccak256(0xff || sender || salt)[12:] to keccak256(0xff000000000000000000000000 || sender || salt)[12:] (you can find better way to spec it).

In the new scheme the keccack input has 65 bytes and it still fits into a single keccak256 block (136). So no big performance change for hashing...

[pdobacz]

OK, I'll go through the relevant PR's / EIPs and update

[pdobacz]

For reference, ASE compatibility for EOFCREATE / TXCREATE done for specs in:

• ca2e8c6
• Update EIP-7620: Simplify EOFCREATE new address hashing scheme ethereum/EIPs#9298 (review)
• Update EIP-7873: TXCREATE hashing scheme to EOFCREATE with ASE ethereum/EIPs#9490

To round this off we should also apply the change to (@gumb0):

• Change EOFCREATE new address hashing scheme evmone#1140
• EIP-7873: EOF - TXCREATE and InitcodeTransaction type evmone#1139

and EEST (PRs TBD). Of course if the proposed change is accepted (I think it has been proposed before so nothing new).

Then I think we can close this issue and track it as part of the broader hashing scheme update planned for eof-devnet-1

[pdobacz]

Closing here to track this change elsewhere 👆