Merge pull request #1564 from ethereum/fork-dir-reorg

reorg specs by fork and move ssz out to own folder

.circleci/config.yml

@@ -35,27 +35,27 @@ commands:
     description: "Restore the cache with pyspec keys"
     steps:
       - restore_cached_venv:
-          venv_name: v5-pyspec
-          reqs_checksum: cache-{{ checksum "test_libs/pyspec/requirements.txt" }}-{{ checksum "test_libs/pyspec/requirements-testing.txt" }}
+          venv_name: v7-pyspec
+          reqs_checksum: cache-{{ checksum "tests/core/pyspec/requirements.txt" }}-{{ checksum "tests/core/pyspec/requirements-testing.txt" }}
   save_pyspec_cached_venv:
     description: Save a venv into a cache with pyspec keys"
     steps:
       - save_cached_venv:
-          venv_name: v5-pyspec
-          reqs_checksum: cache-{{ checksum "test_libs/pyspec/requirements.txt" }}-{{ checksum "test_libs/pyspec/requirements-testing.txt" }}
-          venv_path: ./test_libs/pyspec/venv
+          venv_name: v7-pyspec
+          reqs_checksum: cache-{{ checksum "tests/core/pyspec/requirements.txt" }}-{{ checksum "tests/core/pyspec/requirements-testing.txt" }}
+          venv_path: ./tests/core/pyspec/venv
   restore_deposit_contract_cached_venv:
     description: "Restore the cache with deposit_contract keys"
     steps:
       - restore_cached_venv:
-          venv_name: v8-deposit-contract
-          reqs_checksum: cache-{{ checksum "test_libs/pyspec/requirements.txt" }}-{{ checksum "deposit_contract/requirements-testing.txt" }}
+          venv_name: v9-deposit-contract
+          reqs_checksum: cache-{{ checksum "tests/core/pyspec/requirements.txt" }}-{{ checksum "deposit_contract/requirements-testing.txt" }}
   save_deposit_contract_cached_venv:
     description: Save a venv into a cache with deposit_contract keys"
     steps:
       - save_cached_venv:
-          venv_name: v8-deposit-contract
-          reqs_checksum: cache-{{ checksum "test_libs/pyspec/requirements.txt" }}-{{ checksum "deposit_contract/requirements-testing.txt" }}
+          venv_name: v9-deposit-contract
+          reqs_checksum: cache-{{ checksum "tests/core/pyspec/requirements.txt" }}-{{ checksum "deposit_contract/requirements-testing.txt" }}
           venv_path: ./deposit_contract/venv
 jobs:
   checkout_specs:
@@ -66,16 +66,16 @@ jobs:
       # Restore git repo at point close to target branch/revision, to speed up checkout
       - restore_cache:
           keys:
-            - v1-specs-repo-{{ .Branch }}-{{ .Revision }}
-            - v1-specs-repo-{{ .Branch }}-
-            - v1-specs-repo-
+            - v2-specs-repo-{{ .Branch }}-{{ .Revision }}
+            - v2-specs-repo-{{ .Branch }}-
+            - v2-specs-repo-
       - checkout
       - run:
           name: Clean up git repo to reduce cache size
           command: git gc
       # Save the git checkout as a cache, to make cloning next time faster.
       - save_cache:
-          key: v1-specs-repo-{{ .Branch }}-{{ .Revision }}
+          key: v2-specs-repo-{{ .Branch }}-{{ .Revision }}
           paths:
             - ~/specs-repo
   install_pyspec_test:
@@ -84,7 +84,7 @@ jobs:
     working_directory: ~/specs-repo
     steps:
       - restore_cache:
-          key: v1-specs-repo-{{ .Branch }}-{{ .Revision }}
+          key: v2-specs-repo-{{ .Branch }}-{{ .Revision }}
       - restore_pyspec_cached_venv
       - run:
           name: Install pyspec requirements
@@ -96,13 +96,13 @@ jobs:
     working_directory: ~/specs-repo
     steps:
       - restore_cache:
-          key: v1-specs-repo-{{ .Branch }}-{{ .Revision }}
+          key: v2-specs-repo-{{ .Branch }}-{{ .Revision }}
       - restore_pyspec_cached_venv
       - run:
           name: Run py-tests
           command: make citest
       - store_test_results:
-          path: test_libs/pyspec/test-reports
+          path: tests/core/pyspec/test-reports
   table_of_contents:
     docker:
       - image: circleci/node:10.16.3
@@ -127,7 +127,7 @@ jobs:
     working_directory: ~/specs-repo
     steps:
       - restore_cache:
-          key: v1-specs-repo-{{ .Branch }}-{{ .Revision }}
+          key: v2-specs-repo-{{ .Branch }}-{{ .Revision }}
       - restore_pyspec_cached_venv
       - run:
           name: Run linter
@@ -138,7 +138,7 @@ jobs:
     working_directory: ~/specs-repo
     steps:
       - restore_cache:
-          key: v1-specs-repo-{{ .Branch }}-{{ .Revision }}
+          key: v2-specs-repo-{{ .Branch }}-{{ .Revision }}
       - restore_deposit_contract_cached_venv
       - run:
           name: Install deposit contract requirements
@@ -150,7 +150,7 @@ jobs:
     working_directory: ~/specs-repo
     steps:
       - restore_cache:
-          key: v1-specs-repo-{{ .Branch }}-{{ .Revision }}
+          key: v2-specs-repo-{{ .Branch }}-{{ .Revision }}
       - restore_deposit_contract_cached_venv
       - run:
           name: Run deposit contract test

.gitignore

@@ -14,12 +14,12 @@ eth2.0-spec-tests/
 .mypy_cache
 
 # Dynamically built from Markdown spec
-test_libs/pyspec/eth2spec/phase0/spec.py
-test_libs/pyspec/eth2spec/phase1/spec.py
+tests/core/pyspec/eth2spec/phase0/spec.py
+tests/core/pyspec/eth2spec/phase1/spec.py
 
 # coverage reports
 .htmlcov
 .coverage
 
 # local CI testing output
-test_libs/pyspec/test-reports
+tests/core/pyspec/test-reports

Makefile

@@ -1,9 +1,10 @@
 SPEC_DIR = ./specs
+SSZ_DIR = ./ssz
 SCRIPT_DIR = ./scripts
-TEST_LIBS_DIR = ./test_libs
+TEST_LIBS_DIR = ./tests/core
 PY_SPEC_DIR = $(TEST_LIBS_DIR)/pyspec
 TEST_VECTOR_DIR = ./eth2.0-spec-tests/tests
-GENERATOR_DIR = ./test_generators
+GENERATOR_DIR = ./tests/generators
 DEPOSIT_CONTRACT_DIR = ./deposit_contract
 CONFIGS_DIR = ./configs
 
@@ -16,17 +17,19 @@ GENERATOR_VENVS = $(patsubst $(GENERATOR_DIR)/%, $(GENERATOR_DIR)/%venv, $(GENER
 # To check generator matching:
 #$(info $$GENERATOR_TARGETS is [${GENERATOR_TARGETS}])
 
+PHASE0_SPEC_DIR = $(SPEC_DIR)/phase0
 PY_SPEC_PHASE_0_TARGETS = $(PY_SPEC_DIR)/eth2spec/phase0/spec.py
-PY_SPEC_PHASE_0_DEPS = $(wildcard $(SPEC_DIR)/core/0_*.md)
+PY_SPEC_PHASE_0_DEPS = $(wildcard $(SPEC_DIR)/phase0/*.md)
 
+PHASE1_SPEC_DIR = $(SPEC_DIR)/phase1
 PY_SPEC_PHASE_1_TARGETS = $(PY_SPEC_DIR)/eth2spec/phase1/spec.py
-PY_SPEC_PHASE_1_DEPS = $(wildcard $(SPEC_DIR)/core/1_*.md)
+PY_SPEC_PHASE_1_DEPS = $(wildcard $(SPEC_DIR)/phase1/*.md)
 
 PY_SPEC_ALL_DEPS = $(PY_SPEC_PHASE_0_DEPS) $(PY_SPEC_PHASE_1_DEPS)
 
 PY_SPEC_ALL_TARGETS = $(PY_SPEC_PHASE_0_TARGETS) $(PY_SPEC_PHASE_1_TARGETS)
 
-MARKDOWN_FILES = $(PY_SPEC_ALL_DEPS) $(wildcard $(SPEC_DIR)/*.md) $(wildcard $(SPEC_DIR)/light_client/*.md) $(wildcard $(SPEC_DIR)/networking/*.md) $(wildcard $(SPEC_DIR)/validator/*.md)
+MARKDOWN_FILES = $(PY_SPEC_ALL_DEPS) $(wildcard $(SPEC_DIR)/*.md) $(wildcard $(SSZ_DIR)/*.md) $(wildcard $(SPEC_DIR)/networking/*.md) $(wildcard $(SPEC_DIR)/validator/*.md)
 
 COV_HTML_OUT=.htmlcov
 COV_INDEX_FILE=$(PY_SPEC_DIR)/$(COV_HTML_OUT)/index.html
@@ -101,10 +104,10 @@ test_deposit_contract:
 pyspec: $(PY_SPEC_ALL_TARGETS)
 
 $(PY_SPEC_PHASE_0_TARGETS): $(PY_SPEC_PHASE_0_DEPS)
-	python3 $(SCRIPT_DIR)/build_spec.py -p0 $(SPEC_DIR)/core/0_beacon-chain.md $(SPEC_DIR)/core/0_fork-choice.md $(SPEC_DIR)/validator/0_beacon-chain-validator.md $@
+	python3 $(SCRIPT_DIR)/build_spec.py -p0 $(PHASE0_SPEC_DIR)/beacon-chain.md $(PHASE0_SPEC_DIR)/fork-choice.md $(PHASE0_SPEC_DIR)/validator.md $@
 
 $(PY_SPEC_DIR)/eth2spec/phase1/spec.py: $(PY_SPEC_PHASE_1_DEPS)
-	python3 $(SCRIPT_DIR)/build_spec.py -p1 $(SPEC_DIR)/core/0_beacon-chain.md $(SPEC_DIR)/core/0_fork-choice.md $(SPEC_DIR)/light_client/merkle_proofs.md $(SPEC_DIR)/core/1_custody-game.md $(SPEC_DIR)/core/1_shard-data-chains.md $(SPEC_DIR)/core/1_beacon-chain-misc.md $@
+	python3 $(SCRIPT_DIR)/build_spec.py -p1 $(PHASE0_SPEC_DIR)/beacon-chain.md $(PHASE0_SPEC_DIR)/fork-choice.md $(SSZ_DIR)/merkle-proofs.md $(PHASE1_SPEC_DIR)/custody-game.md $(PHASE1_SPEC_DIR)/shard-data-chains.md $(PHASE1_SPEC_DIR)/beacon-chain-misc.md $@
 
 CURRENT_DIR = ${CURDIR}
 

README.md

@@ -9,18 +9,19 @@ This repository hosts the current Eth2 specifications. Discussions about design
 
 ## Specs
 
-Core specifications for Eth2 client validation can be found in [specs/core](specs/core). These are divided into phases. Each subsequent phase depends upon the prior. The current phases specified are:
+Core specifications for Eth2 clients be found in [specs/](specs/). These are divided into phases. Each subsequent phase depends upon the prior. The current phases specified are:
 
 ### Phase 0
-* [The Beacon Chain](specs/core/0_beacon-chain.md)
-* [Fork Choice](specs/core/0_fork-choice.md)
-* [Deposit Contract](specs/core/0_deposit-contract.md)
-* [Honest Validator](specs/validator/0_beacon-chain-validator.md)
+* [The Beacon Chain](specs/phase0/beacon-chain.md)
+* [Fork Choice](specs/phase0/fork-choice.md)
+* [Deposit Contract](specs/phase0/deposit-contract.md)
+* [Honest Validator](specs/phase0/validator.md)
 
 ### Phase 1
-* [Custody Game](specs/core/1_custody-game.md)
-* [Shard Data Chains](specs/core/1_shard-data-chains.md)
-* [Misc beacon chain updates](specs/core/1_beacon-chain-misc.md)
+* [Custody Game](specs/phase1/custody-game.md)
+* [Shard Data Chains](specs/phase1/shard-data-chains.md)
+* [Misc beacon chain updates](specs/phase1/beacon-chain-misc.md)
+* [Light client syncing protocol](specs/phase1/light-client-sync.md)
 
 ### Phase 2
 
@@ -30,11 +31,9 @@ See the [Eth2 Phase 2 Wiki](https://hackmd.io/UzysWse1Th240HELswKqVA?view) for c
 
 ### Accompanying documents can be found in [specs](specs) and include:
 
-* [SimpleSerialize (SSZ) spec](specs/simple-serialize.md)
-* [BLS signature verification](specs/bls_signature.md)
-* [General test format](specs/test_formats/README.md)
-* [Merkle proof formats](specs/light_client/merkle_proofs.md)
-* [Light client syncing protocol](specs/light_client/sync_protocol.md)
+* [SimpleSerialize (SSZ) spec](ssz/simple-serialize.md)
+* [Merkle proof formats](ssz/merkle-proofs.md)
+* [General test format](tests/formats/README.md)
 
 ## Additional specifications for client implementers
 
@@ -63,6 +62,6 @@ The following are the broad design goals for Ethereum 2.0:
 ## For spec contributors
 
 Documentation on the different components used during spec writing can be found here:
-* [YAML Test Generators](test_generators/README.md)
-* [Executable Python Spec, with Py-tests](test_libs/pyspec/README.md)
+* [YAML Test Generators](tests/generators/README.md)
+* [Executable Python Spec, with Py-tests](tests/core/pyspec/README.md)
 

deposit_contract/requirements-testing.txt

@@ -2,4 +2,4 @@ eth-tester[py-evm]==0.1.0b39
 git+https://github.com/vyperlang/vyper@1761-HOTFIX-v0.1.0-beta.13
 web3==5.0.0b2
 pytest==3.6.1
-../test_libs/pyspec
+../tests/core/pyspec

scripts/build_spec.py

@@ -308,18 +308,18 @@ if __name__ == '__main__':
     description = '''
 Build the specs from the md docs.
 If building phase 0:
-    1st argument is input /core/0_beacon-chain.md
-    2nd argument is input /core/0_fork-choice.md
-    3rd argument is input /core/0_beacon-chain-validator.md
+    1st argument is input phase0/beacon-chain.md
+    2nd argument is input phase0/fork-choice.md
+    3rd argument is input phase0/validator.md
     4th argument is output spec.py
 
 If building phase 1:
-    1st argument is input /core/0_beacon-chain.md
-    2nd argument is input /core/0_fork-choice.md
-    3rd argument is input /light_client/merkle_proofs.md
-    4th argument is input /core/1_custody-game.md
-    5th argument is input /core/1_shard-data-chains.md
-    6th argument is input /core/1_beacon-chain-misc.md
+    1st argument is input phase0/beacon-chain.md
+    2nd argument is input phase0/fork-choice.md
+    3rd argument is input ssz/merkle-proofs.md
+    4th argument is input phase1/custody-game.md
+    5th argument is input phase1/shard-data-chains.md
+    6th argument is input phase1/beacon-chain-misc.md
     7th argument is output spec.py
 '''
     parser = ArgumentParser(description=description)
@@ -338,9 +338,9 @@ If building phase 1:
         else:
             print(
                 " Phase 1 requires input files as well as an output file:\n"
-                "\t core/phase_0: (0_beacon-chain.md, 0_fork-choice.md)\n"
-                "\t light_client: (merkle_proofs.md)\n"
-                "\t core/phase_1: (1_custody-game.md, 1_shard-data-chains.md, 1_beacon-chain-misc.md)\n"
+                "\t phase0: (beacon-chain.md, fork-choice.md)\n"
+                "\t ssz: (merkle-proofs.md)\n"
+                "\t phase1: (custody-game.md, shard-data-chains.md, beacon-chain-misc.md)\n"
                 "\t and output.py"
             )
     else:

specs/phase0/beacon-chain.md

@@ -261,7 +261,7 @@ The following values are (non-configurable) constants used throughout the specif
 
 ## Containers
 
-The following types are [SimpleSerialize (SSZ)](../simple-serialize.md) containers.
+The following types are [SimpleSerialize (SSZ)](../../ssz/simple-serialize.md) containers.
 
 *Note*: The definitions are ordered topologically to facilitate execution of the spec.
 
@@ -579,7 +579,7 @@ def bytes_to_int(data: bytes) -> uint64:
 
 #### `hash_tree_root`
 
-`def hash_tree_root(object: SSZSerializable) -> Root` is a function for hashing objects into a single root by utilizing a hash tree structure, as defined in the [SSZ spec](../simple-serialize.md#merkleization).
+`def hash_tree_root(object: SSZSerializable) -> Root` is a function for hashing objects into a single root by utilizing a hash tree structure, as defined in the [SSZ spec](../../ssz/simple-serialize.md#merkleization).
 
 #### BLS Signatures
 

specs/phase0/deposit-contract.md

@@ -40,7 +40,7 @@ The initial deployment phases of Ethereum 2.0 are implemented without consensus
 
 ### `deposit` function
 
-The deposit contract has a public `deposit` function to make deposits. It takes as arguments `pubkey: bytes[48], withdrawal_credentials: bytes[32], signature: bytes[96], deposit_data_root: bytes32`. The first three arguments populate a [`DepositData`](./0_beacon-chain.md#depositdata) object, and `deposit_data_root` is the expected `DepositData` root as a protection against malformatted calldata.
+The deposit contract has a public `deposit` function to make deposits. It takes as arguments `pubkey: bytes[48], withdrawal_credentials: bytes[32], signature: bytes[96], deposit_data_root: bytes32`. The first three arguments populate a [`DepositData`](./beacon-chain.md#depositdata) object, and `deposit_data_root` is the expected `DepositData` root as a protection against malformatted calldata.
 
 #### Deposit amount
 

specs/phase0/fork-choice.md

@@ -34,7 +34,7 @@
 
 ## Introduction
 
-This document is the beacon chain fork choice spec, part of Ethereum 2.0 Phase 0. It assumes the [beacon chain state transition function spec](./0_beacon-chain.md).
+This document is the beacon chain fork choice spec, part of Ethereum 2.0 Phase 0. It assumes the [beacon chain state transition function spec](./beacon-chain.md).
 
 ## Fork choice
 
@@ -48,7 +48,7 @@ The head block root associated with a `store` is defined as `get_head(store)`. A
 
 1) **Leap seconds**: Slots will last `SECONDS_PER_SLOT + 1` or `SECONDS_PER_SLOT - 1` seconds around leap seconds. This is automatically handled by [UNIX time](https://en.wikipedia.org/wiki/Unix_time).
 2) **Honest clocks**: Honest nodes are assumed to have clocks synchronized within `SECONDS_PER_SLOT` seconds of each other.
-3) **Eth1 data**: The large `ETH1_FOLLOW_DISTANCE` specified in the [honest validator document](../validator/0_beacon-chain-validator.md) should ensure that `state.latest_eth1_data` of the canonical Ethereum 2.0 chain remains consistent with the canonical Ethereum 1.0 chain. If not, emergency manual intervention will be required.
+3) **Eth1 data**: The large `ETH1_FOLLOW_DISTANCE` specified in the [honest validator document](./validator.md) should ensure that `state.latest_eth1_data` of the canonical Ethereum 2.0 chain remains consistent with the canonical Ethereum 1.0 chain. If not, emergency manual intervention will be required.
 4) **Manual forks**: Manual forks may arbitrarily change the fork choice rule but are expected to be enacted at epoch transitions, with the fork details reflected in `state.fork`.
 5) **Implementation**: The implementation found in this specification is constructed for ease of understanding rather than for optimization in computation, space, or any other resource. A number of optimized alternatives can be found [here](https://github.com/protolambda/lmd-ghost).
 

specs/phase0/p2p-interface.md

@@ -398,12 +398,12 @@ Here, `result` represents the 1-byte response code.
 
 The token of the negotiated protocol ID specifies the type of encoding to be used for the req/resp interaction. Two values are possible at this time:
 
--  `ssz`: the contents are [SSZ-encoded](../simple-serialize.md). This encoding type MUST be supported by all clients. For objects containing a single field, only the field is SSZ-encoded not a container with a single field. For example, the `BeaconBlocksByRoot` request is an SSZ-encoded list of `Bytes32`'s.
+-  `ssz`: the contents are [SSZ-encoded](../../ssz/simple-serialize.md). This encoding type MUST be supported by all clients. For objects containing a single field, only the field is SSZ-encoded not a container with a single field. For example, the `BeaconBlocksByRoot` request is an SSZ-encoded list of `Bytes32`'s.
 -  `ssz_snappy`: The contents are SSZ-encoded and then compressed with [Snappy](https://github.com/google/snappy). MAY be supported in the interoperability testnet; MUST be supported in mainnet.
 
 #### SSZ-encoding strategy (with or without Snappy)
 
-The [SimpleSerialize (SSZ) specification](../simple-serialize.md) outlines how objects are SSZ-encoded. If the Snappy variant is selected, we feed the serialized form to the Snappy compressor on encoding. The inverse happens on decoding.
+The [SimpleSerialize (SSZ) specification](../../ssz/simple-serialize.md) outlines how objects are SSZ-encoded. If the Snappy variant is selected, we feed the serialized form to the Snappy compressor on encoding. The inverse happens on decoding.
 
 **Encoding-dependent header:** Req/Resp protocols using the `ssz` or `ssz_snappy` encoding strategies MUST prefix all encoded and compressed (if applicable) payloads with an unsigned [protobuf varint](https://developers.google.com/protocol-buffers/docs/encoding#varints).
 

specs/phase0/validator.md

@@ -1,6 +1,6 @@
 # Ethereum 2.0 Phase 0 -- Honest Validator
 
-**Notice**: This document is a work-in-progress for researchers and implementers. This is an accompanying document to [Ethereum 2.0 Phase 0 -- The Beacon Chain](../core/0_beacon-chain.md), which describes the expected actions of a "validator" participating in the Ethereum 2.0 protocol.
+**Notice**: This document is a work-in-progress for researchers and implementers. This is an accompanying document to [Ethereum 2.0 Phase 0 -- The Beacon Chain](./beacon-chain.md), which describes the expected actions of a "validator" participating in the Ethereum 2.0 protocol.
 
 ## Table of contents
 
@@ -75,7 +75,7 @@ A validator is an entity that participates in the consensus of the Ethereum 2.0
 
 ## Prerequisites
 
-All terminology, constants, functions, and protocol mechanics defined in the [Phase 0 -- The Beacon Chain](../core/0_beacon-chain.md) and [Phase 0 -- Deposit Contract](../core/0_deposit-contract.md) doc are requisite for this document and used throughout. Please see the Phase 0 doc before continuing and use as a reference throughout.
+All terminology, constants, functions, and protocol mechanics defined in the [Phase 0 -- The Beacon Chain](./beacon-chain.md) and [Phase 0 -- Deposit Contract](./deposit-contract.md) doc are requisite for this document and used throughout. Please see the Phase 0 doc before continuing and use as a reference throughout.
 
 ## Constants
 
@@ -110,11 +110,11 @@ The validator constructs their `withdrawal_credentials` via the following:
 
 ### Submit deposit
 
-In Phase 0, all incoming validator deposits originate from the Ethereum 1.0 proof-of-work chain. Deposits are made to the [deposit contract](../core/0_deposit-contract.md) located at `DEPOSIT_CONTRACT_ADDRESS`.
+In Phase 0, all incoming validator deposits originate from the Ethereum 1.0 proof-of-work chain. Deposits are made to the [deposit contract](./deposit-contract.md) located at `DEPOSIT_CONTRACT_ADDRESS`.
 
 To submit a deposit:
 
-- Pack the validator's [initialization parameters](#initialization) into `deposit_data`, a [`DepositData`](../core/0_beacon-chain.md#depositdata) SSZ object.
+- Pack the validator's [initialization parameters](#initialization) into `deposit_data`, a [`DepositData`](./beacon-chain.md#depositdata) SSZ object.
 - Let `amount` be the amount in Gwei to be deposited by the validator where `amount >= MIN_DEPOSIT_AMOUNT`.
 - Set `deposit_data.pubkey` to validator's `pubkey`.
 - Set `deposit_data.withdrawal_credentials` to `withdrawal_credentials`.
@@ -132,13 +132,13 @@ Deposits cannot be processed into the beacon chain until the Eth1 block in which
 
 ### Validator index
 
-Once a validator has been processed and added to the beacon state's `validators`, the validator's `validator_index` is defined by the index into the registry at which the [`ValidatorRecord`](../core/0_beacon-chain.md#validator) contains the `pubkey` specified in the validator's deposit. A validator's `validator_index` is guaranteed to not change from the time of initial deposit until the validator exits and fully withdraws. This `validator_index` is used throughout the specification to dictate validator roles and responsibilities at any point and should be stored locally.
+Once a validator has been processed and added to the beacon state's `validators`, the validator's `validator_index` is defined by the index into the registry at which the [`ValidatorRecord`](./beacon-chain.md#validator) contains the `pubkey` specified in the validator's deposit. A validator's `validator_index` is guaranteed to not change from the time of initial deposit until the validator exits and fully withdraws. This `validator_index` is used throughout the specification to dictate validator roles and responsibilities at any point and should be stored locally.
 
 ### Activation
 
 In normal operation, the validator is quickly activated, at which point the validator is added to the shuffling and begins validation after an additional `MAX_SEED_LOOKAHEAD` epochs (25.6 minutes).
 
-The function [`is_active_validator`](../core/0_beacon-chain.md#is_active_validator) can be used to check if a validator is active during a given epoch. Usage is as follows:
+The function [`is_active_validator`](./beacon-chain.md#is_active_validator) can be used to check if a validator is active during a given epoch. Usage is as follows:
 
 ```python
 def check_if_validator_active(state: BeaconState, validator_index: ValidatorIndex) -> bool:
@@ -209,7 +209,7 @@ A validator has two primary responsibilities to the beacon chain: [proposing blo
 
 ### Block proposal
 
-A validator is expected to propose a [`SignedBeaconBlock`](../core/0_beacon-chain.md#signedbeaconblock) at the beginning of any slot during which `is_proposer(state, validator_index)` returns `True`. To propose, the validator selects the `BeaconBlock`, `parent`, that in their view of the fork choice is the head of the chain during `slot - 1`. The validator creates, signs, and broadcasts a `block` that is a child of `parent` that satisfies a valid [beacon chain state transition](../core/0_beacon-chain.md#beacon-chain-state-transition-function).
+A validator is expected to propose a [`SignedBeaconBlock`](./beacon-chain.md#signedbeaconblock) at the beginning of any slot during which `is_proposer(state, validator_index)` returns `True`. To propose, the validator selects the `BeaconBlock`, `parent`, that in their view of the fork choice is the head of the chain during `slot - 1`. The validator creates, signs, and broadcasts a `block` that is a child of `parent` that satisfies a valid [beacon chain state transition](./beacon-chain.md#beacon-chain-state-transition-function).
 
 There is one proposer per slot, so if there are N active validators any individual validator will on average be assigned to propose once per N slots (e.g. at 312,500 validators = 10 million ETH, that's once per ~6 weeks).
 
@@ -302,25 +302,25 @@ def get_eth1_vote(state: BeaconState, eth1_chain: Sequence[Eth1Block]) -> Eth1Da
 
 ##### Proposer slashings
 
-Up to `MAX_PROPOSER_SLASHINGS`, [`ProposerSlashing`](../core/0_beacon-chain.md#proposerslashing) objects can be included in the `block`. The proposer slashings must satisfy the verification conditions found in [proposer slashings processing](../core/0_beacon-chain.md#proposer-slashings). The validator receives a small "whistleblower" reward for each proposer slashing found and included.
+Up to `MAX_PROPOSER_SLASHINGS`, [`ProposerSlashing`](./beacon-chain.md#proposerslashing) objects can be included in the `block`. The proposer slashings must satisfy the verification conditions found in [proposer slashings processing](./beacon-chain.md#proposer-slashings). The validator receives a small "whistleblower" reward for each proposer slashing found and included.
 
 ##### Attester slashings
 
-Up to `MAX_ATTESTER_SLASHINGS`, [`AttesterSlashing`](../core/0_beacon-chain.md#attesterslashing) objects can be included in the `block`. The attester slashings must satisfy the verification conditions found in [attester slashings processing](../core/0_beacon-chain.md#attester-slashings). The validator receives a small "whistleblower" reward for each attester slashing found and included.
+Up to `MAX_ATTESTER_SLASHINGS`, [`AttesterSlashing`](./beacon-chain.md#attesterslashing) objects can be included in the `block`. The attester slashings must satisfy the verification conditions found in [attester slashings processing](./beacon-chain.md#attester-slashings). The validator receives a small "whistleblower" reward for each attester slashing found and included.
 
 ##### Attestations
 
-Up to `MAX_ATTESTATIONS`, aggregate attestations can be included in the `block`. The attestations added must satisfy the verification conditions found in [attestation processing](../core/0_beacon-chain.md#attestations). To maximize profit, the validator should attempt to gather aggregate attestations that include singular attestations from the largest number of validators whose signatures from the same epoch have not previously been added on chain.
+Up to `MAX_ATTESTATIONS`, aggregate attestations can be included in the `block`. The attestations added must satisfy the verification conditions found in [attestation processing](./beacon-chain.md#attestations). To maximize profit, the validator should attempt to gather aggregate attestations that include singular attestations from the largest number of validators whose signatures from the same epoch have not previously been added on chain.
 
 ##### Deposits
 
-If there are any unprocessed deposits for the existing `state.eth1_data` (i.e. `state.eth1_data.deposit_count > state.eth1_deposit_index`), then pending deposits _must_ be added to the block. The expected number of deposits is exactly `min(MAX_DEPOSITS, eth1_data.deposit_count - state.eth1_deposit_index)`.  These [`deposits`](../core/0_beacon-chain.md#deposit) are constructed from the `Deposit` logs from the [Eth1 deposit contract](../core/0_deposit-contract.md) and must be processed in sequential order. The deposits included in the `block` must satisfy the verification conditions found in [deposits processing](../core/0_beacon-chain.md#deposits).
+If there are any unprocessed deposits for the existing `state.eth1_data` (i.e. `state.eth1_data.deposit_count > state.eth1_deposit_index`), then pending deposits _must_ be added to the block. The expected number of deposits is exactly `min(MAX_DEPOSITS, eth1_data.deposit_count - state.eth1_deposit_index)`.  These [`deposits`](./beacon-chain.md#deposit) are constructed from the `Deposit` logs from the [Eth1 deposit contract](./deposit-contract.md) and must be processed in sequential order. The deposits included in the `block` must satisfy the verification conditions found in [deposits processing](./beacon-chain.md#deposits).
 
 The `proof` for each deposit must be constructed against the deposit root contained in `state.eth1_data` rather than the deposit root at the time the deposit was initially logged from the 1.0 chain. This entails storing a full deposit merkle tree locally and computing updated proofs against the `eth1_data.deposit_root` as needed. See [`minimal_merkle.py`](https://github.com/ethereum/research/blob/master/spec_pythonizer/utils/merkle_minimal.py) for a sample implementation.
 
 ##### Voluntary exits
 
-Up to `MAX_VOLUNTARY_EXITS`, [`VoluntaryExit`](../core/0_beacon-chain.md#voluntaryexit) objects can be included in the `block`. The exits must satisfy the verification conditions found in [exits processing](../core/0_beacon-chain.md#voluntary-exits).
+Up to `MAX_VOLUNTARY_EXITS`, [`VoluntaryExit`](./beacon-chain.md#voluntaryexit) objects can be included in the `block`. The exits must satisfy the verification conditions found in [exits processing](./beacon-chain.md#voluntary-exits).
 
 
 #### Packaging into a `SignedBeaconBlock`
@@ -360,7 +360,7 @@ A validator should create and broadcast the `attestation` to the associated atte
 
 #### Attestation data
 
-First, the validator should construct `attestation_data`, an [`AttestationData`](../core/0_beacon-chain.md#attestationdata) object based upon the state at the assigned slot.
+First, the validator should construct `attestation_data`, an [`AttestationData`](./beacon-chain.md#attestationdata) object based upon the state at the assigned slot.
 
 - Let `head_block` be the result of running the fork choice during the assigned slot.
 - Let `head_state` be the state of `head_block` processed through any empty slots up to the assigned slot using `process_slots(state, slot)`.
@@ -386,7 +386,7 @@ Set `attestation_data.beacon_block_root = hash_tree_root(head_block)`.
 
 #### Construct attestation
 
-Next, the validator creates `attestation`, an [`Attestation`](../core/0_beacon-chain.md#attestation) object.
+Next, the validator creates `attestation`, an [`Attestation`](./beacon-chain.md#attestation) object.
 
 ##### Data
 
@@ -495,7 +495,7 @@ Because Phase 0 does not have shards and thus does not have Shard Committees, th
 
 ### Proposer slashing
 
-To avoid "proposer slashings", a validator must not sign two conflicting [`BeaconBlock`](../core/0_beacon-chain.md#beaconblock) where conflicting is defined as two distinct blocks within the same epoch.
+To avoid "proposer slashings", a validator must not sign two conflicting [`BeaconBlock`](./beacon-chain.md#beaconblock) where conflicting is defined as two distinct blocks within the same epoch.
 
 *In Phase 0, as long as the validator does not sign two different beacon blocks for the same epoch, the validator is safe against proposer slashings.*
 
@@ -508,7 +508,7 @@ If the software crashes at some point within this routine, then when the validat
 
 ### Attester slashing
 
-To avoid "attester slashings", a validator must not sign two conflicting [`AttestationData`](../core/0_beacon-chain.md#attestationdata) objects, i.e. two attestations that satisfy [`is_slashable_attestation_data`](../core/0_beacon-chain.md#is_slashable_attestation_data).
+To avoid "attester slashings", a validator must not sign two conflicting [`AttestationData`](./beacon-chain.md#attestationdata) objects, i.e. two attestations that satisfy [`is_slashable_attestation_data`](./beacon-chain.md#is_slashable_attestation_data).
 
 Specifically, when signing an `Attestation`, a validator should perform the following steps in the following order:
 

specs/phase1/custody-game.md

@@ -59,7 +59,7 @@
 
 ## Introduction
 
-This document details the beacon chain additions and changes in Phase 1 of Ethereum 2.0 to support the shard data custody game, building upon the [Phase 0](0_beacon-chain.md) specification.
+This document details the beacon chain additions and changes in Phase 1 of Ethereum 2.0 to support the shard data custody game, building upon the [Phase 0](../phase0/beacon-chain.md) specification.
 
 ## Terminology
 

ssz/simple-serialize.md

@@ -239,7 +239,7 @@ We now define Merkleization `hash_tree_root(value)` of an object `value` recursi
 
 Let `A` be an object derived from another object `B` by replacing some of the (possibly nested) values of `B` by their `hash_tree_root`. We say `A` is a "summary" of `B`, and that `B` is an "expansion" of `A`. Notice `hash_tree_root(A) == hash_tree_root(B)`.
 
-We similarly define "summary types" and "expansion types". For example, [`BeaconBlock`](./core/0_beacon-chain.md#beaconblock) is an expansion type of [`BeaconBlockHeader`](./core/0_beacon-chain.md#beaconblockheader). Notice that objects expand to at most one object of a given expansion type. For example, `BeaconBlockHeader` objects uniquely expand to `BeaconBlock` objects.
+We similarly define "summary types" and "expansion types". For example, [`BeaconBlock`](../specs/phase0/beacon-chain.md#beaconblock) is an expansion type of [`BeaconBlockHeader`](../specs/phase0/beacon-chain.md#beaconblockheader). Notice that objects expand to at most one object of a given expansion type. For example, `BeaconBlockHeader` objects uniquely expand to `BeaconBlock` objects.
 
 ## Implementations
 

test_generators/epoch_processing/requirements.txt

@@ -1,3 +0,0 @@
-../../test_libs/gen_helpers
-../../test_libs/config_helpers
-../../test_libs/pyspec

test_generators/genesis/requirements.txt

@@ -1,3 +0,0 @@
-../../test_libs/gen_helpers
-../../test_libs/config_helpers
-../../test_libs/pyspec

test_generators/operations/requirements.txt

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

test_generators/sanity/requirements.txt

@@ -1,3 +0,0 @@
-../../test_libs/gen_helpers
-../../test_libs/config_helpers
-../../test_libs/pyspec

test_generators/shuffling/requirements.txt

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

test_generators/ssz_generic/requirements.txt

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

test_generators/ssz_static/requirements.txt

@@ -1,3 +0,0 @@
-../../test_libs/gen_helpers
-../../test_libs/config_helpers
-../../test_libs/pyspec

tests/core/config_helpers/README.md

@@ -1,7 +1,7 @@
 # Eth2 config helpers
 
-`preset_loader`: A util to load constants-presets with.
-See [Constants-presets documentation](../../configs/constants_presets/README.md).
+`preset_loader`: A util to load config-presets with.
+See [Configs documentation](../../../configs/README.md).
 
 Usage:
 

tests/core/gen_helpers/README.md

@@ -4,7 +4,7 @@
 
 A util to quickly write new test suite generators with.
 
-See [Generators documentation](../../test_generators/README.md) for integration details.
+See [Generators documentation](../../generators/README.md) for integration details.
 
 Options:
 

tests/core/pyspec/README.md

@@ -63,4 +63,4 @@ The pyspec is not a replacement.
 
 ## License
 
-Same as the spec itself; see [LICENSE](../../LICENSE) file in the specs repository root.
+Same as the spec itself; see [LICENSE](../../../LICENSE) file in the specs repository root.

tests/core/pyspec/eth2spec/test/conftest.py

@@ -34,6 +34,6 @@ def pytest_addoption(parser):
 def config(request):
     config_name = request.config.getoption("--config")
     from preset_loader import loader
-    presets = loader.load_presets('../../configs/', config_name)
+    presets = loader.load_presets('../../../configs/', config_name)
     spec_phase0.apply_constants_preset(presets)
     spec_phase1.apply_constants_preset(presets)