Update some "1.0" "2.0" wording
This commit is contained in:
parent
911a4169fe
commit
59d8ee34f9
|
@ -1,6 +1,6 @@
|
||||||
# Altair -- Honest Validator
|
# Altair -- Honest Validator
|
||||||
|
|
||||||
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.
|
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 consensus protocol.
|
||||||
|
|
||||||
## Table of contents
|
## Table of contents
|
||||||
|
|
||||||
|
@ -49,8 +49,8 @@ This is an accompanying document to [Altair -- The Beacon Chain](./beacon-chain.
|
||||||
|
|
||||||
## Introduction
|
## Introduction
|
||||||
|
|
||||||
This document represents the expected behavior of an "honest validator" with respect to the Altair upgrade of the Ethereum 2.0 protocol.
|
This document represents the expected behavior of an "honest validator" with respect to the Altair upgrade of the Ethereum consensus protocol.
|
||||||
It builds on the [previous document for the behavior of an "honest validator" from Phase 0](../phase0/validator.md) of the Ethereum 2.0 protocol.
|
It builds on the [previous document for the behavior of an "honest validator" from Phase 0](../phase0/validator.md) of the Ethereum consensus protocol.
|
||||||
This previous document is referred to below as the "Phase 0 document".
|
This previous document is referred to below as the "Phase 0 document".
|
||||||
|
|
||||||
Altair introduces a new type of committee: the sync committee. Sync committees are responsible for signing each block of the canonical chain and there exists an efficient algorithm for light clients to sync the chain using the output of the sync committees.
|
Altair introduces a new type of committee: the sync committee. Sync committees are responsible for signing each block of the canonical chain and there exists an efficient algorithm for light clients to sync the chain using the output of the sync committees.
|
||||||
|
|
|
@ -904,7 +904,7 @@ This integration enables the libp2p stack to subsequently form connections and s
|
||||||
|
|
||||||
### ENR structure
|
### ENR structure
|
||||||
|
|
||||||
The Ethereum Node Record (ENR) for an Ethereum 2.0 client MUST contain the following entries
|
The Ethereum Node Record (ENR) for an Ethereum consensus client MUST contain the following entries
|
||||||
(exclusive of the sequence number and signature, which MUST be present in an ENR):
|
(exclusive of the sequence number and signature, which MUST be present in an ENR):
|
||||||
|
|
||||||
- The compressed secp256k1 publickey, 33 bytes (`secp256k1` field).
|
- The compressed secp256k1 publickey, 33 bytes (`secp256k1` field).
|
||||||
|
@ -1477,7 +1477,7 @@ On the other hand, libp2p Kademlia DHT is a fully-fledged DHT protocol/implement
|
||||||
with content routing and storage capabilities, both of which are irrelevant in this context.
|
with content routing and storage capabilities, both of which are irrelevant in this context.
|
||||||
|
|
||||||
Eth 1.0 nodes will evolve to support discv5.
|
Eth 1.0 nodes will evolve to support discv5.
|
||||||
By sharing the discovery network between Eth 1.0 and 2.0,
|
By sharing the discovery network between Eth consensus-layer and execution-layer clients,
|
||||||
we benefit from the additive effect on network size that enhances resilience and resistance against certain attacks,
|
we benefit from the additive effect on network size that enhances resilience and resistance against certain attacks,
|
||||||
to which smaller networks are more vulnerable.
|
to which smaller networks are more vulnerable.
|
||||||
It should also help light clients of both networks find nodes with specific capabilities.
|
It should also help light clients of both networks find nodes with specific capabilities.
|
||||||
|
|
Loading…
Reference in New Issue