Validator ensures canonical chain

[sergerad]

Current state of the Validator

When asked to sign a block (SignBlock RPC), it:

1. Deserializes the ProposedBlock
2. Checks that every transaction ID in the block exists in its local validated_transactions table (i.e. was previously submitted via SubmitProvenTransaction)
3. Calls proposed_block.into_header_and_body() to build the header
4. Signs the header

It does not:

• Track the chain tip
• Verify prev_block_commitment links to the last block it signed
• Verify block_num is sequential
• Verify chain_commitment (the MMR) is consistent
• Verify the previous block's signature

The validator is completely stateless with respect to the chain. Its database only stores validated transactions — no block headers, no chain tip, no history.

Proposed Changes

The original comment chain explains the suggested changes in order to complete this issue:

I think the validator should make sure the block it is signing is the valid next block in the chain (for some reason, I thought that was already the case, but if not, let's create an issue for this).

The way it could work:

• We use the validator to "bootstrap" the genesis block (I think this is what this PR is about, but I haven't reviewed the details yet). This results in the validator keeping track of the chain tip (which is at first just the genesis block).
• For any new block that the validator needs to sign, the validator:
• Makes sure that all transactions in the block are the ones it has seen/validated before (we already do this, I believe).
• Makes sure that given this transactions, we get the block header that we need to sign (we already do this, I believe).
• Makes sure that the new block header is built on top of the previous block. This may also require checking consistency of account and nullifier tree updates (it may be possible to incorporate this in the above two checks, but I'm not 100% sure).
• If all looks good, the validator signs the block, and sets the new block's header as the chain tip.

Originally posted by @bobbinth in #1764 (comment)

[sergerad]

This may also require checking consistency of account and nullifier tree updates
@bobbinth what do you mean by this?

Is this something that is done by comparing chain tip against proposed block? Or do you mean validating proposed block in isolation in with respect to account and nullifier tree updates?

[bobbinth]

Basically, we need to make sure that given an account tree root from block $n$ and a set of updates in block $n+1$, we get the account tree root in block $n+1$ (and the same for nullifier tree).