From edc50a5e029c8ea85a7c72e0834de6e25d54aa59 Mon Sep 17 00:00:00 2001 From: nate Date: Tue, 10 Oct 2023 10:56:14 -0700 Subject: [PATCH 01/12] Update introduction with linked references; update linked terminology to match. --- src/introduction.md | 4 ++-- src/terminology.md | 20 +++++++++++++++----- 2 files changed, 17 insertions(+), 7 deletions(-) diff --git a/src/introduction.md b/src/introduction.md index 9e5acaf..aafd8a5 100644 --- a/src/introduction.md +++ b/src/introduction.md @@ -1,7 +1,7 @@ # A Trailing Finality Layer for Zcash -This book introduces and specifies a *Trailing Finality Layer* for the Zcash network. +This book introduces and specifies a [*Trailing Finality Layer*](./terminology.md#definition-tfl) for the Zcash network. -This design augments the existing Zcash Proof-of-Work (PoW) network with a new consensus layer which provides *trailing finality*. This layer enables blocks produced via PoW to become *final* which ensures they may never be rolled back. This enables safer and simpler wallets and other infrastructure, and aids trust-minimized cross-chain bridges. This consensus layer uses Proof-of-Stake consensus, and enables ZEC holders to earn protocol rewards for contributing to the security of the Zcash network. By integrating a PoS layer with the current PoW Zcash protocol, this design specifies a *hybrid consensus protocol*. +This design augments the existing Zcash Proof-of-Work ([PoW](./terminology.md#definition-pow)) network with a new consensus layer which provides [*trailing finality*](./terminology.md#definition-trailing-finality). This layer enables blocks produced via PoW to become [*final*](./terminology.md#definition-final) which ensures they may never be rolled back. This enables safer and simpler wallets and other infrastructure, and aids trust-minimized cross-chain bridges. This consensus layer uses [*Proof-of-Stake*](./terminology.md#definition-pos) consensus, and enables ZEC holders to earn protocol rewards for contributing to the security of the Zcash network. By integrating a PoS layer with the current PoW Zcash protocol, this design specifies a [*hybrid consensus*](./terminology.md#definition-hybrid-consensus) protocol dubbed [PoW+TFL](./terminology.md#definition-pow-tfl). The rest of this introductory chapter is aimed at a general audience interested in the context of this proposal within Zcash development, status and next steps, motivations, a primer on finality, and tips to get involved. diff --git a/src/terminology.md b/src/terminology.md index 2af00e5..7865714 100644 --- a/src/terminology.md +++ b/src/terminology.md @@ -8,19 +8,29 @@ We group terms into related categories as follows: ## Protocol Concepts -**Assured Finality**: A protocol property that guarantees that final transactions cannot be reverted by that protocol. As with all protocol guarantees, a protocol assumes certain conditions must be met. +**Assured Finality**: A protocol property that guarantees that some transactions cannot be reverted by that protocol. As with all protocol guarantees, a protocol assumes certain conditions must be met. A transaction may either be final or not: transactions which are not final may not become final, whereas once transactions do achieve finality they retain that property indefinitely (so long as protocol requirements are met). - Importantly, it is not feasible for any protocol to prevent reversing final transactions "out of band" from the protocol, such as if a sufficiently large and motivated group of users forks the network to include a specific new validity rule reverting transactions. For this reason, we forego the term "absolute finality" sometimes used in consensus protocol technical discussions. +Importantly, it is not feasible for any protocol to prevent reversing final transactions "out of band" from the protocol, such as if a sufficiently large and motivated group of users forks the network to include a specific new validity rule reverting transactions. For this reason, we forego the term "absolute finality" sometimes used in consensus protocol technical discussions. + +**Final**: A protocol property of transactions. In this book, this always implies [assured finality](#definition-assured-finality), in contrast to concepts like "probabilistic finality" provided by [PoW](#definition-pow). + +**Trailing Finality**: A protocol property wherein transactions become final some time after first appearing in [PoW](#definition-pow) blocks. ## Protocol Components **PoW+TFL**: the overall complete, integrated consensus protocol specified in this book. -**NU5**: the Zcash consensus protocol as of NU5.[^new-mainnet-precursors] +**NU5**: The Zcash consensus protocol as of NU5.[^new-mainnet-precursors] + +**Proof-of-Work**: A PoW protocol uses Nakamoto consensus pioneered by Bitcoin. The PoW subprotocol within PoW+TFL is a different consensus protocol from [NU5](#definition-nu5) and encompasses more than narrow Nakamoto PoW consensus, including transaction semantics such as for shielded transfers. + +*TODO*: Clarify the distinctions between PoW (general consensus), [NU5](#definition-nu5) which includes transaction semantics, and the PoW component of [PoW-TFL](#definition-pow-tfl). These distinctions deserve unique terms. + +**TFL**: The *Trailing Finality Layer* subprotocol within PoW+TFL. This is a new [PoS](#definition-pos) subprotocol which provides [assured finality](#definition-assured-finality) for Zcash. -**PoW**: the PoW subprotocol within PoW+TFL. Note that this is a different consensus protocol from NU5 and encompasses more than narrow Nakamoto PoW consensus, including transaction semantics such as for shielded transfers. +**Proof-of-Stake**: A PoS protocol achieves consensus on transaction status via taking into account the weighting of staking tokens. PoS protocols fall into a large umbrella and may or may not provide [assured finality](#definition-assured-finality) or other properties this design requires of [TFL](#definition-tfl). -**TFL**: the *Trailing Finality Layer* subprotocol within PoW+TFL. +**Hybrid Consensus**: A consensus protocol which integrates more than one consensus subprotocol. [PoW+TFL](#definition-pow-tfl) is an instance of a hybrid protocol integrating [PoW](#definition-pow) and [PoS](#definition-pos) protocols. ## Infrastructure Roles From 99478d253850e63d59a75030daa92e6203d9d3d0 Mon Sep 17 00:00:00 2001 From: nate Date: Thu, 12 Oct 2023 11:39:48 -0700 Subject: [PATCH 02/12] Remove all unreferenced definitions and remove section distinctions. --- src/terminology.md | 41 +---------------------------------------- 1 file changed, 1 insertion(+), 40 deletions(-) diff --git a/src/terminology.md b/src/terminology.md index 7865714..30d9917 100644 --- a/src/terminology.md +++ b/src/terminology.md @@ -4,9 +4,7 @@ Prior to providing the [Overview](./overview.md), [Design Specification](./desig We rely on terms of art specific to this book. A word of caution that in some cases we use similar terms from elsewhere in the blockchain consensus field with distinct meanings specific to this book and different from other uses, for example *validator*. -We group terms into related categories as follows: - -## Protocol Concepts +## Terms **Assured Finality**: A protocol property that guarantees that some transactions cannot be reverted by that protocol. As with all protocol guarantees, a protocol assumes certain conditions must be met. A transaction may either be final or not: transactions which are not final may not become final, whereas once transactions do achieve finality they retain that property indefinitely (so long as protocol requirements are met). @@ -16,8 +14,6 @@ Importantly, it is not feasible for any protocol to prevent reversing final tran **Trailing Finality**: A protocol property wherein transactions become final some time after first appearing in [PoW](#definition-pow) blocks. -## Protocol Components - **PoW+TFL**: the overall complete, integrated consensus protocol specified in this book. **NU5**: The Zcash consensus protocol as of NU5.[^new-mainnet-precursors] @@ -32,41 +28,6 @@ Importantly, it is not feasible for any protocol to prevent reversing final tran **Hybrid Consensus**: A consensus protocol which integrates more than one consensus subprotocol. [PoW+TFL](#definition-pow-tfl) is an instance of a hybrid protocol integrating [PoW](#definition-pow) and [PoS](#definition-pos) protocols. -## Infrastructure Roles - -These are roles of infrastructure components (not human users). Keep in mind a given product or service may fill multiple roles, for example a wallet application may provide *validator*, *wallet viewer*, and *wallet spender* roles to provide users with safe access to private funds. - -**Validator**: a component which locally verifies the correctness of consensus. This includes verifying that the local view of chain history matches consensus requirements, encompassing block tip selection, block validity, and transaction validity.[^validator-distinction] - -**Block Proposer**: a component which proposes a block of transactions to the network. If accepted by network consensus, this block extends the consensus state of the ledger. - -**PoW Proposer**: a Block Proposer which uses PoW as the proposal mechanism. In NU5 and PoW+TFL, the only Block Proposers are PoW Proposers. In practice, PoW Proposers are typically mining pools, although a solo miner is also a PoW Proposer. We use this term to be more precise than the common term "miner" which can conflate this role with the following: - -**PoW Hashrate Provider**: a component which contributes mining resources towards PoW block proposals. In practice, mining pools rely on a userbase of Hashrate Providers to scale their operation, and solo miners have this capacity "in-house". - -**Block Finalizer**: a component which contributes to consensus progress on the *finality* of a block. - -**Wallet Viewer**: a component which provides a view into the history of funds for particular addresses, given appropriate *viewing keys*. This history may include both transparent and private details. - -**Wallet Spender**: a component that enables generating new transactions which transfer funds to recipients. - -## Blockchain State - - -**Transaction**: a modification of the ledger, issued (by definition) by a Wallet Spender. A transaction cannot become part of the consensus ledger unless all Validators would accept it as valid according to *Transaction Validity Rules*. - -**Block**: **\[TODO\]** - -**Block History**: **\[TODO\]** _(nodes can see multiple local histories and select one as canonical according to consensus) - -**Pending Blocks**: **\[TODO\]** - -**Pending Transactions**: **\[TODO\]** - -**Final Blocks**: **\[TODO\]** - -**Final Transactions**: **\[TODO\]** - # Footnotes [^new-mainnet-precursors]: If new consensus changes are deployed to Zcash mainnet prior to PoW+TFL design finalization, this design must be updated to refer to the new delta (e.g. by reanalyzing all changes against NU6 or NU7, etc…) From 2ed533c41b0c260953abdb41c6ed485cb85a3164 Mon Sep 17 00:00:00 2001 From: nate Date: Thu, 12 Oct 2023 11:42:14 -0700 Subject: [PATCH 03/12] Remove unreferenced footnote. --- src/terminology.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/src/terminology.md b/src/terminology.md index 30d9917..d3054d3 100644 --- a/src/terminology.md +++ b/src/terminology.md @@ -31,5 +31,3 @@ Importantly, it is not feasible for any protocol to prevent reversing final tran # Footnotes [^new-mainnet-precursors]: If new consensus changes are deployed to Zcash mainnet prior to PoW+TFL design finalization, this design must be updated to refer to the new delta (e.g. by reanalyzing all changes against NU6 or NU7, etc…) - -[^validator-distinction]: Our use of the term "validator" deviates from common industry usage. Our usage focuses on literally validating consensus state, and does not imply any participation in maintaining the network or extending the ledger. This is distinct from widespread usage of "validator" to include the role or responsibility of proposing new blocks or achieving network consensus on ledger updates. From e1123bb103db1721718865f1c3b1135f0a880027 Mon Sep 17 00:00:00 2001 From: nate Date: Thu, 12 Oct 2023 11:43:31 -0700 Subject: [PATCH 04/12] Simplify/streamline the terminology intro. --- src/terminology.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/src/terminology.md b/src/terminology.md index d3054d3..0cf15aa 100644 --- a/src/terminology.md +++ b/src/terminology.md @@ -1,8 +1,6 @@ # Terminology -Prior to providing the [Overview](./overview.md), [Design Specification](./design-specification.md) and other sections, we present our terminology. If you prefer to learn terms in the conceptual flow, jump ahead to the [Overview](./overview.md) and refer back as necessary. - -We rely on terms of art specific to this book. A word of caution that in some cases we use similar terms from elsewhere in the blockchain consensus field with distinct meanings specific to this book and different from other uses, for example *validator*. +This book relies on the following terminology. We strive to keep these definitions as precise as possible and their definitions may deviate from uses elsewhere. ## Terms From 04d15dcb9248cf7ffbf55ca704fe7a20397f19f3 Mon Sep 17 00:00:00 2001 From: nate Date: Thu, 12 Oct 2023 11:52:11 -0700 Subject: [PATCH 05/12] Sort definitions alphabetically. --- src/terminology.md | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/src/terminology.md b/src/terminology.md index 0cf15aa..815b33a 100644 --- a/src/terminology.md +++ b/src/terminology.md @@ -2,6 +2,8 @@ This book relies on the following terminology. We strive to keep these definitions as precise as possible and their definitions may deviate from uses elsewhere. +Definitions are sorted alphabetically. + ## Terms **Assured Finality**: A protocol property that guarantees that some transactions cannot be reverted by that protocol. As with all protocol guarantees, a protocol assumes certain conditions must be met. A transaction may either be final or not: transactions which are not final may not become final, whereas once transactions do achieve finality they retain that property indefinitely (so long as protocol requirements are met). @@ -10,21 +12,21 @@ Importantly, it is not feasible for any protocol to prevent reversing final tran **Final**: A protocol property of transactions. In this book, this always implies [assured finality](#definition-assured-finality), in contrast to concepts like "probabilistic finality" provided by [PoW](#definition-pow). -**Trailing Finality**: A protocol property wherein transactions become final some time after first appearing in [PoW](#definition-pow) blocks. - -**PoW+TFL**: the overall complete, integrated consensus protocol specified in this book. +**Hybrid Consensus**: A consensus protocol which integrates more than one consensus subprotocol. [PoW+TFL](#definition-pow-tfl) is an instance of a hybrid protocol integrating [PoW](#definition-pow) and [PoS](#definition-pos) protocols. **NU5**: The Zcash consensus protocol as of NU5.[^new-mainnet-precursors] +**Proof-of-Stake**: A PoS protocol achieves consensus on transaction status via taking into account the weighting of staking tokens. PoS protocols fall into a large umbrella and may or may not provide [assured finality](#definition-assured-finality) or other properties this design requires of [TFL](#definition-tfl). + **Proof-of-Work**: A PoW protocol uses Nakamoto consensus pioneered by Bitcoin. The PoW subprotocol within PoW+TFL is a different consensus protocol from [NU5](#definition-nu5) and encompasses more than narrow Nakamoto PoW consensus, including transaction semantics such as for shielded transfers. -*TODO*: Clarify the distinctions between PoW (general consensus), [NU5](#definition-nu5) which includes transaction semantics, and the PoW component of [PoW-TFL](#definition-pow-tfl). These distinctions deserve unique terms. +**PoW+TFL**: the overall complete, integrated consensus protocol specified in this book. **TFL**: The *Trailing Finality Layer* subprotocol within PoW+TFL. This is a new [PoS](#definition-pos) subprotocol which provides [assured finality](#definition-assured-finality) for Zcash. -**Proof-of-Stake**: A PoS protocol achieves consensus on transaction status via taking into account the weighting of staking tokens. PoS protocols fall into a large umbrella and may or may not provide [assured finality](#definition-assured-finality) or other properties this design requires of [TFL](#definition-tfl). +**Trailing Finality**: A protocol property wherein transactions become final some time after first appearing in [PoW](#definition-pow) blocks. -**Hybrid Consensus**: A consensus protocol which integrates more than one consensus subprotocol. [PoW+TFL](#definition-pow-tfl) is an instance of a hybrid protocol integrating [PoW](#definition-pow) and [PoS](#definition-pos) protocols. +*TODO*: Clarify the distinctions between PoW (general consensus), [NU5](#definition-nu5) which includes transaction semantics, and the PoW component of [PoW-TFL](#definition-pow-tfl). These distinctions deserve unique terms. # Footnotes From ddb9fdbd8858445c616baf2c9f86cc48ae90daa2 Mon Sep 17 00:00:00 2001 From: nate Date: Thu, 12 Oct 2023 11:52:41 -0700 Subject: [PATCH 06/12] Remove the references to `blocks` in introduction so that it refers only of defined terms. --- src/introduction.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/introduction.md b/src/introduction.md index aafd8a5..58e3c48 100644 --- a/src/introduction.md +++ b/src/introduction.md @@ -2,6 +2,6 @@ This book introduces and specifies a [*Trailing Finality Layer*](./terminology.md#definition-tfl) for the Zcash network. -This design augments the existing Zcash Proof-of-Work ([PoW](./terminology.md#definition-pow)) network with a new consensus layer which provides [*trailing finality*](./terminology.md#definition-trailing-finality). This layer enables blocks produced via PoW to become [*final*](./terminology.md#definition-final) which ensures they may never be rolled back. This enables safer and simpler wallets and other infrastructure, and aids trust-minimized cross-chain bridges. This consensus layer uses [*Proof-of-Stake*](./terminology.md#definition-pos) consensus, and enables ZEC holders to earn protocol rewards for contributing to the security of the Zcash network. By integrating a PoS layer with the current PoW Zcash protocol, this design specifies a [*hybrid consensus*](./terminology.md#definition-hybrid-consensus) protocol dubbed [PoW+TFL](./terminology.md#definition-pow-tfl). +This design augments the existing Zcash Proof-of-Work ([PoW](./terminology.md#definition-pow)) network with a new consensus layer which provides [*trailing finality*](./terminology.md#definition-trailing-finality). This layer enables transactions included via PoW to become [*final*](./terminology.md#definition-final) which ensures they may never be rolled back. This enables safer and simpler wallets and other infrastructure, and aids trust-minimized cross-chain bridges. This consensus layer uses [*Proof-of-Stake*](./terminology.md#definition-pos) consensus, and enables ZEC holders to earn protocol rewards for contributing to the security of the Zcash network. By integrating a PoS layer with the current PoW Zcash protocol, this design specifies a [*hybrid consensus*](./terminology.md#definition-hybrid-consensus) protocol dubbed [PoW+TFL](./terminology.md#definition-pow-tfl). The rest of this introductory chapter is aimed at a general audience interested in the context of this proposal within Zcash development, status and next steps, motivations, a primer on finality, and tips to get involved. From 0a8fe31d4d09cecd1fe915ef8684d4700f42a05a Mon Sep 17 00:00:00 2001 From: Nathan Wilcox Date: Mon, 16 Oct 2023 11:29:15 -0700 Subject: [PATCH 07/12] Update src/introduction.md Clarify finality is a protocol property. Co-authored-by: Daira Emma Hopwood --- src/introduction.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/introduction.md b/src/introduction.md index 58e3c48..7a1566d 100644 --- a/src/introduction.md +++ b/src/introduction.md @@ -2,6 +2,6 @@ This book introduces and specifies a [*Trailing Finality Layer*](./terminology.md#definition-tfl) for the Zcash network. -This design augments the existing Zcash Proof-of-Work ([PoW](./terminology.md#definition-pow)) network with a new consensus layer which provides [*trailing finality*](./terminology.md#definition-trailing-finality). This layer enables transactions included via PoW to become [*final*](./terminology.md#definition-final) which ensures they may never be rolled back. This enables safer and simpler wallets and other infrastructure, and aids trust-minimized cross-chain bridges. This consensus layer uses [*Proof-of-Stake*](./terminology.md#definition-pos) consensus, and enables ZEC holders to earn protocol rewards for contributing to the security of the Zcash network. By integrating a PoS layer with the current PoW Zcash protocol, this design specifies a [*hybrid consensus*](./terminology.md#definition-hybrid-consensus) protocol dubbed [PoW+TFL](./terminology.md#definition-pow-tfl). +This design augments the existing Zcash Proof-of-Work ([PoW](./terminology.md#definition-pow)) network with a new consensus layer which provides [*trailing finality*](./terminology.md#definition-trailing-finality). This layer enables transactions included via PoW to become [*final*](./terminology.md#definition-final) which assures that they cannot be reverted by the protocol. This enables safer and simpler wallets and other infrastructure, and aids trust-minimized cross-chain bridges. This consensus layer uses [*Proof-of-Stake*](./terminology.md#definition-pos) consensus, and enables ZEC holders to earn protocol rewards for contributing to the security of the Zcash network. By integrating a PoS layer with the current PoW Zcash protocol, this design specifies a [*hybrid consensus*](./terminology.md#definition-hybrid-consensus) protocol dubbed [PoW+TFL](./terminology.md#definition-pow-tfl). The rest of this introductory chapter is aimed at a general audience interested in the context of this proposal within Zcash development, status and next steps, motivations, a primer on finality, and tips to get involved. From 47860734f688727580d892093ba6a5aa7d8d23ea Mon Sep 17 00:00:00 2001 From: Nathan Wilcox Date: Mon, 16 Oct 2023 11:30:04 -0700 Subject: [PATCH 08/12] Update src/terminology.md Use "assures" rather than "guarantees" to avoid introducing excessive terminology. Co-authored-by: Daira Emma Hopwood --- src/terminology.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/terminology.md b/src/terminology.md index 815b33a..71c2c94 100644 --- a/src/terminology.md +++ b/src/terminology.md @@ -6,7 +6,7 @@ Definitions are sorted alphabetically. ## Terms -**Assured Finality**: A protocol property that guarantees that some transactions cannot be reverted by that protocol. As with all protocol guarantees, a protocol assumes certain conditions must be met. A transaction may either be final or not: transactions which are not final may not become final, whereas once transactions do achieve finality they retain that property indefinitely (so long as protocol requirements are met). +**Assured Finality**: A protocol property that assures that transactions cannot be reverted by that protocol. As with all protocol guarantees, a protocol assumes certain conditions must be met. A transaction may either be final or not: transactions which are not final may not become final, whereas once transactions do achieve finality they retain that property indefinitely (so long as protocol requirements are met). Importantly, it is not feasible for any protocol to prevent reversing final transactions "out of band" from the protocol, such as if a sufficiently large and motivated group of users forks the network to include a specific new validity rule reverting transactions. For this reason, we forego the term "absolute finality" sometimes used in consensus protocol technical discussions. From e906ab4c01cb67e043c80ffea06303e3271f33b2 Mon Sep 17 00:00:00 2001 From: Nathan Wilcox Date: Mon, 16 Oct 2023 11:30:43 -0700 Subject: [PATCH 09/12] Wording improvement in `terminology.md`. Co-authored-by: Daira Emma Hopwood --- src/terminology.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/terminology.md b/src/terminology.md index 71c2c94..9bb26d9 100644 --- a/src/terminology.md +++ b/src/terminology.md @@ -8,7 +8,7 @@ Definitions are sorted alphabetically. **Assured Finality**: A protocol property that assures that transactions cannot be reverted by that protocol. As with all protocol guarantees, a protocol assumes certain conditions must be met. A transaction may either be final or not: transactions which are not final may not become final, whereas once transactions do achieve finality they retain that property indefinitely (so long as protocol requirements are met). -Importantly, it is not feasible for any protocol to prevent reversing final transactions "out of band" from the protocol, such as if a sufficiently large and motivated group of users forks the network to include a specific new validity rule reverting transactions. For this reason, we forego the term "absolute finality" sometimes used in consensus protocol technical discussions. +Importantly, it is not feasible for any protocol to prevent reversing final transactions "out of band" from the protocol, such as if a sufficiently large and motivated group of users forks the network to include a specific new validity rule reverting transactions. For this reason, we forego the term "absolute finality" sometimes used in technical discussions about consensus protocols. **Final**: A protocol property of transactions. In this book, this always implies [assured finality](#definition-assured-finality), in contrast to concepts like "probabilistic finality" provided by [PoW](#definition-pow). From 85d52e104d84247ac460da020b023ecd6fb02047 Mon Sep 17 00:00:00 2001 From: Nathan Wilcox Date: Mon, 16 Oct 2023 11:31:15 -0700 Subject: [PATCH 10/12] `src/terminology.md`: Fix "which" / "that" conflation. Co-authored-by: Daira Emma Hopwood --- src/terminology.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/terminology.md b/src/terminology.md index 9bb26d9..e37ebeb 100644 --- a/src/terminology.md +++ b/src/terminology.md @@ -12,7 +12,7 @@ Importantly, it is not feasible for any protocol to prevent reversing final tran **Final**: A protocol property of transactions. In this book, this always implies [assured finality](#definition-assured-finality), in contrast to concepts like "probabilistic finality" provided by [PoW](#definition-pow). -**Hybrid Consensus**: A consensus protocol which integrates more than one consensus subprotocol. [PoW+TFL](#definition-pow-tfl) is an instance of a hybrid protocol integrating [PoW](#definition-pow) and [PoS](#definition-pos) protocols. +**Hybrid Consensus**: A consensus protocol that integrates more than one consensus subprotocol. [PoW+TFL](#definition-pow-tfl) is an instance of a hybrid protocol integrating [PoW](#definition-pow) and [PoS](#definition-pos) protocols. **NU5**: The Zcash consensus protocol as of NU5.[^new-mainnet-precursors] From 4eba3e54f4921fe9e45849458b5e1a251c6fc768 Mon Sep 17 00:00:00 2001 From: Nathan Wilcox Date: Mon, 16 Oct 2023 11:31:58 -0700 Subject: [PATCH 11/12] `src/terminology.md`: metaphor consistency improvement Co-authored-by: Daira Emma Hopwood --- src/terminology.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/terminology.md b/src/terminology.md index e37ebeb..53d4752 100644 --- a/src/terminology.md +++ b/src/terminology.md @@ -16,7 +16,7 @@ Importantly, it is not feasible for any protocol to prevent reversing final tran **NU5**: The Zcash consensus protocol as of NU5.[^new-mainnet-precursors] -**Proof-of-Stake**: A PoS protocol achieves consensus on transaction status via taking into account the weighting of staking tokens. PoS protocols fall into a large umbrella and may or may not provide [assured finality](#definition-assured-finality) or other properties this design requires of [TFL](#definition-tfl). +**Proof-of-Stake**: A PoS protocol achieves consensus on transaction status by taking into account the weighting of staking tokens. PoS protocols exist under a large umbrella and may or may not provide [assured finality](#definition-assured-finality) or other properties this design requires of [TFL](#definition-tfl). **Proof-of-Work**: A PoW protocol uses Nakamoto consensus pioneered by Bitcoin. The PoW subprotocol within PoW+TFL is a different consensus protocol from [NU5](#definition-nu5) and encompasses more than narrow Nakamoto PoW consensus, including transaction semantics such as for shielded transfers. From 87bab55a39e19d2f294a278e79e2a890c4cc68fb Mon Sep 17 00:00:00 2001 From: Daira Emma Hopwood Date: Tue, 17 Oct 2023 11:01:23 +0100 Subject: [PATCH 12/12] "forego" -> "eschew" MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit "Forgo" and "eschew" are synonyms but there's a subtle difference: "forgo" implies that we're giving up something — often reluctantly; while "eschew" means just that we're intentionally not using it, without implication of reluctance or hardship. (Aside: I would consider "forego" to be, in this case, just an alternate spelling of "forgo". Apparently someone says this is "incorrect", but they also say that Charles Dickens and Emily Brontë agree with me. And that Brontë's use of it in the "giving up something" sense in Wuthering Heights is a "misspelling". I mean come on. Also Oxford Languages agrees that it's an alternate spelling. So that *isn't* the reason we're changing it.) --- src/terminology.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/terminology.md b/src/terminology.md index 53d4752..7bb81fb 100644 --- a/src/terminology.md +++ b/src/terminology.md @@ -8,7 +8,7 @@ Definitions are sorted alphabetically. **Assured Finality**: A protocol property that assures that transactions cannot be reverted by that protocol. As with all protocol guarantees, a protocol assumes certain conditions must be met. A transaction may either be final or not: transactions which are not final may not become final, whereas once transactions do achieve finality they retain that property indefinitely (so long as protocol requirements are met). -Importantly, it is not feasible for any protocol to prevent reversing final transactions "out of band" from the protocol, such as if a sufficiently large and motivated group of users forks the network to include a specific new validity rule reverting transactions. For this reason, we forego the term "absolute finality" sometimes used in technical discussions about consensus protocols. +Importantly, it is not feasible for any protocol to prevent reversing final transactions "out of band" from the protocol, such as if a sufficiently large and motivated group of users forks the network to include a specific new validity rule reverting transactions. For this reason, we eschew the term "absolute finality" sometimes used in technical discussions about consensus protocols. **Final**: A protocol property of transactions. In this book, this always implies [assured finality](#definition-assured-finality), in contrast to concepts like "probabilistic finality" provided by [PoW](#definition-pow).