status-im
/
eth2.0-specs
mirror of https://github.com/status-im/eth2.0-specs.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

forks are based on epoch numbers, as per spec

This commit is contained in:
protolambda 2019-04-07 12:07:10 +10:00
parent 09ceccacb4
commit 1c81638e86
No known key found for this signature in database
GPG Key ID: EC89FDBB2B4C7623
1 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
specs/test_formats/README.md
View File

@ -36,7 +36,7 @@ The particular formats of specific types of tests (test suites) are defined in s
- `case`: a test case, an entry in the `test_cases` list of a `suite`. A case can be anything in general, - `case`: a test case, an entry in the `test_cases` list of a `suite`. A case can be anything in general,
but its format should be well-defined in the documentation corresponding to the `type` (and `handler`).\ but its format should be well-defined in the documentation corresponding to the `type` (and `handler`).\
A test has the same exact configuration and fork context as the other entries in the `case` list of its `suite`. A test has the same exact configuration and fork context as the other entries in the `case` list of its `suite`.
- `forks_timeline`: a fork timeline definition, a YAML file containing a key for each fork-name, and a slot number as value. - `forks_timeline`: a fork timeline definition, a YAML file containing a key for each fork-name, and an epoch number as value.
## Test format philosophy ## Test format philosophy
@ -44,8 +44,8 @@ The particular formats of specific types of tests (test suites) are defined in s
After long discussion, the following types of configured constants were identified: After long discussion, the following types of configured constants were identified:
- Never changing: genesis data - Never changing: genesis data
- Changing, but reliant on old value: e.g. a slot time may change, but if you want to do the conversion - Changing, but reliant on old value: e.g. an epoch time may change, but if you want to do the conversion
`(genesis data, timestamp) -> slot number` you end up needing both constants. `(genesis data, timestamp) -> epoch number` you end up needing both constants.
- Changing, but kept around during fork transition: finalization may take a while, - Changing, but kept around during fork transition: finalization may take a while,
e.g. an executable has to deal with new deposits and old deposits at the same time. Another example may be economic constants. e.g. an executable has to deal with new deposits and old deposits at the same time. Another example may be economic constants.
- Additional, back-wards compatible: new constants are introduced for later phases - Additional, back-wards compatible: new constants are introduced for later phases
@ -119,9 +119,9 @@ They should compile for each configuration once, and run the corresponding tests
## Fork-timeline ## Fork-timeline
A fork timeline is (preferably) loaded in as a configuration object into a client, as opposed to the constants configuration: A fork timeline is (preferably) loaded in as a configuration object into a client, as opposed to the constants configuration:
- we do not allocate or optimize any code based on slot numbers - we do not allocate or optimize any code based on epoch numbers
- when we transition from one fork to the other, it is preferred to stay online. - when we transition from one fork to the other, it is preferred to stay online.
- we may decide on a slot number for a fork based on external events (e.g. Eth1 log event), - we may decide on an epoch number for a fork based on external events (e.g. Eth1 log event),
a client should be able to activate a fork dynamically. a client should be able to activate a fork dynamically.
## Config sourcing ## Config sourcing