diff --git a/src/introduction.md b/src/introduction.md index 9e5acaf..7a1566d 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 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. diff --git a/src/terminology.md b/src/terminology.md index 2af00e5..7bb81fb 100644 --- a/src/terminology.md +++ b/src/terminology.md @@ -1,64 +1,33 @@ # 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. +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. -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*. +Definitions are sorted alphabetically. -We group terms into related categories as follows: +## Terms -## Protocol Concepts +**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). -**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. +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. - 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). -## Protocol Components +**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. -**PoW+TFL**: the overall complete, integrated consensus protocol specified in this book. - -**NU5**: the Zcash consensus protocol as of NU5.[^new-mainnet-precursors] - -**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. - -**TFL**: the *Trailing Finality Layer* subprotocol within PoW+TFL. - -## 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: +**NU5**: The Zcash consensus protocol as of NU5.[^new-mainnet-precursors] -**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". +**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). -**Block Finalizer**: a component which contributes to consensus progress on the *finality* of a block. +**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. -**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\]** +**PoW+TFL**: the overall complete, integrated consensus protocol specified in this book. -**Pending Transactions**: **\[TODO\]** +**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. -**Final Blocks**: **\[TODO\]** +**Trailing Finality**: A protocol property wherein transactions become final some time after first appearing in [PoW](#definition-pow) blocks. -**Final Transactions**: **\[TODO\]** +*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 [^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.