[draft] MD-116: Dongmen (Postconfirmations) Standards #116
Conversation
l-monninger
changed the title
MD/md-n/README.md
Outdated
|
|
||
| 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. |
There was a problem hiding this comment.
I believe it is still defined in the MCR comments.
There was a problem hiding this comment.
i dont understand what comments. it needs to be defined in this document.
apenzk
left a comment
apenzk
left a comment
There was a problem hiding this comment.
Thanks for this great start. There are a few things to address
- synchronous vs partial synchronous needs fixing. They get a bit mixed up
- rounds, slots, heights needs better defining
- several comments on the algorithm A4
MD/md-n/README.md
Outdated
|
|
||
| - **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. |
There was a problem hiding this comment.
what is an honest partition? this should be defined. the partition is either due to faults or due to byzantine. whether it is honest does not seem to matter here.
There was a problem hiding this comment.
I'm introducing this term to describe behavior that is honest w.r.t. to some subset of participants in the original network. An "honest partition," is what would create a long-lived fork.
There was a problem hiding this comment.
this needs to be defined in text. only mentioning it is not an introduction
MD/md-n/README.md
Outdated
|
|
||
| - **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. |
There was a problem hiding this comment.
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 sentence is not clear. what do you mean with "along the fork". In your description a fork seems a particular event (which makes sense), so do you mean "after the fork"? Or do you mean "along a branch".
There was a problem hiding this comment.
We can use fork or branch. The "fork-point" is IMO the more common term to refer to the actual place in the tree that contains more than one child.
There was a problem hiding this comment.
I'll refer to wolfram for the difference between fork and branch. I do acknowledge that software development has lost its way with the terminology of branch and fork :) . But here we are more concerned with the mathematical behavior and hence should stick to the mathematical definitions.
https://mathworld.wolfram.com/Fork.html
https://mathworld.wolfram.com/Branch.html
MD/md-n/README.md
Outdated
|
|
||
| - **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. |
There was a problem hiding this comment.
In consensus, identifying this expert is analogous to identifying a perfect fork.<
why?
There was a problem hiding this comment.
I think this is just redundant and confusing to be honest. If you know the expert, then you know the values of the "perfect fork." But, that statement kind distracts what is actually important in this setting, i.e., the ability to produce that perfectness via PBFT.
MD/md-n/README.md
Outdated
|
|
||
| - **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. |
There was a problem hiding this comment.
If
MD/md-n/README.md
Outdated
|
|
||
| - **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. |
There was a problem hiding this comment.
unclear what you are trying to say with that first sentence.
There was a problem hiding this comment.
Which first sentence. There's an appendix describing this in detail.
There was a problem hiding this comment.
link to the appendix missing
MD/md-n/README.md
Outdated
|
|
||
| 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. |
There was a problem hiding this comment.
| 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*|V|}{3}$, accept $(s, h)$, i.e., the original commitment at the root of the subtree. |
MD/md-n/README.md
Outdated
| 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: |
There was a problem hiding this comment.
it is not clear how the voting would work. i take it that within a given duration
There was a problem hiding this comment.
I left this as sketch because the important thing for the MD is not the algorithm, but the way it outlines how Dongmen Protocols should describe their BFT qualities.
MD/md-n/README.md
Outdated
|
|
||
| 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. |
There was a problem hiding this comment.
- more consistency. use (s,h) not s,h
- you have not defined what means heaviest subtree, or how this results in a weighted tree ( i am aware how this would works, but it should be written explicitly)
MD/md-n/README.md
Outdated
|
|
||
| If $l' > d$, accept the root $s, h$ of the heaviest remaining subtree by weight. | ||
|
|
||
| Otherwise, for each tuple $(s, h') \in V_{h'}$ |
There was a problem hiding this comment.
- V_h is not set of tuples
- the "otherwise ... 1)" should come before the above, as it is the primary check, no?
MD/md-n/README.md
Outdated
| 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$. |
There was a problem hiding this comment.
- first time of mention of round. it is not defined
- it is not N/3 -1 : the assumption is f/(3f+1), N = 3f+1 , therefore f = (N-1)/3
MD/md-n/README.md
Outdated
| 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. |
There was a problem hiding this comment.
it MUST be explained how disagreements could occur with only honest participants (this seemed to be your core argument). if nodes can arrive at a wrong state but think they are honest, this requires they are accounted for in the byzantine set even in pbft
Consider what it would mean in pBFT protocol if honest nodes change their opinion
- N_A = f+1 of honest nodes N = 2f+1 calculate S_A and vote for it.
- N_B = f of honest nodes vote for S_B
- N_C = f dishonest nodes vote for S_B.
S2 has more votes. Now permit that honest nodes can change their opinion.
-
One node of N_A changes to S_B. Supermajority Sup_B reached.
-
Two nodes of N_C change to S_A. Supermajority Sup_A reached.
-
C partitions the network: forward Sup_B to half of network, submit Sup_A to other part. Safety is violated.
PBFT is not safe under the error you assume. I.e. the nodes that vote for the wrong fork MUST be accounted for in the malicious node set.
There was a problem hiding this comment.
if you indeed acknowledge this in MD-116 plz refer to the specific section.
There was a problem hiding this comment.
if nodes can arrive at a wrong state but think they are honest, this requires they are accounted for in the byzantine set even in pbft
This is the not the what the quoted text is referring to. It's more briefly stating that...
- An asynchronous protocol is not a (reliable) consensus protocol. It will sometimes show agreement, but one fault ruins it. That's FLP.
- Because we are trying to design a consensus protocol, this unreliability actually means unliveness. Or, a non-consensus protocol is an unlive consensus protocol.
Co-authored-by: Andreas Penzkofer <[email protected]>
Co-authored-by: Andreas Penzkofer <[email protected]>
Co-authored-by: Andreas Penzkofer <[email protected]>
Co-authored-by: Andreas Penzkofer <[email protected]>
…bsxyz/MIP into l-monninger/dongmen-standards
franck44
changed the title
franck44
added
settlement
Needs changes
MD/md-n/README.md
Outdated
|
|
||
| ### 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. |
There was a problem hiding this comment.
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.
You are just describing a system that favors liveness over safety. in the system you describe there is never any finality. Which makes any quasi-synchronous decission void. you may as well not take a decission at point Delta.
…ustments [update] MD-116
Summary
MD-116