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

Bootnode 1 (37.27.216.110) now serves snap/1 (SnapServer on Bonsai flat db): SNAP clients skip historic body replay; run-node.sh stays FULL on purpose. Measured vs not-measured stated.

Browse Source
This commit is contained in:
Aere Network 2026-08-28 02:31:48 +03:00
parent e5da289a8e
commit 39d3275e17
1 changed files with 10 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
RUN-A-NODE.md
View File

@ -302,6 +302,16 @@ address hands an attacker a target whose downtime costs the network consensus he
sentry style architectures exist. The two nodes above carry no consensus responsibility: if both are
taken down, new nodes cannot bootstrap until they are replaced, and block production is unaffected.
**Update, 2026-08-28.** The first bootnode (37.27.216.110) now also serves the devp2p
`snap/1` protocol (`SnapServer ... Bonsai full flat db` in its startup log, capability list
`[eth/68..71], [istanbul/100], [snap/1]`). A client that chooses `--sync-mode=SNAP` against it
downloads headers plus the state at the pivot instead of replaying every historic block body,
which on this chain of empty blocks removes most of the multi-day full-sync cost. Honest limits,
measured versus not: the server capability and the public endpoint answering are measured today;
a complete stranger's snap sync to head against it has not yet been run, and the one-command
`run-node.sh` path deliberately stays `--sync-mode=FULL`, because a validating node that replayed
every block is a stronger statement than one that trusted a pivot.
A written address is not a live address. This file cannot prove the bootnodes are up at the moment
you read it; only your own `net_peerCount` can.