aere-network/aere-node
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

RUN-A-NODE: your clock is the fifth requirement, with the BREACH_OF_PROTOCOL line it produces when it is a second behind

Browse Source
This commit is contained in:
Aere Network 2026-09-12 08:10:31 +03:00
parent aeee182204
commit 17eee07493
1 changed files with 31 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

32
RUN-A-NODE.md
View File

@ -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`: