Research Area: Validity Proofs to Improve Interop Scalability

Can validity proofs be utilized to improve the scalability of the interop protocol? It isn't immediately clear if they can without first shipping the devnet and then seeing how much throughput the system can handle safely. After that, it should be more clear where the bottlenecks are and then we can benchmark various ways of integrating zkps into the protocol if necessary.

Right now it is assumed that there will be heavy load in unsafe to safe progression described in the [derivation pipeline](https://github.com/ethereum-optimism/specs/blob/main/specs/interop/verifier.md#derivation-pipeline) - the problem can be modeled using a [graph](https://github.com/ethereum-optimism/specs/blob/main/specs/interop/messaging.md#message-graph). There will also be heavy load for the sequencer when accepting incoming transactions to [build blocks](https://github.com/ethereum-optimism/specs/blob/main/specs/interop/sequencer.md#block-building).

These are two different problems and zkps can be applied for both.

For unsafe to safe progression, the sequencer could send proofs via the p2p network so that the derivation pipeline doesn't need to query for as much remote data. This idea has been explored in by adding a [commitment](https://github.com/ethereum-optimism/specs/pull/259) to the L2 blocks themselves and sending the proofs via [p2p](https://github.com/ethereum-optimism/specs/blob/main/specs/interop/rollup_node_p2p.md). This solution doesn't require zkps but there could be a way to improve our current thinking with them.

For the sequencer accepting transactions, the a zkp could be given to the sequencer along with the user's transaction that removes the need for the sequencer to verify the existence of the initiating message before including in a block. This seems like a more promising application, although it isn't immediately clear if this would be a huge gain given the state of zkp proof generation times. Given slight spec changes, it may be possible to make the proof generation times fast enough for this to work. Instead of using an absolute log index, a tx index + relative log index can be used in the identifier and it will greatly speed up zkp proof generation time.

An example of using sp1 for the sort of proof that is required for these solutions can be found here: https://github.com/puma314/verified-logs/

We also need to be very mindful of the downsides if people are able to create fraudulent proofs. No user funds can ever be at risk if a fraudulent proof can be generated.

Start by reading the interop derivation pipeline, message graph, block-building, and rollup_node_p2p specifications linked in the issue, then review the commitment proposal in specs pull request 259 and the verified-logs SP1 example. Measure devnet throughput and identify bottlenecks in unsafe-to-safe progression and sequencer transaction acceptance. Done means benchmarking feasible proof integrations while documenting proof-generation costs and ensuring fraudulent proofs cannot endanger user funds.

Written by the indexing model from the issue text.