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 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. 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 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. you read it; only your own `net_peerCount` can.