Consensus

Introduction

NestBFT is an innovative consensus algorithm developed to withstand grinding attacks while mitigating the risks of DDoS and long-range attacks. NestBFT is engineered with a novel pacemaker mechanism to address validator coordination challenges, while offering immediate safety and finality.

➣ The protocol is optimized to be highly efficient, using BLS multi-signature aggregation for O(1) space complexity while utilizing a star communication pattern to maintain linear communication complexity. This design aims to be intuitive and straightforward to implement, as Canopy employs NestBFT for both the Root Chain and Nested Chain layers.

Leader Election

NestBFT uses a DDoS-resistant, highly available leader election algorithm designed to be immune to grinding attacks. Inspired by Algorand’s Sortition, it uses a Practical VRF - where validators sign seed data to create a unique ‘VRFOut’ each consensus round.

➜ Unlike many protocols that rely on manipulable inputs like the last block hash, NestBFT’s method avoids grindable bias, ensuring leader selection remains fair and unpredictable. By focusing on simplicity and strong cryptography, the protocol strengthens security and resilience in decentralized systems, protecting against both DDoS and grinding threats.

Proof of Age

NestBFT strives to further eliminate reliance on centralized sources and social consensus by offering a novel approach to fork choice. Given that the VDF primitive is a reliable proxy for elapsed time and is fundamentally resistant to specialized hardware, NestBFT employs a Verifiable Delay Function to ensure that the addition of each block to the chain is temporally consistent.

By requiring a sequential proof of elapsed time in each block, the recreation of the blockchain by a long-range attacker is infeasible, as it would require both significant computational resources and time to reconstruct a chain that is longer than the network.

💡 Here’s how it works: each validator replica runs a VDF for just under the expected block time with seed data from the most recent block. The VDFs are aggregated by the block producer during NestBFT and the VDF with the highest number of iterations is included in the proposal block. This design ensures the network gets the hardware benefit (if any) of the most computationally strong node in the network.

BFT Phases

The consensus process of NestBFT is broken down into 8 core phases and 2 recovery phases. Each phase represents the smallest unit in the consensus process. Each round consists of multiple phases, and each height may consist of multiple rounds. These phases are executed sequentially to achieve consensus on the next block.

The minimum stake needed to pass any Vote phase is +⅔ of the voting power.

Election: Replicas self-determine if they are a Leader candidate.

• Each Replica runs a Practical Verifiable Random Function (pVRF):

  pVRF = Hash(BLS.Signature(Last Proposers Addresses + RootHeight + Height + Round))

• Each Replica calculates a candidacy cutoff point based on their stake (more stake = higher chance of being a Candidate).

• If a Replica's VRF output is below the candidacy_cutoff they are a Leader Candidate.

• Candidates send a proof of their candidacy to the Replicas.

Election Vote: Replicas send a vote to the Leader.

• Each Replicas votes for who they believe the is the leader:

  Leader = candidate with the smallest H where H = Hash(Candidate_VRF_OUT)

• If no candidates exist, the process falls back to a stake-weighted-pseudorandom selection algorithm.

Propose: Leader proposes a block with a justification and sends it to the Replicas.

• Determines the 'Lock' with the highest round if one exists.

• If a Lock exists, use that as the proposal - if not, the Leader produces a new proposal.

• Creates a justification by aggregating the votes from the Replicas to form a +⅔ threshold multi-signature.

Propose Vote: Replicas validate the proposal and send a vote to the Leader.

• Replica reviews the message from the Leader by validating the justification (+⅔ multi-sig) proving that they are in-fact the leader

• If the Replica is currently Locked on a previous Proposal for this Height, the new Proposal must either be that 'Lock' or has a +⅔ multi-sig from a higher round.

• Replica Validates the proposal by playing each transaction against the state machine.

Precommit: Leader creates and sends a 'Locking' justification to the Replicas for the Proposal.

• Creates a justification by aggregating the votes from the Replicas to form a +⅔ threshold multi-signature.

Precommit Vote: Replicas Lock on the proposal and send a vote to the Leader.

• Replica reviews the message from the Leader by validating the justification (+⅔ multi-sig) justifying enough of Replicas approved the Proposal.

• Replica Lock on the Proposal to protect those who may commit.

Commit: Leader creates and sends a 'Commit' justification to the Replicas for the Proposal.

• Creates a justification by aggregating the votes from the Replicas to form a +⅔ threshold multi-signature.

Commit Process: Replicas commit and gossip the block.

• Replica reviews the message from the Leader by validating the justification (+⅔ multi-sig) justifying enough of Replicas are locked on the Proposal.

• Replica commits the block to finality.

• Replica gossips the block to peers.

On phase failure - the following recovery phases occur:

⚠️ Round Interrupt (Recovery): Replicas gossip their current round.

• Replica sends their current view to other replicas.

⚠️ Pacemaker (Recovery): Replicas jump to the highest safe round to resolve async round issues.

• Replicas fast-forward to the highest round +⅓ have seen.

Each round, phase_time is doubled to ensure communication overlap of async nodes.