zips/zip-0209.html

65 lines
5.6 KiB
HTML

<!DOCTYPE html>
<html>
<head>
<title>ZIP 209: Prohibit Negative Shielded Value Pool</title>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
<body>
<section>
<pre>ZIP: 209
Title: Prohibit Negative Shielded Value Pool
Owners: Sean Bowe &lt;sean@electriccoin.co&gt;
Status: Final
Category: Consensus
Created: 2019-02-25
License: MIT</pre>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. <a href="#rfc2119" id="id1" class="footnote_reference">1</a></p>
<p>The term "block chain" and "network upgrade" are to be interpreted as defined in <a href="#zip-0200" id="id2" class="footnote_reference">3</a>.</p>
<p>The "Sprout value pool balance" for a given block chain, as implied by section 4.11 of the Zcash Protocol Specification <a href="#protocol" id="id3" class="footnote_reference">2</a>, is the sum of all <code>vpub_old</code> fields for transactions in the block chain, minus the sum of all <code>vpub_new</code> fields for transactions in the block chain.</p>
<p>The "Sapling value pool balance" for a given block chain, as implied by section 4.12 of Zcash Protocol Specification <a href="#protocol" id="id4" class="footnote_reference">2</a>, is the negation of the sum of all <code>valueBalance</code> fields for transactions in the block chain.</p>
</section>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal defines how the consensus rules are altered such that blocks which produce negative shielded value pools are prohibited.</p>
</section>
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>It is possible for nodes to monitor the total value of notes that are shielded to, or unshielded from, each of the Sprout or Sapling value pools. If the total value that is unshielded exceeds the total value that was shielded for a given pool, a balance violation has occurred in the corresponding shielded transaction protocol.</p>
<p>It would be preferable for the network to reject blocks that result in the aforementioned balance violation. However, nodes do not currently react to such an event. Remediation may therefore require chain rollbacks and other disruption.</p>
</section>
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>If the "Sprout value pool balance" or "Sapling value pool balance" would become negative in the block chain created as a result of accepting a block, then all nodes MUST reject the block as invalid.</p>
<p>Nodes MAY relay transactions even if one or more of them cannot be mined due to the aforementioned restriction.</p>
</section>
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a href="#deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This consensus rule is not deployed as part of a network upgrade as defined in ZIP-200 <a href="#zip-0200" id="id5" class="footnote_reference">3</a> and there is no mechanism by which the network will synchronize to enforce this rule. Rather, all nodes should begin enforcing this consensus rule upon acceptance of this proposal.</p>
<p>There is a risk that before all nodes on the network begin enforcing this consensus rule that block(s) will be produced that violate it, potentially leading to network fragmentation. This is considered sufficiently unlikely that the benefits of enforcing this consensus rule sooner are overwhelming.</p>
</section>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>
<th>1</th>
<td><a href="https://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
<table id="protocol" class="footnote">
<tbody>
<tr>
<th>2</th>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2019.0-beta-37 [Overwinter+Sapling]</a></td>
</tr>
</tbody>
</table>
<table id="zip-0200" class="footnote">
<tbody>
<tr>
<th>3</th>
<td><a href="zip-0200">ZIP 200: Network Upgrade Mechanism</a></td>
</tr>
</tbody>
</table>
</section>
</section>
</body>
</html>