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.