# Preconfirmations Glossary & Requirements

# Glossary

- **Preconfirmation** - an early commitment of transaction inclusion and/or execution (ranging from the post transaction state root commitment to weaker inclusion commitment), requested by the user and committed to by an actor having full or partial monopoly on the next rollup sequence.
- **Preconfirmer** - the entity committing to preconfirmation. Requires to have monopoly over the upcoming rollup sequence to enforce the inclusion and ordering, and guarantee the resulting post state honouring the preconfirmation.
- **Validity Conditions** - set of constraints that a sequence needs to comply with in order to be considered valid.
- **Enforcement** - an action of the Preconfirmer defining the validity conditions for the upcoming rollup sequence. Used to constrain the sequence to honour the preconfirmations.
- **Preconfirmation Tip** - an amount mutually agreed by the user and preconfirmer to be paid for the preconfirmation.
- **Preconfirmation Request** - an intent (signed message, transaction or else) sent by the user indicating the desire for a preconfirmation of a specific transaction.
- **Preconfirmation Commitment** - a cryptographic commitment from the Preconfirmer to enforce the preconfirmation specified by the preconfirmation request or be punished otherwise.
- **Preconfirmer Eligibility Criteria** - a set of criteria that an actor must satisfy in order to be eligible to be a preconfirmer.
- **Liveness fault** - a misbehaviour by the Preconfirmer characterised with missed enforcement
- **Safety fault** - a misbehaviour by the Preconfirmer characterised with enforcing validity conditions that do not honour the preconfirmation commitment.
- **Inclusion Preconfirmation** - a preconfirmation that a transaction will be included in the next rollup sequence
- **State Preconfirmation** - a preconfirmation that a transaction will be included in the next rollup sequence and commitment to the resulting post state.

# Requirements

The following is a list of requirements that preconfirmations-enabled based rollup should support. It is purposefully broad enough in order to not limit the design space of preconfirmations:

- **Binding actionable preconfirmations** - preconfirmation requests and their corresponding commitments must be:
- **Interpretable -** preconfirmers being able to interpret the requests of the user
- **Operable** - preconfirmers being able to execute/fulfill the request
- **Cryptographically binding** - both request and commitment must be cryptographically provably binding.
- **Preconfirmation of inclusion** - users can request and receive commitments for preconfirmation of inclusion of a transaction.
- **Preconfirmation of post-state** - users can request and receive commitments for preconfirmation of inclusion of a transaction and a specified valid post-state.
- **Preconfirmer Discoverability** - users have direct (i.e. p2p) or indirect (via relay) mechanism to communicate with the eligible suitable preconfirmers in the lookahead in order to submit preconfirmation requests.
- **Low latency** - users request preconfirmations and receive commitments synchronously within time $\texttt{T}_L$ (i.e. 100ms)
- **Permissionless preconfirmer role** - no special permission is required for an actor to perform the role of preconfirmer as long as they meet the Preconfirmer Eligibility Criteria (i.e. they have staked $\texttt{S}_P$ value, offer a public endpoint for connection, etc).
- **Economic Viability** - The system does not rely on altruism of any actor and honest actors are properly compensated for their duties.
- **Preconfirmation Tip Pricing** - users can discover fair price for their preconfirmation tip
- **Economic Security** - The Preconfirmer Eligibility Criteria includes $\texttt{S}_P$ ETH collateral at stake to make it economically unviable for a preconfirmer to perform an attack on the system.
- **Limited blockspace** - only $\texttt{T}_L$ gas (i.e. 10% of block limit) can be used by preconfirmations in any sequence
- **Fair commitment exchange** - it is safe for both users and preconfirmers to engage in a preconfirmation request-response flow. No party can cause punishment to the other through withholding information.
- **Misbehaviour detection** - a reneged preconfirmation commitment can be detected and deterministically proven
- **Misbehaviour punishment** - a preconfirmer whose misbehaviour - Liveness fault, Safety fault or else - is detected is punished by fully or partially slashing their stake $\texttt{S}_P$.
- **Replay protection** - the protocol enforces both the preconfirmed transaction and the preconfirmation commitment to be actionable just once.
- **Ethereum alignment** - the mechanism is aligned with the shared end-game vision. It strives to increase the economical and non-economical value of the Ethereum ecosystem.

---

# Discuss the addition of (Comment on this if you’d like to propose an addition)