[draft] (MIP65): FFS: FastConfirmation on L2

.github/CODEOWNERS

@@ -16,3 +16,4 @@
 /MD/md-15/ @l-monninger @apenzk
 /MIP/mip-39/ @franck44
 /MIP/mip-53/ @l-monninger
+/MIP/mip-65/ @apenzk

GLOSSARY.md

@@ -13,3 +13,6 @@ ERC-20 type token for the Movement Network with the source contract on L1. See a
 
 **Native Bridge**
 The bridge that allows the transfer of tokens between L1 and L2, which hold `$L1MOVE` and `$L2MOVE` token, respectively. The native bridge has the capability to mint `$L2MOVE` tokens. > [MG-39](./MG/mg-39/README.md)
+
+**ProtoBlock**
+The blocks that are output by the sequencer. The sequencer is not aware of the state of the chains that it serves. Chains can ingest relevant transactions from the protoBlocks.

MD/md-65/README.md

@@ -0,0 +1,37 @@
+# MD-65: FFS: Fastconfirmations
+- **Description**: Fast-Finality Settlement : Fastconfirmations as confirmations on the L2.
+- **Authors**: [Andreas Penzkofer]()
+
+## Overview
+
+This MD requires fastconfirmations on L2 in addition to postconfirmations. Fastconfirmations are a way to settle transactions on the L2 with fast confirmation times. This is achieved by using the L2 as a settlement layer.
+
+See also [MIP-34: Fast Finality Settlement](https://github.com/movementlabsxyz/MIP/pull/34).
+
+## Desiderata
+
+### D1: Efficient Fastconfirmation Certificate Generation
+
+**User Journey**: The system quickly generates an availability certificate upon receiving enough votes from Validators off-L1.
+
+**Justification**: A fast confirmation process enables timely communication of guarantees and improves user experience.
+
+### D2: Decentralization of the approach
+
+**User Journey**: The system is designed to be decentralized.
+
+**Justification**: Decentralization is a core principle of blockchain technology, ensuring security and resilience.
+
+### D3: Storage of the certificates to the DA layer
+
+**User Journey**: Validators provide confirmation guarantees to the Data Availability (DA) layer within seconds.
+
+**Justification**: Quick confirmation enhances user confidence and enables real-time transaction validation.
+
+### D4: Synching of the L2 with the L1
+
+**User Journey**: The L2 is in sync with the L1. Validators should not be able to provide fastconfirmations on the L2 for different blocks than the postconfirmations on the L1.
+
+**Justification**: There should be a way to ensure eventual consistency between the L1 and the L2. This may require slashing validators that provide fastconfirmations on the L2 for different blocks than the postconfirmations on the L1.
+
+## Errata

MIP/mip-65/README.md

@@ -0,0 +1,70 @@
+# MIP-65: FFS: Fastconfirmations
+
+- **Description**: Fast-Finality Settlement : Fastconfirmations as confirmations on the L2.
+- **Authors**: [Andreas Penzkofer]()
+- **Desiderata**: [MD-65](../../MD/md-65/README.md)
+
+## Abstract
+
+This MIP introduces Fastconfirmations on level 2 (L2) as confirmations in addition to Postconfirmations. Fastconfirmations are a way to settle transactions on the L2 with fast confirmation times. This is achieved by using the L2 as a settlement layer for the [Fast Finality Settlement mechanism](https://github.com/movementlabsxyz/MIP/pull/34).
+
+## Motivation
+
+We introduce Postconfirmations on L1 in [MIP-37](https://github.com/movementlabsxyz/MIP/pull/37). While Postconfirmations partially draw from Ethereum security, they are  slow due to the finality time on Ethereum, and also expensive due to high L1 (Ethereum) fees.
+
+In contrast, finality times on the L2 are much faster and fees are much lower. This justifies the introduction of Fastconfirmations on the L2 as a way to settle transactions on the L2 with fast confirmation times, but without any additional security guarantees from the L1.
+
+Postconfirmations are a simple yet elegant design which permits implementation with
+
+- high decentralization capability
+- no requirements on p2p networking between validators
+- no consensus required.
+
+Postconfirmations can draw from the consensus progress on L1. Similarly, Fastconfirmations can draw from the consensus progress on protoBlocks on L2, which is independent of the confirmation of states.
+
+## Specification
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
+
+### Assumption
+
+Abstractly an L2 chain consist of the following main components:
+
+- a ledger
+- a (shared) sequencer with Data Availability
+- a validator set that confirms the ledger.
+
+The sequencer outputs protoBlocks, which are ingested by validators. From these protoBlocks, the validators calculate the state of the ledger and calculates the next L2Block.
+
+![alt text](design.png)
+*Figure 1: Fastconfirmation design.*
+
+A shared sequencer can serve multiple ledgers (also called _chains_). Validators can query for new protoBlocks and separate their transactions out by namespace. Alternatively validators could request based on namespace and receive a transaction stream specific to the chain. For simplicity we continue to refer to a protoBlock when discussing the pre-stage of the next L2Block but in a shared setting protoBlock(namespace) would be more accurate.
+
+### Operator chain
+
+We assume the sequencer operate a chain to handle the protoBlocks and reward distribution to sequencer nodes. This chain is called the _operator chain_.
+
+We require the following additional properties:
+
+- It performs a consensus algorithm that is fast and has a low finality time.
+- It has a high security level.
+- It can run simple smart contracts. In particular we require to run a contract that can check supermajority of validators have signed an L2Block.
+
+### Fastconfirmation
+
+We take inspiration from the Postconfirmation design, see [MIP-37](https://github.com/movementlabsxyz/MIP/pull/37). We introduce Fastconfirmations as a way to settle transactions on the L2 with fast confirmation times. This is achieved by using the ledger of the sequencer as a settlement layer for the Fast Finality Settlement mechanism.
+
+The design is rather similar to the Postconfirmation design. However it requests additional properties from the operator chain, see above. The sequencer chain acts as the settlement layer and we thus inherit the security properties of the operator chain for the supermajority check.
+
+## Reference Implementation
+
+## Verification
+
+## Changelog
+
+## Appendix
+
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).