feat(cosmic-swingset): add swingset 'crankhash' to state vector

[warner]

This 'crankhash' covers all kernel state changes, so if any two validators
diverge, their crankhashes should diverge too. By storing them into the
cosmos-sdk state vector, the AppHashes will diverage as well, causing at
least one of them to fall out of consensus. This should let us catch
divergence as soon as possible.

closes #3442

[michaelfig]

Looks good in principle. I presume the crankhash is a rolling hash so that sampling it just once at the end of the block is useful?

[warner]

Looks good in principle. I presume the crankhash is a rolling hash so that sampling it just once at the end of the block is useful?

Right. Each crank's DB changes are (non-confusably) concatenated and hashed into the "crankhash" for that one crank, then the DB .crankhash is updated to be the hash of the previous .crankhash plus the new crank's hash. So the current DB .crankhash should be sensitive to the entire history.

This includes the v$NN.source static vat sources, but no transcript entries, so it omits dynamic vat sources.

[warner]

Looks good in principle.

And in the specific.. am I writing the hash into the cosmos (consensus-checked) state vector correctly?

[michaelfig]

Need to change the crankhash property to be named value instead.

[michaelfig]

LGTM. Please consider my question, though.

[michaelfig]

Out of curiosity, why is this not a part of the above bootstrapBlock function as well?

[warner]

Hm, good question, I hadn't thought about it. I think that'd be fine, it would capture/signal any divergence during the initial controller.run() that sets up the javascript world. Without it, we'd signal that divergence during the second block instead of during the first. The activityhash is updated for every commitCrank (including the one that initializeKernel() does, making its starting value effectively a hash of the config object), so even if we don't read it at that point, it's still sensitive to the initial state.

I'll add that.