2019-02-15 22:32:09 -08:00
|
|
|
|
::
|
|
|
|
|
|
2019-02-23 21:25:56 -08:00
|
|
|
|
ZIP: 0
|
|
|
|
|
Title: ZIP Process
|
2019-03-19 20:02:47 -07:00
|
|
|
|
Owners: Daira Hopwood
|
|
|
|
|
Josh Cincinnati
|
2019-04-04 13:20:05 -07:00
|
|
|
|
Status: Active
|
2019-04-04 13:24:46 -07:00
|
|
|
|
Category: Process
|
2019-02-23 21:25:56 -08:00
|
|
|
|
Created: 2019-02-16
|
|
|
|
|
License: BSD-2-Clause
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Terminology
|
|
|
|
|
===========
|
|
|
|
|
|
|
|
|
|
The key words "MUST", "SHOULD", "SHOULD NOT", "MAY", "RECOMMENDED",
|
|
|
|
|
"OPTIONAL", and "REQUIRED" in this document are to be interpreted as
|
|
|
|
|
described in RFC 2119. [#RFC2119]_
|
|
|
|
|
|
|
|
|
|
The term "network upgrade" in this document is to be interpreted as
|
|
|
|
|
described in ZIP 200. [#zip-0200]_
|
|
|
|
|
|
2019-02-15 22:32:09 -08:00
|
|
|
|
|
|
|
|
|
Abstract
|
|
|
|
|
========
|
|
|
|
|
|
|
|
|
|
A Zcash Improvement Proposal (ZIP) is a design document providing
|
|
|
|
|
information to the Zcash community, or describing a new feature for
|
|
|
|
|
Zcash or its processes or environment. The ZIP should provide a concise
|
|
|
|
|
technical specification of the feature and a rationale for the feature.
|
|
|
|
|
|
2019-02-23 21:25:56 -08:00
|
|
|
|
We intend ZIPs to be the primary mechanism for proposing new features,
|
2019-02-15 22:32:09 -08:00
|
|
|
|
for collecting community input on an issue, and for documenting the
|
|
|
|
|
design decisions that have gone into Zcash. The author(s) of the ZIP
|
2019-03-19 20:02:47 -07:00
|
|
|
|
(known as Owners in this document) are responsible for building
|
2019-02-15 22:32:09 -08:00
|
|
|
|
consensus within the community and documenting dissenting opinions.
|
|
|
|
|
|
|
|
|
|
Because the ZIPs are maintained as text files in a versioned repository,
|
|
|
|
|
their revision history is the historical record of the feature proposal.
|
|
|
|
|
|
2019-02-23 21:25:56 -08:00
|
|
|
|
This document is based on the work done by Luke Dashjr with
|
|
|
|
|
`BIP 2 <https://github.com/bitcoin/bips>`__ and Daira Hopwood with
|
|
|
|
|
`Draft ZIP 0 <https://github.com/daira/zips/tree/master/drafts/daira-zip-process>`__.
|
2019-02-15 22:32:09 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ZIP Workflow
|
|
|
|
|
============
|
|
|
|
|
|
|
|
|
|
The ZIP process begins with a new idea for Zcash. Each potential ZIP
|
2019-03-19 20:02:47 -07:00
|
|
|
|
must have a Owner -- someone who writes the ZIP using the style and
|
2019-02-15 22:32:09 -08:00
|
|
|
|
format described below, shepherds the discussions in the appropriate
|
|
|
|
|
forums, and attempts to build community consensus around the idea. The
|
2019-03-19 20:02:47 -07:00
|
|
|
|
ZIP Owner (a.k.a. author) should first attempt to ascertain whether
|
2019-02-15 22:32:09 -08:00
|
|
|
|
the idea is ZIP-able. Small enhancements or patches to a particular
|
|
|
|
|
piece of software often don't require standardisation between multiple
|
|
|
|
|
projects; these don't need a ZIP and should be injected into the
|
|
|
|
|
relevant project-specific development workflow with a patch submission
|
|
|
|
|
to the applicable issue tracker. Additionally, many ideas have been
|
|
|
|
|
brought forward for changing Zcash that have been rejected for various
|
|
|
|
|
reasons. The first step should be to search past discussions to see if
|
|
|
|
|
an idea has been considered before, and if so, what issues arose in its
|
|
|
|
|
progression. After investigating past work, the best way to proceed is
|
2019-04-09 15:30:47 -07:00
|
|
|
|
by posting about the new idea to the `Zcash Community Forum
|
|
|
|
|
<https://forum.zcashcommunity.com/>`__.
|
2019-02-15 22:32:09 -08:00
|
|
|
|
|
|
|
|
|
Vetting an idea publicly before going as far as writing a ZIP is meant
|
2019-03-19 20:02:47 -07:00
|
|
|
|
to save both the potential Owner and the wider community time. Asking
|
2019-02-15 22:32:09 -08:00
|
|
|
|
the Zcash community first if an idea is original helps prevent too much
|
|
|
|
|
time being spent on something that is guaranteed to be rejected based on
|
|
|
|
|
prior discussions (searching the internet does not always do the trick).
|
|
|
|
|
It also helps to make sure the idea is applicable to the entire
|
2019-03-19 20:02:47 -07:00
|
|
|
|
community and not just the Owner. Just because an idea sounds good to
|
|
|
|
|
the Owner does not mean it will work for most people in most areas
|
2019-02-15 22:32:09 -08:00
|
|
|
|
where Zcash is used.
|
|
|
|
|
|
2019-03-19 20:02:47 -07:00
|
|
|
|
Once the Owner has asked the Zcash community as to whether an idea
|
2019-02-15 22:32:09 -08:00
|
|
|
|
has any chance of acceptance, a draft ZIP should be presented to the
|
2019-04-09 15:30:47 -07:00
|
|
|
|
`Zcash Community Forum <https://forum.zcashcommunity.com/>`__.
|
2019-03-19 20:02:47 -07:00
|
|
|
|
This gives the Owner a chance to flesh out the draft ZIP to make it
|
2019-02-15 22:32:09 -08:00
|
|
|
|
properly formatted, of high quality, and to address additional concerns
|
|
|
|
|
about the proposal. Following a discussion, the proposal should be
|
|
|
|
|
submitted to the `ZIPs git repository <https://github.com/zcash/zips>`__
|
|
|
|
|
as a pull request. This draft must be written in ZIP style as described
|
|
|
|
|
below, and named with an alias such as
|
2019-02-23 21:25:56 -08:00
|
|
|
|
``zip-zatoshizakamoto-42millionzec`` until the ZIP Editors have assigned
|
2019-03-19 20:02:47 -07:00
|
|
|
|
it a ZIP number (Owners MUST NOT self-assign ZIP numbers).
|
2019-02-15 22:32:09 -08:00
|
|
|
|
|
2019-03-19 20:02:47 -07:00
|
|
|
|
ZIP Owners are responsible for collecting community feedback on both
|
2019-02-15 22:32:09 -08:00
|
|
|
|
the initial idea and the ZIP before submitting it for review. However,
|
2019-04-09 15:30:47 -07:00
|
|
|
|
wherever possible, long open-ended discussions on forums should be avoided.
|
2019-02-15 22:32:09 -08:00
|
|
|
|
|
|
|
|
|
It is highly recommended that a single ZIP contain a single key proposal
|
|
|
|
|
or new idea. The more focused the ZIP, the more successful it tends to
|
|
|
|
|
be. If in doubt, split your ZIP into several well-focused ones.
|
|
|
|
|
|
2019-02-23 21:25:56 -08:00
|
|
|
|
When the ZIP draft is complete, the ZIP Editors will assign the ZIP a
|
2019-02-15 22:32:09 -08:00
|
|
|
|
number, label it as Standards Track, Informational, or Process, and
|
2019-02-23 21:25:56 -08:00
|
|
|
|
merge the pull request to the ZIPs git repository. The ZIP Editors
|
2019-02-15 22:32:09 -08:00
|
|
|
|
will not unreasonably reject a ZIP. Reasons for rejecting ZIPs include
|
|
|
|
|
duplication of effort, disregard for formatting rules, being too
|
|
|
|
|
unfocused or too broad, being technically unsound, not providing proper
|
|
|
|
|
motivation or not in keeping with the Zcash philosophy. For a ZIP to be
|
|
|
|
|
accepted it must meet certain minimum criteria. It must be a clear and
|
|
|
|
|
complete description of the proposed enhancement. The enhancement must
|
|
|
|
|
represent a net improvement. The proposed implementation, if applicable,
|
|
|
|
|
must be solid and must not complicate the protocol unduly.
|
|
|
|
|
|
2019-03-19 20:02:47 -07:00
|
|
|
|
The ZIP Owner may update the draft as necessary in the git
|
|
|
|
|
repository. Updates to drafts should also be submitted by the Owner
|
2019-02-15 22:32:09 -08:00
|
|
|
|
as pull requests.
|
|
|
|
|
|
2019-02-23 21:25:56 -08:00
|
|
|
|
|
2019-02-15 22:32:09 -08:00
|
|
|
|
Transferring ZIP Ownership
|
|
|
|
|
--------------------------
|
|
|
|
|
|
|
|
|
|
It occasionally becomes necessary to transfer ownership of ZIPs to a new
|
2019-03-19 20:02:47 -07:00
|
|
|
|
Owner. In general, we'd like to retain the original Owner as a
|
|
|
|
|
co-Owner of the transferred ZIP, but that's really up to the original
|
|
|
|
|
Owner. A good reason to transfer ownership is because the original
|
|
|
|
|
Owner no longer has the time or interest in updating it or following
|
2019-02-15 22:32:09 -08:00
|
|
|
|
through with the ZIP process, or has fallen off the face of the 'net
|
|
|
|
|
(i.e. is unreachable or not responding to email). A bad reason to
|
|
|
|
|
transfer ownership is because you don't agree with the direction of the
|
|
|
|
|
ZIP. We try to build consensus around a ZIP, but if that's not possible,
|
|
|
|
|
you can always submit a competing ZIP.
|
|
|
|
|
|
|
|
|
|
If you are interested in assuming ownership of a ZIP, send a message
|
2019-03-19 20:02:47 -07:00
|
|
|
|
asking to take over, addressed to both the original Owner and the ZIP
|
|
|
|
|
Editors. If the original Owner doesn't respond to email in a timely
|
2019-02-23 21:25:56 -08:00
|
|
|
|
manner, the ZIP Editors will make a unilateral decision (it's not like
|
2019-02-15 22:32:09 -08:00
|
|
|
|
such decisions can't be reversed :).
|
|
|
|
|
|
2019-02-23 21:25:56 -08:00
|
|
|
|
|
2019-02-15 22:32:09 -08:00
|
|
|
|
ZIP Editors
|
|
|
|
|
-----------
|
|
|
|
|
|
2019-03-19 19:41:33 -07:00
|
|
|
|
The current ZIP Editors are Daira Hopwood, representing the Electric Coin
|
2019-02-15 22:32:09 -08:00
|
|
|
|
Company, and Josh Cincinnati, representing the Zcash Foundation. Both
|
|
|
|
|
can be reached at zips@z.cash . The current design of the ZIP Process
|
|
|
|
|
dictates that there are always at least two ZIP Editors: one from the
|
2019-03-19 19:41:33 -07:00
|
|
|
|
Electric Coin Company and one from the Zcash Foundation. Additional Editors may
|
2019-02-15 22:32:09 -08:00
|
|
|
|
be selected by consensus among the current Editors.
|
|
|
|
|
|
2019-02-23 21:25:56 -08:00
|
|
|
|
|
2019-02-15 22:32:09 -08:00
|
|
|
|
ZIP Editor Responsibilities & Workflow
|
|
|
|
|
--------------------------------------
|
|
|
|
|
|
2019-04-09 16:34:15 -07:00
|
|
|
|
The ZIP Editors subscribe to the `Zcash Community Forum.
|
|
|
|
|
<https://forum.zcashcommunity.com/>`__
|
2019-02-15 22:32:09 -08:00
|
|
|
|
|
|
|
|
|
For each new ZIP that comes in an Editor confirms the following:
|
|
|
|
|
|
2019-02-23 21:25:56 -08:00
|
|
|
|
* Read the ZIP to check if it is ready: sound and complete. The ideas
|
|
|
|
|
must make technical sense, even if they don't seem likely to be
|
|
|
|
|
accepted.
|
|
|
|
|
* The title should accurately describe the content.
|
2019-04-09 15:30:47 -07:00
|
|
|
|
* The ZIP draft must have been sent to the Zcash Community Forum or as
|
|
|
|
|
a PR to the `ZIPs git repository <https://github.com/zcash/zips>`__
|
2019-02-23 21:25:56 -08:00
|
|
|
|
* Motivation and backward compatibility (when applicable) must be
|
|
|
|
|
addressed.
|
|
|
|
|
* The licensing terms are acceptable for ZIPs.
|
2019-02-15 22:32:09 -08:00
|
|
|
|
|
2019-03-19 20:02:47 -07:00
|
|
|
|
If the ZIP isn't ready, the editor will send it back to the Owner for
|
2019-02-15 22:32:09 -08:00
|
|
|
|
revision, with specific instructions.
|
|
|
|
|
|
|
|
|
|
Once the ZIP is ready for the repository it should be submitted as a
|
2019-02-23 21:25:56 -08:00
|
|
|
|
"pull request" to the `ZIPs git repository <https://github.com/zcash/zips>`__
|
2019-03-30 10:30:15 -07:00
|
|
|
|
where it may get further feedback. It should not contain a ZIP number,
|
|
|
|
|
and should be labelled "WIP" in the pull request.
|
2019-02-15 22:32:09 -08:00
|
|
|
|
|
|
|
|
|
The ZIP Editors will:
|
|
|
|
|
|
2019-02-23 21:25:56 -08:00
|
|
|
|
* Assign a ZIP number in the pull request.
|
2019-03-30 10:30:15 -07:00
|
|
|
|
* Merge the pull request when it is ready and remove the "WIP" label.
|
2019-02-15 22:32:09 -08:00
|
|
|
|
|
|
|
|
|
The ZIP editors monitor ZIP changes and update ZIP headers as
|
|
|
|
|
appropriate.
|
|
|
|
|
|
|
|
|
|
The ZIP Editors MAY reject a proposed ZIP or update to an existing ZIP
|
|
|
|
|
for any of the following reasons:
|
|
|
|
|
|
2019-02-23 21:25:56 -08:00
|
|
|
|
* it violates the Zcash Code of Conduct [#conduct]_ ;
|
|
|
|
|
* it appears too unfocused or broad;
|
|
|
|
|
* it duplicates effort in other ZIPs without sufficient technical justification
|
|
|
|
|
(however, alternative proposals to address similar or overlapping problems
|
|
|
|
|
are not excluded for this reason);
|
|
|
|
|
* it has manifest security flaws (including being unrealistically dependent
|
|
|
|
|
on user vigilance to avoid security weaknesses);
|
|
|
|
|
* it disregards compatibility with the existing Zcash blockchain or ecosystem;
|
|
|
|
|
* it is manifestly unimplementable;
|
|
|
|
|
* it includes buggy code, pseudocode, or algorithms;
|
|
|
|
|
* it manifestly violates common expectations of a significant portion of the
|
|
|
|
|
Zcash community;
|
|
|
|
|
* it updates a Draft ZIP to Released when there is significant community
|
|
|
|
|
opposition to its content (however, Draft ZIPs explicitly may describe
|
|
|
|
|
proposals to which there is, or could be expected, significant community
|
|
|
|
|
opposition);
|
|
|
|
|
* in the case of a Released ZIP, the update makes a substantive change to
|
|
|
|
|
which there is significant community opposition;
|
|
|
|
|
* it is dependent on a patent that could potentially be an obstacle to
|
|
|
|
|
adoption of the ZIP;
|
|
|
|
|
* it includes commercial advertising or spam;
|
|
|
|
|
* it disregards formatting rules;
|
|
|
|
|
* it makes non-editorial edits to previous entries in a ZIP's Change history;
|
|
|
|
|
* an update to an existing ZIP extends or changes its scope to an extent
|
|
|
|
|
that would be better handled as a separate ZIP;
|
|
|
|
|
* a new ZIP has been proposed for a category that does not reflect its content,
|
|
|
|
|
or an update would change a ZIP to an inappropriate category;
|
|
|
|
|
* it updates a Released ZIP to Draft when the specification is already
|
|
|
|
|
implemented and has been in common use;
|
|
|
|
|
* it violates any specific "MUST" or "MUST NOT" rule in this document;
|
2019-03-19 20:02:47 -07:00
|
|
|
|
* the expressed political views of a Owner of the document are inimical
|
2019-02-23 21:25:56 -08:00
|
|
|
|
to the Zcash Code of Conduct [#conduct]_ (except in the case of an update
|
2019-03-19 20:02:47 -07:00
|
|
|
|
removing that Owner);
|
|
|
|
|
* it is not authorized by the stated ZIP Owners;
|
|
|
|
|
* it removes an Owner without their consent (unless the reason for removal
|
|
|
|
|
is directly related to a breach of the Code of Conduct by that Owner).
|
2019-02-15 22:32:09 -08:00
|
|
|
|
|
|
|
|
|
The ZIP Editors MUST NOT unreasonably deny publication of a ZIP proposal
|
|
|
|
|
or update that does not violate any of these criteria. If they refuse a
|
|
|
|
|
proposal or update, they MUST give an explanation of which of the
|
|
|
|
|
criteria were violated, with the exception that spam may be deleted
|
|
|
|
|
without an explanation.
|
|
|
|
|
|
|
|
|
|
Note that it is not the primary responsibility of the ZIP Editors to
|
|
|
|
|
review proposals for security, correctness, or implementability.
|
|
|
|
|
|
|
|
|
|
Please send all ZIP-related communications either by email to
|
|
|
|
|
<zips@z.cash>, or by opening an issue on the `ZIPs issue
|
|
|
|
|
tracker <https://github.com/zcash/zips/issues>`__. All communications
|
2019-02-23 21:25:56 -08:00
|
|
|
|
should abide by the Zcash Code of Conduct [#conduct]_
|
2019-02-15 22:32:09 -08:00
|
|
|
|
and follow `the GNU Kind Communication
|
|
|
|
|
Guidelines <https://www.gnu.org/philosophy/kind-communication.en.html>`__
|
|
|
|
|
|
2019-02-23 21:25:56 -08:00
|
|
|
|
|
2019-02-15 22:32:09 -08:00
|
|
|
|
ZIP format and structure
|
|
|
|
|
========================
|
|
|
|
|
|
2019-02-23 21:25:56 -08:00
|
|
|
|
ZIPs SHOULD be written either in reStructuredText [#rst]_ or LaTeX [#latex]_.
|
|
|
|
|
In the latter case, a `Makefile` MUST be provided to build (at least) a
|
|
|
|
|
PDF version of the document.
|
2019-02-15 22:32:09 -08:00
|
|
|
|
|
2019-02-23 21:25:56 -08:00
|
|
|
|
Each ZIP SHOULD have the following parts:
|
2019-02-15 22:32:09 -08:00
|
|
|
|
|
2019-02-23 21:25:56 -08:00
|
|
|
|
* Preamble -- Headers containing metadata about the ZIP (`see
|
2019-03-19 19:43:48 -07:00
|
|
|
|
below <#zip-header-preamble>`__).
|
2019-02-23 21:25:56 -08:00
|
|
|
|
The License field of the preamble indicates the licensing terms,
|
2019-03-19 19:43:48 -07:00
|
|
|
|
which MUST be acceptable according to `the ZIP licensing requirements <#zip-licensing>`__.
|
2019-02-15 22:32:09 -08:00
|
|
|
|
|
2019-02-23 21:25:56 -08:00
|
|
|
|
* Terminology -- Definitions of technical or non-obvious terms used
|
|
|
|
|
in the document.
|
2019-02-15 22:32:09 -08:00
|
|
|
|
|
2019-02-23 21:25:56 -08:00
|
|
|
|
* Abstract -- A short (~200 word) description of the technical issue
|
|
|
|
|
being addressed.
|
2019-02-15 22:32:09 -08:00
|
|
|
|
|
2019-03-19 19:55:15 -07:00
|
|
|
|
* Motivation -- The motivation is critical for ZIPs that want to change
|
|
|
|
|
the Zcash protocol. It should clearly explain why the existing
|
|
|
|
|
protocol is inadequate to address the problem that the ZIP solves.
|
|
|
|
|
|
2019-02-23 21:25:56 -08:00
|
|
|
|
* Specification -- The technical specification should describe the
|
|
|
|
|
interface and semantics of any new feature. The specification should be
|
|
|
|
|
detailed enough to allow competing, interoperable implementations for
|
|
|
|
|
any of the current Zcash platforms.
|
2019-02-15 22:32:09 -08:00
|
|
|
|
|
2019-02-23 21:25:56 -08:00
|
|
|
|
* Rationale -- The rationale fleshes out the specification by
|
|
|
|
|
describing what motivated the design and why particular design
|
|
|
|
|
decisions were made. It should describe alternate designs that were
|
|
|
|
|
considered and related work. The rationale should provide evidence of
|
|
|
|
|
consensus within the community and discuss important objections or
|
|
|
|
|
concerns raised during discussion.
|
2019-02-15 22:32:09 -08:00
|
|
|
|
|
2019-03-19 19:29:12 -07:00
|
|
|
|
* Security and privacy considerations -- If applicable, security
|
|
|
|
|
and privacy considerations should be explicitly described, particularly
|
|
|
|
|
if the ZIP makes explicit trade-offs or assumptions. For guidance on
|
|
|
|
|
this section consider `RFC 3552 <https://tools.ietf.org/html/rfc3552>`__.
|
|
|
|
|
as a starting point.
|
|
|
|
|
|
2019-03-19 19:49:37 -07:00
|
|
|
|
* Reference implementation -- Literal code implementing the ZIP's
|
|
|
|
|
specification, and/or a link to the reference implementation of
|
|
|
|
|
the ZIP's specification. The reference implementation must be
|
2019-02-23 21:25:56 -08:00
|
|
|
|
completed before any ZIP is given status “Implemented”, but it
|
|
|
|
|
generally need not be completed before the ZIP is accepted into
|
|
|
|
|
Proposed.
|
2019-02-15 22:32:09 -08:00
|
|
|
|
|
|
|
|
|
ZIP header preamble
|
2019-02-23 21:25:56 -08:00
|
|
|
|
-------------------
|
|
|
|
|
|
|
|
|
|
Each ZIP must begin with an RFC 822-style header preamble. The following
|
|
|
|
|
header fields are REQUIRED::
|
|
|
|
|
|
|
|
|
|
ZIP:
|
|
|
|
|
Title:
|
2019-03-19 20:02:47 -07:00
|
|
|
|
Owners:
|
2019-02-23 21:25:56 -08:00
|
|
|
|
Status:
|
|
|
|
|
Category:
|
|
|
|
|
Created:
|
|
|
|
|
License:
|
|
|
|
|
|
|
|
|
|
The following additional header fields are OPTIONAL::
|
|
|
|
|
|
|
|
|
|
Discussions-To:
|
|
|
|
|
Network Upgrade:
|
|
|
|
|
Obsoleted by:
|
|
|
|
|
Updated by:
|
|
|
|
|
Obsoletes:
|
|
|
|
|
Updates:
|
2019-02-15 22:32:09 -08:00
|
|
|
|
|
2019-03-19 20:02:47 -07:00
|
|
|
|
The Owners header lists the names and email addresses of all the
|
|
|
|
|
Owners of the ZIP. The format of the Owners header value SHOULD be::
|
2019-02-15 22:32:09 -08:00
|
|
|
|
|
2019-02-23 21:25:56 -08:00
|
|
|
|
Random J. User <address@dom.ain>
|
2019-02-15 22:32:09 -08:00
|
|
|
|
|
2019-03-19 20:02:47 -07:00
|
|
|
|
If there are multiple Owners, each should be on a separate line.
|
2019-02-15 22:32:09 -08:00
|
|
|
|
|
|
|
|
|
While a ZIP is in private discussions (usually during the initial Draft
|
2019-04-09 15:30:47 -07:00
|
|
|
|
phase), a Discussions-To header will indicate the URL where the ZIP is
|
|
|
|
|
being discussed. No Discussions-To header is necessary if the ZIP is being
|
|
|
|
|
discussed privately with the Owner.
|
2019-02-15 22:32:09 -08:00
|
|
|
|
|
2019-02-23 21:25:56 -08:00
|
|
|
|
The Category header specifies the type of ZIP: Consensus, Standards Track,
|
2019-02-15 22:32:09 -08:00
|
|
|
|
Informational, or Process.
|
|
|
|
|
|
2019-02-23 21:25:56 -08:00
|
|
|
|
The Created header records the date that the ZIP was submitted.
|
|
|
|
|
Dates should be in yyyy-mm-dd format, e.g. 2001-08-14.
|
2019-02-15 22:32:09 -08:00
|
|
|
|
|
|
|
|
|
Auxiliary Files
|
2019-02-23 21:25:56 -08:00
|
|
|
|
---------------
|
2019-02-15 22:32:09 -08:00
|
|
|
|
|
|
|
|
|
ZIPs may include auxiliary files such as diagrams. Auxiliary files
|
2019-03-19 19:55:15 -07:00
|
|
|
|
should be included in a subdirectory for that ZIP; that is, for any ZIP
|
|
|
|
|
that requires more than one file, all of the files SHOULD be in a
|
|
|
|
|
subdirectory named zip-XXXX.
|
2019-02-15 22:32:09 -08:00
|
|
|
|
|
2019-02-23 21:25:56 -08:00
|
|
|
|
|
2019-04-04 13:24:46 -07:00
|
|
|
|
ZIP categories
|
|
|
|
|
==============
|
2019-02-15 22:32:09 -08:00
|
|
|
|
|
|
|
|
|
There are several kinds of ZIP:
|
|
|
|
|
|
2019-02-23 21:25:56 -08:00
|
|
|
|
* A Consensus ZIP describes a change that affects the consensus protocol
|
|
|
|
|
followed by all Zcash implementations.
|
|
|
|
|
|
|
|
|
|
* A Standards Track ZIP describes any non-consensus change that affects
|
|
|
|
|
most or all Zcash implementations, such as a change to the network
|
|
|
|
|
protocol, or any change or addition that affects the interoperability
|
|
|
|
|
of applications using Zcash.
|
|
|
|
|
|
2019-03-19 19:49:37 -07:00
|
|
|
|
Consensus and Standards Track ZIPs consist of two parts: a design document
|
2019-02-23 21:25:56 -08:00
|
|
|
|
and a reference implementation.
|
|
|
|
|
|
|
|
|
|
* An Informational ZIP describes Zcash design issues, or general
|
|
|
|
|
guidelines or information for the Zcash community, that do not fall
|
|
|
|
|
into either of the above categories. Informational ZIPs do not
|
|
|
|
|
necessarily represent a Zcash community consensus or recommendation,
|
|
|
|
|
so users and implementers are free to ignore Informational ZIPs or
|
|
|
|
|
follow their advice.
|
|
|
|
|
|
|
|
|
|
* A Process ZIP describes a process surrounding Zcash, or proposes a
|
|
|
|
|
change to (or an event in) a process. Process ZIPs are like Standards
|
|
|
|
|
Track ZIPs but apply to areas other than the Zcash protocol itself.
|
|
|
|
|
They may propose an implementation, but not to Zcash's codebase; they
|
|
|
|
|
often require community consensus; unlike Informational ZIPs, they
|
|
|
|
|
are more than recommendations, and users are typically not free to
|
|
|
|
|
ignore them. Examples include procedures, guidelines, changes to the
|
|
|
|
|
decision-making process, and changes to the tools or environment used
|
|
|
|
|
in Zcash development.
|
2019-02-15 22:32:09 -08:00
|
|
|
|
|
|
|
|
|
New categories may be added by consensus among the ZIP Editors.
|
|
|
|
|
|
2019-02-23 21:25:56 -08:00
|
|
|
|
|
2019-02-15 22:32:09 -08:00
|
|
|
|
ZIP Status Field
|
|
|
|
|
================
|
|
|
|
|
|
2019-02-23 21:25:56 -08:00
|
|
|
|
* Draft: All initial ZIP submissions have this status.
|
2019-02-15 22:32:09 -08:00
|
|
|
|
|
2019-03-19 20:02:47 -07:00
|
|
|
|
* Withdrawn: If the Owner decides to remove the ZIP from
|
2019-02-23 21:25:56 -08:00
|
|
|
|
consideration by the community, they may set the status to Withdrawn.
|
2019-02-15 22:32:09 -08:00
|
|
|
|
|
2019-02-23 21:25:56 -08:00
|
|
|
|
* Active: Typically only used for Process/Informational ZIPs, achieved
|
2019-04-09 15:30:47 -07:00
|
|
|
|
once rough consensus is reached in PR/forum posts from Draft Process ZIP.
|
2019-02-15 22:32:09 -08:00
|
|
|
|
|
2019-02-23 21:25:56 -08:00
|
|
|
|
* Proposed: Typically the stage after Draft, added to a ZIP after
|
2019-04-09 15:30:47 -07:00
|
|
|
|
consideration, feedback, and rough consensus from the community. The ZIP
|
|
|
|
|
Editors must validate this change before it is approved.
|
2019-02-15 22:32:09 -08:00
|
|
|
|
|
2019-02-23 21:25:56 -08:00
|
|
|
|
* Rejected: The status when progress hasn't been made on the ZIP in one
|
2019-03-19 20:02:47 -07:00
|
|
|
|
year. Can revert back to Draft/Proposed if the Owner resumes work
|
2019-02-23 21:25:56 -08:00
|
|
|
|
or resolves issues preventing consensus.
|
2019-02-15 22:32:09 -08:00
|
|
|
|
|
2019-03-19 19:34:22 -07:00
|
|
|
|
* Implemented: When a Consensus or Standards Track ZIP has a working
|
|
|
|
|
reference implementation but before activation on the Zcash network.
|
|
|
|
|
|
2019-02-23 21:25:56 -08:00
|
|
|
|
* Final: When a Consensus or Standards Track ZIP is both implemented
|
|
|
|
|
and activated on the Zcash network.
|
2019-02-15 22:32:09 -08:00
|
|
|
|
|
2019-02-23 21:25:56 -08:00
|
|
|
|
* Obsolete: The status when a ZIP is no longer relevant (typically when
|
|
|
|
|
superseded by another ZIP).
|
2019-02-15 22:32:09 -08:00
|
|
|
|
|
|
|
|
|
More details on the status workflow in the section below.
|
|
|
|
|
|
|
|
|
|
Specification
|
|
|
|
|
-------------
|
|
|
|
|
|
2019-03-19 20:02:47 -07:00
|
|
|
|
Owners of a ZIP may decide on their own to change the status between
|
2019-02-15 22:32:09 -08:00
|
|
|
|
Draft or Withdrawn.
|
|
|
|
|
|
|
|
|
|
A ZIP may only change status from Draft (or Rejected) to Proposed, when
|
2019-03-19 20:02:47 -07:00
|
|
|
|
the Owner deems it is complete and there is rough consensus on the
|
2019-04-09 15:30:47 -07:00
|
|
|
|
forums, validated by both the Electric Coin Company and Zcash Foundation
|
2019-02-23 21:25:56 -08:00
|
|
|
|
Editors. One Editor will not suffice -- there needs to be consensus
|
|
|
|
|
among the Editors. If it's a Standards Track ZIP, upon changing status to
|
|
|
|
|
Proposed the Editors will add the optional ``Network Upgrade`` header
|
|
|
|
|
to the preamble, indicating the intent for the ZIP to be implemented in
|
2019-03-19 19:49:37 -07:00
|
|
|
|
the specified network upgrade. (All ``Network Upgrade`` schedules will be
|
2019-04-09 15:30:47 -07:00
|
|
|
|
distributed via the Zcash Community Forum by the Editors.)
|
2019-02-15 22:32:09 -08:00
|
|
|
|
|
|
|
|
|
A Standards Track ZIP may only change status from Proposed to
|
2019-03-19 20:02:47 -07:00
|
|
|
|
Implemented once the Owner provides an associated reference
|
2019-02-23 21:25:56 -08:00
|
|
|
|
implementation, typically in the period after the network upgrade's
|
2019-03-19 20:02:47 -07:00
|
|
|
|
specification freeze but before the implementation audit. If the Owner
|
|
|
|
|
misses this deadline, the Editors or Owner(s) may choose to update
|
2019-02-23 21:25:56 -08:00
|
|
|
|
the ``Network Upgrade`` header to target another upgrade, at their
|
|
|
|
|
discretion.
|
2019-02-15 22:32:09 -08:00
|
|
|
|
|
|
|
|
|
ZIPs should be changed from Draft or Proposed status, to Rejected
|
|
|
|
|
status, upon request by any person, if they have not made progress in
|
2019-03-19 20:02:47 -07:00
|
|
|
|
one year. Such a ZIP may be changed to Draft status if the Owner
|
2019-02-15 22:32:09 -08:00
|
|
|
|
provides revisions that meaningfully address public criticism of the
|
|
|
|
|
proposal, or to Proposed status if it meets the criteria required as
|
|
|
|
|
described in the previous paragraph.
|
|
|
|
|
|
2019-02-23 21:25:56 -08:00
|
|
|
|
A Consensus or Standards Track ZIP becomes Final when its associated
|
|
|
|
|
network upgrade or other protocol change is activated on Zcash's mainnet.
|
2019-02-15 22:32:09 -08:00
|
|
|
|
|
|
|
|
|
A Process or Informational ZIP may change status from Draft to Active
|
2019-04-09 15:30:47 -07:00
|
|
|
|
when it achieves rough consensus on the forum or PR. Such a proposal is
|
2019-02-15 22:32:09 -08:00
|
|
|
|
said to have rough consensus if it has been open to discussion on the
|
2019-04-09 15:30:47 -07:00
|
|
|
|
forum or GitHub PR for at least one month, and no person maintains
|
2019-02-15 22:32:09 -08:00
|
|
|
|
any unaddressed substantiated objections to it. Addressed or obstructive
|
|
|
|
|
objections may be ignored/overruled by general agreement that they have
|
|
|
|
|
been sufficiently addressed, but clear reasoning must be given in such
|
|
|
|
|
circumstances.
|
|
|
|
|
|
|
|
|
|
When an Active or Final ZIP is no longer relevant, its status may be
|
|
|
|
|
changed to Obsolete. This change must also be objectively verifiable
|
|
|
|
|
and/or discussed. Final ZIPs may be updated; the specification is still
|
|
|
|
|
in force but modified by another specified ZIP or ZIPs (check the
|
|
|
|
|
optional Updated-by header).
|
|
|
|
|
|
2019-02-23 21:25:56 -08:00
|
|
|
|
|
2019-02-15 22:32:09 -08:00
|
|
|
|
ZIP Comments
|
|
|
|
|
============
|
|
|
|
|
|
|
|
|
|
Comments from the community on the ZIP should occur on the Zcash
|
2019-04-09 15:30:47 -07:00
|
|
|
|
Community Forum and the comment fields of the pull requests in
|
2019-02-15 22:32:09 -08:00
|
|
|
|
any open ZIPs. Editors will use these sources to judge rough consensus.
|
|
|
|
|
|
2019-02-23 21:25:56 -08:00
|
|
|
|
|
2019-02-15 22:32:09 -08:00
|
|
|
|
ZIP licensing
|
|
|
|
|
=============
|
|
|
|
|
|
2019-02-23 21:25:56 -08:00
|
|
|
|
New ZIPs may be accepted with the following licenses. Each new ZIP MUST
|
|
|
|
|
identify at least one acceptable license in its preamble. Each license
|
|
|
|
|
MUST be referenced by their respective abbreviation given below.
|
2019-02-15 22:32:09 -08:00
|
|
|
|
|
2019-02-23 21:25:56 -08:00
|
|
|
|
For example, a preamble might include the following License header::
|
2019-02-15 22:32:09 -08:00
|
|
|
|
|
2019-02-23 21:25:56 -08:00
|
|
|
|
License: BSD-2-Clause
|
|
|
|
|
GNU-All-Permissive
|
2019-02-15 22:32:09 -08:00
|
|
|
|
|
|
|
|
|
In this case, the ZIP text is fully licensed under both the OSI-approved
|
|
|
|
|
BSD 2-clause license as well as the GNU All-Permissive License, and
|
|
|
|
|
anyone may modify and redistribute the text provided they comply with
|
2019-02-23 21:25:56 -08:00
|
|
|
|
the terms of *either* license. In other words, the license list is an
|
|
|
|
|
"OR choice", not an "AND also" requirement.
|
2019-02-15 22:32:09 -08:00
|
|
|
|
|
|
|
|
|
It is also possible to license source code differently from the ZIP
|
2019-02-23 21:25:56 -08:00
|
|
|
|
text. This case SHOULD be indicated in the Reference Implementation
|
|
|
|
|
section of the ZIP. Again, each license MUST be referenced by its
|
|
|
|
|
respective abbreviation given below.
|
|
|
|
|
|
|
|
|
|
Statements of code licenses in ZIPs are only advisory; anyone intending
|
|
|
|
|
to use the code should look for license statements in the code itself.
|
|
|
|
|
|
|
|
|
|
ZIPs are not required to be *exclusively* licensed under approved
|
|
|
|
|
terms, and MAY also be licensed under unacceptable licenses
|
|
|
|
|
*in addition to* at least one acceptable license. In this case, only the
|
|
|
|
|
acceptable license(s) should be listed in the License header.
|
|
|
|
|
|
2019-02-15 22:32:09 -08:00
|
|
|
|
|
|
|
|
|
Recommended licenses
|
2019-02-23 21:25:56 -08:00
|
|
|
|
--------------------
|
|
|
|
|
|
|
|
|
|
* MIT: `Expat/MIT/X11 license <https://opensource.org/licenses/MIT>`__
|
|
|
|
|
* BSD-2-Clause: `OSI-approved BSD 2-clause
|
|
|
|
|
license <https://opensource.org/licenses/BSD-2-Clause>`__
|
|
|
|
|
* BSD-3-Clause: `OSI-approved BSD 3-clause
|
|
|
|
|
license <https://opensource.org/licenses/BSD-3-Clause>`__
|
|
|
|
|
* CC0-1.0: `Creative Commons CC0 1.0
|
|
|
|
|
Universal <https://creativecommons.org/publicdomain/zero/1.0/>`__
|
|
|
|
|
* GNU-All-Permissive: `GNU All-Permissive
|
|
|
|
|
License <http://www.gnu.org/prep/maintain/html_node/License-Notices-for-Other-Files.html>`__
|
|
|
|
|
* Apache-2.0: `Apache License, version
|
|
|
|
|
2.0 <http://www.apache.org/licenses/LICENSE-2.0>`__
|
|
|
|
|
|
|
|
|
|
In addition, it is RECOMMENDED that literal code included in the ZIP be
|
2019-02-15 22:32:09 -08:00
|
|
|
|
dual-licensed under the same license terms as the project it modifies.
|
|
|
|
|
For example, literal code intended for zcashd would ideally be
|
|
|
|
|
dual-licensed under the MIT license terms as well as one of the above
|
|
|
|
|
with the rest of the ZIP text.
|
|
|
|
|
|
|
|
|
|
Not recommended, but acceptable licenses
|
2019-02-23 21:25:56 -08:00
|
|
|
|
----------------------------------------
|
|
|
|
|
|
|
|
|
|
* BSL-1.0: `Boost Software License, version
|
|
|
|
|
1.0 <http://www.boost.org/LICENSE_1_0.txt>`__
|
|
|
|
|
* CC-BY-4.0: `Creative Commons Attribution 4.0
|
|
|
|
|
International <https://creativecommons.org/licenses/by/4.0/>`__
|
|
|
|
|
* CC-BY-SA-4.0: `Creative Commons Attribution-ShareAlike 4.0
|
|
|
|
|
International <https://creativecommons.org/licenses/by-sa/4.0/>`__
|
|
|
|
|
* AGPL-3.0+: `GNU Affero General Public License (AGPL), version 3 or
|
|
|
|
|
newer <http://www.gnu.org/licenses/agpl-3.0.en.html>`__
|
|
|
|
|
* FDL-1.3: `GNU Free Documentation License, version
|
|
|
|
|
1.3 <http://www.gnu.org/licenses/fdl-1.3.en.html>`__
|
|
|
|
|
* GPL-2.0+: `GNU General Public License (GPL), version 2 or
|
|
|
|
|
newer <http://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html>`__
|
|
|
|
|
* LGPL-2.1+: `GNU Lesser General Public License (LGPL), version 2.1 or
|
|
|
|
|
newer <http://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html>`__
|
2019-02-15 22:32:09 -08:00
|
|
|
|
|
|
|
|
|
Not acceptable licenses
|
2019-02-23 21:25:56 -08:00
|
|
|
|
-----------------------
|
2019-02-15 22:32:09 -08:00
|
|
|
|
|
|
|
|
|
All licenses not explicitly included in the above lists are not
|
2019-02-23 21:25:56 -08:00
|
|
|
|
acceptable terms for a Zcash Improvement Proposal.
|
2019-02-15 22:32:09 -08:00
|
|
|
|
|
|
|
|
|
Rationale
|
|
|
|
|
---------
|
|
|
|
|
|
|
|
|
|
Bitcoin's BIP 1 allowed the Open Publication License or releasing into
|
|
|
|
|
the public domain; was this insufficient?
|
|
|
|
|
|
2019-02-23 21:25:56 -08:00
|
|
|
|
* The OPL is generally regarded as obsolete, and not a license suitable
|
|
|
|
|
for new publications.
|
|
|
|
|
* The OPL license terms allowed for the author to prevent publication
|
|
|
|
|
and derived works, which was widely considered inappropriate.
|
|
|
|
|
* In some jurisdictions, releasing a work to the public domain is not
|
|
|
|
|
recognised as a legitimate legal action, leaving the ZIP simply
|
|
|
|
|
copyrighted with no redistribution or modification allowed at all.
|
2019-02-15 22:32:09 -08:00
|
|
|
|
|
|
|
|
|
Why are there software licenses included?
|
|
|
|
|
|
2019-02-23 21:25:56 -08:00
|
|
|
|
* Some ZIPs, especially in the Consensus category, may include literal
|
|
|
|
|
code in the ZIP itself which may not be available under the exact
|
|
|
|
|
license terms of the ZIP.
|
|
|
|
|
* Despite this, not all software licenses would be acceptable for
|
|
|
|
|
content included in ZIPs.
|
2019-02-15 22:32:09 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
See Also
|
|
|
|
|
========
|
|
|
|
|
|
2019-02-23 21:25:56 -08:00
|
|
|
|
* `The GNU Kind Communication
|
|
|
|
|
Guidelines <https://www.gnu.org/philosophy/kind-communication.en.html>`__
|
|
|
|
|
* `RFC 7282: On Consensus and Humming in the
|
|
|
|
|
IETF <https://tools.ietf.org/html/rfc7282>`__
|
|
|
|
|
* `Zcash Network Upgrade Pipeline <https://z.cash/blog/the-zcash-network-upgrade-pipeline/>`__
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
References
|
|
|
|
|
==========
|
|
|
|
|
|
|
|
|
|
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
|
|
|
|
|
.. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism <https://github.com/zcash/zips/blob/master/zip-0200.rst>`_
|
|
|
|
|
.. [#conduct] `Zcash Code of Conduct <https://github.com/zcash/zcash/blob/master/code_of_conduct.md>`_
|
|
|
|
|
.. [#rst] `reStructuredText documentation <http://docutils.sourceforge.net/rst.html>`_
|
|
|
|
|
.. [#latex] `LaTeX -- a document preparation system <https://www.latex-project.org/>`_
|
|
|
|
|
|