2019-03-26 11:23:06 -07:00
|
|
|
::
|
|
|
|
|
2019-05-13 16:11:23 -07:00
|
|
|
ZIP: 210
|
2019-03-26 11:23:06 -07:00
|
|
|
Title: Sapling Anchor Deduplication within Transactions
|
2019-08-01 01:18:23 -07:00
|
|
|
Owners: Jack Grigg <str4d@electriccoin.co>
|
2019-03-26 11:23:06 -07:00
|
|
|
Status: Draft
|
|
|
|
Category: Consensus
|
|
|
|
Created: 2019-03-27
|
|
|
|
License: MIT
|
|
|
|
|
|
|
|
|
|
|
|
Terminology
|
|
|
|
===========
|
|
|
|
|
|
|
|
The key words "MUST" and "MAY" in this document are to be interpreted as described in
|
|
|
|
RFC 2119. [#RFC2119]_
|
|
|
|
|
|
|
|
The term "network upgrade" in this document is to be interpreted as described in ZIP 200
|
|
|
|
[#zip-0200]_.
|
|
|
|
|
|
|
|
The term "Sapling" in this document is to be interpreted as described in ZIP 205
|
|
|
|
[#zip-0205]_.
|
|
|
|
|
|
|
|
Abstract
|
|
|
|
========
|
|
|
|
|
|
|
|
This proposal defines a modification to the transaction format whereby a single Sapling
|
|
|
|
anchor is used for all Sapling spends. This change removes a potential implementation
|
|
|
|
fingerprint, and reduces the size of Sapling transactions within the block chain.
|
|
|
|
|
|
|
|
|
|
|
|
Motivation
|
|
|
|
==========
|
|
|
|
|
|
|
|
The Sapling network upgrade [#zip-0205]_ introduced new shielded inputs (spends) and
|
|
|
|
outputs. Each spend proves the existence of the note being spent by including the anchor
|
|
|
|
of a Merkle tree that contains the note's commitment, and proving in zero knowledge the
|
|
|
|
existence of a path from the commitment to the anchor (a witness). Valid anchors
|
|
|
|
correspond to the state of the Sapling commitment tree after each block in the chain.
|
|
|
|
|
|
|
|
The choice of anchor leaks information about the note being spent, namely that the note
|
|
|
|
was created no later than the anchor's block height. This is an unavoidable outcome of the
|
|
|
|
Zcash design, and the least information it is possible to leak about a note being spent.
|
|
|
|
However, the Sapling v4 transaction format [#v4-tx]_ includes a separate anchor for each
|
|
|
|
Sapling spend, and thus it is possible to leak additional information by using different
|
|
|
|
anchors for different notes. The anchor selection choices could also be used as a
|
|
|
|
fingerprint to identify transactions created by particular wallet implementations,
|
|
|
|
reducing the privacy set.
|
|
|
|
|
|
|
|
Modifying the transaction format to have a single Sapling anchor field, instead of one
|
|
|
|
field per Sapling spend, removes the ability (within the new transaction format version)
|
|
|
|
to create transactions with this fingerprint. It also reduces the size of the transaction,
|
|
|
|
costing 32 bytes per transaction instead of 32 bytes per spend.
|
|
|
|
|
|
|
|
|
|
|
|
Specification
|
|
|
|
=============
|
|
|
|
|
|
|
|
A new transaction format is defined, identical to the Sapling v4 transaction format
|
|
|
|
except for two changes:
|
|
|
|
|
|
|
|
- The ``anchor`` field in ``SpendDescription`` is removed.
|
|
|
|
- A new field ``saplingAnchor`` is placed between ``vShieldedOutput`` and ``vJoinSplit``,
|
|
|
|
if and only if ``vShieldedSpend`` is not empty.
|
|
|
|
|
|
|
|
Consensus rules that previously applied to individual ``anchor`` entries MUST be applied
|
|
|
|
to ``saplingAnchor``.
|
|
|
|
|
|
|
|
TODO: If this is the only ZIP updating the transaction format in a NU, specify the full
|
|
|
|
transaction format here. Otherwise, reference the new transaction format when specified.
|
|
|
|
|
|
|
|
Implementations that support older transaction formats MAY copy ``saplingAnchor`` into
|
|
|
|
each spend's in-memory representation during parsing to reduce code duplication, and MUST
|
|
|
|
ensure that these per-spend in-memory anchors are all identical prior to serialization.
|
|
|
|
|
|
|
|
|
|
|
|
Rationale
|
|
|
|
=========
|
|
|
|
|
|
|
|
Placing the ``saplingAnchor`` field after ``vShieldedOutput`` means that it can be
|
|
|
|
conditionally included (saving space when there are no Sapling spends), while ensuring
|
|
|
|
that the transaction can still be parsed unambiguously.
|
|
|
|
|
|
|
|
Requiring all Sapling spends to use the same anchor removes a possible performance
|
|
|
|
optimisation in certain classes of (particularly light) wallets, where witnesses for older
|
|
|
|
notes are only updated periodically instead of every block. This optimisation is exactly
|
|
|
|
the kind of behaviour that can be used as a fingerprint in the v4 transaction format, and
|
|
|
|
that we are choosing to prevent with this proposal.
|
|
|
|
|
|
|
|
|
|
|
|
Security and Privacy Considerations
|
|
|
|
===================================
|
|
|
|
|
|
|
|
This proposal eliminates a possible avenue for distinguishing transactions based on the
|
|
|
|
client implementation that created them.
|
|
|
|
|
|
|
|
|
|
|
|
Reference Implementation
|
|
|
|
========================
|
|
|
|
|
|
|
|
TBD
|
|
|
|
|
|
|
|
|
|
|
|
References
|
|
|
|
==========
|
|
|
|
|
2020-02-29 07:51:03 -08:00
|
|
|
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
|
2019-11-07 12:28:29 -08:00
|
|
|
.. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism <zip-0200.rst>`_
|
|
|
|
.. [#zip-0205] `ZIP 205: Deployment of the Sapling Network Upgrade <zip-0205.rst>`_
|
|
|
|
.. [#v4-tx] `Section 7.1: Encoding of Transactions. Zcash Protocol Specification, Version 2019.0-beta-37 [Overwinter+Sapling] <protocol/protocol.pdf>`_
|