Michael Sproul ca9dc8e094 Optimise HTTP validator lookups (#3559) ... ## Issue Addressed While digging around in some logs I noticed that queries for validators by pubkey were taking 10ms+, which seemed too long. This was due to a loop through the entire validator registry for each lookup. ## Proposed Changes Rather than using a loop through the register, this PR utilises the pubkey cache which is usually initialised at the head*. In case the cache isn't built, we fall back to the previous loop logic. In the vast majority of cases I expect the cache will be built, as the validator client queries at the `head` where all caches should be built. ## Additional Info *I had to modify the cache build that runs after fork choice to build the pubkey cache. I think it had been optimised out, perhaps accidentally. I think it's preferable to have the exit cache and the pubkey cache built on the head state, as they are required for verifying deposits and exits respectively, and we may as well build them off the hot path of block processing. Previously they'd get built the first time a deposit or exit needed to be verified. I've deleted the unused `map_state` function which was obsoleted by `map_state_and_execution_optimistic`.		2022-10-15 22:25:51 +00:00
..
src	Optimise HTTP validator lookups (#3559)	2022-10-15 22:25:51 +00:00
tests	Remove fallback support from eth1 service (#3594)	2022-10-04 08:33:39 +00:00
Cargo.toml	Builder Specs v0.2.0 (#3134)	2022-07-30 00:22:37 +00:00