Hi team, following up the recent post mortem :
i have a few question regarding epoch change and consensus :
To solve the issue, we can add a dictionary with key is viewID (uint64) and value will be the aggregated signatures and bitmap. In this case, whenever one of the viewID (the majority of viewchanging id in the network) has enough M3 type signature (i.e the number of the signature on the same viewID exceeds ⅔ of the network), it can propose new view message and delete all the cached dictionary.
Question on the above (and sorry in advance if this is just some misunderstanding on how everything work) :
- So are we saying the solution is for the leader to store/aggregate the signature per viewID received from the validators and use the viewID that has the M3 type of signature first ? If yes, then wouldn’t we run into a risk where there would always be some validator not in sync, since there are no action to make sure all validator are on the same viewID level
- How a validator can even have a different view ID ? wouldn’t the view ID and the block added to the blockchain kind of follow each other since one view is to be used to sign a new block to be added to the chain
- if different view ID really happened, should we force the shard to at least make sure they are all in sync and at the same level before continuing ? that could be done at each epoch change for instance