aere-research/aips/AIP-3.md

AIP-3: Sub-Second Block Period (500 ms QBFT)

Preamble

Field	Value
AIP	3
Title	Sub-Second Block Period (500 ms QBFT)
Author	AERE Foundation
Type	Standards Track
Category	Core
Status	Final
Created	2026-07-11
Requires	None
Ratification	Foundation-ratified (pre-decentralization)

Abstract

This AIP documents the mid-chain transition of AERE's block period from one second to 500 milliseconds, performed as a QBFT configuration transition rather than a chain restart, so that all history, state, and validator keys were preserved. It is a retro-filed record of a change that is already live on chain 2800.

Motivation

AERE targets settlement-grade latency. A one-second block period puts a hard floor of about one second on inclusion latency and worst-case finality. Halving the block period to 500 ms roughly halves both, which materially improves the feel of interactive flows (swaps, payments, wallet confirmations) without any change to the EVM or to application code.

The change had to be done without re-genesising the chain. AERE had already been forced through one full re-genesis (genesis-v2 on 2026-05-07), and losing history again was not acceptable. QBFT supports timed configuration transitions, so the block period could be reduced at a scheduled block with continuity of state and validator identity.

Specification

Mechanism

Hyperledger Besu QBFT reads the block period from the genesis QBFT config and supports scheduled overrides via a transitions block. The transition key is xblockperiodmilliseconds (note: milliseconds, not the seconds-based blockperiodseconds used for the initial value). The correct, and easily mis-typed, form is:

{
  "config": {
    "qbft": {
      "blockperiodseconds": 1,
      "transitions": {
        "qbft": [
          { "block": 2138451, "xblockperiodmilliseconds": 500 }
        ]
      }
    }
  }
}

Activation

The 500 ms period activated at block 2,138,451 on chain 2800. Before that block the network produced one-second blocks; from that block onward it produces 500 ms blocks. State, account balances, contract code, and the validator set were unchanged across the transition.

Operational note for fresh nodes

A node synced from genesis against this config applies the transition automatically. A brand-new isolated chain started from a config like this needs --sync-min-peers=1 to begin producing, which is an operational detail of bootstrapping, not part of the consensus rule.

Rationale

A configuration transition was chosen over a re-genesis because it preserves the chain's entire history and, critically, the validator keys and account state. Re-genesis was rejected: it destroys history and forces every integrator to re-point. QBFT's timed transition is purpose-built for exactly this kind of parameter change and avoids a client fork.

500 ms was chosen as a conservative first step below one second. It roughly halves latency while staying comfortably within what a small, low-latency, Foundation-operated validator set can sustain. Going lower (for example 250 ms or 100 ms) is possible in principle but was deliberately not attempted here, because tighter periods increase the rate of missed-proposal rounds and stress peer-to-peer timing, and there is no need to push that limit with the current validator topology.

Backwards Compatibility

None at the application layer. Block time is not part of the EVM; contracts do not observe it directly. Note the second-order effect: any code that assumed a one-second block period to convert block counts to wall-clock time (for example a naive per-block reward constant) is now wrong by 2x. AERE hit exactly this: the original staking contract computed rewards against a hardcoded blocks-per-year constant and under-paid once blocks sped up. That was fixed in AereStakingV2 (0x1D95eF6D17aeAB732dF914Ba2d018c270BC155FC) by moving reward accrual to timestamps, which is block-time-immune. New code MUST use block.timestamp, not block height, for wall-clock math.

Security Considerations

Reducing the block period narrows the timing margin for each consensus round. With the current seven validators under a single operator this is low-risk because network latency between the nodes is small and predictable, and QBFT finalizes within the round among a small set. The honest caveats:

• Small, single-operator validator set. Sub-second finality here is a property of a seven-node, one-operator topology, not of a large decentralized set. It should not be read as a claim about behavior under a geographically dispersed, independently operated validator set. Reassessing the block period will be part of decentralizing the validator set.
• No consensus-layer change beyond the parameter. This is a timing parameter, not a new consensus algorithm. It does not alter QBFT's fault tolerance assumptions.

Reference Implementation and On-Chain Deployment

This is a chain-configuration change, so there is no contract address. The authoritative artifacts are the Besu QBFT genesis/config carrying the xblockperiodmilliseconds: 500 transition at block 2,138,451, and the chain history itself: block intervals before 2,138,451 are approximately 1000 ms and after are approximately 500 ms, verifiable via eth_getBlockByNumber timestamp deltas on https://rpc.aere.network. Chain ID is 2800.

Copyright

Released to the public domain (CC0). No rights reserved.