Suzuka State Sync Verification

[l-monninger]

Summary

Let's use this PR to clarify some outstanding concerns for Suzuka p2p state sync verification.

The basic premise is described in rfc-24:

• State root is settled on L1 smart contract.
• Syncer fetches the state root from L1 smart contract.
• Syncer requests state over gossip.
• Syncer checks if state leaves are valid via checking Merkle inclusion proof.

What remains to marry this up with #398 and accept or reject tickets?

[musitdev]

Currently, the settlement written on L1 contains:
* The height of the corresponding block.
* The block ID, which is the Celestia block commitment.
* The commitment, which is the hash of the Aptos state proof after block execution.

In Aptos, a state proof is primarily a list of LedgerInfoWithSignatures generated during the current epoch. LedgerInfoWithSignatures consists of two parts:
* The aggregation of validator signatures on a message, which is not used in Movement.
* LedgerInfo, which is mostly BlockInfo containing block data and the executed_state_id, the accumulator root hash after executing the block. The accumulator root hash is calculated using the root hash of the Tx Merkle tree and adding the new tx hashes as leaves (see TransactionAccumulatorDb.put_transaction_accumulator()).

The state proof is generated after each block execution. Only the latest state proof is kept in memory. The database stores the state proof at the beginning / end of each epoch; otherwise, only the most recent one is retained.

From the L1 settlement, the state proof cannot be calculated, and the only way to retrieve a state proof at a specific height is to execute all blocks up to that height.

Therefore, through the gossip network, the only state root that can currently be requested is that of the most recently executed block.

Requesting over gossip would require implementing a specific protocol to ensure the requester receives one and only one response from another node. If we have an ID for the state root, a more efficient method would be to query a single node directly.