status-im
/
eth2.0-specs
mirror of https://github.com/status-im/eth2.0-specs.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

note v5.1 in discv5 p2p spec

This commit is contained in:
Danny Ryan 2020-10-07 12:12:02 -06:00
parent df23a95a26
commit 8cda237884
No known key found for this signature in database
GPG Key ID: 2765A792E42CE07A
1 changed files with 2 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
specs/phase0/p2p-interface.md
View File

@ -54,8 +54,6 @@ It consists of four main sections:
- [ENR structure](#enr-structure) - [ENR structure](#enr-structure)
- [Attestation subnet bitfield](#attestation-subnet-bitfield) - [Attestation subnet bitfield](#attestation-subnet-bitfield)
- [`eth2` field](#eth2-field) - [`eth2` field](#eth2-field)
- [General capabilities](#general-capabilities)
- [Topic advertisement](#topic-advertisement)
- [Design decision rationale](#design-decision-rationale) - [Design decision rationale](#design-decision-rationale)
- [Transport](#transport-1) - [Transport](#transport-1)
- [Why are we defining specific transports?](#why-are-we-defining-specific-transports) - [Why are we defining specific transports?](#why-are-we-defining-specific-transports)
@ -846,13 +844,11 @@ The response MUST consist of a single `response_chunk`.
## The discovery domain: discv5 ## The discovery domain: discv5
Discovery Version 5 ([discv5](https://github.com/ethereum/devp2p/blob/master/discv5/discv5.md)) is used for peer discovery. Discovery Version 5 ([discv5](https://github.com/ethereum/devp2p/blob/master/discv5/discv5.md)) (Protocol version v5.1) is used for peer discovery.
`discv5` is a standalone protocol, running on UDP on a dedicated port, meant for peer discovery only. `discv5` is a standalone protocol, running on UDP on a dedicated port, meant for peer discovery only.
`discv5` supports self-certified, flexible peer records (ENRs) and topic-based advertisement, both of which are (or will be) requirements in this context. `discv5` supports self-certified, flexible peer records (ENRs) and topic-based advertisement, both of which are (or will be) requirements in this context.
:warning: Under construction. :warning:
### Integration into libp2p stacks ### Integration into libp2p stacks
`discv5` SHOULD be integrated into the client’s libp2p stack by implementing an adaptor `discv5` SHOULD be integrated into the client’s libp2p stack by implementing an adaptor
@ -935,19 +931,6 @@ Clients MAY connect to peers with the same `fork_digest` but a different `next_f
Unless `ENRForkID` is manually updated to matching prior to the earlier `next_fork_epoch` of the two clients, Unless `ENRForkID` is manually updated to matching prior to the earlier `next_fork_epoch` of the two clients,
these connecting clients will be unable to successfully interact starting at the earlier `next_fork_epoch`. these connecting clients will be unable to successfully interact starting at the earlier `next_fork_epoch`.
#### General capabilities
ENRs MUST include a structure enumerating the capabilities offered by the peer in an efficient manner.
The concrete solution is currently undefined.
Proposals include using namespaced bloom filters mapping capabilities to specific protocol IDs supported under that capability.
### Topic advertisement
discv5's topic advertisement feature is not expected to be ready for mainnet launch of Phase 0.
Once this feature is built out and stable, we expect to use topic advertisement as a rendezvous facility for peers on shards.
Until then, the ENR [attestation subnet bitfield](#attestation-subnet-bitfield) will be used for discovery of peers on particular subnets.
# Design decision rationale # Design decision rationale
## Transport ## Transport
@ -1408,7 +1391,7 @@ discv5 supports self-certified, flexible peer records (ENRs) and topic-based adv
On the other hand, libp2p Kademlia DHT is a fully-fledged DHT protocol/implementations On the other hand, libp2p Kademlia DHT is a fully-fledged DHT protocol/implementations
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.
We assume that 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 1.0 and 2.0,
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.