Feat: ExEx op-proposer

[0xKitsune]

Describe the feature

The eth_getProof endpoint currently lacks support for storage proofs at historical blocks. The op-proposer must retrieve proofs from historical blocks for the L2ToL1MessagePasser account in order to submit WithdrawalProofs and facilitate withdrawals from L2 -> L1 for the OP stack.

Instead of unwinding the state to the specified block and calculating the storage proof, we can implement the op-proposer logic as an ExEx, getting a storage proof every n blocks or at some specified interval. The ExEx would then create a transaction that would post the proof to the L2OutputOracle on L1.

We can get started working on this now.

Additional context

No response

[0xOsiris]

We are thinking through an approach and our current design for the ExEx to act as the proposer & submit withdrawal proofs every SUBMISSION_INTERVAL specified via the config. In the event that a transaction is not included on L1 due to congestion, out of funds, etc. and a proof is needed from a historical block we are thinking that the proofs could be stored in some persistent storage (Postgres db for example).

There still exists a risk where reading/writing to the db could fail. Since withdraws depend on proofs being submitted, it might be valuable to have a fallback for edge cases where the historical proof is recomputed in memory by unwinding the db. We could also rely on an fallback endpoint that could fetch the historical proof (geth client for example).

Ideally there is a mechanism that can guarantee that historical proofs are able to be fetched in edge cases resulting from transaction failure. Let me know if you have any thoughts on this.