From 9f73ce4ad2fd9387f8c5976ba69ed532330ff100 Mon Sep 17 00:00:00 2001 From: nate Date: Mon, 16 Oct 2023 11:49:28 -0700 Subject: [PATCH 1/4] `a-path-to-pos-zcash.md`: Linkify intro; add generic tech tree diagram. --- src/diagrams/zcash-tech-tree-generic.dot | 42 ++++++++++++++++++++++++ src/introduction/a-path-to-pos-zcash.md | 8 +++-- 2 files changed, 48 insertions(+), 2 deletions(-) create mode 100644 src/diagrams/zcash-tech-tree-generic.dot diff --git a/src/diagrams/zcash-tech-tree-generic.dot b/src/diagrams/zcash-tech-tree-generic.dot new file mode 100644 index 0000000..0d71956 --- /dev/null +++ b/src/diagrams/zcash-tech-tree-generic.dot @@ -0,0 +1,42 @@ +digraph ZcashTechTreeGeneric { + rankdir = RL + color = "lightgrey" + + node [ shape=box ] + + nu5 [ label = "NU5 Protocol" ] + + a [ label = "Feature A"] + a -> nu5 + + b [ label = "Feature B"] + b -> a + + c [ label = "Feature C"] + c -> nu5 + + d [ label = "Feature D"] + d -> c + d -> a + + e [ label = "Feature E"] + e -> pos2 + + f [ label = "Feature F"] + f -> e + f -> d + + pos1 [ label = "PoS Step 1"] + pos1 -> nu5 + + subgraph cluster_pos { + label = "PoS Transition" + + pos2 [ label = "PoS Step 2"] + pos2 -> pos1 + + pos3 [ label = "PoS Step 3"] + pos3 -> pos2 + } +} + diff --git a/src/introduction/a-path-to-pos-zcash.md b/src/introduction/a-path-to-pos-zcash.md index a350b2c..271cd59 100644 --- a/src/introduction/a-path-to-pos-zcash.md +++ b/src/introduction/a-path-to-pos-zcash.md @@ -1,12 +1,16 @@ # A Path to Proof-of-Stake Zcash -This Trailing Finality Layer (TFL) design provides a possible first step in transitioning [Zcash](https://z.cash) to a Proof-of-Stake (PoS) protocol. Here we describe how a transition to PoS relates to "the Zcash roadmap" and how TFL fits into one approach to a PoS transition. +The [TFL](./terminology.md#definition-tfl) design provides a possible first step in transitioning [Zcash](https://z.cash) to a [PoS](./terminology.md#definition-pos) protocol. Here we describe how a transition to PoS relates to "the Zcash roadmap" and how TFL fits into one approach to a PoS transition. ## The Zcash Tech-Tree There are multiple developer orgs working on different proposed features for Zcash. Some of these involve multiple large distinct upgrade steps, and several of these steps depend on other such steps. This could be represented as a directed-acyclic graph. We have begun referring to this space of possible future improvements as the *Zcash Tech-Tree*, taking inspiration from an analogous concept in gaming.[^tech-tree-history] -We envision a *proof-of-stake transition path* as one of the potential paths within this tech-tree which is the primary protocol focus of this proposal. +We envision a *proof-of-stake transition path* as one of the potential paths within this tech-tree which is the primary protocol focus of this proposal. An example visualization of this Zcash Tech-Tree might look like this: + +```dot process +{{#include ../diagrams/zcash-tech-tree-generic.dot}} +``` ## A Proof-of-Stake Transition Path From c09930e437db79c3d9e185c17b6df9ef836e6a43 Mon Sep 17 00:00:00 2001 From: nate Date: Mon, 16 Oct 2023 11:55:44 -0700 Subject: [PATCH 2/4] `a-path-to-pos-zcash.md`: Add a tech tree diagram with TFL. Hedge goals a bit. --- src/diagrams/zcash-tech-tree-tfl-steps.dot | 43 ++++++++++++++++++++++ src/introduction/a-path-to-pos-zcash.md | 8 +++- 2 files changed, 50 insertions(+), 1 deletion(-) create mode 100644 src/diagrams/zcash-tech-tree-tfl-steps.dot diff --git a/src/diagrams/zcash-tech-tree-tfl-steps.dot b/src/diagrams/zcash-tech-tree-tfl-steps.dot new file mode 100644 index 0000000..81d3443 --- /dev/null +++ b/src/diagrams/zcash-tech-tree-tfl-steps.dot @@ -0,0 +1,43 @@ +digraph ZcashTechTreeGeneric { + rankdir = RL + color = "lightgrey" + + node [ shape=box ] + + nu5 [ label = "NU5 Protocol" ] + + a [ label = "Feature A"] + a -> nu5 + + b [ label = "Feature B"] + b -> a + + c [ label = "Feature C"] + c -> nu5 + + d [ label = "Feature D"] + d -> c + d -> a + + e [ label = "Feature E"] + e -> pos2 + + f [ label = "Feature F"] + f -> e + f -> d + + pos1 [ label = "TFL v1"] + pos1 -> nu5 + + subgraph cluster_pos { + label = "PoS Transition" + + pos2 [ label = "Pure PoS v1"] + pos2 -> pos1 + + pos3 [ label = "Pure PoS v2"] + pos3 -> pos2 + } +} + + diff --git a/src/introduction/a-path-to-pos-zcash.md b/src/introduction/a-path-to-pos-zcash.md index 271cd59..0e5f5cc 100644 --- a/src/introduction/a-path-to-pos-zcash.md +++ b/src/introduction/a-path-to-pos-zcash.md @@ -21,9 +21,15 @@ Given that context, we envision a "path" within the Zcash Tech-Tree for transiti Our primary motivation for proposing (at least) two steps is to minimize usability, safety, security, and ecosystem distruption during each step. +With this approach, the Zcash Tech Tree with the [TFL](./terminology.md#definition-tfl) approach might look something like this: + +```dot process +{{#include ../diagrams/zcash-tech-tree-tfl-steps.dot}} +``` + ## Design Goals for a Hybrid PoW/PoS System -We are refining the design of TFL with several design goals in mind: +We are refining the design of TFL with several design goals. As we refine the design and make various trade-offs, we may not be able to achieve all of these goals. - We want minimal-to-no disruption for existing wallet use cases and UX. For example, nothing should change for the user flows for storing or transferring funds, the format of addresses, etc… - We want a security analysis of the proposed protocol to be as simple as possible _given_ existing security analyses of current Zcash. From a1f5909c97d0a68b491b426ae5ac1caca997f649 Mon Sep 17 00:00:00 2001 From: nate Date: Thu, 19 Oct 2023 07:58:22 -0700 Subject: [PATCH 3/4] Simplify both Zcash Tech Trees. --- src/diagrams/zcash-tech-tree-generic.dot | 5 +---- src/diagrams/zcash-tech-tree-tfl-steps.dot | 5 +---- 2 files changed, 2 insertions(+), 8 deletions(-) diff --git a/src/diagrams/zcash-tech-tree-generic.dot b/src/diagrams/zcash-tech-tree-generic.dot index 0d71956..56cb29b 100644 --- a/src/diagrams/zcash-tech-tree-generic.dot +++ b/src/diagrams/zcash-tech-tree-generic.dot @@ -21,10 +21,7 @@ digraph ZcashTechTreeGeneric { e [ label = "Feature E"] e -> pos2 - - f [ label = "Feature F"] - f -> e - f -> d + e -> d pos1 [ label = "PoS Step 1"] pos1 -> nu5 diff --git a/src/diagrams/zcash-tech-tree-tfl-steps.dot b/src/diagrams/zcash-tech-tree-tfl-steps.dot index 81d3443..68b1cec 100644 --- a/src/diagrams/zcash-tech-tree-tfl-steps.dot +++ b/src/diagrams/zcash-tech-tree-tfl-steps.dot @@ -21,11 +21,8 @@ digraph ZcashTechTreeGeneric { e [ label = "Feature E"] e -> pos2 + e -> d - f [ label = "Feature F"] - f -> e - f -> d - pos1 [ label = "TFL v1"] pos1 -> nu5 From ff1534500de2bc8c174f1a08c0bdb3e5a8b59c5c Mon Sep 17 00:00:00 2001 From: Daira Emma Hopwood Date: Mon, 23 Oct 2023 16:00:31 +0100 Subject: [PATCH 4/4] Minor wording improvements --- src/introduction/a-path-to-pos-zcash.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/introduction/a-path-to-pos-zcash.md b/src/introduction/a-path-to-pos-zcash.md index 0e5f5cc..0da8834 100644 --- a/src/introduction/a-path-to-pos-zcash.md +++ b/src/introduction/a-path-to-pos-zcash.md @@ -4,7 +4,7 @@ The [TFL](./terminology.md#definition-tfl) design provides a possible first step ## The Zcash Tech-Tree -There are multiple developer orgs working on different proposed features for Zcash. Some of these involve multiple large distinct upgrade steps, and several of these steps depend on other such steps. This could be represented as a directed-acyclic graph. We have begun referring to this space of possible future improvements as the *Zcash Tech-Tree*, taking inspiration from an analogous concept in gaming.[^tech-tree-history] +There are multiple developer orgs working on different proposed features for Zcash. Some of these involve multiple large distinct upgrade steps, and several of these steps depend on other such steps. This could be represented as a directed acyclic graph. We have begun referring to this space of possible future improvements as the *Zcash Tech-Tree*, taking inspiration from an analogous concept in gaming.[^tech-tree-history] We envision a *proof-of-stake transition path* as one of the potential paths within this tech-tree which is the primary protocol focus of this proposal. An example visualization of this Zcash Tech-Tree might look like this: @@ -19,7 +19,7 @@ Given that context, we envision a "path" within the Zcash Tech-Tree for transiti 1. Transitioning from current Zcash PoW to a hybrid PoW/PoS system. 2. Transitioning from a hybrid PoW/PoS system to pure PoS. -Our primary motivation for proposing (at least) two steps is to minimize usability, safety, security, and ecosystem distruption during each step. +Our primary motivation for proposing (at least) two steps is to minimize disruption to usability, safety, security, and the ecosystem during each step. With this approach, the Zcash Tech Tree with the [TFL](./terminology.md#definition-tfl) approach might look something like this: @@ -31,8 +31,8 @@ With this approach, the Zcash Tech Tree with the [TFL](./terminology.md#definiti We are refining the design of TFL with several design goals. As we refine the design and make various trade-offs, we may not be able to achieve all of these goals. -- We want minimal-to-no disruption for existing wallet use cases and UX. For example, nothing should change for the user flows for storing or transferring funds, the format of addresses, etc… -- We want a security analysis of the proposed protocol to be as simple as possible _given_ existing security analyses of current Zcash. +- We want minimal-to-no disruption for existing wallet use cases and UX. For example, nothing should change for the user flows for storing or transferring funds, the format of addresses, etc. +- We want a security analysis of the proposed protocol to be as simple as possible given existing security analyses of current Zcash. - We want to enable new use cases around PoS that allow mobile shielded wallet users to earn a return on delegated ZEC. - We want to enable trust-minimized bridges and other benefits by providing a protocol with assured finality (see [Terminology: Protocol Concepts](../terminology.md#protocol_concepts)). - We want to improve the _modularity_ of the consensus protocol, which has several loosely defined and related meanings, e.g.: it's possible to understand some consensus properties only given knowledge of a "component" of the protocol, and it's possible to implement consensus rules in modular code components with clean interfaces.