Merge pull request ethereum#1130 from ethereum/v06x

Release V06x into master

Makefile

@@ -34,7 +34,7 @@ install_test:
 	cd $(PY_SPEC_DIR); python3 -m venv venv; . venv/bin/activate; pip3 install -r requirements-testing.txt;
 
 test: $(PY_SPEC_ALL_TARGETS)
-	cd $(PY_SPEC_DIR); . venv/bin/activate; python -m pytest .
+	cd $(PY_SPEC_DIR); . venv/bin/activate; python -m pytest eth2spec
 
 citest: $(PY_SPEC_ALL_TARGETS)
 	cd $(PY_SPEC_DIR); mkdir -p test-reports/eth2spec; . venv/bin/activate; python -m pytest --junitxml=test-reports/eth2spec/test_results.xml .

scripts/phase0/build_spec.py

@@ -13,7 +13,7 @@ def build_phase0_spec(sourcefile, outfile):
     Tuple,
 )
 from eth2spec.utils.minimal_ssz import *
-from eth2spec.utils.bls_stub import *
+from eth2spec.utils.bls import *
 
 """)
     for i in (1, 2, 3, 4, 8, 32, 48, 96):

specs/core/0_beacon-chain.md

@@ -1756,7 +1756,8 @@ def process_deposit(state: BeaconState, deposit: Deposit) -> None:
     amount = deposit.data.amount
     validator_pubkeys = [v.pubkey for v in state.validator_registry]
     if pubkey not in validator_pubkeys:
-        # Verify the deposit signature (proof of possession)
+        # Verify the deposit signature (proof of possession).
+        # Invalid signatures are allowed by the deposit contract, and hence included on-chain, but must not be processed.
         if not bls_verify(pubkey, signing_root(deposit.data), deposit.data.signature, get_domain(state, DOMAIN_DEPOSIT)):
             return
 

specs/test_formats/README.md

@@ -176,6 +176,18 @@ To prevent parsing of hundreds of different YAML files to test a specific test t
 ...                           <--- more test types
 ```
 
+## Common test-case properties
+
+Some test-case formats share some common key-value pair patterns, and these are documented here:
+
+```
+bls_setting: int     -- optional, can have 3 different values:
+                            0: (default, applies if key-value pair is absent). Free to choose either BLS ON or OFF.
+                                 Tests are generated with valid BLS data in this case,
+                                 but there is no change of outcome when running the test if BLS is ON or OFF.
+                            1: known as "BLS required" - if the test validity is strictly dependent on BLS being ON
+                            2: known as "BLS ignored"  - if the test validity is strictly dependent on BLS being OFF
+```
 
 ## Note for implementers
 

specs/test_formats/epoch_processing/README.md

@@ -0,0 +1,29 @@
+# Epoch processing tests
+
+The different epoch sub-transitions are tested individually with test handlers.
+The format is similar to block-processing state-transition tests.
+There is no "change" factor however, the transitions are pure functions with just the pre-state as input.
+Hence, the format is shared between each test-handler. (See test condition documentation on how to run the tests.)
+
+## Test case format
+
+```yaml
+description: string    -- description of test case, purely for debugging purposes
+bls_setting: int       -- see general test-format spec.
+pre: BeaconState       -- state before running the sub-transition
+post: BeaconState      -- state after applying the epoch sub-transition.
+```
+
+## Condition
+
+A handler of the `epoch_processing` test-runner should process these cases, 
+ calling the corresponding processing implementation.
+
+Sub-transitions:
+
+| *`sub-transition-name`* | *`processing call`*               |
+|-------------------------|-----------------------------------|
+| `crosslinks`            | `process_crosslinks(state)`       |
+| `registry_updates`      | `process_registry_updates(state)` |
+
+The resulting state should match the expected `post` state.

specs/test_formats/operations/README.md

@@ -2,9 +2,34 @@
 
 The different kinds of operations ("transactions") are tested individually with test handlers.
 
-The tested operation kinds are:
-- [`deposits`](./deposits.md)
-- More tests are work-in-progress.
+## Test case format
 
+```yaml
+description: string                    -- description of test case, purely for debugging purposes
+bls_setting: int                       -- see general test-format spec.
+pre: BeaconState                       -- state before applying the operation
+<operation-name>: <operation-object>   -- the YAML encoded operation, e.g. a "ProposerSlashing", or "Deposit".
+post: BeaconState                      -- state after applying the operation. No value if operation processing is aborted.
+```
 
+## Condition
 
+A handler of the `operations` test-runner should process these cases, 
+ calling the corresponding processing implementation.
+
+Operations:
+
+| *`operation-name`*      | *`operation-object`* | *`input name`*       | *`processing call`*                                    |
+|-------------------------|----------------------|----------------------|--------------------------------------------------------|
+| `attestation`           | `Attestation`        | `attestation`        | `process_attestation(state, attestation)`                  |
+| `attester_slashing`     | `AttesterSlashing`   | `attester_slashing`  | `process_attester_slashing(state, attester_slashing)`            |
+| `block_header`          | `Block`              | `block`              | `process_block_header(state, block)`                   |
+| `deposit`               | `Deposit`            | `deposit`            | `process_deposit(state, deposit)`                      |
+| `proposer_slashing`     | `ProposerSlashing`   | `proposer_slashing`  | `process_proposer_slashing(state, proposer_slashing)`  |
+| `transfer`              | `Transfer`           | `transfer`           | `process_transfer(state, transfer)`                    |
+| `voluntary_exit`        | `VoluntaryExit`      | `voluntary_exit`     | `process_voluntary_exit(state, voluntary_exit)`        |
+
+Note that `block_header` is not strictly an operation (and is a full `Block`), but processed in the same manner, and hence included here. 
+
+The resulting state should match the expected `post` state, or if the `post` state is left blank,
+ the handler should reject the input operation as invalid.

specs/test_formats/sanity/README.md

@@ -0,0 +1,7 @@
+# Sanity tests
+
+The aim of the sanity tests is to set a base-line on what really needs to pass, i.e. the essentials.
+
+There are two handlers, documented individually:
+- [`slots`](./slots.md): transitions of one or more slots (and epoch transitions within)
+- [`blocks`](./blocks.md): transitions triggered by one or more blocks

specs/test_formats/sanity/blocks.md

@@ -0,0 +1,18 @@
+# Sanity blocks testing
+
+Sanity tests to cover a series of one or more blocks being processed, aiming to cover common changes.
+
+## Test case format
+
+```yaml
+description: string    -- description of test case, purely for debugging purposes
+bls_setting: int       -- see general test-format spec.
+pre: BeaconState       -- state before running through the transitions triggered by the blocks.
+blocks: [BeaconBlock]  -- blocks to process, in given order, following the main transition function (i.e. process slot and epoch transitions in between blocks as normal)
+post: BeaconState      -- state after applying all the transitions triggered by the blocks.
+```
+
+## Condition
+
+The resulting state should match the expected `post` state, or if the `post` state is left blank,
+ the handler should reject the series of blocks as invalid.

specs/test_formats/sanity/slots.md

@@ -0,0 +1,23 @@
+# Sanity slots testing
+
+Sanity tests to cover a series of one or more empty-slot transitions being processed, aiming to cover common changes.
+
+## Test case format
+
+```yaml
+description: string    -- description of test case, purely for debugging purposes
+bls_setting: int       -- see general test-format spec.
+pre: BeaconState       -- state before running through the transitions.
+slots: N               -- amount of slots to process, N being a positive numer.
+post: BeaconState      -- state after applying all the transitions.
+```
+
+The transition with pure time, no blocks, is known as `state_transition_to(state, slot)` in the spec.
+This runs state-caching (pure slot transition) and epoch processing (every E slots).
+
+To process the data, call `state_transition_to(pre, pre.slot + N)`. And see if `pre` mutated into the equivalent of `post`.
+
+
+## Condition
+
+The resulting state should match the expected `post` state.

specs/test_formats/ssz_static/core.md

@@ -9,11 +9,11 @@ This test-format ensures these direct serializations are covered.
 ## Test case format
 
 ```yaml
-type_name: string  -- string, object name, formatted as in spec. E.g. "BeaconBlock"
-value: dynamic     -- the YAML-encoded value, of the type specified by type_name.
-serialized: bytes  -- string, SSZ-serialized data, hex encoded, with prefix 0x
-root: bytes32      -- string, hash-tree-root of the value, hex encoded, with prefix 0x
-signing_root: bytes32 -- string, signing-root of the value, hex encoded, with prefix 0x. Optional, present if type contains ``signature`` field
+SomeObjectName:        -- key, object name, formatted as in spec. E.g. "BeaconBlock".
+    value: dynamic     -- the YAML-encoded value, of the type specified by type_name.
+    serialized: bytes  -- string, SSZ-serialized data, hex encoded, with prefix 0x
+    root: bytes32      -- string, hash-tree-root of the value, hex encoded, with prefix 0x
+    signing_root: bytes32 -- string, signing-root of the value, hex encoded, with prefix 0x. Optional, present if type contains ``signature`` field
 ```
 
 ## Condition

test_generators/README.md

@@ -58,7 +58,7 @@ It's recommended to extend the base-generator.
 
 Create a `requirements.txt` in the root of your generator directory:
 ```
-eth-utils==1.4.1
+eth-utils==1.6.0
 ../../test_libs/gen_helpers
 ../../test_libs/config_helpers
 ../../test_libs/pyspec

test_generators/bls/requirements.txt

@@ -1,3 +1,3 @@
-py-ecc==1.6.0
-eth-utils==1.4.1
+py-ecc==1.7.0
+eth-utils==1.6.0
 ../../test_libs/gen_helpers

test_generators/epoch_processing/README.md

@@ -0,0 +1,11 @@
+# Epoch processing
+
+Epoch processing covers the sub-transitions during an epoch change.
+
+An epoch-processing test-runner can consume these sub-transition test-suites,
+ and handle different kinds of epoch sub-transitions by processing the cases using the specified test handler.
+
+Information on the format of the tests can be found in the [epoch-processing test formats documentation](../../specs/test_formats/epoch_processing/README.md).
+
+
+

test_generators/epoch_processing/main.py

@@ -0,0 +1,38 @@
+from typing import Callable, Iterable
+
+from eth2spec.phase0 import spec
+from eth2spec.test.epoch_processing import (
+    test_process_crosslinks,
+    test_process_registry_updates
+)
+from gen_base import gen_runner, gen_suite, gen_typing
+from gen_from_tests.gen import generate_from_tests
+from preset_loader import loader
+
+
+def create_suite(transition_name: str, config_name: str, get_cases: Callable[[], Iterable[gen_typing.TestCase]]) \
+        -> Callable[[str], gen_typing.TestSuiteOutput]:
+    def suite_definition(configs_path: str) -> gen_typing.TestSuiteOutput:
+        presets = loader.load_presets(configs_path, config_name)
+        spec.apply_constants_preset(presets)
+
+        return ("%s_%s" % (transition_name, config_name), transition_name, gen_suite.render_suite(
+            title="%s epoch processing" % transition_name,
+            summary="Test suite for %s type epoch processing" % transition_name,
+            forks_timeline="testing",
+            forks=["phase0"],
+            config=config_name,
+            runner="epoch_processing",
+            handler=transition_name,
+            test_cases=get_cases()))
+
+    return suite_definition
+
+
+if __name__ == "__main__":
+    gen_runner.run_generator("epoch_processing", [
+        create_suite('crosslinks', 'minimal', lambda: generate_from_tests(test_process_crosslinks)),
+        create_suite('crosslinks', 'mainnet', lambda: generate_from_tests(test_process_crosslinks)),
+        create_suite('registry_updates', 'minimal', lambda: generate_from_tests(test_process_registry_updates)),
+        create_suite('registry_updates', 'mainnet', lambda: generate_from_tests(test_process_registry_updates)),
+    ])

test_generators/epoch_processing/requirements.txt

@@ -0,0 +1,4 @@
+eth-utils==1.6.0
+../../test_libs/gen_helpers
+../../test_libs/config_helpers
+../../test_libs/pyspec

test_generators/operations/README.md

@@ -3,7 +3,6 @@
 Operations (or "transactions" in previous spec iterations),
  are atomic changes to the state, introduced by embedding in blocks.
 
-This generator provides a series of test suites, divided into handler, for each operation type.
 An operation test-runner can consume these operation test-suites,
  and handle different kinds of operations by processing the cases using the specified test handler.