mirror of https://github.com/zcash/zips.git
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:
parent
327746929e
commit
98b854de95
|
@ -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 >= 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
|
||||
|
|
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue