Merge pull request #87 from Electric-Coin-Company/path-to-pos

Update "A Path to PoS Zcash"

src/diagrams/zcash-tech-tree-generic.dot

@@ -0,0 +1,39 @@
+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
+    e -> 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
+    }
+}
+

src/diagrams/zcash-tech-tree-tfl-steps.dot

@@ -0,0 +1,40 @@
+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
+    e -> 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
+    }
+}
+
+

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]
+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
 
@@ -15,14 +19,20 @@ 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:
+
+```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.
+- 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.