chimera-defi

Overview

Geth (Go-Ethereum) as of July 2022 takes about 650 GiB of space on a fast/snap sync, and then grows by ~ 14 GiB/week with default cache, ~ 8 GiB/week with more cache.

This will fill a 1TB SSD in a few months, to the point where space usage should be brought down again with an offline prune.

There is an odd behavior with Geth 1.10.20 where initial DB size is large after sync until Geth has been restarted twice. This is expected to be fixed soon, possibly as soon as 1.10.21.

Happily, Geth 1.10.x introduces "snapshot offline prune", which brings it back down to about its original size. It takes roughly 4-6 hours to prune the Geth database, and this has to be done while Geth is not running.

Caveat that while several folx have used offline pruning successfully, there is risk associated with it. The two failure mode

chimera-defi

Keybase proof

I hereby claim:

• I am chimera-defi on github.
• I am chimeradefi (https://keybase.io/chimeradefi) on keybase.
• I have a public key ASBzl3lv3amNAGychLL5sac0j1U_wVwQw3sM4cSz3qb_ywo

To claim this, I am signing this object:

chimera-defi

#!/usr/bin/env python3.8
import brownie
from brownie import Contract
import csv

def main():
    brownie.network.connect('mainnet')

    # lobsterdao, or plop your contract addr here
    nft_contract = Contract('0x026224a2940bfe258d0dbe947919b62fe321f042')

chimera-defi

# Please note: The settings below are based on each other and based on a previous config file meant for both nodes. 
# As such, some of the settings may not be valid for the intended process but will be ignored and not cause issues.  

# Beacon node

http-web3provider: https://eth-mainnet.alchemyapi.io/v2/<redacted>
fallback-web3provider: 
  - https://mainnet.infura.io/v3/<redacted>
graffiti: "SharedStake.org Prysm AWS-ohio"
accept-terms-of-use: true

chimera-defi

Benchmarks for Prysm 1.4.4 undergoing normal functioning

The following are benchmarks via sar for a normal Prysm node.
A beacon-chain is running, connected remotely to Alchemy with an Infura backup.
A validator is running with 500 validating keys.

CPU

Via sar -u 3

Linux 5.11.0-1017-aws (ip-.) 	09/09/21 	_x86_64_	(4 CPU)

chimera-defi

Benchmarks for Prysm 1.4.4 undergoing initial sync

This document shows Prysm benchmarks on disk & network I/O and CPU & memory usage undergoing initial sync.
Total time taken to sync up to the current epoch and slot as of Sept 9th, to slot 2028735 was approximately 24 hours.
We tried a few different settings but overall found default is the best.
The final state size of the beacon chain was ~25GB.
Overall it seemed that the block-batch-limit had the most effect on the sync speed and success & error rate.
Error rate seemed to increase as we got closer to the head of the chain.
We recommend reducing the block-batch-limit to 32 from the default of 64 near the chain head if the error rate is very high.