From 04e773000c562bd4812e342f862326eefdc538ce Mon Sep 17 00:00:00 2001 From: Daira Emma Hopwood Date: Thu, 28 Dec 2023 02:17:27 +0000 Subject: [PATCH 1/3] Crosslink docs: cosmetics and link fixes. Signed-off-by: Daira Emma Hopwood --- src/design/crosslink/construction.md | 248 +++++++++--------- .../crosslink/notes-on-snap-and-chat.md | 47 ++-- src/design/crosslink/potential-changes.md | 24 +- src/design/crosslink/questions.md | 4 +- src/design/crosslink/security-analysis.md | 58 ++-- ...mic-availability-and-finality-overrides.md | 105 ++++---- 6 files changed, 245 insertions(+), 241 deletions(-) diff --git a/src/design/crosslink/construction.md b/src/design/crosslink/construction.md index f31ec08..7a1ca86 100644 --- a/src/design/crosslink/construction.md +++ b/src/design/crosslink/construction.md @@ -1,37 +1,37 @@ # The Crosslink Construction -We are now ready to give a description of a variant of Snap‑and‑Chat that takes into account the issues described in [Notes on Snap‑and‑Chat](./notes-on-snap-and-chat.md), and that implements [bounded dynamic availability](./the-arguments-for-bounded-dynamic-availability-and-finality-overrides.md). I call this the "Crosslink" construction. I will try to make the description relatively self-contained, but knowledge of the Snap‑and‑Chat construction from [[NTT2020]](https://eprint.iacr.org/2020/1091.pdf) ([arXiv version](https://arxiv.org/pdf/2009.04987.pdf)) is assumed. +We are now ready to give a description of a variant of Snap‑and‑Chat that takes into account the issues described in [Notes on Snap‑and‑Chat](./notes-on-snap-and-chat.md), and that implements [bounded dynamic availability](./the-arguments-for-bounded-dynamic-availability-and-finality-overrides.md#what-is-bounded-dynamic-availability). I call this the “Crosslink” construction. I will try to make the description relatively self-contained, but knowledge of the Snap‑and‑Chat construction from [[NTT2020]](https://eprint.iacr.org/2020/1091.pdf) ([arXiv version](https://arxiv.org/pdf/2009.04987.pdf)) is assumed. ## Conventions -"$\mathrm{*}$" is a metavariable for the name of a protocol. We also use it as a wildcard in protocol names of a particular type, for example "$\mathrm{*}$bc" for the name of some best‑chain protocol. +“$\mathrm{*}$” is a metavariable for the name of a protocol. We also use it as a wildcard in protocol names of a particular type, for example “$\mathrm{*}$bc” for the name of some best‑chain protocol. -Protocols are referred to as $\Pi_{\mathrm{*}}$ for a name "$\mathrm{*}$". Where it is useful to avoid ambiguity, when referring to a concept defined by $\Pi_{\mathrm{*}}$ we prefix it with "$\mathrm{*}$‑". +Protocols are referred to as $\Pi_{\mathrm{*}}$ for a name “$\mathrm{*}$”. Where it is useful to avoid ambiguity, when referring to a concept defined by $\Pi_{\mathrm{*}}$ we prefix it with “$\mathrm{*}$‑”. We do not take synchrony or partial synchrony as an implicit assumption of the communication model; that is, *unless otherwise specified*, messages between protocol participants can be arbitrarily delayed or dropped. A given message is received at most once, and messages are nonmalleably authenticated as originating from a given sender whenever needed by the applicable protocol. Particular subprotocols may require a stronger model. -```admonish info +```admonish info "Background" For an overview of communication models used to analyse distributed protocols, see [this blog post by Ittai Abraham](https://decentralizedthoughts.github.io/2019-06-01-2019-5-31-models/). ``` -```admonish info collapsible=true title="Discussion of incorrect applications of the GST formalization of partial synchrony to continuously operating protocols. (You're doing it wrong!)" -The original context for the definition of the partially synchronous model in [[DLS1988]](https://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf) was for "one‑shot" Byzantine Agreement --- called "the consensus problem" in that paper. The following argument is used to justify assuming that all messages from the Global Stabilization Time onward are delivered within the upper time bound $\Delta$: +```admonish info collapsible=true title="Discussion of incorrect applications of the GST formalization of partial synchrony to continuously operating protocols. (You’re doing it wrong!)" +The original context for the definition of the partially synchronous model in [[DLS1988]](https://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf) was for “one‑shot” Byzantine Agreement — called “the consensus problem” in that paper. The following argument is used to justify assuming that all messages from the Global Stabilization Time onward are delivered within the upper time bound $\Delta$: > Therefore, we impose an additional constraint: For each execution there is a global stabilization time (GST), unknown to the processors, such that the message system respects the upper bound $\Delta$ from time GST onward. > > This constraint might at first seem too strong: In realistic situations, the upper bound cannot reasonably be expected to hold forever after GST, but perhaps only for a limited time. However, any good solution to the consensus problem in this model would have an upper bound $L$ on the amount of time after GST required for consensus to be reached; in this case it is not really necessary that the bound $\Delta$ hold forever after time GST, but only up to time GST $+\; L$. We find it technically convenient to avoid explicit mention of the interval length $L$ in the model, but will instead present the appropriate upper bounds on time for each of our algorithms. -Several subsequent authors applying the partially synchronous model to block chains appear to have forgotten this context. In particular, the argument depends on the protocol completing soon after GST. Obviously a block-chain protocol does not satisfy this assumption; it is not a "one‑shot" consensus problem. +Several subsequent authors applying the partially synchronous model to block chains appear to have forgotten this context. In particular, the argument depends on the protocol completing soon after GST. Obviously a block-chain protocol does not satisfy this assumption; it is not a “one‑shot” consensus problem. This assumption could be removed, but some authors of papers about block-chain protocols have taken it to be an essential aspect of modelling partial synchrony. I believe this is contrary to the intent of [[DLS1988]](https://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf): > Instead of requiring that the consensus problem be solvable in the GST model, we might think of separating the correctness conditions into safety and termination properties. The safety conditions are that no two correct processors should ever reach disagreement, and that no correct processor should ever make a decision that is contrary to the specified validity conditions. The termination property is just that each correct processor should eventually make a decision. Then we might require an algorithm to satisfy the safety conditions no matter how asynchronously the message system behaves, that is, even if $\Delta$ does not hold eventually. On the other hand, we might only require termination in case $\Delta$ holds eventually. It is easy to see that these safety and termination conditions are [for the consensus problem] equivalent to our GST condition: If an algorithm solves the consensus problem when $\Delta$ holds from time GST onward, then that algorithm cannot possibly violate a safety property even if the message system is completely asynchronous. This is because safety violations must occur at some finite point in time, and there would be some continuation of the violating execution in which $\Delta$ eventually holds. -This argument is correct as stated, i.e. for the one-shot consensus problem. Subtly, essentially the same argument can be adapted to protocols with *safety* properties that need to be satisfied continuously. However, it cannot correctly be applied to *liveness* properties of non-terminating protocols. The authors (Cynthia Dwork, Nancy Lynch, and Larry Stockmeyer) would certainly have known this: notice how they carefully distinguish "the GST model" from "partial synchrony". They cannot plausibly have intended this GST formalization to be applied unmodified to analyze liveness in such protocols, which seems to be common in the block-chain literature, including in the Ebb-and-Flow paper [[NTT2020]](https://eprint.iacr.org/2020/1091.pdf) and the Streamlet paper [[CS2020]](https://eprint.iacr.org/2020/088.pdf). (The latter does refer to "periods of synchrony" which indicates awareness of the issue, but then it uses the unmodified GST model in the proofs.) +This argument is correct as stated, i.e. for the one-shot consensus problem. Subtly, essentially the same argument can be adapted to protocols with *safety* properties that need to be satisfied continuously. However, it cannot correctly be applied to *liveness* properties of non-terminating protocols. The authors (Cynthia Dwork, Nancy Lynch, and Larry Stockmeyer) would certainly have known this: notice how they carefully distinguish “the GST model” from “partial synchrony”. They cannot plausibly have intended this GST formalization to be applied unmodified to analyze liveness in such protocols, which seems to be common in the block-chain literature, including in the Ebb-and-Flow paper [[NTT2020]](https://eprint.iacr.org/2020/1091.pdf) and the Streamlet paper [[CS2020]](https://eprint.iacr.org/2020/088.pdf). (The latter does refer to “periods of synchrony” which indicates awareness of the issue, but then it uses the unmodified GST model in the proofs.) This provides further motivation to avoid taking the GST formalization of partial synchrony as a basic assumption. ``` -${}$ + For simplicity, we assume that all events occur at global times in a total ordering. This assumption is not realistic in an asynchronous communication model, but it is not essential to the design or analysis and could be removed (essentially: replace times with events and use a partial happens-before ordering on events, in place of a total ordering on times). A $\mathrm{*}$‑execution is the complete set of events (message sends/receives and decisions by protocol participants) that occur in a particular run of $\Pi_{\mathrm{*}}$ from its initiation up to a given time. A prefix of a $\mathrm{*}$‑execution is also a $\mathrm{*}$‑execution. Since executions always start from protocol initiation, a strict suffix of a $\mathrm{*}$‑execution is not a $\mathrm{*}$‑execution. @@ -46,24 +46,24 @@ If $\mathsf{ch}$ is a $\mathrm{*}$‑chain,depth $k \in \mathbb{N}^+$ in a $\mathrm{*}$‑chain $\mathsf{ch}$ is defined to be the tip of $\mathsf{ch} \lceil_{\mathrm{*}}^k$. Thus the block at depth $k$ in a chain is the last one that cannot be affected by a rollback of length $k$. -```admonish info -Our usage of "depth" is different from [[NTT2020]](https://eprint.iacr.org/2020/1091.pdf), which uses "depth" to refer to what Bitcoin and Zcash call "height". It also differs by $1$ from the convention for confirmation depths in `zcashd`, where the tip is considered to be at depth $1$, rather than $0$. +```admonish info "Terminology note" +Our usage of “depth” is different from [[NTT2020]](https://eprint.iacr.org/2020/1091.pdf), which uses “depth” to refer to what Bitcoin and Zcash call “height”. It also differs by $1$ from the convention for confirmation depths in `zcashd`, where the tip is considered to be at depth $1$, rather than $0$. ``` For $\mathrm{*}$‑blocks $B$ and $C$, * the notation $B \preceq_{\mathrm{*}} C$ means that the $\mathrm{*}$‑chain with tip $B$ is a prefix of the one with tip $C$. This includes the case $B = C$. -* the notation $B \preceq\hspace{-0.5em}\succeq_{\mathrm{*}} C$ means that either $B \preceq_{\mathrm{*}} C$ or $C \preceq_{\mathrm{*}} B$. That is, "one of $B$ and $C$ is a prefix of the other". +* the notation $B \preceq\hspace{-0.5em}\succeq_{\mathrm{*}} C$ means that either $B \preceq_{\mathrm{*}} C$ or $C \preceq_{\mathrm{*}} B$. That is, “one of $B$ and $C$ is a prefix of the other”. -We also use $\mathsf{log} \preceq \mathsf{log}'$ (without a subscript on $\preceq$) to mean that the transaction ledger $\mathsf{log}$ is a prefix of $\mathsf{log}'$. Similarly to $\preceq\hspace{-0.5em}\succeq_{\mathrm{*}}$ above, $\mathsf{log} \preceq\hspace{-0.5em}\succeq \mathsf{log}'$ means that either $\mathsf{log} \preceq \mathsf{log}'$ or $\mathsf{log}' \preceq \mathsf{log}$; that is, "one of $\mathsf{log}$ and $\mathsf{log}'$ is a prefix of the other". +We also use $\mathsf{log} \preceq \mathsf{log}'$ (without a subscript on $\preceq$) to mean that the transaction ledger $\mathsf{log}$ is a prefix of $\mathsf{log}'$. Similarly to $\preceq\hspace{-0.5em}\succeq_{\mathrm{*}}$ above, $\mathsf{log} \preceq\hspace{-0.5em}\succeq \mathsf{log}'$ means that either $\mathsf{log} \preceq \mathsf{log}'$ or $\mathsf{log}' \preceq \mathsf{log}$; that is, “one of $\mathsf{log}$ and $\mathsf{log}'$ is a prefix of the other”. -The notation $[f(X) \text{ for } X \preceq_{\mathrm{*}} Y]$ means the sequence of $f(X)$ for each $\mathrm{*}$‑block $X$ in chain order from genesis up to and including $Y$. ($X$ is a bound variable within this construct.) +The notation $[f(X) \text{ for } X \preceq_{\mathrm{*}} Y]$ means the sequence of $f(X)$ for each $\mathrm{*}$‑block $X$ in chain order from genesis up to and including $Y\!$. ($X$ is a bound variable within this construct.) ## Subprotocols As in Snap‑and‑Chat, we depend on a BFT protocol $\Pi_{\mathrm{origbft}}$, and a best‑chain protocol $\Pi_{\mathrm{origbc}}$. ```admonish info -See [this terminology note](./the-arguments-for-bounded-dynamic-availability-and-finality-overrides.md#Terminology-note) for why we do not call $\Pi_{\mathrm{origbc}}$ a "longest‑chain" protocol. +See [this terminology note](./the-arguments-for-bounded-dynamic-availability-and-finality-overrides.md#terminology-note) for why we do not call $\Pi_{\mathrm{origbc}}$ a “longest‑chain” protocol. ``` We modify $\Pi_{\mathrm{origbft}}$ (resp. $\Pi_{\mathrm{origbc}}$) to give $\Pi_{\mathrm{bft}}$ (resp. $\Pi_{\mathrm{bc}}$) by adding structural elements, changing validity rules, and potentially changing the specified behaviour of honest nodes. @@ -72,50 +72,50 @@ A Crosslink node must participate in both $\Pi ### Model for BFT protocols (Π{origbft,bft}) -A player's view in $\Pi_{\mathrm{*bft}}$ includes a set of $\mathrm{*}$bft‑block chains each rooted at a fixed genesis $\mathrm{*}$bft‑block $\mathcal{O}_{\mathrm{*bft}}$. There is a $\mathrm{*}$bft‑block‑validity rule (specified below), which depends only on the content of the block and its ancestors. A non‑genesis block can only be $\mathrm{*}$bft‑block‑valid if its parent is $\mathrm{*}$bft‑block‑valid. A $\mathrm{*}$bft‑valid‑chain is a chain of $\mathrm{*}$bft‑block‑valid blocks. +A player’s view in $\Pi_{\mathrm{*bft}}$ includes a set of $\mathrm{*}$bft‑block chains each rooted at a fixed genesis $\mathrm{*}$bft‑block $\mathcal{O}_{\mathrm{*bft}}$. There is a $\mathrm{*}$bft‑block‑validity rule (specified below), which depends only on the content of the block and its ancestors. A non‑genesis block can only be $\mathrm{*}$bft‑block‑valid if its parent is $\mathrm{*}$bft‑block‑valid. A $\mathrm{*}$bft‑valid‑chain is a chain of $\mathrm{*}$bft‑block‑valid blocks. -A $\mathrm{*}$bft‑proposal refers to a parent $\mathrm{*}$bft‑block, and specifies an epoch. The content of a proposal is signed by the proposer using a strongly unforgeable signature scheme. We consider the proposal to include this signature. There is a $\mathrm{*}$bft‑proposal‑validity rule, depending only on the content of the proposal and its parent block, and the validity of the proposer's signature. +A $\mathrm{*}$bft‑proposal refers to a parent $\mathrm{*}$bft‑block, and specifies the proposal’s epoch. The content of a proposal is signed by the proposer using a strongly unforgeable signature scheme. We consider the proposal to include this signature. There is a $\mathrm{*}$bft‑proposal‑validity rule, depending only on the content of the proposal and its parent block, and the validity of the proposer’s signature. ```admonish info -We will shorten "$\mathrm{*}$bft‑block‑valid $\mathrm{*}$bft‑block" to "$\mathrm{*}$bft‑valid‑block", and "$\mathrm{*}$bft‑proposal‑valid $\mathrm{*}$bft‑proposal" to "$\mathrm{*}$bft‑valid‑proposal". +We will shorten “$\mathrm{*}$bft‑block‑valid $\mathrm{*}$bft‑block” to “$\mathrm{*}$bft‑valid‑block”, and “$\mathrm{*}$bft‑proposal‑valid $\mathrm{*}$bft‑proposal” to “$\mathrm{*}$bft‑valid‑proposal”. ``` For each epoch, there is a fixed number of voting units distributed between the players, which they use to vote for a $\mathrm{*}$bft‑proposal. We say that a voting unit has been cast for a $\mathrm{*}$bft‑proposal $P$ at a given time in a $\mathrm{*}$bft‑execution, if and only if $P$ is $\mathrm{*}$bft‑proposal‑valid and a ballot for $P$ authenticated by the holder of the voting unit exists at that time. If, and only if, the votes cast for a $\mathrm{*}$bft‑proposal $P$ satisfy a notarization rule at a given time in a $\mathrm{*}$bft‑execution, then it is possible to obtain a valid $\mathrm{*}$bft‑notarization‑proof $\mathsf{proof}_P$. The notarization rule must require at least a two‑thirds absolute supermajority of voting units in $P$'s epoch to have been cast for $P$. It may also require other conditions. -A voting unit is cast non‑honestly for an epoch's proposal iff: +A voting unit is cast non‑honestly for an epoch’s proposal iff: * it is cast other than by the holder of the unit (due to key compromise or any flaw in the voting protocol, for example); or * it is double‑cast (i.e. for distinct proposals); or * the holder of the unit following the conditions for honest voting in $\Pi_{\mathrm{*bft}}$, according to its view, should not have cast that vote. -```admonish success +```admonish success "Definition: One‑third bound on non‑honest voting" An execution of $\Pi_{\mathrm{bft}}$ has the **one‑third bound on non‑honest voting** property if at any epoch in the execution, *strictly* fewer than one third of the total voting units for that epoch are cast non‑honestly. ``` ```admonish info -It may be the case that a ballot marked for $P$ is not in honest view when it is used to create a notarisation proof for $P$. Since we are not assuming synchrony, it may also be the case that such a ballot is in honest view but that any given node has not received it (and perhaps will never receive it). +It may be the case that a ballot cast for $P$ is not in honest view when it is used to create a notarisation proof for $P$. Since we are not assuming synchrony, it may also be the case that such a ballot is in honest view but that any given node has not received it (and perhaps will never receive it). There may be multiple distinct ballots or distinct ballot messages attempting to cast a given voting unit for the same proposal; this is undesirable for bandwidth usage, but it is not necessary to consider it to be non‑honest behaviour for the purpose of security analysis, as long as such ballots are not double‑counted toward the two‑thirds threshold. ``` A $\mathrm{*}$bft‑block consists of $(P, \mathsf{proof}_P)$ re‑signed by the same proposer using a strongly unforgeable signature scheme. It is $\mathrm{*}$bft‑block‑valid iff: * $P$ is $\mathrm{*}$bft‑proposal‑valid; and -* $\mathsf{proof}_P$ is a valid proof that some subset of votes cast for $P$ are sufficient to satisfy the notarization rule; and -* the proposer's outer signature on $(P, \mathsf{proof}_P)$ is valid. +* $\mathsf{proof}_P$ is a valid proof that some subset of ballots cast for $P$ are sufficient to satisfy the notarization rule; and +* the proposer’s outer signature on $(P, \mathsf{proof}_P)$ is valid. -A $\mathrm{*}$bft‑proposal's parent reference hashes the entire parent $\mathrm{*}$bft‑block, i.e. proposal, proof, and outer signature. +A $\mathrm{*}$bft‑proposal’s parent reference hashes the entire parent $\mathrm{*}$bft‑block, i.e. proposal, proof, and outer signature. ```admonish info -Neither $\mathsf{proof}_P$ nor the proposer's outer signature is unique for a given $P$. The proposer's outer signature is however third‑party nonmalleable, by definition of a strongly unforgeable signature scheme. An "honest $\mathrm{*}$bft‑proposal" is a $\mathrm{*}$bft‑proposal made for a given epoch by a proposer who is honest in that epoch. Such a proposer will only create one proposal and only sign at most once for each epoch, and so there will be at most one "honestly submitted" $\mathrm{*}$bft‑block for each epoch. +Neither $\mathsf{proof}_P$ nor the proposer’s outer signature is unique for a given $P$. The proposer’s outer signature is however third‑party nonmalleable, by definition of a strongly unforgeable signature scheme. An “honest $\mathrm{*}$bft‑proposal” is a $\mathrm{*}$bft‑proposal made for a given epoch by a proposer who is honest in that epoch. Such a proposer will only create one proposal and only sign at most once for each epoch, and so there will be at most one “honestly submitted” $\mathrm{*}$bft‑block for each epoch. -It is possible for there to be multiple $\mathrm{*}$bft‑valid‑blocks for the same proposal, with different notarization proofs and/or outer signatures, if the proposer is not honest. However, the property that there will be at most one "honestly submitted" $\mathrm{*}$bft‑block for each epoch is important for liveness, even though we cannot guarantee that any particular proposer for an epoch is honest. ==TODO check that we are correctly using this in the liveness analysis.== +It is possible for there to be multiple $\mathrm{*}$bft‑valid‑blocks for the same proposal, with different notarization proofs and/or outer signatures, if the proposer is not honest. However, the property that there will be at most one “honestly submitted” $\mathrm{*}$bft‑block for each epoch is important for liveness, even though we cannot guarantee that any particular proposer for an epoch is honest. ==TODO check that we are correctly using this in the liveness analysis.== ``` -There is an efficiently computable function $\mathrm{*}\textsf{bft‑last‑final} :: \mathrm{*}\textsf{bft‑block} \to \mathrm{*}\textsf{bft‑block} \cup \{\bot\}$. For a $\mathrm{*}$bft‑block‑valid input block $C$, this function outputs the last ancestor of $C$ that is final in the context of $C.$ +There is an efficiently computable function $\mathrm{*}\textsf{bft‑last‑final} :: \mathrm{*}\textsf{bft‑block} \to \mathrm{*}\textsf{bft‑block} \cup \{\bot\}$. For a $\mathrm{*}$bft‑block‑valid input block $C$, this function outputs the last ancestor of $C$ that is final in the context of $C$. ```admonish info -The chain of ancestors is unambiguously determined because a $\mathrm{*}$bft‑proposal's parent reference hashes the entire parent $\mathrm{*}$bft‑block; each $\mathrm{*}$bft‑block commits to a proposal; and the parent hashes are collision-resistant. This holds despite the caveat mentioned above that there may be multiple $\mathrm{*}$bft‑valid‑blocks for the same proposal. +The chain of ancestors is unambiguously determined because a $\mathrm{*}$bft‑proposal’s parent reference hashes the entire parent $\mathrm{*}$bft‑block; each $\mathrm{*}$bft‑block commits to a proposal; and the parent hashes are collision-resistant. This holds despite the caveat mentioned above that there may be multiple $\mathrm{*}$bft‑valid‑blocks for the same proposal. ``` $\mathrm{*}\textsf{bft‑last‑final}$ must satisfy all of the following: @@ -127,53 +127,53 @@ The chain of ancestors is unambiguously determined because a $\mathrm{*}$bft‑valid-block $C$ unambiguously determines a $\mathrm{*}$bft‑valid-block $\mathrm{*}\textsf{bft-last-final}(C)$), but it is not correct to refer to a given $\mathrm{*}$bft‑block as objectively "$\mathrm{*}$bft‑final". +It is correct to talk about the “last final block” of a given chain (that is, each $\mathrm{*}$bft‑valid-block $C$ unambiguously determines a $\mathrm{*}$bft‑valid-block $\mathrm{*}\textsf{bft-last-final}(C)$), but it is not correct to refer to a given $\mathrm{*}$bft‑block as objectively “$\mathrm{*}$bft‑final”. ``` A particular BFT protocol might need adaptations to fit it into this model for $\Pi_{\mathrm{origbft}}$, *before* we apply the Crosslink modifications to obtain $\Pi_{\mathrm{bft}}$. Any such adaptions are necessarily protocol-specific. In particular, -* origbft‑proposal‑validity should correspond to the strongest property of an origbft‑proposal that is objectively and feasibly verifiable from the content of the proposal and its parent origbft‑block at the time the proposal is made. It must include verification of the proposer's signature. -* origbft‑block‑validity should correspond to the strongest property of an origbft‑block that is objectively and feasibly verifiable from the content of the block and its ancestors at the time the block is added to an origbft‑chain. It should typically include all of the relevant checks from origbft‑proposal‑validity that apply to the created block (or equivalent checks). It must also include verification of the notarization proof and the proposer's outer signature. -* If a node observes an origbft‑valid block $C$, then it should be infeasible for an adversary to cause a rollback in that node's view past $\textsf{origbft-last-final}(C)$, and the view of the chain up to $\textsf{origbft-last-final}(C)$ should agree with that of all other honest nodes. This is formalized in the next section. +* origbft‑proposal‑validity should correspond to the strongest property of an origbft‑proposal that is objectively and feasibly verifiable from the content of the proposal and its parent origbft‑block at the time the proposal is made. It must include verification of the proposer’s signature. +* origbft‑block‑validity should correspond to the strongest property of an origbft‑block that is objectively and feasibly verifiable from the content of the block and its ancestors at the time the block is added to an origbft‑chain. It should typically include all of the relevant checks from origbft‑proposal‑validity that apply to the created block (or equivalent checks). It must also include verification of the notarization proof and the proposer’s outer signature. +* If a node observes an origbft‑valid block $C$, then it should be infeasible for an adversary to cause a rollback in that node’s view past $\textsf{origbft-last-final}(C)$, and the view of the chain up to $\textsf{origbft-last-final}(C)$ should agree with that of all other honest nodes. This is formalized in the next section. #### Safety of $\Pi_{\mathrm{*bft}}$ The intuition behind the following safety property is that: -* For $\Pi_{\mathrm{*bft}}$ to be safe, it should never be the case that two honest nodes observe (at any time) $\mathrm{*}$bft‑blocks $B$ and $B'$ respectively that they each consider final in some context, but $B \preceq\hspace{-0.5em}\succeq_{\mathrm{*bft}} B'$ does not hold. +* For $\Pi_{\mathrm{*bft}}$ to be safe, it should never be the case that two honest nodes observe (at any time) $\mathrm{*}$bft‑blocks $B$ and $B'$ respectively that they each consider final in some context, but $B \preceq\hspace{-0.5em}\succeq_{\mathrm{*bft}} B'$ does not hold. * By definition, an honest node observes a $\mathrm{*}$bft‑block to be final in the context of another $\mathrm{*}$bft‑block $C$, iff $B \preceq_{\mathrm{*bft}} \mathrm{*}\textsf{bft-last-final}(C)$. -We say that a $\mathrm{*}$bft‑block is "in honest view" if a party observes it at some time at which that party is honest. +We say that a $\mathrm{*}$bft‑block is “in honest view” if a party observes it at some time at which that party is honest. -```admonish success -An execution of $\Pi_{\mathrm{*bft}}$ has **Final Agreement** iff for all $\mathrm{*}$bft‑valid blocks $C$ in honest view at time $t$ and $C'$ in honest view at time $t'$, we have $\mathrm{*}\textsf{bft-last-final}(C) \preceq\hspace{-0.5em}\succeq_{\mathrm{*bft}} \mathrm{*}\textsf{bft-last-final}(C')\,$. +```admonish success "Definition: Final Agreement" +An execution of $\Pi_{\mathrm{*bft}}$ has **Final Agreement** iff for all $\mathrm{*}$bft‑valid blocks $C$ in honest view at time $t$ and $C'$ in honest view at time $t'$, we have $\mathrm{*}\textsf{bft-last-final}(C) \preceq\hspace{-0.5em}\succeq_{\mathrm{*bft}} \mathrm{*}\textsf{bft-last-final}(C')$. ``` Note that it is possible for this property to hold for an execution of a BFT protocol in an asynchronous communication model. The following caveat applies: if the **one‑third bound on non‑honest voting** property is *ever* broken at any time in an execution, then it may not be possible to maintain **Final Agreement** from that point on. This is an area of possible improvement in the design and analysis, left for future work. ```admonish info collapsible=true title="Adapting the Streamlet BFT protocol." -Streamlet as described in [[CS2020]](https://eprint.iacr.org/2020/088.pdf) has three possible states of a block in a player's view: -* "valid" (but not notarized or final); -* "notarized" (but not final); -* "final". +Streamlet as described in [[CS2020]](https://eprint.iacr.org/2020/088.pdf) has three possible states of a block in a player’s view: +* “valid” (but not notarized or final); +* “notarized” (but not final); +* “final”. -By "valid" the Streamlet paper means just that it satisfies the structural property of being part of a block chain with parent hashes. The role of $\mathrm{*}$bft‑block‑validity in our model corresponds roughly to Streamlet's "notarized". It turns out that with some straightforward changes relative to Streamlet, we can identify "origbft‑block‑valid" with "notarized" and consider an origbft‑valid‑chain to only consist of notarized blocks. This is not obvious, but is a useful simplification. +By “valid” the Streamlet paper means just that it satisfies the structural property of being part of a block chain with parent hashes. The role of $\mathrm{*}$bft‑block‑validity in our model corresponds roughly to Streamlet’s “notarized”. It turns out that with some straightforward changes relative to Streamlet, we can identify “origbft‑block‑valid” with “notarized” and consider an origbft‑valid‑chain to only consist of notarized blocks. This is not obvious, but is a useful simplification. -Here is how the paper defines "notarized": +Here is how the paper defines “notarized”: > When a block gains votes from at least $2n/3$ distinct players, it becomes notarized. A chain is notarized if its constituent blocks are all notarized. This implies that blocks can be added to chains independently of notarization. However, the paper also says that a leader always proposes a block extending from a notarized chain. Therefore, only *notarized* chains really matter in the protocol. -In unmodified Streamlet, the order in which a player sees signatures might cause it to view blocks as notarized out of order. Streamlet's security analysis is in a synchronous model, and assumes for liveness that any vote will have been received by all players within two epochs. +In unmodified Streamlet, the order in which a player sees signatures might cause it to view blocks as notarized out of order. Streamlet’s security analysis is in a synchronous model, and assumes for liveness that any vote will have been received by all players within two epochs. In Crosslink, however, we need origbft‑block‑validity to be an objectively and feasibly verifiable property. We also would prefer reliable message delivery within bounded time not to be a basic assumption of our communication model. (This does not dictate what assumptions about message delivery are made for particular security analyses.) If we did not make a modification to the protocol to take this into account, then some Crosslink nodes might receive a two‑thirds absolute supermajority of voting messages and consider a BFT block to be notarized, while others might never receive enough of those messages. -Obviously a *proposal* cannot include signatures on itself --- but the block formed from it can include proofs about the proposal and signatures. We can therefore say that when a proposal gains a two‑thirds absolute supermajority of signatures, a block is created from it that contains a proof (such as an aggregate signature) that it had such a supermajority. For example, we can have the proposer itself make this proof once it has enough votes, sign the resulting $(P, \mathsf{proof}_P)$ to create a block, then *submit* that block in a separate message. (The proposer has most incentive to do this in order to gain whatever reward attaches to a successful proposal; it can outsource the proving task if needed.) Then the origbft‑block‑validity rule can require a valid supermajority proof, which is objectively and feasibly verifiable. Players that see an origbft‑block‑valid block can immediately consider it notarized. +Obviously a *proposal* cannot include signatures on itself — but the block formed from it can include proofs about the proposal and signatures. We can therefore say that when a proposal gains a two‑thirds absolute supermajority of signatures, a block is created from it that contains a proof (such as an aggregate signature) that it had such a supermajority. For example, we can have the proposer itself make this proof once it has enough votes, sign the resulting $(P, \mathsf{proof}_P)$ to create a block, then *submit* that block in a separate message. (The proposer has most incentive to do this in order to gain whatever reward attaches to a successful proposal; it can outsource the proving task if needed.) Then the origbft‑block‑validity rule can require a valid supermajority proof, which is objectively and feasibly verifiable. Players that see an origbft‑block‑valid block can immediately consider it notarized. Note that for the liveness analysis to be unaffected, we need to assume that the combined latency of messages, of collecting and aggregating signatures, and of block submission is such that all players will receive a notarized block corresponding to a given proposal (rather than just all of the votes for the proposal) within two epochs. Alternatively we could re‑do the timing analysis. -With this change, "origbft‑block‑valid" and "notarized" do not need to be distinguished. +With this change, “origbft‑block‑valid” and “notarized” do not need to be distinguished. -Streamlet's finality rule is: +Streamlet’s finality rule is: > If in any notarized chain, there are three adjacent blocks with consecutive epoch numbers, the prefix of the chain up to the second of the three blocks is considered final. When a block becomes final, all of its prefix must be final too. @@ -181,12 +181,12 @@ We can straightforwardly express this as an $\textsf{origbft-last-final}$ functi For an origbft‑valid block $C$, $\textsf{origbft-last-final}(C)$ is the last origbft‑valid block $B \preceq_{\mathrm{origbft}} C$ such that either $B = \mathcal{O}_{\mathrm{origbft}}$ or $B$ is the second block of a group of three adjacent blocks with consecutive epoch numbers. -Note that "When a block becomes final, all of its prefix must be final too." is implicit in the model. +Note that “When a block becomes final, all of its prefix must be final too.” is implicit in the model. ``` ### Model for best-chain protocols (Π{origbc,bc}) -A node's view in $\Pi_{\mathrm{*bc}}$ includes a set of $\mathrm{*}$bc‑block chains each rooted at a fixed genesis $\mathrm{*}$bc‑block $\mathcal{O}_{\mathrm{*bc}}$. There is a $\mathrm{*}$bc‑block‑validity rule (often described as a collection of "consensus rules"), depending only on the content of the block and its ancestors. A non‑genesis block can only be $\mathrm{*}$bc‑block‑valid if its parent is $\mathrm{*}$bc‑block‑valid. By "$\mathrm{*}$bc‑valid‑chain" we mean a chain of $\mathrm{*}$bc‑block‑valid blocks. +A node’s view in $\Pi_{\mathrm{*bc}}$ includes a set of $\mathrm{*}$bc‑block chains each rooted at a fixed genesis $\mathrm{*}$bc‑block $\mathcal{O}_{\mathrm{*bc}}$. There is a $\mathrm{*}$bc‑block‑validity rule (often described as a collection of “consensus rules”), depending only on the content of the block and its ancestors. A non‑genesis block can only be $\mathrm{*}$bc‑block‑valid if its parent is $\mathrm{*}$bc‑block‑valid. By “$\mathrm{*}$bc‑valid‑chain” we mean a chain of $\mathrm{*}$bc‑block‑valid blocks. The definition of $\mathrm{*}$bc‑block‑validity is such that it is hard for a block producer to extend a $\mathrm{*}$bc‑valid‑chain unless they are selected by a random process that chooses a block producer in proportion to their resources with an approximately known and consistent time distribution, subject to some assumption about the total proportion of resources held by honest nodes. @@ -198,11 +198,11 @@ The $\mathsf{score}$ function is required to satisfy $\mathsf{score}(\mathsf{ch} For a Proof‑of‑Work protocol, the score of a $\mathrm{*}$bc‑chain should be its accumulated work. ``` -Unless an adversary is able to censor knowledge of other chains from the node's view, it should be difficult to cause the node to switch to a chain with a last common ancestor more than $\sigma$ blocks back from the tip of their previous $\mathrm{*}$bc‑best‑chain. +Unless an adversary is able to censor knowledge of other chains from the node’s view, it should be difficult to cause the node to switch to a chain with a last common ancestor more than $\sigma$ blocks back from the tip of their previous $\mathrm{*}$bc‑best‑chain. -Following [[NTT2020]](https://eprint.iacr.org/2020/1091.pdf), we use the notation $\mathsf{ch}_i^t$ for node $i$'s $\mathrm{*}$bc‑best‑chain at time $t$. +Following [[NTT2020]](https://eprint.iacr.org/2020/1091.pdf), we use the notation $\mathsf{ch}_i^t$ for node $i$’s $\mathrm{*}$bc‑best‑chain at time $t$. -A $\mathrm{*}$bc‑context allows testing whether a given transaction is contextually valid ("$\mathrm{*}$bc‑context‑valid"), and adding it to the context if it is. Given a context $\mathsf{ctx}$, the resulting sequence of contextually valid transactions since genesis can be obtained as $\textsf{context-txns}(\mathsf{ctx})$. It is possible to obtain a $\mathrm{*}$bc‑context corresponding to the state after the genesis $\mathrm{*}$bc‑block. +A $\mathrm{*}$bc‑context allows testing whether a given transaction is contextually valid (“$\mathrm{*}$bc‑context‑valid”), and adding it to the context if it is. Given a context $\mathsf{ctx}$, the resulting sequence of contextually valid transactions since genesis can be obtained as $\textsf{context-txns}(\mathsf{ctx})$. It is possible to obtain a $\mathrm{*}$bc‑context corresponding to the state after the genesis $\mathrm{*}$bc‑block. We assume that the only reasons for a transaction to be contextually invalid are that it double‑spends, or that an input is missing. @@ -220,10 +220,10 @@ Given that the only reasons for a transaction to be contextually invalid are dou It might be possible to relax this assumption, but it would require additional analysis to ensure that the above equivalence still holds. ``` -${}$ + A $\mathrm{*}$bc‑block logically contains a sequence of transactions. In addition to other rules, a block is only $\mathrm{*}$bc‑block‑valid if its transactions, taken in order, are all $\mathrm{*}$bc‑context‑valid given previous blocks and previous transactions in the block. -```admonish info collapsible=true title="Detail of 'logically contains' for Zcash." +```admonish info collapsible=true title="Detail of ‘logically contains’ for Zcash." In Zcash, a block logically contains its transactions by having the block header commit to a Merkle tree over txids, and another Merkle tree (in the same transaction order) over witness hashes. A txid and witness hash together authenticate all data fields of a transaction. For v5 transactions, the txid commits to effecting data (that determines the effect of the transaction) and the witness hash commits to witness data (signatures and proofs). For earlier transaction versions, the witness hash is null and the txid commits to all transaction data. @@ -242,7 +242,7 @@ In addition, a coinbase transaction is implicitly able to spend the total amount [Block consensus rule](https://zips.z.cash/protocol/protocol.pdf#blockheader): * The first transaction in a block MUST be a coinbase transaction, and subsequent transactions MUST NOT be coinbase transactions. -[Payment of Founders' Reward](https://zips.z.cash/protocol/protocol.pdf#foundersreward): +[Payment of Founders’ Reward](https://zips.z.cash/protocol/protocol.pdf#foundersreward): * [Pre‑Canopy] A coinbase transaction at $\mathsf{height} \in \{1..\mathsf{FoundersRewardLastBlockHeight}\}$ MUST include at least one output that pays exactly $\mathsf{FoundersReward}(\mathsf{height})$ zatoshi with [details of script omitted]. [Payment of Funding Streams](https://zips.z.cash/protocol/protocol.pdf#fundingstreams): @@ -257,33 +257,33 @@ To achieve the intent, it is sufficient to change this rule to only allow coinba If we assume that coinbase block subsidies and fees, and the position of coinbase transactions as the first transaction in each block have already been checked as $\mathrm{*}$bc‑block‑validity rules, then the model is sufficient. ``` -${}$ -A "coinbase transaction" is a $\mathrm{*}$bc‑transaction that only distributes newly issued funds and has no inputs. + +A “coinbase transaction” is a $\mathrm{*}$bc‑transaction that only distributes newly issued funds and has no inputs. Define $\textsf{is-coinbase-only-block} :: \mathrm{*}\textsf{bc-block} \to \mathsf{boolean}$ so that $\textsf{is-coinbase-only-block}(B) = \mathsf{true}$ iff $B$ has exactly one transaction that is a coinbase transaction. Each $\mathrm{*}$bc‑block is summarized by a $\mathrm{*}$bc‑header that commits to the block. There is a notion of $\mathrm{*}$bc‑header‑validity that is necessary, but not sufficient, for validity of the block. We will only make the distinction between $\mathrm{*}$bc‑headers and $\mathrm{*}$bc‑blocks when it is necessary to avoid ambiguity. ```admonish info collapsible=true title="Header validity for Proof‑of‑Work protocols." -In a Proof‑of‑Work protocol, it is normally possible to check the Proof‑of‑Work of a block using only the header. There is a difficulty adjustment function that determines the target difficulty for a block based on its parent chain. So, checking that the correct difficulty target has been used relies on knowing that the header's parent chain is valid. +In a Proof‑of‑Work protocol, it is normally possible to check the Proof‑of‑Work of a block using only the header. There is a difficulty adjustment function that determines the target difficulty for a block based on its parent chain. So, checking that the correct difficulty target has been used relies on knowing that the header’s parent chain is valid. Checking header validity before expending further resources on a purported block can be relevant to mitigating denial‑of‑service attacks that attempt to inflate validation cost. ``` -${}$ + Typically, Bitcoin‑derived best chain protocols do not need much adaptation to fit into this model. The model still omits some details that would be important to implementing Crosslink, but distracting for this level of abstraction. #### Safety of $\Pi_{\mathrm{*bc}}$ -We make an assumption on executions of $\Pi_{\mathrm{origbc}}$ that we will call **Prefix Consistency** (introduced in [[PSS2016](https://eprint.iacr.org/2016/454.pdf), section 3.3] as just "consistency"): +We make an assumption on executions of $\Pi_{\mathrm{origbc}}$ that we will call **Prefix Consistency** (introduced in [[PSS2016](https://eprint.iacr.org/2016/454.pdf), section 3.3] as just “consistency”): -```admonish success +```admonish success "Definition: Prefix Consistency" An execution of $\Pi_{\mathrm{*bc}}$ has **Prefix Consistency** at confirmation depth $\sigma$, iff for all times $t \leq t'$ and all nodes $i$, $j$ (potentially the same) such that $i$ is honest at time $t$ and $j$ is honest at time $t'$, we have that $\mathsf{ch}_i^t \lceil_{\!\mathrm{*bc}}^\sigma\, \preceq_{\mathrm{*bc}} \mathsf{ch}_j^{t'}$. ``` ```admonish info collapsible=true title="Explain the confusion in the literature about what variants of this property are called." -The literature uses the same name, "common‑prefix property", for two different properties of very different strength. +The literature uses the same name, “common‑prefix property”, for two different properties of very different strength. -[[PSS2016](https://eprint.iacr.org/2016/454.pdf), section 3.3] introduced the stronger variant. That paper first describes the weaker variant, calling it the "common‑prefix property by Garay et al [[GKL2015]](https://link.springer.com/chapter/10.1007/978-3-662-46803-6_10)." Then it explains what is essentially a bug in that variant, and describes the stronger variant which it just calls "consistency": +[[PSS2016](https://eprint.iacr.org/2016/454.pdf), section 3.3] introduced the stronger variant. That paper first describes the weaker variant, calling it the “common‑prefix property by Garay et al [[GKL2015]](https://link.springer.com/chapter/10.1007/978-3-662-46803-6_10).” Then it explains what is essentially a bug in that variant, and describes the stronger variant which it just calls “consistency”: > The common‑prefix property by Garay et al [[GKL2015]](https://link.springer.com/chapter/10.1007/978-3-662-46803-6_10), which was already considered and studied by Nakamoto [[Nakamoto2008]](https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.221.9986), requires that in any round $r$, the record chains of any two honest players $i$, $j$ agree on all, but potentially the last $T$, records. We note that this property (even in combination with the other two desiderata [of Chain Growth and Chain Quality]) provides quite weak guarantees: even if any two honest parties perfectly agree on the chains, the chain could be completely different on, say, even rounds and odd rounds. We here consider a stronger notion of consistency which additionally stipulates players should be consistent with their “future selves”. > @@ -291,7 +291,7 @@ The literature uses the same name, "common‑p Unfortunately, [[GKL2020]](https://eprint.iacr.org/2014/765.pdf), which is a revised version of [[GKL2015]](https://link.springer.com/chapter/10.1007/978-3-662-46803-6_10), switches to the stronger variant without changing the name. (The [eprint version history](https://eprint.iacr.org/archive/versions/2014/765) may be useful; the change was made in [version 20181013:200033](https://eprint.iacr.org/archive/2014/765/20181013:200033), page 17.) -Note that [GKL2020] uses an adaptive‑corruption model, "meaning that the adversary is allowed to take control of parties on the fly", and so their wording in Definition 3: +Note that [GKL2020] uses an adaptive‑corruption model, “meaning that the adversary is allowed to take control of parties on the fly”, and so their wording in Definition 3: > ... for any pair of honest players $P_1$, $P_2$ adopting the chains $\mathcal{C}_1$, $\mathcal{C}_2$ at rounds $r_1 \leq r_2$ in view$^{t,n}_{\Pi,\mathcal{A},\mathcal{Z}}$ respectively, it holds that $\mathcal{C}_1^{\lceil k} \preceq \mathcal{C}_2$. is intended to mean the same as our @@ -300,33 +300,33 @@ is intended to mean the same as our (The latter is closer to [[PSS2016]](https://eprint.iacr.org/2016/454.pdf).) -Incidentally, I cannot find any variant of this property in [[Nakamoto2008]](https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.221.9986). Maybe implicitly, but it's a stretch. +Incidentally, I cannot find any variant of this property in [[Nakamoto2008]](https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.221.9986). Maybe implicitly, but it’s a stretch. ``` -```admonish info collapsible=true title="Discussion of [GKL2020]'s communication model and network partition." -**Prefix Consistency** implies that, in the relevant executions, the network of honest nodes is never partitioned --- unless (roughly speaking) any partition lasts only for a short length of time relative to $\sigma$ block times. If node $i$ is on one side of a full partition and node $j$ on the other, then after node $i$'s best chain has been extended by more than $\sigma$ blocks, $\mathsf{ch}_i^t \lceil_{\!\mathrm{*bc}}^\sigma$ will contain information that has no way to get to node $j$. And even if the partition is incomplete, we cannot guarantee that the Prefix Consistency property will hold for any given pair of nodes. +```admonish info collapsible=true title="Discussion of [GKL2020]’s communication model and network partition." +**Prefix Consistency** implies that, in the relevant executions, the network of honest nodes is never partitioned — unless (roughly speaking) any partition lasts only for a short length of time relative to $\sigma$ block times. If node $i$ is on one side of a full partition and node $j$ on the other, then after node $i$’s best chain has been extended by more than $\sigma$ blocks, $\mathsf{ch}_i^t \lceil_{\!\mathrm{*bc}}^\sigma$ will contain information that has no way to get to node $j$. And even if the partition is incomplete, we cannot guarantee that the Prefix Consistency property will hold for any given pair of nodes. And yet, [[GKL2020]](https://eprint.iacr.org/2014/765.pdf) claims to *prove* this property from other assumptions. So we know that those assumptions must also rule out a long partition between honest nodes. In fact the required assumption is implicit in the communication model: * A synchronous network cannot be partitioned. -* A partially synchronous network ---that is, providing reliable delivery with bounded but unknown delay--- cannot be partitioned for longer than the delay. +* A partially synchronous network —that is, providing reliable delivery with bounded but unknown delay— cannot be partitioned for longer than the delay. We might be concerned that these implicit assumptions are stronger than we would like. In practice, the peer‑to‑peer network protocol of Bitcoin and Zcash attempts to flood blocks to all nodes. This protocol might have weaknesses, but it is not intended to (and plausibly does not) depend on all messages being received. (Incidentally, Streamlet also implicitly floods messages to all nodes.) Also, Streamlet and many other BFT protocols do *not* assume *for safety* that the network is not partitioned. That is, BFT protocols can be safe in a fully asynchronous communication model with unreliable messaging. That is why we avoid taking synchrony or partial synchrony as an implicit assumption of the communication model, or else we could end up with a protocol with weaker safety properties than $\Pi_{\mathrm{origbft}}$ alone. -This leaves the question of whether the **Prefix Consistency** property is still too strong, even if we do not rely on it for the analysis of safety when $\Pi_{\mathrm{bft}}$ has not been subverted. In particular, if a particular node $h$ is not well-connected to the rest of the network, then that will inevitably affect node $h$'s security, but should not affect other honest nodes' security. +This leaves the question of whether the **Prefix Consistency** property is still too strong, even if we do not rely on it for the analysis of safety when $\Pi_{\mathrm{bft}}$ has not been subverted. In particular, if a particular node $h$ is not well-connected to the rest of the network, then that will inevitably affect node $h$’s security, but should not affect other honest nodes’ security. -Fortunately, it is not the case that disconnecting a single node $h$ from the network causes the security assumption to be voided. The solution is to view $h$ as not honest in that case (even though it would follow the protocol if it could). This achieves the desired effect within the model, because other nodes can no longer rely on $h$'s honest input. Although viewing $h$ as potentially adversarial might seem conservative from the point of view of other nodes, bear in mind that an adversary could censor an arbitrary subset of incoming and outgoing messages from the node, and this may be best modelled by considering it to be effectively controlled by the adversary. +Fortunately, it is not the case that disconnecting a single node $h$ from the network causes the security assumption to be voided. The solution is to view $h$ as not honest in that case (even though it would follow the protocol if it could). This achieves the desired effect within the model, because other nodes can no longer rely on $h$’s honest input. Although viewing $h$ as potentially adversarial might seem conservative from the point of view of other nodes, bear in mind that an adversary could censor an arbitrary subset of incoming and outgoing messages from the node, and this may be best modelled by considering it to be effectively controlled by the adversary. ``` -${}$ -Prefix Consistency compares the $\sigma$-truncated chain of some node $i$ with the *untruncated* chain of node $j$. For our analysis of safety of the derived ledgers, we will also need to make an assumption on executions of $\Pi_{\mathrm{origbc}}$ that at any given time $t$, any two honest nodes $i$ and $j$ **agree** on their confirmed prefixes --- with only the caveat that one may have observed more of the chain than the other. That is: -```admonish success +Prefix Consistency compares the $\sigma$-truncated chain of some node $i$ with the *untruncated* chain of node $j$. For our analysis of safety of the derived ledgers, we will also need to make an assumption on executions of $\Pi_{\mathrm{origbc}}$ that at any given time $t$, any two honest nodes $i$ and $j$ **agree** on their confirmed prefixes — with only the caveat that one may have observed more of the chain than the other. That is: + +```admonish success "Definition: Prefix Agreement" An execution of $\Pi_{\mathrm{*bc}}$ has **Prefix Agreement** at confirmation depth $\sigma$, iff for all times $t$, $t'$ and all nodes $i$, $j$ (potentially the same) such that $i$ is honest at time $t$ and $j$ is honest at time $t'$, we have $\mathsf{ch}_i^t \lceil_{\!\mathrm{*bc}}^\sigma\, \preceq\hspace{-0.5em}\succeq_{\mathrm{*bc}} \mathsf{ch}_j^{t'} \lceil_{\!\mathrm{*bc}}^\sigma$. ``` ```admonish info collapsible=true title="Why are this property, and Prefix Consistency above, stated as unconditional properties of protocol *executions*, rather than as probabilistic assumptions?" -Our security arguments that depend on these properties will all be of the form "in an execution where (safety properties) are not violated, (undesirable thing) cannot happen". +Our security arguments that depend on these properties will all be of the form “in an execution where (safety properties) are not violated, (undesirable thing) cannot happen”. It is not necessary to involve probability in arguments of this form. Any probabilistic reasoning can be done separately. @@ -342,10 +342,10 @@ The conclusions that can be obtained from this approach are necessarily probabil (Here $p$ is the probability that any given node gets to produce a block in any given time slot.) -In fact none of the proofs of security properties for Snap‑and‑Chat depend on the particular expression $e^{-\Omega(\sqrt{\sigma})}$; for example in the proofs of Lemma 5 and Theorem 1, this probability just "passes through" the proof from the premisses to the conclusion, because the argument is not probabilistic. The same will be true of our safety arguments. +In fact none of the proofs of security properties for Snap‑and‑Chat depend on the particular expression $e^{-\Omega(\sqrt{\sigma})}$; for example in the proofs of Lemma 5 and Theorem 1, this probability just “passes through” the proof from the premisses to the conclusion, because the argument is not probabilistic. The same will be true of our safety arguments. Talking about what is possible in particular executions has further advantages: -* It sidesteps the issue of how to interpret results in the partially synchronous model, when we do not know what *C*$(\max(\mathsf{GST}, \mathsf{GAT}))$ is. See also the critique of applying the partially synchronous model to block-chain protocols under "Discussion of [GKL2020]'s communication model and network partition" above. +* It sidesteps the issue of how to interpret results in the partially synchronous model, when we do not know what *C*$(\max(\mathsf{GST}, \mathsf{GAT}))$ is. See also the critique of applying the partially synchronous model to block-chain protocols under [“Discussion of [GKL2020]’s communication model and network partition”](#admonition-discussion-of-gkl2020s-communication-model-and-network-partition) above. * We do not require $\Pi_{\mathrm{bc}}$ to be a Nakamoto‑style Proof‑of‑Work block chain protocol. Some other kind of protocol could potentially satisfy Prefix Consistency and Prefix Agreement. * It is not clear whether a $e^{-\Omega(\sqrt{\sigma})}$ probability of failure would be concretely adequate. That would depend on the value of $\sigma$ and the constant hidden by the $\Omega$ notation. The asymptotic property using $\Omega$ tells us whether a sufficiently large $\sigma$ *could* be chosen, but we are more interested in what needs to be assumed for a given concrete choice of $\sigma$. * If a violation of a required safety property occurs *in a given execution*, then the safety argument for Crosslink that depended on the property fails for that execution, regardless of what the probability of that occurrence was. This approach therefore more precisely models the consequences of such violations. @@ -376,15 +376,15 @@ Let $\mathsf{LOG}_{\mathrm{fin},i}^t :: [\textsf{bc-transaction}]$ be the finali The following definition is rough and only intended to provide intuition. -Consider, at a point in time $t$, the number of bc‑blocks of transactions that have entered $\mathsf{LOG}_{\mathrm{bda},i,0}^t$ but have not (yet) entered $\mathsf{LOG}_{\mathrm{fin},i}^t$. We call this the "finality gap" at time $t$. Under an assumption about the distribution of bc‑block intervals, if this gap stays roughly constant then it corresponds to the approximate time that transactions added to $\mathsf{LOG}_{\mathrm{bda},i,0}$ have taken to enter $\mathsf{LOG}_{\mathrm{fin},i}$ (if they do so at all) just prior to time $t$. +Consider, at a point in time $t$, the number of bc‑blocks of transactions that have entered $\mathsf{LOG}_{\mathrm{bda},i,0}^t$ but have not (yet) entered $\mathsf{LOG}_{\mathrm{fin},i}^t$. We call this the “finality gap” at time $t$. Under an assumption about the distribution of bc‑block intervals, if this gap stays roughly constant then it corresponds to the approximate time that transactions added to $\mathsf{LOG}_{\mathrm{bda},i,0}$ have taken to enter $\mathsf{LOG}_{\mathrm{fin},i}$ (if they do so at all) just prior to time $t$. As explained in detail by [The Arguments for Bounded Dynamic Availability and Finality Overrides](./the-arguments-for-bounded-dynamic-availability-and-finality-overrides.md), if this bound exceeds a reasonable threshold then it likely signals an exceptional or emergency condition, in which it is undesirable to keep accepting user transactions that spend funds into $\mathsf{LOG}_{\mathrm{bda},i,0}$. -The condition that the network enters in such cases will be called "Safety Mode". For a given higher‑level transaction protocol, we can define a policy for which bc‑blocks will be accepted in Safety Mode. This will be modelled by a predicate $\textsf{is-safety-block} :: \textsf{bc-block} \to \mathsf{boolean}$. A bc‑block for which $\textsf{is-safety-block}$ returns $\mathsf{true}$ is called a "safety block". +The condition that the network enters in such cases will be called “Safety Mode”. For a given higher‑level transaction protocol, we can define a policy for which bc‑blocks will be accepted in Safety Mode. This will be modelled by a predicate $\textsf{is-safety-block} :: \textsf{bc-block} \to \mathsf{boolean}$. A bc‑block for which $\textsf{is-safety-block}$ returns $\mathsf{true}$ is called a “safety block”. Note that a bc‑block producer is only constrained to produce safety blocks while, roughly speaking, its view of the finalization point remains stalled. In particular an adversary that has subverted the BFT protocol in a way that does *not* keep it in a stalled state can always avoid being constrained by Safety Mode. -The desired properties of safety blocks and a possible Safety Mode policy for Zcash are discussed in the [How to block hazards](./the-arguments-for-bounded-dynamic-availability-and-finality-overrides.md#How-to-block-hazards) section of [The Arguments for Bounded Dynamic Availability and Finality Overrides](./the-arguments-for-bounded-dynamic-availability-and-finality-overrides.md). +The desired properties of safety blocks and a possible Safety Mode policy for Zcash are discussed in the [How to block hazards](./the-arguments-for-bounded-dynamic-availability-and-finality-overrides.md#how-to-block-hazards) section of [The Arguments for Bounded Dynamic Availability and Finality Overrides](./the-arguments-for-bounded-dynamic-availability-and-finality-overrides.md). ## Parameters @@ -392,7 +392,7 @@ Crosslink is parameterized by a bc‑confirmat Each node $i$ always uses the fixed confirmation depth $\sigma$ to obtain its view of the finalized ledger $\mathsf{LOG}_{\mathsf{fin},i} :: [\textsf{bc-transaction}]$. -Each node $i$ chooses a potentially different bc‑confirmation‑depth $\mu \in \mathbb{N}$ to obtain its view of the bounded‑dynamically‑available ledger $\mathsf{LOG}_{\mathsf{bda},i,\mu} :: [\textsf{bc-transaction}]$. We will assume that $\mu \leq \sigma$, since there is no reason to choose $\mu > \sigma$. Choosing $\mu \lt \sigma$ is at the node's own risk and may increase the risk of rollback attacks against $\mathsf{LOG}_{\mathsf{bda},i,\mu}$ (it does not affect $\mathsf{LOG}_{\mathsf{fin},i}$). The default should be $\mu = \sigma$. +Each node $i$ chooses a potentially different bc‑confirmation‑depth $\mu \in \mathbb{N}$ to obtain its view of the bounded‑dynamically‑available ledger $\mathsf{LOG}_{\mathsf{bda},i,\mu} :: [\textsf{bc-transaction}]$. We will assume that $\mu \leq \sigma$, since there is no reason to choose $\mu > \sigma$. Choosing $\mu \lt \sigma$ is at the node’s own risk and may increase the risk of rollback attacks against $\mathsf{LOG}_{\mathsf{bda},i,\mu}$ (it does not affect $\mathsf{LOG}_{\mathsf{fin},i}$). The default should be $\mu = \sigma$. ```admonish info The definition of $\mathsf{LOG}_{\mathsf{bda},i,\mu}$ is also used internally to the protocol with $\mu = 0$. @@ -413,19 +413,19 @@ For a bft‑block or bft‑proposal $B$, define $$ $$ ```admonish info collapsible=true title="Use of the headers_bc field, and its relation to the ch field in Snap‑and‑Chat." -For a bft‑proposal or bft‑block $B$, the role of the bc‑chain snapshot referenced by $B\mathsf{.headers\_bc}[0] \lceil_{\mathrm{bc}}^1$ is comparable to the $\Pi_{\mathrm{lc}}$ snapshot referenced by $B\mathsf{.ch}$ in the Snap‑and‑Chat construction from [[NTT2020]](https://eprint.iacr.org/2020/1091.pdf). The motivation for the additional headers is to demonstrate, to any party that sees a bft‑proposal (resp. bft‑block), that the snapshot had been confirmed when the proposal (resp. the block's proposal) was made. +For a bft‑proposal or bft‑block $B$, the role of the bc‑chain snapshot referenced by $B\mathsf{.headers\_bc}[0] \lceil_{\mathrm{bc}}^1$ is comparable to the $\Pi_{\mathrm{lc}}$ snapshot referenced by $B\mathsf{.ch}$ in the Snap‑and‑Chat construction from [[NTT2020]](https://eprint.iacr.org/2020/1091.pdf). The motivation for the additional headers is to demonstrate, to any party that sees a bft‑proposal (resp. bft‑block), that the snapshot had been confirmed when the proposal (resp. the block’s proposal) was made. -Typically, a node that is validating an honest bft‑proposal or bft‑block will have seen at least the snapshotted bc‑block (and possibly some of the subsequent bc‑blocks in the $\mathsf{header\_bc}$ chain) before. For this not to be the case, the validator's bc‑best‑chain would have to be more than $\sigma$ bc‑blocks behind the honest proposer's bc‑best‑chain at a given time, which would violate the **Prefix Consistency** property of $\Pi_{\mathrm{bc}}$. +Typically, a node that is validating an honest bft‑proposal or bft‑block will have seen at least the snapshotted bc‑block (and possibly some of the subsequent bc‑blocks in the $\mathsf{header\_bc}$ chain) before. For this not to be the case, the validator’s bc‑best‑chain would have to be more than $\sigma$ bc‑blocks behind the honest proposer’s bc‑best‑chain at a given time, which would violate the **Prefix Consistency** property of $\Pi_{\mathrm{bc}}$. If the headers do not connect to any bc‑valid‑chain known to the validator, then the validator should be suspicious that the proposer might not be honest. It can assign a lower priority to validating the proposal in this case, or simply drop it. The latter option could drop a valid proposal, but this does not in practice cause a problem as long as a sufficient number of validators are properly synced (so that **Prefix Consistency** holds for them). -If the headers *do* connect to a known bc‑valid‑chain, it could still be the case that the whole header chain up to and including $B\mathsf{.headers\_bc}[\sigma-1]$ is not a bc‑valid‑chain. Therefore, to limit denial‑of‑service attacks the validator should first check the Proofs‑of‑Work and difficulty adjustment ---which it can do locally using only the headers--- before attempting to download and validate any bc‑blocks that it has not already seen. This is why we include the full headers rather than just the block hashes. +If the headers *do* connect to a known bc‑valid‑chain, it could still be the case that the whole header chain up to and including $B\mathsf{.headers\_bc}[\sigma-1]$ is not a bc‑valid‑chain. Therefore, to limit denial‑of‑service attacks the validator should first check the Proofs‑of‑Work and difficulty adjustment —which it can do locally using only the headers— before attempting to download and validate any bc‑blocks that it has not already seen. This is why we include the full headers rather than just the block hashes. ``` ```admonish info collapsible=true title="Why is a distinguished value needed for the headers_bc field in the genesis bft‑block?" -It would be conceptually nice for $\mathcal{O}_{\mathrm{bft}}\mathsf{.headers}[0] \lceil_{\mathrm{bc}}^1$ to refer to $\mathcal{O}_{\mathrm{bc}}$, as well as $\mathcal{O}_{\mathrm{bc}}\mathsf{.context\_bft}$ being $\mathcal{O}_{\mathrm{bft}}$ so that $\textsf{bft-last-final}(\mathcal{O}_{\mathrm{bc}}\mathsf{.context\_bft}) = \mathcal{O}_{\mathrm{bft}}$. That reflects the fact that we know "from the start" that neither genesis block can be rolled back. +It would be conceptually nice for $\mathcal{O}_{\mathrm{bft}}\mathsf{.headers}[0] \lceil_{\mathrm{bc}}^1$ to refer to $\mathcal{O}_{\mathrm{bc}}$, as well as $\mathcal{O}_{\mathrm{bc}}\mathsf{.context\_bft}$ being $\mathcal{O}_{\mathrm{bft}}$ so that $\textsf{bft-last-final}(\mathcal{O}_{\mathrm{bc}}\mathsf{.context\_bft}) = \mathcal{O}_{\mathrm{bft}}$. That reflects the fact that we know “from the start” that neither genesis block can be rolled back. -This is not literally implementable using block hashes because it would involve a hash cycle, but we achieve the same effect by defining a $\mathsf{snapshot}$ function that allows us to "patch" $\mathsf{snapshot}(\mathcal{O}_{\mathrm{bft}})$ to be $\mathcal{O}_{\mathrm{bc}}$. We do it this way around rather than "patching" the link from a bc‑block to a bft‑block, because the genesis bft‑block already needs a special case since there are not $\sigma$ bc‑headers available. +This is not literally implementable using block hashes because it would involve a hash cycle, but we achieve the same effect by defining a $\mathsf{snapshot}$ function that allows us to “patch” $\mathsf{snapshot}(\mathcal{O}_{\mathrm{bft}})$ to be $\mathcal{O}_{\mathrm{bc}}$. We do it this way around rather than “patching” the link from a bc‑block to a bft‑block, because the genesis bft‑block already needs a special case since there are not $\sigma$ bc‑headers available. ``` ```admonish info collapsible=true title="Why is the context_bft field needed? Why not use a final_bft field to refer directly to the last final bft‑block before the context block?" @@ -446,29 +446,29 @@ A bft‑proposal (resp. non‑genesis bft‑block) $B$ is bft‑proposal‑valid * **Increasing Score rule:** Either $\mathsf{score}(\mathsf{snapshot}(B \lceil_{\mathrm{bft}}^1)) \lt \mathsf{score}(\mathsf{snapshot}(B))$ or $\mathsf{snapshot}(B \lceil_{\mathrm{bft}}^1) = \mathsf{snapshot}(B)$. * **Tail Confirmation rule:** $B\mathsf{.headers\_bc}$ form the $\sigma$‑block tail of a bc‑valid‑chain. -The "corresponding validity rules" are assumed to include the **Parent rule** that $B$'s parent is bft‑valid. +The “corresponding validity rules” are assumed to include the **Parent rule** that $B$’s parent is bft‑valid. -Note: origbft‑block‑validity rules may be different to origbft‑proposal‑validity rules. For example, in adapted Streamlet, a origbft‑block needs evidence that it was voted for by a supermajority, and an origbft‑proposal doesn't. Such differences also apply to bft‑block‑validity vs bft‑proposal‑validity. +Note: origbft‑block‑validity rules may be different to origbft‑proposal‑validity rules. For example, in adapted Streamlet, a origbft‑block needs evidence that it was voted for by a supermajority, and an origbft‑proposal doesn’t. Such differences also apply to bft‑block‑validity vs bft‑proposal‑validity. ```admonish info collapsible=true title="What about making the bc‑block producer the bft‑proposer?" If this were enforced, it could be an alternative way of ensuring that every bft‑proposal snapshots a new bc‑block with a higher score than previous snapshots, potentially making the **Increasing Score rule** redundant. However, it would require merging bc‑block producers and bft‑proposers, which could have concerning knock‑on effects (such as concentrating security into fewer participants). -For a contrary view, see [What about making the bc‑block producer the bft‑proposer?](./potential-changes.md#What-about-making-the-bc-block-producer-the-bft-proposer) in [Potential changes to Crosslink](./potential-changes.md). +For a contrary view, see [What about making the bc‑block‑producer the bft‑proposer?](./potential-changes.md#what-about-making-the-bcblockproducer-the-bftproposer) in [Potential changes to Crosslink](./potential-changes.md). ``` ```admonish info collapsible=true title="Why have validity rules been separated from the honest voting condition below?" -The reason to separate the validity rules from the honest voting condition, is that the validity rules are objective: they don't depend on an observer's view of the bc‑best‑chain. Therefore, they can be checked independently of validator signatures. Even a proposal voted for by 100% of validators will not be considered bft‑proposal‑valid by other nodes unless it satisfies the above rules. If more than two thirds of voting units are cast for an **invalid** proposal, something is seriously *and visibly* wrong; in any case, the block will not be accepted as a valid bft‑block. Importantly, a purportedly valid bft‑block will not be recognized as such by *any* honest Crosslink node even if it includes a valid notarization proof, if it does not meet other bft‑block‑validity rules. +The reason to separate the validity rules from the honest voting condition, is that the validity rules are objective: they don’t depend on an observer’s view of the bc‑best‑chain. Therefore, they can be checked independently of validator signatures. Even a proposal voted for by 100% of validators will not be considered bft‑proposal‑valid by other nodes unless it satisfies the above rules. If more than two thirds of voting units are cast for an **invalid** proposal, something is seriously *and visibly* wrong; in any case, the block will not be accepted as a valid bft‑block. Importantly, a purportedly valid bft‑block will not be recognized as such by *any* honest Crosslink node even if it includes a valid notarization proof, if it does not meet other bft‑block‑validity rules. This is essential to making $\mathsf{LOG}_{\mathrm{fin}}$ safe against a flaw in $\Pi_{\mathrm{bft}}$ or its security assumptions (even, say, a complete break of the validator signature algorithm), as long as $\Pi_{\mathrm{bc}}$ remains safe. ``` ```admonish info collapsible=true title="What does the **Increasing Score rule** do?" -This rule ensures that each snapshot in a bft‑valid‑chain is strictly "better" than the last distinct snapshot (and therefore any earlier distinct snapshot), according to the same metric used to choose the bc‑best‑chain. +This rule ensures that each snapshot in a bft‑valid‑chain is strictly “better” than the last distinct snapshot (and therefore any earlier distinct snapshot), according to the same metric used to choose the bc‑best‑chain. This rule has several positive effects: * It prevents potential attacks that rely on proposing a bc‑valid‑chain that forks from a much earlier block. This is necessary because the difficulty (or stake threshold) at that point could have been much lower. -* It limits the extent of disruption an adversary can feasibly cause to $\mathsf{LOG}_{\mathrm{bda},i}$, *even if* it has subverted $\Pi_{\mathrm{bft}}$. In particular, if transactions are inserted into $\mathsf{LOG}_{\mathrm{bda},i}$ at the finalization point, this rule ensures that they can only come from a bc‑valid‑chain that has a higher score than the previous snapshot. And since the adversary must prove that its snapshot is confirmed, there must be at least $\sigma$ blocks' worth of Proof‑of‑Work on top of that snapshot, at a difficulty close to the current network difficulty. - Note that the adversary could take advantage of an "accidental" fork and start its attack from the base of that fork, so that not all of this work is done by it alone. This is also possible in the case of a standard "private mining" attack, and is not so much of a problem in practice because accidental forks are expected to be short. In any case, $\sigma$ should be chosen to take it into account. +* It limits the extent of disruption an adversary can feasibly cause to $\mathsf{LOG}_{\mathrm{bda},i}$, *even if* it has subverted $\Pi_{\mathrm{bft}}$. In particular, if transactions are inserted into $\mathsf{LOG}_{\mathrm{bda},i}$ at the finalization point, this rule ensures that they can only come from a bc‑valid‑chain that has a higher score than the previous snapshot. And since the adversary must prove that its snapshot is confirmed, there must be at least $\sigma$ blocks’ worth of Proof‑of‑Work on top of that snapshot, at a difficulty close to the current network difficulty. + Note that the adversary could take advantage of an “accidental” fork and start its attack from the base of that fork, so that not all of this work is done by it alone. This is also possible in the case of a standard “private mining” attack, and is not so much of a problem in practice because accidental forks are expected to be short. In any case, $\sigma$ should be chosen to take it into account. * A snapshot with a higher score than any previous snapshot cannot be a prefix of a previous snapshot (because score strictly increases within a bc‑valid‑chain). So, this excludes proposals that would be a no‑op for that reason. The increase in score is intentionally always relative to the snapshot of the parent bft‑block, even if it is not final in the context of the current bft‑block. This is because the rule needs to hold if and when it becomes final in the context of some descendant bft‑block. @@ -477,13 +477,13 @@ The increase in score is intentionally always relative to the snapshot of the pa ``` ```admonish info collapsible=true title="Why does the **Increasing Score rule** allow keeping the same snapshot as the parent?" -This is necessary in order to preserve liveness of $\Pi_{\mathrm{bft}}$ relative to $\Pi_{\mathrm{origbft}}$. Liveness of $\Pi_{\mathrm{origbft}}$ might require honest proposers to make proposals at a minimum rate. That requirement could be consistently violated if it were not always possible to make a valid proposal. But given that it is allowed to repeat the same snapshot as in the parent bft‑block, neither the **Increasing Score rule** nor the **Tail Confirmation rule** can prevent making a valid proposal --- and all other rules of $\Pi_{\mathrm{bft}}$ affecting the ability to make valid proposals are the same as in $\Pi_{\mathrm{origbft}}$. (In principle, changes to voting in $\Pi_{\mathrm{bft}}$ could also affect its liveness; we'll discuss that in the liveness proof later.) +This is necessary in order to preserve liveness of $\Pi_{\mathrm{bft}}$ relative to $\Pi_{\mathrm{origbft}}$. Liveness of $\Pi_{\mathrm{origbft}}$ might require honest proposers to make proposals at a minimum rate. That requirement could be consistently violated if it were not always possible to make a valid proposal. But given that it is allowed to repeat the same snapshot as in the parent bft‑block, neither the **Increasing Score rule** nor the **Tail Confirmation rule** can prevent making a valid proposal — and all other rules of $\Pi_{\mathrm{bft}}$ affecting the ability to make valid proposals are the same as in $\Pi_{\mathrm{origbft}}$. (In principle, changes to voting in $\Pi_{\mathrm{bft}}$ could also affect its liveness; we’ll discuss that in the liveness proof later.) -For example, Streamlet requires three notarized blocks *in consecutive epochs* in order to finalize a block [[CS2020](https://eprint.iacr.org/2020/088.pdf), section 1.1]. Its proof of liveness depends on the assumption that in each epoch for which the leader is honest, that leader will make a proposal, and that during a "period of synchrony" this proposal will be received by every node [[CS2020](https://eprint.iacr.org/2020/088.pdf), section 3.6]. This argument can also be extended to adapted‑Streamlet. +For example, Streamlet requires three notarized blocks *in consecutive epochs* in order to finalize a block [[CS2020](https://eprint.iacr.org/2020/088.pdf), section 1.1]. Its proof of liveness depends on the assumption that in each epoch for which the leader is honest, that leader will make a proposal, and that during a “period of synchrony” this proposal will be received by every node [[CS2020](https://eprint.iacr.org/2020/088.pdf), section 3.6]. This argument can also be extended to adapted‑Streamlet. -We could alternatively have allowed to always make a "null" proposal, rather than to always make a proposal with the same snapshot as the parent. We prefer the latter because the former would require specifying the rules for null proposals in $\Pi_{\mathrm{origbft}}$. +We could alternatively have allowed to always make a “null” proposal, rather than to always make a proposal with the same snapshot as the parent. We prefer the latter because the former would require specifying the rules for null proposals in $\Pi_{\mathrm{origbft}}$. -As a clarification, no BFT protocol that uses leader election can *require* a proposal in each epoch, because the leader might be dishonest. The above issue concerns liveness of the protocol when assumptions about the attacker's share of bft‑validators or stake are met, so that it can be assumed that sufficiently long periods with enough honest leaders to make progress (5 consecutive epochs in the case of Streamlet), will occur with significant probability. +As a clarification, no BFT protocol that uses leader election can *require* a proposal in each epoch, because the leader might be dishonest. The above issue concerns liveness of the protocol when assumptions about the attacker’s share of bft‑validators or stake are met, so that it can be assumed that sufficiently long periods with enough honest leaders to make progress (5 consecutive epochs in the case of Streamlet), will occur with significant probability. ``` ```admonish info collapsible=true title="Why is it not allowed to switch between snapshots with the same score?" @@ -498,22 +498,22 @@ The finality rule for bft‑blocks in a given context is unchanged from origbft ### Πbft honest proposal -An honest proposer of a bft‑proposal $P$ chooses $P\mathsf{.headers\_bc}$ as the $\sigma$‑block tail of its bc‑best‑chain, provided that it is consistent with the **Increasing Score rule**. If it would not be consistent with that rule, it sets $P\mathsf{.headers\_bc}$ to the same $\mathsf{headers\_bc}$ field as $P$'s parent bft‑block. It does not make proposals until its bc‑best‑chain is at least $\sigma + 1$ blocks long. +An honest proposer of a bft‑proposal $P$ chooses $P\mathsf{.headers\_bc}$ as the $\sigma$‑block tail of its bc‑best‑chain, provided that it is consistent with the **Increasing Score rule**. If it would not be consistent with that rule, it sets $P\mathsf{.headers\_bc}$ to the same $\mathsf{headers\_bc}$ field as $P$’s parent bft‑block. It does not make proposals until its bc‑best‑chain is at least $\sigma + 1$ blocks long. ```admonish info collapsible=true title="Why σ + 1?" If the length were less than $\sigma + 1$ blocks, it would be impossible to construct the $\mathsf{headers\_bc}$ field of the proposal. -Note that when the length of the proposer' bc‑best‑chain is exactly $\sigma + 1$ blocks, the snapshot must be of $\mathcal{O}_{\mathrm{bc}}.$ But this does not violate the **Increasing Score rule**, because $\mathcal{O}_{\mathrm{bc}}$ matches the previous snapshot by $\mathcal{O}_{\mathrm{bft}}$. +Note that when the length of the proposer’s bc‑best‑chain is exactly $\sigma + 1$ blocks, the snapshot must be of $\mathcal{O}_{\mathrm{bc}}.$ But this does not violate the **Increasing Score rule**, because $\mathcal{O}_{\mathrm{bc}}$ matches the previous snapshot by $\mathcal{O}_{\mathrm{bft}}$. ``` -```admonish info collapsible=true title="How is it possible that the **Increasing Score rule** would not be satisfied by choosing headers from the proposer's bc‑best‑chain?" +```admonish info collapsible=true title="How is it possible that the **Increasing Score rule** would not be satisfied by choosing headers from the proposer’s bc‑best‑chain?" Assume for this discussion that $\Pi_{\mathrm{bc}}$ uses PoW. Depending on the value of $\sigma$, the timestamps of bc‑blocks, and the difficulty adjustment rule, it could be the case that the difficulty on the new bc‑best‑chain increases relative to the chain of the previous snapshot. In that case, when there is a fork, the new chain could reach a higher score than the previous chain in less than $\sigma$ blocks from the fork point, and so its $\sigma$‑confirmed snapshot could be before the previous snapshot. -(For [Zcash's difficulty adjustment algorithm](https://zips.z.cash/protocol/protocol.pdf#diffadjustment), the difficulty of each block is adjusted based on the median timestamps and difficulty target thresholds over a range of $\mathsf{PoWAveragingWindow} = 17$ blocks, where each median is taken over $\mathsf{PoWMedianBlockSpan} = 11$ blocks. Other damping factors and clamps are applied in order to prevent instability and to reduce the influence that adversarially chosen timestamps can have on difficulty adjustment. This makes it unlikely that an adversary could gain a significant advantage by manipulating the difficulty adjustment.) +(For [Zcash’s difficulty adjustment algorithm](https://zips.z.cash/protocol/protocol.pdf#diffadjustment), the difficulty of each block is adjusted based on the median timestamps and difficulty target thresholds over a range of $\mathsf{PoWAveragingWindow} = 17$ blocks, where each median is taken over $\mathsf{PoWMedianBlockSpan} = 11$ blocks. Other damping factors and clamps are applied in order to prevent instability and to reduce the influence that adversarially chosen timestamps can have on difficulty adjustment. This makes it unlikely that an adversary could gain a significant advantage by manipulating the difficulty adjustment.) -For a variation on the **Increasing Score rule** that would be automatically satisfied by choosing headers from the proposer's bc‑best‑chain, see [Potential changes to Crosslink](./potential-changes.md#Changing-the-Increasing-Score-rule-to-require-the-score-of-the-tip-rather-than-the-score-of-the-snapshot-to-increase). +For a variation on the **Increasing Score rule** that would be automatically satisfied by choosing headers from the proposer’s bc‑best‑chain, see [Potential changes to Crosslink](./potential-changes.md#changing-the-increasing-score-rule-to-require-the-score-of-the-tip-rather-than-the-score-of-the-snapshot-to-increase). ``` ### Πbft honest voting @@ -523,24 +523,24 @@ An honest validator considering a proposal $P$, first updates its view of both s For each downloaded bc‑block, the bft‑chain referenced by its $\mathsf{context\_bft}$ field might need to be validated if it has not been seen before. ```admonish info collapsible=true title="Wait what, how much validation is that?" -In general the entire referenced bft‑chain needs to be validated, not just the referenced block --- and for each bft‑block, the bc‑chain in $\mathsf{headers\_bc}$ needs to be validated, and so on recursively. If this sounds overwhelming, note that: +In general the entire referenced bft‑chain needs to be validated, not just the referenced block — and for each bft‑block, the bc‑chain in $\mathsf{headers\_bc}$ needs to be validated, and so on recursively. If this sounds overwhelming, note that: * We should check the requirement that a bft‑valid‑block must have been voted for by a two‑thirds absolute supermajority of validators, and any other *non‑recursive* bft‑validity rules, *first*. * Before validating a bc‑chain referenced by a $\mathsf{headers\_bc}$ field, we check that it connects to an already-validated bc‑chain and that the Proofs‑of‑Work are valid. This implies that the amount of bc‑block validation is constrained by how fast the network can find valid Proofs‑of‑Work. In other words, the order of validation is important to avoid denial‑of‑service. But it already is in Bitcoin and Zcash. ``` -${}$ + After updating its view, the validator will vote for a proposal $P$ *only if*: * **Valid proposal criterion:** it is bft‑proposal‑valid, and -* **Confirmed best‑chain criterion:** $\mathsf{snapshot}(P)$ is part of the validator's bc‑best‑chain at a bc‑confirmation‑depth of at least $\sigma$. +* **Confirmed best‑chain criterion:** $\mathsf{snapshot}(P)$ is part of the validator’s bc‑best‑chain at a bc‑confirmation‑depth of at least $\sigma$. -```admonish info collapsible=true title="Blocks in a bc‑best‑chain are by definition bc‑block‑valid. If we're checking the **Confirmed best‑chain criterion**, why do we need to have separately checked that the blocks referenced by the headers are bc‑block‑valid?" -The **Confirmed best‑chain criterion** is quite subtle. It ensures that $\mathsf{snapshot}(P) = P\mathsf{.headers\_bc}[0] \lceil_{\mathrm{bc}}^1$ is bc‑block‑valid and has $\sigma$ bc‑block‑valid blocks after it in the validator's bc‑best‑chain. However, it need not be the case that $P\mathsf{.headers\_bc}[\sigma-1]$ is part of the validator's bc‑best‑chain after it updates its view. That is, the chain could fork after $\mathsf{snapshot}(P)$. +```admonish info collapsible=true title="Blocks in a bc‑best‑chain are by definition bc‑block‑valid. If we’re checking the **Confirmed best‑chain criterion**, why do we need to have separately checked that the blocks referenced by the headers are bc‑block‑valid?" +The **Confirmed best‑chain criterion** is quite subtle. It ensures that $\mathsf{snapshot}(P) = P\mathsf{.headers\_bc}[0] \lceil_{\mathrm{bc}}^1$ is bc‑block‑valid and has $\sigma$ bc‑block‑valid blocks after it in the validator’s bc‑best‑chain. However, it need not be the case that $P\mathsf{.headers\_bc}[\sigma-1]$ is part of the validator’s bc‑best‑chain after it updates its view. That is, the chain could fork after $\mathsf{snapshot}(P)$. -The bft‑proposal‑validity rule must be objective; it can't depend on what the validator's bc‑best‑chain is. The validator's bc‑best‑chain *may* have been updated to $P\mathsf{.headers\_bc}[\sigma-1]$ (if it has the highest score), but it also may not. +The bft‑proposal‑validity rule must be objective; it can’t depend on what the validator’s bc‑best‑chain is. The validator’s bc‑best‑chain *may* have been updated to $P\mathsf{.headers\_bc}[\sigma-1]$ (if it has the highest score), but it also may not. -However, if the validator's bc‑best‑chain *was* updated, that makes it more likely that it will be able to vote for the proposal. +However, if the validator’s bc‑best‑chain *was* updated, that makes it more likely that it will be able to vote for the proposal. In any case, if the validator does not check that all of the blocks referenced by the headers are bc‑block‑valid, then its vote may be invalid. ``` @@ -549,9 +549,9 @@ In any case, if the validator does not check that all of the blocks referenced b Snap‑and‑Chat already had the voting condition: > An honest node only votes for a proposed BFT block $B$ if it views $B\mathsf{.ch}$ as confirmed. -but it did *not* give the headers potentially needed to update the validator's view, and it did not require a proposal to be for an *objectively confirmed* snapshot as a matter of validity. +but it did *not* give the headers potentially needed to update the validator’s view, and it did not require a proposal to be for an *objectively confirmed* snapshot as a matter of validity. -If a Crosslink‑like protocol were to require an objectively confirmed snapshot but without including the bc‑headers in the proposal, then validators would not immediately know which bc‑blocks to download to check its validity. This would increase latency, and would be likely to lead proposers to be more conservative and only propose blocks that they think will *already* be in at least a two‑thirds absolute supermajority of validators' best chains. +If a Crosslink‑like protocol were to require an objectively confirmed snapshot but without including the bc‑headers in the proposal, then validators would not immediately know which bc‑blocks to download to check its validity. This would increase latency, and would be likely to lead proposers to be more conservative and only propose blocks that they think will *already* be in at least a two‑thirds absolute supermajority of validators’ best chains. That is, showing $P\mathsf{.headers\_bc}$ to all of the validators is advantageous to the proposer, because the proposer does not have to guess what blocks the validators might have already seen. It is also advantageous for the protocol goals in general, because it improves the trade‑off between finalization latency and security. ``` @@ -562,7 +562,7 @@ That is, showing $P\mathsf{.headers\_bc}$ to all of the validators is advantageo In Snap‑and‑Chat, a node $i$ at time $t$ obtains $\mathsf{LOG}_{\mathrm{fin},i}^t$ from its latest view of bft‑finality. -In Crosslink, it obtains $\mathsf{LOG}_{\mathrm{fin},i}^t$ from the view of bft‑finality given by $\mathsf{ch}_i^t \lceil_{\mathrm{bc}}^\sigma$, i.e. the block at depth $\sigma$ in node $i$'s' bc‑best‑chain at time $t$. +In Crosslink, it obtains $\mathsf{LOG}_{\mathrm{fin},i}^t$ from the view of bft‑finality given by $\mathsf{ch}_i^t \lceil_{\mathrm{bc}}^\sigma$, i.e. the block at depth $\sigma$ in node $i$’s bc‑best‑chain at time $t$. Specifically,$$ \begin{array}{rcl} @@ -580,18 +580,18 @@ $$ For the definitions that use it, $\mu \in \mathbb{N}$ is a confirmation depth. -```admonish warning +```admonish warning "Security caveat" Using small values of $\mu$ is not recommended. $\mu = 0$ is an allowed value only because it is used in the definition of contextual validity in the next section. ``` Sanitization is the same as in Snap‑and‑Chat: it does a left fold over an input sequence of transactions, adding each of them to a running bc‑context if they are bc‑context‑valid. The initial bc‑context for this fold corresponds to the state after the genesis bc‑block. This process can be optimized by immediately discarding duplicate bc‑blocks in the concatenated snapshot chains after their first occurrence. -```admonish info -Implementation advice: memoize the $\textsf{san-ctx}$ function. If you see an input to $\textsf{san-ctx}$ that extends a previous input (either adding a new snapshot, or adding blocks to the last snapshot), compute the result incrementally from the previous result. +```admonish info "Implementation advice" +Memoize the $\textsf{san-ctx}$ function. If you see an input to $\textsf{san-ctx}$ that extends a previous input (either adding a new snapshot, or adding blocks to the last snapshot), compute the result incrementally from the previous result. ``` -```admonish success -**Ledger prefix property**: For all nodes $i$, times $t$, and confirmation depths $\mu$, $\mathsf{LOG}_{\mathsf{fin},i} \preceq \mathsf{LOG}_{\mathsf{bda},i,\mu}$. +```admonish success "Theorem: Ledger prefix property" +For all nodes $i$, times $t$, and confirmation depths $\mu$, $\mathsf{LOG}_{\mathsf{fin},i} \preceq \mathsf{LOG}_{\mathsf{bda},i,\mu}$. Proof: By construction of $\mathsf{LOG}_{\mathsf{fin},i}$ and $\mathsf{LOG}_{\mathsf{bda},i,\mu}$. ``` @@ -601,7 +601,9 @@ Proof: By construction of $\mathsf{LOG}_{\mathsf{fin},i}$ and $\mathsf{LOG}_{\mathrm{bda},i,\mu}$; + b) checking whether a block is bc‑block‑valid in order to append it to a chain; + c) checking whether a transaction in the mempool could be included in a block. Note that the model we presented earlier considers only adding a transaction to an origbc‑context. It is straightforward to apply this to the sanitization use case a), as described in the previous section. However, the other two use cases raise the question of which starting bc‑context to use. @@ -626,21 +628,21 @@ $$ Then either $\textsf{finality-depth}(H) \leq L$ or node $i$'s bc‑best‑chain at time $t$. +Let $H = \mathsf{ch}_i^t$, i.e. the tip of node $i$’s bc‑best‑chain at time $t$. Then, $\mathsf{LF}(H \lceil_{\mathrm{bc}}^\sigma)$ is the bft‑block providing the last $\Pi_{\mathrm{bc}}$ snapshot that will be used to construct $\mathsf{LOG}_{\mathrm{fin},i}^t$. $\mathsf{tailhead}(H)$ is the last common ancestor of that snapshot and $H$. The idea behind the above definition is that: * If $\mathsf{snapshot}(\mathsf{LF}(H \lceil_{\mathrm{bc}}^\sigma))$ is an ancestor of $H$, then it is equal to $\mathsf{tailhead}(H)$, and that is the last bc‑block that contributes to $\mathsf{LOG}_{\mathrm{fin},i}^t$. If the best chain were to continue from $H$ without a rollback, then the bc‑blocks to be finalized next would be the ones from $\mathsf{tailhead}(H)$ to $H$, and so the number of those blocks gives the finality depth. -* Otherwise, $\mathsf{snapshot}(\mathsf{LF}(H \lceil_{\mathrm{bc}}^\sigma))$ must be on a different fork, and the bc‑blocks to be finalized next would resume from the fork point toward $H$ --- unless some of those blocks have already been included, as discussed below. $\mathsf{LOG}_{\mathrm{fin},i}^t$ will definitely contain transactions from blocks up to $\mathsf{tailhead}(H)$, but usually not subsequent transactions on $H$'s fork. So it is still reasonable to measure the finality depth from $\mathsf{tailhead}(H)$ to $H$. +* Otherwise, $\mathsf{snapshot}(\mathsf{LF}(H \lceil_{\mathrm{bc}}^\sigma))$ must be on a different fork, and the bc‑blocks to be finalized next would resume from the fork point toward $H$ — unless some of those blocks have already been included, as discussed below. $\mathsf{LOG}_{\mathrm{fin},i}^t$ will definitely contain transactions from blocks up to $\mathsf{tailhead}(H)$, but usually not subsequent transactions on $H$’s fork. So it is still reasonable to measure the finality depth from $\mathsf{tailhead}(H)$ to $H$. -Strictly speaking, it is possible that a previous bft‑block took a snapshot $H'$ that is between $\mathsf{tailhead}(H)$ and $H$. This can only happen if there have been at least two rollbacks longer than $\sigma$ blocks (i.e. we went more than $\sigma$ blocks down $H$'s fork from $\mathsf{tailhead}(H)$, then reorged to more than $\sigma$ blocks down the fork to $\mathsf{snapshot}(\mathsf{LF}(H \lceil_{\mathrm{bc}}^\sigma))$, then reorged again to $H$'s fork). In that case, the finalized ledger would already have the non‑conflicting transactions from blocks between $\mathsf{tailhead}(H)$ and $H'$ --- and it could be argued that the correct definition of finality depth in such cases is the number of blocks from $H'$ to $H$, not from $\mathsf{tailhead}(H)$ to $H$. +Strictly speaking, it is possible that a previous bft‑block took a snapshot $H'$ that is between $\mathsf{tailhead}(H)$ and $H$. This can only happen if there have been at least two rollbacks longer than $\sigma$ blocks (i.e. we went more than $\sigma$ blocks down $H$’s fork from $\mathsf{tailhead}(H)$, then reorged to more than $\sigma$ blocks down the fork to $\mathsf{snapshot}(\mathsf{LF}(H \lceil_{\mathrm{bc}}^\sigma))$, then reorged again to $H$’s fork). In that case, the finalized ledger would already have the non‑conflicting transactions from blocks between $\mathsf{tailhead}(H)$ and $H'$ — and it could be argued that the correct definition of finality depth in such cases is the number of blocks from $H'$ to $H$, not from $\mathsf{tailhead}(H)$ to $H$. However, * The definition above is simpler and easier to compute. * The effect of overestimating the finality depth in such corner cases would only cause us to enforce Safety Mode slightly sooner, which seems fine (and even desirable) in any situation where there have been at least two rollbacks longer than $\sigma$ blocks. -By the way, the "tailhead" of a tailed animal is the area where the posterior of the tail joins the rump (also called the "dock" in some animals). +By the way, the “tailhead” of a tailed animal is the area where the posterior of the tail joins the rump (also called the “dock” in some animals). ``` ### Πbc honest block production @@ -656,7 +658,7 @@ The honest block producer then sets $H\mathsf{ ```admonish info collapsible=true title="Why not choose *T*  such that *H* ⌈1bc . context_bft  ⪯bft  bft‑last‑final(*T* )?" The effect of this would be to tend to more often follow the last bft‑block seen by the producer of the parent bc‑block, if there is a choice. It is not always possible to do so, though: the resulting set of candidates for $C$ might be empty. -Also, it is not clear that giving the parent bc‑block‑producer the chance to "guide" what bft‑block should be chosen next is beneficial, since that producer might be adversarial and the resulting incentives are difficult to reason about. +Also, it is not clear that giving the parent bc‑block‑producer the chance to “guide” what bft‑block should be chosen next is beneficial, since that producer might be adversarial and the resulting incentives are difficult to reason about. ``` ```admonish info collapsible=true title="Why choose the longest *C*, rather than the longest bft‑last‑final(*C* )?" @@ -664,9 +666,9 @@ We could have instead chosen $C$ to maximize the length i.e. $\mathsf{score}(\mathsf{tip}(\textsf{bft-last-final}(C)))$. +If we [switch to using the Increasing Tip Score rule](./potential-changes.md#changing-the-increasing-score-rule-to-require-the-score-of-the-tip-rather-than-the-score-of-the-snapshot-to-increase), then it would be more consistent to also change this tie‑breaking rule to use the tip score, i.e. $\mathsf{score}(\mathsf{tip}(\textsf{bft-last-final}(C)))$. ``` -${}$ + At this point we have completed the definition of Crosslink. In [Security Analysis of Crosslink](./security-analysis.md), we will prove it secure. diff --git a/src/design/crosslink/notes-on-snap-and-chat.md b/src/design/crosslink/notes-on-snap-and-chat.md index 83dd1ee..5f2c687 100644 --- a/src/design/crosslink/notes-on-snap-and-chat.md +++ b/src/design/crosslink/notes-on-snap-and-chat.md @@ -1,16 +1,16 @@ -# Notes on Snap-and-Chat +# Notes on Snap‑and‑Chat -The discussion in [The Argument for Bounded Dynamic Availability and Finality Overrides](./the-arguments-for-bounded-dynamic-availability-and-finality-overrides.md) is at an abstract level, applying to any ebb-and-flow-like protocol. +The discussion in [The Argument for Bounded Dynamic Availability and Finality Overrides](./the-arguments-for-bounded-dynamic-availability-and-finality-overrides.md) is at an abstract level, applying to any Ebb‑and‑Flow-like protocol. -This document considers specifics of the snap-and-chat construction proposed in [[NTT2020]](https://eprint.iacr.org/2020/1091.pdf) ([arXiv version](https://arxiv.org/pdf/2009.04987.pdf)). +This document considers specifics of the Snap‑and‑Chat construction proposed in [[NTT2020]](https://eprint.iacr.org/2020/1091.pdf) ([arXiv version](https://arxiv.org/pdf/2009.04987.pdf)). ```admonish info -I am trying to be precise in this note about use of the terms "ebb-and-flow", which is the security model and goal introduced in [[NTT2020]](https://eprint.iacr.org/2020/1091.pdf), vs "snap-and-chat", which is the construction proposed in the same paper to achieve that goal. There could be other ways to design an ebb-and-flow protocol that don't run into the difficulties described in this section (or that run into different difficulties). +I am trying to be precise in this note about use of the terms "Ebb‑and‑Flow", which is the security model and goal introduced in [[NTT2020]](https://eprint.iacr.org/2020/1091.pdf), vs "Snap‑and‑Chat", which is the construction proposed in the same paper to achieve that goal. There could be other ways to design an Ebb‑and‑Flow protocol that don't run into the difficulties described in this section (or that run into different difficulties). ``` ### Effect on consensus -A general problem with the snap-and-chat construction is that it does not follow, from enforcement of the original consensus rules on blocks produced in $\Pi_{\mathrm{lc}}$, that the properties they are intended to enforce hold for the $\mathsf{LOG}_{\mathrm{fin},i}^t$ or $\mathsf{LOG}_{\mathrm{da},i}^t$ ledgers. Less obviously, the converse also does not follow: enforcing unmodified consensus rules on $\Pi_{\mathrm{lc}}$ blocks is **both** too lax and too strict. +A general problem with the Snap‑and‑Chat construction is that it does not follow, from enforcement of the original consensus rules on blocks produced in $\Pi_{\mathrm{lc}}$, that the properties they are intended to enforce hold for the $\mathsf{LOG}_{\mathrm{fin},i}^t$ or $\mathsf{LOG}_{\mathrm{da},i}^t$ ledgers. Less obviously, the converse also does not follow: enforcing unmodified consensus rules on $\Pi_{\mathrm{lc}}$ blocks is **both** too lax and too strict. Recall from the paper how $\mathsf{LOG}_{\mathrm{fin},i}^t$ and $\mathsf{LOG}_{\mathrm{da},i}^t$ are constructed (starting at the end of page 8 of [[NTT2020]](https://eprint.iacr.org/2020/1091.pdf)): @@ -18,10 +18,9 @@ Recall from the paper how $\mathsf{LOG}_{\mathrm{fin},i}^t$ and $\mathsf{LOG}_{\ This says that $\mathsf{LOG}_{\mathrm{fin},i}^t$ and $\mathsf{LOG}_{\mathrm{da},i}^t$ are sequences of transactions, *not* sequences of blocks. Therefore, [consensus rules defined at the block level](https://zips.z.cash/protocol/protocol.pdf#blockheader) are not applicable. -```admonish warning -**Zcash-specific** +```admonish warning "Zcash-specific" -Most of these rules are Proof-of-Work-related checks that can be safely ignored at this level. Some are related to the `hashBlockCommitments` field intended for use by the FlyClient protocol. It is not at all clear how to make FlyClient (or other uses of this commitment) work with the snap-and-chat construction. In particular, the `hashEarliest{Sapling,Orchard}Root`, `hashLatest{Sapling,Orchard}Root`, and `n{Sapling,Orchard}TxCount` fields don't make sense in this context since they could only reflect the values in $\mathsf{ch}_i^t$, which have no relation in general to those for any subrange of transactions in $\mathsf{LOG}_{\mathrm{da},i}^t$. However, that problem occurs for unmodified snap-and-chat, and so is outside the scope of this note. +Most of these rules are Proof-of-Work-related checks that can be safely ignored at this level. Some are related to the `hashBlockCommitments` field intended for use by the FlyClient protocol. It is not at all clear how to make FlyClient (or other uses of this commitment) work with the Snap‑and‑Chat construction. In particular, the `hashEarliest{Sapling,Orchard}Root`, `hashLatest{Sapling,Orchard}Root`, and `n{Sapling,Orchard}TxCount` fields don't make sense in this context since they could only reflect the values in $\mathsf{ch}_i^t$, which have no relation in general to those for any subrange of transactions in $\mathsf{LOG}_{\mathrm{da},i}^t$. However, that problem occurs for unmodified Snap‑and‑Chat, and so is outside the scope of this note. ``` Since $\mathsf{LOG}_{\mathrm{da},i}^t$ does not have blocks, it is not well-defined whether it has "coinbase-only blocks" when in Safety Mode. That by itself is not so much of a problem because it would be sufficient for it to have only coinbase transactions in that mode. @@ -30,7 +29,7 @@ Since $\mathsf{LOG}_{\mathrm{da},i}^t$ does not have blocks, it is not well-defi The issuance schedule of Zcash was designed under the assumption that blocks only come from a single chain, and that the difficulty adjustment algorithm keeps the rate of block mining roughly constant over time. -For snap-and-chat, if there is a rollback longer than $\sigma$ blocks in $\Pi_{\mathrm{lc}}$, additional coinbase transactions from the rolled-back chain will be included in $\mathsf{LOG}_{\mathrm{fin}}$. +For Snap‑and‑Chat, if there is a rollback longer than $\sigma$ blocks in $\Pi_{\mathrm{lc}}$, additional coinbase transactions from the rolled-back chain will be included in $\mathsf{LOG}_{\mathrm{fin}}$. We can argue that this will happen rarely enough not to cause any significant problem for the overall issuance schedule. However, it does mean that issuance is less predictable, because the block subsidies will be computed according to their depth in the $\Pi_{\mathrm{lc}}$ chain on which they were mined. So it will no longer be the case that coinbase transactions issue a deterministic, non-increasing sequence of block subsidies. @@ -50,7 +49,7 @@ This means that if $\mathsf{LOG}_{\mathrm{fin},i}$ is extended by a block that i ### Subtlety in the definition of sanitization -There are two possible ways to interpret how $\mathsf{LOG}_{\{\mathrm{fin},\mathrm{da}\}}$ are constructed in snap-and-chat: +There are two possible ways to interpret how $\mathsf{LOG}_{\{\mathrm{fin},\mathrm{da}\}}$ are constructed in Snap‑and‑Chat: 1. Concatenate the transactions from each final BFT block snapshot of an LC chain, and sanitize the resulting transaction sequence by including each transaction iff it is contextually valid. 2. Concatenate the *blocks* from each final BFT block snapshot of an LC chain, remove duplicate *blocks*, and only then sanitize the resulting transaction sequence by including each transaction iff it is contextually valid. @@ -61,14 +60,14 @@ The only reasons for a transaction to be contextually invalid are double-spends * If a transaction is omitted due to a double-spend, then any subsequent time it is checked, that input will still have been double-spent. * If a transaction is omitted due to a missing input, this can only be because an earlier transaction in the input to sanitization was omitted. So the structure of omitted transactions forms a DAG in which parent links must be to *earlier* omitted transactions. The roots of the DAG are at double-spending transactions, which cannot be reinstated. A child cannot be reinstated until its parents have been reinstated. Therefore, no transactions are reinstated. -Note that any *other* reason for transactions to be contextually invalid might interfere with this argument. Therefore, strictly speaking snap-and-chat should require of $\Pi_{\mathrm{lc}}$ that there is no such other reason. I cannot see this explicitly stated anywhere in [[NTT2020]](https://eprint.iacr.org/2020/1091.pdf). +Note that any *other* reason for transactions to be contextually invalid might interfere with this argument. Therefore, strictly speaking Snap‑and‑Chat should require of $\Pi_{\mathrm{lc}}$ that there is no such other reason. I cannot see this explicitly stated anywhere in [[NTT2020]](https://eprint.iacr.org/2020/1091.pdf). ### Spending finalized outputs Transactions in $\mathsf{ch}_i^t$ need to be able to spend outputs that are not necessarily from any previous transaction in $\mathsf{ch}_i^t$. This is because, from the point of view of a user of node $i$ at time $t$, the block chain includes all transactions in $\mathsf{LOG}_{\mathrm{da},i}^t$. All of the transactions after the finalization point are guaranteed to also be in $\mathsf{ch}_i^t$, but the ones before the finalization point (i.e. in $\mathsf{LOG}_{\mathrm{fin},i}^t$) are not, because they could be from some other $\mathsf{ch}_j^u$ for $u \leq t$ and $j \neq i$ (intuitively, from some long chain fork that was once considered confirmed by enough nodes). ```admonish info -Honest nodes only ever vote for confirmed snapshots, that is, prefixes of their best $\Pi_{\mathrm{lc}}$ chain truncated by the confirmation depth $\sigma$. Obviously the whole point of having the BFT protocol is that chain forks longer than $\sigma$ **can** occur in $\Pi_{\mathrm{lc}}$ --- otherwise we'd just use $\Pi_{\mathrm{lc}}$ and have done. So it is not that we expect this case to be common, but if it happens then it will never fix itself: the consensus chain in $\Pi_{\mathrm{lc}}$ will continue on without ever including the transactions from $\mathsf{LOG}_{\mathrm{fin}}^t$ that were obtained from a snapshot of another fork. +Honest nodes only ever vote for confirmed snapshots, that is, prefixes of their best $\Pi_{\mathrm{lc}}$ chain truncated by the confirmation depth $\sigma$. Obviously the whole point of having the BFT protocol is that chain forks longer than $\sigma$ **can** occur in $\Pi_{\mathrm{lc}}$ — otherwise we'd just use $\Pi_{\mathrm{lc}}$ and have done. So it is not that we expect this case to be common, but if it happens then it will never fix itself: the consensus chain in $\Pi_{\mathrm{lc}}$ will continue on without ever including the transactions from $\mathsf{LOG}_{\mathrm{fin}}^t$ that were obtained from a snapshot of another fork. ``` A user must be able to spend outputs for which they hold the spending key from **any** finalized transaction, otherwise there would be no point to the finalization. @@ -77,13 +76,13 @@ I think the authors of [[NTT2020]](https://eprint.iacr.org/2020/1091.pdf) probab Suppose that node $j$ is trying to determine whether $\mathsf{ch}_i^t$ is a consensus-valid chain, which is necessary for deterministic consensus in $\Pi_{\mathrm{lc}}$. It cannot decide whether to allow transactions in $\mathsf{ch}_i^t$ to spend outputs not in the history of $\mathsf{ch}_i^t$ on the basis of its *own* finalized view $\mathsf{LOG}_{\mathrm{fin},j}^t,$ because $\mathsf{LOG}_{\mathrm{fin},i}^t$ and $\mathsf{LOG}_{\mathrm{fin},j}^t$ are not in general the same. -Of course, we hope that $\mathsf{LOG}_{\mathrm{fin},i}^t$ and $\mathsf{LOG}_{\mathrm{fin},j}^t$ are consistent, i.e. one is a prefix of the other. But even if they are consistent, they are not necessarily the same length. In particular, if $\mathsf{LOG}_{\mathrm{fin},j}^t$ is *shorter* than $\mathsf{LOG}_{\mathrm{fin},i}^t,$ then node $j$ does not have enough information to fill in the gap --- and so it may incorrectly view a transaction in $\mathsf{ch}_i^t$ as spending an output that does not exist, when actually it does exist in $\mathsf{LOG}_{\mathrm{fin},i}^t \setminus \mathsf{LOG}_{\mathrm{fin},j}^t.$ Conversely if $\mathsf{LOG}_{\mathrm{fin},j}^t$ were longer and node $j$ were to allow spending an output in $\mathsf{LOG}_{\mathrm{fin},j}^t \setminus \mathsf{LOG}_{\mathrm{fin},i}^t,$ that would be using information that is not necessarily available to other nodes, and so node $j$ could diverge from consensus. +Of course, we hope that $\mathsf{LOG}_{\mathrm{fin},i}^t$ and $\mathsf{LOG}_{\mathrm{fin},j}^t$ are consistent, i.e. one is a prefix of the other. But even if they are consistent, they are not necessarily the same length. In particular, if $\mathsf{LOG}_{\mathrm{fin},j}^t$ is *shorter* than $\mathsf{LOG}_{\mathrm{fin},i}^t,$ then node $j$ does not have enough information to fill in the gap — and so it may incorrectly view a transaction in $\mathsf{ch}_i^t$ as spending an output that does not exist, when actually it does exist in $\mathsf{LOG}_{\mathrm{fin},i}^t \setminus \mathsf{LOG}_{\mathrm{fin},j}^t.$ Conversely if $\mathsf{LOG}_{\mathrm{fin},j}^t$ were longer and node $j$ were to allow spending an output in $\mathsf{LOG}_{\mathrm{fin},j}^t \setminus \mathsf{LOG}_{\mathrm{fin},i}^t,$ that would be using information that is not necessarily available to other nodes, and so node $j$ could diverge from consensus. -Consensus validity of the block at the tip of $\mathsf{ch}_i^t$ can only be a deterministic function of the block itself and its ancestors in $\mathsf{ch}_i^t$. It is crucial to be able to *eventually* spend outputs from the finalized chain. We are forced to conclude that the chain $\mathsf{ch}_i^t$ **must include** the information needed to calculate $\mathsf{LOG}_{\mathrm{fin},i}^{t'}$ for some $t'$ not too far behind $t$. That is, $\Pi_{\mathrm{lc}}$ must be modified to ensure that this is the case. This leads us to strengthen the required properties of an ebb-and-flow protocol to include another property, "finalization availability". +Consensus validity of the block at the tip of $\mathsf{ch}_i^t$ can only be a deterministic function of the block itself and its ancestors in $\mathsf{ch}_i^t$. It is crucial to be able to *eventually* spend outputs from the finalized chain. We are forced to conclude that the chain $\mathsf{ch}_i^t$ **must include** the information needed to calculate $\mathsf{LOG}_{\mathrm{fin},i}^{t'}$ for some $t'$ not too far behind $t$. That is, $\Pi_{\mathrm{lc}}$ must be modified to ensure that this is the case. This leads us to strengthen the required properties of an Ebb‑and‑Flow protocol to include another property, "finalization availability". ## Finalization Availability -In the absence of security flaws and under the security assumptions required by the finality layer, the finalization point will not be seen by any honest node to roll back. However, that does not imply that all nodes will see the same finalized height --- which is impossible given network delays and unreliable messaging. +In the absence of security flaws and under the security assumptions required by the finality layer, the finalization point will not be seen by any honest node to roll back. However, that does not imply that all nodes will see the same finalized height — which is impossible given network delays and unreliable messaging. Both in order to optimize the availability of applications that require finality, and in order to solve the technical issue of spending finalized outputs described in the previous section, we need to consider availability of the information needed to finalize the chain up to a particular point. @@ -91,20 +90,20 @@ Note that in Bitcoin-like consensus protocols, we don't generally consider it to Suppose, then, that each block header in $\Pi_{\mathrm{lc}}$ commits to the latest final BFT block known by the $\Pi_{\mathrm{lc}}$ block producer. For a block header $H$, we will refer to this commitment as $\textsf{final-bft}(H)$. -```admonish success +```admonish success "Consensus rule" We require, as a consensus rule, that if $H$ is not the genesis block header, then this BFT block either descends from or is the same as the final BFT block committed to by the $\Pi_{\mathrm{lc}}$ block's parent: i.e. $\textsf{final-bft}(\mathsf{parent}_{\mathrm{lc}}(H)) \preceq_{\mathrm{bft}} \textsf{final-bft}(H)$. ``` This rule does not prevent the BFT chain from rolling back, if the security assumptions of $\Pi_{\mathrm{bft}}$ were violated. However, it means that if a node $i$ does not observe a rollback in $\Pi_{\mathrm{lc}}$ at confirmation depth $\sigma$, then it will also not observe any instability in $\mathsf{LOG}_{\mathrm{fin},i}$, *even if* the security assumptions of $\Pi_{\mathrm{bft}}$ are violated. This property holds **by construction**, and in fact regardless of $\Pi_{\mathrm{bft}}$. ```admonish info -In the snap-and-chat construction, we also have BFT block proposals committing to $\Pi_{\mathrm{lc}}$ snapshots (top of right column of [[NTT2020](https://eprint.iacr.org/2020/1091.pdf), page 7]): +In the Snap‑and‑Chat construction, we also have BFT block proposals committing to $\Pi_{\mathrm{lc}}$ snapshots (top of right column of [[NTT2020](https://eprint.iacr.org/2020/1091.pdf), page 7]): > In addition, $\mathsf{ch}^t_i$ is used as side information in $\Pi_{\mathrm{bft}}$ to boycott the finalization of invalid snapshots proposed by the adversary. This does not cause any circularity, because each protocol only commits to *earlier* blocks of the other. In fact, BFT validators have to listen to transmission of $\Pi_{\mathrm{lc}}$ block headers anyway, so that *could* be also the protocol over which they get the information needed to make and broadcast their own signatures or proposals. (A possible reason not to broadcast individual signatures to all nodes is that with large numbers of validators, the proof that a sufficient proportion of validators/stake has signed can use an aggregate signature, which could be much smaller. Also, $\Pi_{\mathrm{lc}}$ nodes only need to know about *successful* BFT block proposals.) ``` -Now suppose that, in a snap-and-chat protocol, the BFT consensus finalizes a $\Pi_{\mathrm{lc}}$ snapshot that does not extend the snapshot in the previous block (which can happen if either $\Pi_{\mathrm{bft}}$ is unsafe, or $\Pi_{\mathrm{lc}}$ suffers a rollback longer than $\sigma$ blocks). In that case we will initially not be able to spend outputs from the old snapshot in the new chain. But eventually for some node $i$ that sees the header $H$ at the tip of its best chain at time $t$, $\textsf{final-bft}(H)$ will be such that from then on (i.e. at time $t' \geq t$), $\mathsf{LOG}_{\mathrm{fin},i}^{t'}$ includes the output that we want to spend. This assumes *liveness* of $\Pi_{\mathrm{lc}}$ and *safety* of $\Pi_{\mathrm{bft}}$. +Now suppose that, in a Snap‑and‑Chat protocol, the BFT consensus finalizes a $\Pi_{\mathrm{lc}}$ snapshot that does not extend the snapshot in the previous block (which can happen if either $\Pi_{\mathrm{bft}}$ is unsafe, or $\Pi_{\mathrm{lc}}$ suffers a rollback longer than $\sigma$ blocks). In that case we will initially not be able to spend outputs from the old snapshot in the new chain. But eventually for some node $i$ that sees the header $H$ at the tip of its best chain at time $t$, $\textsf{final-bft}(H)$ will be such that from then on (i.e. at time $t' \geq t$), $\mathsf{LOG}_{\mathrm{fin},i}^{t'}$ includes the output that we want to spend. This assumes *liveness* of $\Pi_{\mathrm{lc}}$ and *safety* of $\Pi_{\mathrm{bft}}$. That is, including a reference to a recent final BFT block in $\Pi_{\mathrm{lc}}$ block headers both incentivizes nodes to propagate this information, *and* can be used to solve the "spending finalized outputs" problem. @@ -120,7 +119,7 @@ $$ Here $\textsf{final-bft}(H)$ is the BFT block we are providing information for, and $\mathsf{snapshot}(\textsf{final-bft}(H))$ is the corresponding $\Pi_{\mathrm{lc}}$ snapshot. For a node $i$ that sees $\textsf{final-bft}(H)$ as the most recent final BFT block at time $t$, $\mathsf{LOG}_{\mathrm{fin},i}^t$ will definitely contain transactions from blocks up to $\mathsf{tailhead}(H)$, but usually will not contain subsequent transactions on $H$'s fork. ```admonish info -Strictly speaking, it is possible that a previous BFT block took a snapshot $H'$ that is between $\mathsf{tailhead}(H)$ and $H$. This can only happen if there have been at least two rollbacks longer than $\sigma$ blocks (i.e. we went more than $\sigma$ blocks down $H$'s fork from $\mathsf{tailhead}(H)$, then reorged to more than $\sigma$ blocks down $\mathsf{snapshot}(\textsf{final-bft}(H))$'s fork, then reorged again to $H$'s fork). In that case, the finalized ledger would already have the non-conflicting transactions from blocks between $\mathsf{tailhead}(H)$ and $H'$ --- and it could be argued that the correct definition of finality depth in such cases is the depth of $H'$ relative to $H$, not of $\mathsf{tailhead}(H)$ relative to $H$. +Strictly speaking, it is possible that a previous BFT block took a snapshot $H'$ that is between $\mathsf{tailhead}(H)$ and $H$. This can only happen if there have been at least two rollbacks longer than $\sigma$ blocks (i.e. we went more than $\sigma$ blocks down $H$'s fork from $\mathsf{tailhead}(H)$, then reorged to more than $\sigma$ blocks down $\mathsf{snapshot}(\textsf{final-bft}(H))$'s fork, then reorged again to $H$'s fork). In that case, the finalized ledger would already have the non-conflicting transactions from blocks between $\mathsf{tailhead}(H)$ and $H'$ — and it could be argued that the correct definition of finality depth in such cases is the depth of $H'$ relative to $H$, not of $\mathsf{tailhead}(H)$ relative to $H$. However, * The definition above is simpler and easier to compute. @@ -133,12 +132,12 @@ We could alternatively just rely on the fact that some proportion of block produ Specifically, if we accept the above definition of finality depth, then the security property we want is -```admonish success +```admonish success "Definition" **Bounded hazard-freeness** for a finality gap bound of $L$ blocks: There is never, for any node $i$ at time $t$, observed to be a more-available ledger $\mathsf{LOG}_{\mathrm{da},i}^t$ with a hazardous transaction that comes from block $H$ of $\mathsf{ch}_i^t$ such that $\textsf{finality-depth}(H) > L$. ``` ```admonish info -This assumes that transactions in the non-finalized suffix $\mathsf{LOG}_{\mathrm{da},i}^t \setminus \mathsf{LOG}_{\mathrm{fin},i}^t$ come from blocks in $\mathsf{ch}_i^t$. In snap-and-chat they do by definition, but ideally we wouldn't depend on that. The difficulty in finding a more general security definition is due to the ledgers in an ebb-and-flow protocol being specified as sequences of transactions, so that a depth in the ledger would have only a very indirect correspondence to time. We could instead base a definition on timestamps, but that could run into difficulties in ensuring timestamp accuracy. +This assumes that transactions in the non-finalized suffix $\mathsf{LOG}_{\mathrm{da},i}^t \setminus \mathsf{LOG}_{\mathrm{fin},i}^t$ come from blocks in $\mathsf{ch}_i^t$. In Snap‑and‑Chat they do by definition, but ideally we wouldn't depend on that. The difficulty in finding a more general security definition is due to the ledgers in an Ebb‑and‑Flow protocol being specified as sequences of transactions, so that a depth in the ledger would have only a very indirect correspondence to time. We could instead base a definition on timestamps, but that could run into difficulties in ensuring timestamp accuracy. Another possibility would be to count the number of coinbase transactions in $\mathsf{LOG}_{\mathrm{da},i}^t \setminus \mathsf{LOG}_{\mathrm{fin},i}^t$ before the hazardous transaction. This would still be somewhat ad hoc (it depends on the fact that coinbase transactions happen once per block and cannot conflict with any other distinct transaction). @@ -147,7 +146,7 @@ In any case, if $\textsf{finality-depth}$ sometimes overestimates the depth, tha Note that a node that is validating a chain $\mathsf{ch}_i^t$ must fetch all the chains referenced by BFT blocks reachable from it (back to an ancestor that it has seen before). In theory, there could be a partition that causes there to be multiple disjoint snapshots that get added to the BFT chain in quick succession. However, in practice we expect such long rollbacks to be rare if $\Pi_{\mathrm{lc}}$ is meeting its security goals. -Going into Safety Mode if there is a long finalization stall helps to reduce the cost of validation when the stall resolves. That is, if there is a partition and nodes build on several long chains, then in unmodified snap-and-chat, it could be necessary to validate an arbitrary number of transactions on each chain when the stall resolves. Having only coinbase transactions after a certain point in each chain would significantly reduce the concrete validation costs in this situation. +Going into Safety Mode if there is a long finalization stall helps to reduce the cost of validation when the stall resolves. That is, if there is a partition and nodes build on several long chains, then in unmodified Snap‑and‑Chat, it could be necessary to validate an arbitrary number of transactions on each chain when the stall resolves. Having only coinbase transactions after a certain point in each chain would significantly reduce the concrete validation costs in this situation. Nodes should not simply trust that the BFT blocks are correct; they should check validator signatures (or aggregate signatures) and finalization rules. Similarly, $\Pi_{\mathrm{lc}}$ snapshots should not be trusted just because they are referenced by BFT blocks; they should be fully validated, including the proofs-of-work. @@ -171,13 +170,13 @@ Note that if full nodes have access to the BFT chain, knowing $\textsf{final-bft Suppose that the finality gap bound is $L$ blocks. Having already defined $\textsf{finality-depth}$, the necessary $\Pi_{\mathrm{lc}}$ consensus rule is attractively simple: -```admonish success +```admonish success "Consensus rule" For every $\Pi_{\mathrm{lc}}$ block $H$, $\textsf{finality-depth}(H) \leq L$. ``` To adapt this approach to enforce Safety Mode instead of stalling the chain, we can allow the alternative of producing a block that follows the Safety Mode restrictions: -```admonish success +```admonish success "Consensus rule" For every $\Pi_{\mathrm{lc}}$ block $H$, either $\textsf{finality-depth}(H) \leq L$, or $H$ follows the Safety Mode restrictions. ``` diff --git a/src/design/crosslink/potential-changes.md b/src/design/crosslink/potential-changes.md index 8f4fd4d..737aff7 100644 --- a/src/design/crosslink/potential-changes.md +++ b/src/design/crosslink/potential-changes.md @@ -232,7 +232,7 @@ The answer given for this question at [The Crosslink Construction](./constructio This may have been too hasty. It is not clear that merging bc‑block‑producers and bft‑proposers actually does "concentrate security into fewer participants" in a way that can have any harmful effect. -Remember, the job of a bft‑proposer in Crosslink is primarily to snapshot the bc‑best‑chain (even more so if the [Increasing Tip Score rule](./potential-changes.md#Changing-the-Increasing-Score-rule-to-require-the-score-of-the-tip-rather-than-the-score-of-the-snapshot-to-increase) is adopted). An honest miner *by definition* is claiming to build on the best chain, and miners have a strong economic incentive to do so. Therefore, it is entirely reasonable for every newly produced block to be treated as a bft‑proposal. This arguably decentralizes the task of proposing bft‑blocks more effectively than using a leader election protocol would --- especially given that in a hybrid protocol we *necessarily* still rely on there being sufficient honest miners. +Remember, the job of a bft‑proposer in Crosslink is primarily to snapshot the bc‑best‑chain (even more so if the [Increasing Tip Score rule](#changing-the-increasing-score-rule-to-require-the-score-of-the-tip-rather-than-the-score-of-the-snapshot-to-increase) is adopted). An honest miner *by definition* is claiming to build on the best chain, and miners have a strong economic incentive to do so. Therefore, it is entirely reasonable for every newly produced block to be treated as a bft‑proposal. This arguably decentralizes the task of proposing bft‑blocks more effectively than using a leader election protocol would — especially given that in a hybrid protocol we *necessarily* still rely on there being sufficient honest miners. [[DKT2021]](https://arxiv.org/pdf/2010.08154.pdf), for example, argues for the importance of "the complete unpredictability of who will get to propose a block next, even by the winner itself." The main basis of this argument is that it makes subversion of the proposer significantly more difficult. A PoW protocol has that property, and most PoS protocols do not. (It is not that PoS protocols are unable to provide this property; indeed, [[DKT2021]](https://arxiv.org/pdf/2010.08154.pdf) constructs a PoS protocol, "PoSAT", that provides it.) @@ -245,19 +245,19 @@ Considered as a bft‑proposal, a bc‑block needs to refer to a parent bft‑bl ```admonish info collapsible=true title="What are the caveats?" If we are in an execution where **Final Agreement** holds for $\Pi_{\mathrm{bft}}$, then it is possible to show that merging the two fields has no negative effect, *provided* that $\Pi_{\mathrm{origbft}}$ has no additional rules that could disallow it in some cases. -This is because, by **Final Agreement**, $\textsf{bft-last-final}(H'\mathsf{.context_bft}) \preceq\hspace{-0.5em}\succeq_{\mathrm{*bft}} \textsf{bft-last-final}(C)\,$ for any potential bft‑block $C$ that the bc‑block‑producer of a new block $H$ could choose as $H\mathsf{.context\_bft}$. Suppose that the bc‑block‑producer freely chooses $H\mathsf{.parent\_bft}$ according to the desired honest behaviour for a bft‑proposer in $\Pi_{\mathrm{bft}}$, and then chooses $C$ to be the same block (which is always reasonable as long as it is allowed). +This is because, by **Final Agreement**, $\textsf{bft-last-final}(H'\mathsf{.context\_bft}) \preceq\hspace{-0.5em}\succeq_{\mathrm{*bft}} \textsf{bft-last-final}(C)\,$ for any potential bft‑block $C$ that the bc‑block‑producer of a new block $H$ could choose as $H\mathsf{.context\_bft}$. Suppose that the bc‑block‑producer freely chooses $H\mathsf{.parent\_bft}$ according to the desired honest behaviour for a bft‑proposer in $\Pi_{\mathrm{bft}}$, and then chooses $C$ to be the same block (which is always reasonable as long as it is allowed). -In the case $\textsf{bft-last-final}(H'\mathsf{.context_bft}) \preceq_{\mathrm{*bft}} \textsf{bft-last-final}(C)$, we are done, because this choice of $H\mathsf{.context\_bft}$ is allowed by the **Extension rule**. +In the case $\textsf{bft-last-final}(H'\mathsf{.context\_bft}) \preceq_{\mathrm{*bft}} \textsf{bft-last-final}(C)$, we are done, because this choice of $H\mathsf{.context\_bft}$ is allowed by the **Extension rule**. -In the case $\textsf{bft-last-final}(H'\mathsf{.context_bft}) ⪲_{\mathrm{*bft}} \textsf{bft-last-final}(C)$, we can argue that $H'\mathsf{.context\_bft}$ would be a better choice than $C$ for $H\mathsf{.parent\_bft}$ as well as for $H\mathsf{.context\_bft}$, because it has a later final ancestor. This is where the argument might fall down if $\Pi_{\mathrm{origbft}}$ (and therefore $\Pi_{\mathrm{bft}}$) has any additional rules that could disallow this choice. For now let's suppose that situtation does not arise, but it is one of the caveats. +In the case $\textsf{bft-last-final}(H'\mathsf{.context\_bft}) \;⪲_{\mathrm{*bft}}\; \textsf{bft-last-final}(C)$, we can argue that $H'\mathsf{.context\_bft}$ would be a better choice than $C$ for $H\mathsf{.parent\_bft}$ as well as for $H\mathsf{.context\_bft}$, because it has a later final ancestor. This is where the argument might fall down if $\Pi_{\mathrm{origbft}}$ (and therefore $\Pi_{\mathrm{bft}}$) has any additional rules that could disallow this choice. For now let's suppose that situtation does not arise, but it is one of the caveats. -Another potential problem is that in an execution where **Final Agreement** does *not* hold for $\Pi_{\mathrm{bft}}$, we can no longer infer that either $\textsf{bft-last-final}(H'\mathsf{.context\_bft}) \preceq_{\mathrm{*bft}} \textsf{bft-last-final}(C)$ or $\textsf{bft-last-final}(H'\mathsf{.context\_bft}) ⪲_{\mathrm{*bft}} \textsf{bft-last-final}(C)$. In particular it could be the case that the producer of $H'$ was adversarial, and chose $H'\mathsf{.context\_bft}$ in such a way as to favour its own bft‑block that is final in that context. +Another potential problem is that in an execution where **Final Agreement** does *not* hold for $\Pi_{\mathrm{bft}}$, we can no longer infer that either $\textsf{bft-last-final}(H'\mathsf{.context\_bft}) \preceq_{\mathrm{*bft}} \textsf{bft-last-final}(C)$ or $\textsf{bft-last-final}(H'\mathsf{.context\_bft}) \;⪲_{\mathrm{*bft}}\; \textsf{bft-last-final}(C)$. In particular it could be the case that the producer of $H'$ was adversarial, and chose $H'\mathsf{.context\_bft}$ in such a way as to favour its own bft‑block that is final in that context. -However, in that situation it must be possible for the bc‑block‑producer to see (and prove) that the bft‑chain has a final fork. That is, it can produce a witness $C$ to the violation of **Final Agreement**, showing that $\textsf{bft-last-final}(H'\mathsf{.context_bft}) \preceq\hspace{-0.5em}\succeq_{\mathrm{*bft}} \textsf{bft-last-final}(C)\,$ does not hold, as discussed in the section [Recording more info about the bft‑chain in bc‑blocks](./potential-changes.md#Low-risk-Recording-more-info-about-the-bft-chain-in-bc-blocks) above. +However, in that situation it must be possible for the bc‑block‑producer to see (and prove) that the bft‑chain has a final fork. That is, it can produce a witness $C$ to the violation of **Final Agreement**, showing that $\textsf{bft-last-final}(H'\mathsf{.context\_bft}) \preceq\hspace{-0.5em}\succeq_{\mathrm{*bft}} \textsf{bft-last-final}(C)\,$ does not hold, as discussed in the section [Recording more info about the bft‑chain in bc‑blocks](#recommended-recording-more-info-about-the-bftchain-in-bcblocks) above. The second caveat is that in that situation, we still need to set $H\mathsf{.parent\_bft}$ and $H\mathsf{.context\_bft}$ in order to be able to recover, and they typically should not be the same in order to do so. ``` -${}$ + The **Increasing Tip Score rule** is still needed, but it can be simplified. A newly produced bc-block $H$ is also a bft‑proposal such that $\mathsf{snapshot}(H) = H$. This would yield the following bft‑proposal / bc‑block validity rule: > [Candidate rule for discussion] Either $\mathsf{score}(\mathsf{tip}(H\mathsf{.parent\_bft})) < \mathsf{score}(H)$ or $\mathsf{tip}(H\mathsf{.parent\_bft}) = H$. @@ -266,7 +266,7 @@ except that $\mathsf{tip}(H\mathsf{.parent\_bft})$ *cannot* bc‑block $\mathsf{tip}(H\mathsf{.parent\_bft})$, the bc‑block‑producer should instead have built on top of that bc‑block --- which was necessarily known to the producer in order for it to set $H\mathsf{.parent\_bft}$ in the header of the new block. +This works because, if $H$ does not have a higher score than the bc‑block $\mathsf{tip}(H\mathsf{.parent\_bft})$, the bc‑block‑producer should instead have built on top of that bc‑block — which was necessarily known to the producer in order for it to set $H\mathsf{.parent\_bft}$ in the header of the new block. The voting would be the same, performed by the same parties. Therefore, there is no concentration of voting into fewer parties. There is no change in the producer/proposer's incentive to make the bft‑notarization‑proof or its soundness properties. Everything else is roughly the same, including the use of the $\mathsf{context\_bft}$ field of a bc‑block and the validity rules related to it. As far as I can see, all of the security analysis goes through essentially unchanged. @@ -279,7 +279,7 @@ Strictly speaking, whether there is a stake requirement to make a proposal is in In a system that uses PoS, validators by definition need to have stake in order to control the ability to vote. This also allows validators to be slashed. -On the other hand, there is no *technical* reason why the ability to make a bft‑proposal has to be gatekept by a stake requirement --- given the situation of Zcash in which we already have a mining infrastructure, and that in a Snap‑and‑Chat or Crosslink‑style hybrid protocol we necessarily still rely on miners not to censor transactions. The potential to make proposals that are expensive to validate as a denial of service is made sufficiently difficult by proof‑of‑work. This option has probably been underexplored by previous PoS protocols because they cannot assume an existing mining infrastructure. +On the other hand, there is no *technical* reason why the ability to make a bft‑proposal has to be gatekept by a stake requirement — given the situation of Zcash in which we already have a mining infrastructure, and that in a Snap‑and‑Chat or Crosslink‑style hybrid protocol we necessarily still rely on miners not to censor transactions. The potential to make proposals that are expensive to validate as a denial of service is made sufficiently difficult by proof‑of‑work. This option has probably been underexplored by previous PoS protocols because they cannot assume an existing mining infrastructure. ``` It could be argued that this approach goes less far toward a pure PoS‑based blockchain protocol, leaving more to be done in the second stage. However, there is a clear route to that second stage, by replacing PoW with a protocol like PoSAT that has full unpredictabilty and dynamic availability. PoSAT does this using a VDF, and as it happens, Halo 2 is a strong candidate to be used to construct such a VDF. @@ -292,13 +292,13 @@ Building on the previous idea, we can try to eliminate the explicit bft‑chain This left the concept of a bft‑block intact. Recall that in baseline Crosslink, a bft‑block $B$ consists of $(P, \mathsf{proof}_P)$ signed by the proposer. So in "Crosslink with proposer = producer", a bft‑block consists of $(H, \mathsf{proof}_H)$ signed by the producer. -What if a bc‑block $H$ were to "inline" its parent and context bft‑blocks rather than referring to them? I.e. a bc‑block $H$ with $H\mathsf{.parent\_bft}$ *referring to* $(H', \mathsf{proof}_{H'})$ signed for $H'\mathsf{.pubkey}$, would instead *literally include* (either in the header or the coinbase transaction) $(H', \mathsf{proof}_{H'})$ signed for $H'\mathsf{.pubkey}$ --- and similarly for $H\mathsf{.context\_bft}$. +What if a bc‑block $H$ were to "inline" its parent and context bft‑blocks rather than referring to them? I.e. a bc‑block $H$ with $H\mathsf{.parent\_bft}$ *referring to* $(H', \mathsf{proof}_{H'})$ signed for $H'\mathsf{.pubkey}$, would instead *literally include* (either in the header or the coinbase transaction) $(H', \mathsf{proof}_{H'})$ signed for $H'\mathsf{.pubkey}$ — and similarly for $H\mathsf{.context\_bft}$. It would still be necessary to have the message type that the proposer/producer previously used to submit a notarized bft‑block. (It cannot be merged with a bc‑block announcement: the producer of a new block is not in general the producer of its parent, and their incentives may differ; also we cannot wait until a new block is found before publishing the previous notarization.) It would also still be necessary for Crosslink nodes to keep track of notarizations that have not made it into any bc‑block. Nevertheless, this is a potential simplification. -Note that unless notarization proofs are particularly short and constant-length, it would not be appropriate to include them in the bc‑block headers, and so they would have to go into the coinbase transaction or another similar variable-length data structure. In that case we would still have an indirection to obtain the bft‑block information; it would just be merged with the indirection to obtain a coinbase transaction (or similar) --- which is already needed in order to check validity of the bc‑block. +Note that unless notarization proofs are particularly short and constant-length, it would not be appropriate to include them in the bc‑block headers, and so they would have to go into the coinbase transaction or another similar variable-length data structure. In that case we would still have an indirection to obtain the bft‑block information; it would just be merged with the indirection to obtain a coinbase transaction (or similar) — which is already needed in order to check validity of the bc‑block. -As discussed under "[Recording more info about the bft‑chain in bc‑blocks](#Low-risk-Recording-more-info-about-the-bft-chain-in-bc-blocks)" above, we might in any case want to record information about other proposed and notarized bft‑blocks, and the data structure needed for this would necessarily be variable-length. The complexity burden of doing so would be shared between these two changes. +As discussed under "[Recording more info about the bft‑chain in bc‑blocks](#recommended-recording-more-info-about-the-bftchain-in-bcblocks)" above, we might in any case want to record information about other proposed and notarized bft‑blocks, and the data structure needed for this would necessarily be variable-length. The complexity burden of doing so would be shared between these two changes. It would be possible to save some space in headers (while keeping them fixed-length), by inlining only one of $H\mathsf{.parent\_bft}$ and $H\mathsf{.context\_bft}$ in the header and keeping the other as a hash. As discussed under "What are the caveats?" above, the only reason for the two bft‑blocks referred to by these fields to be different, is that the bc‑block producer has observed a violation of **Final Agreement** in $\Pi_{\mathrm{bft}}$. In that case, we can include an inlining of the other $H\mathsf{.*\_bft}$ block, and any other information needed to prove that a violation of **Final Agreement** has occurred, in a variable-length overflow structure. diff --git a/src/design/crosslink/questions.md b/src/design/crosslink/questions.md index c8e6c3c..c0bdaa4 100644 --- a/src/design/crosslink/questions.md +++ b/src/design/crosslink/questions.md @@ -35,7 +35,7 @@ All that said, does the suggested rule help? First we have to ask whether it int * This does not mean that a break of $\Pi_{\mathrm{bft}}$ is not a problem for Crosslink. In particular, an adversary that can violate safety of $\Pi_{\mathrm{bft}}$ can violate safety of $\mathsf{LOG}_{\mathrm{bda}}$ (and of $\mathsf{LOG}_{\mathrm{fin}}$ if there is also a $\sigma$-block rollback in some node's bc-best-chain). * The difference is that a safety violation of $\Pi_{\mathrm{bft}}$ can be directly observed by nodes *without any chance of false positives*, which is not necessarily the case for all possible attacks against $\Pi_{\mathrm{bft}}$. (The attack described above does *not* violate safety of $\Pi_{\mathrm{bft}}$; it just adds a final bft-block with a suspiciously long $\Pi_{\mathrm{bc}}$ rollback. It could alternatively have added a block with a less suspiciously long rollback, say exactly $\sigma + 1$ blocks. That is, in pursuit of preventing an attack against $\Pi_{\mathrm{bc}}$, we have enabled attacks against $\Pi_{\mathrm{bft}}$ to achieve the same effect --- precisely what Crosslink is designed to prevent.) * This raises an interesting idea: if any node sees a rollback in the chain of final bft-blocks, it could provide objective evidence of that rollback in the form of a "bft-final-vee": two final bft-blocks with the same parent. Similarly, if any node sees more than one third of stake vote for conflicting blocks in a given epoch, then the assumption bounding the adversary's stake must have been violated. This evidence can be posted in a transaction to the bc-chain. In that case, any node that is synced to the bc-chain can see that the bft-chain suffered a violation of safety or of a safety assumption, without needing to have seen that violation itself. This can be generalized to allow other proofs of flaws in $\Pi_{\mathrm{bft}}$. Optionally, a bc-chain that has posted such a proof could be latched into Safety Mode until manual intervention can occur. (Obviously we need to make sure that this cannot be abused for denial-of-service.) - * This is now described in [Potential changes to Crosslink](./potential-changes.md#Low-risk-Recording-more-info-about-the-bft-chain-in-bc-blocks). + * This is now described in [Potential changes to Crosslink](./potential-changes.md#recommended-recording-more-info-about-the-bftchain-in-bcblocks). **Okay, but is it a good idea to make that change to the fork-choice rule anyway?** @@ -45,7 +45,7 @@ The change was that the bc-best-chain for a node $i$ would be required to extend From the point of view of any modular analysis that treats $\Pi_{\mathsf{bft}}$ as potentially subverted, we cannot say anything useful about $\mathsf{snapshot}(B)$. It seems as though any repair would have to assume much more about the BFT protocol than is desirable. -In general, changes to fork-choice rules are tricky; it was a fork-choice rule problem that allowed the liveness attack against Casper FFG described in [[NTT2021](https://arxiv.org/pdf/2009.04987.pdf), Appendix E]. +In general, changes to fork-choice rules are tricky; it was a fork-choice rule problem that allowed the liveness attack against Casper FFG described in [[NTT2020](https://eprint.iacr.org/2020/1091.pdf), Appendix E]. **What if validators who see that a long rollback occurred, refuse to vote for it?** diff --git a/src/design/crosslink/security-analysis.md b/src/design/crosslink/security-analysis.md index 8f47386..05faa7c 100644 --- a/src/design/crosslink/security-analysis.md +++ b/src/design/crosslink/security-analysis.md @@ -63,20 +63,20 @@ So what is the strongest security property we can realistically get? It is stron ### Proof of safety for LOGfin -In order to capture the intuition that it is hard in practice to cause a consistent partition of the kind described in the previous section, we will need to assume that the [**Prefix Agreement**](./construction.md#Safety-of-Pi_mathrmbc) safety property holds for the relevant executions of $\Pi_{\mathrm{bc}}$. The structural and consensus modifications to $\Pi_{\mathrm{bc}}$ relative to $\Pi_{\mathrm{origbc}}$ seem unlikely to have any significant effect on this property, given that we proved above that they do not affect liveness. ==TODO: that is a handwave; we should be able to do better, as we do for $\Pi_{\mathrm{bft}}$ below.== So, to the extent that it is reasonable to assume that **Prefix Agreement** holds for executions of $\Pi_{\mathrm{origbc}}$ under some conditions, it should also be reasonable to assume it holds for executions of $\Pi_{\mathrm{bc}}$ under the same conditions. +In order to capture the intuition that it is hard in practice to cause a consistent partition of the kind described in the previous section, we will need to assume that the [**Prefix Agreement**](./construction.md#admonition-definition-prefix-agreement) safety property holds for the relevant executions of $\Pi_{\mathrm{bc}}$. The structural and consensus modifications to $\Pi_{\mathrm{bc}}$ relative to $\Pi_{\mathrm{origbc}}$ seem unlikely to have any significant effect on this property, given that we proved above that they do not affect liveness. ==TODO: that is a handwave; we should be able to do better, as we do for $\Pi_{\mathrm{bft}}$ below.== So, to the extent that it is reasonable to assume that [**Prefix Agreement**](./construction.md#admonition-definition-prefix-agreement) holds for executions of $\Pi_{\mathrm{origbc}}$ under some conditions, it should also be reasonable to assume it holds for executions of $\Pi_{\mathrm{bc}}$ under the same conditions. Recall that $\mathsf{LF}(H) := \textsf{bft-last-final}(H\mathsf{.context\_bft})$. -```admonish success -**Prefix Lemma:** If $H_1$, $H_2$ are bc‑valid blocks with $H_1 \preceq_{\mathrm{bc}} H_2$, then $\mathsf{LF}(H_1) \preceq_{\mathrm{bft}} \mathsf{LF}(H_2)$. +```admonish success "Prefix Lemma" +If $H_1$, $H_2$ are bc‑valid blocks with $H_1 \preceq_{\mathrm{bc}} H_2$, then $\mathsf{LF}(H_1) \preceq_{\mathrm{bft}} \mathsf{LF}(H_2)$. Proof: Using the **Extension rule**, by induction on the distance between $H_1$ and $H_2$. ``` -Using this lemma (once for each direction) we can transfer the [**Prefix Agreement**](./construction.md#Safety-of-Pi_mathrmbc) property to the referenced bft‑blocks: +Using the **Prefix Lemma** once for each direction, we can transfer the [**Prefix Agreement**](./construction.md#admonition-definition-prefix-agreement) property to the referenced bft‑blocks: -```admonish success -**Prefix Agreement Lemma:** In an execution of $\Pi_{\mathrm{bc}}$ that has **Prefix Agreement** at confirmation depth $\sigma$, for all times $t$, $t'$ and all nodes $i$, $j$ (potentially the same) such that $i$ is honest at time $t$ and $j$ is honest at time $t'$, we have $\mathsf{LF}(\mathsf{ch}_i^t \lceil_{\mathrm{bc}}^\sigma) \preceq\hspace{-0.5em}\succeq_{\mathrm{bft}} \mathsf{LF}(\mathsf{ch}_j^{t'} \lceil_{\mathrm{bc}}^\sigma)$. +```admonish success "Prefix Agreement Lemma" +In an execution of $\Pi_{\mathrm{bc}}$ that has [**Prefix Agreement**](./construction.md#admonition-definition-prefix-agreement) at confirmation depth $\sigma$, for all times $t$, $t'$ and all nodes $i$, $j$ (potentially the same) such that $i$ is honest at time $t$ and $j$ is honest at time $t'$, we have $\mathsf{LF}(\mathsf{ch}_i^t \lceil_{\mathrm{bc}}^\sigma) \preceq\hspace{-0.5em}\succeq_{\mathrm{bft}} \mathsf{LF}(\mathsf{ch}_j^{t'} \lceil_{\mathrm{bc}}^\sigma)$. ``` (The notation $B \preceq\hspace{-0.5em}\succeq_{\mathrm{*}} C$ means that either $B \preceq_{\mathrm{*}} C$ or $C \preceq_{\mathrm{*}} B$. That is, "one of $B$ and $C$ is a prefix of the other".) @@ -97,36 +97,36 @@ $$ Because $\mathsf{fin}$ takes the form $\mathsf{fin}(H) := [f(X) \text{ for } X \preceq_{\mathrm{bft}} g(H)]$, we have that $g(H) \preceq_{\mathrm{bft}} g(H') \implies \mathsf{fin}(H) \preceq \mathsf{fin}(H')$. (This would be true for any well‑typed $f$ and $g$.) -By this observation and the **Prefix Agreement Lemma**, we also have that, in an execution of Crosslink where $\Pi_{\mathrm{bc}}$ has the **Prefix Agreement** safety property at confirmation depth $\sigma$, for all times $t$, $t'$ and all nodes $i$, $j$ (potentially the same) such that $i$ is honest at time $t$ and $j$ is honest at time $t'$, $\mathsf{fin}(\mathsf{ch}_i^t) \preceq\hspace{-0.5em}\succeq \mathsf{fin}(\mathsf{ch}_j^{t'})$. +By this observation and the **Prefix Agreement Lemma**, we also have that, in an execution of Crosslink where $\Pi_{\mathrm{bc}}$ has the [**Prefix Agreement**](./construction.md#admonition-definition-prefix-agreement) safety property at confirmation depth $\sigma$, for all times $t$, $t'$ and all nodes $i$, $j$ (potentially the same) such that $i$ is honest at time $t$ and $j$ is honest at time $t'$, $\mathsf{fin}(\mathsf{ch}_i^t) \preceq\hspace{-0.5em}\succeq \mathsf{fin}(\mathsf{ch}_j^{t'})$. Because $\mathsf{sanitize}$ only considers previous state, $\textsf{context-txns}$ ∘ $\textsf{san-ctx}$ must be a prefix-preserving map; that is, if $S_1 \preceq S_2$ then $\textsf{context-txns}(\textsf{san-ctx}(S_1)) \preceq \textsf{context-txns}(\textsf{san-ctx}(S_2))$. Therefore: -```admonish success -**LOGfin Safety theorem (from Prefix Agreement of Πbc):** In an execution of Crosslink where $\Pi_{\mathrm{bc}}$ has **Prefix Agreement** at confirmation depth $\sigma$, for all times $t$, $t'$ and all nodes $i$, $j$ (potentially the same) such that $i$ is honest at time $t$ and $j$ is honest at time $t'$, $\mathsf{LOG}_{\mathrm{fin},i}^t \preceq\hspace{-0.5em}\succeq \mathsf{LOG}_{\mathrm{fin},j}^{t'}\,$. +```admonish success "Theorem: LOGfin Safety (from Prefix Agreement of Πbc)" +In an execution of Crosslink where $\Pi_{\mathrm{bc}}$ has [**Prefix Agreement**](./construction.md#admonition-definition-prefix-agreement) at confirmation depth $\sigma$, for all times $t$, $t'$ and all nodes $i$, $j$ (potentially the same) such that $i$ is honest at time $t$ and $j$ is honest at time $t'$, $\mathsf{LOG}_{\mathrm{fin},i}^t \preceq\hspace{-0.5em}\succeq \mathsf{LOG}_{\mathrm{fin},j}^{t'}\,$. ``` Notice that this does not depend on any safety property of $\Pi_{\mathrm{bft}}$, and is an elementary proof. ([[NTT2020](https://eprint.iacr.org/2020/1091.pdf), Theorem 2] is a much more complicated proof that takes nearly 3 pages, not counting the reliance on results from [[PS2017]](https://eprint.iacr.org/2016/918.pdf).) -*In addition,* just as in Snap‑and‑Chat, safety of $\mathsf{LOG}_{\mathrm{fin}}$ can be inferred from safety of $\Pi_{\mathrm{bft}}$, which follows from safety of $\Pi_{\mathrm{origbft}}$. We prove this based on the [**Final Agreement**](./construction.md#Safety-of-Pi_mathrmbft) property for executions of $\Pi_{\mathrm{origbft}}$: +*In addition,* just as in Snap‑and‑Chat, safety of $\mathsf{LOG}_{\mathrm{fin}}$ can be inferred from safety of $\Pi_{\mathrm{bft}}$, which follows from safety of $\Pi_{\mathrm{origbft}}$. We prove this based on the [**Final Agreement**](./construction.md#admonition-definition-final-agreement) property for executions of $\Pi_{\mathrm{origbft}}$: -```admonish success -An execution of $\Pi_{\mathrm{origbft}}$ has the **Final Agreement** safety property iff for all origbft‑valid blocks $C$ in honest view at time $t$ and $C'$ in honest view at time $t'$, we have $\textsf{origbft-last-final}(C) \preceq\hspace{-0.5em}\succeq_{\mathrm{origbft}} \textsf{origbft-last-final}(C')\,$. +```admonish success "Definition: Final Agreement" +An execution of $\Pi_{\mathrm{origbft}}$ has the [**Final Agreement**](./construction.md#admonition-definition-final-agreement) safety property iff for all origbft‑valid blocks $C$ in honest view at time $t$ and $C'$ in honest view at time $t'$, we have $\textsf{origbft-last-final}(C) \preceq\hspace{-0.5em}\succeq_{\mathrm{origbft}} \textsf{origbft-last-final}(C')\,$. ``` -The changes in $\Pi_{\mathrm{bft}}$ relative to $\Pi_{\mathrm{origbft}}$ only add structural components and tighten bft‑block‑validity and bft‑proposal‑validity rules. So for any legal execution of $\Pi_{\mathrm{bft}}$ there is a corresponding legal execution of $\Pi_{\mathrm{origbft}}$, with the structural additions erased and with the same nodes honest at any given time. A safety property, by definition, only asserts that executions not satisfying the property do not occur. Safety properties of $\Pi_{\mathrm{origbft}}$ necessarily do not refer to the added structural components in $\Pi_{\mathrm{bft}}$. Therefore, for any safety property of $\Pi_{\mathrm{origbft}}$, including **Final Agreement**, the corresponding safety property holds for $\Pi_{\mathrm{bft}}$. +The changes in $\Pi_{\mathrm{bft}}$ relative to $\Pi_{\mathrm{origbft}}$ only add structural components and tighten bft‑block‑validity and bft‑proposal‑validity rules. So for any legal execution of $\Pi_{\mathrm{bft}}$ there is a corresponding legal execution of $\Pi_{\mathrm{origbft}}$, with the structural additions erased and with the same nodes honest at any given time. A safety property, by definition, only asserts that executions not satisfying the property do not occur. Safety properties of $\Pi_{\mathrm{origbft}}$ necessarily do not refer to the added structural components in $\Pi_{\mathrm{bft}}$. Therefore, for any safety property of $\Pi_{\mathrm{origbft}}$, including [**Final Agreement**](./construction.md#admonition-definition-final-agreement), the corresponding safety property holds for $\Pi_{\mathrm{bft}}$. -By the definition of $\mathsf{fin}$ as above, in an execution of Crosslink where $\Pi_{\mathrm{bft}}$ has [**Final Agreement**](./construction.md#Safety-of-Pi_mathrmbft), for all times $t$, $t'$ and all nodes $i$, $j$ (potentially the same) such that $i$ is honest at time $t$ and $j$ is honest at time $t'$, $\mathsf{fin}(\mathsf{ch}_i^t) \preceq\hspace{-0.5em}\succeq \mathsf{fin}(\mathsf{ch}_j^{t'})\,$. Therefore, by an argument similar to the one above using the fact that $\textsf{context-txns}$ ∘ $\textsf{san-ctx}$ is a prefix-preserving map: +By the definition of $\mathsf{fin}$ as above, in an execution of Crosslink where $\Pi_{\mathrm{bft}}$ has [**Final Agreement**](./construction.md#admonition-definition-final-agreement), for all times $t$, $t'$ and all nodes $i$, $j$ (potentially the same) such that $i$ is honest at time $t$ and $j$ is honest at time $t'$, $\mathsf{fin}(\mathsf{ch}_i^t) \preceq\hspace{-0.5em}\succeq \mathsf{fin}(\mathsf{ch}_j^{t'})\,$. Therefore, by an argument similar to the one above using the fact that $\textsf{context-txns}$ ∘ $\textsf{san-ctx}$ is a prefix-preserving map: -```admonish success -**LOGfin Safety theorem (from Final Agreement of Πbft or Πorigbft):** In an execution of Crosslink where $\Pi_{\mathrm{bft}}$ has **Final Agreement**, for all times $t$, $t'$ and all nodes $i$, $j$ (potentially the same) such that $i$ is honest at time $t$ and $j$ is honest at time $t'$, $\mathsf{LOG}_{\mathrm{fin},i}^t \preceq\hspace{-0.5em}\succeq \mathsf{LOG}_{\mathrm{fin},j}^{t'}\,$. +```admonish success "Theorem: LOGfin Safety (from Final Agreement of Πbft or Πorigbft)" +In an execution of Crosslink where $\Pi_{\mathrm{bft}}$ has [**Final Agreement**](./construction.md#admonition-definition-final-agreement), for all times $t$, $t'$ and all nodes $i$, $j$ (potentially the same) such that $i$ is honest at time $t$ and $j$ is honest at time $t'$, $\mathsf{LOG}_{\mathrm{fin},i}^t \preceq\hspace{-0.5em}\succeq \mathsf{LOG}_{\mathrm{fin},j}^{t'}\,$. ``` ### Proof of safety for LOGbda -From the two $\mathsf{LOG}_{\mathrm{fin}}$ Safety theorems and the [Ledger prefix property](#Definitions-of-LOGtfini-and-LOGtbdai%CE%BC), we immediately have: +From the two $\mathsf{LOG}_{\mathrm{fin}}$ Safety theorems and the [**Ledger prefix property**](./construction.md#admonition-theorem-ledger-prefix-property), we immediately have: -```admonish success -**LOGbda does not roll back past the agreed LOGfin:** Let $\mu_i$ be an arbitrary choice of $\mathsf{LOG}_{\mathrm{bda}}$ confirmation depth for each node $i$. Consider an execution of Crosslink where either $\Pi_{\mathrm{bc}}$ has **Prefix Agreement** at confirmation depth $\sigma$ or $\Pi_{\mathrm{bft}}$ has **Final Agreement**. +```admonish success "Theorem: LOGbda does not roll back past the agreed LOGfin" +Let $\mu_i$ be an arbitrary choice of $\mathsf{LOG}_{\mathrm{bda}}$ confirmation depth for each node $i$. Consider an execution of Crosslink where either $\Pi_{\mathrm{bc}}$ has [**Prefix Agreement**](./construction.md#admonition-definition-prefix-agreement) at confirmation depth $\sigma$ or $\Pi_{\mathrm{bft}}$ has [**Final Agreement**](./construction.md#admonition-definition-final-agreement). In such an execution, for all times $t$, $t'$ and all nodes $i$, $j$ (potentially the same) such that $i$ is honest at time $t$ and $j$ is honest at time $t'$, either $\mathsf{LOG}_{\mathrm{fin},i}^t \preceq_{\mathrm{bc}} \mathsf{LOG}_{\mathrm{fin},j}^{t'} \preceq_{\mathrm{bc}} \mathsf{LOG}_{\mathrm{bda},j,\mu_j}^{t'}$ or $\mathsf{LOG}_{\mathrm{fin},j}^{t'} \preceq_{\mathrm{bc}} \mathsf{LOG}_{\mathrm{fin},i}^t \preceq_{\mathrm{bc}} \mathsf{LOG}_{\mathrm{bda},i,\mu_i}^t$. @@ -135,7 +135,7 @@ In such an execution, for all times $t$, $t'$< The above property is not as strong as we would like for practical uses of $\mathsf{LOG}_{\mathrm{bda}}$, because it does not say anything about rollbacks up to the finalization point, and such rollbacks may be of unbounded length. (Loosely speaking, the number of non-Safety Mode bc‑blocks after the consensus finalization point is bounded by $L$, but we have also not proven that so far.) -As documented in the [Model for BFT protocols](./construction.md#Model-for-BFT-protocols-%CE%A0origbftbft) section of [The Crosslink Construction](./construction.md)): +As documented in the [Model for BFT protocols](./construction.md#model-for-bft-protocols-Πorigbftbft) section of [The Crosslink Construction](./construction.md)): > For each epoch, there is a fixed number of voting units distributed between the players, which they use to vote for a $\mathrm{*}$bft‑proposal. If, and only if, the votes cast for a $\mathrm{*}$bft‑proposal $P$ satisfy a notarization rule, then it is possible to obtain a valid $\mathrm{*}$bft‑notarization-proof $\mathsf{proof}_P$. The notarization rule must require at least a two-thirds absolute supermajority of voting units to have been cast for $P$. (It may also require other conditions.) > @@ -148,9 +148,11 @@ As documented in the [Model for BFT protocols](./construction.md#Model-for-BFT-p > An execution of $\Pi_{\mathrm{bft}}$ has the **one‑third bound on non‑honest voting** property if at any epoch in the execution, strictly fewer than one third of the total voting units for that epoch are cast non‑honestly. > ``` +```admonish success "Theorem: On bft‑valid blocks for a given epoch in honest view" By a well known argument often used to prove safety of BFT protocols, in an execution of Crosslink where $\Pi_{\mathrm{bft}}$ has the **one‑third bound on non‑honest voting** property (and assuming soundness of notarization proofs), any bft‑valid block for a given epoch in honest view must commit to the same proposal. Proof (adapted from [[CS2020](https://eprint.iacr.org/2020/088.pdf), Lemma 1]): Suppose there are two bft‑proposals $P$ and $P'$, both for epoch $e$, such that $P$ is committed to by some bft‑block‑valid block $B$, and $P'$ is committed to by some bft‑block‑valid block $B'$. This implies that $B$ and $B'$ have valid notarization proofs. Let the number of voting units for epoch $e$ be $n_e$. Assuming soundness of the notarization proofs, it must be that at least $2n_e/3$ voting units for epoch $e$, denoted as the set $S$, were cast for $P$, and at least $2n_e/3$ voting units for epoch $e$, denoted as the set $S'$, were cast for $P'$. Since there are $n_e$ voting units for epoch $e$, $S \cap S'$ must have size at least $n_e/3$. In an execution of Crosslink where $\Pi_{\mathrm{bft}}$ has the **one‑third bound on non‑honest voting** property, $S \cap S'$ must therefore include at least one voting unit that was cast honestly. Since a voting unit for epoch $e$ that is cast honestly is not double-cast, it must be that $P = P'$. +``` ```admonish info In the case of a network partition, votes may not be seen on both/all sides of the partition. Therefore, it is not necessarily the case that honest nodes can directly see double‑voting. The above argument does not depend on being able to do so. @@ -167,10 +169,10 @@ Let $H$ be any bc‑valid block. We have by definition: $$ \end{array} $$ So, taking $C = H \lceil_{\mathrm{bc}}^\sigma\mathsf{.context\_bft}$, each $\mathsf{snapshot}(B)$ for $B$ of epoch $e$ in the result of $\mathsf{fin}(H)$ satisfies $\mathsf{snapshot}(B) \preceq_{\mathrm{bc}} \mathsf{ch}_i^{t_{e,i}} \lceil_{\mathrm{bc}}^\sigma$ for all $i$ in some nonempty honest set of nodes $\mathcal{I}_e$. -For an execution of Crosslink in which $\Pi_{\mathrm{bc}}$ has the **Prefix Consistency** property at confirmation depth $\sigma$, for every epoch $e$, for every such $(i, t_{e,i})$, for every node $j$ that is honest at any time $t' \geq t_{e,i}$, we have $\mathsf{ch}_i^{t_{e,i}} \lceil_{\mathrm{bc}}^\sigma \preceq_{\mathrm{bc}} \mathsf{ch}_j^{t'}$. Let $t_e = \min \{ t_{e,i} : i \in \mathcal{I}_e \}$. Then, by transitivity of $\preceq_{\mathrm{bc}}$: +For an execution of Crosslink in which $\Pi_{\mathrm{bc}}$ has the [**Prefix Consistency**](./construction.md#admonition-definition-prefix-consistency) property at confirmation depth $\sigma$, for every epoch $e$, for every such $(i, t_{e,i})$, for every node $j$ that is honest at any time $t' \geq t_{e,i}$, we have $\mathsf{ch}_i^{t_{e,i}} \lceil_{\mathrm{bc}}^\sigma \preceq_{\mathrm{bc}} \mathsf{ch}_j^{t'}$. Let $t_e = \min \{ t_{e,i} : i \in \mathcal{I}_e \}$. Then, by transitivity of $\preceq_{\mathrm{bc}}$: -```admonish success -In an execution of Crosslink where $\Pi_{\mathrm{bft}}$ has the **one‑third bound on non‑honest voting** property and $\Pi_{\mathrm{bc}}$ has the **Prefix Consistency** property at confirmation depth $\sigma$, every bc‑chain $\mathsf{snapshot}(B)$ in $\mathsf{fin}(\mathsf{ch}_i^t)$ (and therefore every snapshot that contributes to $\mathsf{LOG}_{\mathrm{fin},i}^t$) is, at any time $t' \geq t_e$, in the bc‑best‑chain of every node $j$ that is honest at time $t'$ (where $B$ commits to $P_e$ at epoch $e$ and $t_e$ is the time of the first honest vote for $P_e$). +```admonish success "Theorem: On snapshots in LOGfin" +In an execution of Crosslink where $\Pi_{\mathrm{bft}}$ has the **one‑third bound on non‑honest voting** property and $\Pi_{\mathrm{bc}}$ has the [**Prefix Consistency**](./construction.md#admonition-definition-prefix-consistency) property at confirmation depth $\sigma$, every bc‑chain $\mathsf{snapshot}(B)$ in $\mathsf{fin}(\mathsf{ch}_i^t)$ (and therefore every snapshot that contributes to $\mathsf{LOG}_{\mathrm{fin},i}^t$) is, at any time $t' \geq t_e$, in the bc‑best‑chain of every node $j$ that is honest at time $t'$ (where $B$ commits to $P_e$ at epoch $e$ and $t_e$ is the time of the first honest vote for $P_e$). ``` A similar (weaker) statement holds if we replace $t' \geq t_e$ with $t' \geq t$, since the time of the first honest vote for $P$ necessarily precedes the time at which the signed $(P, \mathsf{proof}_P)$ is submitted as a bft‑block, which necessarily precedes $t$. (Whether or not the notarization proof depends on the *first* honest vote for $B$'s proposal $P_e$, it must depend on some honest vote for that proposal that was not made earlier than $t_e$.) @@ -182,17 +184,17 @@ Furthermore, we have $$ \end{array} $$ -So in an execution of Crosslink where $\Pi_{\mathrm{bc}}$ has the **Prefix Consistency** property at confirmation depth $\mu$, if node $i$ is honest at time $t$ then $H \lceil_{\mathrm{bc}}^\mu$ is also, at any time $t' \geq t$, in the bc‑best‑chain of every node $j$ that is honest at time $t'$. +So in an execution of Crosslink where $\Pi_{\mathrm{bc}}$ has the [**Prefix Consistency**](./construction.md#admonition-definition-prefix-consistency) property at confirmation depth $\mu$, if node $i$ is honest at time $t$ then $H \lceil_{\mathrm{bc}}^\mu$ is also, at any time $t' \geq t$, in the bc‑best‑chain of every node $j$ that is honest at time $t'$. -If an execution of $\Pi_{\mathrm{bc}}$ has the **Prefix Consistency** property at confirmation depth $\mu \leq \sigma$, then it necessarily also has it at confirmation depth $\sigma$. Therefore we have: +If an execution of $\Pi_{\mathrm{bc}}$ has the [**Prefix Consistency**](./construction.md#admonition-definition-prefix-consistency) property at confirmation depth $\mu \leq \sigma$, then it necessarily also has it at confirmation depth $\sigma$. Therefore we have: -```admonish success -In an execution of Crosslink where $\Pi_{\mathrm{bft}}$ has the **one‑third bound on non‑honest voting** property and $\Pi_{\mathrm{bc}}$ has the **Prefix Consistency** property at confirmation depth $\mu \leq \sigma$, every bc‑chain snapshot in $\mathsf{fin}(\mathsf{ch}_i^t) \,||\, [\mathsf{ch}_i^t \lceil_{\mathrm{bc}}^\mu]$ (and therefore every snapshot that contributes to $\mathsf{LOG}_{\mathrm{bda},i,\mu}^t$) is, at any time $t' \geq t$, in the bc‑best‑chain of every node $j$ that is honest at time $t'$. +```admonish success "Theorem: On snapshots in LOGbda" +In an execution of Crosslink where $\Pi_{\mathrm{bft}}$ has the **one‑third bound on non‑honest voting** property and $\Pi_{\mathrm{bc}}$ has the [**Prefix Consistency**](./construction.md#admonition-definition-prefix-consistency) property at confirmation depth $\mu \leq \sigma$, every bc‑chain snapshot in $\mathsf{fin}(\mathsf{ch}_i^t) \,||\, [\mathsf{ch}_i^t \lceil_{\mathrm{bc}}^\mu]$ (and therefore every snapshot that contributes to $\mathsf{LOG}_{\mathrm{bda},i,\mu}^t$) is, at any time $t' \geq t$, in the bc‑best‑chain of every node $j$ that is honest at time $t'$. ``` Sketch: we also need the sequence of snapshots output from fin to only be extended in the view of any node. In that case we can infer that the node does not observe a rollback in LOG_bda. -Recall that in the proof of safety for $\mathsf{LOG}_{\mathrm{fin}}$, we showed that in an execution of Crosslink where $\Pi_{\mathrm{bft}}$ (or $\Pi_{\mathrm{origbft}}$) has [**Final Agreement**](./construction.md#Safety-of-Pi_mathrmbft), for all times $t$, $t'$ and all nodes $i$, $j$ (potentially the same) such that $i$ is honest at time $t$ and $j$ is honest at time $t'$, $\mathsf{fin}(\mathsf{ch}_i^t) \preceq\hspace{-0.5em}\succeq \mathsf{fin}(\mathsf{ch}_j^{t'})\,$. +Recall that in the proof of safety for $\mathsf{LOG}_{\mathrm{fin}}$, we showed that in an execution of Crosslink where $\Pi_{\mathrm{bft}}$ (or $\Pi_{\mathrm{origbft}}$) has [**Final Agreement**](./construction.md#admonition-definition-final-agreement), for all times $t$, $t'$ and all nodes $i$, $j$ (potentially the same) such that $i$ is honest at time $t$ and $j$ is honest at time $t'$, $\mathsf{fin}(\mathsf{ch}_i^t) \preceq\hspace{-0.5em}\succeq \mathsf{fin}(\mathsf{ch}_j^{t'})\,$. What we want to show is that, under some conditions on executions, ... diff --git a/src/design/crosslink/the-arguments-for-bounded-dynamic-availability-and-finality-overrides.md b/src/design/crosslink/the-arguments-for-bounded-dynamic-availability-and-finality-overrides.md index bd85ec0..a88075b 100644 --- a/src/design/crosslink/the-arguments-for-bounded-dynamic-availability-and-finality-overrides.md +++ b/src/design/crosslink/the-arguments-for-bounded-dynamic-availability-and-finality-overrides.md @@ -1,30 +1,30 @@ # The Arguments for Bounded Dynamic Availability and Finality Overrides -This document considers disadvantages of allowing transactions to continue to be included at the chain tip while the gap from the last finalized block becomes unbounded, and what I think should be done instead. This condition is allowed by ebb-and-flow protocols [[NTT2021]](https://arxiv.org/pdf/2009.04987.pdf). +This document considers disadvantages of allowing transactions to continue to be included at the chain tip while the gap from the last finalized block becomes unbounded, and what I think should be done instead. This condition is allowed by Ebb‑and‑Flow protocols [[NTT2020]](https://eprint.iacr.org/2020/1091.pdf). I also argue that it is necessary to allow for the possibility of overriding finalization in order to respond to certain attacks, and that this should be explicitly modelled and subject to a well-defined governance process. -This is a rewritten version of [this forum post](https://forum.zcashcommunity.com/t/the-trailing-finality-layer/45133/10), adapting the main argument to take into account the discussion of "tail-thrashing attacks" and finalization availability from the Addendum. More details of how bounded dynamic availability could be implemented in the context of a snap-and-chat protocol are in [Notes on Snap-and-Chat](./notes-on-snap-and-chat.md). +This is a rewritten version of [this forum post](https://forum.zcashcommunity.com/t/the-trailing-finality-layer/45133/10), adapting the main argument to take into account the discussion of “tail-thrashing attacks” and finalization availability from the Addendum. More details of how bounded dynamic availability could be implemented in the context of a Snap‑and‑Chat protocol are in [Notes on Snap‑and‑Chat](./notes-on-snap-and-chat.md). -The proposed changes end up being significant enough to give our construction a new name: "[Crosslink](./construction.md)", referring to the cross-links between blocks of the BFT and best-chain protocols. Crosslink has evolved somewhat, and now includes other changes not covered in either this document or [Notes on Snap-and-Chat](./notes-on-snap-and-chat.md). +The proposed changes end up being significant enough to give our construction a new name: “[Crosslink](./construction.md)”, referring to the cross-links between blocks of the BFT and best-chain protocols. Crosslink has evolved somewhat, and now includes other changes not covered in either this document or [Notes on Snap‑and‑Chat](./notes-on-snap-and-chat.md). ## Background -“Ebb-and-flow”, as described in [[NTT2021]](https://arxiv.org/pdf/2009.04987.pdf), is a security model for consensus protocols that provide two transaction logs, one with dynamic availability, and a prefix of it with finality. +“Ebb‑and‑Flow”, as described in [[NTT2020]](https://eprint.iacr.org/2020/1091.pdf) ([arXiv version](https://arxiv.org/pdf/2009.04987.pdf)), is a security model for consensus protocols that provide two transaction logs, one with dynamic availability, and a prefix of it with finality. -The paper proposes an instantiation of this security model called a "snap-and-chat" construction. It composes two consensus subprotocols, a BFT subprotocol and a best-chain subprotocol (it calls this the "longest chain protocol"). The above logs are obtained from the output of these subprotocols in a non-trivial way. +The paper proposes an instantiation of this security model called a “Snap‑and‑Chat” construction. It composes two consensus subprotocols, a BFT subprotocol and a best-chain subprotocol (it calls this the “longest chain protocol”). The above logs are obtained from the output of these subprotocols in a non-trivial way. This is claimed by the paper to “resolve” the tension between finality and dynamic availability. However, a necessary consequence is that in a situation where the “final” log stalls and the “available” log does not, the “finalization gap” between the finalization point and the chain tip can grow without bound. In particular, this means that transactions that spend funds can remain unfinalized for an arbitrary length of time. -In this note, we argue that this is unacceptable, and that it is preferable to sacrifice strict dynamic availability. However, we also argue that the main idea behind ebb-and-flow protocols is a good one, and that allowing the chain tip to run ahead of the finalization point does make sense and has practical advantages. However, we also argue that it should not be possible to include transactions that spend funds in blocks that are too far ahead of the finalization point. +In this note, we argue that this is unacceptable, and that it is preferable to sacrifice strict dynamic availability. However, we also argue that the main idea behind Ebb‑and‑Flow protocols is a good one, and that allowing the chain tip to run ahead of the finalization point does make sense and has practical advantages. However, we also argue that it should not be possible to include transactions that spend funds in blocks that are too far ahead of the finalization point. ```admonish info -Naive ways of preventing an unbounded finalization gap, such as stopping the chain completely in the case of a finalization stall, turn out to run into serious security problems --- at least when the best-chain protocol uses Proof-of-Work. We'll discuss those in detail. +Naive ways of preventing an unbounded finalization gap, such as stopping the chain completely in the case of a finalization stall, turn out to run into serious security problems — at least when the best-chain protocol uses Proof-of-Work. We’ll discuss those in detail. -Our proposed solution will be to require coinbase-only blocks during a long finalization stall. This solution has the advantage that, as far as this change goes, the security analysis of the snap-and-chat construction from [[NTT2021]](https://arxiv.org/pdf/2009.04987.pdf) can still be applied. +Our proposed solution will be to require coinbase-only blocks during a long finalization stall. This solution has the advantage that, as far as this change goes, the security analysis of the Snap‑and‑Chat construction from [[NTT2020]](https://eprint.iacr.org/2020/1091.pdf) can still be applied. ``` -We argue that losing strict dynamic availability in favour of "bounded dynamic availability" is preferable to the consequences of the unbounded finality gap, if/when a “long finalization stall” occurs. +We argue that losing strict dynamic availability in favour of “bounded dynamic availability” is preferable to the consequences of the unbounded finality gap, if/when a “long finalization stall” occurs. We also argue that it is beneficial to explicitly allow “finality overrides” under the control of a well-documented governance process. Such overrides allow long rollbacks that may be necessary in the case of an exploited security flaw. This is complementary to the argument for bounded dynamic availability, because the latter limits the period of user transactions that could be affected. The governance process can impose a limit on the length of this long rollback if desired. @@ -32,8 +32,8 @@ We also argue that it is beneficial to explicitly allow “finality overrides” Since partition between nodes sufficient for finalization cannot be prevented, loosely speaking the [CAP theorem](https://en.wikipedia.org/wiki/CAP_theorem) implies that any consistent protocol (and therefore any protocol with finality) may stall for at least as long as the partition takes to heal. -```admonish info -That "loosely speaking" is made precise by [[LR2020]](https://arxiv.org/pdf/2006.10698.pdf). +```admonish info "Background" +That “loosely speaking” is made precise by [[LR2020]](https://arxiv.org/pdf/2006.10698.pdf). ``` Dynamic availability implies that the chain tip will continue to advance, and so the finalization gap increases without bound. @@ -42,17 +42,17 @@ Partition is not necessarily the only condition that could cause a finalization ## Problems with allowing spends in an unbounded finalization gap -Both the available protocol, and the subprotocol that provides finality, will be used in practice — otherwise, one or both of them might as well not exist. There is always a risk that blocks may be rolled back to the finalization point, by definition. +Both the available protocol, and the subprotocol that provides finality, will be used in practice — otherwise, one or both of them might as well not exist. There is always a risk that blocks may be rolled back to the finalization point, by definition. Suppose, then, that there is a long finalization stall. The final and available protocols are not separate: there is no duplication of tokens between protocols, but the rules about how to determine best-effort balance and guaranteed balance depend on both protocols, how they are composed, and how the history after the finalization point is interpreted. ```admonish info -The guaranteed minimum balance of a given party is not just the minimum of their balance at the finalization point and their balance at the current tip. It is the minimum balance taken over all possible transaction histories that extend the finalized chain – taking into account that a party’s previously published transactions might be able to be reapplied in a different context without its explicit consent. The extent to which published transactions can be reapplied depends on technical choices that we must make, subject to some constraints (for example, we know that shielded transactions cannot be reapplied after their anchors have been invalidated). It may be desirable to further constrain re-use in order to make guaranteed minimum balances easier to compute. +The guaranteed minimum balance of a given party is not just the minimum of their balance at the finalization point and their balance at the current tip. It is the minimum balance taken over all possible transaction histories that extend the finalized chain — taking into account that a party’s previously published transactions might be able to be reapplied in a different context without its explicit consent. The extent to which published transactions can be reapplied depends on technical choices that we must make, subject to some constraints (for example, we know that shielded transactions cannot be reapplied after their anchors have been invalidated). It may be desirable to further constrain re-use in order to make guaranteed minimum balances easier to compute. ``` As the finalization gap increases, the negative consequences of rolling back user transactions that spend funds increase. (Coinbase transactions do not spend funds; they are a special case that we will discuss later.) -There are several possible ---not mutually exclusive--- outcomes: +There are several possible —not mutually exclusive— outcomes: * Users of the currency start to consider the available protocol increasingly unreliable. * Users start to consider a rollback to be untenable, and lobby to prevent it or cry foul if it occurs. @@ -60,9 +60,9 @@ There are several possible ---not mutually exclusive--- outcomes: * There is no free lunch that would allow us to avoid availability problems for services that also depend on finality. * Service providers adopt temporary workarounds that may not have had adequate security analysis. -Any of these might precipitate a crisis of confidence, and there are reasons to think this effect might be worse than if the chain had switched to a "Safety Mode" designed to prevent loss of user funds. Any such crisis may have a negative effect on token prices and long-term adoption. +Any of these might precipitate a crisis of confidence, and there are reasons to think this effect might be worse than if the chain had switched to a “Safety Mode” designed to prevent loss of user funds. Any such crisis may have a negative effect on token prices and long-term adoption. -Note that adding finalization using an ebb-and-flow protocol does not by itself increase the probability of a rollback in the available chain, provided the PoW remains as secure against rollbacks of a given length as before. But that is a big proviso. We have a design constraint (motivated by limiting token devaluation and by governance issues) to limit issuance to be no greater than that of the original Zcash protocol up to a given height. Since some of the issuance is likely needed to reward staking, the amount of money available for mining rewards is reduced, which may reduce overall hash rate and security of the PoW. Independently, there may be a temptation for design decisions to rely on finality in a way that reduces security of PoW (“risk compensation”). There is also pressure to reduce the energy usage of PoW, which necessarily reduces the global hash rate, and therefore the cost of performing an attack that depends on the adversary having any given proportion of global hash rate. +Note that adding finalization using an Ebb‑and‑Flow protocol does not by itself increase the probability of a rollback in the available chain, provided the PoW remains as secure against rollbacks of a given length as before. But that is a big proviso. We have a design constraint (motivated by limiting token devaluation and by governance issues) to limit issuance to be no greater than that of the original Zcash protocol up to a given height. Since some of the issuance is likely needed to reward staking, the amount of money available for mining rewards is reduced, which may reduce overall hash rate and security of the PoW. Independently, there may be a temptation for design decisions to rely on finality in a way that reduces security of PoW (“risk compensation”). There is also pressure to reduce the energy usage of PoW, which necessarily reduces the global hash rate, and therefore the cost of performing an attack that depends on the adversary having any given proportion of global hash rate. It could be argued that the issue of availability of services that depend on finality is mainly one of avoiding over-claiming about what is possible. Nevertheless I think there are also real usability issues if balances as seen by those services can differ significantly and for long periods from balances at the chain tip. @@ -70,45 +70,45 @@ Regardless, incorrect assumptions about the extent to which the finalized and av ## What is Bounded Dynamic Availability? -An intuitive notion of "availability" for blockchain protocols includes the ability to use the protocol as normal to spend funds. So, just to be clear, in a situation where that cannot happen we have lost availability, *even if* the block chain is advancing. +An intuitive notion of “availability” for blockchain protocols includes the ability to use the protocol as normal to spend funds. So, just to be clear, in a situation where that cannot happen we have lost availability, *even if* the block chain is advancing. -```admonish info +```admonish info "Background" For an explanation of *dynamic* availability and its advantages, I recommend [[DKT2020]](https://arxiv.org/abs/2010.08154) and its [accompanying talk](https://www.youtube.com/watch?v=SacUT_53Pg8). ``` -Bounded dynamic availability is a weakening of dynamic availability. It means that we intentionally sacrifice availability when some potentially hazardous operation ---a "hazard" for short--- would occur too far after the current finalization point. For now, assume for simplicity that our only hazard is spending funds. More generally, the notion of bounded dynamic availability can be applied to a wider range of protocols by tailoring the definition of "hazard" to the protocol. +Bounded dynamic availability is a weakening of dynamic availability. It means that we intentionally sacrifice availability when some potentially hazardous operation —a “hazard” for short— would occur too far after the current finalization point. For now, assume for simplicity that our only hazard is spending funds. More generally, the notion of bounded dynamic availability can be applied to a wider range of protocols by tailoring the definition of “hazard” to the protocol. ### Terminology note -[[NTT2021]](https://arxiv.org/pdf/2009.04987.pdf) calls the dynamically available blockchain protocol $\Pi_{\mathrm{lc}}$ that provides input to the rest of the contruction, the "longest chain" protocol. There are two reasons to avoid this terminology: -* In Bitcoin, Zcash, and most other PoW-based protocols, what is actually used by each node is not its longest observed chain, but its observed consensus-valid chain with most accumulated work. In Zcash this is called the node's "[best valid block chain](https://zips.z.cash/protocol/protocol.pdf#blockchain)", which we shorten to "best chain". -* As footnote 2 on page 3 of [[NTT2021]](https://arxiv.org/pdf/2009.04987.pdf) says, that paper does not require $\Pi_{\mathrm{lc}}$ to be a "longest chain" protocol anyway. +[[NTT2020]](https://eprint.iacr.org/2020/1091.pdf) calls the dynamically available blockchain protocol $\Pi_{\mathrm{lc}}$ that provides input to the rest of the contruction, the “longest chain” protocol. There are two reasons to avoid this terminology: +* In Bitcoin, Zcash, and most other PoW-based protocols, what is actually used by each node is not its longest observed chain, but its observed consensus-valid chain with most accumulated work. In Zcash this is called the node’s “[best valid block chain](https://zips.z.cash/protocol/protocol.pdf#blockchain)”, which we shorten to “best chain”. +* As footnote 2 on page 3 of [[NTT2020]](https://eprint.iacr.org/2020/1091.pdf) says, that paper does not require $\Pi_{\mathrm{lc}}$ to be a “longest chain” protocol anyway. -```admonish info -The error in conflating the "longest chain" with the observed consensus-valid chain with most accumulated work, originates in the Bitcoin whitepaper. [[Nakamoto2008](https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.221.9986), page 3] +```admonish info "Historical note" +The error in conflating the “longest chain” with the observed consensus-valid chain with most accumulated work, originates in the Bitcoin whitepaper. [[Nakamoto2008](https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.221.9986), page 3] ``` -We will use the term "best-chain protocol" instead. Note that this means $\Pi_{\mathrm{lc}}$ in the snap-and-chat construction, *not* any node's view of the sanitized ledger $\mathsf{LOG}_{\mathrm{da}}$. +We will use the term “best-chain protocol” instead. Note that this means $\Pi_{\mathrm{lc}}$ in the Snap‑and‑Chat construction, *not* any node’s view of the sanitized ledger $\mathsf{LOG}_{\mathrm{da}}$. ### How to block hazards -We have not yet decided *how* to block hazards during a long finalization stall. We could do so directly, or by stopping block production in the more-available protocol. For reasons explained in the section on "Tail-thrashing attacks" below, it's desirable *not* to stop block production. And so it's consistent to have bounded dynamic availability together with another liveness property ---which can be defined similarly to dynamic availability--- that says the more-available protocol's chain is still advancing. This is what we will aim for. +We have not yet decided *how* to block hazards during a long finalization stall. We could do so directly, or by stopping block production in the more-available protocol. For reasons explained in the [section on “Tail-thrashing attacks”](#tail-thrashing-attacks) below, it’s desirable *not* to stop block production. And so it’s consistent to have bounded dynamic availability together with another liveness property —which can be defined similarly to dynamic availability— that says the more-available protocol’s chain is still advancing. This is what we will aim for. -We will call this method of blocking hazards, without stopping block production, "going into Safety Mode". +We will call this method of blocking hazards, without stopping block production, “going into Safety Mode”. -```admonish info -This concept of Safety Mode is very similar to a [feature that was discussed early in the development of Zcash](https://github.com/zcash/zcash/issues/3311), but never fully designed or implemented. (After originally being called "Safety Mode", it was at some point renamed to "Emergency Mode", but then the latter term was used for [something else](https://electriccoin.co/blog/update-addressing-zcash-wallet-performance-issues/).) +```admonish info "Historical note" +This concept of Safety Mode is very similar to a [feature that was discussed early in the development of Zcash](https://github.com/zcash/zcash/issues/3311), but never fully designed or implemented. (After originally being called “Safety Mode”, it was at some point renamed to “Emergency Mode”, but then the latter term was used for [something else](https://electriccoin.co/blog/update-addressing-zcash-wallet-performance-issues/).) ``` -For Zcash, I propose that the main restriction of Safety Mode should be to require coinbase-only blocks. This achieves a similar effect, for our purposes, as actually stalling the more-available protocol's chain. Since funds cannot be spent in coinbase-only blocks, the vast majority of attacks that we are worried about would not be exploitable in this state. +For Zcash, I propose that the main restriction of Safety Mode should be to require coinbase-only blocks. This achieves a similar effect, for our purposes, as actually stalling the more-available protocol’s chain. Since funds cannot be spent in coinbase-only blocks, the vast majority of attacks that we are worried about would not be exploitable in this state. ```admonish info -It is possible that a security flaw could affect coinbase transactions. We *might* want to turn off shielded coinbase for Safety Mode blocks in order to reduce the chance of that. +It is possible that a security flaw could affect coinbase transactions. We *might* want to turn off shielded coinbase for Safety Mode blocks in order to reduce the chance of that. Also, mining rewards cannot be spent in a coinbase-only block; in particular, mining pools cannot distribute rewards. So there is a risk that an unscrupulous mining pool might try to do a rug-pull after mining of non-coinbase-only blocks resumes, if there were a very long finalization stall. But this approach works at least in the short term, and probably for long enough to allow manual intervention into the finalization protocol, or governance processes if needed. ``` -A analogy for the effect of this on availability that may be familiar to many people, is that it works like video streaming. All video streaming services use a buffer to paper over short-term interruptions or slow-downs of network access. In most cases, this buffer is bounded. This allows the video to be watched uninterrupted and at a constant rate in most circumstances. But if there is a longer-term network failure or insufficient sustained bandwidth, the playback will unavoidably stall. In our case, block production does not literally stall, but it's the same as far as users' ability to perform "hazardous" operations is concerned. +A analogy for the effect of this on availability that may be familiar to many people, is that it works like video streaming. All video streaming services use a buffer to paper over short-term interruptions or slow-downs of network access. In most cases, this buffer is bounded. This allows the video to be watched uninterrupted and at a constant rate in most circumstances. But if there is a longer-term network failure or insufficient sustained bandwidth, the playback will unavoidably stall. In our case, block production does not literally stall, but it’s the same as far as users’ ability to perform “hazardous” operations is concerned. ### Why is this better? @@ -116,18 +116,18 @@ So, why do I advocate this over: 1. A protocol that only provides dynamic availability; 2. A protocol that only provides finality; -3. An unmodified ebb-and-flow protocol? +3. An unmodified Ebb‑and‑Flow protocol? -The reason to reject a) is straightforward: finality is a valuable security property that is necessary for some use cases. +The reason to reject option 1 is straightforward: finality is a valuable security property that is necessary for some use cases. -If a protocol only provides finality (option b), then short-term availability is directly tied to finalization. It may be possible to make finalization stalls sufficiently rare or short-lived that this is tolerable. But that is more likely to be possible if and when there is a well-established staking ecosystem. Before that ecosystem is established, the protocol may be particularly vulnerable to stalls. Furthermore, it’s difficult to get to such a protocol from a pure PoW system like current Zcash. +If a protocol only provides finality (option 2), then short-term availability is directly tied to finalization. It may be possible to make finalization stalls sufficiently rare or short-lived that this is tolerable. But that is more likely to be possible if and when there is a well-established staking ecosystem. Before that ecosystem is established, the protocol may be particularly vulnerable to stalls. Furthermore, it’s difficult to get to such a protocol from a pure PoW system like current Zcash. -We argued in the previous section that allowing hazards in an unbounded finalization gap is bad. Option c) entails an unbounded finalization gap that *will* allow hazards. However, that isn’t sufficient to argue that bounded dynamic availability is better. Perhaps there are no good solutions! What are we gaining from a bounded dynamic availability approach that would justify the complexity of a hybrid protocol without obtaining strict dynamic availability? +We argued in the previous section that allowing hazards in an unbounded finalization gap is bad. Option 3 entails an unbounded finalization gap that *will* allow hazards. However, that isn’t sufficient to argue that bounded dynamic availability is better. Perhaps there are no good solutions! What are we gaining from a bounded dynamic availability approach that would justify the complexity of a hybrid protocol without obtaining strict dynamic availability? My argument goes like this: * It is likely that a high proportion of the situations in which a sustained finalization stall happens will require human intervention. If the finality protocol were going to recover without intervention, there is no reason to think that it wouldn’t do so in a relatively short time. -* When human intervention is required, the fact that the chain tip is still proceeding apace (in protocols with strict dynamic availability) makes restarting the finality protocol harder, for many potential causes of a finalization stall. This may be less difficult when only "non-hazardous" transactions are present--- in particular, when only coinbase transactions (which are subject to fairly strict rules in Zcash and other Bitcoin-derived chains) are present. This argument carries even more force when the protocol also allows “finality overrides”, as discussed later in the Complementarity section. +* When human intervention is required, the fact that the chain tip is still proceeding apace (in protocols with strict dynamic availability) makes restarting the finality protocol harder, for many potential causes of a finalization stall. This may be less difficult when only “non-hazardous” transactions are present— in particular, when only coinbase transactions (which are subject to fairly strict rules in Zcash and other Bitcoin-derived chains) are present. This argument carries even more force when the protocol also allows “finality overrides”, as discussed later in the Complementarity section. * Nothing about bounded dynamic availability prevents us from working hard to design a system that makes finalization stalls as infrequent and short-lived as possible, just as we would for any other option that provides finality. * We want to optimistically minimize the finalization gap under good conditions, because this improves the usability of services that depend on finality. This argues against protocols that try to maintain a fixed gap, and motivates letting the gap vary. * In practice, the likelihood of short finalization stalls is high enough that heuristically retaining availability in those situations is useful. @@ -177,23 +177,23 @@ Although that would allow saying that the finality property has technically not ## Complementarity -Finality overrides and bounded dynamic availability are complementary in the following way: if a problem is urgent enough, then validators can be asked to stop validating. For genuinely harmful problems, it is likely to be in the interests of enough validators to stop that this causes a finalization stall. If this lasts longer than the availability bound then the protocol will go into Safety Mode, giving time for the defined governance process to occur and decide what to do. And because the unfinalized consensus chain will contain only a limited period of user transactions that spend funds, the option of a long rollback remains realistically open. +Finality overrides and bounded dynamic availability are complementary in the following way: if a problem is urgent enough, then validators can be asked to stop validating. For genuinely harmful problems, it is likely to be in the interests of enough validators to stop that this causes a finalization stall. If this lasts longer than the availability bound then the protocol will go into Safety Mode, giving time for the defined governance process to occur and decide what to do. And because the unfinalized consensus chain will contain only a limited period of user transactions that spend funds, the option of a long rollback remains realistically open. If, on the other hand, there is time pressure to make a governance decision about a rollback in order to reduce its length, that may result in a less well-considered decision. -A possible objection is that there might be a coalition of validators who ignore the request to stop (possibly including the attacker or validators that an attacker can bribe), in which case the finalization stall would not happen. But that just means that we don’t gain the advantage of more time to make a governance decision; it isn’t actively a disadvantage relative to alternative designs. This outcome can also be thought of as a feature rather than a bug: going into Safety Mode should be a last resort, and if the argument given for the request to stop failed to convince a sufficient number of validators that it was reason enough to do so, then perhaps it wasn’t a good enough reason. +A possible objection is that there might be a coalition of validators who ignore the request to stop (possibly including the attacker or validators that an attacker can bribe), in which case the finalization stall would not happen. But that just means that we don’t gain the advantage of more time to make a governance decision; it isn’t actively a disadvantage relative to alternative designs. This outcome can also be thought of as a feature rather than a bug: going into Safety Mode should be a last resort, and if the argument given for the request to stop failed to convince a sufficient number of validators that it was reason enough to do so, then perhaps it wasn’t a good enough reason. -```admonish info -This resolves one of the main objections to the [original Safety Mode idea](https://github.com/zcash/zcash/issues/3311) that stopped us from implementing it in Zcash. The original proposal was to use a signature with a key held by ECC to trigger Safety Mode, which would arguably have been too centralized. The Safety Mode described in this document, on the other hand, can only be entered by consensus of a larger validator set, or if there is an availability failure of the finalization protocol. +```admonish info "Rationale" +This resolves one of the main objections to the [original Safety Mode idea](https://github.com/zcash/zcash/issues/3311) that stopped us from implementing it in Zcash. The original proposal was to use a signature with a key held by ECC to trigger Safety Mode, which would arguably have been too centralized. The Safety Mode described in this document, on the other hand, can only be entered by consensus of a larger validator set, or if there is an availability failure of the finalization protocol. ``` It is also possible to make the argument that the threshold of stake needed is imposed by technical properties of the finality protocol and by the resources of the attacker, which might not be ideal for the purpose described above. However, I would argue that it does not need to be ideal, and will be in the right ballpark in practice. -There's a caveat related to doing intentional rollbacks when using the Safety Mode approach, where block production in the more-available protocol continues during a long finalization stall. What happens to incentives of block producers (miners in the case of Proof-of-Work), given that they know the consensus chain might be intentionally rolled back? They might reasonably conclude that it is less valuable to produce those blocks, leading to a reduction of hash rate or other violations of the security assumptions of $\Pi_{\mathrm{lc}}$. +There’s a caveat related to doing intentional rollbacks when using the Safety Mode approach, where block production in the more-available protocol continues during a long finalization stall. What happens to incentives of block producers (miners in the case of Proof-of-Work), given that they know the consensus chain might be intentionally rolled back? They might reasonably conclude that it is less valuable to produce those blocks, leading to a reduction of hash rate or other violations of the security assumptions of $\Pi_{\mathrm{lc}}$. This is actually fairly easy to solve. We have the governance procedures say that if we do an intentional rollback, the coinbase-only mining rewards will be preserved. I.e. we produce a block or blocks that include those rewards paid to the same addresses (adjusting the consensus to allow them to be created from thin air if necessary), have everyone check it thoroughly, and require the chain to restart from that block. So as long as block producers believe that this governance procedure will be followed and that the chain will eventually recover at a reasonable coin price, they will still have incentive to produce on $\Pi_{\mathrm{lc}}$, at least for a time. -```admonish info +```admonish info "Rationale" Although the community operating the governance procedures has already obtained the security benefit of mining done on the rolled-back chain by the time it creates the new chain, there is a strong incentive not to renege on the agreement with miners, because the same situation may happen again. ``` @@ -201,29 +201,30 @@ Although the community operating the governance procedures has already obtained Earlier we said that there were two possible approaches to preventing hazards during a long finalization stall: -a) go into a Safety Mode that directly disallows hazardous transactions (for example, by requiring $\Pi_{\mathrm{lc}}$ blocks to be coinbase-only in Zcash); +a) go into a Safety Mode that directly disallows hazardous transactions (for example, by requiring $\Pi_{\mathrm{lc}}$ blocks to be coinbase-only in Zcash); + b) temporarily cause the more-available chain to stall. This section describes an important class of potential attacks on approach b) that are difficult to resolve. They are based on the fact that when the unfinalized chain stalls, an adversary has more time to find blocks, and this might violate security assumptions of the more-available protocol. For instance, if the more-available protocol is PoW-based, then its security in the steady state is predicated on the fact that an adversary with a given proportion of hash power has only a limited time to use that power, before the rest of the network finds another block. -```admonish info -For an analysis of the concrete security of Nakamoto-like protocols, see [[DKT+2020]](https://arxiv.org/abs/2005.10484) and [[GKR2020]](https://eprint.iacr.org/2020/661). These papers confirm the intuition that the "private attack" ---in which an adversary races privately against the rest of the network to construct a forking chain--- is optimal, obtaining the same tight security bound independently using different techniques. +```admonish info "Background" +For an analysis of the concrete security of Nakamoto-like protocols, see [[DKT+2020]](https://arxiv.org/abs/2005.10484) and [[GKR2020]](https://eprint.iacr.org/2020/661). These papers confirm the intuition that the “private attack” —in which an adversary races privately against the rest of the network to construct a forking chain— is optimal, obtaining the same tight security bound independently using different techniques. ``` During a chain stall, the adversary no longer has a limited time to construct a forking chain. If, say, the adversary has 10% hash power, then it can on average find a block in 10 block times. And so in 100 block times it can create a 10-block fork. -It may in fact be worse than this: once miners know that a finalization stall is happening, their incentive to continue mining is reduced, since they know that there is a greater chance that their blocks might be rolled back. So we would expect the global hash rate to fall ---even before the finality gap bound is hit--- and then the adversary would have a greater proportion of hash rate. +It may in fact be worse than this: once miners know that a finalization stall is happening, their incentive to continue mining is reduced, since they know that there is a greater chance that their blocks might be rolled back. So we would expect the global hash rate to fall —even before the finality gap bound is hit— and then the adversary would have a greater proportion of hash rate. ```admonish info -Even in a pure ebb-and-flow protocol, a finalization stall could cause miners to infer that their blocks are more likely to be rolled back, but the fact that the chain is continuing would make that more difficult to exploit. This issue with the global hash rate is mostly specific to the more-available protocol being PoW: if it were PoS, then its validators might as well continue proposing blocks because it is cheap to do so. There might be other attacks when the more-available protocol is PoS; I haven't spent much time analysing that case. +Even in a pure Ebb‑and‑Flow protocol, a finalization stall could cause miners to infer that their blocks are more likely to be rolled back, but the fact that the chain is continuing would make that more difficult to exploit. This issue with the global hash rate is mostly specific to the more-available protocol being PoW: if it were PoS, then its validators might as well continue proposing blocks because it is cheap to do so. There might be other attacks when the more-available protocol is PoS; we haven’t spent much time analysing that case. ``` -The problem is that the more-available chain does not necessarily *just halt* during a chain stall. In fact, for a finality gap bound of $k$ blocks, an adversary could cause the $k$-block "tail" of the chain as seen by any given node to "thrash" between different chains. I will call this a **tail-thrashing attack**. +The problem is that the more-available chain does not necessarily *just halt* during a chain stall. In fact, for a finality gap bound of $k$ blocks, an adversary could cause the $k$-block “tail” of the chain as seen by any given node to “thrash” between different chains. I will call this a **tail-thrashing attack**. If a protocol allowed such attacks then it would be a regression relative to the security we would normally expect from an otherwise similar PoW-based protocol. It only occurs during a finalization stall, but note that we cannot exclude the possibility of an adversary being able to provoke a finalization stall. -Note that in the snap-and-chat construction, snapshots of $\Pi_{\mathrm{lc}}$ are used as input to the BFT protocol. That implies that the tail-thrashing problem could also affect the input to that protocol, which would be bad (not least for security analysis of availability, which seems somewhat intractable in that case). +Note that in the Snap‑and‑Chat construction, snapshots of $\Pi_{\mathrm{lc}}$ are used as input to the BFT protocol. That implies that the tail-thrashing problem could also affect the input to that protocol, which would be bad (not least for security analysis of availability, which seems somewhat intractable in that case). -Also, when restarting $\Pi_{\mathrm{lc}}$, we would need to take account of the fact that the adversary has had an arbitrary length of time to build long chains from every block that we could potentially restart from. It could be possible to invalidate those chains by requiring blocks after the restart to be dependent on fresh randomness, but that sounds quite tricky (especially given that we want to restart *without* manual intervention if possible), and there may be other attacks I haven't thought of. This motivates using approach a) instead. +Also, when restarting $\Pi_{\mathrm{lc}}$, we would need to take account of the fact that the adversary has had an arbitrary length of time to build long chains from every block that we could potentially restart from. It could be possible to invalidate those chains by requiring blocks after the restart to be dependent on fresh randomness, but that sounds quite tricky (especially given that we want to restart *without* manual intervention if possible), and there may be other attacks we haven’t thought of. This motivates using approach a) instead. -Note that we have still glossed over precisely how consensus rules would change to enforce a). I recommend reading [Notes on Snap-and-Chat](./notes-on-snap-and-chat.md) next, followed by [The Crosslink Construction](./construction.md). +Note that we have still glossed over precisely how consensus rules would change to enforce a). I recommend reading [Notes on Snap‑and‑Chat](./notes-on-snap-and-chat.md) next, followed by [The Crosslink Construction](./construction.md). From a8bcafcb5d59ada5d343cabcbc087dcb70a8734c Mon Sep 17 00:00:00 2001 From: Daira Emma Hopwood Date: Thu, 28 Dec 2023 02:17:52 +0000 Subject: [PATCH 2/3] Crosslink: clarifications. Signed-off-by: Daira Emma Hopwood --- src/design/crosslink/construction.md | 14 +++++++++++--- src/design/crosslink/security-analysis.md | 18 ++++++++++-------- 2 files changed, 21 insertions(+), 11 deletions(-) diff --git a/src/design/crosslink/construction.md b/src/design/crosslink/construction.md index 7a1ca86..7618a6c 100644 --- a/src/design/crosslink/construction.md +++ b/src/design/crosslink/construction.md @@ -74,6 +74,8 @@ A Crosslink node must participate in both $\Pi A player’s view in $\Pi_{\mathrm{*bft}}$ includes a set of $\mathrm{*}$bft‑block chains each rooted at a fixed genesis $\mathrm{*}$bft‑block $\mathcal{O}_{\mathrm{*bft}}$. There is a $\mathrm{*}$bft‑block‑validity rule (specified below), which depends only on the content of the block and its ancestors. A non‑genesis block can only be $\mathrm{*}$bft‑block‑valid if its parent is $\mathrm{*}$bft‑block‑valid. A $\mathrm{*}$bft‑valid‑chain is a chain of $\mathrm{*}$bft‑block‑valid blocks. +Execution proceeds in a sequence of epochs. In each epoch, a $\mathrm{*}$bft‑proposal may be made. + A $\mathrm{*}$bft‑proposal refers to a parent $\mathrm{*}$bft‑block, and specifies the proposal’s epoch. The content of a proposal is signed by the proposer using a strongly unforgeable signature scheme. We consider the proposal to include this signature. There is a $\mathrm{*}$bft‑proposal‑validity rule, depending only on the content of the proposal and its parent block, and the validity of the proposer’s signature. ```admonish info @@ -82,15 +84,15 @@ We will shorten “$\mathrm{*}$bft‑block‑v For each epoch, there is a fixed number of voting units distributed between the players, which they use to vote for a $\mathrm{*}$bft‑proposal. We say that a voting unit has been cast for a $\mathrm{*}$bft‑proposal $P$ at a given time in a $\mathrm{*}$bft‑execution, if and only if $P$ is $\mathrm{*}$bft‑proposal‑valid and a ballot for $P$ authenticated by the holder of the voting unit exists at that time. -If, and only if, the votes cast for a $\mathrm{*}$bft‑proposal $P$ satisfy a notarization rule at a given time in a $\mathrm{*}$bft‑execution, then it is possible to obtain a valid $\mathrm{*}$bft‑notarization‑proof $\mathsf{proof}_P$. The notarization rule must require at least a two‑thirds absolute supermajority of voting units in $P$'s epoch to have been cast for $P$. It may also require other conditions. +Using knowledge of ballots cast for a $\mathrm{*}$bft‑proposal $P$ that collectively satisfy a notarization rule at a given time in a $\mathrm{*}$bft‑execution, and only with such knowledge, it is possible to obtain a valid $\mathrm{*}$bft‑notarization‑proof $\mathsf{proof}_P$. The notarization rule must require at least a two‑thirds absolute supermajority of voting units in $P$’s epoch to have been cast for $P$. It may also require other conditions. A voting unit is cast non‑honestly for an epoch’s proposal iff: * it is cast other than by the holder of the unit (due to key compromise or any flaw in the voting protocol, for example); or -* it is double‑cast (i.e. for distinct proposals); or +* it is double‑cast (i.e. there are two ballots casting it for distinct proposals); or * the holder of the unit following the conditions for honest voting in $\Pi_{\mathrm{*bft}}$, according to its view, should not have cast that vote. ```admonish success "Definition: One‑third bound on non‑honest voting" -An execution of $\Pi_{\mathrm{bft}}$ has the **one‑third bound on non‑honest voting** property if at any epoch in the execution, *strictly* fewer than one third of the total voting units for that epoch are cast non‑honestly. +An execution of $\Pi_{\mathrm{bft}}$ has the **one‑third bound on non‑honest voting** property iff for every epoch, *strictly* fewer than one third of the total voting units for that epoch are ever cast non‑honestly. ``` ```admonish info @@ -99,6 +101,12 @@ It may be the case that a ballot cast for $P$ is not in honest view when it is u There may be multiple distinct ballots or distinct ballot messages attempting to cast a given voting unit for the same proposal; this is undesirable for bandwidth usage, but it is not necessary to consider it to be non‑honest behaviour for the purpose of security analysis, as long as such ballots are not double‑counted toward the two‑thirds threshold. ``` +```admonish warning "Security caveat" +The **one‑third bound on non‑honest voting** property considers all ballots cast in the entire execution. In particular, it is possible that a validator’s key is compromised and then used to cast its voting units for a proposal of an epoch long finished. If the number of voting units cast non-honestly for any epoch *ever* reaches one third of the total voting units for that epoch during an execution, then the **one‑third bound on non‑honest voting** property is violated for that execution. + +Therefore, validator keys of honest nodes must remain secret indefinitely. Whenever a key is rotated, the old key must be securely deleted. For further discussion and potential improvements, see [tfl-book issue #140](https://github.com/Electric-Coin-Company/tfl-book/issues/140). +``` + A $\mathrm{*}$bft‑block consists of $(P, \mathsf{proof}_P)$ re‑signed by the same proposer using a strongly unforgeable signature scheme. It is $\mathrm{*}$bft‑block‑valid iff: * $P$ is $\mathrm{*}$bft‑proposal‑valid; and * $\mathsf{proof}_P$ is a valid proof that some subset of ballots cast for $P$ are sufficient to satisfy the notarization rule; and diff --git a/src/design/crosslink/security-analysis.md b/src/design/crosslink/security-analysis.md index 05faa7c..9124a26 100644 --- a/src/design/crosslink/security-analysis.md +++ b/src/design/crosslink/security-analysis.md @@ -137,16 +137,18 @@ The above property is not as strong as we would like for practical uses of $\mat As documented in the [Model for BFT protocols](./construction.md#model-for-bft-protocols-Πorigbftbft) section of [The Crosslink Construction](./construction.md)): -> For each epoch, there is a fixed number of voting units distributed between the players, which they use to vote for a $\mathrm{*}$bft‑proposal. If, and only if, the votes cast for a $\mathrm{*}$bft‑proposal $P$ satisfy a notarization rule, then it is possible to obtain a valid $\mathrm{*}$bft‑notarization-proof $\mathsf{proof}_P$. The notarization rule must require at least a two-thirds absolute supermajority of voting units to have been cast for $P$. (It may also require other conditions.) +> For each epoch, there is a fixed number of voting units distributed between the players, which they use to vote for a $\mathrm{*}$bft‑proposal. We say that a voting unit has been cast for a $\mathrm{*}$bft‑proposal $P$ at a given time in a $\mathrm{*}$bft‑execution, if and only if $P$ is $\mathrm{*}$bft‑proposal‑valid and a ballot for $P$ authenticated by the holder of the voting unit exists at that time. > -> A voting unit for an epoch is cast non‑honestly if: -> * it is cast other than by the holder of the unit (due to key compromise or any flaw in the voting protocol, for example); or -> * it is double‑cast (i.e. for distinct proposals); or -> * the holder of the unit following the conditions for honest voting in $\Pi_{\mathrm{*bft}}$, according to its view, should not have cast that vote. +> Using knowledge of ballots cast for a $\mathrm{*}$bft‑proposal $P$ that collectively satisfy a notarization rule at a given time in a $\mathrm{*}$bft‑execution, and only with such knowledge, it is possible to obtain a valid $\mathrm{*}$bft‑notarization‑proof $\mathsf{proof}_P$. The notarization rule must require at least a two‑thirds absolute supermajority of voting units in $P$’s epoch to have been cast for $P$. It may also require other conditions. > -> ```admonish success -> An execution of $\Pi_{\mathrm{bft}}$ has the **one‑third bound on non‑honest voting** property if at any epoch in the execution, strictly fewer than one third of the total voting units for that epoch are cast non‑honestly. -> ``` +> A voting unit is cast non‑honestly for an epoch’s proposal iff: +> * it is cast other than by the holder of the unit (due to key compromise or any flaw in the voting protocol, for example); or +> * it is double‑cast (i.e. there are two ballots casting it for distinct proposals); or +> * the holder of the unit following the conditions for honest voting in $\Pi_{\mathrm{*bft}}$, according to its view, should not have cast that vote. + +```admonish success "Definition: One‑third bound on non‑honest voting" +An execution of $\Pi_{\mathrm{bft}}$ has the **one‑third bound on non‑honest voting** property iff for every epoch, *strictly* fewer than one third of the total voting units for that epoch are ever cast non‑honestly. +``` ```admonish success "Theorem: On bft‑valid blocks for a given epoch in honest view" By a well known argument often used to prove safety of BFT protocols, in an execution of Crosslink where $\Pi_{\mathrm{bft}}$ has the **one‑third bound on non‑honest voting** property (and assuming soundness of notarization proofs), any bft‑valid block for a given epoch in honest view must commit to the same proposal. From 215b51e2aef38b08d8b9ccec39b24b337c29bb71 Mon Sep 17 00:00:00 2001 From: Daira Emma Hopwood Date: Fri, 19 Jan 2024 17:46:54 +0000 Subject: [PATCH 3/3] Clarifications from code review. Co-authored-by: Nate Wilcox Signed-off-by: Daira Emma Hopwood --- src/design/crosslink/construction.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/design/crosslink/construction.md b/src/design/crosslink/construction.md index 7618a6c..8c54117 100644 --- a/src/design/crosslink/construction.md +++ b/src/design/crosslink/construction.md @@ -74,7 +74,7 @@ A Crosslink node must participate in both $\Pi A player’s view in $\Pi_{\mathrm{*bft}}$ includes a set of $\mathrm{*}$bft‑block chains each rooted at a fixed genesis $\mathrm{*}$bft‑block $\mathcal{O}_{\mathrm{*bft}}$. There is a $\mathrm{*}$bft‑block‑validity rule (specified below), which depends only on the content of the block and its ancestors. A non‑genesis block can only be $\mathrm{*}$bft‑block‑valid if its parent is $\mathrm{*}$bft‑block‑valid. A $\mathrm{*}$bft‑valid‑chain is a chain of $\mathrm{*}$bft‑block‑valid blocks. -Execution proceeds in a sequence of epochs. In each epoch, a $\mathrm{*}$bft‑proposal may be made. +Execution proceeds in a sequence of epochs. In each epoch, an honest proposer for that epoch may make a $\mathrm{*}$bft‑proposal. A $\mathrm{*}$bft‑proposal refers to a parent $\mathrm{*}$bft‑block, and specifies the proposal’s epoch. The content of a proposal is signed by the proposer using a strongly unforgeable signature scheme. We consider the proposal to include this signature. There is a $\mathrm{*}$bft‑proposal‑validity rule, depending only on the content of the proposal and its parent block, and the validity of the proposer’s signature. @@ -88,7 +88,7 @@ Using knowledge of ballots cast for a $\mathrm A voting unit is cast non‑honestly for an epoch’s proposal iff: * it is cast other than by the holder of the unit (due to key compromise or any flaw in the voting protocol, for example); or -* it is double‑cast (i.e. there are two ballots casting it for distinct proposals); or +* it is double‑cast (i.e. there are at least two ballots casting it for distinct proposals); or * the holder of the unit following the conditions for honest voting in $\Pi_{\mathrm{*bft}}$, according to its view, should not have cast that vote. ```admonish success "Definition: One‑third bound on non‑honest voting"