Cancun Support about solidity HOT 4 OPEN

* [ ]  [EIP-4788: Beacon block root in the EVM](https://eips.ethereum.org/EIPS/eip-4788)
  TODO: verify if there's anything for us to do here.

Regarding this item, I did some research, and it appears that the current proposal does not require any changes in the compiler. Instead, it involves modifications to the execution and consensus clients. Although, while reading the EIP I thought that the parent_beacon_block_root would be exposed at the language level, but this does not seem to be the case according to the current specification.

Originally, the EIP was drafted requiring a new opcode (BEACON_STATE_ROOT at 0x4A, now used by BLOBBASEFEE), but it was later modified to incorporate a "stateful" precompile. More recently, another change was made, the "stateful" precompile idea was dropped, and now the EIP proposes the use of what is now referred to as a "system contract". As per the current specification, the parent_beacon_block_root would be passed as calldata to the system contract (which would have the bytecode directly deployed at the given system address), and the execution clients would write to or read from the EVM state through a system transaction. I may have misunderstood something, so it would be helpful if someone else could confirm this as well.

from solidity.

I can confirm @r0qs analysis, there's nothing for us to do there. It's implemented as a system contract and does not add any new opcodes. The fact that EIP-4788 is never mentioned in evmc 10.1...11 diff (including the changelog) confirms that.

BTW, thanks for digging into the history of this EIP. Reading it now, I see no mention that it went from opcode, to precompile, to system contract, so that's useful to know.

from solidity.

Actually, maybe absence of this in evmc does not really confirm it (e.g. MCOPY does not require any changes there either).

On the evmone side the change was done in ethereum/evmone#709. Still, looks like this does not require any special compiler support. The VM automatically executes the system call that updates the circular buffer with block roots before every block. It does not deploy the system contract on its own, but, as far as I understand the EIP, it's not really the responsibility of the VM. Presence of the contract is optional.

It might at most affect our testing if we wanted to include contracts that call this system contract. For that I guess we'd have to deploy it when we set up the test environment? That does not seem like something we need right now though.

from solidity.

For EIP-6780: SELFDESTRUCT only in same transaction we may need some changes in tests. At least the self-destructed contracts should no longer be cleared:

This might not be the only change.

from solidity.