Implement a chain rebroadcast mechanism independent of GPBFT

[masih]

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.

[masih]

Discussed with @Kubuxu at Standup:

The chain rebroadcast heuristic:

• 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:
  1. Work around the pubsub deduplication.
  2. 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?

Thanks

[Stebalien]

The broadcast message includes a timestamp rounded to some minimum acceptable interval. This is to:

We can also use a separate topic with separate message ID rules in this case. But a timestamp is probably acceptable?

I'm not sure how this relates to adversaries.

The broadcasted chain then may change to whatever proposal the instance is swayed.

I'd handle more than swaying here. E.g., we need to consider anything we try to commit to.

[masih]

Thanks Steven, the topic for publishing chain is already separated with its own id function.

[Stebalien]

Hm. Yeah, I guess that doesn't help because there's no way to specify different timed-cache timeouts on different topics...