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). For transaction processing within a block, see Transaction Processing.

​

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:

​

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

​

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.