Closed ehildenb closed 6 months ago
the BlockchainTests/GeneralStateTests are identical to GeneralStateTests. GeneralStateTests don't account for the mining reward and beacon precompile autocreation in state.
for you purposes it is better to use BlockchainTests/GeneralStateTests as it contains all the information you need such as full post state. and also we are thinking to discontinue GeneralStateTests format.
Thank you! Feel free to close this, unless you think it's good for informational purposes. Or maybe that can be stated in the README targeting people using the test-suite.
this repo is about to be archived anyway
What's the migration plan? Where will the tests go?
I'm looking at updating KEVM to use the newer test formats instead of
LegacyTests
, and am having trouble understanding which ones I should tackle.I see
GeneralStateTests
, andBlockchainTests/GeneralStateTests
. The former seems nice and clean, well-separated, etc..., but doesn't have actual post states, just post-state hashes. The latter is a bit larger and seems less clean, but has post-state hashes. Which should I adapt KEVM to use?Post-state hashes are difficult for clients to deal with when they are making new semantics. For example, there is a team making a Lean4 semantics of EVM, which should they start with? Will they be required to implement the state hashing just to get testing up and running? Is there a way to take something in
GeneralStateTests/
and turn it into one with explicit post-states for the account storage slots.Any help would be appreciated @winsvega .