[review] MIP-71: Informer V1 for the Operation of the Lock/Mint Native Bridge

.github/CODEOWNERS

@@ -7,12 +7,11 @@
 /MIP/mip-0/ @l-monninger @apenzk
 /MD/md-0/ @l-monninger @apenzk
 /MG/mg-0/ @l-monninger @apenzk
-
-/MIP/mip1/ @l-monninger
-
+/MIP/mip-1/ @l-monninger
 /MD/md-3/ @l-monninger
-
 /MIP/mip-15/ @l-monninger @apenzk
 /MD/md-15/ @l-monninger @apenzk
 /MIP/mip-39/ @franck44
 /MIP/mip-53/ @l-monninger
+/MD/md-71/ @apenzk
+/MIP/mip-71/ @apenzk

MD/md-71/README.md

@@ -0,0 +1,39 @@
+# MD-71: Informer service for the Lock/Mint-based Native Bridge
+- **Description**: Provide a component that informs about the total circulating supply of \$MOVE across L1 and L2.
+- **Authors**: [Author](mailto:[email protected])
+
+## Overview
+
+Several components should react if the bridge is under attack or faulty. In particular, the considered components are the Insurance Fund, see [MIP-50](https://github.com/movementlabsxyz/MIP/pull/50) and the Rate Limiter, see [MIP-56](https://github.com/movementlabsxyz/MIP/pull/56), and more generally the governance operator.
+
+The Operator that controls these components requires knowledge about the states of minted or locked tokens on L1 and L2. The Operator is an entity (e.g. multisig human) that has the ability to sign transactions and send funds from the Security Fund. Moreover, the operation of these components may also be handled via a governance, which could also rely on state information.
+
+This MD requests to provide an informing service that satisfies the above.
+
+## Desiderata
+
+### D1: Provide information about the circulating supply on L2
+
+On the L2 the bridge contract mints \$MOVE token when token should be transferred to L2. When tokens are transferred to L1, the user burns provably some tokens on L2. The Informer should learn about those two supplies and provide information about the current circulating \$MOVE supply on L2.
+
+### D2: Provide information about the locked supply on L1
+
+On the L1 the L1 bridge contract locks any \$MOVE token that should be transferred to L2 in a bridge pool. When \$MOVE token should be transferred to L1 the L1 bridge contract releases tokens held by the bridge pool. The operator should be informed about the locked amount.
+
+### D3: Optional: Provide information about the inflight tokens
+
+Provide information about the inflight tokens. This includes tokens that are not yet processed by the relayer, as well as tokens that are processed (i.e. the `complete` transaction is in a block on the target chain) but not yet finalized.
+
+### D4: Define what it means for the Native Bridge to be secure
+
+Based on the variables above the informer should derive a metric that can provide a warning if the metric seems incorrect. It has to be defined what means incorrect.
+
+### D5: Explore implications if relayer does not utilize postconfirmations
+
+The postconfirmation process is a synchronization mechanism for L2 to L1, see [MIP-37](https://github.com/movementlabsxyz/MIP/pull/37).
+
+If the Relayer completes transfers from L2 to L1 without awaiting postconfirmation of the L2 `initiate` transaction, synchronization guarantees are reduced. The postconfirmation is an anchoring mechanism that binds the L2 to a certain L2 block height and hash, and hinders reorgs beyond a certain depth on L2.
+
+We need to check the implications for the Informer if the Relayer ignores postconfirmations.
+
+## Errata

MIP/mip-71/README.md

@@ -0,0 +1,104 @@
+# MIP-71: Informer V1 for the Operation of the Lock/Mint Native Bridge
+
+- **Description**: The Informer collects data from L1 and L2 about the supply of \$MOVE tokens and forwards the information to relevant parties, which is critical for the safe operation of the Native Bridge.
+- **Authors**: [Andreas Penzkofer](mailto:[email protected])
+- **Desiderata**: [MD-71](../../MD/md-71)
+
+## Abstract
+
+The Informer V1 (hereafter simply called Informer) for the Lock/Mint-Native Bridge (in the following simply referred to as Native Bridge) is introduced to collect information about the state from L1 and L2 and provide this information to components of the **Governance** or the **Governance Operator**. The information is not based on the total supply but rather circulating supply on L2 and locked supply on L1. The provided information is critical for the safe operation of bridge components such as the Rate Limiter, the Security Fund, and the Bridge Operator.
+
+The Informer V1 is limited in scope and capabilities with the intention that future releases will expand its monitoring capabilities. For example the calculation of inflight tokens is optional in this version, and is listed for future versions.
+
+## Motivation
+
+Several components should react if the bridge is under attack or faulty. In particular, the considered components are the Insurance Fund, see [MIP-50](https://github.com/movementlabsxyz/MIP/pull/50) and the Rate Limiter, see [MIP-56](https://github.com/movementlabsxyz/MIP/pull/56).
+
+The Operator that controls these components requires knowledge about the states of minted or locked tokens on L1 and L2. The Operator is an entity (e.g. multisig human) that has the ability to sign transactions and send funds from the Security Fund. Moreover, the operation of the components may also be handled via a governance, which could also rely on state information.
+
+## Context
+
+We refer to the following illustration for a bridge transfer from L1 to L2, which is taken from [MIP-58](https://github.com/movementlabsxyz/MIP/pull/58).
+
+![L1 to L2 Transfer](L1ToL2.png)
+*Figure 1: Illustration of L1 to L2 token transfer process.*
+
+## 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.
+
+![Overview](overview.png)
+*Figure 1: Dependencies of components on the Informer mechanism in the Native Bridge.*
+
+The Informer collects information about the state of \$L1MOVE and \$L2MOVE and provides this information to the Governance Operator who controls relevant components of the Native Bridge. The Informer is a trusted component that is critical to the safe operation of the Native Bridge.
+
+1. The Informer is a component that MUST run a node or client on L1 and on L2 to be able to extract information about the states of the chains.
+1. On L1 the Informer SHOULD read the supply `L1MOVE_locked` of \$L1MOVE token at the finalized state.
+1. On L2 the Informer SHOULD read the circulating supply `L2MOVE_minted` of \$L2MOVE token at the finalized state. The `L2MOVE_minted` value MUST consider the amount of burned tokens through transfers from L2 to L1 (`initiate_transfer` calls on L2), such that the `L2MOVE_minted` represents the circulating supply of \$L2MOVE on L2.
+1. Since L1 blocks have timestamps we say the Informer reads `L1MOVE_locked` at time `t_L1`.
+1. We assume that L2 blocks acquire timestamps from the sequencing protocol, e.g. Celestia. Thus the Informer reads `L2MOVE_minted` at time `t_L2`.
+
+> [!NOTE]
+Instead of the finalized state we could also consider the $k$-confirmed state for the L1. The definition of $k$-confirmed is given in [Issue-838](https://github.com/movementlabsxyz/movement/issues/838). Similarly, for the L2, we could assume some different confirmation level like the fast-confirmation, see [MIP-65](https://github.com/movementlabsxyz/MIP/pull/65).
+
+Since the Relayer may use a confirmation level that is not the finalization, we add the following requirement:
+
+6. The confirmation levels for the Informer MUST be the same as for the Relayer.
+
+#### Dissemination of information
+
+We do not prescribe a particular dissemination method.  In case the Informer detects possible threat, the Informer MAY provide the information to the Governance Operator via publishing a notification and which then alerts the Operator via a PagerDuty service to relevant personal.
+
+#### Locked and minted supply difference
+
+The Informer MUST provide the information about the difference of locked \$L1MOVE and minted \$L2MOVE supply `MOVE_diff`. This indirectly informs, whether there is an issue with the total circulating supply of \$MOVE across the L1 and L2. The Informer provides this information at time `t'`, where `t' ~ max{t_L1,t_L2}`). It is approximate, since the local time of the informer may differ from the chain clocks. However, it can only provide guarantees for `t = min {t_L1,t_L2}`, which is discrete block time.
+
+The Informer MUST measure `MOVE_diff(t) = L1MOVE_locked(t_L1) - L2MOVE_mint(t_L2)` and the condition `is_MOVE_diff_safe = (MOVE_diff < 0)`.
+
+> [!NOTE]
+`CONDITION_1` :  The Informer warns if `is_MOVE_DIFF` is false. This is because in this scenario the circulating supply exceeds the maximum circulating supply `MOVE_Max`.
+
+#### (Optional:) Inflight tokens
+
+The Informer MAY calculate the in-flight tokens. Inflight tokens are tokens that are locked (burned) on L1 (L2) but that are not yet minted (unlocked) on L2 (L1) with a **finalized state**. With respect to finalized states it should be `MOVE_inflight = MOVE_diff`.
+
+We can further differentiate the inflight tokens, however this considers non-finalized events and thus results may not be precise or may even revert.
+
+We can differentiate the following types of inflight tokens:
+
+1. transfer is processed by the Relayer and the `complete_transfer` transaction is recorded on the target chain but not finalized. This includes the sets `L1MOVE_inflight_processing` and `L2MOVE_inflight_processing`.
+1. transfer is initiated on source chain but the Relayer has not yet processed the transfer. This includes the sets `L1MOVE_inflight_init` and `L2MOVE_inflight_init`.
+
+The Informer can measure `L1MOVE_inflight_processing` and `L2MOVE_inflight_processing` by reading the non-finalized state of the respective chain.
+
+## Recommendations
+
+#### Possible measurement errors
+
+The timestamps of the two layers are not synchronized. We assume that the difference is negligible, however, for correctness, the implications of a drift between the L1 and L2 clocks should be considered. Moreover, the clocks of the layers progress discretely. This means that the Informer reads events from L1 and L2 with slightly different time stamps. This timestamp difference can introduce errors in the calculation of circulating token.
+
+#### Slow chain
+
+The Informer may receive block events delayed from one of the chains. Consequently, finalized `complete_transfer` transactions on the target chain could be read before their respective `initiate_transfer` counterpart from the source chain. In this case the `MOVE_diff` could trigger `CONDITION_1` albeit the chains are safe. To improve on this, the Informer SHOULD only consider transfers for which the `initiate_transfer` is on the target chain.
+
+We currently have a counter called `nonce` implemented. Since this counter strictly increases on the source chain, we could improve the Informer by keeping two types of lists locally off-chain: `LtargetMOVE_completed_but_init_missing` and `LtargetMOVE_completed_with_init`. The Informer SHOULD only consider `LtargetMOVE_completed_with_init` and updates the list when the corresponding `initiate_transfer` becomes available.
+
+#### UNSAFE Relayer operation and reorg protection
+
+The postconfirmation process is a synchronization mechanism for L2 to L1, see [MIP-37](https://github.com/movementlabsxyz/MIP/pull/37). It is also an anchoring mechanism that protects against reorgs. If the Relayer only processes postconfirmed states, this forces synchronization between L2 to L1.
+
+If the Relayer is set up to operate in an UNSAFE mode and completes transfers based on only fast-confirmations, see [MIP-65](https://github.com/movementlabsxyz/MIP/pull/65), or even simply based on states computed from protoBlocks that are issued by the sequencer, the Relayer SHOULD warn about this or the operator MUST at least be aware of this.
+
+## Reference Implementation
+
+## Verification
+
+Needs discussion.
+
+---
+
+## Errata
+
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).