From 17eee07493cb61b53e412632aec943dfd14dd7c3 Mon Sep 17 00:00:00 2001 From: Aere Network Date: Sat, 12 Sep 2026 08:10:31 +0300 Subject: [PATCH] RUN-A-NODE: your clock is the fifth requirement, with the BREACH_OF_PROTOCOL line it produces when it is a second behind --- RUN-A-NODE.md | 32 +++++++++++++++++++++++++++++++- 1 file changed, 31 insertions(+), 1 deletion(-) diff --git a/RUN-A-NODE.md b/RUN-A-NODE.md index faef9fd..c704231 100644 --- a/RUN-A-NODE.md +++ b/RUN-A-NODE.md @@ -43,7 +43,7 @@ audit each step rather than run it. --- -## The four things you need +## The five things you need | What | Where | |---|---| @@ -51,6 +51,36 @@ audit each step rather than run it. | `registries/` | The public Falcon validator registries. Without them a node imports fine to block 13,014,000 (the first anchor) and then refuses every anchor block, because it cannot map a certificate's seal indices to validator addresses. See `registries/README.md`; sha256 of each below. | | a bootnode enode | one published in the bootnodes section below; run-node.sh uses it by default | | `patches/`, `precompiles/` | The Besu fork, see `README.md`. Needed to sync past block 9,189,161 | +| **a clock within one second of real time** | not a file, but as hard a requirement as the four above. See below | + +**Your clock, and why it is on that list.** QBFT header validation on this chain is +`TimestampBoundedByFutureParameter(1)`: a header whose timestamp is more than **one second** ahead of +your node's clock is invalid. Blocks here are ~0.6 s apart, so a machine running one second slow sees +every fresh head as "from the future" - and Besu does not treat that as a clock disagreement. It +treats it as `BREACH_OF_PROTOCOL` and disconnects the peer that served it: + +``` +INFO | TimestampBoundedByFutureParameter | Invalid block header: + timestamp 1789189254 is greater than the timestamp margin 1789189253 +WARN | PipelineChainDownloader | Invalid block detected (BREACH_OF_PROTOCOL). + Disconnecting from sync target. +``` + +If you see that, nothing is wrong with the chain and nothing is wrong with this package. Your clock is +behind. The node recovers on its own ("Chain download failed. Restarting after short delay.") and will +still reach the head, but it drops good peers while it does. Run NTP - and check it actually took: +measured 2026-09-12 on our own import run, a machine where `timedatectl` reported +`NTPSynchronized=yes` was still a full second behind, because it was a VM whose host clock was right +and whose own was not. Compare against the chain itself rather than against a status flag: + +``` +curl -s -X POST -H 'content-type: application/json' \ + -d '{"jsonrpc":"2.0","id":1,"method":"eth_getBlockByNumber","params":["latest",false]}' \ + https://rpc.aere.network | grep -o '"timestamp":"0x[0-9a-f]*"' +``` + +Convert that hex to decimal and compare it with `date +%s` on your machine. A difference of 0 or 1 is +fine. More than that, in either direction, and you will see the behaviour above. The registries are public (Falcon public keys and validator addresses, each carrying a proof of possession and an ECDSA claim; no private key material). Their sha256, also in `registries/SHA256SUMS`: