L2: (proposer) persist proposer's state

[fborello-lambda]

Since the state of the proposer/prover_server depends on the last_verified_block or block_committed to the L1 and the zk Proofs coming from the prover_client, there is a need to keep track of the verified proofs and then update the proposer's state.

• If we think that the prover_client just asks for inputs to use, it can be thought as a stateless component, all the state is handled by the proposer.
• The prover_server should store:
  • The latest_verified_block(block verified on the L1) → check if we can get it from a contract.
  • The account_updates of each block.
  • Unsent proofs to the L1, if we want to batch proof verifications.

The complete workflow would be:

• New block is executed.
• Proposer commits to this new block. For this it reexecutes the block to get the account updates. It saves the account_updates on disk.
• The prover server reads from disk the account_updates, creates the execution_db and passes it to the prover client.
• When the client sends the proof to the proof server, the server stores it on disk.

Proposed structure:

1/
    account_updates_1.json
    proof_1.json
2/
    account_updates_2.json
    proof_2.json

• Whenever a new proof is verified on L1, we can delete the account updates file for that block.
• The proposer has to keep track of the latest committed block and the latest verified block.
  • The latest committed block can be tracked by creating a new (empty) directory for the block when the commit is confirmed on L1.
  • The latest verified block can be tracked by querying the L1 contract directly.

We may have to create a verifying contract, described in Issue #1006.

TaskList:

• L2: (proposer) save account_updates after commitment #1005.