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:

```json
{
  "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.
</content>