Follow up from #1066, this PR adding the quorum certificate into the prepare and deliver abci.
In prepare, it will first check if a quorum is formed. Previous only the parent block height and hash is returned from the vote tally, now the block height, block hash and side effects commitment is returned in a struct: TopdownVote together with the QuorumCertificate. The quorum certificate is the aggregated signatures of voted validator.
Do note that only the bitmap of the voted validators are returned, the validators are sorted by power and then byte order of their public key.
The process method will then check if in cache to see if the the current node will create the same topdown vote that matches with the TopdownVote received. If they are the same, it means the local proposal is the same as that in the validator quorum, it will create a TopdownProposalWIthQuorum. Else, it means the local node has data that is not the same as that of the validators quorum. The validator will give up the chance to include a topdown proposal and let other node do it.
For deliver, it will just extract the topdown messages and validator changes and commit them, just like before. Just without the RPC queries.
[x] Add process to validate the quorum signatures, #1070
A limitation with existing approach is still ECDSA based signature aggregation algorithm, it will not scale with more validators. A todo is added in the code base to look into Schnorr scheme.
Follow up from #1066, this PR adding the quorum certificate into the
prepareanddeliverabci.In
prepare, it will first check if a quorum is formed. Previous only the parent block height and hash is returned from the vote tally, now the block height, block hash and side effects commitment is returned in a struct:TopdownVotetogether with theQuorumCertificate. The quorum certificate is the aggregated signatures of voted validator.Do note that only the bitmap of the voted validators are returned, the validators are sorted by power and then byte order of their public key.
The
processmethod will then check if in cache to see if the the current node will create the same topdown vote that matches with theTopdownVotereceived. If they are the same, it means the local proposal is the same as that in the validator quorum, it will create aTopdownProposalWIthQuorum. Else, it means the local node has data that is not the same as that of the validators quorum. The validator will give up the chance to include a topdown proposal and let other node do it.For
deliver, it will just extract the topdown messages and validator changes and commit them, just like before. Just without the RPC queries.processto validate the quorum signatures, #1070A limitation with existing approach is still ECDSA based signature aggregation algorithm, it will not scale with more validators. A
todois added in the code base to look intoSchnorrscheme.