zips/zip-0222.rst

::

  ZIP: 222
  Title: Transparent Zcash Extensions
  Owners: Jack Grigg <jack@electriccoin.co>
  Credits: Zaki Manian <zaki@manian.org>
           Daira Hopwood <daira@electriccoin.co>
           Sean Bowe <sean@electriccoin.co>
  Status: Draft
  Category: Consensus
  Created: 2019-07-01
  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 consensus rules that enables complex forms of
transparent output predicates to be deployed in network upgrades. This in turn enables the
creation of "transparent Zcash extensions" that augment the network's functionality in a
carefully-defined and auditable fashion.


Motivation
==========

Zcash transactions have three types of outputs: Sapling shielded outputs, Sprout shielded
outputs, and transparent outputs. All three can by design be "encumbered" by a spending
key - a user creating a transaction that spends the output must prove that they have
access to the spending key controlling the output. For Sprout shielded outputs this was
part of the zero-knowledge proof; for transparent and Sapling shielded outputs, the user
creates a signature with the spending key.

In some situations, more complex predicates are required. Zcash does not yet have any form
of shielded programmability, and thus users rely on the script system inherited from
Bitcoin to encumber transparent outputs. But even this is insufficient as-is for some
desired use cases. In particular, the Bolt protocol [#zip-draft-bolt]_ requires a custom
opcode, because the script system does not have the necessary primitives; this requires a
change to the consensus rules.

Shielded programmability would require significant changes across the ecosystem. In the
interim, we propose in this ZIP a transparent form of Zcash extensibility that could later
be migrated to shielded programmability.


Conventions
===========

We use the following notation as defined in the Zcash protocol specification
[#spec-notation]_, reproduced here for convenience:

- length(*S*) means the length of (number of elements in) *S*.

- { *a* .. *b* } means the set or type of integers from *a* through *b* inclusive.

- *a* || *b* means the concatenation of sequences *a* then *b*.

We reproduce the following conversion function from ZIP 32 [#zip-0032]_:

- I2LEOSP\ :sub:`l`\ (*k*) is the byte sequence *S* of length *l*/8 representing in little-endian order the
  integer *k* in range {0..2\ :sup:`l`\ -1}.


Specification
=============

Transparent extension
---------------------

A transparent extension is identified by a numeric ``type``. A transparent extension may
also have several modes of operation, corresponding to different kinds of encumbrance
within the extension's overall protocol.

A transparent extension mode is defined by four properties (in addition to ``type``):

- A numeric ``mode``.
- A byte sequence ``predicate`` containing a prefix-free encoding describing the
  predicate.
- A non-malleable byte sequence ``witness`` containing a prefix-free encoding of evidence
  satisfying the predicate.
- A deterministic verification algorithm ``tze_verify`` that takes as arguments ``mode``,
  ``predicate``, ``witness``, and a context object providing deterministic public
  information about the transaction as well as the block chain (up to and including the
  block that the transaction is mined in). It returns ``true`` if the predicate is
  satisfied, and ``false`` otherwise.

ZIPs that define a new transparent extension must completely specify all four of these
properties.

The lengths of ``predicate`` and ``witness`` are not required to be constant length, but
MUST be solely determined by the pair ``(type, mode)``.

Encoding in transactions
------------------------

We define a new transaction format that is both non-malleable and contains two new fields:

- ``tze_outputs``: A list of pairs of:

  - The value being encumbered.
  - The predicate that must be satisfied to spend the value.

- ``tze_inputs``: A list of pairs of:

  - An outpoint referencing a prior predicate.
  - A witness that satisfies it.

Non-malleability of the transaction format will be specified in a separate ZIP.

TODO: Finish encoding specification.

Consensus rules
---------------

Once the TODO network upgrade activates, the following new consensus rules are enforced:

- For each ``(outpoint, witness)`` pair in ``tze_inputs``:

  - ``outpoint`` MUST reference a predicate of the same type and mode in an already-mined
    transaction.
  - ``tze_verify(mode, predicate, witness, context)`` MUST return ``true``.

- If a transaction has non-empty ``tze_inputs`` and non-empty ``tze_outputs``, then every
  element in both fields MUST have the same ``type``.

Rationale
=========

Transactions that have both TZE inputs and outputs are required to use a single extension
type, in order to prevent cross-protocol attacks. This prevents TZE-encumbered value from
being spent directly into a different TZE type; the value needs to go through a regular
address in between.

- TODO: Maybe also disallow regular (transparent, Sprout, and Sapling) spends/outputs in
  transactions that have TZE inputs and outputs?

An earlier draft version of this ZIP stored the payloads inside transparent inputs and
outputs. This coupled the extension logic too tightly to the transparent address logic,
and was replaced with dedicated transaction fields.


Security and Privacy Considerations
===================================

This ZIP assumes that the base transaction format is non-malleable. However, the
``predicate`` and ``witness`` byte sequences are treated here as opaque. It is the
responsibility of ``tze_verify`` to enforce the following:

- ``witness`` MUST be non-malleable: any malleation MUST cause ``tze_verify`` to
  return ``false``.
- The output of ``tze_verify(mode, predicate, witness, context)`` MUST be deterministic.

ZIPs defining new extension types MUST include a section explaining how any potential
sources of malleability are handled.

This ZIP includes restrictions to prevent cross-protocol attacks, but the extension mode
is another potential attack surface. It is the responsibility of ZIPs defining new
extensions to examine the potential for cross-mode attacks within their security analysis,
and/or appropriately restrict which modes may be combined within a single transaction.


Reference Implementation
========================

TBD


Acknowledgements
================

The handler semantics of ``tze_verify`` were suggested by Zaki Manian, drawing on the
design of Cosmos. Daira Hopwood and Sean Bowe gave useful feedback on an early draft of
this ZIP, and helped to analyse the various sources of transaction ID malleability.

We would also like to thank the numerous other individuals who participated in discussions
at Zcon1 that led to the earlier draft version of this ZIP.


References
==========

.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
.. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism <https://github.com/zcash/zips/blob/master/zip-0200.rst>`_
.. [#zip-0205] `ZIP 205: Deployment of the Sapling Network Upgrade <https://github.com/zcash/zips/blob/master/zip-0205.rst>`_
.. [#zip-draft-bolt] `Draft ZIP: Add support for Blind Off-chain Lightweight Transactions (Bolt) protocol <https://github.com/zcash/zips/pull/216>`_
.. [#spec-notation] `Section 2: Notation. Zcash Protocol Specification, Version 2019.0.2 [Overwinter+Sapling] <https://github.com/zcash/zips/blob/master/protocol/protocol.pdf>`_
.. [#zip-0032] `ZIP 32: Shielded Hierarchical Deterministic Wallets <https://github.com/zcash/zips/blob/master/zip-0032.rst>`_