-
Notifications
You must be signed in to change notification settings - Fork 983
Description
Description
We have a setup of LH running BN and VC separated. The VC is loading thousands of validator keys through from the validation_definitions file. We use web3signer externally for singing purposes.
We are working on activating the builder proposals to some of the validators (not all, so removing the --builder-proposals argument). We are using the API as documented on [this link](https://lighthouse-book.sigmaprime.io/builders.html#enabledisable-builder- proposals-via-http).
When experimenting with this API by only calling the PATCH to 1 validator, we noticed that it loads ALL validator keys again from the definitions file, creating high CPU usage.
The request is something like: PATCH lighthouse/validators/{pubkey} with a body with { "builder_proposals": true }. When making the request, the logs of LH VC show the following:
│ lighthouse-validator Dec 13 10:30:26.246 INFO Enabled validator voting_pubkey: <pubkey1>, signing_method: remote_signer │
│ lighthouse-validator Dec 13 10:30:26.246 INFO Enabled validator voting_pubkey: <pubkey2>, signing_method: remote_signer │
│ lighthouse-validator Dec 13 10:30:26.246 INFO Enabled validator voting_pubkey: <pubkey3>, signing_method: remote_signer
So it loads all pub keys again. on the example we did, it loads the 500 keys even though we only patched 1. Imagine that it loads 500 keys for the 500 requests we need to update the state of all keys, and it becomes an exponential problem.
On the tests we did, the CPU usage and Storage I/O goes high when compared to not doing those requests.
Version
version: Lighthouse/v3.3.0-bf533c8
Present Behaviour
When patching the builder_proposal value for a validator key, the LH VC service reloads all validators again.
Expected Behaviour
It should update that validator and not reload the data for all validators configured.