Pass MessageID To Broadcast

[olegshmuelov]

Overview

This PR is a follow up for #372.

Changes

• Pass message ID to broadcast

[GalRogozinski]

I am thinking about this further now...
you only need the ValidatorPublicKey?
So maybe it is best to simply pass recipientID []byte parameter for topic.

This is because in the very near future (cluster-based consensus), we will be using ClusterID exclusively for topic calculation (at least this is the current plan), while it may not necessarily be in the MessageID (duty dependent). So my offer will save a future change...

Your choice whether you want to change it now of course

[y0sher]

I think Gal's point is valid though, if we can make it thinner and just pass validator pubkey then maybe it's better.

[moshe-blox]

@GalRogozinski @y0sher
imo consensus should make the least amount of assumptions on how p2p works
passing only 'recipient' means consensus assumes subnets are by cluster id or validator pk
but what if p2p wants to determine subnet by role + recipient?

either way is fine for now, just noting the difference between the two

[GalRogozinski]

@moshe-blox
recipient is a general term that can be passed with no assumption...
It could be that the messageID won't have the necessary information for the topic

[moshe-blox]

@GalRogozinski how so? i thought that MessageID can contain in it either the cluster id or the validator pk (if its a block proposal for example)

sure, it makes sense if it's a []byte named recipient instead and as long as it's not spec-tested then the implementation is free to pass whatever it wants there

[GalRogozinski]

@moshe-blox
Let say we decide to calculate all topics only with cluster_id%128, and for each validator we find the cluster it belongs to (current proposal)

then in this case if you pass only validator pk MessageID won't have enough information

[moshe-blox]

@GalRogozinski it's an implementation problem no? we're going to maintain mappings between cluster ids and validators so it's shouldn't be an issue