Best set of runtime arguments for maximizing revenue? Best set of compile-time arguments?

[JamesCropcho]

Let us assume that AWS resources are free. Let us further assume that none of our EC2 instances are constrained by networking throughput, CPU use, RAM capacity, disk I/O, or the rest.

What would be the best set of runtime arguments to maximize validator revenue? The question applies to both the Beacon Node and the Validator Client.

A non-default --block-cache-size ?

A non-default --target-peers ?

A non-default --network-load ?

Inclusion of --subscribe-all-subnets?

Inclusion of --import-all-attestations?

The above are just examples; the scope of the question is not limited to them.

[michaelsproul]

The most impactful flags are --subscribe-all-subnets and --import-all-attestations. If you enable both and your machine can handle the load then your blocks will end up containing more attestations on average and being up to 5% more profitable.

Other than that, Lighthouse is designed to run optimally by default on whatever hardware it's given. Having a fast CPU helps, particuarly one that supports ADX and SHA256 native instructions (e.g. all AMD Ryzen CPUs support this, and most modern Intel ones). Having fast I/O is also advantageous.

You may see some small benefit from increasing --block-cache-size, --target-peers or --network-load, although our testing indicates that the block cache is pretty ineffectual, and increasing bandwidth beyond the default is usually not useful.

[JamesCropcho]

Thank you, Michael. That is very helpful, as well as interesting.

For the lighthouse beacon_node instance I was using a Xeon CPU with a whopping 4 GHz clock speed, however it lacked lacked support for SHA256 native instructions. I have since switched to a 3.5 GHz Ice Lake CPU which does support SHA256 native instructions (and both supported ADX). I am tentatively pleased with the results, although I can't yet say the increase in revenue is statistically significant.

To take advantage of these CPU-specific performance enhancements do I need to build Lighthouse from source or can I use https://github.com/sigp/lighthouse/releases/download/v3.0.0/lighthouse-v3.0.0-x86_64-unknown-linux-gnu.tar.gz ?

[michaelsproul]

To take advantage of these CPU-specific performance enhancements do I need to build Lighthouse from source or can I use https://github.com/sigp/lighthouse/releases/download/v3.0.0/lighthouse-v3.0.0-x86_64-unknown-linux-gnu.tar.gz ?

Yeah you can use the binary. Compiling from source might yield some additional benefits, particularly if you use something like RUSTFLAGS='-C target-cpu=native' to ask LLVM to tune the binary to your specific CPU, however this isn't an avenue we've investigated much.

You should get confirmation of SHA-256 acceleration in lighthouse --version:

Lighthouse v3.0.0-65af3c5 BLS library: blst SHA256 hardware acceleration: true Specs: mainnet (true), minimal (false), gnosis (false)

[JamesCropcho]

Again, thank you for the valuable guidance, Michael.

Expecting no noticeable difference in performance I built the executable, on the beacon_node target/production machine (the aforementioned 3.5 GHz Ice Lake CPU) via

env RUSTFLAGS='-C target-cpu=native' FEATURES="modern" make

$ lighthouse --version

Lighthouse v3.0.0-18c61a5 BLS library: blst-modern SHA256 hardware acceleration: true Specs: mainnet (true), minimal (false), gnosis (false)

(I'm not running a Slasher because my understanding is that it does not presently result in an increase of revenue—let me know if I'm mistaken.)

The lighthouse validator_client continues to run on a different instance (aarch64) in the same AWS Availability Zone and VPC and consumes virtually no compute/networking resources.

I did this more so to report my case study for community benefit:

I have not noticed any performance difference (although I'm not performing a formal analysis), nor have I noticed any other sort of difference, positive or negative, including within the logs (logging at INFO-and-above).

If I can perform any further experimentation with this matter let me know. Otherwise, if I notice anything which is in the literal sense "remarkable" then I will report back.

[michaelsproul]

Closing this as stale. We're always updating LH to provide the best profitability flags by default (e.g. #4971) and anything beyond that is usually subject to change quickly, and is probably best gleaned from Discord, chats with devs, guides, etc.

[JamesCropcho]

Having a fast CPU helps, particularly one that supports ADX and SHA256 native instructions (e.g. all AMD Ryzen CPUs support this, and most modern Intel ones).

Does this describe running lighthouse beacon_node, lighthouse validator_client, or both?

Having fast I/O is also advantageous.

Would I assume that fast I/O does not matter when it comes to running lighthouse validator_client?

[michaelsproul]

Does this describe running lighthouse beacon_node, lighthouse validator_client, or both?

Both benefit from ADX, as that's used for BLS signing (VC) & verifying (BN). The BN benefits from SHA-256 as it's the one that hashes the state.

Would I assume that fast I/O does not matter when it comes to running lighthouse validator_client?

It helps a little, particularly at high validator counts – 100+, but especially 1000+. The reason is that the VC needs to do quite a lot of atomic writes to the slashing protection database. If you are using web3signer and --disable-slashing-protection-web3signer then I/O doesn't matter.