Support storing voting snapshots in the database

[jwasinger]

Otherwise, we have to trace back through the chain and rebuild the voting snapshot on startup (which can be very slow depending on where we are in the epoch).

[jleni]

I am not sure about the context of what you've been discussing.
Are you referring to an internal class for Snapshots matching Geth snapshots?

To match the types in the API, I have to create this:
https://github.com/goerli/parity-goerli/pull/58/files#diff-c08ee81f30b2cc1b9b605a93a4267708R47

But having this tracked internally instead would be useful

[jwasinger]

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 state:

https://github.com/goerli/parity-goerli/blob/master/ethcore/src/engines/clique/mod.rs#L266-L299

Geth stores voting snapshots on disk to avoid this. We can do the same.

[jleni]

yes, this is a problem for the REST API, because I need to access them by index or hash

[jleni]

if this is refactored, it would be amazing if:

• storage allows for fast access via index or hash
• the data structures match Geth.

Otherwise, searching/wrapping/converting on each REST call will be inefficient.
We can get the types/tests from that file in the PR that I linked earlier.

[jwasinger]

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

[jwasinger]

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

[jleni]

Yes, I have just started. I will be working on this in the next few days. It is much better now that things got merged and are a bit more stable.

I assume then that snapshots are accessible here:

parity-goerli/ethcore/src/engines/clique/mod.rs

Line 160 in 941d454

block_state_by_hash: RwLock<LruCache<H256, CliqueBlockState>>,

I may need a way to get them by index. I need to review the code a bit more.

[jwasinger]

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

[jwasinger]

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 the Parity side.

[jleni]

would it be possible to make this public?

parity-goerli/ethcore/src/engines/clique/mod.rs

Line 254 in 5fa0228

fn state(&self, header: &Header) -> Result<CliqueBlockState, Error> {

[jwasinger]

Yes. I think so.

[jwasinger]

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.