Encoding Details

blockHash, txHash, nf, cmu, and epk are encoded as specified in the Zcash Protocol Spec.

The output and spend descriptions are handled differently, as described in the following sections.

Output Compression

In the normal Zcash protocol, the output ciphertext consists of the AEAD-encrypted form of a note plaintext 5:

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 (in addition to the 32-byte ephemeral public key).

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 public 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.

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 the note as valid and spendable.

Spend Compression

Recall that a full Sapling Spend description is 384 bytes long 6:

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.

Local processing

Given a CompactBlock at block height \(\mathsf{height}\) received in height-sequential order from a proxy server, a light client can process it in four ways:

Client-server interaction

We can divide the typical client-server interaction into four distinct phases:

Phase   Client                Server
=====   ============================
  A     GetLatestBlock ------------>

        <---------------- BlockID(X)

        GetBlock(X) --------------->

        <----------- CompactBlock(X)

            ===

  B     GetLatestBlock ------------>

        <---------------- BlockID(Y)

        GetBlockRange(X, Y) ------->

        <--------- CompactBlock(X)
        <--------- CompactBlock(X+1)
        <--------- CompactBlock(X+2)
                        ...
        <--------- CompactBlock(Y-1)
        <--------- CompactBlock(Y)

            ===

  C     GetTransaction(X+4, 7) ---->

        <--- FullTransaction(X+4, 7)

        GetTransaction(X+9, 2) ---->

        <--- FullTransaction(X+9, 2)

            ===

  D     GetLatestBlock ------------>

        <---------------- BlockID(Z)

        GetBlockRange(Y, Z) ------->

        <--------- CompactBlock(Y)
        <--------- CompactBlock(Y+1)
        <--------- CompactBlock(Y+2)
                        ...
        <--------- CompactBlock(Z-1)
        <--------- CompactBlock(Z)

Phase A: The light client starts up for the first time.

• The light client queries the server to fetch the most recent block X.
• The light client queries the commitment tree state for block X.
  • Or, it has to set X to the block height at which Sapling activated, so as to be sent the entire commitment tree. [TODO: Decide which to specify.]
• Shielded addresses created by the light client will not have any relevant transactions in this or any prior block.

Phase B: The light client updates its local chain view for the first time.

• The light client queries the server to fetch the most recent block Y.
• It then executes a block range query to fetch every block between X (inclusive) and Y (inclusive).
• The block at height X is checked to ensure the received blockHash matches the light client's cached copy, and then discards it without further processing.
  • An inconsistency would imply that block X was orphaned during a chain reorg.
• As each subsequent CompactBlock arrives, the light client:
  • Validates the block header if it is present.
  • Scans the CompactBlock to find any relevant transactions for addresses generated since X was fetched (likely the first transactions involving those addresses). If notes are detected, it:
    • Generates incremental witnesses for the notes, and updates them going forward.
    • Scans for their nullifiers from that block onwards.

Phase C: The light client has detected some notes and displayed them. User interaction has indicated that the corresponding full transactions should be fetched.

• The light client queries the server for each transaction it wishes to fetch.

Phase D: The user has spent some notes. The light client updates its local chain view some time later.

• The light client queries the server to fetch the most recent block Z.
• It then executes a block range query to fetch every block between Y (inclusive) and Z (inclusive).
• The block at height Y is checked to ensure the received blockHash matches the light client's cached copy, and then discards it without further processing.
  • An inconsistency would imply that block Y was orphaned during a chain reorg.
• As each subsequent CompactBlock arrives, the light client:
  • Validates the block header if it is present.
  • Updates the incremental witnesses for known notes.
  • Scans for any known nullifiers. The corresponding notes are marked as spent at that height, and excluded from further witness updates.
  • Scans for any relevant transactions for addresses generated since Y was fetched. These are handled as in phase B.

Block privacy via bucketing

This section describes a proposed enhancement that has not been implemented.

The above interaction reveals to the server at the start of each synchronisation phase (B and D) the block height which the light client had previously synchronised to. This is an information leak under our security model (assuming network privacy). We can reduce the information leakage by "bucketing" the start point of each synchronisation. Doing so also enables us to handle most chain reorgs simultaneously.

Let ⌊X⌋ = X - (X % N) be the value of X rounded down to some multiple of the bucket size N. The synchronisation phases from the above interaction are modified as follows:

Phase   Client                Server
=====   ============================
  B     GetLatestBlock ------------>

        <---------------- BlockID(Y)

        GetBlockRange(⌊X⌋, Y) ----->

        <-------- CompactBlock(⌊X⌋)
        <-------- CompactBlock(⌊X⌋+1)
        <-------- CompactBlock(⌊X⌋+2)
                        ...
        <-------- CompactBlock(Y-1)
        <-------- CompactBlock(Y)

            ===

  D     GetLatestBlock ------------>

        <---------------- BlockID(Z)

        GetBlockRange(⌊Y⌋, Z) ----->

        <-------- CompactBlock(⌊Y⌋)
        <-------- CompactBlock(⌊Y⌋+1)
                        ...
        <-------- CompactBlock(Z-1)
        <-------- CompactBlock(Z)

Phase B: The light client updates its local chain view for the first time.

• The light client queries the server to fetch the most recent block Y.
• It then executes a block range query to fetch every block between ⌊X⌋ (inclusive) and Y (inclusive).
• Blocks between ⌊X⌋ and X are checked to ensure that the received blockHash matches the light client's chain view for each height, and are then discarded without further processing.
  • If an inconsistency is detected at height Q, the light client sets X = Q-1, discards all local blocks with height >= Q, and rolls back the state of all local transactions to height Q-1 (un-mining them as necessary).
• Blocks between X+1 and Y are processed as before.

Phase D: The user has spent some notes. The light client updates its local chain view some time later.

• The light client queries the server to fetch the most recent block Z.
• It then executes a block range query to fetch every block between ⌊Y⌋ (inclusive) and Z (inclusive).
• Blocks between ⌊Y⌋ and Y are checked to ensure that the received blockHash matches the light client's chain view for each height, and are then discarded without further processing.
  • If an inconsistency is detected at height R, the light client sets Y = R-1, discards all local blocks with height >= R, and rolls back the following local state to height R-1:
    • All local transactions (un-mining them as necessary).
    • All tracked nullifiers (unspending or discarding as necessary).
    • All incremental witnesses (caching strategies are not covered in this ZIP).
• Blocks between Y+1 and Z are processed as before.

Transaction privacy

The synchronisation phases give the light client sufficient information to determine accurate address balances, show when funds were received or spent, and spend any unspent notes. As synchronisation happens via a broadcast medium, it leaks no information about which transactions the light client is interested in.

If, however, the light client needs access to other components of a transaction (such as the memo fields for received notes, or the outgoing ciphertexts in order to recover spend information when importing a wallet seed), it will need to download the full transaction. The light client SHOULD obscure the exact transactions of interest by downloading numerous uninteresting transactions as well, and SHOULD download all transactions in any block from which a single full transaction is fetched (interesting or otherwise). It MUST convey to the user that fetching full transactions will reduce their privacy.