Interacting with L1

Espresso is intended primarily for use with rollups, and an essential feature of rollups is that they periodically send verified checkpoints of their state to some other blockchain, the layer 1. In the case of Espresso we have two types of checkpoints:

• HotShot checkpoints record the history and state of HotShot. This includes commitments to all blocks that have been sequenced and the state that is needed to verify new blocks (such as the stake table) starting from the latest checkpoint. These checkpoints are recorded in the sequencer contract and shared by all applications using Espresso.

• Rollup checkpoints record the state of individual rollups, such as the state of an EVM instance. Each rollup records its own checkpoints in its rollup contract. When recording a new checkpoint, the rollup contract will validate the checkpoint against the committed sequence of blocks by reading the historical sequence of block commitments from a corresponding HotShot checkpoint.

Many rollups will not only write their state to the L1, but will also allow information from the L1 to flow back into the rollup. In this case, the interaction with the rollup contract becomes a bridge between the L1 and the rollup, allowing tokens and other information to be exchanged bidirectionally.

Espresso is interesting in that HotShot itself also allows this bidirectional flow of information to and from the L1, specifically regarding the stake table. This allows operations on the L1 to interact with the Espresso staking token, a crucial requirement for implementing restaking, which allows Espresso to share the security budget of the L1 and pass value generated by the sequencer back to L1 validators.

Since state updates are not only written to the L1 but also read back into the HotShot and rollup states, we will hereafter eschew the "checkpoint" terminology and instead refer to HotShot state updates and rollup state updates.

The following sections dive into the use cases for these state updates and explore some of the utility and security properties that L2s are able to derive from the L1 that they use for state updates.