rename eth1 and eth2 throughout specs and readme where reasonable

specs/altair/beacon-chain.md

@@ -1,4 +1,4 @@
-# Ethereum 2.0 Altair Beacon chain changes
+# Altair -- The Beacon Chain
 
 ## Table of contents
 

specs/altair/bls.md

@@ -1,4 +1,4 @@
-# Ethereum 2.0 Altair BLS extensions
+# Altair -- BLS extensions
 
 ## Table of contents
 

specs/altair/fork.md

@@ -1,4 +1,4 @@
-# Ethereum 2.0 Altair fork
+# Altair -- Fork Logic
 
 **Notice**: This document is a work-in-progress for researchers and implementers.
 
@@ -17,7 +17,7 @@
 
 ## Introduction
 
-This document describes the process of the first upgrade of Ethereum 2.0: the Altair hard fork, introducing light client support and other improvements.
+This document describes the process of the first upgrade of the eacon chain: the Altair hard fork, introducing light client support and other improvements.
 
 ## Configuration
 

specs/altair/p2p-interface.md

@@ -1,6 +1,6 @@
-# Ethereum Altair networking specification
+# Altair -- Networking
 
-This document contains the networking specification for Ethereum 2.0 clients added during the Altair deployment.
+This document contains the networking specification for Altair.
 This document should be viewed as additive to the [document from Phase 0](../phase0/p2p-interface.md) and will be referred to as the "Phase 0 document" hereafter.
 Readers should understand the Phase 0 document and use it as a basis to understand the changes outlined in this document.
 

specs/altair/sync-protocol.md

@@ -1,4 +1,4 @@
-# Minimal Light Client
+# Altair -- Minimal Light Client
 
 **Notice**: This document is a work-in-progress for researchers and implementers.
 
@@ -28,8 +28,8 @@
 
 ## Introduction
 
-Eth2 is designed to be light client friendly for constrained environments to
-access Eth2 with reasonable safety and liveness.
+The beacon chain is designed to be light client friendly for constrained environments to
+access Ethereum with reasonable safety and liveness.
 Such environments include resource-constrained devices (e.g. phones for trust-minimised wallets)
 and metered VMs (e.g. blockchain VMs for cross-chain bridges).
 
@@ -184,7 +184,7 @@ def process_light_client_update(store: LightClientStore, update: LightClientUpda
     ):
         # Apply update if (1) 2/3 quorum is reached and (2) we have a finality proof.
         # Note that (2) means that the current light client design needs finality.
-        # It may be changed to re-organizable light client design. See the on-going issue eth2.0-specs#2182.
+        # It may be changed to re-organizable light client design. See the on-going issue consensus-specs#2182.
         apply_light_client_update(store.snapshot, update)
         store.valid_updates = set()
     elif current_slot > store.snapshot.header.slot + update_timeout:

specs/altair/validator.md

@@ -1,6 +1,6 @@
-# Ethereum 2.0 Altair -- Honest Validator
+# Altair -- Honest Validator
 
-This is an accompanying document to [Ethereum 2.0 Altair -- The Beacon Chain](./beacon-chain.md), which describes the expected actions of a "validator" participating in the Ethereum 2.0 protocol.
+This is an accompanying document to [Altair -- The Beacon Chain](./beacon-chain.md), which describes the expected actions of a "validator" participating in the Ethereum 2.0 protocol.
 
 ## Table of contents
 

specs/custody_game/beacon-chain.md

@@ -1,4 +1,4 @@
-# Ethereum 2.0 Custody Game -- Beacon Chain
+# Custody Game -- The Beacon Chain
 
 **Notice**: This document is a work-in-progress for researchers and implementers.
 
@@ -57,7 +57,7 @@
 
 ## Introduction
 
-This document details the beacon chain additions and changes of Ethereum 2.0 to support the shard data custody game,
+This document details the beacon chain additions and changes of to support the shard data custody game,
 building upon the [Sharding](../sharding/beacon-chain.md) specification.
 
 ## Constants

specs/custody_game/validator.md

@@ -1,8 +1,8 @@
-# Ethereum 2.0 Custody Game -- Honest Validator
+# Custody Game -- Honest Validator
 
 **Notice**: This document is a work-in-progress for researchers and implementers.
-This is an accompanying document to the [Ethereum 2.0 Custody Game](./), which describes the expected actions of a "validator"
-participating in the Ethereum 2.0 Custody Game.
+This is an accompanying document to the [Custody Game](./), which describes the expected actions of a "validator"
+participating in the shard data Custody Game.
 
 ## Table of contents
 

specs/das/das-core.md

@@ -1,4 +1,4 @@
-# Ethereum 2.0 Data Availability Sampling -- Core
+# Data Availability Sampling -- Core
 
 **Notice**: This document is a work-in-progress for researchers and implementers.
 

specs/das/fork-choice.md

@@ -1,4 +1,4 @@
-# Ethereum 2.0 Data Availability Sampling -- Fork Choice
+# Data Availability Sampling -- Fork Choice
 
 **Notice**: This document is a work-in-progress for researchers and implementers.
 
@@ -17,7 +17,7 @@
 
 ## Introduction
 
-This document is the beacon chain fork choice spec for Ethereum 2.0 Data Availability Sampling. The only change that we add from phase 0 is that we add a concept of "data dependencies";
+This document is the beacon chain fork choice spec for Data Availability Sampling. The only change that we add from phase 0 is that we add a concept of "data dependencies";
 a block is only eligible for consideration in the fork choice after a data availability test has been successfully completed for all dependencies.
 The "root" of a shard block for data dependency purposes is considered to be a `DataCommitment` object, which is a pair of a Kate commitment and a length.
 

specs/das/p2p-interface.md

@@ -1,4 +1,4 @@
-# Ethereum 2.0 Data Availability Sampling -- Network specification
+# Data Availability Sampling -- Networking
 
 **Notice**: This document is a work-in-progress for researchers and implementers.
 

specs/das/sampling.md

@@ -1,4 +1,4 @@
-# Ethereum 2.0 Data Availability Sampling
+# Data Availability Sampling -- Sampling
 
 **Notice**: This document is a work-in-progress for researchers and implementers.
 

specs/merge/beacon-chain.md

@@ -1,4 +1,4 @@
-# Ethereum 2.0 The Merge
+# The Merge -- The Beacon Chain
 
 **Notice**: This document is a work-in-progress for researchers and implementers.
 

specs/merge/fork-choice.md

@@ -1,4 +1,4 @@
-# Ethereum 2.0 The Merge
+# The Merge -- Fork Choice
 
 **Notice**: This document is a work-in-progress for researchers and implementers.
 

specs/merge/fork.md

@@ -1,4 +1,4 @@
-# Ethereum 2.0 The Merge
+# The Merge -- Fork Logic
 
 **Notice**: This document is a work-in-progress for researchers and implementers.
 

specs/merge/p2p-interface.md

@@ -1,6 +1,6 @@
-# Ethereum Merge networking specification
+# The Merge -- Networking
 
-This document contains the networking specification for Ethereum 2.0 clients added during the Merge deployment.
+This document contains the networking specification for the Merge.
 
 The specification of these changes continues in the same format as the network specifications of previous upgrades, and assumes them as pre-requisite. This document should be viewed as additive to the documents from [Phase 0](../phase0/p2p-interface.md) and from [Altair](../altair/p2p-interface.md)
 and will be referred to as the "Phase 0 document" and "Altair document" respectively, hereafter.

specs/merge/validator.md

@@ -1,4 +1,4 @@
-# Ethereum 2.0 The Merge
+# The Merge -- Honest Validator
 
 **Notice**: This document is a work-in-progress for researchers and implementers.
 

specs/phase0/beacon-chain.md

@@ -1,4 +1,4 @@
-# Ethereum 2.0 Phase 0 -- The Beacon Chain
+# Phase 0 -- The Beacon Chain
 
 ## Table of contents
 <!-- TOC -->
@@ -140,10 +140,10 @@
 
 ## Introduction
 
-This document represents the specification for Phase 0 of Ethereum 2.0 -- The Beacon Chain.
+This document represents the specification for Phase 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 (in a later Eth2 upgrade) and proof-of-stake votes for a beacon block (Phase 0).
+At the core of Ethereum proof-of-stake is a system chain called the "beacon chain". The beacon chain stores and manages the registry of validators. In the initial deployment phases of proof-of-stake, the only mechanism to become a validator is to make a one-way ETH transaction to a deposit contract on the Ethereum proof-of-work chain. Activation as a validator happens when 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 (in a later upgrade) and proof-of-stake votes for a beacon block (Phase 0).
 
 ## Notation
 
@@ -1166,13 +1166,13 @@ def slash_validator(state: BeaconState,
 
 ## Genesis
 
-Before the Ethereum 2.0 genesis has been triggered, and for every Ethereum 1.0 block, let `candidate_state = initialize_beacon_state_from_eth1(eth1_block_hash, eth1_timestamp, deposits)` where:
+Before the Ethereum beacon chain genesis has been triggered, and for every Ethereum proof-of-work block, let `candidate_state = initialize_beacon_state_from_eth1(eth1_block_hash, eth1_timestamp, deposits)` where:
 
-- `eth1_block_hash` is the hash of the Ethereum 1.0 block
+- `eth1_block_hash` is the hash of the Ethereum proof-of-work block
 - `eth1_timestamp` is the Unix timestamp corresponding to `eth1_block_hash`
 - `deposits` is the sequence of all deposits, ordered chronologically, up to (and including) the block with hash `eth1_block_hash`
 
-Eth1 blocks must only be considered once they are at least `SECONDS_PER_ETH1_BLOCK * ETH1_FOLLOW_DISTANCE` seconds old (i.e. `eth1_timestamp + SECONDS_PER_ETH1_BLOCK * ETH1_FOLLOW_DISTANCE <= current_unix_time`). Due to this constraint, if `GENESIS_DELAY < SECONDS_PER_ETH1_BLOCK * ETH1_FOLLOW_DISTANCE`, then the `genesis_time` can happen before the time/state is first known. Values should be configured to avoid this case.
+Proof-of-work blocks must only be considered once they are at least `SECONDS_PER_ETH1_BLOCK * ETH1_FOLLOW_DISTANCE` seconds old (i.e. `eth1_timestamp + SECONDS_PER_ETH1_BLOCK * ETH1_FOLLOW_DISTANCE <= current_unix_time`). Due to this constraint, if `GENESIS_DELAY < SECONDS_PER_ETH1_BLOCK * ETH1_FOLLOW_DISTANCE`, then the `genesis_time` can happen before the time/state is first known. Values should be configured to avoid this case.
 
 ```python
 def initialize_beacon_state_from_eth1(eth1_block_hash: Bytes32,

specs/phase0/deposit-contract.md

@@ -1,4 +1,4 @@
-# Ethereum 2.0 Phase 0 -- Deposit Contract
+# Phase 0 -- Deposit Contract
 
 ## Table of contents
 <!-- TOC -->
@@ -8,7 +8,7 @@
 - [Introduction](#introduction)
 - [Constants](#constants)
 - [Configuration](#configuration)
-- [Ethereum 1.0 deposit contract](#ethereum-10-deposit-contract)
+- [Staking deposit contract](#staking-deposit-contract)
   - [`deposit` function](#deposit-function)
     - [Deposit amount](#deposit-amount)
     - [Withdrawal credentials](#withdrawal-credentials)
@@ -20,7 +20,7 @@
 
 ## Introduction
 
-This document represents the specification for the beacon chain deposit contract, part of Ethereum 2.0 Phase 0.
+This document represents the specification for the beacon chain deposit contract, part of Phase 0.
 
 ## Constants
 
@@ -42,9 +42,9 @@ These configurations are updated for releases and may be out of sync during `dev
 | `DEPOSIT_NETWORK_ID` | `1` |
 | `DEPOSIT_CONTRACT_ADDRESS` | `0x00000000219ab540356cBB839Cbe05303d7705Fa` |
 
-## Ethereum 1.0 deposit contract
+## Staking deposit contract
 
-The initial deployment phases of Ethereum 2.0 are implemented without consensus changes to Ethereum 1.0. A deposit contract at address `DEPOSIT_CONTRACT_ADDRESS` is added to the Ethereum 1.0 chain defined by the [chain-id](https://eips.ethereum.org/EIPS/eip-155) -- `DEPOSIT_CHAIN_ID` -- and the network-id -- `DEPOSIT_NETWORK_ID` -- for deposits of ETH to the beacon chain. Validator balances will be withdrawable to the shards in Phase 2.
+The initial deployment phases of Ethereum proof-of-stake are implemented without consensus changes to the existing Ethereum proof-of-work chain. A deposit contract at address `DEPOSIT_CONTRACT_ADDRESS` is added to the Ethereum proof-of-work chain defined by the [chain-id](https://eips.ethereum.org/EIPS/eip-155) -- `DEPOSIT_CHAIN_ID` -- and the network-id -- `DEPOSIT_NETWORK_ID` -- for deposits of ETH to the beacon chain. Validator balances will be withdrawable to the execution-layer in a followup fork after the Merge.
 
 _Note_: See [here](https://chainid.network/) for a comprehensive list of public Ethereum chain chain-id's and network-id's.
 
@@ -54,7 +54,7 @@ The deposit contract has a public `deposit` function to make deposits. It takes
 
 #### Deposit amount
 
-The amount of ETH (rounded down to the closest Gwei) sent to the deposit contract is the deposit amount, which must be of size at least `MIN_DEPOSIT_AMOUNT` Gwei. Note that ETH consumed by the deposit contract is no longer usable on Ethereum 1.0.
+The amount of ETH (rounded down to the closest Gwei) sent to the deposit contract is the deposit amount, which must be of size at least `MIN_DEPOSIT_AMOUNT` Gwei. Note that ETH consumed by the deposit contract is no longer usable on the execution-layer until sometime after the Merge.
 
 #### Withdrawal credentials
 
@@ -68,7 +68,7 @@ Support for new withdrawal prefixes can be added without modifying the deposit c
 
 #### `DepositEvent` log
 
-Every Ethereum 1.0 deposit emits a `DepositEvent` log for consumption by the beacon chain. The deposit contract does little validation, pushing most of the validator onboarding logic to the beacon chain. In particular, the proof of possession (a BLS12-381 signature) is not verified by the deposit contract.
+Every deposit emits a `DepositEvent` log for consumption by the beacon chain. The deposit contract does little validation, pushing most of the validator onboarding logic to the beacon chain. In particular, the proof of possession (a BLS12-381 signature) is not verified by the deposit contract.
 
 ## Solidity code
 

specs/phase0/fork-choice.md

@@ -1,4 +1,4 @@
-# Ethereum 2.0 Phase 0 -- Beacon Chain Fork Choice
+# Phase 0 -- Beacon Chain Fork Choice
 
 ## Table of contents
 <!-- TOC -->
@@ -35,7 +35,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](./beacon-chain.md).
+This document is the beacon chain fork choice spec, part of Phase 0. It assumes the [beacon chain state transition function spec](./beacon-chain.md).
 
 ## Fork choice
 
@@ -51,7 +51,7 @@ Any of the above handlers that trigger an unhandled exception (e.g. a failed ass
 
 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.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 beacon chain remains consistent with the canonical Ethereum proof-of-work 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).