Feat: add CANCUN hard fork support

[mrLSD]

Description

➡️ Added EVM CANCUN hard fork support. Based on SputnikVM release v0.42.0-aurora
➡️ Changed engine-tests that related to CACUN changes
➡️ Solidity: updated to 0.8.25 which support CANCUN Features
➡️ Extended Transactions fields for CANCUN hard fork requirements

Cancun hard fork

➡️ EVM impelentation of Cancun hard fork: aurora-is-near/sputnikvm/pull/39

Breaking changes

➡️ Transaction extended according to EIP-4844 requirements

Gas cost

Gas cost changed as expected insignificantly.

• 2 tests: gas increased to 1 TGas
• 1 test: gas decreased to 1 TGas

[birchmd]

I left a few comments on the EIP-4844 transaction implementation, but now I am wondering if we should remove the implementation and simply return an error saying that transaction type is unsupported.

The reason I am asking about this is because the current implementation of EIP-4844 is incomplete and the work needed to complete it seems too large relative to the benefit we get from having it. The following items are missing:

1. Proper implementation of get_blob_hash and blob_gas_price
2. Implementation of the point evaluation precompile (for verifying KZG proofs)
3. Blob transaction validation at runtime
4. Ability to send complete transaction data (including the blobs, commitments, proofs fields which come after the tx_payload_body), and validation of that additional data

All of this looks like a lot of work to me. The reason I do not think this work is necessarily worth it to us is because this type of transaction is designed for building rollups on top of Ethereum and it does not make sense to try to build a rollup on top of Aurora.

What do you think @aleksuss @mrLSD ?

[mrLSD]

I left a few comments on the EIP-4844 transaction implementation, but now I am wondering if we should remove the implementation and simply return an error saying that transaction type is unsupported.
[...]
What do you think @aleksuss @mrLSD ?

@birchmd We didn't plan to support EIP-4844. But the transaction type was added for compatibility reasons.

But you reasonably point out that it's better just to remove supporting that type of transaction.

My reason for not support EIP-4844 on aurora-engine side is:

• it solves very specific Ethereum Network problems like temporary
  blob data storage. It's the unnatural solution for Aurora on top NEAR.

• Ethereum full node should operate on it's own to manage and delete blob data
  approximately after 4 weeks. Again as top on NEAR solution, it looks unreasonable at all.
  It's hard to manage. Also, it's related to large amount of data.

• it's part of the way to Ethereum sharding. And it solves very specific Ethereum network problems.
  Aurora as a solution top on NEAR does not reach that specific kind of problem, as this part is NEAR Protocol
  related solution, but not Aurora as smarcontract on NEAR.

• And as a conclusion, it doesn't meet the concrete current requirement of Aurora to use blob data storage (and blob hashes as proof verifications)

[birchmd]

Great, thanks @mrLSD . Since we agree EIP-4844 is not relevant to Aurora please remove the implementation and just return an error if we get a transaction with that type byte.

[aleksuss]

My point was that we can know about the EIP-4844 transaction but are not obligated to execute it and just respond to a user that we do not support this type of transaction. But, of course, if we can understand the type of transaction by type byte then the implementation could be removed, and we don't need to deserialize it completely.