Running a BNB Smart Chain node

This is the expensive chain of the three measured here, and the reason is block production: a chain that produces blocks several times a second writes several times as much state, and the machine has to keep up with the writing rather than with the reading.

Roughly four times what an Ethereum full node is specified at, for the same job. Treat the numbers as floors on the day they were read, and size the disk for a year out: growing a full node’s disk usually means resyncing it.

The single configuration knob worth getting right before you start. BNB Chain’s own guidance is to hand roughly a third of physical memory to the client’s cache — on a 64 GB machine, that is:

geth --cache 20000 \
  --datadir /var/lib/bsc \
  --http --http.addr 127.0.0.1 --http.api eth,net,web3

The same page notes that the chain primarily supports PBSS and PebbleDB as storage formats. Both are decisions made at initialisation, so they are cheap now and a resync later.

1. 1

   Download a chaindata snapshot

   BNB Chain distributes snapshots and expects you to use them. Syncing from scratch on a chain of this size and block rate is measured in weeks, not days, and the difference is not a matter of patience — the node has to catch up faster than the chain advances, and on this chain that is a real constraint rather than a formality.

2. 2

   Understand what you have accepted

   A snapshot is somebody else’s copy of state, taken on trust exactly as a checkpoint is on Ethereum. Verify the published checksum, and prefer the chain’s own distribution over a mirror you found in a forum thread.

3. 3

   Then watch the gap close, not the process list

   A node still catching up answers RPC quickly and with old state. That is the failure that looks like success, and the first thing to monitor is distance from the head — see knowing your node is healthy.

One reason to run your own BSC node is stated plainly in the chain’s own documentation, and it catches applications at runtime rather than at design time:

• This is a product decision, not an outage. An application that treats the resulting error as the chain being down will retry into a wall.
• Your own node has no such restriction — which also means nothing protects it from an unbounded log range except what you put in front of it. Serving RPC at scale covers giving that method its own pool.
• Check before you assume. The method matrix measures what each BSC endpoint actually answers, which is faster than reading everybody’s documentation.

Bind the RPC to localhost

Always, and put something in front of it. The rules are the same on every chain and are written out once in exposing RPC without giving it away.

Track releases from bnb-chain/bsc

Hard forks arrive with a deadline attached. The announcement that matters is the one on the repository whose binary you run.

Watch disk growth as a rate

On this chain more than the others. The useful alert is days-of-disk-remaining at the current rate, not a percentage threshold.

If the machine above reads as more than you want to own, that is a legitimate conclusion — getting a dedicated node works through the comparison honestly, including the parts of the self-hosted bill that usually get estimated at zero.