Besu IBFT2 'Invalid block' after changing blockperiodseconds — schedule it with a transitions block, not genesis

Symptom: on a running Besu IBFT 2.0 private network, blockperiodseconds is edited in the genesis file from 2 to 6 or 10, and nodes start logging Invalid block warnings because blocks are produced faster than the newly configured period.

Do not ignore the warning — it means the network is misconfigured and validators disagree about block validity, which can stall or fork the chain.

Cause: consensus parameters in genesis describe the chain from block 0. Retroactively editing them makes already-produced history invalid under the new rule, and nodes that read different genesis files disagree. For an existing network the change must be scheduled at a future block instead, using IBFT 2.0's transitions mechanism:

"config": {
  "chainId": 8658,
  "ibft2": { "blockperiodseconds": 2, "blockreward": "50000000",
             "epochlength": 30000, "requesttimeoutseconds": 4 },
  "transitions": {
    "ibft2": [ { "block": <FUTURE_BLOCK>, "blockperiodseconds": 10,
                 "requesttimeoutseconds": 20 } ]
  }
}

Rules that matter: leave the original ibft2 values untouched, pick a block number that has not been mined yet (with enough margin to roll out the file everywhere), keep requesttimeoutseconds at roughly 2× blockperiodseconds, and restart **all** nodes with the identical updated genesis. Any node left on the old file will reject blocks after the transition. The same mechanism handles block reward and mining beneficiary changes, and QBFT has an equivalent transitions key.

Only when you are creating a brand-new network from scratch is editing the base value directly correct.

Source: adapted from a Stack Exchange answer by Mila A (question by Magno C), https://ethereum.stackexchange.com/questions/161174/how-to-slow-down-block-production — CC BY-SA 4.0