Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

De-duplicate pubkey caches across BeaconState/BeaconChain #6484

Open
michaelsproul opened this issue Oct 14, 2024 · 2 comments
Open

De-duplicate pubkey caches across BeaconState/BeaconChain #6484

michaelsproul opened this issue Oct 14, 2024 · 2 comments
Labels
optimization Something to make Lighthouse run more efficiently. tree-states Upcoming state and database overhaul

Comments

@michaelsproul
Copy link
Member

Description

Presently Lighthouse has two notions of a pubkey cache. There's the "global" cache attached to the BeaconChain, and "local" caches attached to each BeaconState.

Since in-memory tree-states, the local caches are stored using a persistent data structure, meaning that many beacon states can share most of the pubkey cache without duplication. The idea behind this issue is to extend this structural sharing to the global public key cache.

Implementation

One way to implement the cache would be for new beacon state caches to be initialised from the global cache, by cloning and making the necessary mutations. The persistent data structures (from rpds) then ensure that memory is shared

Another approach would be to have a global cache that is aware of changes to pubkeys over time, and can respond with results for different epoch values. The beacon states could contain an Arc<RwLock<..>> reference to this cache, and make queries. This approach might be more compatible with validator index reuse should it be implemented in future, as the global cache would never "forget" about old overwritten validators. This could be advantageous when reloading old states from disk, as the cache would already contain the relevant information and would not need to be rebuilt.

@michaelsproul michaelsproul added optimization Something to make Lighthouse run more efficiently. tree-states Upcoming state and database overhaul labels Oct 14, 2024
@dapplion
Copy link
Collaborator

This approach might be more compatible with validator index reuse

I don't think we should consider index reuse for now. If it ever comes it will be in a long while. Beam chain might happen in the middle

@michaelsproul
Copy link
Member Author

Two separate cleanups:

  • Remove pubkey_bytes field from global cache. It is rarely used and quite unnecessary because we can always load pubkey bytes from the head state, or load a PublicKey and quickly compress it.
  • De-dupe the global and state caches. Lion and I discussed this offline and settled on an approach where we remove the cache from the BeaconState, and have a persistent cache that is cloned before block processing (keeps block processing lock free).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
optimization Something to make Lighthouse run more efficiently. tree-states Upcoming state and database overhaul
Projects
None yet
Development

No branches or pull requests

2 participants