Ahead of time auction for prover incentives

[ggonzalez94]

Fixes #15

This PR includes the design for an implicit ahead of time auction and all the logic and accounting necessary for taking proposers' fees and paying and slashing provers. It implements the design exposed here.

Some design assumptions

• The ProverManager contract implements two interfaces, the IProposerFees and the IProverManager interfaces. It is called by the Inbox contract to pay the fees for each proposal and calls the CheckPointTracker when proving publications.
• When deployed an initial prover is set. This simplifies some of the logic, as we can assume there's always an active period(making the implementation more efficient), and proposers can directly submit publications. This shouldn't be an issue, as the rollup operator can set themselves as an initial prover, with a high enough fee so that other participants can outbid them relatively easily.
• This design assumes only sequential proving is allowed, so Simplify the CheckpointTracker by storing only the latest checkpoint #56 should be implemented. Every proof starts from the latest known checkpoint and advances the chain, there's no need to track transitions. This makes the market design easier since we don't need to keep track of separate proving deadlines, or non consecutive periods.

What this PR does not include

These is a list of things this PR does not include to keep the scope manageable. These will be submitted as separated PRs or tracked as separate issues.

• Gas optimizations(will be submitted as a separate PR). Particularly packing the Period struct into only two slots yields ~20% gas improvements.
• Logic for a permissioned actor(e.g. a DAO) to change some of the parameters(livenessWindow, livenessBond, etc.)
• How to price delayed publications(since we still need to decide if we will price them differently). The contract has the parameters necessary to deal with delayed publications, but would still need some adjustments. Tracked under Price delayed publications for proving and modify the ProverMarket #68
• Logic to work with ERC20 tokens. Tracked under Allow using ERC20 tokens in the ahead of time auction #51

[nikeshnazareth]

Should we unite livenessWindow and provingWindow?

• I think we want provingWindow to be at least as large as livenessWindow, because otherwise a publication can come in on the end timestamp, and you will only have provingWindow to prove it.
• On the other hand, there doesn't seem to be a reason for provingWindow to be larger than livenessWindow.

Similarly, is there any reason that exitDelay and successionDelay are different? Both of them are commented saying they allow for enough time for the auction + spin up hardware. Are these supposed to be two different phases of time (i.e. I won't know if I need to spin up my hardware until I know if I won the auction)?

Also, there is something a little suspicious about the zero deadline for evicted provers. It does mean that the evicted prover is still responsible for some future publications (up to exitDelay from now) but are not given any time where they have monopoly proving rights. Perhaps this is okay because they've already failed to prove so maybe losing the stake based on future publications is just one of the costs.

[LeoPatOZ]

Similarly, is there any reason that exitDelay and successionDelay are different? Both of them are commented saying they allow for enough time for the auction + spin up hardware. Are these supposed to be two different phases of time (i.e. I won't know if I need to spin up my hardware until I know if I won the auction)?

Im really of the opinion that exit and succession delay should be merged - #49 (comment)

[ggonzalez94]

@nikeshnazareth @LeoPatOZ

Should we unite livenessWindow and provingWindow?

I do think there’s some value in keeping the two values separated as explained [here](#49 (comment)), but it is not a strong opinion, so I’m happy to unify them if there’s consensus on it.

is there any reason that exitDelay and successionDelay are different?

Similar to the above, I do see some value but also is not a very strong opinion. Here’s a case for keeping them separated:

• successionDelay might be kept at a higher value, ensuring provers don’t have a very short period if they are quickly outbid for whatever reason. This does not hurt chain liveness since the prover has not shown any liveness failure.
• exitDelay especially in the case where a prover has shown a liveness issue might be chosen to be relatively short, since the chain cannot finalize until we switch to a new period.

Also, there is something a little suspicious about the zero deadline for evicted provers. It does mean that the evicted prover is still responsible for some future publications (up to exitDelay from now) but are not given any time where they have monopoly proving rights. Perhaps this is okay because they've already failed to prove so maybe losing the stake based on future publications is just one of the costs.

Yeah, this is my assumption basically. We would be ok with ending their period immediately, the only reason we don’t do that is to allow for the auction to happen.