Update "Getting Involved" and "Next Steps" with discord, DAG, Crosslink overview, and simtfl overview.

src/introduction/a-path-to-pos-zcash.md

@@ -14,7 +14,7 @@ We envision a *proof-of-stake transition path* as one of the potential paths wit
 
 ## A Proof-of-Stake Transition Path
 
-Given that context, we envision a "path" within the Zcash Tech-Tree for transitioning Zcash to PoS. At the top-level we propose this path contains at least two major milestones:
+Given that context, we envision a "path" within the Zcash Tech-Tree for transitioning Zcash to PoS. At the top level we propose that this path contain at least two major milestones:
 
 1. Transitioning from current Zcash PoW to a hybrid PoW/PoS system.
 2. Transitioning from a hybrid PoW/PoS system to pure PoS.
@@ -34,8 +34,8 @@ We are refining the design of TFL with several design goals. As we refine the de
 - 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.
+- We want to enable trust-minimized bridges and other benefits by providing a protocol with [assured finality](../terminology.md#definition-assured-finality).
+- We want to improve the _modularity_ of the consensus protocol. That is, it should be possible to understand some consensus properties only given knowledge of a "component" of the protocol, and it should be possible to implement consensus rules in modular code components with clean interfaces.
 
 We will be refining these goals and potentially adding more as we continue to develop this proposal.
 

src/introduction/get-involved.md

@@ -6,19 +6,19 @@ There are a variety of ways to contribute to this project:
 
 ## Github
 
-If you have a Github account, you can get hands on via [the github repository](https://github.com/nathan-at-least/tfl-book) for this book, including:
+If you have a GitHub account, you can get hands-on via [the GitHub repository](https://github.com/nathan-at-least/tfl-book) for this book, including:
 
 - [Ask a Question](https://github.com/nathan-at-least/tfl-book/issues/new?assignees=nathan-at-least&labels=question&projects=&template=question.yml) - all questions welcome from basics to in-depth.
-- [Suggest an Improvement](https://github.com/nathan-at-least/tfl-book/issues/new?assignees=nathan-at-least&labels=improvement&projects=&template=improvement.yml) to the content, anything from typo fixes to major design change proposals.
+- [Suggest an Improvement](https://github.com/nathan-at-least/tfl-book/issues/new?assignees=nathan-at-least&labels=improvement&projects=&template=improvement.yml) to the content: anything from typo fixes to major design change proposals.
 - [Report Rendering / Infrastructure Issues](https://github.com/nathan-at-least/tfl-book/issues/new?assignees=nathan-at-least&labels=infrastructure&projects=&template=infrastructure.yml) in case you're having trouble reading the content, viewing diagrams, rendering on your own computer, etc…
 
 ## Zcash Forum
 
-[The Zcash Forum](https://forum.zcashcommunity.com/) is a hangout for many Zcash enthusiasts. This is a good spot for more open ended discussion about this design proposal, alternatives, and other developments in Zcash.
+[The Zcash Forum](https://forum.zcashcommunity.com/) is a hangout for many Zcash enthusiasts. This is a good spot for more open-ended discussion about this design proposal, alternatives, and other developments in Zcash.
 
 ## Zcash R&D Discord
 
-You can catch us on [the Zcash R&D Discord](https://discord.gg/U26xq3R2) in the `#proof-of-stake` channel.
+You can catch us on [the Zcash R&D Discord](https://discord.gg/U26xq3R2) in this [`#proof-of-stake` channel](https://discord.com/channels/809218587167293450/826162958027063377).
 
 ## Zcash Arborist Calls
 

src/introduction/motivating-finality.md

@@ -1,6 +1,6 @@
 # Motivating Finality
 
-In Zcash currently, consensus relies solely on PoW, which only provides *probabilistic finality*, rather than *guaranteed finality*.[^finality-qualifiers] This style of consensus does not offer a guarantee that any given block may not be *rolled back* which may invalidate the transactions it contains. Instead, the probability that a block may be rolled back decreases as more blocks are mined subsquently on top of it.[^pow-rollback-security-assumptions]
+In Zcash currently, consensus relies solely on PoW, which only provides *probabilistic finality*, rather than [*assured finality*](../terminology.md#definition-assured-finality).[^finality-qualifiers] This style of consensus does not offer a guarantee that any given block may not be *rolled back* which may invalidate the transactions it contains. Instead, the probability that a block may be rolled back decreases as more blocks are mined subsquently on top of it.[^pow-rollback-security-assumptions]
 
 Let's walk through an example of how Zcash's current PoW with probabilistic finality can impede important use cases. Consider a PoW node which sees this block sequence at time `T=0`:
 
@@ -26,31 +26,31 @@ In our example, the bridging system acted in response to a transaction in the or
 
 ## Rollback Complications
 
-This example demonstrates how a lack of guaranteed finality can impede many useful real-world scenarios. In practice, systems and services which need greater assurances wait for more block confirmations.
+This example demonstrates how a lack of assured finality can impede many useful real-world scenarios. In practice, systems and services which need greater assurances wait for more block confirmations.
 
 This has several drawbacks:
 
-- it _doesn't remove the vulnerability_, it only reduces the likelihood,
-- different applications/services may require different block depths making it difficult to compose or chain together different applications/services,
-- different block depth policies potentially confuse users, i.e. "why do I have to wait one hour for my deposit in this exchange, but only 30 minutes on that exchange?", and
-- it introduces a delay which inhibits many useful applications.
+- it _doesn't remove the vulnerability_, it only reduces the likelihood;
+- different applications/services may require different block depths, making it difficult to compose or chain together different applications/services;
+- different block depth policies potentially confuse users, i.e. "why do I have to wait one hour for my deposit in this exchange, but only 30 minutes on that exchange?"; and
+- it introduces a long delay which inhibits many useful applications.
 
 In addition to these user-facing and economic drawbacks, correctly handling rollbacks makes the code for nodes, wallets, and other infrastructure more complex. Worse still, many systems may not have correct behavior for rollbacks at different depths, and since large rollbacks are rarer, these implementation flaws may not surface until there is a large rollback. While a large rollback would be disruptive all by itself, it becomes even worse when previously undiscovered bugs exacerbate the situation.
 
 ## Trailing Finality Benefits
 
-Trailing finality extends the existing PoW consensus so that older blocks become final, ensuring they _cannot_ be rolled back, and by extension neither can any of the transactions they contain.
+Trailing finality extends the existing PoW consensus so that older blocks become final, assuring they _cannot_ be rolled back, and by extension neither can any of the transactions they contain.
 
-This directly addresses the first two flaws above: it completely removes the vulnerability and it ensures all systems which need finality behave consistently with each other.
+This directly addresses the first two flaws above: it completely removes the vulnerability, and it ensures all systems that need finality behave consistently with each other.
 
- As for delay, tailing finality also introduces delay since final blocks "trail behind" the most recent PoW blocks. This can be an improvement for some applications, but not others. For example, if the delay to finality averages around 10 minutes, then this would enable an improvement for an exchange which requires 60 minutes of PoW blocks for a deposit. On the other hand, it would not be an improvement for an application that needs finality faster than 10 minutes.
+As for delay, trailing finality also introduces delay since final blocks "trail behind" the most recent PoW blocks. This can be an improvement for some applications, depending on their latency requirements. For example, if the delay to finality averages around 10 minutes, then this would enable an improvement for an exchange that requires 60 minutes of PoW blocks for a deposit. On the other hand, it would not be an improvement for an application that needs finality faster than 10 minutes.
 
 Finally, implementations can be simplified by relying on the guarantee of finality. For example, a wallet can describe any transaction as pending or final, and does not need to provide difficult and potentially confusing UX (and the supporting database sophistication) for handling rollbacks.
 
 # Footnotes
 
-[^finality-qualifiers]: Throughout this book, when we say *finality* or *final* without other qualifiers, we specifically are referring to *guaranteed finality* or a *guaranteed final* block. Where we call out *probabalistic finality* we always use that qualifier.
+[^finality-qualifiers]: Throughout this book, when we say *finality* or *final* without other qualifiers, we specifically are referring to *assured finality* or a *assured final* block. Where we call out *probabalistic finality* we always use that qualifier.
 
 [^pow-rollback-security-assumptions]: The estimated probability of a rollback relies on a variety of PoW security assumptions, and can be violated in various conditions, such as in mining efficiency breakthroughs, compromises of the PoW challenge algorithm (e.g. hash function collision resistance failure), difficulty-adjustment-algorithm failures, sudden/surprise mining capacity increases, and so on. So the estimated probability can be violated in potential "black swan" events.
 
-[^txn-rollback]: This discussion simplifies consideration of *transaction rollback* vs *block rollback*. When a block is rolled back, it is possible for some of the transactions contained in it to appear in new canonical blocks. The conditions when this can occur vs when it cannot are multifaceted and also subject to malicious influence, so for simplicity we assume all transactions within a rolled-back block are also rolled back.
+[^txn-rollback]: This discussion simplifies consideration of *transaction rollback* vs *block rollback*. When a block is rolled back, it is possible for some of the transactions contained in it to appear in new canonical blocks. The conditions when this can occur vs when it cannot are multifaceted and also subject to malicious influence, so for simplicity we assume all transactions within a rolled-back block are also rolled back.

src/introduction/status-and-next-steps.md

@@ -1,29 +1,49 @@
 # Status and Next Steps
 
-This is an early and very incomplete protocol design proposal. It has not been well vetted for feasibility and safety. It has not had broad review from the Zcash community, so its status on any Zcash roadmap is undetermined.
+This is an early and incomplete protocol design proposal. It has not been well vetted for feasibility and safety. It has not had broad review from the Zcash community, so its status on any Zcash roadmap is undetermined.
 
-## Major Missing Elements
+## Current Components
 
-This design is at a very early stage and lacks substantial clarity around essential details. These details must be clarified before this proposal would be ready for the [Zcash Improvement Proposals](https://zips.z.cash) process. They include:
+### This Book
 
-- PoS protocol selection,
+This book is intended to become both a high-level overview and introduction to [TFL](../terminology.md#definition-tfl), and a full specification.
+
+### Crosslink
+
+The current heart of the design work is an in-progress hybrid consensus protocol construction called [Crosslink](../terminology.md#definition-crosslink). This is an in-development realization of the [TFL](../terminology.md#definition-tfl) design goals. The essential design details are specified, along with a security argument for its [liveness](../terminology.md#definition-liveness). The security argument for its [safety](../terminology.md#definition-liveness) is in progress.
+
+The draft specification and security arguments of Crosslink currently live on [this hackmd](https://hackmd.io/JqENg--qSmyqRt_RqY7Whw?view).
+
+### `simtfl`
+
+We've begun creating a simulator called [`simtfl`](../terminology.md#definition-simtfl) which we will use to model security and abstract performance concerns. Its development is tracked at <https://github.com/zcash/simtfl>.
+
+## Major Missing Components
+
+- PoS subprotocol selection,
 - Issuance and supply mechanics, such as how much ZEC stakers may earn,
+- Integrated Zcash transaction semantics,
 - A transition plan from current Zcash mainnet to this protocol design,
-- The specifics of how PoW and PoS safely integrate,
-- Security and safety analysis,
-- Economic analysis,
-- and more.
+- [ZIP](../terminology.md#definition-zip)s specifying the above to the level of specificity required by ZIPs,
+- Security and safety analyses,
+- Economic analyses.
+
+This list may be incomplete, and as the design matures the need for major new components may be revealed.
 
 ## Next Steps
 
-This design proposal is being developed by [ElecticCoin Co](https://electriccoin.co/) as the first major milestone in our focus of deploying Proof-of-Stake to the Zcash protocol. Our rough near term plan for this proposal is as follows:
+This design proposal is being developed by [Electric Coin Company](https://electriccoin.co/) as the first major milestone in our focus of deploying Proof-of-Stake to the Zcash protocol. Our rough near-term plan for this proposal is as follows:
 
-1. Write a very high-level design overview which lacks many details but clarifies the general approach.
-2. Get early feedback from Zcash community and consensus protocol experts on this high level overview.
-3. If there are flaws so substantial that we decide the approach is infeasible, start over with a different PoS transition design.
-4. Otherwise, refine the high-level "overview" into a concrete, comprehensive proposal through multiple milestones with wide review.
-5. As the concrete proposal approaches maturity, draft one or more [Zcash Improvement Proposals](https://zips.z.cash).
-6. Follow the general Zcash process for proposal/review/refinement.
-7. Follow the general Zcash governance process for proposal acceptance.
+1. Complete the [Crosslink](../terminology.md#definition-crosslink) description.
+2. Complete core security arguments for [Crosslink](../terminology.md#definition-crosslink).
+3. Define the [Major Missing Components](#major-missing-components) above, including considerations such as issuance mechanics and Proof-of-Stake mechanisms.
+4. Complete auxillary security arguments and analyses, such as specific attack scenarios, game-theoretic security, and so forth.
+5. Mature [`simtfl`](../terminology.md#definition-simtfl) to analyze all cases of interest.
+6. Follow the general Zcash process for proposal/review/refinement, including proposing one or more [ZIP](../terminology.md#definition-zip)s.
+7. Follow the general Zcash governance process for proposal review and refinement.
 8. If accepted, productionize the proposal in ECC products and collaborate with other implementors who implement the proposal.
-9. Celebrate when the proposal is activated on Mainnet. 🎉
+9. Celebrate when and if the proposal is activated on Mainnet. 🎉
+
+The fine-grained day-to-day goals and tasks for this project are present in [the Zcash Developers Hub](https://zcash.github.io/developers) in the [TFL-focused DAG](https://zcash.github.io/developers/zcash-tfl-dag).
+
+Please also see [Getting Involved](./getting-involved.md) if you are interested in tracking this progress more closely, or in contributing.

src/introduction/trailing-finality-layer-in-a-nutshell.md

@@ -4,7 +4,7 @@ The hybrid PoW/PoS protocol proposed in this book is similar to today's Zcash NU
 
 **TODO**: Add graphic showing nodes connected to each other in the p2p protocol. Each node has two parts: PoW and TFL. Each part has a distinct connection to the neighbors of the same part, so node A's "PoW" connects to node B's "PoW", node A's "TFL" connects to node B's "TFL". Finally, we want some way to visualize that all of the PoW nodes and connections were "pre-existing" and that the TFL pieces are a "new layer".
 
-The Zcash Trailing Finality Layer refers to a new subprotocol of a new hybrid PoW/PoS protocol, which we refer to as *PoW+TFL*. This subprotocol introduces *assured finality* (see [Terminology: Protocol Concepts](../terminology.md#protocol_concepts)) for the Zcash blockchain, ensuring that *final* blocks (and the transactions within them) may never be rolled back.
+The Zcash Trailing Finality Layer refers to a new subprotocol of a new hybrid PoW/PoS protocol, which we refer to as *PoW+TFL*. This subprotocol introduces [assured finality](../terminology.md#definition-assured-finality) for the Zcash blockchain, ensuring that *final* blocks (and the transactions within them) may never be rolled back.
 
 We use the term "layer" because we can understand this design as introducing a new layer to the Zcash network, making only minimal changes to the existing network and consensus protocol. This modular separation is present in the consensus rules, the network protocol, and the code architecture.
 

src/introduction/visualizing-trailing-finality.md

@@ -1,6 +1,6 @@
 # Visualizing Trailing Finality
 
-In the [previous chapter](./motivating-finality.md) we visualized a node's view of consensus in PoW and a valid rollback transition. When we consider a protocol combinging PoW with trailing finality, there are multiple possible transitions:
+In the [previous chapter](./motivating-finality.md) we visualized a node's view of consensus in PoW and a valid rollback transition. When we consider a protocol combining PoW with trailing finality, there are multiple possible transitions:
 
 - PoW can make progress on discovering a new block,
 - finality can make progress on finalizing a previously found block, and
@@ -56,7 +56,7 @@ Now let's consider an invalid attempt to rollback a final block:
 
 ## An Invalid Finality Rollback
 
-At `T=4` the node learns of a new sequence ending in `i''` where each header in the Proof-of-Work sequence is valid and demonstrates sufficient work accoring to pure PoW consensus:
+At `T=4` the node learns of a new sequence ending in `i''` where each header in the Proof-of-Work sequence is valid and demonstrates sufficient work according to pure PoW consensus:
 
 ```dot process
 {{#include ../diagrams/tf-with-invalid-finality-rollback.dot}}
@@ -66,4 +66,4 @@ The sequence `d'' → e'' → f'' → g'' → h'' → i''` is invalid and reject
 
 # Summary
 
-Visualizing these possible transitions of a PoW-with-Trailing-Finality protocol helps provide an intuition about the intended protocols behavior.
+Visualizing these possible transitions of a PoW-with-Trailing-Finality protocol helps provide an intuition about the intended protocol's behavior.