Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Networking: protocol advertisement in discv5 #1335

Closed
raulk opened this issue Aug 4, 2019 · 4 comments
Closed

Networking: protocol advertisement in discv5 #1335

raulk opened this issue Aug 4, 2019 · 4 comments

Comments

@raulk
Copy link
Contributor

raulk commented Aug 4, 2019

The networking spec introduced in #1328 relies on fine-grained, per-operation protocol IDs to univocally identify what operation a req/rep stream targets (negotiated and selected via multistream-select 1.0 / multiselect 2.0).

[For background on the rationale, see the answer to question "Why segregate requests into dedicated protocol IDs?"]

To efficiently advertise our supported protocol set on the discovery layer (discv5), I propose to introduce the concept of protocol families OR protocol groups OR protocol suites OR protocol manifests that aggregate finer-grained protocols into a logical, versioned unit that can be advertised/enumerated efficiently on the ENR (max. size 300 bytes), e.g. /eth/reqrep/attestation/v03.

Another approach worth considering is bloom filters on the ENR, in order to compact advertisements in a probabilistic manner. Either:

  1. a single, flat bloom filter.
  2. one bloom filter per namespace, e.g. one bloom filter for /eth/reqrep/attestation, another one for /eth/reqrep/slashing

could potentially work well.

See the following discussions for context:

#1328 (comment)
#1328 (comment)
https://github.com/ethereum/eth2.0-specs/pull/1328/files#diff-9e07d955515655364c9a5f28c94f5627R236

@JustinDrake
Copy link
Contributor

@raulk: I'm going through old/stale issues. Any update on this? cc @AgeManning

@AgeManning
Copy link
Contributor

This is a good idea and a relatively easy implementation to advertise protocols.

I think whether we adopt a solution like this, or another ENR-based advertised solution depends on whether we can get discv5 topics to a production state that everyone agrees on.

For the time being, we are discovering peers, then negotiating protocols via multistream select, rather than checking a bloom filter.

If @raulk agrees, I think we can close this and re-address when looking into topic advertisements in discv5.

@djrtwo
Copy link
Contributor

djrtwo commented Dec 17, 2019

We certainly want to do shard-subnet advertisement via ENR in the meantime. We plan to accomplish this via a 64-bit bitfield in phase 0. Getting this into spec and releasing a very minor v0.9.4 is top of my list tomorrow

@JustinDrake
Copy link
Contributor

Getting this into spec and releasing a very minor v0.9.4 is top of my list

It made it in v0.9.4 https://github.com/ethereum/eth2.0-specs/pull/1534/files :)

I think we can close this and re-address when looking into topic advertisements in discv5

Closing! @rauljordan—Feel free to reopen if you feel otherwise.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants