BSC blockchain ecosystem has proved itself to be the most accessible and the most accessed platform for decentralized applications and open finance. But the large amount of accounts, contracts and transactions on BSC have brought challenges in scaling up. It is hard to keep nearly 18TB data of a BSC archive node on one machine with the Geth client. Many community members met difficulties when running their own archive node.
Erigon originally started as turbo-geth and an improvement of Geth. Later it has become to “erigon” after significant re-writing of the database structure, data model, and sync process.
Here is the key features of Erigon:
- More efficient state storage, less space for state data, uses a key-value database and stores accounts and storage in a simple way.
- Faster initial sync, uses a rearchitected full sync algorithm from Geth that is split into “stages”.
- Independent JSON-RPC daemon, RPC calls are extracted out of the main binary into a separate daemon supporting both local or remote DBs.
- Fewer Read/Write operations with the database when interacting with state data.
With the help of community developers Erigon has supported BSC by the end of last year.Below is our experience to run an archive node of BSC from the genesis block with Erigon client.
The AWS EC2 server we used includes:
- 16 vCPU
- 64 GB memory
- 50 GB disk for OS
- 8T GB nvme disk for BSC mainnet archive data
Unlike Go-Ethreum’s client Geth, erigon has a separate RPC service which is called rpcdaemon. So we need to download the repo from github and checkout the devel branch(some bug fixes needed on this branch), then make to get the erigon and rpcdaemon binary separately.
git checkout devel
It is simple to run an erigon archive node. Erigon runs in archive mode by default while you need to add “–gcmode=archive” for Geth. Erigon’s rpcdaemon runs in its own separate process.This brings many benefits including easier development, the ability to run multiple daemons at once, and the ability to run the daemon remotely. It is possible to run the daemon locally as well (read-only) if both processes have access to the data folder.We selected local DB mode, which RPC daemon runs on the same computer as Erigon.This mode uses shared memory access to the database of Erigon, which has better performance than accessing via TPC socket.
Provide both --datadir and --private.api.addr options when running commands:
- Run Erigon for BSC mainnet
- Run rpcdaemon
./build/bin/rpcdaemon --datadir=/server/erigon/build/bin/node --private.api.addr=localhost:9090 --http.api=eth,erigon,web3,net,debug,trace,txpool
- Updating node
Updating erigon is fairly straightforward, simply pull the latest changes from github, run make, and restart our services.
I would suggest paying more attention when updating. Although the Erigon team does their best to ensure that Erigon is safe and stable, it’s always best to be safe. Also, Some updates might not be reversible, when that happens, the startup of your node after updating will include a migration of data. However, if you want to downgrade, you would likely have to re-sync.
It took about two months for erigon to catch up with the latest block of BSC mainnet. And the disk space used is about 4.8TB (much smaller than 18TB with Geth client) when running to 15243567 block height for BSC mainnet.
- 20,000qps stress test, most of the delays are around 5 milliseconds, tested with 3 rpc methods(eth_call/eth_getBalance/eth_getTransactionCount):
Below are the issues we met with Erigon client:
- 4TB size limitation
Erigon crashed when running to the block height of 141335260. It can be seen that the error “map size limit reached” was hit when the data size is nearly 4TB.So we modified the map size and restarted the erigon client. Another coredump was hit in mdbx library.We raised one issue for mdbx: 4Tb assert · Issue #260 · erthink/libmdbx · GitHub with the community developers, we reproduced the issue locally with the debug version provided by the community. The issue was located smoothly with our coredump file. It is one problem of mdbx-go. And libmdbx developers have released a new fix for it in version 0.11.4. And also the fix has been merged to erigon “devel” branch now.
- OOM issues
Our archive nodes got OOM during block execution. One is “block=13506637”, the other is “13562001”. Talking with community developers, it might be a memory leak issue in erigon or an issue in libmdbx. It is suggested that we could bypass it by resetting the process. And it seems it’s not critical and doesn’t affect the sync process. The issue was not hit after that, but needs to be investigated later.