app/eth2wrap: implement and wire validator cache #2121
Conversation
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #2121 +/- ##
=======================================
Coverage ? 53.56%
=======================================
Files ? 174
Lines ? 22547
Branches ? 0
=======================================
Hits ? 12078
Misses ? 9014
Partials ? 1455
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report in Codecov by Sentry. |
app/eth2wrap/httpwrap.go
Outdated
| @@ -36,6 +37,34 @@ type NodePeerCountProvider interface { | |||
| NodePeerCount(ctx context.Context) (int, error) | |||
| } | |||
|
|
|||
| type ActiveValidators map[eth2p0.ValidatorIndex]eth2p0.BLSPubKey | |||
There was a problem hiding this comment.
another nit: maybe this type should live in valcache.go?
corverroos
added
the
merge when ready
corverroos
force-pushed
the
corver/valcache2
branch
from
06af57b
to
bd93590
Compare
| resp[val.Index] = val.Validator.PublicKey | ||
| } | ||
|
|
||
| c.active = resp |
There was a problem hiding this comment.
I'd suggest to lock mutex around this (when c.active is updated) and not above as we are calling eth2Cl after locking mutex.
There was a problem hiding this comment.
no the point here is to lock while only one call to populate the cache is done
This is a second attempt at caching active validators. Instead of caching the
eth2client.ValidatorProviderendpoints which return fullValidatorobjects that are not actually immutable by epoch, rather implement a new set of client endpoint specifically for cached immutable active validators by current epoch that only return the validator index and pubkey which are immutable. The only race condition is the fact that we query this by "head", so could be for another slot that what we think is current, although this was already the case previously, so no new races are introdcued.This should significantly decrease BN load, especially if using the validatormock.
category: feature
ticket: #1396