status-im/eth2.0-specs
2
0
Fork 0
mirror of https://github.com/status-im/eth2.0-specs.git synced 2025-02-20 22:38:11 +00:00
Code Issues Projects Releases Wiki Activity

Add faq

Browse Source
This commit is contained in:
Jacek Sieka 2020-03-01 17:17:29 +01:00
parent 61f661b3ec
commit 38323d8186
No known key found for this signature in database
GPG Key ID: A1B09461ABB656B8
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
specs/phase0/p2p-interface.md
View File

@ -763,9 +763,9 @@ For future extensibility with almost zero overhead now (besides the extra bytes
### How do we upgrade gossip channels (e.g. changes in encoding, compression)?
Changing gossipsub/broadcasts requires a coordinated upgrade where all clients start publishing to the new topic together, for example during a hard fork.
Changing gossipsub/broadcasts requires a coordinated upgrade where all clients start publishing to the new topic together, during a hard fork.
One can envision a two-phase deployment as well where clients start listening to the new topic in the first phase then start publishing some time later, letting the traffic naturally move over to the new topic.
When a node is preparing for upcoming tasks (e.g. validator duty lookahead) on a gossipsub topic, the node should join the topic of the future epoch in which the task is to occur in addition to listening to the topics for the current epoch.
### Why must all clients use the same gossip topic instead of one negotiated between each peer pair?