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
Hotstuff and cerberus are message based protocols. Currently we implement a message protocol that requires nodes to connect to every other node in the local shard. For cross shard messaging, we implement a strategy that limits the number of messages sent but relies on multiple connections per peer across shards.
Proposal 1
Leverage libp2p's gossipsub for all consensus broadcasts to local/foreign shards.
At a high-level:
Each shard subscribes to their topic consensus-{start}-{end} (start and end are the start/end shards in the ShardGroup type) (see mempool gossip)
Ambient peer discovery required by gossipsub is already performed by the Tari-implemented peer sync protocol and L1 registrations
Peers maintain enough connections (recommended 4/5) to local nodes
Peers maintain at least one connection to each foreign shard
Investigate: do we have to implement points 3/4 or perhaps we can intelligently establish/select an existing connection when the message is sent or perhaps gossipsub can work out who to connect to for us?
cerberus assumes some form of reliable broadcast and a solution to the cluster-sending problem, I'm unsure if gossipsub fits this
Subscriptions to topics will need to be managed on epoch change and on validator node registration, this should happen outside of the consensus crate
NB: The output messaging trait should remain as is, except for broadcast, which can take in a shard group instead of individual VN public keys (this should save us some epoch manager calls!). Outbound broadcast will simply publish on the topic shard_group_to_topic(shard_group) -> String
The text was updated successfully, but these errors were encountered:
Problem
Hotstuff and cerberus are message based protocols. Currently we implement a message protocol that requires nodes to connect to every other node in the local shard. For cross shard messaging, we implement a strategy that limits the number of messages sent but relies on multiple connections per peer across shards.
Proposal 1
Leverage libp2p's gossipsub for all consensus broadcasts to local/foreign shards.
At a high-level:
consensus-{start}-{end}
(start and end are the start/end shards in the ShardGroup type) (see mempool gossip)Investigate: do we have to implement points 3/4 or perhaps we can intelligently establish/select an existing connection when the message is sent or perhaps gossipsub can work out who to connect to for us?
https://docs.libp2p.io/concepts/pubsub/overview/
**Notes: **
shard_group_to_topic(shard_group) -> String
The text was updated successfully, but these errors were encountered: