Hey, not sure it's worth it but locking validators into a genesis_time (once we know it) might also be useful to help a scenario where a validator connects to the wrong network (i.e., testnet node) and starts signing shit in the future (according to their native chain). The genesis_validators_root should stop this from being slashable, but perhaps it would still cause issues?

Sorry bit of a brain dump message, just didn't want to forget.

This is finally ready for review!

Here's a quick overview:

• SlashingDatabase is an interface to an SQLite database stored by default in ~/.lighthouse/validators/slashing_protection.sqlite which records all of the attestations and blocks signed by validators. It contains a table of known (registered) validators, for which it tracks signatures and allows new signatures.
• For now, new validators can only be registered with slashing protection using the --auto-register flag on the validator client. In future we should look at better (and safer) usage patterns like registration from the account manager, or via the HTTP API.
• Concurrency-related bugs (see parallel_tests.rs) are prevented in 3 ways, in the spirit of Defense in Depth:
  1. The database is put into locking_mode=EXCLUSIVE, which instructs SQLite to only allow a single connection to the database (see docs).
  2. All database transactions operate in EXCLUSIVE mode.
  3. Uniqueness constraints on the signed_attestations and signed_blocks tables prevent double votes at the schema-level. Only surrounding attestations could be entered into the database by parallel writers, if they were allowed.
• Attempts to sign the same block or attestation twice will be gently refused. Although this would be safe, the beacon node seems to dislike duplicate blocks and attestations (open to changing this).

All review comments have been addressed I think, just waiting on CI to pass.

Regarding the domain, you're right. Unless we stored a mapping from validator -> slot -> domain -> block, we can't support signing on multiple chains. And I agree the complexity wouldn't be worth it. I switched from storing the object root to storing the signing root in the database because it felt right to store the actual data being signed, and it prevents a peculiar case where a beacon node (malicious or otherwise) tries to get us to sign what appears to be "the same" attestation data with a different domain (which at the time I thought was slashable, but as you point out, is not). My general thinking with the slashing database was to only prevent slashing, and not try to prevent other strange signings that aren't slashable, as those can be the responsibility of the rest of the VC (making sure we're on the right chain, etc). But some false positives, if they simplify the design, seem tolerable.

I added a test (invalid_double_vote_diff_data) to check a mutation to the beacon_block_root, although a previous attestation mutating test existed (invalid_double_vote_diff_target which changes the target root).