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

Add message.topic to gossipsub message-id in Altair #2475

Merged
merged 4 commits into from
Jun 8, 2021
Merged

Add message.topic to gossipsub message-id in Altair #2475

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
d64b4e7
Add `message.topic` to gossipsub `message-id` in Altair
ralexstokes Jun 8, 2021
25a2e34
Update specs/altair/p2p-interface.md
ralexstokes Jun 8, 2021
f60f139
Harden topic serialization
ralexstokes Jun 8, 2021
a343680
Add implementation note on message id fn
ralexstokes Jun 8, 2021
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
17 changes: 17 additions & 0 deletions specs/altair/p2p-interface.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -74,6 +74,23 @@ New topics are added in Altair to support the sync committees and the beacon blo

The specification around the creation, validation, and dissemination of messages has not changed from the Phase 0 document.

The derivation of the `message-id` has changed starting with Altair to incorporate the message `topic` along with the message `data`. These are fields of the `Message` Protobuf, and interpreted as empty byte strings if missing.
The `message-id` MUST be the following 20 byte value computed from the message:
* If `message.data` has a valid snappy decompression, set `message-id` to the first 20 bytes of the `SHA256` hash of
the concatenation of the following data: `MESSAGE_DOMAIN_VALID_SNAPPY`, the length of the topic byte string (encoded as little-endian `uint64`),
the topic byte string, and the snappy decompressed message data:
i.e. `SHA256(MESSAGE_DOMAIN_VALID_SNAPPY + uint_to_bytes(uint64(len(message.topic))) + message.topic + snappy_decompress(message.data)[:20]`.
* Otherwise, set `message-id` to the first 20 bytes of the `SHA256` hash of
the concatenation of the following data: `MESSAGE_DOMAIN_INVALID_SNAPPY`, the length of the topic byte string (encoded as little-endian `uint64`),
the topic byte string, and the raw message data:
i.e. `SHA256(MESSAGE_DOMAIN_INVALID_SNAPPY + uint_to_bytes(uint64(len(message.topic))) + message.topic + message.data)[:20]`.

Implementations may need to carefully handle the function that computes the `message-id`. In particular, messages on topics with the Phase 0
fork digest should use the `message-id` procedure specified in the Phase 0 document.
Messages on topics with the Altair fork digest should use the `message-id` procedure defined here.
If an implementation only supports a single `message-id` function, it can define a switch inline;
for example, `if topic in phase0_topics: return phase0_msg_id_fn(message) else return altair_msg_id_fn(message)`.

The new topics along with the type of the `data` field of a gossipsub message are given in this table:

| Name | Message Type |
Expand Down