Support for BLOBHASH from EIP-4844

[ekpyron]

Part of #14739
Two steps, first PR:

• Implement the blobhash opcode as specified in https://eips.ethereum.org/EIPS/eip-4844
• Give it a test value in evmone/evmc to test.

Second PR:

• Introduce the high-level global function
  blobhash(uint index) returns (bytes32)
  analog to the existing blockhash function
• Document it in https://docs.soliditylang.org/en/develop/units-and-global-variables.html#block-and-transaction-properties
• This will need to allow being overridden by user-defined functions with a shadowing warning (otherwise it'd be breaking).

Remark:
Testing this may mean to add bogus values in EVMHost. I.e. check if we can inject values at all - otherwise the hashes may just end up as zero in testing.

Also needs to take care of this not being breaking: #11763

[r0qs]

Just as a side note, the eip mentions a point evaluation precompile, which I'm not sure we need to implement considering that we lack of support for BLS pairings. Should we also implement this, @ekpyron? For reference, the verify_kzg_proof function is defined here if needed.

[cameel]

I don't think we have to do anything about precompiles. They don't need special language support like the opcodes, since they can be invoked with a generic call(). We do have global built-in functions for some of the precompiles added in the past, but not even all of them. We're heading in the direction of having less hard-coded stuff so I doubt we'll be adding high-level wrappers for precompiles in the future. At best we might provide them as a part of stdlib.

You might just need to add some hard-coded results from the precompile for testing (IIRC we have them for other precompiles in EVMHost? Or in some similar file), but that's only if you need to use that precompile in some test.

[ekpyron]

Yeah, we're aiming for minimal Cancun support only for the next release, for which being able to low-level call the precompile is perfectly fine. It's not like it's a major issue to add high-level support per se, but we won't do it for now and only after strong demand (it's indeed better done via stdlib later on)

[qizhou]

FYI: we have implemented a blob hash getter contract via Assembly code and test it against devnet-12: https://github.com/ethstorage/eip4844-blob-hash-getter

[qizhou]

• Introduce the high-level global function
  blobhash(uint blockNumber) returns (bytes32)
  analog to the existing blockhash function
• Document it in https://docs.soliditylang.org/en/develop/units-and-global-variables.html#block-and-transaction-properties
• This will need to allow being overridden by user-defined functions with a shadowing warning (otherwise it'd be breaking).

Remark: Testing this may mean to add bogus values in EVMHost. I.e. check if we can inject values at all - otherwise the hashes may just end up as zero in testing.

Also needs to take care of this not being breaking: #11763

My two cents: could we introduce blobhash assembly code rather than a global function? Therefore, we don't need to deal with the overridden case if a user-defined function happens to be the same.

[cameel]

A Yul builtin is being added by #14757 so it's not either-or. We'll have both.