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

ZIP 307: add notes about differences from the implementation (see https://github.com/zcash/zips/issues/341#issuecomment-622262394 ). 

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2020-06-29 22:25:50 +01:00
parent 327746929e
commit 98b854de95
2 changed files with 11 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
zip-0307.html
View File

@ -153,6 +153,7 @@ License: MIT</pre>
</section>
<section id="proxy-operation"><h2><span class="section-heading">Proxy operation</span><span class="section-anchor"> <a rel="bookmark" href="#proxy-operation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>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.</p>
<p><em>The details of the API described below may differ from the implementation.</em></p>
<p>The proxy offers the following API to clients:</p>
<pre data-language="proto"><span class="kd">service</span> <span class="n">CompactTxStreamer</span> <span class="p">{</span>
<span class="k">rpc</span> <span class="n">GetLatestBlock</span><span class="p">(</span><span class="n">ChainSpec</span><span class="p">)</span> <span class="k">returns</span> <span class="p">(</span><span class="n">BlockID</span><span class="p">)</span> <span class="p">{}</span>
@ -267,6 +268,7 @@ License: MIT</pre>
<p>The <code>CompactSpend</code> entries can be checked against known local nullifiers, to for example ensure that a transaction has been received by the network and mined.</p>
</section>
<section id="block-header-validation"><h4><span class="section-heading">Block header validation</span><span class="section-anchor"> <a rel="bookmark" href="#block-header-validation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p><em>This section describes a proposed enhancement that has been only partially implemented: currently only</em> <code>prevHash</code> <em>is checked.</em></p>
<p>If the <code>CompactBlock</code> for height <code>X</code> contains a block header, the light client can validate it in a similar way to SPV clients <a id="id8" class="footnote_reference" href="#spv-clients">11</a> by performing the following checks:</p>
<ul>
<li><code>version &gt;= MIN_BLOCK_VERSION</code></li>
@ -402,6 +404,7 @@ License: MIT</pre>
</section>
</section>
<section id="block-privacy-via-bucketing"><h3><span class="section-heading">Block privacy via bucketing</span><span class="section-anchor"> <a rel="bookmark" href="#block-privacy-via-bucketing"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p><em>This section describes a proposed enhancement that has not been implemented.</em></p>
<p>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.</p>
<p>Let <code>⌊X⌋ = X - (X % N)</code> be the value of <code>X</code> rounded down to some multiple of the bucket size <code>N</code>. The synchronisation phases from the above interaction are modified as follows:</p>
<pre data-language="text">Phase Client Server

8
zip-0307.rst
View File

@ -200,6 +200,8 @@ Zcash node and any number of light clients. It accomplishes this by parsing a bl
stream of transactions from the node and converting them into the compact format described
above.
*The details of the API described below may differ from the implementation.*
The proxy offers the following API to clients:
.. code:: proto
@ -312,6 +314,10 @@ ensure that a transaction has been received by the network and mined.
Block header validation
```````````````````````
*This section describes a proposed enhancement that has been only partially implemented:
currently only* ``prevHash`` *is checked.*
If the ``CompactBlock`` for height ``X`` contains a block header, the light client can
validate it in a similar way to SPV clients [#spv-clients]_ by performing the following
checks:
@ -484,6 +490,8 @@ In this case, phase A is modified as follows:
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