This PR aims to improve the Round-Change validation functions.
The reason is that, from benchmark tests, Round-Change message processing showed unexpectedly high latency. This performance hurdle comes from:
verifying already verified Prepare messages for the Round-Change message creation, after a partial quorum of Round-Change messages is received.
verifying already verified Prepare and Round-Change messages for the creation of Proposal messages after a quorum of Round-Change messages is received.
Changes
The validSignedPrepareForHeightRoundAndRoot function was refactored by the following way:
a new validPrepareForHeightRoundAndRoot function that performs all the message fields and logic checks.
validSignedPrepareForHeightRoundAndRoot now calls validPrepareForHeightRoundAndRoot and then, if there is no error, it verifies the signature.
getRoundChangeJustification, now, calls validPrepareForHeightRoundAndRoot to validate the Prepare messages (for a round and root) without verifying the signature.
Once a quorum of Round-Change messages is reached, the Proposal justification validation for the Proposal creation will not verify signatures (since container messages are already verified). This is accomplished by adding a flag verifySignatures to the isProposalJustification function. For received Proposal messages, the flag is set to true, and, for Proposal validation for creation, the flag is set to false.
The validRoundChangeForData function is refactored to validSignedRoundChangeForData.
A new validRoundChangeForData function is created with similar behavior to validSignedRoundChangeForData but without verifying signatures.
Performance Comparison
All times are in milliseconds.
Due to the change no. 2, we get the following Round-Change processing improvement:
1st
2nd
3rd (quorum)
Old
4.5
9.5
21.5
New
4.5
4.8
21.5
Due to the changes no. 2 and 3, we get the following Round-Change processing improvement:
Overview
This PR aims to improve the Round-Change validation functions.
The reason is that, from benchmark tests, Round-Change message processing showed unexpectedly high latency. This performance hurdle comes from:
Changes
validSignedPrepareForHeightRoundAndRoot
function was refactored by the following way:validPrepareForHeightRoundAndRoot
function that performs all the message fields and logic checks.validSignedPrepareForHeightRoundAndRoot
now callsvalidPrepareForHeightRoundAndRoot
and then, if there is no error, it verifies the signature.getRoundChangeJustification
, now, callsvalidPrepareForHeightRoundAndRoot
to validate the Prepare messages (for a round and root) without verifying the signature.verifySignatures
to theisProposalJustification
function. For received Proposal messages, the flag is set totrue
, and, for Proposal validation for creation, the flag is set tofalse
.validRoundChangeForData
function is refactored tovalidSignedRoundChangeForData
.validRoundChangeForData
function is created with similar behavior tovalidSignedRoundChangeForData
but without verifying signatures.Performance Comparison
All times are in milliseconds.
Due to the change no. 2, we get the following Round-Change processing improvement: