From ffe89cf1cac3a80a38061fb04f7646342d4f2d8e Mon Sep 17 00:00:00 2001 From: Daira Emma Hopwood Date: Wed, 1 Nov 2023 00:21:26 +0000 Subject: [PATCH] Apply Daira Emma's suggestions from review --- src/overview/design-at-a-glance.md | 6 +++--- src/terminology.md | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/overview/design-at-a-glance.md b/src/overview/design-at-a-glance.md index 7ca6c62..7d65854 100644 --- a/src/overview/design-at-a-glance.md +++ b/src/overview/design-at-a-glance.md @@ -1,6 +1,6 @@ # Design at a Glance -The [PoW+TFL](../terminology.md#definition-pow-tfl) consensus protocol is logically an extension of the Zcash consensus rules to introduce [trailing finality](../terminology.md#definition-trailing-finality). This is achieved by compartmentalizing the top-level PoW+TFL protocol into two [consensus subprotocols](../terminology.md#definition-consensus-subprotocols), one embodying most of the current consensus logic of Zcash and another the TFL. These protocols interact through a [hybrid construction](../terminology.md#definition-hybrid-construction), which specifies how the protocols interact, and what changes from "off-the-shelf" behavior, if any, need to be imposed on the subprotocols. Each of these components (the two subprotocols and the hybrid construction) are somewhat modular: different subprotocols or hybrid constructions may be combined (with some modification) to product a candidate [PoW+TFL](../terminology.md#definition-pow-tfl) protocol. +The [PoW+TFL](../terminology.md#definition-pow-tfl) consensus protocol is logically an extension of the Zcash consensus rules to introduce [trailing finality](../terminology.md#definition-trailing-finality). This is achieved by compartmentalizing the top-level PoW+TFL protocol into two [consensus subprotocols](../terminology.md#definition-consensus-subprotocols), one embodying most of the current consensus logic of Zcash and another the TFL. These protocols interact through a [hybrid construction](../terminology.md#definition-hybrid-construction), which specifies how the protocols interact, and what changes from "off-the-shelf" behavior, if any, need to be imposed on the subprotocols. Each of these components (the two subprotocols and the hybrid construction) are somewhat modular: different subprotocols or hybrid constructions may be combined (with some modification) to produce a candidate [PoW+TFL](../terminology.md#definition-pow-tfl) protocol. **TODO:** Add consensus subprotocol diagram. @@ -8,8 +8,8 @@ The [PoW+TFL](../terminology.md#definition-pow-tfl) consensus protocol is logica The [hybrid construction](../terminology.md#definition-hybrid-construction) is a major design component of the full consensus protocol which specifies how the subprotocols integrate. So far we have considered three candidates: -1. The implied/loosely defined hybrid construction presented at Zcon4. **TODO: Link** -2. The [Snap-and-Chat](../terminology.md#definition-snap-and-chat) from the Ebb-and-Flow paper. **TODO: Add References and link.** +1. The implied/loosely defined hybrid construction [presented at Zcon4](https://www.youtube.com/watch?v=qhMzMYeEPMM&list=PL40dyJ0UYTLII7oQRQmNOFf0d2iKT35tL&index=17). +2. The [Snap-and-Chat](../terminology.md#definition-snap-and-chat) from the [Ebb-and-Flow paper](https://eprint.iacr.org/2020/1091). 3. The [Crosslink](../terminology.md#definition-crosslink) construction. Currently we believe [Crosslink](../terminology.md#definition-crosslink) is the best candidate, due to security considerations. diff --git a/src/terminology.md b/src/terminology.md index a71346e..2374d46 100644 --- a/src/terminology.md +++ b/src/terminology.md @@ -26,7 +26,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] -**Objective Validity**: A validity property of a protocol history (such as a ledger) which can be computed purely from that history with no other context. +**Objective Validity**: A validity property of a protocol history (such as a ledger) which can be computed purely from that history with no other context. Objective validity is needed to define consensus rules that will lead to the same protocol state being eventually agreed on by all nodes. **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).