Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix terminology rendering regression. #97

Merged
merged 3 commits into from
Oct 25, 2023
Merged

Fix terminology rendering regression. #97

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
11f49a0
Fix the span rendering regression.
Oct 25, 2023
3b30247
Add a comment to motivate the whitespace.
Oct 25, 2023
91c6c53
Document why the span tags are empty.
Oct 25, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
31 changes: 17 additions & 14 deletions src/terminology.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,42 +6,45 @@ Definitions are sorted alphabetically.

## Terms

<span id="definition-assured-finality">**Assured Finality**</span>: A protocol property that assures that transactions cannot be reverted by that protocol. As with all protocol guarantees, a protocol assumes certain conditions must be met. A transaction may either be final or not: transactions which are not final may not become final, whereas once transactions do achieve finality they retain that property indefinitely (so long as protocol requirements are met).
<!-- Unlike true html, it seems `mdbook` requires the span tags to be empty and immediately pre-fix the intended anchor target. -->
Copy link
Collaborator

@daira daira Oct 25, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mdbook is actually doing the Right Thing, and I should have realised it. The "**" markup is used for bold text in Markdown, but has no special meaning in HTML. An HTML container (such as span) embedded in Markdown should have its contents parsed as the Markdown-supported subset of HTML, not as Markdown. Therefore the rendering with non-bold **Assured Finality**, etc. is correct. You would need <span id="definition-assured-finality"><b>Assured Finality</b></span> (or <strong>, I'm not exactly sure which tags are supported) to get bold text within a span. In any case this is fine for now. I will fix the comment in my next PR.


<span id="definition-assured-finality"></span>**Assured Finality**: A protocol property that assures that transactions cannot be reverted by that protocol. As with all protocol guarantees, a protocol assumes certain conditions must be met. A transaction may either be final or not: transactions which are not final may not become final, whereas once transactions do achieve finality they retain that property indefinitely (so long as protocol requirements are met).

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. In some cases this might be desirable, for example to mitigate exploitation of a security flaw. We are investigating the implications for governance and how to incorporate such situations into our security model. In any case, for this reason we eschew the term "absolute finality" sometimes used in technical discussions about consensus protocols.

<span id="definition-crosslink">**Crosslink**</span>: 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-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">**Final**</span>: 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-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">**Hybrid Consensus**</span>: 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-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">**Liveness**</span>: 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-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">**NU5**</span>: The Zcash consensus protocol as of NU5.[^new-mainnet-precursors]
<span id="definition-nu5"></span>**NU5**: The Zcash consensus protocol as of NU5.[^new-mainnet-precursors]

<span id="definition-pos">**Proof-of-Stake**</span>: 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).
<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).

<span id="definition-pow">**Proof-of-Work**</span>: A PoW protocol uses Nakamoto consensus pioneered by Bitcoin. The PoW subprotocol within PoW+TFL is a different consensus protocol from [NU5](#definition-nu5) and encompasses more than narrow Nakamoto PoW consensus, including transaction semantics such as for shielded transfers.
<span id="definition-pow"></span>**Proof-of-Work**: A PoW protocol uses Nakamoto consensus pioneered by Bitcoin. The PoW subprotocol within PoW+TFL is a different consensus protocol from [NU5](#definition-nu5) and encompasses more than narrow Nakamoto PoW consensus, including transaction semantics such as for shielded transfers.

<span id="definition-pow-tfl">**PoW+TFL**</span>: the overall complete, integrated consensus protocol specified in this book.
<span id="definition-pow-tfl"></span>**PoW+TFL**: the overall complete, integrated consensus protocol specified in this book.

<span id="definition-safety">**Safety**</span>: 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-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">**`simtfl`**</span>: 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-simtfl"></span>**`simtfl`**: a protocol simulator for analyzing [TFL](#definition-tfl) security and abstract performance. Development lives at <https://github.com/zcash/simtfl></span>. See [Status and Next Steps: Current Components](./introduction/status-and-next-steps.md#current-components) for current status.

<span id="definition-tfl">**TFL**</span>: 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-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">**Trailing Finality**</span>: A protocol property wherein transactions become final some time after first appearing in [PoW](#definition-pow) blocks.
<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">**ZIP**</span>: a Zcash Improvement Proposal is the protocol development process the Zcash community uses to safely define potential protocol improvements. See <https://zips.z.cash>.
<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></span>.

*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

[^new-mainnet-precursors]: If new consensus changes are deployed to Zcash mainnet prior to PoW+TFL design finalization, this design must be updated to refer to the new delta (e.g. by reanalyzing all changes against NU6 or NU7, etc…)

<!-- This trailing whitespace ensures that readers who follow a link to a definition will always see that term at the top of their view. -->
<pre>


Expand Down