-
Notifications
You must be signed in to change notification settings - Fork 801
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
Move processing cache out of DA #5420
Conversation
3c5af19
to
0c86593
Compare
@@ -305,6 +305,11 @@ impl<T: BeaconChainTypes> Critical<T> { | |||
Ok(()) | |||
} | |||
|
|||
/// Returns true if the block root is known, without altering the LRU ordering | |||
pub fn has_block(&self, block_root: &Hash256) -> bool { | |||
self.in_memory.peek(block_root).is_some() || self.store_keys.get(block_root).is_some() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ethDreamer is this line right, i.e. should I also check the store keys?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think so, the store keys are referencing the entries in the data availability cache that over overflowed to disk. So it's an extension of the availability cache really.
Side note - but once we've merged tree states we should consider getting rid of the overflow logic. It would be a nice complexity reduction.
overall I agree with your reasoning and support the change! This probably could/should have happened along with the removal of delayed lookup logic |
Sharing some notes justifying the change as is. We can address the de-duplication gadget on another PR Lighthouse processing cacheProcessing cache is tied to the
The processing cache purposes are:
Gossip block journey
Gossip blob journey
Unknown head attestation journey
chain.canonical_head.fork_choice_read_lock()
.get_block(&attestation.data.beacon_block_root) IF UNKNOWN
ON SYNC
let Some(processing_components) = da_checker.processing_cache.get(block_root)
else { return MissingBlobs::fetch_all_for_block(block_root) };
da_checker.get_missing_blob_ids(block_root, processing_components) Is the processing cache necessary for blobs?For early ReqResp serving
The processing cache is not checked for ReqResp blob serving. And that's okay, blobs are inserted to the For de-duplication
If we rely only on
Which matches the long term average of 4ms seen below = 100ms/32 In the unlikely case that sync attempts to download a blob during a slow run of fork-choice block import, the worst case is to download a set of blobs. Is the processing cache necessary for blocks?For early ReqResp serving
For de-duplication
Blocks enjoy another cache, the
So |
…n-da-processing-cache
…ng blob id calculations
removed a TODO that was outdated, removed the processing cache file, and updated the missing blob ids calculation to consider if we're in deneb (keeps us from requesting blobs pre-deneb) |
@Mergifyio queue |
🛑 The pull request has been removed from the queue
|
@Mergifyio requeue |
❌ This pull request head commit has not been previously disembarked from queue. |
@Mergifyio dequeue |
✅ The pull request has been removed from the queue
|
@Mergifyio requeue |
✅ This pull request will be re-embarked automaticallyThe followup |
🛑 The pull request has been removed from the queue
|
@mergify requeue |
✅ This pull request will be re-embarked automaticallyThe followup |
🛑 The pull request has been removed from the queue
|
…n-da-processing-cache
@Mergifyio queue |
🛑 The pull request has been removed from the queue
|
@Mergifyio requeue |
✅ This pull request will be re-embarked automaticallyThe followup |
✅ The pull request has been merged automaticallyThe pull request has been merged automatically at 30dc260 |
Current unstable has a processing cache that tracks both blocks and blobs while they are being processed. To be specific, in the case of blobs "processing" means the time to KZG verify the proofs and insert them in the data availability overflow cache:
The purpose of the cache is to:
Let's address each one for blocks and blobs
1 / blocks
Block processing can take a few hundred milliseconds due to execution validation. There must exist some cache but does not need to be tied to DA.
1 / blobs
This cache will be useful if we get a blobs by root request for a blob that we have just received which happens to be in the few milliseconds KZG proof validation takes. I can be convinced otherwise, but this use-case does not justify the complexity.
2
After deleting delayed lookup logic this argument is mostly void. In rare conditions we may end up
Benefits
The
AvailabilityView
abstraction spills complexity that only affects the accumulators of the availability cache and block lookups also into the processing cache.By making the processing cache not concerned with DA Lighthouse is a bit more maintainable and easy to reason about.