Operations Guide

​

Purpose and Scope

​

Network Deployment

​

Genesis File Creation

​

Genesis Configuration Parameters

​

System Contract Initialization

• members: Comma-separated list of operator addresses
• validators: Comma-separated list of validator addresses
• blsPublicKeys: List of validator BLS public keys (same order as validators)
• quorum: Minimum number of votes required to approve governance actions
• expiry: Governance proposal expiration time (seconds, default: 604800 = 7 days)
• gasTip: Gas tip applied to transactions from non-authorized accounts (wei)

• name: Native token name (e.g. "WKRC")
• symbol: Native token symbol (e.g. "WKRC")
• decimals: Token decimals (typically 18)
• currency: Pegged fiat currency code (e.g. "KRW")
• masterMinter: GovMasterMinter contract address
• minters: Comma-separated list of contracts with minting authority

​

Bootnode Configuration

--bootnodes enode://722f1f35c6fe2ac829aa9e0d7ef55bbe782ef3cea1e2354eefbe1584057a01b7@127.0.0.1:8589,enode://aa46e4a40781022e480bb05d1fd578fff164dc2ad379dc00370456c5ce9c2479@127.0.0.1:8589

1. Explicitly specified via the --bootnodes flag
2. BootstrapNodes defined in the configuration file
3. Network preset flags (--mainnet, --testnet)
4. Default mainnet bootnode configuration

​

Network Flags and Configuration

​

Validator Operations

​

Validator Key Structure

​

Key Generation and Management

​

ECDSA Keys

# Generate operator key (for governance)
gstable account new --datadir /data/validator1

# Generate validator key (for block signing)
gstable account new --datadir /data/validator1 --keystore /data/validator1/validator-keystore

# Import an existing private key
gstable account import private.key --datadir /data/validator1

​

BLS Key Derivation

// Derive a BLS key from an ECDSA private key
blsKey, err := bls.DeriveFromECDSA(ecdsaPrivateKey)
if err != nil {
    log.Fatal("Failed to derive BLS key", "err", err)
}
blsPublicKey := blsKey.PublicKey()

​

Validator Registration

​

Starting a Validator Node

gstable \
    --datadir /data/validator1 \
    --networkid 8282 \
    --mine \
    --miner.etherbase 0xYOUR_VALIDATOR_ADDRESS

​

Validator Mining Process

1. Load validator state
   • Load the registered validator set from genesis and the latest chain state via GovValidator.
   • Verify that the node’s etherbase is part of the active validator set.
2. Validate validator keys
   • Ensure the address derived from the signing key matches the etherbase address.
   • Verify that the corresponding BLS public key is correctly registered in GovValidator.blsPublicKeys.
3. Initialize the WBFT consensus engine
   • Load Anzeon WBFT parameters (epoch length, block period, timeout, etc.) from genesis.
   • Apply the WBFT configuration for the current block height.
4. Determine validator role
   • Decide whether the node is the proposer for the current round based on the proposer policy.
   • If selected as proposer, prepare a block proposal.
5. Start consensus message handling
   • Activate network handlers for consensus messages.
   • Initialize signing and verification logic for each consensus phase, including BLS signature aggregation.
6. Block production and consensus participation
   • If proposer, propose a block including WBFTExtra.
   • If not proposer, validate the proposed block and broadcast signed messages according to the consensus phase.

​

Gas Tip Policy

​

Authorized Accounts

• Per-transaction gas tip configuration
• The specified maxPriorityFeePerGas is applied as-is
• Competitive prioritization during congestion
• Not subject to the fixed gas tip policy defined by governance

​

Non-Authorized Accounts

• Regardless of the transaction’s maxPriorityFeePerGas, the fixed gas tip defined by governance is applied
• The transaction-specified gas tip is used only for transaction replacement logic
• Transactions below the fixed gas tip are filtered out by the transaction pool

​

Gas Tip Updates

• Validators may propose updates to the fixed gas tip via governance proposals
• Proposals require quorum approval and are applied immediately upon execution

​

Epoch Transitions

• Epoch length is configured via anzeon.wbft.epochLength (default: 10 blocks)
• Validator set changes approved during epoch N become active at the start of epoch N+1
• The first epoch uses the validator set defined in anzeon.init.validators
• Subsequent epochs load validator sets from GovValidator.validators

​

Governance Participation

​

Proposal Types

• ADD_VALIDATOR: Add a new validator to the set
• REMOVE_VALIDATOR: Remove an existing validator
• SET_GAS_TIP: Update the mandatory gas tip value
• CONFIGURE_SYSTEM: Update system parameters and configuration

​

Voting Process

• Any governance member can submit a proposal via a contract call
• Other members vote using vote(proposalId, approve)
• Proposals are executed automatically upon reaching quorum
• Proposals expire after the configured expiry period (default: 7 days)

​

Node Monitoring and Maintenance

​

Logging Configuration

# Set global log level
gstable --verbosity 3  # 0=silent, 1=error, 2=warn, 3=info, 4=debug, 5=trace

# Module-specific log levels
gstable --vmodule "consensus/*=5,miner=4,eth/*=3"

# File logging and rotation
gstable --log.file /var/log/gstable/node.log --log.rotate

# JSON-formatted logs for log aggregation
gstable --log.json

​

Metrics and Monitoring

# Enable metrics server
gstable --metrics --metrics.addr 0.0.0.0 --metrics.port 6060

# Enable InfluxDB metrics export
gstable \
    --metrics.influxdb \
    --metrics.influxdb.endpoint http://influxdb:8086 \
    --metrics.influxdb.database gstable \
    --metrics.influxdb.username monitor \
    --metrics.influxdb.password secret

​

Disk Space Management

​

Minimum Free Disk Space

# Set minimum free disk space (in MB)
gstable --datadir.minfreedisk 50000  # Shutdown if free space drops below 50 GB

​

Database Size Monitoring

• chaindata/: Main blockchain state and block database
• ancient/: Freezer directory for old blocks (if configured separately)
• blobpool/: Blob transaction pool data
• ethash/: DAG storage (if Ethash consensus is used)

​

Pruning and Garbage Collection

# Archive mode (no pruning)
gstable --gcmode archive --cache.gc 0

# Full mode (pruning enabled)
gstable --gcmode full --cache.gc 25  # Use 25% of cache for GC

​

Database Maintenance

​

State Scheme Selection

# Hash-based scheme (traditional)
gstable --state.scheme hash

# Path-based scheme (recommended for new nodes)
gstable --state.scheme path

• Automatic state pruning
• Lower disk usage
• Improved synchronization performance

• Mature and well-tested
• Manual control over pruning and garbage collection
• Suitable for environments requiring offline pruning tools

​

Offline Pruning Recovery

// Automatic recovery at startup
if scheme == rawdb.HashScheme {
    if err := pruner.RecoverPruning(stack.ResolvePath(""), chainDb); err != nil {
        log.Error("Failed to recover state", "error", err)
    }
}

​

Chain Recovery and SetHead

# Roll back to a specific block number
gstable attach /data/gstable.ipc --exec 'debug.setHead("0x10000")'  # Move to block 65536

# Roll back by number of blocks
gstable attach /data/gstable.ipc --exec 'debug.setHead("0x-100")'  # Move back 256 blocks

• Recovery from corrupted block data
• Rolling back after detecting chain anomalies
• Rebuilding the chain on the correct fork after a network split

​

Node Upgrade Procedure

1. Stop the node
   • Gracefully shut down the running gstable process.
2. Replace binaries
   • Back up the existing binary and replace it with the new version.
   • Verify execution permissions and binary paths.
3. Review configuration files
   • Check for new or modified configuration options in the new version.
   • Ensure compatibility with existing configuration files.
4. Restart the node
   • Restart the node with the same options.
   • For validator nodes, ensure the --mine flag is included.
5. Inspect initial logs
   • Review startup logs for database migrations, consensus initialization, and network connectivity issues.

• Review release notes for breaking changes
• Back up the database (chaindata/ directory)
• Test the upgrade on non-critical nodes first
• For validator nodes, announce planned downtime to peers in advance

# Check node version
gstable version

# Check database version
gstable --datadir /data version-check

# Check synchronization status
gstable attach --exec 'eth.syncing'

# Check peer connectivity
gstable attach --exec 'admin.peers.length'

# For validator nodes, check mining status
gstable attach --exec 'eth.mining'

​

Abnormal Shutdown Detection

​

Abnormal Shutdown Handling

• On startup, LevelDB WAL (Write-Ahead Log) is used to recover incomplete writes
• Consistency between state database, snapshots, and ancient data is verified
• If consistency cannot be restored automatically, resynchronization or state reconstruction may be triggered

# Verify database integrity
gstable --datadir /data verify-db

# Rebuild indexes if necessary
gstable --datadir /data rebuild-indexes

​

Bootnode Operations

# Generate bootnode key
bootnode --genkey=boot.key

# Run the bootnode
bootnode \
    --nodekey=boot.key \
    --addr=:30303 \
    --netrestrict=0.0.0.0/0 \
    --verbosity=3

# Print enode URL
bootnode --nodekey=boot.key --writeaddress

gstable --bootnodes enode://[nodekey-pubkey]@[ip]:30303

​

Network Monitoring Dashboard