From 84f7ed70bc4e6a864a1560784ac62d489f4146d8 Mon Sep 17 00:00:00 2001 From: Liam Monninger Date: Fri, 4 Apr 2025 17:38:01 +0800 Subject: [PATCH 01/18] feat: dongmen standards. --- MD/md-n/README.md | 137 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 137 insertions(+) create mode 100644 MD/md-n/README.md diff --git a/MD/md-n/README.md b/MD/md-n/README.md new file mode 100644 index 00000000..c7c235e1 --- /dev/null +++ b/MD/md-n/README.md @@ -0,0 +1,137 @@ +# MD-n: Dongmen (Postconfirmations) Standards + +- **Description**: Provides a set of liveness and correctness requirements for Postconfirmations protocols. +- **Authors**: [Liam Monninger](mailto:liam@movementlabs.xyz) +- **Approval**: :red-cross: +- **Etymology**: These standards were originally drafted in the Dongmen neighborhood of Taipei. + +## Overview + +As identified in [MD-3](https://github.com/movementlabsxyz/MIP/tree/main/MD/md-3), [MD-4](https://github.com/movementlabsxyz/MIP/tree/main/MD/md-4), [MD-5](https://github.com/movementlabsxyz/MIP/tree/main/MD/md-4), [MIP-34](https://github.com/movementlabsxyz/MIP/pulls?page=2&q=is%3Apr+is%3Aopen), and [MIP-37](https://github.com/movementlabsxyz/MIP/pull/37), naive interpretations--such as MCR--of the Postconfirmations protocol fall short of modern BFT expectations. + +We summarize the shortcomings relevant to these standards as follows: + +1. **Asynchronicity**: per [FLP](https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf), asynchronous voting protocols cannot achieve consensus in the presence of one or more faulty processes. Thus, Asynchronous Postconfirmations protocols, i.e., those not defining a Global Stabilization Times, are **not in fact BFT consensus protocols.** MCR, for example--due its single vote per slot without any bound--may remain in permanent disagreement. +2. **Liveness**: failure to come to consensus presents a liveness shortcoming. Permanent disagreement means that the network will never progress to the next accepted state. Further, we assert indefinite disagreement is unnecessary in the context of Postconfirmations. + +For more detailed information on these properties, see [BFT Synchronicity and Liveness](#a1-bft-synchronicity-and-liveness). + +In response to these shortcomings, we request a protocol which is **fully-synchronous**, **fork-transferable**, **fork-perfect**, and **minority-aware**. The last three of these terms are introduced and defined in this MD. + +Because the Dongmen Postconfirmations Standards request a **fully-synchronous** protocol, we assert said protocol can no longer be traditionally-BFT. That is, non-supermajority forks may exist under these standards. For a traditional BFT standard, see the [Ximen Postconfirmations Standards](). + +## Definitions + +- **Fully-synchronous**: A network and protocol assumption in which message transmission and processing are guaranteed to complete within known, fixed bounds. A protocol that assumes this model must commit or reject decisions by a deterministically computable time. + +- **Global Stabilization Time (GST)**: The unknown point in time after which a partially synchronous network behaves synchronously. This term is critical in distinguishing traditional BFT protocols from fully-synchronous ones, which assume GST has already occurred or is always satisfied. + +- **Fork-transferable**: A property of a consensus protocol that allows consumers to transfer application state from a forked chain of consensus rounds while preserving verifiability and auditability, even in the presence of honest partitions or temporary disagreement. + +- **Fork-perfect**: A refinement of PBFT’s intersection safety. A fork is fork-perfect if every round of consensus along the fork intersects with at least one unit of honest voting power *relative to the fork*. This ensures local safety guarantees on a per-fork basis, even in the presence of multiple non-merging branches. + +- **Perfect Expert**: A theoretical construct (adapted from [expert learning models](https://people.csail.mit.edu/ronitt/COURSE/S16/notes7.pdf)) which assumes the existence of a strategy (or sequence of decisions) that would have been globally optimal or correct. In consensus, identifying this expert is analogous to identifying a perfect fork. Fork-perfectness aims to localize this ideal to a given fork in the presence of asynchrony or faults. + +- **Minority-aware**: A protocol property requiring formal understanding and bounded valuation of consensus decisions made by a Byzantine minority. This property mandates a clear risk model quantifying the probability and cost of such decisions under full synchrony when liveness demands finality at fixed times. + +## Desiderata + +### D1: Fully-synchronous + +**User journey**: Consumers of Dongmen Postconfirmations consensus can rely on agreement to be achieved by a know Global Stabilization Time w.r.t. to the confirming ledger. + +**Justification**: A fully-synchronous protocol is a consensus protocol under FLP. It also renders predictable points in time by which consensus will be achieved, offering qualitatively optimal liveness. + +### D2: Fork-transferable + +**User journey**: Consumers of Dongmen Postconfirmations consensus can safely transfer state from the ledger by following a set of standards. + +**Justification**: The transfer of value from a BFT system to other systems is critical in the modern DLT landscape. How to do this safely is critical to both application and general ledger usage. + +### D3: Fork-perfect + +**User journey**: Consumers of Dongmen Postconfirmations consensus can rely on consensus to identify the assumed perfect expert w.r.t. a given fork. + +**Justification**: We assert the perfectness of PBFT argued for in [PBFT and Perfectness](#a2-pbft-and-perfectness) is an essentially quality of modern BFT networks. + +### D4: Minority-aware + +**User journey**: Consumers of Dongmen Postconfirmations consensus can rely on a formalized understanding of the expected value of Byzantine consensus attack w.r.t. the value of the state and intrinsic rewards. This may additionally consider [fork-transferrable](#d2-fork-transferable) stipulations. + +**Justification**: We assert that the [**full-synchronicity**](#d1-fully-synchronous) of Dongmen Protocols complicates BFT assumptions. These complications must be well understood for a given protocol. + +## Appendix + +### A1: BFT Synchronicity and Liveness + +| Model | Network Delays Known? | Bounded? | Known Bound? | +|------------------|------------------------|----------|----------------| +| Synchronous | Yes | Yes | Yes | +| Asynchronous | No | No | No | +| Partially Synchronous | No | Yes, after GST | No | + + +| Feature | Asynchronous | Partially Synchronous | Fully Synchronous | +|-----------------------|---------------------|-------------------------|--------------------------| +| **Message delay** | Unbounded forever | Unbounded until GST | Bounded always | +| **Knowledge of bounds** | None | Exist post-GST (unknown) | Known and fixed | +| **Liveness possible?** | No | Yes, eventually | Yes, by bounds | + +| Feature | Fully Synchronous | Partially Synchronous | +|-------------------------------|-----------------------------------|----------------------------------------| +| **Timing Assumption** | Fixed known bounds | Unknown bounds before GST | +| **Liveness Guarantee** | Always (if bounds hold) | Only eventually (after GST) | +| **Safety Guarantee** | Depends on strict timing, traditional Byzantine assumption violated | Holds even under asynchrony | +| **Fault Tolerance** | Assumptions must be modified to allow a non-supermajority fork to exist, hence not traditionally BFT | Designed to tolerate Byzantine faults | +| **Performance** | High under tight control | Adaptive but may have delays | + +### A2: PBFT and Perfectness + +[PBFT](https://pmg.csail.mit.edu/papers/osdi99.pdf) introduced a protocol which ensures consecutive rounds of consensus intersect in at least one unit of honest voting power via the Generalized Pigeon Hole Principle. The transitivity of this property ensures that a chain of consensus rounds must intersect in at least one unit of honest voting power. + +Under an [experts model](https://people.csail.mit.edu/ghaffari/AA19/AAscript.pdf?utm_source=chatgpt.com) understanding of PBFT systems, we can make an assumption that there is a perfect expert and thus that this perfect expert is identified by consensus. This, in turn, renders PBFT a lossless approximate algorithm. + +If we consider allowing forks, however, it is initially unclear how perfectness translates. Naively, our assumption that there is globally one perfect expert means that there is one **perfect** fork. + +We can, however, apply a reduced criterion and state that a each **fork** be comprised of a chain of consensus rounds each of which intersect in one unit of honest voting power w.r.t. to the fork itself. We call this **fork-perfectness**. + +Preserving **fork-perfectness** reduces to ensuring the fraction of stake which decided the original fork maintains a supermajority. If this does not occur, then it is impossible to have the guaranteed intersection. + +### A3: Awareness of Minority Decisions + +The requirement of **full-synchronicity** means that if a supermajority decision is not made by Global Stabilization Time, some form of minority decision must effectively be made. This does not inherently mean that a Byzantine fraction of voting power may decide the global state. For example, if long-lived forks are preserved, there are multiple global states and eventual supermajority consistency can be achieved via a reconstitution of supermajority stake on an honest fork. In other words, while a **partially-synchronous** system renders eventual liveness and guaranteed safety, a **full-synchronous** system can render guaranteed liveness and eventual safety. + +Regardless, Dongmen Postconfirmation protocols are required to provide a formal model of the expected value of consensus on a Byzantine minority w.r.t. the value of the state and intrinsic rewards. In other words, they must explain the nature of eventual safety that abides by Byzantine assumptions or else describe the non-BFT nature of the protocol at full-synchronous decision points. + +### A4: Example Minority-Aware Protocol +Consider the following fully-synchronous protocol: + +1. Votes $v \in V$ are cast for states $s \in S$ at height $h \in H$. +2. A decision in made on a vote $s, h$ by time $t \in T$. + 1. If $V_{h}(s) > \frac{2*|V|}{3}$, accept $s, h$ + 2. Otherwise, begin **Play Foward** algorithm. + +The **Play Forward** algorithm is as follows: + +Given a duration $d: (t + d) \in T$, and a slot duration $l: (d/l) \in T$, for each slot $l'$ in the duration $t, t + l, ... t + d$ $h' = h + (l'/l)$. + +If $l' > d$, accept the root $s, h$ of the heaviest remaining subtree by weight. + +Otherwise, for each tuple $(s, h') \in V_{h'}$ + +1. If $V_{h'}(s) > \frac{2*|V|}{3}$, accept $s, h$, i.e., the original commitment at the root of the subtree. +2. If $V_{h'}(s) = \text{argmin} V_{h'}(s)$, remove all tuples $s, h \leq V_{h'}(s)$ and their descendants from the entire tree. + +At any given round, the number of ways the Byzantine fraction $\frac{|V|}{3} - 1$ can be eliminated is $n' = (incomplete)$ out of the total number of combinations $n$. + +Thus, the probability of that the Byzantine fraction makes it to the final acceptance is $p =(incomplete)$. + +All other subtrees are considered honest partitions. Accepting any of these is considered **perfect**. + +Thus, our protocol now admits a $p$ probability of Byzantine attack. The expected value of Byzantine consensus attack is $p(Val(s) + Val(Rewards(h)))$. + +This is **fully-synchronous** because a decision will be cast on $h$ by $t + d$. + +## Changelog + + From ccb5c37d6f06dd7afebeb34373306242f1861e7b Mon Sep 17 00:00:00 2001 From: Liam Monninger <79056955+l-monninger@users.noreply.github.com> Date: Fri, 4 Apr 2025 17:57:27 +0800 Subject: [PATCH 02/18] fix: md-5 --- MD/md-n/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MD/md-n/README.md b/MD/md-n/README.md index c7c235e1..34eb4813 100644 --- a/MD/md-n/README.md +++ b/MD/md-n/README.md @@ -7,7 +7,7 @@ ## Overview -As identified in [MD-3](https://github.com/movementlabsxyz/MIP/tree/main/MD/md-3), [MD-4](https://github.com/movementlabsxyz/MIP/tree/main/MD/md-4), [MD-5](https://github.com/movementlabsxyz/MIP/tree/main/MD/md-4), [MIP-34](https://github.com/movementlabsxyz/MIP/pulls?page=2&q=is%3Apr+is%3Aopen), and [MIP-37](https://github.com/movementlabsxyz/MIP/pull/37), naive interpretations--such as MCR--of the Postconfirmations protocol fall short of modern BFT expectations. +As identified in [MD-3](https://github.com/movementlabsxyz/MIP/tree/main/MD/md-3), [MD-4](https://github.com/movementlabsxyz/MIP/tree/main/MD/md-4), [MD-5](https://github.com/movementlabsxyz/MIP/tree/main/MD/md-5), [MIP-34](https://github.com/movementlabsxyz/MIP/pulls?page=2&q=is%3Apr+is%3Aopen), and [MIP-37](https://github.com/movementlabsxyz/MIP/pull/37), naive interpretations--such as MCR--of the Postconfirmations protocol fall short of modern BFT expectations. We summarize the shortcomings relevant to these standards as follows: From 9cc3fa03dc15785d04949dbc6121518647c97dae Mon Sep 17 00:00:00 2001 From: Liam Monninger <79056955+l-monninger@users.noreply.github.com> Date: Fri, 4 Apr 2025 18:09:55 +0800 Subject: [PATCH 03/18] fix: numbering --- MD/md-n/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MD/md-n/README.md b/MD/md-n/README.md index 34eb4813..c63ccb42 100644 --- a/MD/md-n/README.md +++ b/MD/md-n/README.md @@ -1,4 +1,4 @@ -# MD-n: Dongmen (Postconfirmations) Standards +# MD-116: Dongmen (Postconfirmations) Standards - **Description**: Provides a set of liveness and correctness requirements for Postconfirmations protocols. - **Authors**: [Liam Monninger](mailto:liam@movementlabs.xyz) From 1d44d15ef8206dae89c555a4ca7879634ca8561b Mon Sep 17 00:00:00 2001 From: apenzk Date: Fri, 4 Apr 2025 19:22:44 +0200 Subject: [PATCH 04/18] add 2 examples --- MD/md-n/README.md | 43 ++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 42 insertions(+), 1 deletion(-) diff --git a/MD/md-n/README.md b/MD/md-n/README.md index c63ccb42..7b63ee51 100644 --- a/MD/md-n/README.md +++ b/MD/md-n/README.md @@ -132,6 +132,47 @@ Thus, our protocol now admits a $p$ probability of Byzantine attack. The expecte This is **fully-synchronous** because a decision will be cast on $h$ by $t + d$. -## Changelog +### A6: Example Minority-Selecting Protocol (with revotes) + +Consider the following synchronous protocol: + +Any voter may cast their vote only once for a given slot height. Votes $v \in V_h$, where $|V_h| = |V|$ is the number of voters, are cast for states $s \in S_h$ at slot height $h \in H$. The first recorded vote on height $h$ determines the timestamp $t_h$ of that slot. Let $\sigma_h(s_h)$ be the number of votes for state $s_h$ at slot height $h$. + +> :warning: Since nodes could set the timestamp arbitrarily into the future for a given slot height, we MUST require that nodes cannot vote for heights that are too far away from accepted heights. + +We assume that the nodes can become faulty, vote for a branch with state $s^x_h$ and can acknowledge they voted for the wrong branch. We suggest that these nodes should be permitted to rejoin and support a different branch (with state $s_h$) that they deem correct. In order to vote for $s_h$ they MUST be permitted to cast an additional vote for $s_h$ at height $h$. + +The proposed protocol is as follows: + +1. Given a vote for state $s_h$ at slot height $h$, update + $\sigma_h(s_h) \leftarrow \sigma_h(s_h) + 1$. + +Slots are handled sequentially, i.e. if slot height $h^*$ has not been processed, then slot height $h^*+1$ is not processed. + +For each undecided height $h^*$ < h$ +2. If $\sigma_{h^*}(s_h^*) > \frac{2}{3}|V|$ AND $t \leq t_h^* + \Delta$, accept the tuple $(s_h^*, h^*)$. Continue processing slot $h^*+1$. +3. Else If $t > t_h^* + \Delta$, select the branch with the highest weight. Continue processing slot $h^*+1$. +4. Else Return +**What can go wrong?** +If no branch is finalized at $t_h^* + \Delta$, the protocol will select the branch with the highest weight, this may not be secure against a Byzantine minority. + +### A5: Example Minority-Selecting Protocol (without revotes) + +Assume the previous protocol, but nodes are not permitted to cast more than one vote per slot height. However, we still would like to entertain that nodes can resubmit their vote for a different branch. + +In order to do this, we must permit that votes are propagated along the branch to the currently undecided root. + +We update rule 1 to be: + +1. Given a vote for state $s_h$ at slot height $h$, update + 1. $\sigma_h(s_h) \leftarrow \sigma_h(s_h) + 1$. + 2. For each ancestor state $s_{h-k}$ of $s_h$ in the tree that is not finalized and for which the vote has not already been cast, $\sigma_{h-k}(s_{h-k}) \leftarrow \sigma_{h-k}(s_{h-k}) + 1$. + +We note this is marginally different to the previous example. + +**What can go wrong?** +1. Same problem as previous example. + +## Changelog From b3cc21b7cd8c46aa33f1f756cacb6c472613d25a Mon Sep 17 00:00:00 2001 From: apenzk Date: Fri, 4 Apr 2025 19:24:24 +0200 Subject: [PATCH 05/18] edit --- MD/md-n/README.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/MD/md-n/README.md b/MD/md-n/README.md index 7b63ee51..3151da54 100644 --- a/MD/md-n/README.md +++ b/MD/md-n/README.md @@ -147,16 +147,16 @@ The proposed protocol is as follows: 1. Given a vote for state $s_h$ at slot height $h$, update $\sigma_h(s_h) \leftarrow \sigma_h(s_h) + 1$. -Slots are handled sequentially, i.e. if slot height $h^*$ has not been processed, then slot height $h^*+1$ is not processed. +Slots are handled sequentially, i.e. if slot height $h^+$ has not been processed, then slot height $h^++1$ is not processed. -For each undecided height $h^*$ < h$ +For each undecided height $h^+$ < h$ -2. If $\sigma_{h^*}(s_h^*) > \frac{2}{3}|V|$ AND $t \leq t_h^* + \Delta$, accept the tuple $(s_h^*, h^*)$. Continue processing slot $h^*+1$. -3. Else If $t > t_h^* + \Delta$, select the branch with the highest weight. Continue processing slot $h^*+1$. +2. If $\sigma_{h^+}(s_h^+) > \frac{2}{3}|V|$ AND $t \leq t_h^+ + \Delta$, accept the tuple $(s_h^+, h^+)$. Continue processing slot $h^++1$. +3. Else If $t > t_h^+ + \Delta$, select the branch with the highest weight. Continue processing slot $h^++1$. 4. Else Return **What can go wrong?** -If no branch is finalized at $t_h^* + \Delta$, the protocol will select the branch with the highest weight, this may not be secure against a Byzantine minority. +If no branch is finalized at $t_h^+ + \Delta$, the protocol will select the branch with the highest weight, this may not be secure against a Byzantine minority. ### A5: Example Minority-Selecting Protocol (without revotes) From b1485b0d495d984e6b8efaee65eb9bd2553a6fde Mon Sep 17 00:00:00 2001 From: apenzk Date: Fri, 4 Apr 2025 19:59:43 +0200 Subject: [PATCH 06/18] Example 6 with revoking of votes --- MD/md-n/README.md | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/MD/md-n/README.md b/MD/md-n/README.md index 3151da54..feb142ce 100644 --- a/MD/md-n/README.md +++ b/MD/md-n/README.md @@ -156,7 +156,9 @@ For each undecided height $h^+$ < h$ 4. Else Return **What can go wrong?** -If no branch is finalized at $t_h^+ + \Delta$, the protocol will select the branch with the highest weight, this may not be secure against a Byzantine minority. + +- If no branch is finalized at $t_h^+ + \Delta$, the protocol will select the branch with the highest weight, this may not be secure against a Byzantine minority. +- Since votes of a node can double count, it is possible that eventually the wrong branch wins, since a byzantine actor plus the initial wrong "honest" votes can outvote the correct branch. ### A5: Example Minority-Selecting Protocol (without revotes) @@ -175,4 +177,21 @@ We note this is marginally different to the previous example. **What can go wrong?** 1. Same problem as previous example. +### A6: Example Minority-Selecting Protocol (with revotes but no double counting) + +Assume the previous protocol, but votes are removed from branches that are not supported any longer. + +We change rule 1 to be: + +1. Given a vote for state $s_h$ at slot height $h$, update + $\sigma_h(s_h) \leftarrow \sigma_h(s_h) + 1$. +2. For each ancestor state $s_{h-k}$ of $s_h$ in the tree that is not finalized and for which the vote has not already been cast, $\sigma_{h-k}(s_{h-k}) \leftarrow \sigma_{h-k}(s_{h-k}) + 1$. +3. For each height $h^+< h$, remove all votes for $s_{h^+}$ from a branch that is not an ancestor of $s_h$. + +> :bulb: This has infact similar behavior and properties to [Tangle 2.0 Leaderless Nakamoto Consensus on the Heaviest DAG](https://ieeexplore.ieee.org/document/9907014). However, here we have a tree and an L1 to synchronize and remove problems with partitions, which makes the challenges much easier. + +**What can go wrong?** + +- If no branch is finalized at $t_h^+ + \Delta$, the protocol will select the branch with the highest weight, this may not be secure against a Byzantine minority. + ## Changelog From e16ddb3ea01fb50d6721b0844b907ec5a86b487d Mon Sep 17 00:00:00 2001 From: Liam Monninger <79056955+l-monninger@users.noreply.github.com> Date: Sat, 5 Apr 2025 06:41:21 +0800 Subject: [PATCH 07/18] Update MD/md-n/README.md Co-authored-by: Andreas Penzkofer <36140574+apenzk@users.noreply.github.com> --- MD/md-n/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MD/md-n/README.md b/MD/md-n/README.md index feb142ce..fe7dbb8b 100644 --- a/MD/md-n/README.md +++ b/MD/md-n/README.md @@ -106,7 +106,7 @@ Regardless, Dongmen Postconfirmation protocols are required to provide a formal ### A4: Example Minority-Aware Protocol Consider the following fully-synchronous protocol: -1. Votes $v \in V$ are cast for states $s \in S$ at height $h \in H$. +1. Votes $v \in V_h$ are cast for states $s \in S_h$ at height $h \in H$. 2. A decision in made on a vote $s, h$ by time $t \in T$. 1. If $V_{h}(s) > \frac{2*|V|}{3}$, accept $s, h$ 2. Otherwise, begin **Play Foward** algorithm. From 9518fa067e31b29f629e32cf79edef56c9088f5c Mon Sep 17 00:00:00 2001 From: Liam Monninger <79056955+l-monninger@users.noreply.github.com> Date: Sat, 5 Apr 2025 11:23:06 +0800 Subject: [PATCH 08/18] Update MD/md-n/README.md Co-authored-by: Andreas Penzkofer <36140574+apenzk@users.noreply.github.com> --- MD/md-n/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MD/md-n/README.md b/MD/md-n/README.md index fe7dbb8b..d51c8241 100644 --- a/MD/md-n/README.md +++ b/MD/md-n/README.md @@ -2,7 +2,7 @@ - **Description**: Provides a set of liveness and correctness requirements for Postconfirmations protocols. - **Authors**: [Liam Monninger](mailto:liam@movementlabs.xyz) -- **Approval**: :red-cross: +- **Approval**: - **Etymology**: These standards were originally drafted in the Dongmen neighborhood of Taipei. ## Overview From 9cee1f7489c8845d7f47aef67557129bfa0560e2 Mon Sep 17 00:00:00 2001 From: Liam Monninger <79056955+l-monninger@users.noreply.github.com> Date: Sat, 5 Apr 2025 11:23:15 +0800 Subject: [PATCH 09/18] Update MD/md-n/README.md Co-authored-by: Andreas Penzkofer <36140574+apenzk@users.noreply.github.com> --- MD/md-n/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MD/md-n/README.md b/MD/md-n/README.md index d51c8241..46dadd89 100644 --- a/MD/md-n/README.md +++ b/MD/md-n/README.md @@ -11,7 +11,7 @@ As identified in [MD-3](https://github.com/movementlabsxyz/MIP/tree/main/MD/md-3 We summarize the shortcomings relevant to these standards as follows: -1. **Asynchronicity**: per [FLP](https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf), asynchronous voting protocols cannot achieve consensus in the presence of one or more faulty processes. Thus, Asynchronous Postconfirmations protocols, i.e., those not defining a Global Stabilization Times, are **not in fact BFT consensus protocols.** MCR, for example--due its single vote per slot without any bound--may remain in permanent disagreement. +1. **Asynchronicity**: per [FLP](https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf), asynchronous voting protocols cannot achieve consensus in the presence of one or more faulty processes. Thus, Asynchronous Postconfirmations protocols, i.e., those not defining a Global Stabilization Times, are **not in fact BFT consensus protocols.** MCR, for example--if implemented with a single vote per slot and without any bound on when the slot moves to a new committee--may remain in permanent disagreement. 2. **Liveness**: failure to come to consensus presents a liveness shortcoming. Permanent disagreement means that the network will never progress to the next accepted state. Further, we assert indefinite disagreement is unnecessary in the context of Postconfirmations. For more detailed information on these properties, see [BFT Synchronicity and Liveness](#a1-bft-synchronicity-and-liveness). From f61d8a5f52d0f702440d81645d337376258d2be9 Mon Sep 17 00:00:00 2001 From: Liam Monninger <79056955+l-monninger@users.noreply.github.com> Date: Sat, 5 Apr 2025 11:23:59 +0800 Subject: [PATCH 10/18] Update MD/md-n/README.md Co-authored-by: Andreas Penzkofer <36140574+apenzk@users.noreply.github.com> --- MD/md-n/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MD/md-n/README.md b/MD/md-n/README.md index 46dadd89..ca7deed7 100644 --- a/MD/md-n/README.md +++ b/MD/md-n/README.md @@ -22,7 +22,7 @@ Because the Dongmen Postconfirmations Standards request a **fully-synchronous** ## Definitions -- **Fully-synchronous**: A network and protocol assumption in which message transmission and processing are guaranteed to complete within known, fixed bounds. A protocol that assumes this model must commit or reject decisions by a deterministically computable time. +- **Fully-synchronous**: Describes a synchronous model. A network and protocol assumption in which message transmission and processing are guaranteed to complete within known, fixed bounds. Messages destined to be handled within a certain bound may arrive outside of these bounds, however, they are then ignored. A protocol that assumes this model must commit or reject decisions by a deterministically computable time. - **Global Stabilization Time (GST)**: The unknown point in time after which a partially synchronous network behaves synchronously. This term is critical in distinguishing traditional BFT protocols from fully-synchronous ones, which assume GST has already occurred or is always satisfied. From 2a3d96ae4b9d7728b5148aeac72e765ba284b009 Mon Sep 17 00:00:00 2001 From: apenzk Date: Sat, 5 Apr 2025 15:21:48 +0200 Subject: [PATCH 11/18] update A6 --- MD/md-n/README.md | 66 +++++++++++++++++++++++++++++++---------------- 1 file changed, 44 insertions(+), 22 deletions(-) diff --git a/MD/md-n/README.md b/MD/md-n/README.md index feb142ce..0512c555 100644 --- a/MD/md-n/README.md +++ b/MD/md-n/README.md @@ -132,56 +132,78 @@ Thus, our protocol now admits a $p$ probability of Byzantine attack. The expecte This is **fully-synchronous** because a decision will be cast on $h$ by $t + d$. -### A6: Example Minority-Selecting Protocol (with revotes) +### A6: Examples Minority-Selecting Protocols Consider the following synchronous protocol: -Any voter may cast their vote only once for a given slot height. Votes $v \in V_h$, where $|V_h| = |V|$ is the number of voters, are cast for states $s \in S_h$ at slot height $h \in H$. The first recorded vote on height $h$ determines the timestamp $t_h$ of that slot. Let $\sigma_h(s_h)$ be the number of votes for state $s_h$ at slot height $h$. +Voters, where $N$ is the number of voters, cast their votes $v \in V_h$, for states $s \in S_h$ at slot height $h \in H$. The first recorded vote on height $h$ determines the timestamp $t_h$ of that slot. Let $\sigma_h(s_h)$ be the number of votes for state $s_h$ at slot height $h$. A voter can cast at most one vote per state per slot height. -> :warning: Since nodes could set the timestamp arbitrarily into the future for a given slot height, we MUST require that nodes cannot vote for heights that are too far away from accepted heights. +Slots are handled sequentially, i.e. if slot height $h^+$ has not been processed, then slot height $h^++1$ is not processed. -We assume that the nodes can become faulty, vote for a branch with state $s^x_h$ and can acknowledge they voted for the wrong branch. We suggest that these nodes should be permitted to rejoin and support a different branch (with state $s_h$) that they deem correct. In order to vote for $s_h$ they MUST be permitted to cast an additional vote for $s_h$ at height $h$. +The basic protocol looks as follows: -The proposed protocol is as follows: +1. Vote and potential vote propagation (described in next subsections) +1. For each undecided height $h^+ < h$ + 1. If $\sigma_{h^+}(s_h^+) > \frac{2}{3}|V|$ AND $t \leq t_h^+ + \Delta$, accept the tuple $(s_h^+, h^+)$. Continue processing slot $h^++1$. + 2. Else If $t > t_h^+ + \Delta$, select the branch with the highest weight. Continue processing slot $h^++1$. + 3. Else Return -1. Given a vote for state $s_h$ at slot height $h$, update - $\sigma_h(s_h) \leftarrow \sigma_h(s_h) + 1$. +Note that 2.ii) is where the **synchronous nature** of the protocol is used. -Slots are handled sequentially, i.e. if slot height $h^+$ has not been processed, then slot height $h^++1$ is not processed. +> :warning: Since nodes could set the timestamp arbitrarily into the future for a given slot height, we MUST require that nodes cannot vote for heights that are too far away from accepted heights. This is important for the synchronous model. + +We assume that the nodes can become faulty or byzantine, vote for a branch with state $s^x_h$ and may acknowledge they voted for the wrong branch. + +We suggest that these nodes should be permitted to support a different branch (with state $s_h$) that they deem correct (and that is in conflict with their previous vote). In order to vote for $s_h$ they MUST be permitted to cast an additional vote (**revote**) for $s_h$ at height $h$. + +Since a the choice for a new branch would mean that all previous votes are invalid (from the point of view of the voter itself), this raises the question of how to handle revotes, and in particular the ancestor votes that depend on this. -For each undecided height $h^+$ < h$ +A combination of the following two properties can be used to achieve the desired protocol: -2. If $\sigma_{h^+}(s_h^+) > \frac{2}{3}|V|$ AND $t \leq t_h^+ + \Delta$, accept the tuple $(s_h^+, h^+)$. Continue processing slot $h^++1$. -3. Else If $t > t_h^+ + \Delta$, select the branch with the highest weight. Continue processing slot $h^++1$. -4. Else Return +- Revoting + 1. Revoting is not allowed. (Voter can cast one vote per slot height only) + 1. Revoting is allowed. +- Counting of votes + 1. Double counting, i.e., all votes count, including votes before revoting. + 1. Only the last vote counts. +- Propagation of votes + 1. Votes are cast for a branch, not a state. (less transactions but per transaction more computation) + 1. Votes are cast for a state, not a branch. (more transactions but per transaction less computation) + +Lets explore sone of the options: + +#### A6.1: Revotes, double counting, no propagation + +Step 1 of the above algorithm becomes + +1. Given a vote for state $s_h$ at slot height $h$, update + $\sigma_h(s_h) \leftarrow \sigma_h(s_h) + 1$. **What can go wrong?** - If no branch is finalized at $t_h^+ + \Delta$, the protocol will select the branch with the highest weight, this may not be secure against a Byzantine minority. - Since votes of a node can double count, it is possible that eventually the wrong branch wins, since a byzantine actor plus the initial wrong "honest" votes can outvote the correct branch. -### A5: Example Minority-Selecting Protocol (without revotes) - -Assume the previous protocol, but nodes are not permitted to cast more than one vote per slot height. However, we still would like to entertain that nodes can resubmit their vote for a different branch. +#### A6.2: No Revotes, single-counting, with propagation -In order to do this, we must permit that votes are propagated along the branch to the currently undecided root. +Here we would like to entertain that nodes can resubmit their vote for a different branch, but existing votes cannot be changed. We also would like to propagate votes a long a branch to ensure that this branch is maximally supported. -We update rule 1 to be: +Step 1 of the above algorithm becomes 1. Given a vote for state $s_h$ at slot height $h$, update 1. $\sigma_h(s_h) \leftarrow \sigma_h(s_h) + 1$. - 2. For each ancestor state $s_{h-k}$ of $s_h$ in the tree that is not finalized and for which the vote has not already been cast, $\sigma_{h-k}(s_{h-k}) \leftarrow \sigma_{h-k}(s_{h-k}) + 1$. + 2. For each ancestor state $s_{h-k}$, $k>0$ of $s_h$ in the tree that is not yet voted on, $\sigma_{h-k}(s_{h-k}) \leftarrow \sigma_{h-k}(s_{h-k}) + 1$. -We note this is marginally different to the previous example. +We note this is marginally different to the previous example. It differs only in that a voter can batch votes for a branch not a state. This is not a meaningful solution but it is the precursor to the next example. **What can go wrong?** 1. Same problem as previous example. -### A6: Example Minority-Selecting Protocol (with revotes but no double counting) +#### A6.3: Revotes, single-counting, with propagation -Assume the previous protocol, but votes are removed from branches that are not supported any longer. +Assume the previous protocol, but votes are removed from branches that are not supported any longer. This means we override previous votes. -We change rule 1 to be: +Step 1 of the above algorithm becomes 1. Given a vote for state $s_h$ at slot height $h$, update $\sigma_h(s_h) \leftarrow \sigma_h(s_h) + 1$. From 437f025ef41dfab6465204d08171fa3a47d5023d Mon Sep 17 00:00:00 2001 From: apenzk Date: Sat, 5 Apr 2025 15:25:23 +0200 Subject: [PATCH 12/18] N --- MD/md-n/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MD/md-n/README.md b/MD/md-n/README.md index ef73ba59..f2e473b2 100644 --- a/MD/md-n/README.md +++ b/MD/md-n/README.md @@ -144,7 +144,7 @@ The basic protocol looks as follows: 1. Vote and potential vote propagation (described in next subsections) 1. For each undecided height $h^+ < h$ - 1. If $\sigma_{h^+}(s_h^+) > \frac{2}{3}|V|$ AND $t \leq t_h^+ + \Delta$, accept the tuple $(s_h^+, h^+)$. Continue processing slot $h^++1$. + 1. If $\sigma_{h^+}(s_h^+) > \frac{2}{3}N$ AND $t \leq t_h^+ + \Delta$, accept the tuple $(s_h^+, h^+)$. Continue processing slot $h^++1$. 2. Else If $t > t_h^+ + \Delta$, select the branch with the highest weight. Continue processing slot $h^++1$. 3. Else Return From fc5b7df7a1288d400db51bab2fb63ead3b3bd7cc Mon Sep 17 00:00:00 2001 From: apenzk Date: Wed, 9 Apr 2025 17:25:26 +0200 Subject: [PATCH 13/18] edits and mermaids --- MD/md-n/README.md | 302 ++++++++++++++++++++++++++++++++++++---------- 1 file changed, 238 insertions(+), 64 deletions(-) diff --git a/MD/md-n/README.md b/MD/md-n/README.md index f2e473b2..48ec2dd8 100644 --- a/MD/md-n/README.md +++ b/MD/md-n/README.md @@ -1,6 +1,6 @@ -# MD-116: Dongmen (Postconfirmations) Standards +# MD-116: Dongmen Standards for Postconfirmations -- **Description**: Provides a set of liveness and correctness requirements for Postconfirmations protocols. +- **Description**: Provides a set of liveness and correctness requirements for quasi-synchronous Postconfirmations protocols. - **Authors**: [Liam Monninger](mailto:liam@movementlabs.xyz) - **Approval**: - **Etymology**: These standards were originally drafted in the Dongmen neighborhood of Taipei. @@ -11,79 +11,111 @@ As identified in [MD-3](https://github.com/movementlabsxyz/MIP/tree/main/MD/md-3 We summarize the shortcomings relevant to these standards as follows: -1. **Asynchronicity**: per [FLP](https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf), asynchronous voting protocols cannot achieve consensus in the presence of one or more faulty processes. Thus, Asynchronous Postconfirmations protocols, i.e., those not defining a Global Stabilization Times, are **not in fact BFT consensus protocols.** MCR, for example--if implemented with a single vote per slot and without any bound on when the slot moves to a new committee--may remain in permanent disagreement. -2. **Liveness**: failure to come to consensus presents a liveness shortcoming. Permanent disagreement means that the network will never progress to the next accepted state. Further, we assert indefinite disagreement is unnecessary in the context of Postconfirmations. +1. **Quasi-Asynchronicity**: + +per [FLP](https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf), protocols under asynchronous network conditions cannot achieve consensus in the presence of one or more faulty processes. As noted in [MD-118](https://github.com/movementlabsxyz/MIP/tree/main/MD/md-118) Appendix A1, the L1 essentially provides strong guarantees on the network conditions, which possibly could be classified as **totally ordered broadcast**, as the L1 records votes and finalizes them in blocks that reach all participants. + +!!! We do not require this discussion on asynchronicity. + +2. **Temporary Liveness issues**: + +Votes on a given commitment height may never arrive as the postconfirmation attesters may become inactive, which could stall the liveness of the protocol. + +Thus, Postconfirmations protocols that do not define synchronization times, timeouts and/or a view change on who is the attester committee, can loose liveness indefinitely. + +3. **Temporary forks**: + +Failure to come to consensus presents a liveness shortcoming. Permanent disagreement about the state on L2 means that the network will never progress to the next accepted state. We assert indefinite disagreement is unnecessary in the context of Postconfirmations, as attesters may change over time or their view of the state may change. + +OLD + +, are **not in fact BFT consensus protocols.** MCR, for example--if implemented with a single vote per slot and without any bound on when the slot moves to a new committee--may remain in permanent disagreement. For more detailed information on these properties, see [BFT Synchronicity and Liveness](#a1-bft-synchronicity-and-liveness). -In response to these shortcomings, we request a protocol which is **fully-synchronous**, **fork-transferable**, **fork-perfect**, and **minority-aware**. The last three of these terms are introduced and defined in this MD. +In response to these shortcomings, this MD requests a protocol which is **quasi-synchronous**, **fork-transferable**, **fork-perfect**, and **minority-aware**. The last three of these terms are introduced and defined in this MD. -Because the Dongmen Postconfirmations Standards request a **fully-synchronous** protocol, we assert said protocol can no longer be traditionally-BFT. That is, non-supermajority forks may exist under these standards. For a traditional BFT standard, see the [Ximen Postconfirmations Standards](). +In order to be a **quasi-synchronous** protocol, we assert said protocol can no longer be traditionally-BFT. That is, non-supermajority branches may exist under these standards. For a protocol that satisfies BFT requirements, see the [Ximen Postconfirmations Standards](). ## Definitions -- **Fully-synchronous**: Describes a synchronous model. A network and protocol assumption in which message transmission and processing are guaranteed to complete within known, fixed bounds. Messages destined to be handled within a certain bound may arrive outside of these bounds, however, they are then ignored. A protocol that assumes this model must commit or reject decisions by a deterministically computable time. +- **Fork and Branch**: A fork on L2 is the event of a divergence in what is considered the "correct" state on L2. A branch is a chain of blocks (or consensus rounds). A fork creates two or more branches. -- **Global Stabilization Time (GST)**: The unknown point in time after which a partially synchronous network behaves synchronously. This term is critical in distinguishing traditional BFT protocols from fully-synchronous ones, which assume GST has already occurred or is always satisfied. +- **Quasi-models**: We attempt to transfer the concept of message propagation guarantees in network models to the Postconfirmation protocol. For more details on the models, see [Appendix A1.1](). + - **Quasi-synchronous**: The protocol assume that all relevant voting messages are delivered within time $\Delta$. Based on the received votes, the protocol will make a decision. Messages destined to be handled within the bound may arrive outside of these bounds, however, they are then ignored. It is liveness-favoring. + - **Quasi-partially synchronous**: A supermajority of votes are delivered within time $\Delta$ at some finite point in the future. Steps are taken to ensure that the protocol can make a decision at some finite point in the future. This is similar to the concept of Global Stabilization Time (GST). This is safety-favoring. + - **Quasi-asynchronous**: There is no bound on when the supermajority of votes will be delivered. This is safety-favoring. -- **Fork-transferable**: A property of a consensus protocol that allows consumers to transfer application state from a forked chain of consensus rounds while preserving verifiability and auditability, even in the presence of honest partitions or temporary disagreement. +- **Branch-transferable**: A property of a protocol that allows consumers to transfer application state from a forked chain of consensus rounds (i.e. a branch) while preserving verifiability and audibility, even in the presence of honest partitions or temporary disagreement. -- **Fork-perfect**: A refinement of PBFT’s intersection safety. A fork is fork-perfect if every round of consensus along the fork intersects with at least one unit of honest voting power *relative to the fork*. This ensures local safety guarantees on a per-fork basis, even in the presence of multiple non-merging branches. +- **Branch-perfect**: A refinement of PBFT’s intersection safety. A branch is branch-perfect if every round of consensus along the branch intersects with at least one unit of honest voting power *relative to the branch*. This ensures local safety guarantees on a per-branch basis, even in the presence of multiple non-merging branches. -- **Perfect Expert**: A theoretical construct (adapted from [expert learning models](https://people.csail.mit.edu/ronitt/COURSE/S16/notes7.pdf)) which assumes the existence of a strategy (or sequence of decisions) that would have been globally optimal or correct. In consensus, identifying this expert is analogous to identifying a perfect fork. Fork-perfectness aims to localize this ideal to a given fork in the presence of asynchrony or faults. +- **Perfect Expert**: A theoretical construct (adapted from [expert learning models](https://people.csail.mit.edu/ronitt/COURSE/S16/notes7.pdf)) which assumes the existence of a strategy (or sequence of decisions) that would have been globally optimal or correct. In consensus, identifying this expert is analogous to identifying a perfect branch. Branch-perfectness aims to localize this ideal to a given branch in the presence of asynchrony or faults. -- **Minority-aware**: A protocol property requiring formal understanding and bounded valuation of consensus decisions made by a Byzantine minority. This property mandates a clear risk model quantifying the probability and cost of such decisions under full synchrony when liveness demands finality at fixed times. +- **Minority-aware**: A protocol property requiring formal understanding and bounded valuation of consensus decisions made by a Byzantine minority. This property mandates a clear risk model quantifying the probability and cost of such decisions under quasi-synchrony when liveness demands finality at fixed times. ## Desiderata -### D1: Fully-synchronous +### D1: Liveness-favoring and quasi-synchronous + +**User journey**: Consumers of Postconfirmations can rely on agreement to be achieved within an known time delta w.r.t. to the confirming ledger. + +**Justification**: A quasi-synchronous protocol provides predictable points in time by which a decision will be made. It is liveness-favoring. It does not provide guarantees against byzantine actors with respect to selecting the correct state for the L2. -**User journey**: Consumers of Dongmen Postconfirmations consensus can rely on agreement to be achieved by a know Global Stabilization Time w.r.t. to the confirming ledger. +The requirement of **quasi-synchronicity** means that if a supermajority decision is not made by some time $\Delta$, some form of minority decision must effectively be made, for the protocol to make progress. In essence this means that the protocol is **liveness-favoring**, see Appendix [A1.2](). -**Justification**: A fully-synchronous protocol is a consensus protocol under FLP. It also renders predictable points in time by which consensus will be achieved, offering qualitatively optimal liveness. +Regardless, Dongmen Postconfirmation protocols are required to provide a formal model of the expected value of consensus on a Byzantine minority w.r.t. the value of the state and intrinsic rewards. In other words, they must explain the nature of eventual safety (with respect to Byzantine assumptions) or else describe the non-BFT nature of the protocol at quasi-synchronous decision points. -### D2: Fork-transferable +### D2: Branch-transferable -**User journey**: Consumers of Dongmen Postconfirmations consensus can safely transfer state from the ledger by following a set of standards. +**User journey**: Consumers of Postconfirmations can safely transfer state from the ledger by following a set of standards. **Justification**: The transfer of value from a BFT system to other systems is critical in the modern DLT landscape. How to do this safely is critical to both application and general ledger usage. -### D3: Fork-perfect +### D3: Branch-perfect -**User journey**: Consumers of Dongmen Postconfirmations consensus can rely on consensus to identify the assumed perfect expert w.r.t. a given fork. +**User journey**: Consumers of Postconfirmations can rely on consensus to identify the assumed perfect expert w.r.t. a given fork. **Justification**: We assert the perfectness of PBFT argued for in [PBFT and Perfectness](#a2-pbft-and-perfectness) is an essentially quality of modern BFT networks. ### D4: Minority-aware -**User journey**: Consumers of Dongmen Postconfirmations consensus can rely on a formalized understanding of the expected value of Byzantine consensus attack w.r.t. the value of the state and intrinsic rewards. This may additionally consider [fork-transferrable](#d2-fork-transferable) stipulations. +**User journey**: Consumers of Postconfirmations can rely on a formalized understanding of Byzantine attacks w.r.t. the resulting state and intrinsic rewards. This may additionally consider [branch-transferrable](#d2-branch-transferable) stipulations. -**Justification**: We assert that the [**full-synchronicity**](#d1-fully-synchronous) of Dongmen Protocols complicates BFT assumptions. These complications must be well understood for a given protocol. +**Justification**: We assert that the [**quasi-synchronicity**](#d1-quasi-synchronous) of Postconfirmations complicates BFT assumptions. These complications must be well understood for a given protocol. ## Appendix -### A1: BFT Synchronicity and Liveness +### A1: Classification of the Protocol + +#### A1.1: Network Synchronicity Models + +In Network theory, the following models for message propagation and arrival are considered: + +| Property / Feature | Synchronous | Partially Synchronous | Asynchronous | +|-------------------------------|---------------------------|-------------------------------|------------------------| +| Network Delays Known? | Yes | Yes, after unknown GST | No | +| Guaranteed bounded message arrival | Yes | Yes, after unknown GST | No | -| Model | Network Delays Known? | Bounded? | Known Bound? | -|------------------|------------------------|----------|----------------| -| Synchronous | Yes | Yes | Yes | -| Asynchronous | No | No | No | -| Partially Synchronous | No | Yes, after GST | No | +Similarly here we define Quasi-metrics for the Postconfirmation protocol that exists on the L1 contract. For this we focus on the timely delivery of votes from the L2 on the L1. +| Property / Feature | Quasi-synchronous | Quasi-partially Synchronous | Quasi-asynchronous | +|-------------------------------|---------------------------|-------------------------------|------------------------| +| Liveness possible? | Yes, but unsafe | Yes, eventually | No | +| Safety Guarantee | Have to use unsafe majority assumptions | Safe | Safe | +| Byzantine Fault Tolerance | No | Yes | Yes | +| Performance | High under tight control | Adaptive but with delays | Not applicable | -| Feature | Asynchronous | Partially Synchronous | Fully Synchronous | -|-----------------------|---------------------|-------------------------|--------------------------| -| **Message delay** | Unbounded forever | Unbounded until GST | Bounded always | -| **Knowledge of bounds** | None | Exist post-GST (unknown) | Known and fixed | -| **Liveness possible?** | No | Yes, eventually | Yes, by bounds | +#### A1.2: Liveness- and Safety-Favoring Assumptions + +We may also consider the protocol in terms of liveness-favoring and safety-favoring assumptions. + +| Property / Feature | Liveness-favoring | Inbetween Liveness-favoring and Safety-favoring | Safety-favoring | +|-------------------------------|---------------------------|-------------------------------|------------------------| +| Liveness possible? | Yes, but unsafe | Yes, eventually | No | +| Safety Guarantee | Have to use unsafe majority assumptions | Safe | Safe | +| Byzantine Fault Tolerance | No | Yes | Yes | -| Feature | Fully Synchronous | Partially Synchronous | -|-------------------------------|-----------------------------------|----------------------------------------| -| **Timing Assumption** | Fixed known bounds | Unknown bounds before GST | -| **Liveness Guarantee** | Always (if bounds hold) | Only eventually (after GST) | -| **Safety Guarantee** | Depends on strict timing, traditional Byzantine assumption violated | Holds even under asynchrony | -| **Fault Tolerance** | Assumptions must be modified to allow a non-supermajority fork to exist, hence not traditionally BFT | Designed to tolerate Byzantine faults | -| **Performance** | High under tight control | Adaptive but may have delays | ### A2: PBFT and Perfectness @@ -91,20 +123,16 @@ Because the Dongmen Postconfirmations Standards request a **fully-synchronous** Under an [experts model](https://people.csail.mit.edu/ghaffari/AA19/AAscript.pdf?utm_source=chatgpt.com) understanding of PBFT systems, we can make an assumption that there is a perfect expert and thus that this perfect expert is identified by consensus. This, in turn, renders PBFT a lossless approximate algorithm. -If we consider allowing forks, however, it is initially unclear how perfectness translates. Naively, our assumption that there is globally one perfect expert means that there is one **perfect** fork. +If we consider allowing forks, however, it is initially unclear how perfectness translates. Naively, our assumption that there is globally one perfect expert means that there is one **perfect** branch. -We can, however, apply a reduced criterion and state that a each **fork** be comprised of a chain of consensus rounds each of which intersect in one unit of honest voting power w.r.t. to the fork itself. We call this **fork-perfectness**. +We can, however, apply a reduced criterion and state that a each **branch** be comprised of a chain of consensus rounds each of which intersect in one unit of honest voting power w.r.t. to the fork itself. We call this **branch-perfectness**. -Preserving **fork-perfectness** reduces to ensuring the fraction of stake which decided the original fork maintains a supermajority. If this does not occur, then it is impossible to have the guaranteed intersection. +Preserving **branch-perfectness** reduces to ensuring the fraction of stake which was involved in the fork and which resulted in the winning branch maintains a supermajority. If this does not occur, then it is impossible to have the guaranteed intersection. -### A3: Awareness of Minority Decisions -The requirement of **full-synchronicity** means that if a supermajority decision is not made by Global Stabilization Time, some form of minority decision must effectively be made. This does not inherently mean that a Byzantine fraction of voting power may decide the global state. For example, if long-lived forks are preserved, there are multiple global states and eventual supermajority consistency can be achieved via a reconstitution of supermajority stake on an honest fork. In other words, while a **partially-synchronous** system renders eventual liveness and guaranteed safety, a **full-synchronous** system can render guaranteed liveness and eventual safety. +### A3: Example Minority-Aware Protocol -Regardless, Dongmen Postconfirmation protocols are required to provide a formal model of the expected value of consensus on a Byzantine minority w.r.t. the value of the state and intrinsic rewards. In other words, they must explain the nature of eventual safety that abides by Byzantine assumptions or else describe the non-BFT nature of the protocol at full-synchronous decision points. - -### A4: Example Minority-Aware Protocol -Consider the following fully-synchronous protocol: +Consider the following quasi-synchronous protocol: 1. Votes $v \in V_h$ are cast for states $s \in S_h$ at height $h \in H$. 2. A decision in made on a vote $s, h$ by time $t \in T$. @@ -130,43 +158,109 @@ All other subtrees are considered honest partitions. Accepting any of these is c Thus, our protocol now admits a $p$ probability of Byzantine attack. The expected value of Byzantine consensus attack is $p(Val(s) + Val(Rewards(h)))$. -This is **fully-synchronous** because a decision will be cast on $h$ by $t + d$. +This is **quasiy-synchronous** because a decision will be cast on $h$ by $t + d$. ### A6: Examples Minority-Selecting Protocols -Consider the following synchronous protocol: +Consider the following quasi-synchronous protocol: -Voters, where $N$ is the number of voters, cast their votes $v \in V_h$, for states $s \in S_h$ at slot height $h \in H$. The first recorded vote on height $h$ determines the timestamp $t_h$ of that slot. Let $\sigma_h(s_h)$ be the number of votes for state $s_h$ at slot height $h$. A voter can cast at most one vote per state per slot height. +Voters, where $N$ is the number of voters, cast their votes for states $s$ at slot height $h$. We assume the protocol requires a fullfilled slot at every height. The first recorded vote on height $h$ determines the timestamp $t_h$ of that slot. Let $\sigma(s_h)$ be the number of votes for state $s_h$ at slot height $h$. A voter can cast at most one vote per state per slot height. (So it may be still possible that he has multiple votes for the same slot height). -Slots are handled sequentially, i.e. if slot height $h^+$ has not been processed, then slot height $h^++1$ is not processed. +Slots are handled sequentially, i.e. if slot height $h$ has not been processed, then slot height $h+1$ will not be processed. The basic protocol looks as follows: 1. Vote and potential vote propagation (described in next subsections) 1. For each undecided height $h^+ < h$ - 1. If $\sigma_{h^+}(s_h^+) > \frac{2}{3}N$ AND $t \leq t_h^+ + \Delta$, accept the tuple $(s_h^+, h^+)$. Continue processing slot $h^++1$. + 1. If $\sigma(s_h^+) > \frac{2}{3}N$ AND $t \leq t_h^+ + \Delta$, accept the tuple $(s_h^+, h^+)$. Continue processing slot $h^++1$. 2. Else If $t > t_h^+ + \Delta$, select the branch with the highest weight. Continue processing slot $h^++1$. 3. Else Return -Note that 2.ii) is where the **synchronous nature** of the protocol is used. +Note that 2.ii) is where the **quasi-synchronous nature** of the protocol is used, and which implies a liveness-favoring property. + +
+ +
+ +```mermaid +graph TD + s0 -->|11%| s1 + s1 -->|10%| s2 + s1 -->|9%| s2' + s2' --> |9%| s3' + + style s1 fill:#faa,stroke:#f00,stroke-width:2px + style s2 fill:#faa,stroke:#f00,stroke-width:2px + style s2' fill:#faa,stroke:#f00,stroke-width:2px + style s3' fill:#faa,stroke:#f00,stroke-width:2px +``` + +

Fig 1 a): Time = Δ. Committee A was active. s2 gathers the highest number of votes and will be committed. Votes for s2' and s3' will be ignored.

+
+ +
+ +```mermaid +graph TD + s0 --> s1 + s1 --> s2 + s1 --> s2' + s2 --> |10%| s3 + s2' --> s3' + + style s2' fill:#fff,stroke:#000,stroke-width:1px,stroke-dasharray: 5 5 + style s3' fill:#fff,stroke:#000,stroke-width:1px,stroke-dasharray: 5 5 + style s3 fill:#faa,stroke:#f00,stroke-width:2px +``` + +

Fig 1 b): Time = 2Δ. Committee B was active. s3 will be committed.

+
+ +
-> :warning: Since nodes could set the timestamp arbitrarily into the future for a given slot height, we MUST require that nodes cannot vote for heights that are too far away from accepted heights. This is important for the synchronous model. +> :warning: Since nodes could set the timestamp arbitrarily into the future for a given slot height, we MUST require that nodes cannot vote for heights that are too far away from accepted heights. This is important for the quasi-synchronous model. -We assume that the nodes can become faulty or byzantine, vote for a branch with state $s^x_h$ and may acknowledge they voted for the wrong branch. +**Revoting**: We assume that the nodes can become faulty or byzantine, vote for a branch with state $s'_h$ and may acknowledge they voted for the wrong branch. We suggest that these nodes should be permitted to support a different branch (with state $s_h$) that they deem correct (and that is in conflict with their previous vote). In order to vote for $s_h$ they MUST be permitted to cast an additional vote (**revote**) for $s_h$ at height $h$. -We suggest that these nodes should be permitted to support a different branch (with state $s_h$) that they deem correct (and that is in conflict with their previous vote). In order to vote for $s_h$ they MUST be permitted to cast an additional vote (**revote**) for $s_h$ at height $h$. +
+ +
+ + ```mermaid + graph TD + s0a -->|50%| s1a + s0a -->|50%| s1a' + s1a -->|50%| s2a + ``` + +

Fig 2 a): Initial state. Vote support is indicating on the arrows.

+
+ +
+ + ```mermaid + graph TD + s0b -->|90%| s1b + s0b -->|10%| s1a' + s1b -->|90%| s2a + ``` + +

Fig 2 b): After revoting.

+
+ +
Since a the choice for a new branch would mean that all previous votes are invalid (from the point of view of the voter itself), this raises the question of how to handle revotes, and in particular the ancestor votes that depend on this. -A combination of the following two properties can be used to achieve the desired protocol: +**Protocol Options**: A combination of the following two properties can be used to achieve the desired protocol: -- Revoting +- **Revoting** 1. Revoting is not allowed. (Voter can cast one vote per slot height only) 1. Revoting is allowed. -- Counting of votes +- **Counting** of votes 1. Double counting, i.e., all votes count, including votes before revoting. 1. Only the last vote counts. -- Propagation of votes +- **Propagation** of votes 1. Votes are cast for a branch, not a state. (less transactions but per transaction more computation) 1. Votes are cast for a state, not a branch. (more transactions but per transaction less computation) @@ -177,13 +271,55 @@ Lets explore sone of the options: Step 1 of the above algorithm becomes 1. Given a vote for state $s_h$ at slot height $h$, update - $\sigma_h(s_h) \leftarrow \sigma_h(s_h) + 1$. + $\sigma(s_h) \leftarrow \sigma(s_h) + 1$. **What can go wrong?** - If no branch is finalized at $t_h^+ + \Delta$, the protocol will select the branch with the highest weight, this may not be secure against a Byzantine minority. +- Honest actors have to take care of apply their votes to all heights, otherwise the protocol will be less safe. See the Figure below, where $s_2'$ is favored over $s_2'$ despite that $s_3$' has much more weight. - Since votes of a node can double count, it is possible that eventually the wrong branch wins, since a byzantine actor plus the initial wrong "honest" votes can outvote the correct branch. + +
+ +
+ +```mermaid +graph TD + s0 -->|80%| s1 + s1 -->|10%| s2 + s1 -->|9%| s2' + s2' --> |30%| s3' + + style s1 fill:#faa,stroke:#f00,stroke-width:2px + style s2 fill:#faa,stroke:#f00,stroke-width:2px + style s2' fill:#faa,stroke:#f00,stroke-width:2px + style s3' fill:#faa,stroke:#f00,stroke-width:2px +``` + +

Fig 1 a): Time = Δ. Committee A was active. State s2 gathers the highest number of votes and will be committed. Votes for s2' and s3' will be ignored.

+
+ +
+ +```mermaid +graph TD + s0 --> s1 + s1 --> s2 + s1 --> s2' + s2 --> |10%| s3 + s2' --> s3' + + style s2' fill:#fff,stroke:#000,stroke-width:1px,stroke-dasharray: 5 5 + style s3' fill:#fff,stroke:#000,stroke-width:1px,stroke-dasharray: 5 5 + style s3 fill:#faa,stroke:#f00,stroke-width:2px +``` + +

Fig 1 b): Time = 2Δ. Committee B was active. s3 will be committed.

+
+ +
+ #### A6.2: No Revotes, single-counting, with propagation Here we would like to entertain that nodes can resubmit their vote for a different branch, but existing votes cannot be changed. We also would like to propagate votes a long a branch to ensure that this branch is maximally supported. @@ -191,7 +327,7 @@ Here we would like to entertain that nodes can resubmit their vote for a differe Step 1 of the above algorithm becomes 1. Given a vote for state $s_h$ at slot height $h$, update - 1. $\sigma_h(s_h) \leftarrow \sigma_h(s_h) + 1$. + 1. $\sigma(s_h) \leftarrow \sigma(s_h) + 1$. 2. For each ancestor state $s_{h-k}$, $k>0$ of $s_h$ in the tree that is not yet voted on, $\sigma_{h-k}(s_{h-k}) \leftarrow \sigma_{h-k}(s_{h-k}) + 1$. We note this is marginally different to the previous example. It differs only in that a voter can batch votes for a branch not a state. This is not a meaningful solution but it is the precursor to the next example. @@ -206,7 +342,7 @@ Assume the previous protocol, but votes are removed from branches that are not s Step 1 of the above algorithm becomes 1. Given a vote for state $s_h$ at slot height $h$, update - $\sigma_h(s_h) \leftarrow \sigma_h(s_h) + 1$. + $\sigma(s_h) \leftarrow \sigma(s_h) + 1$. 2. For each ancestor state $s_{h-k}$ of $s_h$ in the tree that is not finalized and for which the vote has not already been cast, $\sigma_{h-k}(s_{h-k}) \leftarrow \sigma_{h-k}(s_{h-k}) + 1$. 3. For each height $h^+< h$, remove all votes for $s_{h^+}$ from a branch that is not an ancestor of $s_h$. @@ -216,4 +352,42 @@ Step 1 of the above algorithm becomes - If no branch is finalized at $t_h^+ + \Delta$, the protocol will select the branch with the highest weight, this may not be secure against a Byzantine minority. + +
+ +
+ +```mermaid +graph TD + s0 -->|80%| s1 + s1 -->|10%| s2 + s1 -->|30%| s2' + s2' --> |30%| s3' + + style s1 fill:#faa,stroke:#f00,stroke-width:2px + style s2 fill:#faa,stroke:#f00,stroke-width:2px + style s2' fill:#faa,stroke:#f00,stroke-width:2px + style s3' fill:#faa,stroke:#f00,stroke-width:2px +``` + +

Fig 1 a): Time = Δ. Committee A was active. State s2' gathers at least the minimum number of votes of any state in that branch.

+
+ +
+ +```mermaid +graph TD + s0 --> s1 + s1 --> s2 + s1 --> s2' + s2' --> s3' + + style s2 fill:#fff,stroke:#000,stroke-width:1px,stroke-dasharray: 5 5 +``` + +

Fig 1 b): Time = 2Δ. Committee B was active. Nothing happens.

+
+ +
+ ## Changelog From 1b1afa724cb30dba83b9d75e93267ba12557cd64 Mon Sep 17 00:00:00 2001 From: apenzk Date: Wed, 9 Apr 2025 21:30:24 +0200 Subject: [PATCH 14/18] edits --- MD/md-n/README.md | 35 ++++++++++++++--------------------- 1 file changed, 14 insertions(+), 21 deletions(-) diff --git a/MD/md-n/README.md b/MD/md-n/README.md index 48ec2dd8..a703c622 100644 --- a/MD/md-n/README.md +++ b/MD/md-n/README.md @@ -1,50 +1,43 @@ -# MD-116: Dongmen Standards for Postconfirmations +# MD-116: Dongmen Standards - Liveness-favoring Postconfirmation protocol -- **Description**: Provides a set of liveness and correctness requirements for quasi-synchronous Postconfirmations protocols. +- **Description**: Provides a set of liveness and correctness requirements for liveness-favoring Postconfirmations protocols. - **Authors**: [Liam Monninger](mailto:liam@movementlabs.xyz) - **Approval**: - **Etymology**: These standards were originally drafted in the Dongmen neighborhood of Taipei. ## Overview -As identified in [MD-3](https://github.com/movementlabsxyz/MIP/tree/main/MD/md-3), [MD-4](https://github.com/movementlabsxyz/MIP/tree/main/MD/md-4), [MD-5](https://github.com/movementlabsxyz/MIP/tree/main/MD/md-5), [MIP-34](https://github.com/movementlabsxyz/MIP/pulls?page=2&q=is%3Apr+is%3Aopen), and [MIP-37](https://github.com/movementlabsxyz/MIP/pull/37), naive interpretations--such as MCR--of the Postconfirmations protocol fall short of modern BFT expectations. +We suggest and investigate a protocol which is **quasi-synchronous**, **fork-transferable**, **fork-perfect**, and **minority-aware**. The last three of these terms are introduced and defined in this MD. -We summarize the shortcomings relevant to these standards as follows: +However, we already arrive at the conclusion that a protocol that satisfies the **quasi-synchronous** requirement does not provide BFT protection. That is, confirmed branches (created through a state fork) may exist, that do not have a supermajority of support. -1. **Quasi-Asynchronicity**: +For a protocol that does satisfy BFT requirements, see the [MD-117: Ximen Postconfirmations Standards](https://github.com/movementlabsxyz/MIP/tree/l-monninger/dongmen-standards/MD/md-n). -per [FLP](https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf), protocols under asynchronous network conditions cannot achieve consensus in the presence of one or more faulty processes. As noted in [MD-118](https://github.com/movementlabsxyz/MIP/tree/main/MD/md-118) Appendix A1, the L1 essentially provides strong guarantees on the network conditions, which possibly could be classified as **totally ordered broadcast**, as the L1 records votes and finalizes them in blocks that reach all participants. +#### Motivation -!!! We do not require this discussion on asynchronicity. +As identified in [MD-3](https://github.com/movementlabsxyz/MIP/tree/main/MD/md-3), [MD-4](https://github.com/movementlabsxyz/MIP/tree/main/MD/md-4), [MD-5](https://github.com/movementlabsxyz/MIP/tree/main/MD/md-5), [MIP-34](https://github.com/movementlabsxyz/MIP/pulls?page=2&q=is%3Apr+is%3Aopen), and [MIP-37](https://github.com/movementlabsxyz/MIP/pull/37), naive interpretations--such as MCR--of the Postconfirmations protocol fall short of modern BFT expectations. -2. **Temporary Liveness issues**: +We summarize the shortcomings relevant to these standards as follows: +1. **Liveness issues**: Votes on a given commitment height may never arrive as the postconfirmation attesters may become inactive, which could stall the liveness of the protocol. - Thus, Postconfirmations protocols that do not define synchronization times, timeouts and/or a view change on who is the attester committee, can loose liveness indefinitely. -3. **Temporary forks**: - +2. **Temporary forks**: Failure to come to consensus presents a liveness shortcoming. Permanent disagreement about the state on L2 means that the network will never progress to the next accepted state. We assert indefinite disagreement is unnecessary in the context of Postconfirmations, as attesters may change over time or their view of the state may change. -OLD - -, are **not in fact BFT consensus protocols.** MCR, for example--if implemented with a single vote per slot and without any bound on when the slot moves to a new committee--may remain in permanent disagreement. +Certain types of Postconfirmation protocols are, thus, **not in fact BFT consensus protocols.** MCR, for example--if implemented with a single vote per commitment slot height or without any bound on when the slot moves to a new committee--may remain in permanent disagreement. For more detailed information on these properties, see [BFT Synchronicity and Liveness](#a1-bft-synchronicity-and-liveness). -In response to these shortcomings, this MD requests a protocol which is **quasi-synchronous**, **fork-transferable**, **fork-perfect**, and **minority-aware**. The last three of these terms are introduced and defined in this MD. - -In order to be a **quasi-synchronous** protocol, we assert said protocol can no longer be traditionally-BFT. That is, non-supermajority branches may exist under these standards. For a protocol that satisfies BFT requirements, see the [Ximen Postconfirmations Standards](). - ## Definitions - **Fork and Branch**: A fork on L2 is the event of a divergence in what is considered the "correct" state on L2. A branch is a chain of blocks (or consensus rounds). A fork creates two or more branches. - **Quasi-models**: We attempt to transfer the concept of message propagation guarantees in network models to the Postconfirmation protocol. For more details on the models, see [Appendix A1.1](). - - **Quasi-synchronous**: The protocol assume that all relevant voting messages are delivered within time $\Delta$. Based on the received votes, the protocol will make a decision. Messages destined to be handled within the bound may arrive outside of these bounds, however, they are then ignored. It is liveness-favoring. - - **Quasi-partially synchronous**: A supermajority of votes are delivered within time $\Delta$ at some finite point in the future. Steps are taken to ensure that the protocol can make a decision at some finite point in the future. This is similar to the concept of Global Stabilization Time (GST). This is safety-favoring. - - **Quasi-asynchronous**: There is no bound on when the supermajority of votes will be delivered. This is safety-favoring. + - **Quasi-synchronous**: The protocol assume that all relevant voting messages are delivered within time $\Delta$. Based on the received votes, the protocol will make a decision. Messages destined to be handled within the bound may arrive outside of these bounds, however, they are then ignored. It is **liveness-favoring**. + - **Quasi-partially synchronous**: A supermajority of votes are delivered within time $\Delta$ at some finite point in the future. Steps are taken to ensure that the protocol can make a decision at some finite point in the future. This is similar to the concept of Global Stabilization Time (GST). This is **safety-favoring**. + - **Quasi-asynchronous**: There is no bound on when the supermajority of votes will be delivered. This is **safety-favoring**. - **Branch-transferable**: A property of a protocol that allows consumers to transfer application state from a forked chain of consensus rounds (i.e. a branch) while preserving verifiability and audibility, even in the presence of honest partitions or temporary disagreement. From 0d98357c872c466a534422a5989ea7b872d369bd Mon Sep 17 00:00:00 2001 From: apenzk Date: Wed, 9 Apr 2025 21:32:21 +0200 Subject: [PATCH 15/18] color adjustment --- MD/md-n/README.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/MD/md-n/README.md b/MD/md-n/README.md index a703c622..f84fd117 100644 --- a/MD/md-n/README.md +++ b/MD/md-n/README.md @@ -188,7 +188,7 @@ graph TD style s3' fill:#faa,stroke:#f00,stroke-width:2px ``` -

Fig 1 a): Time = Δ. Committee A was active. s2 gathers the highest number of votes and will be committed. Votes for s2' and s3' will be ignored.

+

Fig 1 a): Time = Δ. Committee A (red) was active. s2 gathers the highest number of votes and will be committed. Votes for s2' and s3' will be ignored.

@@ -203,10 +203,10 @@ graph TD style s2' fill:#fff,stroke:#000,stroke-width:1px,stroke-dasharray: 5 5 style s3' fill:#fff,stroke:#000,stroke-width:1px,stroke-dasharray: 5 5 - style s3 fill:#faa,stroke:#f00,stroke-width:2px + style s3 fill:#afa,stroke:#0a0,stroke-width:2px ``` -

Fig 1 b): Time = 2Δ. Committee B was active. s3 will be committed.

+

Fig 1 b): Time = 2Δ. Committee B (green)was active. s3 will be committed.

@@ -290,7 +290,7 @@ graph TD style s3' fill:#faa,stroke:#f00,stroke-width:2px ``` -

Fig 1 a): Time = Δ. Committee A was active. State s2 gathers the highest number of votes and will be committed. Votes for s2' and s3' will be ignored.

+

Fig 1 a): Time = Δ. Committee A (red) was active. State s2 gathers the highest number of votes and will be committed. Votes for s2' and s3' will be ignored.

@@ -305,10 +305,10 @@ graph TD style s2' fill:#fff,stroke:#000,stroke-width:1px,stroke-dasharray: 5 5 style s3' fill:#fff,stroke:#000,stroke-width:1px,stroke-dasharray: 5 5 - style s3 fill:#faa,stroke:#f00,stroke-width:2px + style s3 fill:#afa,stroke:#0a0,stroke-width:2px ``` -

Fig 1 b): Time = 2Δ. Committee B was active. s3 will be committed.

+

Fig 1 b): Time = 2Δ. Committee B (green) was active. s3 will be committed.

@@ -363,7 +363,7 @@ graph TD style s3' fill:#faa,stroke:#f00,stroke-width:2px ``` -

Fig 1 a): Time = Δ. Committee A was active. State s2' gathers at least the minimum number of votes of any state in that branch.

+

Fig 1 a): Time = Δ. Committee A (red) was active. State s2' gathers at least the minimum number of votes of any state in that branch.

From 0540a6a7610fed26ecc79b997aea3a85e1e0bc6e Mon Sep 17 00:00:00 2001 From: apenzk Date: Wed, 9 Apr 2025 21:33:05 +0200 Subject: [PATCH 16/18] change folder --- MD/{md-n => md-116}/README.md | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename MD/{md-n => md-116}/README.md (100%) diff --git a/MD/md-n/README.md b/MD/md-116/README.md similarity index 100% rename from MD/md-n/README.md rename to MD/md-116/README.md From 99dc3032952ea606ec9ab9b8b4a7ec3c9abc3199 Mon Sep 17 00:00:00 2001 From: apenzk Date: Wed, 9 Apr 2025 22:22:24 +0200 Subject: [PATCH 17/18] update mermaids --- MD/md-116/README.md | 219 ++++++++++++++++++++------------------------ 1 file changed, 97 insertions(+), 122 deletions(-) diff --git a/MD/md-116/README.md b/MD/md-116/README.md index f84fd117..2b1d79df 100644 --- a/MD/md-116/README.md +++ b/MD/md-116/README.md @@ -171,77 +171,63 @@ The basic protocol looks as follows: Note that 2.ii) is where the **quasi-synchronous nature** of the protocol is used, and which implies a liveness-favoring property. -
- -
- ```mermaid graph TD - s0 -->|11%| s1 - s1 -->|10%| s2 - s1 -->|9%| s2' - s2' --> |9%| s3' - - style s1 fill:#faa,stroke:#f00,stroke-width:2px - style s2 fill:#faa,stroke:#f00,stroke-width:2px - style s2' fill:#faa,stroke:#f00,stroke-width:2px - style s3' fill:#faa,stroke:#f00,stroke-width:2px + %% Subgraph for Fig 1 b + subgraph "Fig 1 b)" + s0b["s_0"] --> s1b["s_1"] + s1b --> s2b["s_2"] + s1b --> s2b'["s_2'"] + s2b -->|10%| s3b["s_3"] + s2b' --> s3b'["s_3'"] + + style s2b' fill:#fff,stroke:#000,stroke-width:1px,stroke-dasharray: 5 5 + style s3b' fill:#fff,stroke:#000,stroke-width:1px,stroke-dasharray: 5 5 + style s3b fill:#afa,stroke:#0a0,stroke-width:2px + end + + %% Subgraph for Fig 1 a + subgraph "Fig 1 a)" + s0a["s_0"] -->|11%| s1a["s_1"] + s1a -->|10%| s2a["s_2"] + s1a -->|9%| s2a'["s_2'"] + s2a' -->|9%| s3a'["s_3'"] + + style s1a fill:#faa,stroke:#f00,stroke-width:2px + style s2a fill:#faa,stroke:#f00,stroke-width:2px + style s2a' fill:#faa,stroke:#f00,stroke-width:2px + style s3a' fill:#faa,stroke:#f00,stroke-width:2px + end ``` -

Fig 1 a): Time = Δ. Committee A (red) was active. s2 gathers the highest number of votes and will be committed. Votes for s2' and s3' will be ignored.

-
- -
- -```mermaid -graph TD - s0 --> s1 - s1 --> s2 - s1 --> s2' - s2 --> |10%| s3 - s2' --> s3' - - style s2' fill:#fff,stroke:#000,stroke-width:1px,stroke-dasharray: 5 5 - style s3' fill:#fff,stroke:#000,stroke-width:1px,stroke-dasharray: 5 5 - style s3 fill:#afa,stroke:#0a0,stroke-width:2px -``` +*Fig 1 a: Committee A (🟥 ). Time = Δ. Committee A (red) was active for (0..Δ]. `s_2` gathers the highest number of votes and will be committed. Votes for `s_2'` and `s_3'` will be ignored.* -

Fig 1 b): Time = 2Δ. Committee B (green)was active. s3 will be committed.

-
+*Fig 1 b: Committee B (🟩 ). Time = 2Δ. Committee B (green) was active for (Δ..2Δ]. `s_3` will be committed.* -
> :warning: Since nodes could set the timestamp arbitrarily into the future for a given slot height, we MUST require that nodes cannot vote for heights that are too far away from accepted heights. This is important for the quasi-synchronous model. **Revoting**: We assume that the nodes can become faulty or byzantine, vote for a branch with state $s'_h$ and may acknowledge they voted for the wrong branch. We suggest that these nodes should be permitted to support a different branch (with state $s_h$) that they deem correct (and that is in conflict with their previous vote). In order to vote for $s_h$ they MUST be permitted to cast an additional vote (**revote**) for $s_h$ at height $h$. -
- -
- - ```mermaid - graph TD - s0a -->|50%| s1a - s0a -->|50%| s1a' - s1a -->|50%| s2a - ``` - -

Fig 2 a): Initial state. Vote support is indicating on the arrows.

-
- -
- - ```mermaid - graph TD - s0b -->|90%| s1b - s0b -->|10%| s1a' - s1b -->|90%| s2a - ``` - -

Fig 2 b): After revoting.

-
+```mermaid +graph TD + %% Subgraph for Fig 2 b + subgraph "Fig 2 b) After revoting" + s0b["s_0"] -->|90%| s1b["s_1"] + s0b -->|10%| s1b'["s_1'"] + s1b -->|90%| s2b["s_2"] + end + + %% Subgraph for Fig 2 a + subgraph "Fig 2 a) Initial state" + s0a["s_0"] -->|50%| s1a["s_1"] + s0a -->|50%| s1a'["s_1'"] + s1a -->|50%| s2a["s_2"] + end +``` -
+*Fig 2 a: Initial state. Vote support is indicated on the arrows.* +*Fig 2 b: After revoting.* Since a the choice for a new branch would mean that all previous votes are invalid (from the point of view of the voter itself), this raises the question of how to handle revotes, and in particular the ancestor votes that depend on this. @@ -272,46 +258,40 @@ Step 1 of the above algorithm becomes - Honest actors have to take care of apply their votes to all heights, otherwise the protocol will be less safe. See the Figure below, where $s_2'$ is favored over $s_2'$ despite that $s_3$' has much more weight. - Since votes of a node can double count, it is possible that eventually the wrong branch wins, since a byzantine actor plus the initial wrong "honest" votes can outvote the correct branch. - -
- -
- ```mermaid graph TD - s0 -->|80%| s1 - s1 -->|10%| s2 - s1 -->|9%| s2' - s2' --> |30%| s3' - - style s1 fill:#faa,stroke:#f00,stroke-width:2px - style s2 fill:#faa,stroke:#f00,stroke-width:2px - style s2' fill:#faa,stroke:#f00,stroke-width:2px - style s3' fill:#faa,stroke:#f00,stroke-width:2px -``` - -

Fig 1 a): Time = Δ. Committee A (red) was active. State s2 gathers the highest number of votes and will be committed. Votes for s2' and s3' will be ignored.

-
-
+ %% Subgraph for Fig 3 b + subgraph "Fig 3 b)" + s0b["s_0"] --> s1b["s_1"] + s1b --> s2b["s_2"] + s1b --> s2b'["s_2'"] + s2b -->|10%| s3b["s_3"] + s2b' --> s3b'["s_3'"] + + style s2b' fill:#fff,stroke:#000,stroke-width:1px,stroke-dasharray: 5 5 + style s3b' fill:#fff,stroke:#000,stroke-width:1px,stroke-dasharray: 5 5 + style s3b fill:#afa,stroke:#0a0,stroke-width:2px + end + + %% Subgraph for Fig 3 a + subgraph "Fig 3 a)" + s0a["s_0"] -->|80%| s1a["s_1"] + s1a -->|10%| s2a["s_2"] + s1a -->|9%| s2a'["s_2'"] + s2a' -->|30%| s3a'["s_3'"] + + style s1a fill:#faa,stroke:#f00,stroke-width:2px + style s2a fill:#faa,stroke:#f00,stroke-width:2px + style s2a' fill:#faa,stroke:#f00,stroke-width:2px + style s3a' fill:#faa,stroke:#f00,stroke-width:2px + end -```mermaid -graph TD - s0 --> s1 - s1 --> s2 - s1 --> s2' - s2 --> |10%| s3 - s2' --> s3' - - style s2' fill:#fff,stroke:#000,stroke-width:1px,stroke-dasharray: 5 5 - style s3' fill:#fff,stroke:#000,stroke-width:1px,stroke-dasharray: 5 5 - style s3 fill:#afa,stroke:#0a0,stroke-width:2px ``` -

Fig 1 b): Time = 2Δ. Committee B (green) was active. s3 will be committed.

-
+*Fig 3 a: Committee A (🟥 ). Time = Δ. Committee A was active for (0..Δ]. State `s_2` gathers the highest number of votes and will be committed. Votes for `s_2'` and `s_3'` will be ignored.* -
+*Fig 3 b: Committee B (🟩 ). Time = 2Δ. Committee B was active for (Δ..2Δ]. `s_3` will be committed.* #### A6.2: No Revotes, single-counting, with propagation @@ -345,42 +325,37 @@ Step 1 of the above algorithm becomes - If no branch is finalized at $t_h^+ + \Delta$, the protocol will select the branch with the highest weight, this may not be secure against a Byzantine minority. - -
- -
- ```mermaid graph TD - s0 -->|80%| s1 - s1 -->|10%| s2 - s1 -->|30%| s2' - s2' --> |30%| s3' - - style s1 fill:#faa,stroke:#f00,stroke-width:2px - style s2 fill:#faa,stroke:#f00,stroke-width:2px - style s2' fill:#faa,stroke:#f00,stroke-width:2px - style s3' fill:#faa,stroke:#f00,stroke-width:2px -``` -

Fig 1 a): Time = Δ. Committee A (red) was active. State s2' gathers at least the minimum number of votes of any state in that branch.

-
+ %% Subgraph for Fig 4 b + subgraph "Fig 4 b)" + s0b["s_0"] --> s1b["s_1"] + s1b --> s2b["s_2"] + s1b --> s2b'["s_2'"] + s2b' --> s3b'["s_3'"] + + style s2b fill:#fff,stroke:#000,stroke-width:1px,stroke-dasharray: 5 5 + end + + %% Subgraph for Fig 4 a + subgraph "Fig 4 a)" + s0a["s_0"] -->|80%| s1a["s_1"] + s1a -->|10%| s2a["s_2"] + s1a -->|30%| s2a'["s_2'"] + s2a' -->|30%| s3a'["s_3'"] + + style s1a fill:#faa,stroke:#f00,stroke-width:2px + style s2a fill:#faa,stroke:#f00,stroke-width:2px + style s2a' fill:#faa,stroke:#f00,stroke-width:2px + style s3a' fill:#faa,stroke:#f00,stroke-width:2px + end -
- -```mermaid -graph TD - s0 --> s1 - s1 --> s2 - s1 --> s2' - s2' --> s3' - - style s2 fill:#fff,stroke:#000,stroke-width:1px,stroke-dasharray: 5 5 ``` -

Fig 1 b): Time = 2Δ. Committee B was active. Nothing happens.

-
+*Fig 4 a: Committee A (🟥 ). Time = Δ. Committee A was active for (0..Δ]. State `s_2'` gathers at least the minimum number of votes of any state in that branch.* + +*Fig 4 b: Committee B (🟩 ). Time = 2Δ. Committee B was active for (Δ..2Δ]. Nothing happens.* -
## Changelog From a1698bbb69eb36af9bbeeb7e92207f61bbc518b9 Mon Sep 17 00:00:00 2001 From: apenzk Date: Thu, 10 Apr 2025 10:44:00 +0200 Subject: [PATCH 18/18] applied review --- MD/md-116/README.md | 51 ++++++++++++++++++++++++--------------------- 1 file changed, 27 insertions(+), 24 deletions(-) diff --git a/MD/md-116/README.md b/MD/md-116/README.md index 2b1d79df..8fbb2bc2 100644 --- a/MD/md-116/README.md +++ b/MD/md-116/README.md @@ -1,4 +1,4 @@ -# MD-116: Dongmen Standards - Liveness-favoring Postconfirmation protocol +# MD-116: Dongmen Standards for Postconfirmations - **Description**: Provides a set of liveness and correctness requirements for liveness-favoring Postconfirmations protocols. - **Authors**: [Liam Monninger](mailto:liam@movementlabs.xyz) @@ -7,34 +7,34 @@ ## Overview -We suggest and investigate a protocol which is **quasi-synchronous**, **fork-transferable**, **fork-perfect**, and **minority-aware**. The last three of these terms are introduced and defined in this MD. +We suggest and investigate a protocol which is **quasi-synchronous**, **branch-transferable**, **branch-perfect**, and **minority-aware**. The last three of these terms are introduced and defined in this MD. However, we already arrive at the conclusion that a protocol that satisfies the **quasi-synchronous** requirement does not provide BFT protection. That is, confirmed branches (created through a state fork) may exist, that do not have a supermajority of support. For a protocol that does satisfy BFT requirements, see the [MD-117: Ximen Postconfirmations Standards](https://github.com/movementlabsxyz/MIP/tree/l-monninger/dongmen-standards/MD/md-n). -#### Motivation +### Motivation As identified in [MD-3](https://github.com/movementlabsxyz/MIP/tree/main/MD/md-3), [MD-4](https://github.com/movementlabsxyz/MIP/tree/main/MD/md-4), [MD-5](https://github.com/movementlabsxyz/MIP/tree/main/MD/md-5), [MIP-34](https://github.com/movementlabsxyz/MIP/pulls?page=2&q=is%3Apr+is%3Aopen), and [MIP-37](https://github.com/movementlabsxyz/MIP/pull/37), naive interpretations--such as MCR--of the Postconfirmations protocol fall short of modern BFT expectations. We summarize the shortcomings relevant to these standards as follows: -1. **Liveness issues**: -Votes on a given commitment height may never arrive as the postconfirmation attesters may become inactive, which could stall the liveness of the protocol. +1. **Quasi-asynchronicity**: per [FLP](https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf), protocols that operate with asynchronous network conditions, cannot achieve consensus in the presence of one or more faulty processes. Similarly, certain variants of Postconfirmation protocol, which do not define an upper bound on voting times, may halt indefinitely if enough attesters become inactive. We call these quasi-asynchronous Postconfirmation protocols, see [Definitions](#definitions) for more details. Note that the concept of quasi-asynchrony does not map to asynchrony as the L1 provides total order broadcast, and thus synchrony on vote message dissemination. However, we suggest this helps to explain the problem. An example, would be the implementation of [MCR](https://github.com/movementlabsxyz/ffs/blob/4ffcccb950611964d5929cdb300638ecaebfe3c4/protocol/mcr/README.md). If implemented with a single vote per slot and without any bound on when the slot moves to a new committee, it may remain in permanent disagreement. + +2. **Liveness issues**: +Votes on a given commitment height may never arrive as the postconfirmation attesters may become inactive, which could halt the liveness of the protocol. Thus, Postconfirmations protocols that do not define synchronization times, timeouts and/or a view change on who is the attester committee, can loose liveness indefinitely. -2. **Temporary forks**: +3. **Temporary forks**: Failure to come to consensus presents a liveness shortcoming. Permanent disagreement about the state on L2 means that the network will never progress to the next accepted state. We assert indefinite disagreement is unnecessary in the context of Postconfirmations, as attesters may change over time or their view of the state may change. -Certain types of Postconfirmation protocols are, thus, **not in fact BFT consensus protocols.** MCR, for example--if implemented with a single vote per commitment slot height or without any bound on when the slot moves to a new committee--may remain in permanent disagreement. - -For more detailed information on these properties, see [BFT Synchronicity and Liveness](#a1-bft-synchronicity-and-liveness). +For more detailed information on these properties, see Appendix [A1: Classification of the Protocol](#a1-classification-of-the-protocol). ## Definitions - **Fork and Branch**: A fork on L2 is the event of a divergence in what is considered the "correct" state on L2. A branch is a chain of blocks (or consensus rounds). A fork creates two or more branches. -- **Quasi-models**: We attempt to transfer the concept of message propagation guarantees in network models to the Postconfirmation protocol. For more details on the models, see [Appendix A1.1](). +- **Quasi-models**: We attempt to transfer the concept of message propagation guarantees in network models to the Postconfirmation protocol. For more details on the models, see [Appendix A1](#a1-classification-of-the-protocol). - **Quasi-synchronous**: The protocol assume that all relevant voting messages are delivered within time $\Delta$. Based on the received votes, the protocol will make a decision. Messages destined to be handled within the bound may arrive outside of these bounds, however, they are then ignored. It is **liveness-favoring**. - **Quasi-partially synchronous**: A supermajority of votes are delivered within time $\Delta$ at some finite point in the future. Steps are taken to ensure that the protocol can make a decision at some finite point in the future. This is similar to the concept of Global Stabilization Time (GST). This is **safety-favoring**. - **Quasi-asynchronous**: There is no bound on when the supermajority of votes will be delivered. This is **safety-favoring**. @@ -55,7 +55,7 @@ For more detailed information on these properties, see [BFT Synchronicity and Li **Justification**: A quasi-synchronous protocol provides predictable points in time by which a decision will be made. It is liveness-favoring. It does not provide guarantees against byzantine actors with respect to selecting the correct state for the L2. -The requirement of **quasi-synchronicity** means that if a supermajority decision is not made by some time $\Delta$, some form of minority decision must effectively be made, for the protocol to make progress. In essence this means that the protocol is **liveness-favoring**, see Appendix [A1.2](). +The requirement of **quasi-synchronicity** means that if a supermajority decision is not made by some time $\Delta$, some form of minority decision must effectively be made, for the protocol to make progress. In essence this means that the protocol is **liveness-favoring**, see Appendix [A1](#a1-classification-of-the-protocol). Regardless, Dongmen Postconfirmation protocols are required to provide a formal model of the expected value of consensus on a Byzantine minority w.r.t. the value of the state and intrinsic rewards. In other words, they must explain the nature of eventual safety (with respect to Byzantine assumptions) or else describe the non-BFT nature of the protocol at quasi-synchronous decision points. @@ -77,6 +77,8 @@ Regardless, Dongmen Postconfirmation protocols are required to provide a formal **Justification**: We assert that the [**quasi-synchronicity**](#d1-quasi-synchronous) of Postconfirmations complicates BFT assumptions. These complications must be well understood for a given protocol. +**Recommendation**: To illustrate the possible protocols that could be possible with minority-aware properties, we provide a selection of examples in [Appendix A4](#a4-examples-minority-selecting-protocols). + ## Appendix ### A1: Classification of the Protocol @@ -92,6 +94,8 @@ In Network theory, the following models for message propagation and arrival are Similarly here we define Quasi-metrics for the Postconfirmation protocol that exists on the L1 contract. For this we focus on the timely delivery of votes from the L2 on the L1. +In the following table, we consider that safe means safe in the context BFT assumptions with 2/3 honest voting power. + | Property / Feature | Quasi-synchronous | Quasi-partially Synchronous | Quasi-asynchronous | |-------------------------------|---------------------------|-------------------------------|------------------------| | Liveness possible? | Yes, but unsafe | Yes, eventually | No | @@ -109,10 +113,9 @@ We may also consider the protocol in terms of liveness-favoring and safety-favor | Safety Guarantee | Have to use unsafe majority assumptions | Safe | Safe | | Byzantine Fault Tolerance | No | Yes | Yes | - ### A2: PBFT and Perfectness -[PBFT](https://pmg.csail.mit.edu/papers/osdi99.pdf) introduced a protocol which ensures consecutive rounds of consensus intersect in at least one unit of honest voting power via the Generalized Pigeon Hole Principle. The transitivity of this property ensures that a chain of consensus rounds must intersect in at least one unit of honest voting power. +[PBFT](https://pmg.csail.mit.edu/papers/osdi99.pdf) introduced a protocol which ensures consecutive rounds of consensus intersect in at least one unit of honest voting power via the Generalized Pigeon Hole Principle. The transitivity of this property ensures that a chain of consensus rounds must intersect in at least one unit of honest voting power. Under an [experts model](https://people.csail.mit.edu/ghaffari/AA19/AAscript.pdf?utm_source=chatgpt.com) understanding of PBFT systems, we can make an assumption that there is a perfect expert and thus that this perfect expert is identified by consensus. This, in turn, renders PBFT a lossless approximate algorithm. @@ -120,16 +123,17 @@ If we consider allowing forks, however, it is initially unclear how perfectness We can, however, apply a reduced criterion and state that a each **branch** be comprised of a chain of consensus rounds each of which intersect in one unit of honest voting power w.r.t. to the fork itself. We call this **branch-perfectness**. -Preserving **branch-perfectness** reduces to ensuring the fraction of stake which was involved in the fork and which resulted in the winning branch maintains a supermajority. If this does not occur, then it is impossible to have the guaranteed intersection. - +Preserving **branch-perfectness** reduces to ensuring the fraction of stake which was involved in the fork and which resulted in the winning branch maintains a supermajority. If this does not occur, then it is impossible to have the guaranteed intersection. ### A3: Example Minority-Aware Protocol +> This is a sketch for the purpose of demonstrating how Minority-Awareness would be proven. + Consider the following quasi-synchronous protocol: -1. Votes $v \in V_h$ are cast for states $s \in S_h$ at height $h \in H$. +1. Votes $v \in V_h$ are cast for states $s \in S_h$ at height $h \in H$. The maximal number of votes for a state can be $N$. 2. A decision in made on a vote $s, h$ by time $t \in T$. - 1. If $V_{h}(s) > \frac{2*|V|}{3}$, accept $s, h$ + 1. If $V_{h}(s) > \frac{2}{3}N$, accept $s, h$ 2. Otherwise, begin **Play Foward** algorithm. The **Play Forward** algorithm is as follows: @@ -140,10 +144,10 @@ If $l' > d$, accept the root $s, h$ of the heaviest remaining subtree by weight. Otherwise, for each tuple $(s, h') \in V_{h'}$ -1. If $V_{h'}(s) > \frac{2*|V|}{3}$, accept $s, h$, i.e., the original commitment at the root of the subtree. +1. If $V_{h'}(s) > \frac{2}{3}N$, accept $s, h$, i.e., the original commitment at the root of the subtree. 2. If $V_{h'}(s) = \text{argmin} V_{h'}(s)$, remove all tuples $s, h \leq V_{h'}(s)$ and their descendants from the entire tree. -At any given round, the number of ways the Byzantine fraction $\frac{|V|}{3} - 1$ can be eliminated is $n' = (incomplete)$ out of the total number of combinations $n$. +At any given round, the number of ways the Byzantine fraction $\frac{N}{3} - 1$ can be eliminated is $n' = (incomplete)$ out of the total number of combinations $n$. Thus, the probability of that the Byzantine fraction makes it to the final acceptance is $p =(incomplete)$. @@ -153,7 +157,7 @@ Thus, our protocol now admits a $p$ probability of Byzantine attack. The expecte This is **quasiy-synchronous** because a decision will be cast on $h$ by $t + d$. -### A6: Examples Minority-Selecting Protocols +### A4: Examples Minority-Selecting Protocols Consider the following quasi-synchronous protocol: @@ -245,7 +249,7 @@ Since a the choice for a new branch would mean that all previous votes are inval Lets explore sone of the options: -#### A6.1: Revotes, double counting, no propagation +#### A4.1: Revotes, double counting, no propagation Step 1 of the above algorithm becomes @@ -293,7 +297,7 @@ graph TD *Fig 3 b: Committee B (🟩 ). Time = 2Δ. Committee B was active for (Δ..2Δ]. `s_3` will be committed.* -#### A6.2: No Revotes, single-counting, with propagation +#### A4.2: No Revotes, single-counting, with propagation Here we would like to entertain that nodes can resubmit their vote for a different branch, but existing votes cannot be changed. We also would like to propagate votes a long a branch to ensure that this branch is maximally supported. @@ -308,7 +312,7 @@ We note this is marginally different to the previous example. It differs only in **What can go wrong?** 1. Same problem as previous example. -#### A6.3: Revotes, single-counting, with propagation +#### A4.3: Revotes, single-counting, with propagation Assume the previous protocol, but votes are removed from branches that are not supported any longer. This means we override previous votes. @@ -357,5 +361,4 @@ graph TD *Fig 4 b: Committee B (🟩 ). Time = 2Δ. Committee B was active for (Δ..2Δ]. Nothing happens.* - ## Changelog