Current Implementation
The current implementation of the commit phase of Harmony’s consensus looks as follows:
After the prepare phase, validators send their commit message, along with signatures, to the network leader. As soon as quorum is met (i.e. leader has received ≥ 67% valid votes from the network), the leader the then calls preCommitAndPropose, which does the following:
- Commits the block with ≥ 67% commit signature
- Broadcasts
committedmessage with the above information - Starts async proposal of a new block, which will wait for the full commit signature
After the method is finished, the leader starts a grace period (currently set to 1 second). During this period, the leader waits for extra commit signatures from the network. Only after the 1 second, or 100% of votes have been collected, the leader will call finalCommit. Here, the leader saves / commits the block and finalizes the consensus.
The grace period allows signatures beyond 67% to be collected. However, this does introduce wait time, which can be prevented by the following proposal.
Proposal
Rather than waiting for grace period to end, the leader can finalize the block as soon as ≥ 67% of valid signatures have been collected. The signatures beyond the 67% can be collected in the next block header. This will require additional header fields (previous signatures and previous bitmap) and logic to collect those data in consensus. However, it will speed up the block finalizing process.
The grace period will remain in place for epoch blocks to avoid problems in epoch transition. (TODO)
Changes
Block Header
prevCommitSignatures: FBFT commit group signature for the second-to-last block.prevCommitBitmap: Signatory bitmap of the second-to-last block. Bit positions index into committee member array.
Consensus: Leader
onPrevCommit: Processes FBFT message containing the signature(s) for the previous block. The processed data will be stored in the current block header and
Consensus
- Grace period removal for the
commitphase afterFastCommitEpoch.
Reward
- Reward for previous commit signatures will be distributed (TODO)
Questions
Absence of gracer period introduce potential threats?
- No, because the grace period is only triggered after the 67% collection of commit signature. 67% signature collection guarantees security mesaures in Harmony protocol. By the time grace period is initiated, security measure for the current blocks is guaranteed.
Introducing new data to block header leads to different block size? Size difference?
Network transition to this mechanism?
- Hardfork required due to block structural change.
- The consensus process to validators should not be very different. Majority of the change will occur at the leader level.
Fallback mechanism
Blockchains need to be backward compatible
- In the codebase, the feature will only be enabled after
FastCommitEpoch. The existing logic will be in place so that in the previous epochs, the former logic is triggered.
Rollback plan (important)
Could there be a scenario where a malicious attacker submit batch transactions?
Grace Period: Buffer against malicious actors?
Different levels of latency for nodes / discrepancies
Security Measures; Potential Attacks?
??
Other Examples
- Ethereum?
- Elron?
- Binance?
- Near?