mirror of https://github.com/zcash/zips.git
ZIP 207: reference fix and HTML.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood
parent
9ce78b04f5
commit
9ac5984f54
|
|
@ -3,6 +3,7 @@
|
|||
<head>
|
||||
<title>ZIP 207: Funding Streams</title>
|
||||
<meta charset="utf-8" />
|
||||
<script src="https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.1/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
|
||||
<body>
|
||||
<section>
|
||||
|
|
@ -37,43 +38,61 @@ License: MIT</pre>
|
|||
<p>This ZIP 207 was originally proposed for the Blossom network upgrade, as a means of splitting the original Founders' Reward into several streams. It was then withdrawn when such splitting was judged to be unnecessary at the consensus level. Since the capabilities of the funding stream mechanism match the requirements for the Zcash Development Fund, the ZIP is being reintroduced for that purpose in order to reuse specification, analysis, and implementation effort.</p>
|
||||
</section>
|
||||
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a href="#requirements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>The primary requirement of this ZIP is to provide a mechanism for specifying the funding streams that are used in ZIP 214 [#zip-0214] to implement the Zcash Development Fund. It should be sufficiently expressive to handle both the main three "slices" (ECC, ZF, and MG) defined in ZIP 1014 <a id="id10" class="footnote_reference" href="#zip-1014">13</a>, and also (with additional funding stream definitions) the "direct grant option" described in that ZIP.</p>
|
||||
<p>The primary requirement of this ZIP is to provide a mechanism for specifying the funding streams that are used in ZIP 214 <a id="id10" class="footnote_reference" href="#zip-0214">11</a> to implement the Zcash Development Fund. It should be sufficiently expressive to handle both the main three "slices" (ECC, ZF, and MG) defined in ZIP 1014 <a id="id11" class="footnote_reference" href="#zip-1014">13</a>, and also (with additional funding stream definitions) the "direct grant option" described in that ZIP.</p>
|
||||
<p>As for the original Founders' Reward, addresses for a given funding stream are changed on a roughly-monthly basis, so that keys that are not yet needed may be kept off-line as a security measure.</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>
|
||||
<section id="definitions"><h3><span class="section-heading">Definitions</span><span class="section-anchor"> <a href="#definitions"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>We use the following constants and functions defined in <a id="id11" class="footnote_reference" href="#protocol-constants">4</a>, <a id="id12" class="footnote_reference" href="#protocol-subsidies">5</a>, and <a id="id13" class="footnote_reference" href="#protocol-foundersreward">6</a>:</p>
|
||||
<p>We use the following constants and functions defined in <a id="id12" class="footnote_reference" href="#protocol-constants">4</a>, <a id="id13" class="footnote_reference" href="#protocol-subsidies">5</a>, and <a id="id14" class="footnote_reference" href="#protocol-foundersreward">6</a>:</p>
|
||||
<ul>
|
||||
<li><code>BlossomActivationHeight</code></li>
|
||||
<li><code>PostBlossomHalvingInterval</code></li>
|
||||
<li><code>Halving(height)</code></li>
|
||||
<li><code>BlockSubsidy(height)</code></li>
|
||||
<li><code>RedeemScriptHash(height)</code>.</li>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{BlossomActivationHeight}\)</span>
|
||||
</li>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{PostBlossomHalvingInterval}\)</span>
|
||||
</li>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{Halving}(\mathsf{height})\)</span>
|
||||
</li>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{BlockSubsidy}(\mathsf{height})\)</span>
|
||||
</li>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{RedeemScriptHash}(\mathsf{height})\)</span>
|
||||
.</li>
|
||||
</ul>
|
||||
<p>We also define the following function:</p>
|
||||
<ul>
|
||||
<li><code>HeightForHalving(halving)</code>: Smallest <code>height</code> such that <code>Halving(height) = halving</code></li>
|
||||
<li>
|
||||
<span class="math">\(\mathsf{HeightForHalving}(\mathsf{halving})\)</span>
|
||||
: Smallest
|
||||
<span class="math">\(\mathsf{height}\)</span>
|
||||
such that
|
||||
<span class="math">\(\mathsf{Halving}(\mathsf{height}) = \mathsf{halving}\)</span>
|
||||
</li>
|
||||
</ul>
|
||||
</section>
|
||||
<section id="funding-streams"><h3><span class="section-heading">Funding streams</span><span class="section-anchor"> <a href="#funding-streams"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>A funding stream is defined by a block subsidy fraction (represented as a numerator and a denominator), a start height (inclusive), and an end height (exclusive).</p>
|
||||
<p>By defining the issuance as a proportion of the total block subsidy, rather than absolute zatoshis, this ZIP dovetails with any changes to both block target spacing and issuance-per-block rates, while maintaining an unchanged target-time-based issuance schedule. Such a target-time / issuance rate change occurred at the Blossom network upgrade, for example. <a id="id14" class="footnote_reference" href="#zip-0208">9</a></p>
|
||||
<p>By defining the issuance as a proportion of the total block subsidy, rather than absolute zatoshis, this ZIP dovetails with any changes to both block target spacing and issuance-per-block rates. Such a change occurred at the Blossom network upgrade, for example. <a id="id15" class="footnote_reference" href="#zip-0208">9</a></p>
|
||||
<p>The value of a funding stream at a given block height is defined as:</p>
|
||||
<pre>FundingStream[FUND].Value(height) =
|
||||
floor((
|
||||
BlockSubsidy(height) * FundingStream[FUND].ValueNumerator
|
||||
) / FundingStream[FUND].ValueDenominator)</pre>
|
||||
<div class="math">\(\mathsf{FundingStream[FUND].Value}(\mathsf{height}) =
|
||||
\mathsf{floor}\left(
|
||||
\frac{\mathsf{BlockSubsidy}(\mathsf{height}) \,\cdot\, \mathsf{FundingStream[FUND].ValueNumerator}}{\mathsf{FundingStream[FUND].ValueDenominator}}
|
||||
\right)\)</div>
|
||||
<p>An active funding stream at a given block height is defined as a funding stream for which the block height is less than its end height, but not less than its start height.</p>
|
||||
<p>Each funding stream has an associated sequence of recipient addresses, each of which MUST be either a transparent P2SH address or a Sapling address.</p>
|
||||
<p>Each address is used for at most 1/48th of a halving interval, creating a roughly-monthly sequence of funding periods. The address to be used for a given block height is defined as follows:</p>
|
||||
<pre>AddressChangeInterval = PostBlossomHalvingInterval / 48
|
||||
AddressPeriod(height) =
|
||||
floor((
|
||||
height + PostBlossomHalvingInterval - HeightForHalving(1)
|
||||
) / AddressChangeInterval)
|
||||
FundingStream[FUND].AddressIndex(height) =
|
||||
AddressPeriod(height) - AddressPeriod(FundingStream[FUND].StartHeight)
|
||||
Address(height) = FundingStream[FUND].Addresses[FundingStream[FUND].AddressIndex(height)]</pre>
|
||||
<div class="math">\(\begin{eqnarray*}
|
||||
\mathsf{AddressChangeInterval} &=& \mathsf{PostBlossomHalvingInterval} / 48 \\
|
||||
\mathsf{AddressPeriod}(\mathsf{height}) &=&
|
||||
\mathsf{floor}\left(
|
||||
{\small\frac{\mathsf{height} + \mathsf{PostBlossomHalvingInterval} - \mathsf{HeightForHalving}(1)}{\mathsf{AddressChangeInterval}}}
|
||||
\right) \\
|
||||
\mathsf{FundingStream[FUND].AddressIndex}(\mathsf{height}) &=&
|
||||
\mathsf{AddressPeriod}(\mathsf{height}) - \\&&\hspace{2em} \mathsf{AddressPeriod}(\mathsf{FundingStream[FUND].StartHeight}) \\
|
||||
\mathsf{Address}(\mathsf{height}) &=& \mathsf{FundingStream[FUND].Addresses[} \\&&\hspace{2em} \mathsf{FundingStream[FUND].AddressIndex}(\mathsf{height})\mathsf{]}
|
||||
\end{eqnarray*}\)</div>
|
||||
<p>This has the property that all active funding streams change the address they are using on the same block height schedule, aligned to the height of the first halving so that 48 funding periods fit cleanly within a halving interval. This can be leveraged to simplify implementations, by batching the necessary outputs for each funding period.</p>
|
||||
<p>Below is a visual representation of how stream addresses align with funding periods:</p>
|
||||
<blockquote>
|
||||
|
|
@ -177,15 +196,15 @@ Address(height) = FundingStream[FUND].Addresses[FundingStream[FUND].AddressIndex
|
|||
<p>On Mainnet, ${NU4} is planned to activate exactly at the point when the Founders' Reward expires, at block height 1046400. On Testnet, there will be a shortened Founders' Reward address period prior to ${NU4} activation.</p>
|
||||
</section>
|
||||
<section id="consensus-rules"><h3><span class="section-heading">Consensus rules</span><span class="section-anchor"> <a href="#consensus-rules"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>Prior to activation of the ${NU4} network upgrade, the existing consensus rule for payment of the original Founders' Reward is enforced. <a id="id15" class="footnote_reference" href="#protocol-foundersreward">6</a></p>
|
||||
<p>Prior to activation of the ${NU4} network upgrade, the existing consensus rule for payment of the original Founders' Reward is enforced. <a id="id16" class="footnote_reference" href="#protocol-foundersreward">6</a></p>
|
||||
<p>Once the ${NU4} network upgrade activates:</p>
|
||||
<ul>
|
||||
<li>The existing consensus rule <a id="id16" class="footnote_reference" href="#protocol-foundersreward">6</a> is no longer active. (This would be the case under the preexisting consensus rules for Mainnet, but not for Testnet.)</li>
|
||||
<li>The existing consensus rule for payment of the Founders' Reward <a id="id17" class="footnote_reference" href="#protocol-foundersreward">6</a> is no longer active. (This would be the case under the preexisting consensus rules for Mainnet, but not for Testnet.)</li>
|
||||
<li>The coinbase transaction in each block MUST contain at least one output per active funding stream that pays the stream's value in the prescribed way to the stream's recipient address for the block's height.</li>
|
||||
<li>The "prescribed way" to pay a transparent P2SH address is to use a standard P2SH script of the form <code>OP_HASH160 RedeemScriptHash(height) OP_EQUAL</code> as the <code>scriptPubKey</code>.</li>
|
||||
<li>The "prescribed way" to pay a Sapling address is as defined in <a id="id17" class="footnote_reference" href="#zip-0213">10</a>. That is, all Sapling outputs in coinbase transactions (including, but not limited to, outputs for funding streams) MUST have valid note commitments when recovered using a 32-byte array of zeroes as the outgoing viewing key.</li>
|
||||
<li>The "prescribed way" to pay a Sapling address is as defined in <a id="id18" class="footnote_reference" href="#zip-0213">10</a>. That is, all Sapling outputs in coinbase transactions (including, but not limited to, outputs for funding streams) MUST have valid note commitments when recovered using a 32-byte array of zeroes as the outgoing viewing key.</li>
|
||||
</ul>
|
||||
<p>For the funding stream definitions to be activated at ${NU4}, see ZIP 214. <a id="id18" class="footnote_reference" href="#zip-0214">11</a> Funding stream definitions can be added, changed, or deleted in ZIPs associated with subsequent network upgrades, subject to the ZIP process. <a id="id19" class="footnote_reference" href="#zip-0000">7</a></p>
|
||||
<p>For the funding stream definitions to be activated at ${NU4}, see ZIP 214. <a id="id19" class="footnote_reference" href="#zip-0214">11</a> Funding stream definitions can be added, changed, or deleted in ZIPs associated with subsequent network upgrades, subject to the ZIP process. <a id="id20" class="footnote_reference" href="#zip-0000">7</a></p>
|
||||
</section>
|
||||
<section id="example-implementation"><h3><span class="section-heading">Example implementation</span><span class="section-anchor"> <a href="#example-implementation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<pre data-language="cpp"><span class="k">struct</span> <span class="n">FundingPeriod</span> <span class="p">{</span>
|
||||
|
|
@ -218,6 +237,7 @@ Address(height) = FundingStream[FUND].Addresses[FundingStream[FUND].AddressIndex
|
|||
<span class="kt">uint64_t</span> <span class="n">valueDenominator</span><span class="p">)</span>
|
||||
<span class="p">{</span>
|
||||
<span class="n">assert</span><span class="p">(</span><span class="n">valueNumerator</span> <span class="o"><</span> <span class="n">valueDenominator</span><span class="p">);</span>
|
||||
<span class="n">assert</span><span class="p">(</span><span class="n">valueNumerator</span> <span class="o"><</span> <span class="n">INT64_MAX</span> <span class="o">/</span> <span class="n">MAX_MONEY</span><span class="p">);</span>
|
||||
<span class="n">params</span><span class="p">.</span><span class="n">vFundingPeriods</span><span class="p">[</span><span class="n">idx</span><span class="p">].</span><span class="n">addresses</span> <span class="o">=</span> <span class="n">addresses</span><span class="p">;</span>
|
||||
<span class="n">params</span><span class="p">.</span><span class="n">vFundingPeriods</span><span class="p">[</span><span class="n">idx</span><span class="p">].</span><span class="n">valueNumerator</span> <span class="o">=</span> <span class="n">valueNumerator</span><span class="p">;</span>
|
||||
<span class="n">params</span><span class="p">.</span><span class="n">vFundingPeriods</span><span class="p">[</span><span class="n">idx</span><span class="p">].</span><span class="n">valueDenominator</span> <span class="o">=</span> <span class="n">valueDenominator</span><span class="p">;</span>
|
||||
|
|
@ -338,7 +358,7 @@ Address(height) = FundingStream[FUND].Addresses[FundingStream[FUND].AddressIndex
|
|||
</section>
|
||||
</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 proposal is intended to be deployed with ${NU4}. <a id="id20" class="footnote_reference" href="#zip-0251">12</a></p>
|
||||
<p>This proposal is intended to be deployed with ${NU4}. <a id="id21" class="footnote_reference" href="#zip-0251">12</a></p>
|
||||
</section>
|
||||
<section id="backward-compatibility"><h2><span class="section-heading">Backward compatibility</span><span class="section-anchor"> <a href="#backward-compatibility"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This proposal intentionally creates what is known as a "bilateral consensus rule change". Use of this mechanism requires that all network participants upgrade their software to a compatible version within the upgrade window. Older software will treat post-upgrade blocks as invalid, and will follow any pre-upgrade consensus branch that persists.</p>
|
||||
|
|
|
|||
|
|
@ -63,7 +63,7 @@ Requirements
|
|||
============
|
||||
|
||||
The primary requirement of this ZIP is to provide a mechanism for specifying
|
||||
the funding streams that are used in ZIP 214 [#zip-0214] to implement the Zcash
|
||||
the funding streams that are used in ZIP 214 [#zip-0214]_ to implement the Zcash
|
||||
Development Fund. It should be sufficiently expressive to handle both the main
|
||||
three "slices" (ECC, ZF, and MG) defined in ZIP 1014 [#zip-1014]_, and also
|
||||
(with additional funding stream definitions) the "direct grant option" described
|
||||
|
|
|
|||
Loading…
Reference in New Issue