Cancun Support

[ekpyron]

Prerequisites:

• Bump evmc version to 11.0.0 and evmone to the upcoming 11.0.0 release (promised for Dec 21st 2023)
  Tracked in Bump evmone/evmc to version 11.0.0 for Cancun support #14744 @nikola-matic

We need full support for the EIPs of Cancun:

• EIP-1153: Transient storage opcodes
  PR: Introduce transient storage support for inline assembly #14737 @matheusaaguiar
• EIP-4788: Beacon block root in the EVM
  TODO: verify if there's anything for us to do here. @r0qs
• EIP-4844: Shard Blob Transactions
  Tracked in Support for BLOBHASH from EIP-4844 #14740 @r0qs
• EIP-5656: MCOPY - Memory copying instruction @cameel
  Tracked in Support for MCOPY #14741
• EIP-6780: SELFDESTRUCT only in same transaction @r0qs
  This will mean documentation adjustment, so falls together with Clean up documentation with regards to deprecated selfdestruct #13889.
  We should also add the change in behaviour to the deprecation warning.
• EIP-7516: BLOBBASEFEE opcode
  Tracked in Support for BLOBBASEFEE from EIP 7516 #14742 @nikola-matic

Additionally we will need to:

• Adjust our documentation with sufficent details about Cancun. (Introduce Cancun EVM version #14705 (review) and check if anything else needs to be done)
• Publish a blog post about transient storage

[r0qs]

* [ ]  [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.

[cameel]

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.

[cameel]

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.

[cameel]

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:

solidity/test/EVMHost.cpp

Lines 186 to 187 in fbbac9c

	for (auto& [address, _]: recorded_selfdestructs)
	accounts.erase(address);

This might not be the only change.

[k06a]

Any plans to have transient modifier for variables?

[cameel]

It's planned but not a priority at the moment. Other things, especially the new type system and improving the IR pipeline before we enable it by default, take precedence.

[cameel]

#13889 was the last thing to do here and it's done so I'm closing the issue.