Michael Sproul 0b54ff17f2 Fix assert in slashing protection import (#2881) ... ## Issue Addressed There was an overeager assert in the import of slashing protection data here: fff01b24dd/validator_client/slashing_protection/src/slashing_database.rs (L939) We were asserting that if the import contained any blocks for a validator, then the database should contain only a single block for that validator due to pruning/consolidation. However, we would only prune if the import contained _relevant blocks_ (that would actually change the maximum slot): fff01b24dd/validator_client/slashing_protection/src/slashing_database.rs (L629-L633) This lead to spurious failures (in the form of `ConsistencyError`s) when importing an interchange containing no new blocks for any of the validators. This wasn't hard to trigger, e.g. export and then immediately re-import the same file. ## Proposed Changes This PR fixes the issue by simplifying the import so that it's more like the import for attestations. I.e. we make the assert true by always pruning when the imported file contains blocks. In practice this doesn't have any downsides: if we import a new block then the behaviour is as before, except that we drop the `signing_root`. If we import an existing block or an old block then we prune the database to a single block. The only time this would be relevant is during extreme clock drift locally _plus_ import of a non-drifted interchange, which should occur infrequently. ## Additional Info I've also added `Arbitrary` implementations to the slashing protection types so that we can fuzz them. I have a fuzzer sitting in a separate directory which I may or may not commit in a subsequent PR. There's a new test in the standard interchange tests v5.2.1 that checks for this issue: https://github.com/eth-clients/slashing-protection-interchange-tests/pull/12		2022-01-04 20:46:44 +00:00
..
test_generator.rs	Fix assert in slashing protection import (#2881)	2022-01-04 20:46:44 +00:00