zec
/
zips
mirror of https://github.com/zcash/zips.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

zipWIP: add diagrams and tables

This commit is contained in:
George Tankersley 2018-10-02 22:27:57 +00:00 committed by Daira Hopwood
parent 8f11e9dee1
commit e0ec6d5eff
2 changed files with 105 additions and 68 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

BIN
arch.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 35 KiB

173
zip-XXX-light-payment-detection.rst
View File

@ -16,70 +16,70 @@ Terminology
The terms below are to be interpreted as follows:
Light client
A client that is not a full participant in the network of Zcash peers. It can
send and receive payments, but does not store or validate a copy of the
blockchain.
A client that is not a full participant in the network of Zcash peers. It can send and
receive payments, but does not store or validate a copy of the blockchain.
Abstract
========
This proposal defines a protocol for a Zcash light client supporting Sapling
shielded transactions.
This proposal defines a protocol for a Zcash light client supporting Sapling shielded
transactions.
Motivation
==========
Currently a client that wishes to send or receive shielded payments must be a
full node participanting in the Zcash network. This requires an amount of
available bandwidth, space, and processing power that may be unsuitable for
some classes of user. This light client protocol addresses that need, and is
appropriate for low-power, bandwidth-conscious, or otherwise limited machines
(such as mobile phones).
Currently a client that wishes to send or receive shielded payments must be a full node
participanting in the Zcash network. This requires an amount of available bandwidth,
space, and processing power that may be unsuitable for some classes of user. This light
client protocol addresses that need, and is appropriate for low-power,
bandwidth-conscious, or otherwise limited machines (such as mobile phones).
High-Level Design
=================
There are three logical components to a Zcash light client system:
- **Zcash node** that provides chain state and serves as a root of trust for
the system.
- **Zcash node** that provides chain state and serves as a root of trust for the system.
- **Proxy server** that extracts blockchain data from zcashd to store and serve
it in a lower-bandwidth format.
- **Proxy server** that extracts blockchain data from zcashd to store and serve it in a
lower-bandwidth format.
- **Light client** that subscribes to the stream from a proxy server and uses
that data to update its own view of the chain state.
- **Light client** that subscribes to the stream from a proxy server and uses that data to
update its own view of the chain state. The light client MAY be attached to a wallet
backend that will track particular Sapling notes.
.. figure:: arch.png
:align: center
:figclass: align-center
[ASCII DIAGRAM HERE or include png]
Outline of the light wallet architecture
Security Model
==============
In this model, we propose **payment detection privacy** as our main security
goal. That is, the proxy should not learn which transactions (received from the
blockchain) are addressed to a given light wallet. If we further assume network
privacy (via Tor or similar), the proxy should not be able to link different
connections or queries as deriving from the the same wallet.
In this model, we propose **payment detection privacy** as our main security goal. That
is, the proxy should not learn which transactions (received from the blockchain) are
addressed to a given light wallet. If we further assume network privacy (via Tor or
similar), the proxy should not be able to link different connections or queries as
deriving from the the same wallet.
In particular, the underlying Zcash node / proxy combination is assumed to be
"honest but curious" and is trusted to provide a correct view of the current
best chain state and to faithfully transmit queries and responses. Methods for
weakening this assumption are discussed in appendix FOO.
In particular, the underlying Zcash node / proxy combination is assumed to be "honest but
curious" and is trusted to provide a correct view of the current best chain state and to
faithfully transmit queries and responses. Methods for weakening this assumption are
discussed in appendix FOO.
This ZIP does not address how to spend notes privately.
Compact Stream Format
=====================
A key observation in this protocol is that the current zcashd encrypted field
is several hundred bytes long, due to the inclusion of a transaction “memo”.
The need to download this entire field imposes a substantial bandwidth cost on
each light wallets, which may be a limited mobile device on a
restricted-bandwidth plan. While more efficient techniques can be
developed in the future, for the moment we propose ignoring the memo field
during payment detection. Futhermore, we can also ignore any information that
is not directly relevant to a Sapling shielded transaction.
A key observation in this protocol is that the current zcashd encrypted field is several
hundred bytes long, due to the inclusion of a transaction “memo”. The need to download
this entire field imposes a substantial bandwidth cost on each light wallets, which may be
a limited mobile device on a restricted-bandwidth plan. While more efficient techniques
can be developed in the future, for the moment we propose ignoring the memo field during
payment detection. Futhermore, we can also ignore any information that is not directly
relevant to a Sapling shielded transaction.
A **compact block** is a packaging of ONLY the data from a block needed to:
@ -87,8 +87,8 @@ A **compact block** is a packaging of ONLY the data from a block needed to:
2. Detect a spend of your shielded Sapling notes
3. Update your witnesses to generate new Sapling spend proofs.
A compact block and its component compact transactions are encoded on the wire
using the following Protocol Buffers [XXX] format:
A compact block and its component compact transactions are encoded on the wire using the
following Protocol Buffers [XXX] format:
.. code:: proto
@ -123,48 +123,84 @@ using the following Protocol Buffers [XXX] format:
Encoding Details
----------------
`blockHash`, `txHash`, `nf`, `cmu`, and `epk` are encoded as specified in the Zcash Protocol Spec.
``blockHash``, ``txHash``, ``nf``, ``cmu``, and ``epk`` are encoded as
specified in the Zcash Protocol Spec.
The output ciphertext is handled differently, as described in section Output Ciphertext Compression.
The output and spend descriptions are handled differently, as described in the following
sections.
Output Ciphertext Compression
-----------------------------
Output Compression
------------------
In the normal Zcash protocol, the output ciphertext consists of the AEAD
encrypted form of a *note plaintext*:
In the normal Zcash protocol, the output ciphertext consists of the AEAD encrypted form of
a *note plaintext* (see Zcash Spec section 5.5):
[diagram from 5.5-beta22]
+------------+----------+----------+-------------+-----------------------------------+
| 8-bit 0x01 | 88-bit d | 64-bit v | 256-bit rcm | memo (512 bytes) + tag (16 bytes) |
+------------+----------+----------+-------------+-----------------------------------+
A recipient detects their transactions by trial-decrypting this ciphertext. On
a full node that has the entire block chain, the primary cost is computational.
For light clients however, there is an additional bandwidth cost: every
ciphertext on the block chain must be streamed from the server (or network
node) the light client is connected to. This results in a total of 580 bytes
per output that must be streamed to the client.
A recipient detects their transactions by trial-decrypting this ciphertext. On a full node
that has the entire block chain, the primary cost is computational. For light clients
however, there is an additional bandwidth cost: every ciphertext on the block chain must
be received from the server (or network node) the light client is connected to. This
results in a total of 580 bytes per output that must be streamed to the client.
However, we don't need all of that just to detect payments. The first 52 bytes
of the ciphertext contain the contents and opening of the note commitment,
which is all of the data needed to spend the note and to verify that the note
is spendable. If we ignore the memo and the authentication tag, we're left with
a 32-byte ephemeral key, the 32-byte note commitment, and only the first 52
bytes of the ciphertext for each output needed to decrypt, verify, and spend a
note. This totals to 116 bytes per output, for an 80% reduction in bandwidth
use.
However, we don't need all of that just to detect payments. The first 52 bytes of the
ciphertext contain the contents and opening of the note commitment, which is all of the
data needed to spend the note and to verify that the note is spendable. If we ignore the
memo and the authentication tag, we're left with a 32-byte ephemeral key, the 32-byte note
commitment, and only the first 52 bytes of the ciphertext for each output needed to
decrypt, verify, and spend a note. This totals to 116 bytes per output, for an 80%
reduction in bandwidth use.
However, skipping the full ciphertext means that we can no longer calculate the
authentication tag for the entire ciphertext and will need to do something else
to validate the integrity of the decrypted note plaintext.
authentication tag for the entire ciphertext and will need to do something else to
validate the integrity of the decrypted note plaintext.
Since the note commitment is sent outside the ciphertext and is authenticated
by the binding signature over the entire transaction, it serves as an adequate
check on the validity of the decrypted plaintext (assuming you trust the entity
assembling transactions). We therefore recalculate the note commitment from the
decrypted plaintext. If the recalculated commitment matches the one in the
output, we accept note as valid and spendable.
Since the note commitment is sent outside the ciphertext and is authenticated by the
binding signature over the entire transaction, it serves as an adequate check on the
validity of the decrypted plaintext (assuming you trust the entity assembling
transactions). We therefore recalculate the note commitment from the decrypted plaintext.
If the recalculated commitment matches the one in the output, we accept note as valid and
spendable.
Spend Compression
-----------------
Recall that a full Sapling Spend description is 384 bytes long:
+-------+--------------+-----------+
| Bytes | Name | Type |
+=======+==============+===========+
| 32 | cv | char[32] |
+-------+--------------+-----------+
| 32 | anchor | char[32] |
+-------+--------------+-----------+
| 32 | nullifier | char[32] |
+-------+--------------+-----------+
| 32 | rk | char[32] |
+-------+--------------+-----------+
| 192 | zkproof | char[192] |
+-------+--------------+-----------+
| 64 | spendAuthSig | char[64] |
+-------+--------------+-----------+
The only part necessary for detection is the nullifier, which allows a light client to
detect when one of its own notes has been spent. This means we only need to take 32 bytes
of each Spend, for a 90% improvement in bandwidth use.
Proxy operation
===============
The proxy's purpose is to provide a scalable and bandwidth-efficient interface between a
Zcash node and any number of light clients. It accomplishes this by parsing a blockwise
stream of transactions from the node and converting them into the compact format described
above.
The proxy stores
Client operation
================
@ -176,8 +212,8 @@ You can require the proxy to give you all the block headers to validate.
Reference Implementation
========================
This proposal is supported by a set of libraries and reference code made
available by the Zcash Company.
This proposal is supported by a set of libraries and reference code made available by the
Zcash Company.
[NOTE: 2018-09-17 WE HAVE NOT YET FINISHED OR RELEASED THESE.]
@ -185,4 +221,5 @@ References
==========
[bipXXX] define a light client
[XXX] protobufs