Refactor rollup into a consumable library

[ernestognw]

Over the development of the project, I've felt we've been working on multiple tightly related topics without properly gluing them together into the correct abstractions.

Some code smells like comparing commitment to its hashes in the PublicationFeed, or multiple functions permissioned to addresses that seemed to be similar (e.g. checkpoint tracker, signal service) convinced me to experiment building a modular L1Rollup using language features.

By "language features", I mean that the Solidity compiler should guide the developer in how to get started with a simple minimal rollup and then add functionalities as they see fit.

Rationale

I decided to aim for having a single contract on the L1 that is just a "rollup".

I had the gut that multiple concepts were duplicated across the implementations. For example, the current PublicationFeed only defines the PublicationHeader struct and tracks its hashes, where the publications include a commitment that's up to the L2 inbox to understand.

It seems to me that there's a general concept of a single commitment of a publication, and whatever the publication means is left to the implementation. However, for developers to build their own publication formats, they must compose all these implementations and understand where/how to insert their logic.

Minimal Implementation

I'm proposing a minimal implementation of a rollup with the following interface:

interface IL1Rollup {
    event Proposed(bytes32 indexed commitment, bytes publication);
    event Proven(bytes32 indexed commitment);

    event SignalSent(bytes32 indexed value);

    error InvalidProof();
    error UnknownCommitment();
    error UnprovenCommitment();

    function latestCommitment() external view returns (bytes32);
    function nextCommitment(bytes32 commitment) external view returns (bytes32);
    function proposed(bytes calldata publication) external view returns (bool);
    function proven(bytes calldata publication) external view returns (bool);
    function signalSent(bytes32 value) external view returns (bool);
    function isValidTransition(bytes32 from, bytes32 target, bytes memory proof) external view returns (bool);
    function toCommitment(bytes memory publication) external view returns (bytes32);
    function propose(bytes memory publication) external;
    function prove(bytes32 from, bytes32 target, bytes memory proof) external;
    function sendSignal(bytes32 value) external returns (bytes32);
}

Extending to other features

So far, the features we've been discussing like delayed inclusion, preconfirmations (i.e. permissioned proposer) or proving markets (i.e. who can prove) can build on top of these interfaces as overrides to a base implementation. It's up to the developer how they want to handle those cases, and if they want to prove with a simple ECDSA that should be ok.

Though, the library should offer the building blocks to deploy the most decentralized version of a rollup since the beginning. Here are some ideas of how the L1Rollup contract can be extended:

L1RollupDepositable

Multiple use cases to design a rollup involve economic incentives. For those, an extension that allows depositing and withdrawing ETH would be a good extension that is compatible with those use cases

L1RollupProverMarket

An extension that implements @ggonzalez94 work on an ahead-of-time auction for provers. Instead of being a manager contract, the proving market is held within the same rollup instance.

Preconfirmations

Teams can use the L1Rollup contract to override the propose function and set mechanisms to give the proposer rights dynamically.