[draft] MIP-65: FFS: Fastconfirmation on L2 + MD-65: FFS: Fastconfirmations

.github/CODEOWNERS

@@ -13,5 +13,6 @@
 /MIP/mip-39/ @franck44
 /MIP/mip-53/ @l-monninger
 /MIP/mip-58/ @primata @apenzk
+/MIP/mip-65/ @apenzk
 /MIP/mip-88/ @apenzk @Primata
 /MIP/mip-91/ @apenzk

.vscode/spellright.dict

@@ -1,5 +1,9 @@
+Changelog
 Fastconfirmation
+Fastconfirmations
 multisig
+protoBlock
+protoBlocks
 timelock
 timelocks
 trustlessness

MD/md-65/README.md

@@ -0,0 +1,50 @@
+# 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 on L2 (off-L1).
+
+**Justification**: A fast confirmation process enables timely communication of guarantees and improves user experience. It enhances user confidence and enables real-time transaction validation.
+
+### 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**: Storing certificates to the DA layer ensures that the system can provide guarantees to users in real-time.
+
+### 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.
+
+### D5: Alignment of stakes between L1 and L2
+
+**User Journey**: The stakes on the L1 and L2 are aligned to ensure correct security guarantees.
+
+**Justification**: The security guarantees of the L2 should be aligned with the security guarantees of the L1.
+
+### D6: Rewarding Validators
+
+**User Journey**: Validators are rewarded for providing Fastconfirmations.
+
+**Justification**: Validators should be incentivized to provide Fastconfirmations.
+
+## Changelog

MIP/mip-65/README.md

@@ -0,0 +1,94 @@
+# MIP-65: FFS: Fastconfirmations
+
+- **Description**: Fast-Finality Settlement : Fastconfirmations as confirmations on the L2.
+- **Authors**: Andreas Penzkofer
+- **Desiderata**: [MD-65](https://github.com/movementlabsxyz/MIP/blob/mip/L2confirmation/MD/md-65/README.md)
+
+## Abstract
+
+This MIP introduces Fastconfirmations on L2 as confirmations in addition to Postconfirmations. Fastconfirmations are a way to settle transactions on the L2 with fast confirmation times, but with potentially lower security (e.g., lack of long-range attack protection). This is achieved by using the L2 as a confirmation 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 and provide protection against particular attacks (such as long-range attacks, see [MD-4)](https://github.com/movementlabsxyz/MIP/pull/5) they are slow due to the finality time on Ethereum, and also expensive due to high 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 confirm transactions on the L2 with low latency, 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, where the consensus is driven by a BFT protocol. Similarly, Fastconfirmations can draw from the consensus progress on protoBlocks on L2, which is similarly driven by a BFT protocol.
+
+## 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.*
+
+### Components
+
+Abstractly an L2 chain consist of the following main components:
+
+- a ledger
+- a sequencer with Data Availability (DA)
+- 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.*
+
+### Operator chain
+
+The *operator chain* is a ledger that is dedicated to
+
+- handling reward distribution for sequencer,
+- handling reward distribution for FFS validators,
+- verification and recording Fastconfirmations.
+
+We require the operator chain
+
+- is protected by a high security level.
+- has low latency to finality.
+- has low fees.
+- Throughput and fees should not be impacted by load on other chains in the cluster that is operated by a shared sequencer.
+
+> :warning: At this point it is not clear, whether the VM that drives the operator chain should be operated by the FFS mechanism or the sequencers. The former has lower security, as the security then depends on both FFS validators and sequencers. The latter adds complexity, as it requires the sequencers to run a VM, albeit potentially a simple one.
+
+### Fastconfirmation
+
+We take inspiration from the Postconfirmation design, see [MIP-37](https://github.com/movementlabsxyz/MIP/pull/37). Similarly to recording confirmations on the L1, here we record the commitments of FFS validators on the operator chain, see Figure 1.
+
+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.
+
+### Shared sequencing and multi-chain clusters
+
+We design for a cluster-based solution with a shared sequencer at the core. This means that a sequencer serves multiple ledgers (also called chains).
+
+Validators can query for new protoBlocks and separate their transactions out by namespace. (Or alternatively validators could request based on namespace and receive a transaction stream specific to the chain.) For simplicity we refer to a protoBlock when discussing the pre-stage of the next L2Block, but in a shared setting protoBlock[namespace] would be more accurate.
+
+Nodes can choose to specialize on a given chain, which significantly reduces hardware requirements. With the introduction of the operator chain, the node has to follow the operator chain in addition to its specialized chain. Thus the load on the operator chain should be kept low.
+
+### ProtoBlock to L2Block mapping
+
+The protoBlock output by the sequencer is the input to the L2Block calculation. The mapping from protoBlock to L2Block is deterministic and can be calculated by any validator. The mapping is a function of the state of the ledger and the transactions in the protoBlock.
+
+The protoBlock production may be high frequent, e.g., every 500ms. The L2Block production may be less frequent, e.g., every 4 seconds. And thus an L2Block may contain multiple protoBlocks.
+
+## Alternative considerations
+
+**Operator chain vs own chain for Fastconfirmations**
+It could be considered that Fastconfirmations are recorded on the chain itself. However, we carefully must consider the security implications of this. The operator chain is a dedicated chain that is optimized for guaranteed throughput for confirmations and low fees.
+
+## Reference Implementation
+
+## Verification
+
+## Changelog
+
+## Appendix
+
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).