feat: ChonkyBFT types #209
Conversation
|
I still need to add tests for some new error types that I introduced. |
|
Please do not remove the fastest hotstuff logic, we need both to coexist for the time of the migration. |
|
Why do we need the old logic? |
|
for transition? |
|
But as I've wrote in the description, the change is backwards compatible for ENs. And we only have one validator, so it doesn't need to be backwards compatible for validators. Unless I'm missing something here, it seems like it should work. |
| /// A timeout QC is just a collection of timeout votes (with at least | ||
| /// QUORUM_WEIGHT) for the previous view. Unlike with the Commit QC, | ||
| /// timeout votes don't need to be identical. | ||
| /// The first proposal, for view 0, will always be a timeout. |
There was a problem hiding this comment.
I think it is in fact a good idea to make view 0 always time out, as this will be the initial synchronization point of the consensus. However please make sure that this doesn't create an artificial delay - i.e. validators should immediately cast timeout vote for view 0 on startup, rather than waiting for the actual timeout delay.
Implemented all types for ChonkyBFT. Work on this is all on the roles crate. Tests in roles crate are passing. Note that I'm not keeping the old types, that's because
ReplicaCommithas no changes to it (I checked and serialization is the same for old and new, old signatures still work) as well asCommitQCandFinalBlock. Any type that an EN could receive, or that ends on our database, doesn't suffer any alterations. So it seems that the upgrade to ChonkyBFT is backwards-compatible for ENs. Since we only have one validator, we can upgrade the whole network without a planned hard fork.Part of BFT-452