# 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.

<div data-full-width="false"><figure><img src="/files/v2pJwQPSCrZbxQiAw1nX" alt=""><figcaption></figcaption></figure></div>

### 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.&#x20;

<figure><img src="/files/pPSoCOGzaZexT62WcfvS" alt=""><figcaption></figcaption></figure>

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.&#x20;

{% hint style="success" %}
The minimum stake needed to pass any *Vote* phase is +⅔ of the voting power.
{% endhint %}

**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.

<figure><img src="/files/7ekxPsuxuIm0UAjDFIvl" alt=""><figcaption></figcaption></figure>

**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.

<figure><img src="/files/AWZoOgYJXItSurkgEVsU" alt=""><figcaption></figcaption></figure>

**Propose:** *Leader proposes a block with a justification and sends it to the* Replica&#x73;*.*

* 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.

<figure><img src="/files/VZ0QOBf6biYXNQy8aj0b" alt=""><figcaption></figcaption></figure>

**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.

<figure><img src="/files/tLY9ioYRoHzZbCsm2Lne" alt=""><figcaption></figcaption></figure>

**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.

<figure><img src="/files/4tP2RzHNMdaLKqJg5USJ" alt=""><figcaption></figcaption></figure>

**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.

<figure><img src="/files/aiPXIkepO85YwBBQMRJO" alt=""><figcaption></figcaption></figure>

**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.

<figure><img src="/files/NmIrMDRJlwGaiBzdN0gq" alt=""><figcaption></figcaption></figure>

**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.

<figure><img src="/files/n4UMiz1U51YZGwZD9syr" alt=""><figcaption></figcaption></figure>

On phase failure, the following recovery phases occur:

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

* Replica sends their current view to other replicas.

<figure><img src="/files/EYWLWZYV4YnI2817Tfy6" alt=""><figcaption></figcaption></figure>

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

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

{% hint style="info" %}
Each round, phase\_time is doubled to ensure communication overlap of async nodes.
{% endhint %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://canopy-network.gitbook.io/docs/canopy-network/how-does-canopy-work/consensus.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.