feat: cache builder deposit signatures for gloas fork transition - #9727
feat: cache builder deposit signatures for gloas fork transition#9727twoeths wants to merge 11 commits into
Conversation
Performance Report✔️ no performance regression detected Full benchmark results
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## unstable #9727 +/- ##
============================================
- Coverage 52.52% 52.52% -0.01%
============================================
Files 848 848
Lines 60242 60241 -1
Branches 4430 4430
============================================
- Hits 31642 31641 -1
Misses 28541 28541
Partials 59 59 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: aa035b011d
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| try { | ||
| batchValid = | ||
| signatureSets.length >= 2 | ||
| ? verifyMultipleAggregateSignatures(signatureSets, true, true) |
There was a problem hiding this comment.
I wonder if there can be attackers that submit a bunch of deposits with invalid signature that force us to fall back to verify one by one which makes lodestar hard to keep up.
They only need 1 bad deposit per batch (32 deposits) to nullify all the optimizations here
There was a problem hiding this comment.
this is a valid concern but also the attacker would burn the eth, so it's basically a trade-off here, we want the batch sizes to be large enough to get benefits from batching but not too large so an invalid signature can't waste too much time/compute
| * keyed by the value object. Capped at `maxBuilderDeposits` new verifications per call; a later tick | ||
| * resumes past the cached deposits. Caller guarantees the fork-epoch + non-epoch-transition gates. | ||
| */ | ||
| export function preVerifyBuilderDepositsPreGloas( |
There was a problem hiding this comment.
Can we time-box this? If we run out of time, we should just keep the result on batches that we have verified so far and return, instead of letting this run unbound
There was a problem hiding this comment.
For example, before calling verifyDepositSignatures for a chunk, check how much time left. If no time remaining, give up.
There was a problem hiding this comment.
sounds like a good idea too me if it doesn't add too much complexity
There was a problem hiding this comment.
this is a good idea, will also resolve the invalid signatures concern above
nflaig
left a comment
There was a problem hiding this comment.
Looks pretty good to me, ideally we want this on devnet-8 before the fork happens
Motivation
Description
PendingDepositssz type toContainerNodeStructso that we can speed up the loop and cache by the object itselfBuilderDepositSignatureCachePrepareNextSlot2 epochs before gloas transitionAI Assistance Disclosure