-
Notifications
You must be signed in to change notification settings - Fork 2k
design
This page discusses the design of the Zcash protocol as well as the reference implementation code design.
Contents
The Zcash protocol integrates the Bitcoin protocol with the Zerocash protocol. There exist several approaches to this integration with a multitude of engineering constraints and design tradeoffs.
This page attempts to document the "academic prototype integration" as well as proposing one or more alternative integrations. Ideally we'd have both Bitcoin experts (with a good knowledge of the historical evolution as well as core implementation) and Zerocash experts help us in selecting the best design.
Our goals for an integration design are:
- PG1. Fundamental Security
- The protocol design preserves the security properties of the Zerocash protocol as much as feasible.
- PG2. Conservative Protocol Delta
- The protocol design makes as few exceptions to the Bitcoin consensus protocol as possible.
- PG3. Robust Tracking of Bitcoin Evolution
- The protocol design is robust towards protocol upgrades which follow upstream Bitcoin's protocol upgrades.
- IG1. Minimally Complex Implementation
- The implementation is relatively easy to explain to engineers familiar with Bitcoin.
- IG2. Robust Tracking of Bitcoin Core Implementation
- The implementation can easily incorporate useful upstream code changes which don't impact our protocol or implementation goals.
- IG3. Usable Security
- The implementation defaults to secure behavior and the user flow does not involve more complexity than Bitcoin to achieve our security goals.
Exceptions to upstream are a crucial and difficult issue.
Practical consensus is "brittle": every behavior of the majority-implementation is de facto consensus, whether or not it is a "bug" or humans are or are not aware of it.
Any code paths which affect consensus that are different versus Bitcoin core carry a risk of implicit exceptions to upstream consensus. The risk is that Zcash may fork where Bitcoin does not fork, even when users behave identically.
An important distinction is between exceptions to concensus rules, and the "standard policy" (eg: the default policy of the most commonly deployed software).
For example, Bitcoin clients can choose whether or not to relay transactions based on a heuristic "priority" system. How Zcash integrates Zerocash into the protocol may affect the standard policy as well as consensus rules itself.
Additionally, we may choose to have distinct policies from Bitcoin. For example we may say "if a transaction is a Zerocash Pour, then treat the priority calculation specially". Any such choice should be carefully evaluated since it contends with PG2.
There are invariants in both Bitcoin protocol and the reference implementation which may not be apparent, even given infinite code review! We need to understand not only extant invariants, but how they may affect future design choices for upstream.
For example, there is a consensus rule in upstream that every transaction must have at least one TxOut. Logically, a transaction with a Mint may not need a TxOut, since a Mint does not emit any "cleartext currency". However, if we made an exception to this consensus rule, we would also be violating an invariant that's depended on throughout the codebase.
It seems like a win if we can exclude swaths of code when considering how the design introduces exceptions from upstream.
For example, the academic prototype design makes exceptions to Script processing and TxIn semantics. This in turn affects Script interpretation, (non-ZC) signature verification, Transaction balance invariants, prevout pointers, and UTXO spend/unspent invariants. (This list may not be comprehensive.) If an alternative design is known to not affect any of those code areas, it may better meet most of our protocol and implementation goals.
#. Document the current "academic prototype design" and enumerate the exceptions we're aware of. Stack them up against the goals.
- Any alternative proposal needs comparison versus prototype design as
well as all other alternatives along these axes:
- how it stacks up against the goals
- which exceptions to upstream are necessary
- Every tx has at least one input or output.
- Every tx has a unique hash (in bitcoin: prevout pointers plus the height-encoding in coinbase guarantees this). (HT: sipa on #bitcoin-wizards)