mirror of https://github.com/zcash/zips.git
zipWIP: add diagrams and tables
This commit is contained in:
parent
8f11e9dee1
commit
e0ec6d5eff
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue