-
Notifications
You must be signed in to change notification settings - Fork 2
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #78 from Electric-Coin-Company/update-introduction…
…-and-terminology-anticipating-crosslink Update introduction and terminology.
- Loading branch information
Showing
2 changed files
with
16 additions
and
47 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -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. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -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 | ||
| <span id="definition-assured-finality"></span>**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). | ||
|
|
||
| <span id="definition-assured-finality"></span>**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. | ||
| <span id="definition-final"></span>**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 | ||
| <span id="definition-hybrid-consensus"></span>**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. | ||
|
|
||
| <span id="definition-pow-tfl"></span>**PoW+TFL**: the overall complete, integrated consensus protocol specified in this book. | ||
|
|
||
| <span id="definition-nu5"></span>**NU5**: the Zcash consensus protocol as of NU5.[^new-mainnet-precursors] | ||
|
|
||
| <span id="definition-pow"></span>**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. | ||
|
|
||
| <span id="definition-tfl"></span>**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. | ||
|
|
||
| <span id="definition-validator"></span>**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] | ||
|
|
||
| <span id="definition-block-proposer"></span>**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. | ||
|
|
||
| <span id="definition-pow-proposer"></span>**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: | ||
| <span id="definition-nu5"></span>**NU5**: The Zcash consensus protocol as of NU5.[^new-mainnet-precursors] | ||
|
|
||
| <span id="definition-pow-hashrate-provider"></span>**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". | ||
| <span id="definition-pos"></span>**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). | ||
|
|
||
| <span id="definition-block-finalizer"></span>**Block Finalizer**: a component which contributes to consensus progress on the *finality* of a block. | ||
| <span id="definition-pow"></span>**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. | ||
|
|
||
| <span id="definition-wallet-viewer"></span>**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. | ||
|
|
||
| <span id="definition-wallet-spender"></span>**Wallet Spender**: a component that enables generating new transactions which transfer funds to recipients. | ||
|
|
||
| ## Blockchain State | ||
|
|
||
|
|
||
| <span id="definition-transaction"></span>**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*. | ||
|
|
||
| <span id="definition-block"></span>**Block**: **\[TODO\]** | ||
|
|
||
| <span id="definition-block-history"></span>**Block History**: **\[TODO\]** _(nodes can see multiple local histories and select one as canonical according to consensus) | ||
|
|
||
| <span id="definition-pending-blocks"></span>**Pending Blocks**: **\[TODO\]** | ||
| <span id="definition-pow-tfl"></span>**PoW+TFL**: the overall complete, integrated consensus protocol specified in this book. | ||
|
|
||
| <span id="definition-pending-transactions"></span>**Pending Transactions**: **\[TODO\]** | ||
| <span id="definition-tfl"></span>**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. | ||
|
|
||
| <span id="definition-final-blocks"></span>**Final Blocks**: **\[TODO\]** | ||
| <span id="definition-trailing-finality"></span>**Trailing Finality**: A protocol property wherein transactions become final some time after first appearing in [PoW](#definition-pow) blocks. | ||
|
|
||
| <span id="definition-final-transactions"></span>**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. |