Incentivize proving and set bonds

[ggonzalez94]

In the current version of Taiko protocol, proposers are on the hook to prove their on batches and deposit a livenessBond to make sure they do so(or if they don't do it in time a prover can come and claim a part of their bond).
Under this new design we don't have a specific proposeBatches function in the Inbox, and the DataFeed is intended to be used across multiple rollups.
We would like to have a design where provers are incentivized and compensated to prove multiple publications(regardless of who proposed them), instead of each proposer having to prove their own(which is less efficient).
We would also like a design that is "modular", where the protocol is agnostic to how these incentives work, and each rollup can "extend" this by adding their own mechanism(e.g. some rollup may decide to subsidize proving with token emissions, while others may prefer a prover marketplace that gets the best price per proof)

[nikeshnazareth]

A related thought: we instantiated a design assumption that may be obsoleted by this discussion. Once this is resolved there is a potential simplification.

The Inbox contract currently tracks a mapping of proven checkpoints. There is an effort to use a circular buffer to save storage costs.

However, we could potentially remove the mapping and just save the latest checkpoint.

We currently insist that proofs advance the latest proven checkpoint (i.e. the start checkpoint is already proven, and the end checkpoint has not been yet). We do not insist that the start checkpoint is the latest proven checkpoint. One reason for keeping this behaviour is so a proof cannot be invalidated by someone else.

For instance, if I'm am constructing a large proof between checkpoints 10 to 15, and someone else makes the proof between 10 to 11, my proof is still valid. If we only store the latest proven checkpoint then it would not be valid.

Intuitively I feel like an Inbox should not be opinionated about who provides proofs. There could be multiple people executing proofs for different reasons. However, in practice, there is likely to be a single incentive mechanism and people will want a guarantee that if they create the proof then they will be compensated. When that design is clear, we should revisit whether we need historical checkpoints at all.