> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stablenet.network/llms.txt
> Use this file to discover all available pages before exploring further.

# Anzeon WBFT Consensus Protocol

## Purpose and Scope

This document provides an in-depth technical description of the Anzeon WBFT consensus protocol used in StableNet.\
It covers the Byzantine fault tolerance mechanism, epoch-based validator management, BLS signature aggregation, block production integration, and the relationships between consensus components and system contracts.

For information on validator set management through governance and voting, see [Validator Governance (GovValidator)](/en/governance-system/5.3-validator-governance-\(govvalidator\)).\
For details on block production and transaction selection, refer to [Block Production and Mining](/en/consensus-and-block-production/4.2-block-production-and-mining).

## Overview

Anzeon WBFT is a specialized variant of the WEMIX Byzantine Fault Tolerance (WBFT) consensus engine, adapted to StableNet’s Proof-of-Authority architecture.\
WBFT is an evolution of QBFT (Quorum Byzantine Fault Tolerance) that preserves Byzantine fault tolerance while providing scalability tailored to operational environments.

### Relationship Between WBFT and QBFT

| Protocol        | Characteristics                                          | Target Network           |
| --------------- | -------------------------------------------------------- | ------------------------ |
| **QBFT**        | Base BFT, permissioned validators                        | Private / PoA networks   |
| **WBFT**        | QBFT + staking + diligence + slashing                    | Public / Hybrid networks |
| **Anzeon WBFT** | WBFT with staking and rewards removed, optimized for PoA | StableNet                |

### Key Modifications in Anzeon WBFT

Anzeon WBFT removes or simplifies the following elements from standard WBFT to align with StableNet’s stablecoin-oriented design.

* **Removal of staking mechanism**: Validator eligibility is determined through GovValidator governance, not token staking
* **Removal of block rewards**: No new token issuance; validators earn only transaction fees
* **Removal of legacy WPoA**: Uses a pure WBFT engine without backward compatibility layers
* **Diligence-based rewards**: BaseFee is distributed to validators based on diligence metrics
* **Governance-driven configuration**: Validator sets and gas tips are managed by system contracts

### Consensus Properties

| Property                      | Value                                              |
| ----------------------------- | -------------------------------------------------- |
| **Byzantine Fault Tolerance** | Tolerates up to f = ⌊(n-1)/3⌋ Byzantine validators |
| **Finality**                  | Immediate (final), no rollback                     |
| **Block Time**                | Configurable, default 1 second                     |
| **Epoch Length**              | Configurable, default 10 blocks                    |
| **Signature Scheme**          | BLS12-381 aggregated signatures                    |
| **Proposer Selection**        | Default round-robin, configurable                  |

## Configuration and Initialization

### AnzeonConfig Structure

The `AnzeonConfig` structure in the chain configuration defines all parameters required for WBFT consensus.

#### WBFT Configuration Fields

| Field                      | Type      | Description                     |
| -------------------------- | --------- | ------------------------------- |
| `EpochLength`              | `uint64`  | Number of blocks per epoch      |
| `BlockPeriodSeconds`       | `uint64`  | Target time between blocks      |
| `RequestTimeoutSeconds`    | `uint64`  | Initial consensus round timeout |
| `MaxRequestTimeoutSeconds` | `*uint64` | Maximum timeout value           |
| `ProposerPolicy`           | `*uint64` | Proposer selection policy       |

#### Init Configuration

The `Init` section defines the initial validator set active during the first epoch.\
This set applies from block 1 through the first epoch block; afterward, the validator set managed by the GovValidator contract is used.

### Genesis Configuration Example

The initial validator set and WBFT parameters must be explicitly included in the genesis block, and responsibility for validator management is transferred to GovValidator after epoch 1.

## Consensus Architecture

### Rounds and Epochs

Anzeon WBFT divides the consensus process into two layers: **epochs** and **rounds**.

An **epoch** consists of a fixed number of blocks, and validator set changes are only allowed at epoch blocks.\
A **round** represents a single attempt to reach consensus for a given block; if it fails, the protocol transitions to the next round with an increased timeout.

### Block Period and Timeouts

| Timer                      | Purpose                   |
| -------------------------- | ------------------------- |
| `BlockPeriodSeconds`       | Block production interval |
| `RequestTimeoutSeconds`    | Initial consensus timeout |
| `MaxRequestTimeoutSeconds` | Maximum timeout           |

Timeouts increase exponentially as rounds progress and never exceed the configured maximum.

## Byzantine Fault Tolerance Mechanism

Anzeon WBFT uses a two-phase commit protocol consisting of PREPARE and COMMIT phases, leveraging BLS signature aggregation in each phase.

### BLS Signature Aggregation

BLS aggregated signatures combine signatures from multiple validators into a single signature, significantly reducing network overhead and verification cost.

* Reduced signature size
* Single verification operation
* Safety guaranteed with 2f+1 signatures

### Quorum Requirements

With n validators and f = ⌊(n-1)/3⌋ tolerated Byzantine validators, the required number of signatures is as follows:

| Phase       | Quorum Size |
| ----------- | ----------- |
| **PREPARE** | 2f + 1      |
| **COMMIT**  | 2f + 1      |

## Validator Set Management

### EpochInfo Structure

`EpochInfo` contains the validator set information valid for a specific epoch and is encoded in the `WBFTExtra` field of the block header.

### Epoch Transition Process

The following steps are performed during an epoch transition:

1. Check whether the current block is an epoch block
2. Retrieve the latest validator list from the GovValidator contract
3. Construct a new EpochInfo
4. Embed it in the first block header of the epoch
5. Activate the new validator set

## Block Production Integration

Unlike standard Ethereum consensus, Anzeon WBFT triggers the worker through the consensus engine.

### WBFT Worker Loop

In WBFT mode, block production is initiated only through the `readyToCommitCh` event, and periodic recommit is not performed.

| Aspect  | Standard Mining | WBFT Mining           |
| ------- | --------------- | --------------------- |
| Trigger | Timer-based     | Consensus event-based |
| Seal    | Asynchronous    | Synchronous (BFT)     |
| Reorg   | Allowed         | Restricted            |

### Gas Tip Updates

After each block, the worker queries the GovValidator contract to synchronize the network-wide gas tip and update transaction pool filtering criteria.

## Block Header Extra Data

### WBFTExtra Structure

WBFT-related metadata and signatures are RLP-encoded and stored in the `Extra` field of the block header.

| Field         | Genesis | Creation | PREPARE | COMMIT | Final |
| ------------- | ------- | -------- | ------- | ------ | ----- |
| VanityData    | ✓       | ✓        | ✓       | ✓      | ✓     |
| Round         | 0       | Set      | ✓       | ✓      | ✓     |
| EpochInfo     | ✓       | Boundary | ✓       | ✓      | ✓     |
| GasTip        | ✓       | ✓        | ✓       | ✓      | ✓     |
| PreparedSeal  | Empty   | Empty    | Set     | ✓      | ✓     |
| CommittedSeal | Empty   | Empty    | Empty   | Set    | ✓     |

## Protocol Messages

WBFT uses the following message types to reach block consensus:

| Message      | Purpose                    |
| ------------ | -------------------------- |
| PREPARE      | Block proposal             |
| PREPARE-VOTE | Proposal approval          |
| COMMIT       | Prepared block propagation |
| COMMIT-VOTE  | Final approval             |
| ROUND-CHANGE | Request round transition   |

## Architecture Summary

Anzeon WBFT has a tightly integrated architecture involving genesis configuration, the consensus engine, the worker, and system contracts.

1. Consensus parameters and initial validators are defined in the genesis
2. The consensus engine controls block production by the worker
3. Consensus results and validator information are encoded in the block header
4. Validator sets are updated via GovValidator at epoch blocks
5. Gas tip policies are immediately reflected in transaction processing