You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As part of #792 the propagation of EC Chain is separated into its own pubsub topic, managed via chainexchange. Initially, the broadcast of chain and its reboradcast is coupled to GPBFT broadcast/re-boradcast: Whenever GPBFT broadcasts a message we broadcast its chain and so on. But we can do better, because: all chain subsets can be inferred from the longest broadcasted chain (i.e. the QUALITY proposal), and depending on the progress it may not be necessary to rebroadcast the chain.
Ideally, the system should have control over the chain broadcast intensity. Separate out the heuristic of chain broadcast from GPBFT.
Ideas:
Only broadcast a chain a fixed number of times.
Introduce an incrementing sequence number in messages to work around gossipsub deduplication.
For safety rebroadcast subsets of the QUALITY chain relative to progress?
Or just stick with always broadcasting the QUALITY proposal. Because from it we can infer all the sub chains that could be stemmed from it during an instance, and it is simpler to implement/maintain.
The text was updated successfully, but these errors were encountered:
Broadcast chains periodically for the lifetime of a GPBFT instance.
The broadcast message includes a timestamp rounded to some minimum acceptable interval. This is to:
Work around the pubsub deduplication.
Protect against an adversarial model of swaying the network with spam about a particular chain early on/ too soon (compared to using plain monotonically increasing sequence numbers).
The broadcasted chain is initially the QUALITY proposal for at least n number of times.
The broadcasted chain then may change to whatever proposal the instance is swayed.
The time interval for rebroadcast of QUALITY proposal and swayed chain is independently configurable via manifest to give us room for experimentation during passive testing.
@Stebalien can I get a quick sanity check on this please whenever you get a chance?
As part of #792 the propagation of EC Chain is separated into its own pubsub topic, managed via
chainexchange
. Initially, the broadcast of chain and its reboradcast is coupled to GPBFT broadcast/re-boradcast: Whenever GPBFT broadcasts a message we broadcast its chain and so on. But we can do better, because: all chain subsets can be inferred from the longest broadcasted chain (i.e. the QUALITY proposal), and depending on the progress it may not be necessary to rebroadcast the chain.Ideally, the system should have control over the chain broadcast intensity. Separate out the heuristic of chain broadcast from GPBFT.
Ideas:
The text was updated successfully, but these errors were encountered: