-
Notifications
You must be signed in to change notification settings - Fork 109
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace current fork >=
tests everywhere with calculated EIP behaviour flags
#640
Comments
Many places outside the EVM use `Fork` and the fork list, and in general we want progressively fewer dependencies on EVM internal types and files. This may prove to be a temporary location, especially when we implement issue #640. But it's a fine temporary location if so. Signed-off-by: Jamie Lokier <[email protected]>
After the POS merge, and after we have more subsystem implemented, it become obvious we need to raise this issue priority. New EF test cases sametimes require network configuration in the format "Fork+EIPS". Currently there is no way to enable or disable eips in nimbus-eth1. We need to manage EIPS in a more sophisticated way. Other factors contribute to the importance of this issue are:
There is a need to track POS transition by blockNumber and Total Difficulty in a centralized place rather than scattered around in many places. note: remember to modify chain config fork block into all optional instead of using blocknumber.high. and also change the fork order validation algorithm |
one of hive test, ethereum/consensus depends on this refactoring. currently, all post merge test case are failing. HIVE_TERMINAL_TOTAL_DIFFICULTY indicate the simulator is running engine api test. what's wrong in nimbus-eth1: currently it is confused between merge fork and ttd. if only ttd exists and no merge fork, then it is a pre merge waiting for merge transition.
|
fixed by #1344, closing |
Following on from a conversation at #635 (comment)
Behaviour flags would say which EIP (and other) behaviours are active for the current block. They would replace all occurrences of
fork >=
in the codebase, except for the part which calculates the flags of course.They are calculated from chain id, block number and therefore fork id. Then it's probably best to store them as flags, probably on the current block or transaction being processed, and quick to access.
Ideally they would be consistently named and greppable, so it's easy to find all the places where a particular behaviour is conditional, and also find all the places where any behaviour depends on the current chain/block/fork.
Probably we would make these flags configurable for custom chains, testing and so on, just like we currently make the block to fork thresholds configurable.
The text was updated successfully, but these errors were encountered: