2024 Besu Defaults

Context

Currently starting Besu without configuring a handful of options will create a sub-par experience for users. It will use FOREST and FAST sync and attempt to connect to Ethereum Mainnet. These options are no longer suitable for Mainnet and Proof of stake.

For private network users, configuration must be done either way to set up a custom genesis, chain ID, and to configure connections to peers. Defaults will have less impact on these users. Enterprises and developers are more likely to read the documentation prior to first start up.

Suggestions

The Consensys team is suggesting a re-evaluation of defaults in the new year. We are also simultaneously suggesting adding “profiles” to Besu that when set, provide defaults that serve certain use-cases or sets of users. 

One more note. When setting a profile, any other options the user configures that fall underneath that profile will be overwritten. For example, if a user sets --profile=enterprise and --sync-mode=FULL it will override the sync mode flag from FAST  to FULL.

Defaults, no profile

When starting up Besu with no additional commands ./bin/besu , the following defaults are suggested:

  • Sync Mode: SNAP
  • Data-storage-format: BONSAI
    • Full flat DB by default Xsnapsync-synchronizer-flat-db-healing-enabled=true (DELETE THIS FLAG → Safety concerns Gary Schulte) 
    • Full flat DB will be default for all BONSAI users
    • bonsai-limit-trie-logs-enabled=True
    • bonsai-historical-block-limit=512
  • Network: Mainnet (should we specify a testnet for first time users without a config?)
  • Max-peers: 50 (in line with Geth and other clients)
  • -Xp2p-peer-lower-bound=25
  • Tx-pool: Layered (already default)

These defaults promote the most performant profile for public networks with the full chain history. This is especially important when we ship SnapSync as a Server in Q1. We want these users to be able to serve any data required by peers to be good network citizens. We also want to bump the peer count to enable more robust peering and serving more data to the network.

Profile Defaults

The Consensys Team is suggesting 4 profiles with their own defaults:

  • Selfish-staker
  • Considerate-staker (name?)
  • Private-network / Enterprise (?)
  • RPC Provider
    • Archive - Awaiting Bonsai Archive to change defaults
    • Near-head - Standard full node

Broken down below are the profiles.

Selfish-staker

  • Sync mode: CHECKPOINT
    • Lowest disk, quickest sync, cannot serve old block data, can serve all world state data
  • Data-storage-format: BONSAI
    • bonsai-historical-block-limit: 128
  • Max-peers: 25 
    • Slight reduction in CPU overhead from peering
    • -Xp2p-peer-lower-bound=10
  • Chain-pruning: Enabled
    • Deposit logs / tree dependency (TEKU ONLY) 

Considerate-staker

  • Sync mode: SNAP
    • More disk, quickest sync, can serve more block data, can serve all world state data
  • Data-storage-format: BONSAI

Private-network / Enterprise (?)

  • Sync-mode: FAST (move to snap —> not until snap server and Bonsai are tested in this environment, might require bonsai archive for some networks to migrate entirely over)
    • --fast-sync-min-peers = 3
  • Min-gas-price=0?
  • --remote-connections-limit-enabled=false
  • Tx-pool=Legacy / Sequential
    • --tx-pool-no-local-priority 
    • --tx-pool-limit-by-account-percentage=(something bigger than 4 transactions)

RPC Provider (Needed?)

  • Archive - Awaiting Bonsai Archive to change defaults, then…
    • data-storage-format: Bonsai
    • New options for how many checkpoints to take (i.e. tradeoff between storage and rollback time)
  • Near-head - Standard full node
    • Uses default profile from above

Both types:

  • revert-reason=true
  • rpc-gascap? (currently 1 eth, may want to lower for RPC providers)


  • No labels

10 Comments

  1. Sally MacFarlane

    2 comments

    1. re SNAP default - we need to change from X_SNAP first - declare no longer experimental - what's stopping us from doing that now?
    2. re changes to default min/max peers - I think before we change the defaults we should test this out on running nodes to quantify the CPU overhead vs how much it helps peering/syncing times.

    1. Matt Nelson

      agree on both. I think the X is ready to go away, especially when we launch snap server


  2. Sally MacFarlane

    where does fleet mode fit into this

    1. Matt Nelson

      As fleet is bundled via plug-in, it is out of scope for this proposal. 

  3. ahamlat

    Regarding JVM options, I recommend to set -Xmx8g for machines or VM that have >= 32 GiB RAM and -Xmx5g if RAM < 32 GiB.

  4. Matthew Whitehead

    I think this is really useful to give enterprise users a convenient way to switch on a bunch of sensible defaults. Initial comments on the proposal so far:

    • Having "private/enterprise" and "rpc provider" as mutually exclusive profiles feels like it's not catering for someone wanting a "private/enterprise RPC node". I wonder if there needs to be 2 levels of profile: chain profile (public vs private/enterprise), and node profile (rpc node, archive node, validator node etc).
      • Defaulting to FAST for "private/enterprise" is fine (and when SNAP works with QBFT should probably be replaced with that) but I guess if I want to create a private/enterprise archive node, it needs to be FULL synced with the chain?
    • It feels like there are some minor diagnostic/tidy up items related to moving X_SNAP to SNAP
      • Since SNAP is an extension of FAST in the codebase, the log entries for a SNAP sync node all show as FAST sync e.g. "main | INFO  | FastSyncDownloader | Starting sync". It's not ideal when looking through logs that the class names logged out can mislead you as to which sync mode is being used
      • Does SNAP sync support --fast-sync-min-peers? Besu doesn't complain if you set it (unlike FULL where it fails to start) and again, as an extension of FAST sync in the code I'm guessing it does apply to the min peer requirements for a SNAP sync. If that's the case, I think a synonym should be added as part of moving it out of experimental, with --fast-sync-min-peers  deprecated for removal in a future version.

    Some other suggested defaults for a private/enterprise node:

    • --fast-sync-min-peers < 5 (and similar for SNAP sync depending on the answer to comment above)
      • A chain of 4 nodes isn't uncommon, and I believe the default of 5 is related to trust of public peers ( ? ) which isn't as much of an issue with permissioned chains
    • --remote-connections-limit-enabled=false (inbound vs outbound peer connections aren't likely to be important)
    • --tx-pool-no-local-priority (locally submitted TXs being prioritised over those arriving through P2P communication is also less likely to be important)
    • --tx-pool-limit-by-account-percentage=(something bigger than 4 transactions). 

    1. Matt Nelson

      Thanks for these notes, I'll try to step through. 

      • For RPC provider, I feel like we can delete this. Probably not needed, especially considering I am recommending we use the default specs (smile)  Archive is a different story we aren't ready to tell... yet
      • For Archive - any flag that is set in the config that exists in the default or profile will be overwritten. So if you have --profile=enterprise and --sync-mode=full   it will override only the sync mode flag. I will update this page for clarity here. 
      • Logging for snap is bad and I will open a ticket to see if we can tidy this up.
      • SNAP is indeed impacted by --fast-sync-min-peers when using a non-PoS network. I will open a PR to change the docs (same with CHECKPOINT). With this in mind, we should also maybe change the flag itself. Open to suggestions, maybe --sync-min-peers  and we are explicit in the docs its only for PoW and PoA networks. 
      • ACK on all of your suggested changes - i think those are great, I will update the page itself. 


  5. Matthew Whitehead

    "maybe --sync-min-peers"

    I think it would be good to differentiate it from sync options that aren't affected by it. I'm thinking of FULL sync nodes really, which don't start if you set it.

  6. Matthew Whitehead

    One other thought for `--sync-min-peers` (or whatever the new name becomes). I wonder if FULL sync could be changed to tolerate it and just give a warning, instead of preventing node startup. Other options seem to be treated that way and that slightly more permissive approach is can be helpful in certain circumstances.

  7. Sally MacFarlane

    re p2p-lower-bound - following further discussion - question whether this is useful/being used - or if it should be removed altogether