From 8ad08654243433951c4fb2e1b5e79dc8ef193ba5 Mon Sep 17 00:00:00 2001 From: protolambda Date: Tue, 15 Sep 2020 01:15:16 +0200 Subject: [PATCH] Use gossip signing policy in p2p spec, see libp2p/specs#294 --- specs/phase0/p2p-interface.md | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/specs/phase0/p2p-interface.md b/specs/phase0/p2p-interface.md index e90a91341..c38fd6bf0 100644 --- a/specs/phase0/p2p-interface.md +++ b/specs/phase0/p2p-interface.md @@ -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) @@ -243,6 +244,10 @@ 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. + 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 @@ -1164,10 +1169,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: