jwasinger

This looks good @hermanjunge . As we discussed, I will be working on writing the javascript implementation of the rlpx transport `js-libp2p-rlpx`.

I'm referring to the way voting snapshot state is constructed. Right now, when the client starts up we must traverse the chain backwards to the last epoch in order rebuild...

The voting snapshot is only restored during client startup so there should be no overhead for the RPC API AFAIK

I haven't had time to review the RPC API changes yet so I could be wrong.

Cool. Looking forward to seeing what you come up with :)

My inclination is that this issue is nice to have but the implementation should be merged separately from the main clique PR in order to avoid more review overhead from...

Yes. I think so.

Hey @jleni looks like this might be easy to add via the "block metadata feature" (see the related comment on the PR above). I'm going to look into this.

I can look into it after I wrap the bls benchmarks and bls fuzzers.

Full sync benchmark nodes are running around block 12.2 million (bench7 is running this PR with the witness collection flag enabled, bench8 is master)    Witness collection mode...