misc. phase1 modules refactor updates

.gitignore

@@ -16,7 +16,6 @@ eth2.0-spec-tests/
 
 # Dynamically built from Markdown spec
 tests/core/pyspec/eth2spec/phase0/
-tests/core/pyspec/eth2spec/phase1/
 tests/core/pyspec/eth2spec/altair/
 
 # coverage reports

Makefile

@@ -54,7 +54,6 @@ partial_clean:
 	rm -rf $(PY_SPEC_DIR)/.pytest_cache
 	rm -rf $(DEPOSIT_CONTRACT_TESTER_DIR)/.pytest_cache
 	rm -rf $(PY_SPEC_DIR)/phase0
-	rm -rf $(PY_SPEC_DIR)/phase1
 	rm -rf $(PY_SPEC_DIR)/altair
 	rm -rf $(PY_SPEC_DIR)/$(COV_HTML_OUT)
 	rm -rf $(PY_SPEC_DIR)/.coverage

configs/README.md

@@ -3,7 +3,7 @@
 This directory contains a set of constants presets used for testing, testnets, and mainnet.
 
 A preset file contains all the constants known for its target.
-Later-fork constants can be ignored, e.g. ignore Phase 1 constants as a client that only supports Phase 0 currently.
+Later-fork constants can be ignored, e.g. ignore Sharding constants as a client that only supports Phase 0 currently.
 
 
 ## Forking

specs/phase0/beacon-chain.md

@@ -139,7 +139,7 @@
 This document represents the specification for Phase 0 of Ethereum 2.0 -- The Beacon Chain.
 
 At the core of Ethereum 2.0 is a system chain called the "beacon chain". The beacon chain stores and manages the registry of validators. In the initial deployment phases of Ethereum 2.0, the only mechanism to become a validator is to make a one-way ETH transaction to a deposit contract on Ethereum 1.0. Activation as a validator happens when Ethereum 1.0 deposit receipts are processed by the beacon chain, the activation balance is reached, and a queuing process is completed. Exit is either voluntary or done forcibly as a penalty for misbehavior.
-The primary source of load on the beacon chain is "attestations". Attestations are simultaneously availability votes for a shard block (Phase 1) and proof-of-stake votes for a beacon block (Phase 0).
+The primary source of load on the beacon chain is "attestations". Attestations are simultaneously availability votes for a shard block (in a later Eth2 upgrade) and proof-of-stake votes for a beacon block (Phase 0).
 
 ## Notation
 

specs/phase0/p2p-interface.md

@@ -433,7 +433,7 @@ The following validations MUST pass before forwarding the `attestation` on the s
 Attestation broadcasting is grouped into subnets defined by a topic.
 The number of subnets is defined via `ATTESTATION_SUBNET_COUNT`.
 The correct subnet for an attestation can be calculated with `compute_subnet_for_attestation`.
-`beacon_attestation_{subnet_id}` topics, are rotated through throughout the epoch in a similar fashion to rotating through shards in committees in Phase 1.
+`beacon_attestation_{subnet_id}` topics, are rotated through throughout the epoch in a similar fashion to rotating through shards in committees (future Eth2 upgrade).
 The subnets are rotated through with `committees_per_slot = get_committee_count_per_slot(state, attestation.data.target.epoch)` subnets per slot.
 
 Unaggregated attestations are sent as `Attestation`s to the subnet topic,

specs/phase0/validator.md

@@ -513,7 +513,7 @@ The `subnet_id` for the `attestation` is calculated with:
 def compute_subnet_for_attestation(committees_per_slot: uint64, slot: Slot, committee_index: CommitteeIndex) -> uint64:
     """
     Compute the correct subnet for an attestation for Phase 0.
-    Note, this mimics expected Phase 1 behavior where attestations will be mapped to their shard subnet.
+    Note, this mimics expected future behavior where attestations will be mapped to their shard subnet.
     """
     slots_since_epoch_start = uint64(slot % SLOTS_PER_EPOCH)
     committees_since_epoch_start = committees_per_slot * slots_since_epoch_start