112 lines
9.6 KiB
HTML
112 lines
9.6 KiB
HTML
<!DOCTYPE html>
|
|
<html>
|
|
<head>
|
|
<title>ZIP guide: {Something Short and To the Point}</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: Unassigned {numbers are assigned by ZIP editors}
|
|
Title: {Something Short and To the Point}
|
|
Owners: First Owner <email>
|
|
...
|
|
Credits: First Credited
|
|
...
|
|
Status: Draft
|
|
Category: {Consensus | Standards Track | Network | RPC | Wallet | Informational | Process}
|
|
Created: yyyy-mm-dd
|
|
License: {usually MIT}
|
|
Pull-Request: <<a href="https://github.com/zcash/zips/pull/253">https://github.com/zcash/zips/pull/253</a>></pre>
|
|
<section id="don-t-panic"><h2><span class="section-heading">Don't Panic</span><span class="section-anchor"> <a rel="bookmark" href="#don-t-panic"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
|
<p>If this is your first time writing a ZIP, the structure and format may look intimidating. But really, it's just meant to reflect common-sense practice and some technical conventions. Feel free to start with a simple initial draft that gets ideas across, even if it doesn't quite follow this format. The community and ZIP editors will help you figure things out and get it into shape later.</p>
|
|
<p>{Delete this section.}</p>
|
|
</section>
|
|
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
|
<p>{Edit this to reflect the key words that are actually used.} The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
|
<p>The terms below are to be interpreted as follows:</p>
|
|
<dl>
|
|
<dt>{Term to be defined}</dt>
|
|
<dd>{Definition.}</dd>
|
|
<dt>{Another term}</dt>
|
|
<dd>{Definition.}</dd>
|
|
</dl>
|
|
</section>
|
|
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
|
<p>{Describe what this proposal does, typically in a few paragraphs.</p>
|
|
<p>The Abstract should only provide a summary of the ZIP; the ZIP should remain complete without the Abstract.</p>
|
|
<p>Use links where applicable, e.g. <a id="id2" class="footnote_reference" href="#protocol">2</a> <a id="id3" class="footnote_reference" href="#protocol-introduction">3</a>.}</p>
|
|
</section>
|
|
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
|
<p>{Why is this proposal needed?</p>
|
|
<p>This is one of the most important sections of the ZIP, and should be detailed and comprehensive. It shouldn't include any of the actual specification -- don't put conformance requirements in this section.</p>
|
|
<p>Explain the status quo, why the status quo is in need of improvement, and if applicable, the history of how this area has changed. Then describe <em>at a high level</em> why this proposed solution addresses the perceived issues. It is ok if this is somewhat redundant with the abstract, but here you can go into a lot more detail.}</p>
|
|
</section>
|
|
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a rel="bookmark" href="#requirements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
|
<p>{Describe design constraints on, or goals for the solution -- typically one paragraph for each constraint or goal. Again, don't actually specify anything here; this section is primarily for use as a consistency check that what is specified meets the requirements.}</p>
|
|
</section>
|
|
<section id="non-requirements"><h2><span class="section-heading">Non-requirements</span><span class="section-anchor"> <a rel="bookmark" href="#non-requirements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
|
<p>{This section is entirely optional. If it is present, it describes issues that the proposal is <em>not</em> attempting to address, that someone might otherwise think it does or should.}</p>
|
|
</section>
|
|
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
|
<p>{This section describes what should change, using precise language and conformance key words. Anything that is <em>required in order to implement the ZIP</em> (or follow its process, in the case of a Process ZIP) should be in this section.</p>
|
|
<p>Avoid overspecification! Also avoid underspecification. Specification is hard. Don't be afraid to ask for help.</p>
|
|
<p>Unless the specification is particularly simple, you will need to organise it under subheadings.}</p>
|
|
<section id="example-subheading"><h3><span class="section-heading">Example subheading</span><span class="section-anchor"> <a rel="bookmark" href="#example-subheading"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
|
<p>{At least while the ZIP is in Draft, we encourage writing open questions and TODOs.}</p>
|
|
<section id="open-questions"><h4><span class="section-heading">Open questions</span><span class="section-anchor"> <a rel="bookmark" href="#open-questions"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
|
|
<ul>
|
|
<li>What happens if a full node can't parse the fandangle as a doohicky?</li>
|
|
</ul>
|
|
<p>TODO: define byte encoding for the Jabberwock.</p>
|
|
<p>{Feel free to copy from other ZIPs doing similar things, e.g. defining RPC calls, consensus rules, etc.}</p>
|
|
</section>
|
|
</section>
|
|
<section id="valid-restructuredtext"><h3><span class="section-heading">Valid reStructuredText</span><span class="section-anchor"> <a rel="bookmark" href="#valid-restructuredtext"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
|
<p>This is optional before publishing a PR, but to check whether a document is valid reStructuredText, first install <code>rst2html5</code>. E.g. on Debian-based distros:</p>
|
|
<pre>sudo apt-get install python3-pip pandoc perl sed
|
|
sudo pip3 install rst2html5</pre>
|
|
<p>Then, with <code>zip-xxxx.rst</code> in the root directory of a clone of this repo, run:</p>
|
|
<pre>make zip-xxxx.html</pre>
|
|
<p>(or just <code>make</code>) and view <code>zip-xxxx.html</code> in a web browser.</p>
|
|
</section>
|
|
</section>
|
|
<section id="reference-implementation"><h2><span class="section-heading">Reference implementation</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
|
<p>{This section is entirely optional; if present, it usually gives links to zcashd or zebrad PRs.}</p>
|
|
</section>
|
|
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
|
<table id="rfc2119" class="footnote">
|
|
<tbody>
|
|
<tr>
|
|
<th>1</th>
|
|
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: 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 2020.1.24 or later</a></td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<table id="protocol-introduction" class="footnote">
|
|
<tbody>
|
|
<tr>
|
|
<th>3</th>
|
|
<td><a href="protocol/protocol.pdf#introduction">Zcash Protocol Specification, Version 2020.1.24. Section 1: Introduction</a></td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<table id="zip-0000" class="footnote">
|
|
<tbody>
|
|
<tr>
|
|
<th>4</th>
|
|
<td><a href="zip-0000">ZIP 0: ZIP Process</a></td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</section>
|
|
</section>
|
|
</body>
|
|
</html> |