⚡

Fast Commit

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 committed message 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 commit phase after FastCommitEpoch.

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?

Tradeoff w/ Uncle Block