status-im
/
eth2.0-specs
mirror of https://github.com/status-im/eth2.0-specs.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

Add implementation note on message id fn

This commit is contained in:
Alex Stokes 2021-06-08 14:29:08 -05:00
parent f60f13964c
commit a343680fd4
No known key found for this signature in database
GPG Key ID: 99B3D88FD6C55A69
1 changed files with 6 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
specs/altair/p2p-interface.md
View File

@ -85,6 +85,12 @@ The `message-id` MUST be the following 20 byte value computed from the message:
the topic byte string, and the raw message data: 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]`. 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: The new topics along with the type of the `data` field of a gossipsub message are given in this table:
| Name | Message Type | | Name | Message Type |