Ensure parameters match in the peer protocol.

[nathan-at-least]

If a node joins a network but is using different zkSNARK circuit params, in the current codebase, I believe the peer protocol level won't notice this and then some nodes will fail other nodes' proofs.

A simple way to handle this is to bake in the hash of the parameters into the genesis block because the genesis block is already hardwired into nodes and the peer protocol (and there are different ones with different parameters: eg: prod network, testnet, localtest, etc...).

I added future proofing because we've discussed being able to migrate parameters long term. In that case we would need a way to do this "parameter agreement" as new parameters are introduced. One question is: if we use the "bake-it-in-the-genesis method" I described above, would this preclude any of our brainstormed parameter migration strategies?

[nathan-at-least]

A related issue for transmission of the parameters (and maybe in-memory representation) is the serialization size. From spot checks of the serialized format, it appears to be whitespace separate decimal integers. So bzip2 should provide some widely deployed low-hanging fruit for cutting down on transmission size.

It's easy to imaging a different compact binary serialization, which would be more coding effort, but may also improve loading time. I don't know if that's at all an issue though.

[ebfull]

I had a thought over the weekend about this: we could also include it in the "commitment tree" as, perhaps, the first element. I don't know what we'd gain over doing this instead of modifying the genesis block. It may make sense if we change the parameters and need to maintain multiple commitment trees.

[daira]

The peer protocol already has an identifier that would prevent any confusion here. Also, it would be a fork because blocks that would verify with one set of parameters wouldn't verify with the other.