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.

Sign up for GitHub

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

Use gossip signing policy in p2p spec, see libp2p/specs#294 #2060

Merged
merged 2 commits into from
Sep 30, 2020
Merged

Use gossip signing policy in p2p spec, see libp2p/specs#294 #2060

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
8ad0865
Use gossip signing policy in p2p spec, see libp2p/specs#294
protolambda Sep 14, 2020
62d596a
update signature policy link
protolambda Sep 25, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 14 additions & 2 deletions specs/phase0/p2p-interface.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -78,6 +78,7 @@ It consists of four main sections:
- [How do we upgrade gossip channels (e.g. changes in encoding, compression)?](#how-do-we-upgrade-gossip-channels-eg-changes-in-encoding-compression)
- [Why must all clients use the same gossip topic instead of one negotiated between each peer pair?](#why-must-all-clients-use-the-same-gossip-topic-instead-of-one-negotiated-between-each-peer-pair)
- [Why are the topics strings and not hashes?](#why-are-the-topics-strings-and-not-hashes)
- [Why are we using the `StrictNoSign` signature policy?](#why-are-we-using-the-strictnosign-signature-policy)
- [Why are we overriding the default libp2p pubsub `message-id`?](#why-are-we-overriding-the-default-libp2p-pubsub-message-id)
- [Why are these specific gossip parameters chosen?](#why-are-these-specific-gossip-parameters-chosen)
- [Why is there `MAXIMUM_GOSSIP_CLOCK_DISPARITY` when validating slot ranges of messages in gossip subnets?](#why-is-there-maximum_gossip_clock_disparity-when-validating-slot-ranges-of-messages-in-gossip-subnets)
Expand Down Expand Up @@ -243,6 +244,11 @@ Each gossipsub [message](https://github.com/libp2p/go-libp2p-pubsub/blob/master/
Clients MUST reject (fail validation) messages that are over this size limit.
Likewise, clients MUST NOT emit or propagate messages larger than this limit.

The optional `from` (1), `seqno` (3), `signature` (5) and `key` (6) protobuf fields are omitted from the message,
since messages are identified by content, anonymous, and signed where necessary in the application layer.
Starting from Gossipsub v1.1, clients MUST enforce this by applying the `StrictNoSign`
[signature policy](https://github.com/libp2p/specs/blob/master/pubsub/README.md#signature-policy-options).

The `message-id` of a gossipsub message MUST be the first 8 bytes of the SHA-256 hash of the message data, i.e.:

```python
Expand Down Expand Up @@ -1164,10 +1170,16 @@ since the domain is finite anyway, and calculating a digest's preimage would be
Furthermore, the Eth2 topic names are shorter than their digest equivalents (assuming SHA-256 hash),
so hashing topics would bloat messages unnecessarily.

### Why are we using the `StrictNoSign` signature policy?

The policy omits the `from` (1), `seqno` (3), `signature` (5) and `key` (6) fields. These fields would:
- Expose origin of sender (`from`), type of sender (based on `seqno`)
- Add extra unused data to the gossip, since message IDs are based on `data`, not on the `from` and `seqno`.
- Introduce more message validation than necessary, e.g. no `signature`.

### Why are we overriding the default libp2p pubsub `message-id`?

For our current purposes, there is no need to address messages based on source peer,
and it seems likely we might even override the message `from` to obfuscate the peer.
For our current purposes, there is no need to address messages based on source peer, or track a message `seqno`.
By overriding the default `message-id` to use content-addressing we can filter unnecessary duplicates before hitting the application layer.

Some examples of where messages could be duplicated:
Expand Down