-
Notifications
You must be signed in to change notification settings - Fork 998
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
Comments
@raulk: I'm going through old/stale issues. Any update on this? cc @AgeManning |
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. |
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 |
It made it in
Closing! @rauljordan—Feel free to reopen if you feel otherwise. |
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).
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:
/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
The text was updated successfully, but these errors were encountered: