[reopen] Eth2 shorthand standardized (#1452)

* Update README.md

* Update README.md

* Update p2p-interface.md

* Update simple-serialize.md

* Update README.md

* Update initialization.md

* Update README.md

* Update 0_beacon-chain-validator.md

* Update README.md

* Update README.md

* Update README.md

* Update README.md

* Update README.md

* Update README.md

* Update README.md

* Update README.md

README.md

@@ -4,12 +4,12 @@
 
 To learn more about sharding and Ethereum 2.0 (Serenity), see the [sharding FAQ](https://github.com/ethereum/wiki/wiki/Sharding-FAQ) and the [research compendium](https://notes.ethereum.org/s/H1PGqDhpm).
 
-This repository hosts the current Eth 2.0 specifications. Discussions about design rationale and proposed changes can be brought up and discussed as issues. Solidified, agreed-upon changes to the spec can be made through pull requests.
+This repository hosts the current Eth2 specifications. Discussions about design rationale and proposed changes can be brought up and discussed as issues. Solidified, agreed-upon changes to the spec can be made through pull requests.
 
 
 ## Specs
 
-Core specifications for Eth 2.0 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 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:
 
 ### Phase 0
 * [The Beacon Chain](specs/core/0_beacon-chain.md)
@@ -26,7 +26,7 @@ Core specifications for Eth 2.0 client validation can be found in [specs/core](s
 
 Phase 2 is still actively in R&D and does not yet have any formal specifications.
 
-See the [Eth 2.0 Phase 2 Wiki](https://hackmd.io/UzysWse1Th240HELswKqVA?view) for current progress, discussions, and definitions regarding this work.
+See the [Eth2 Phase 2 Wiki](https://hackmd.io/UzysWse1Th240HELswKqVA?view) for current progress, discussions, and definitions regarding this work.
 
 ### Accompanying documents can be found in [specs](specs) and include:
 
@@ -40,9 +40,9 @@ See the [Eth 2.0 Phase 2 Wiki](https://hackmd.io/UzysWse1Th240HELswKqVA?view) fo
 
 Additional specifications and standards outside of requisite client functionality can be found in the following repos:
 
-* [Eth2.0 APIs](https://github.com/ethereum/eth2.0-apis)
-* [Eth2.0 Metrics](https://github.com/ethereum/eth2.0-metrics/)
-* [Interop Standards in Eth2.0-pm](https://github.com/ethereum/eth2.0-pm/tree/master/interop)
+* [Eth2 APIs](https://github.com/ethereum/eth2.0-apis)
+* [Eth2 Metrics](https://github.com/ethereum/eth2.0-metrics/)
+* [Interop Standards in Eth2 PM](https://github.com/ethereum/eth2.0-pm/tree/master/interop)
 
 ## Design goals
 

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 phase1 constants as a client that only supports phase 0 currently.
+Later-fork constants can be ignored, e.g. ignore Phase 1 constants as a client that only supports Phase 0 currently.
 
 
 ## Forking
@@ -14,9 +14,8 @@ Instead, for forks that introduce changes in a constant, the constant name is pr
 Over time, the need to sync an older state may be deprecated.
 In this case, the prefix on the new constant may be removed, and the old constant will keep a special name before completely being removed.
 
-A previous iteration of forking made use of "timelines", but this collides with the definitions used in the spec (constants for special forking slots etc.),
- and was not integrated sufficiently in any of the spec tools or implementations.
-Instead, the config essentially doubles as fork definition now, changing the value for e.g. `PHASE_1_GENESIS_SLOT` changes the fork.
+A previous iteration of forking made use of "timelines", but this collides with the definitions used in the spec (constants for special forking slots, etc.), and was not integrated sufficiently in any of the spec tools or implementations.
+Instead, the config essentially doubles as fork definition now, e.g. changing the value for `PHASE_1_GENESIS_SLOT` changes the fork.
 
 Another reason to prefer forking through constants is the ability to program a forking moment based on context, instead of being limited to a static slot number.
 

specs/networking/p2p-interface.md

@@ -5,9 +5,9 @@ This document contains the networking specification for Ethereum 2.0 clients.
 It consists of four main sections:
 
 1. A specification of the network fundamentals detailing the two network configurations: interoperability test network and mainnet launch.
-2. A specification of the three network interaction *domains* of Eth 2.0: (a) the gossip domain, (b) the discovery domain, and (c) the Req/Resp domain.
+2. A specification of the three network interaction *domains* of Eth2: (a) the gossip domain, (b) the discovery domain, and (c) the Req/Resp domain.
 3. The rationale and further explanation for the design choices made in the previous two sections.
-4. An analysis of the maturity/state of the libp2p features required by this spec across the languages in which Eth 2.0 clients are being developed.
+4. An analysis of the maturity/state of the libp2p features required by this spec across the languages in which Eth2 clients are being developed.
 
 ## Table of contents
 
@@ -21,7 +21,7 @@ It consists of four main sections:
   - [Encryption and identification](#encryption-and-identification)
   - [Protocol negotiation](#protocol-negotiation)
   - [Multiplexing](#multiplexing)
-- [Eth 2.0 network interaction domains](#eth-20-network-interaction-domains)
+- [Eth2 network interaction domains](#eth2-network-interaction-domains)
   - [Configuration](#configuration)
   - [The gossip domain: gossipsub](#the-gossip-domain-gossipsub)
   - [The Req/Resp domain](#the-reqresp-domain)
@@ -83,7 +83,7 @@ The following SecIO parameters MUST be supported by all stacks:
 
 [Noise Framework](http://www.noiseprotocol.org/) handshakes will be used for mainnet. libp2p Noise support [is in the process of being standardized](https://github.com/libp2p/specs/issues/195) in the libp2p project.
 
-Noise support will presumably include IX, IK, and XX handshake patterns, and may rely on Curve25519 keys, ChaCha20 and Poly1305 ciphers, and SHA-256 as a hash function. These aspects are being actively debated in the referenced issue (Eth 2.0 implementers are welcome to comment and contribute to the discussion).
+Noise support will presumably include IX, IK, and XX handshake patterns, and may rely on Curve25519 keys, ChaCha20 and Poly1305 ciphers, and SHA-256 as a hash function. These aspects are being actively debated in the referenced issue (Eth2 implementers are welcome to comment and contribute to the discussion).
 
 ## Protocol Negotiation
 
@@ -105,7 +105,7 @@ Two multiplexers are commonplace in libp2p implementations: [mplex](https://gith
 
 Clients MUST support [mplex](https://github.com/libp2p/specs/tree/master/mplex) and MAY support [yamux](https://github.com/hashicorp/yamux/blob/master/spec.md). If both are supported by the client, yamux must take precedence during negotiation. See the [Rationale](#design-decision-rationale) section below for tradeoffs.
 
-# Eth 2.0 network interaction domains
+# Eth2 network interaction domains
 
 ## Configuration
 
@@ -475,9 +475,9 @@ Specifications of these parameters can be found in the [ENR Specification](http:
 
 #### Interop
 
-In the interoperability testnet, all peers will support all capabilities defined in this document (gossip, full Req/Resp suite, discovery protocol), therefore the ENR record does not need to carry Eth 2.0 capability information, as it would be superfluous.
+In the interoperability testnet, all peers will support all capabilities defined in this document (gossip, full Req/Resp suite, discovery protocol), therefore the ENR record does not need to carry Eth2 capability information, as it would be superfluous.
 
-Nonetheless, ENRs MUST carry a generic `eth2` key with nil value, denoting that the peer is indeed an Eth 2.0 peer, in order to eschew connecting to Eth 1.0 peers.
+Nonetheless, ENRs MUST carry a generic `eth2` key with nil value, denoting that the peer is indeed an Eth2 peer, in order to eschew connecting to Eth 1.0 peers.
 
 #### Mainnet
 
@@ -514,7 +514,7 @@ Clients may support other transports such as libp2p QUIC, WebSockets, and WebRTC
 
 The libp2p QUIC transport inherently relies on TLS 1.3 per requirement in section 7 of the [QUIC protocol specification](https://tools.ietf.org/html/draft-ietf-quic-transport-22#section-7) and the accompanying [QUIC-TLS document](https://tools.ietf.org/html/draft-ietf-quic-tls-22).
 
-The usage of one handshake procedure or the other shall be transparent to the Eth 2.0 application layer, once the libp2p Host/Node object has been configured appropriately.
+The usage of one handshake procedure or the other shall be transparent to the Eth2 application layer, once the libp2p Host/Node object has been configured appropriately.
 
 ### What are the advantages of using TCP/QUIC/Websockets?
 
@@ -524,7 +524,7 @@ QUIC is a new protocol that’s in the final stages of specification by the IETF
 
 QUIC is being adopted as the underlying protocol for HTTP/3. This has the potential to award us censorship resistance via deep packet inspection for free. Provided that we use the same port numbers and encryption mechanisms as HTTP/3, our traffic may be indistinguishable from standard web traffic, and we may only become subject to standard IP-based firewall filtering—something we can counteract via other mechanisms.
 
-WebSockets and/or WebRTC transports are necessary for interaction with browsers, and will become increasingly important as we incorporate browser-based light clients to the Eth 2.0 network.
+WebSockets and/or WebRTC transports are necessary for interaction with browsers, and will become increasingly important as we incorporate browser-based light clients to the Eth2 network.
 
 ### Why do we not just support a single transport?
 
@@ -652,7 +652,7 @@ Topic names have a hierarchical structure. In the future, gossipsub may support
 
 No security or privacy guarantees are lost as a result of choosing plaintext topic names, since the domain is finite anyway, and calculating a digest's preimage would be trivial.
 
-Furthermore, the Eth 2.0 topic names are shorter than their digest equivalents (assuming SHA-256 hash), so hashing topics would bloat messages unnecessarily.
+Furthermore, the Eth2 topic names are shorter than their digest equivalents (assuming SHA-256 hash), so hashing topics would bloat messages unnecessarily.
 
 ### Why are there `SHARD_SUBNET_COUNT` subnets, and why is this not defined?
 
@@ -683,7 +683,7 @@ Requests are segregated by protocol ID to:
 3. Enable clients to select the individual requests/versions they support. It would no longer be a strict requirement to support all requests, and clients, in principle, could support a subset of requests and variety of versions.
 4. Enable flexibility and agility for clients adopting spec changes that impact the request, by signalling to peers exactly which subset of new/old requests they support.
 5. Enable clients to explicitly choose backwards compatibility at the request granularity. Without this, clients would be forced to support entire versions of the coarser request protocol.
-6. Parallelise RFCs (or Eth 2.0 EIPs). By decoupling requests from one another, each RFC that affects the request protocol can be deployed/tested/debated independently without relying on a synchronization point to version the general top-level protocol.
+6. Parallelise RFCs (or Eth2 EIPs). By decoupling requests from one another, each RFC that affects the request protocol can be deployed/tested/debated independently without relying on a synchronization point to version the general top-level protocol.
   1. This has the benefit that clients can explicitly choose which RFCs to deploy without buying into all other RFCs that may be included in that top-level version.
   2. Affording this level of granularity with a top-level protocol would imply creating as many variants (e.g. /protocol/43-{a,b,c,d,...}) as the cartesian product of RFCs inflight, O(n^2).
 7. Allow us to simplify the payload of requests. Request-id’s and method-ids no longer need to be sent. The encoding/request type and version can all be handled by the framework.
@@ -795,4 +795,4 @@ For specific ad-hoc testing scenarios, you can use the [plaintext/2.0.0 secure c
 
 # libp2p implementations matrix
 
-This section will soon contain a matrix showing the maturity/state of the libp2p features required by this spec across the languages in which Eth 2.0 clients are being developed.
+This section will soon contain a matrix showing the maturity/state of the libp2p features required by this spec across the languages in which Eth2 clients are being developed.

specs/simple-serialize.md

@@ -1,6 +1,6 @@
 # SimpleSerialize (SSZ)
 
-**Notice**: This document is a work-in-progress describing typing, serialization, and Merkleization of Eth 2.0 objects.
+**Notice**: This document is a work-in-progress describing typing, serialization, and Merkleization of Eth2 objects.
 
 ## Table of contents
 <!-- TOC -->

specs/test_formats/README.md

@@ -1,6 +1,6 @@
 # General test format
 
-This document defines the YAML format and structure used for Eth 2.0 testing.
+This document defines the YAML format and structure used for Eth2 testing.
 
 ## Table of contents
 <!-- TOC -->

specs/test_formats/genesis/initialization.md

@@ -6,7 +6,7 @@ Tests the initialization of a genesis state based on Eth1 data.
 
 ### `eth1_block_hash.yaml`
 
-A `Bytes32` hex encoded, with prefix 0x. The root of the Eth-1 block.
+A `Bytes32` hex encoded, with prefix 0x. The root of the Eth1 block.
 
 Also available as `eth1_block_hash.ssz`.
 

specs/test_formats/ssz_static/README.md

@@ -1,7 +1,7 @@
 # SSZ, static tests
 
 This set of test-suites provides static testing for SSZ:
- to instantiate just the known Eth 2.0 SSZ types from binary data.
+ to instantiate just the known Eth2 SSZ types from binary data.
 
 This series of tests is based on the spec-maintained `eth2spec/utils/ssz/ssz_impl.py`, i.e. fully consistent with the SSZ spec. 
 

specs/validator/0_beacon-chain-validator.md

@@ -106,7 +106,7 @@ To submit a deposit:
 
 ### Process deposit
 
-Deposits cannot be processed into the beacon chain until the Eth 1.0 block in which they were deposited or any of its descendants is added to the beacon chain `state.eth1_data`. This takes _a minimum_ of `ETH1_FOLLOW_DISTANCE` Eth 1.0 blocks (~4 hours) plus `ETH1_DATA_VOTING_PERIOD` epochs (~1.7 hours). Once the requisite Eth 1.0 data is added, the deposit will normally be added to a beacon chain block and processed into the `state.validators` within an epoch or two. The validator is then in a queue to be activated.
+Deposits cannot be processed into the beacon chain until the Eth1 block in which they were deposited or any of its descendants is added to the beacon chain `state.eth1_data`. This takes _a minimum_ of `ETH1_FOLLOW_DISTANCE` Eth1 blocks (~4 hours) plus `ETH1_DATA_VOTING_PERIOD` epochs (~1.7 hours). Once the requisite Eth1 data is added, the deposit will normally be added to a beacon chain block and processed into the `state.validators` within an epoch or two. The validator is then in a queue to be activated.
 
 ### Validator index
 
@@ -217,9 +217,9 @@ def get_epoch_signature(state: BeaconState, block: BeaconBlock, privkey: int) ->
 
 ##### Eth1 Data
 
-The `block.eth1_data` field is for block proposers to vote on recent Eth 1.0 data. This recent data contains an Eth 1.0 block hash as well as the associated deposit root (as calculated by the `get_deposit_root()` method of the deposit contract) and deposit count after execution of the corresponding Eth 1.0 block. If over half of the block proposers in the current Eth 1.0 voting period vote for the same `eth1_data` then `state.eth1_data` updates at the end of the voting period. Each deposit in `block.body.deposits` must verify against `state.eth1_data.eth1_deposit_root`.
+The `block.eth1_data` field is for block proposers to vote on recent Eth1 data. This recent data contains an Eth1 block hash as well as the associated deposit root (as calculated by the `get_deposit_root()` method of the deposit contract) and deposit count after execution of the corresponding Eth1 block. If over half of the block proposers in the current Eth1 voting period vote for the same `eth1_data` then `state.eth1_data` updates at the end of the voting period. Each deposit in `block.body.deposits` must verify against `state.eth1_data.eth1_deposit_root`.
 
-Let `get_eth1_data(distance: uint64) -> Eth1Data` be the (subjective) function that returns the Eth 1.0 data at distance `distance` relative to the Eth 1.0 head at the start of the current Eth 1.0 voting period. Let `previous_eth1_distance` be the distance relative to the Eth 1.0 block corresponding to `state.eth1_data.block_hash` at the start of the current Eth 1.0 voting period. An honest block proposer sets `block.eth1_data = get_eth1_vote(state, previous_eth1_distance)` where:
+Let `get_eth1_data(distance: uint64) -> Eth1Data` be the (subjective) function that returns the Eth1 data at distance `distance` relative to the Eth1 head at the start of the current Eth1 voting period. Let `previous_eth1_distance` be the distance relative to the Eth1 block corresponding to `state.eth1_data.block_hash` at the start of the current Eth1 voting period. An honest block proposer sets `block.eth1_data = get_eth1_vote(state, previous_eth1_distance)` where:
 
 ```python
 def get_eth1_vote(state: BeaconState, previous_eth1_distance: uint64) -> Eth1Data:
@@ -265,7 +265,7 @@ Up to `MAX_ATTESTATIONS`, aggregate attestations can be included in the `block`.
 
 ##### 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 [Eth 1.0 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`](../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).
 
 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.
 

test_generators/README.md

@@ -1,6 +1,6 @@
-# Eth 2.0 Test Generators
+# Eth2 test generators
 
-This directory contains all the generators for tests, consumed by Eth 2.0 client implementations.
+This directory contains all the generators for tests, consumed by Eth2 client implementations.
 
 Any issues with the generators and/or generated tests should be filed in the repository that hosts the generator outputs,
  here: [ethereum/eth2.0-spec-tests](https://github.com/ethereum/eth2.0-spec-tests).

test_generators/bls/README.md

@@ -9,7 +9,7 @@ The base unit is bytes48 of which only 381 bits are used
 
 ## Resources
 
-- [Eth2.0 spec](../../specs/bls_signature.md)
+- [Eth2 spec](../../specs/bls_signature.md)
 - [Finite Field Arithmetic](http://www.springeronline.com/sgw/cda/pageitems/document/cda_downloaddocument/0,11996,0-0-45-110359-0,00.pdf)
 - Chapter 2 of [Elliptic Curve Cryptography](http://cacr.uwaterloo.ca/ecc/). Darrel Hankerson, Alfred Menezes, and Scott Vanstone 
 - [Zcash BLS parameters](https://github.com/zkcrypto/pairing/tree/master/src/bls12_381)