Verify all Round-Change messages and their nested prepare messages.
Take one of the highest prepared Round-Change messages and compare its data to the attached prepare messages
Now, we:
Verify all Round-Change messages without verifying their justifications.
Check if one of the highest-prepared Round-Change messages is in accordance with the attached prepare messages. To be "in accordance" means to have the same proposed data.
If a proposal has no prepared round-change messages but includes a justification of prepare messages, it will be accepted. This is due to the fact that, if there's no prepared round-change, the validation will return nil without checking the prepare messages. Should we add a check to ensure that the prepare messages should be empty in this case?
A correctly signed prepared round-change message without justification is:
valid if it's included in the justification of a proposal msg
invalid as a single RC message.
We could add a quorum check in the validation of the proposal justification, but what would be the point if we don't inspect the contents of the RC justification?
Performance implications
All times are in milliseconds.
Max processing time for the Proposal message
Round 1
Round 2
Round 3
Old
1.5
18
18
New
1.5
8
8
Max processing time for a consensus round
1st round
2nd round
3rd round
Old
13
64
64
New
13
44
44
The difference is 20ms (not 10ms as one could expect) because, once a quorum of Round-Change messages is received, the isReceivedProposalJustification function is called.
Namely, look at the break-down times of each phase for round 2:
Round-Changes
Proposal
Prepares
Commits
Old
4, 9, 21
18
1, 1, 1, 1
1, 1, 1, 1
New
4, 9, 11
8
1, 1, 1, 1
1, 1, 1, 1
Tests
In the following, we list existing and added tests for the proposal phase.
The existing tests are listed for one to check the test coverage.
Valid
Existing:
[x] Valid proposal for rounds 1 and 2 (with prepared data)
[x] Valid proposal for round 5 with no preparation
Overview
We changed the
isProposalJustification
function according to the QBFT formal specification (Audit suggestion 5).To compare the changes, follow up the QBFT formal spec isProposalJustification and validRoundChange functions.
Basically, we used to:
Now, we:
Dependency
This PR is built upon the Fix - Misaligned terms PR's branch.
Discussion topics
Performance implications
All times are in milliseconds.
Max processing time for the Proposal message
Max processing time for a consensus round
The difference is 20ms (not 10ms as one could expect) because, once a quorum of Round-Change messages is received, the
isReceivedProposalJustification
function is called.Namely, look at the break-down times of each phase for round 2:
Tests
In the following, we list existing and added tests for the proposal phase.
The existing tests are listed for one to check the test coverage.
Valid
Existing:
Proposal fields
Existing:
Added:
Message time or multiplicity
Existing:
Justification - Quorum checks
Existing:
Justification - Logic
Existing:
Added: