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

# Consensus and Block Production

## Purpose and Scope

This document describes the consensus mechanism and block production process of StableNet.\
It covers the Anzeon WBFT consensus protocol, the block production pipeline, validator management, and the application of the gas tip policy. For details on the validator governance contract, see [Validator Governance (GovValidator)](/en/governance-system/5.3-validator-governance-\(govvalidator\)). For transaction processing within a block, see [Transaction Processing](/en/transaction-processing/index).

## Consensus Architecture Overview

StableNet uses the **Anzeon WBFT** consensus engine, which is a Proof-of-Authority (PoA) variant of the Wemix Byzantine Fault Tolerance protocol.\
The consensus layer coordinates with the block production layer (Worker) to create, validate, and finalize blocks.

### System Components

## Anzeon WBFT Consensus Protocol

### Protocol Characteristics

Anzeon WBFT is the application of the WBFT consensus algorithm tailored for StableNet. Its key characteristics are as follows:

| Property             | Value                                    |
| -------------------- | ---------------------------------------- |
| **Type**             | Byzantine Fault Tolerant (BFT)           |
| **Model**            | Proof-of-Authority (PoA)                 |
| **Block Time**       | 1 second (configurable)                  |
| **Finality**         | Deterministic, immediate                 |
| **Signature Scheme** | BLS (Boneh–Lynn–Shacham)                 |
| **Fault Tolerance**  | Up to f = ⌊(n-1)/3⌋ Byzantine validators |
| **Epoch Length**     | 10 blocks (configurable)                 |

### Differences from Standard WBFT

Anzeon WBFT removes several features from the original WBFT implementation to align with StableNet’s stablecoin-oriented design.

**Key Modifications**

1. **No staking requirement**: Validators are managed purely through governance voting, without token deposits
2. **No block rewards**: Validators earn only transaction fees, preserving a 1:1 stablecoin peg
3. **Anzeon fork enabled**: Anzeon is active from the genesis block
4. **BLS key storage change**: Moved from the `GovStaking` contract to the `GovValidator` contract
5. **Removed governance contracts**: `GovStaking`, `GovConfig`, `GovNCP`, and `GovRewardeeImp` are not used

### Consensus Configuration

Anzeon configuration is defined in the genesis block.

**Configuration Structure**

* `anzeon.wbft`: Core consensus parameters (epoch length, block period, timeouts)
* `anzeon.init`: Initial validator set active during epoch 0
* `anzeon.systemContracts.govValidator`: Validator governance parameters, including the validator set from epoch 1 onward

**Important:** `init.validators` applies only to the first epoch.\
The `govValidator.validators` parameter defines the active validator set starting from epoch 1.

### Block Finalization Flow

WBFT consensus follows a two-phase commit protocol (PREPARE and COMMIT) with BLS signature aggregation for efficiency.\
A block is considered finalized and irreversible once `2f+1` validators (where `f` is the maximum number of tolerated Byzantine faults) have signed both phases.

## Block Production Pipeline

The Worker component ([`miner/worker.go`](https://github.com/stable-net/go-stablenet/blob/master/miner/worker.go)) is responsible for assembling and producing blocks.\
It coordinates transaction selection, state transitions, and integration with the consensus engine.

### Worker Architecture

### Worker Event Loop (WBFT Mode)

In WBFT mode, the worker uses a simplified event loop compared to standard Ethereum mining.

**Key Differences from Standard Mining**

1. **No periodic re-commit**: Standard Ethereum miners periodically rebuild blocks to include higher-fee transactions, whereas WBFT relies on consensus timing
2. **Consensus-driven timing**: The `readyToCommitCh` signal is emitted by the WBFT engine when it is time to produce a block
3. **Round-based**: Each consensus round triggers exactly one block production attempt

### Block Assembly Process

The `commitWork()` function orchestrates the entire block assembly process.

**Core Functions**

* **`commitWork(interrupt, timestamp)`**: Main coordinator, handles interrupt signals
* **`generateWork(params)`**: Builds the execution environment and state
* **`commitTransactions(txs, coinbase)`**: Applies transactions sequentially while respecting the gas limit
* **`commit(env, interval)`**: Submits work to the consensus engine for finalization

### Transaction Selection and Ordering

**Transaction Selection Algorithm**

1. **Fetch pending transactions**: Retrieve all transactions from the pool that satisfy the minimum gas tip requirement
2. **Local priority**: Local transactions are processed first
3. **Gas tip application**: In Anzeon mode, regular accounts must use the gas tip defined by `GovValidator`, while authorized accounts may specify a custom tip
4. **Nonce ordering**: Transactions must be processed sequentially by nonce within each account
5. **Price ordering**: Across accounts, transactions with higher effective gas prices have priority
6. **Gas limit enforcement**: Stop when the block gas limit is reached

### Gas Tip Management

StableNet’s gas tip policy is enforced through the Worker’s integration with the `GovValidator` contract.

**Implementation Details**

* **Initialization**: The Worker reads the gas tip from `GovValidator` during creation
* **Callback registration**: The blockchain registers `updateGasTipFromContract` as a callback after each block import
* **Synchronization**: The Worker’s internal `tip` field and the transaction pool’s minimum price are updated together
* **Lock-free updates**: The callback only updates state, avoiding lock contention with the Worker’s main loop

## Validator Management

### Key Management

StableNet validators use three keys for governance, block production, and consensus messaging.\
For detailed descriptions of each key’s role, usage, and derivation, see [Validator Operations](/en/operations-guide/11.2-validator-operations).

### Validator Registration and Rotation

**Validator Set Updates**

1. **Epoch blocks**: Validator set changes are applied only at epoch blocks
2. **Contract reads**: When producing an epoch block, the WBFT engine reads the current validator list from `GovValidator`
3. **Member versioning**: The `memberVersion` field tracks changes, and the WBFT engine detects updates by comparing versions
4. **Immediate effect**: Once a new epoch starts, the validator set remains fixed for the duration of that epoch

### Genesis vs Runtime Validator Sets

StableNet supports two validator set specifications in its genesis configuration.

**Important Configuration Notes**

* **Epoch 0**: The validator set active from block 1 to the first epoch block is defined by `anzeon.init.validators`
* **Epoch 1+**: From block `epochLength + 1`, the validator set is read from the `validators` parameter of the `GovValidator` contract
* **Best practice**: Unless a controlled validator migration is intended, these two lists should be identical

## Integration Points

### Worker–WBFT Integration

The Worker and the WBFT engine coordinate through a callback-based mechanism.

**Code Flow**

1. **Startup**: `eth.StartMining()` calls `miner.Start()`, which invokes `worker.start()`
2. **Engine start**: `worker.start()` calls `wbftEngine.Start()` with the `readyToCommit` callback
3. **Consensus trigger**: When the WBFT core determines it is time to propose a block, it calls `readyToCommit(round)`
4. **Block creation**: The callback signals `readyToCommitCh`, triggering `commitWork()`
5. **Sealing**: The assembled block is sent to `engine.Seal()` for consensus processing

### Miner Initialization

The miner is initialized during Ethereum backend setup.

**Anzeon-Specific Settings**

* **Forced etherbase**: In Anzeon mode, the etherbase is automatically set to the node key–derived address and cannot be configured by the user
* **Gas tip initialization**: The Worker reads the initial gas tip from `GovValidator` during configuration

## Summary

StableNet’s consensus and block production system has the following characteristics:

1. **Deterministic finality**: Anzeon WBFT provides immediate, irreversible finality through BFT consensus
2. **Governance-driven validators**: Validator sets are fully managed by on-chain governance via the `GovValidator` contract
3. **Stablecoin-aligned economics**: No block rewards, no token burning, validators earn only transaction fees
4. **Dynamic gas tip policy**: Network-wide gas tips enforced and automatically updated by `GovValidator`
5. **Key security model**: Separation of governance, block production, and consensus signing keys
6. **Epoch-based rotation**: Validator set changes are applied only at epoch blocks for stability

The Worker component acts as the central coordinator, integrating transaction pool management, state transitions, consensus engine interaction, and governance policy enforcement into a consistent block production pipeline.