Electric-Coin-Company · nathan-at-least · Oct 23, 2023 · Oct 19, 2023 · Oct 19, 2023 · Oct 23, 2023
diff --git a/src/introduction/get-involved.md b/src/introduction/get-involved.md
@@ -18,7 +18,7 @@ If you have a Github account, you can get hands on via [the github repository](h
 
 ## 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
 

diff --git a/src/introduction/status-and-next-steps.md b/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) as well as 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 implementation of the [TFL](../terminology.md#definition-tfl) design goals. The essential design details are specified, along with a security argument of 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-tfl) 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-tfl)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:
 
-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.
+1. Complete [Crosslink](../terminology.md#definition-crosslink) protocol specification.
+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-tfl) to analyze all cases of interest.
+6. Follow the general Zcash process for proposal/review/refinement, including proposing  or more [ZIP](../terminology.md#definition-tfl)s.
 7. Follow the general Zcash governance process for proposal acceptance.
 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. 🎉
+
+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 contributing.
diff --git a/src/terminology.md b/src/terminology.md
@@ -10,10 +10,14 @@ Definitions are sorted alphabetically.
 
 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.
 
+<span id="definition-crosslink"></span>**Crosslink**: A hybrid consensus protocol construction striving to implement the [TFL](#definition-tfl) design goals. See [Status and Next Steps: Current Components](./introduction/status-and-next-steps.md#Current Components) for current status.
+
 <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).
 
 <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-liveness"></span>**Liveness**: The property of a distributed protocol which ensures that the protocol may progress provided liveness requirements are met. **TODO:** Fix this definition, which begs the question by failing to define "progress".
+
 <span id="definition-nu5"></span>**NU5**: The Zcash consensus protocol as of NU5.[^new-mainnet-precursors]
 
 <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).
@@ -22,10 +26,16 @@ Importantly, it is not feasible for any protocol to prevent reversing final tran
 
 <span id="definition-pow-tfl"></span>**PoW+TFL**: the overall complete, integrated consensus protocol specified in this book.
 
+<span id="definition-safety"></span>**Safety**: The property of a distributed protocol that guarantees a participant may safely rely on a consistent local state, provided safety requirements are met. **TODO:** Fix this definition.
+
+<span id="definition-simtfl"></span>**`simtfl`**: a protocol simulator for analyzing [TFL](#definition-tfl) security and abstract performance. Development lives at <https://github.com/zcash/simtfl>. See [Status and Next Steps: Current Components](./introduction/status-and-next-steps.md#Current Components) for current status.
+
 <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-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-zip"></span>**ZIP**: a Zcash Improvement Proposal is the protocol development process the Zcash community uses to safely define potential protocol improvements. See <https://zips.z.cash>.
+
 *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