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

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