Add DATAHASH opcode #4894
Add DATAHASH opcode #4894
Conversation
…b.com/nethermindeth/nethermind into feature/shanghai-eip-4895-withdrawals # Conflicts: # src/Nethermind/Nethermind.Blockchain.Test/Proofs/WithdrawalTrieTests.cs # src/Nethermind/Nethermind.Consensus/Processing/BlockProcessor.cs # src/Nethermind/Nethermind.Consensus/Withdrawals/IWithdrawalApplier.cs # src/Nethermind/Nethermind.Consensus/Withdrawals/ProductionWithdrawalApplier.cs # src/Nethermind/Nethermind.Consensus/Withdrawals/ValidationWithdrawalApplier.cs # src/Nethermind/Nethermind.Core/BlockHeader.cs # src/Nethermind/Nethermind.Core/Specs/IReleaseSpec.cs # src/Nethermind/Nethermind.Merge.Plugin.Test/EngineModuleTests.V2.cs # src/Nethermind/Nethermind.Serialization.Rlp/WithdrawalDecoder.cs # src/Nethermind/Nethermind.Specs/Forks/15_Shanghai.cs # src/Nethermind/Nethermind.State/Proofs/WithdrawalTrie.cs
…ion_fix' into feature/shanghai-eip-4895-withdrawals # Conflicts: # src/Nethermind/Nethermind.Specs/ChainSpecStyle/ChainParameters.cs # src/Nethermind/Nethermind.Specs/ChainSpecStyle/ChainSpecBasedSpecProvider.cs # src/Nethermind/Nethermind.Specs/ChainSpecStyle/ChainSpecLoader.cs # src/Nethermind/Nethermind.Specs/ChainSpecStyle/Json/ChainSpecParamsJson.cs
…b.com/nethermindeth/nethermind into feature/shanghai-eip-4895-withdrawals
| @@ -110,9 +110,9 @@ protected TestAllTracerWithOutput Execute(params byte[] code) | |||
| return tracer; | |||
| } | |||
|
|
|||
| protected TestAllTracerWithOutput Execute(long blockNumber, long gasLimit, byte[] code, long blockGasLimit = DefaultBlockGasLimit, ulong timestamp = 0) | |||
| protected TestAllTracerWithOutput Execute(long blockNumber, long gasLimit, byte[] code, long blockGasLimit = DefaultBlockGasLimit, ulong timestamp = 0, byte[][] blobVersionedHashes = null) | |||
There was a problem hiding this comment.
Only tests, but I would consider creating some container (class) for those parameters, to easier evolve them in the future.
There was a problem hiding this comment.
Do you mean just blobVersionedHashes? Or all the stuff like blobVersionedHashes, blobs, kzgs, proof?
blobVersionedHashes byte[][] type looks OK for me, may be UIn256t[] could look better, but would bring redundant type conversions
blobVersionedHashes is always a block part, but blobs, kzgs and proof may be considered as a separate thing, that exists until passed to CL. Still I'd give a try to flat transaction structure, we can easily change in the future without problems with serialization anyway
There was a problem hiding this comment.
All parameters, when your method starts to take more than 4-5 it is time to make them into a class/struct of their own. It is nothing crucial and can stay as is, just providing a tip.
…-usage-of-chain-and-network-ids
…github.com:NethermindEth/nethermind into bugfix/4848-Correct-usage-of-chain-and-network-ids
…in-and-network-ids' into feature/add-blob-spec-fork-and-fields
…in-and-network-ids' into feature/add-blob-spec-fork-and-fields
…thermindEth/nethermind into feature/add-blob-spec-fork-and-fields
…ec-fork-and-fields
flcl42
force-pushed
the
feature/add-datahash-opcode
branch
from
2e1fe41
to
4c84274
Compare
Depends on #4867
Add a new opcode according to https://github.com/ethereum/EIPs/blob/master/EIPS/eip-4844.md#opcode-to-get-versioned-hashes
Changes:
Types of changes
What types of changes does your code introduce?
Put an
xin the boxes that applyTesting
Requires testing
In case you checked yes, did you write tests??
Comments about testing , should you have some (optional)
Further comments (optional)
If this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution you did and what alternatives you considered, etc...