Project Name: Proposal - AZ submission of ZIP-001 to validate process
Description: The intent of this proposal will be to have the Pillars vote on accepting the proposed ZIP framework and relevant recommendations (see Proposal: Zenon Improvement Proposals (ZIP) framework development - #17 by romeo). I will fill out this forum post with the recommendations, as well as the proposed content for ZIP-001 (to be added to the Zenon GitHub later on). I am finalizing the content now, but want to have a vote here on the forum prior to AZ submission.
What is your high-level roadmap? Only 1 phase, drafting of key content in this post, forum vote, then submission of the A-Z proposal
High level overview of main tasks:
- Draft submission
- Forum vote
- Submit to AZ
Completion of Phase 1 will be measured by:
- Finalizing the content of ZIP-001
Total Requested Funding = 10 ZNN and 100 QSR (minimum for A-Z proposals)
Project Duration = n/a
Risks, Assumptions, Known Issues, Dependencies: There is a risk that the core team do not agree with certain recommendations (such as the use of the official Zenon repository on GitHub for storing ZIPs), but I’m hoping the on-chain consensus proves the communities choices to an extent that they will participate and make the relevant changes.
Have you previously submitted a proposal (either in Accelerator-Z or Incubator)? No
The following table is for review and acceptance by the Pillars, it is the core of this submission - please review in detail and ask any questions here prior to voting if need be:
|#||Key Decision Point||Criticality||Recommendation|
|KDP001||Community and Pillar acceptance of the proposed ZIP framework||Stage 1||Accept the proposed framework|
|KDP002||Should an Accelerator-Z proposal be submitted for the key Stage 1 decision points to validate consensus on the way forward?||Stage 1||Submission to A-Z will be used to validate and accept the Stage 1 KDPs|
|KDP003||What numbering system should be used initially for the ZIP process?||Stage 1||Implement sequential numbering starting at 001 initially with a view to change during Stage 2 if necessary|
|KDP004||Should additional ZIP Types and Categories be introduced?||Stage 1||Move forward with the original 3 ZIP types initially with a view to review and change for Stage 2|
|KDP005||A community driven public Testnet will be required to support changes to the NoM – who will build and support his?||Stage 1||Community or Pillar operators to develop A-Z proposal for a funded public test environment|
|KDP006||Who will be the first Editors and have access to the Zenon GitHub for ZIPs?||Stage 1||ZIPS repository to be created under the official Zenon-Network GitHub. Core Zenon team to act as interim Editors for initial 6-12 months with a view to develop a community driven proposal for subsequent editors|
|KDP007||How much additional governance should be enforced in Stage 1 for off-chain activities?||Stage 1||Clear metrics should be defined for community consensus (>50% forum vote in favor), identifying Editors (same metrics as ZIP approval) and approving ZIPs (defined within ZIP001)|
The following would be the actual content for ZIP001
What is a ZIP
A Zenon Improvement Proposal (ZIP) is a design document or proposal that is intended to provide information and justification for a proposed change or improvement to the NoM. The ZIP should provide a clear and concise technical specification of the change or feature.
The ZIP process will be the primary mechanism for proposing new features, for collecting community input or consensus on an issue, and for documenting the design decisions that have gone into the development and growth of the Zenon Network. It is a community driven process where the author of the proposal is in charge of development and consensus building within the community.
For Zenon contributors, ZIPs are the core way to achieve and champion change to the NoM. Ensuring a consistent and trackable design taxonomy for the community to review and consume. A community code of conduct is currently under development on the community forum and the same core values and rules will be applied to ZIP submission – “ZIPs should be about tech and code, not about politics”.
ZIP Workflow and States
The ZIP workflow outlines the steps from which an idea transitions from draft to implemented feature or change. It also outlines the states of ZIPs throughout its life cycle.
All ZIPs start out as a draft idea proposed in the Zenon Community forum. An open and fair community review on the suggested idea should predate any formal submission. There are no formal template or structure requirements for this stage of the process. It is the authors responsibility to articulate their idea and generate enough interest and comments to maximize the chances of a successful submission. There are also no formal consensus requirements at the draft stage, anyone is free to move onto the Proposed stage if they wish even if community sentiment is not positive – however the on-chain voting mechanism where Pillars vote on the ZIP will likely fail without community backing. The author may choose to Withdraw the idea at this stage without issue.
If the Draft is moved to the Proposed stage by the author, it must be formally be submitted into the on-chain voting mechanism. The submission requires the ZIP template to be filled out and included in the submission, however at this stage it is not yet reviewed for completion or accuracy by the Editor. The Pillars will then vote on the proposal utilizing the currently active NoM consensus protocol. If the proposal does not reach Pillar consensus and fails, it is then deemed Rejected. If it passes, it moves onto the Final stage.
During the Final stage, the Editor assigns a ZIP number and documents the submission transaction ID from the on-chain Pillar vote. The proposal is submitted to the ZIP repository as a pull request. It is then reviewed for completion in relation to the template – if any changes are required the author will be advised. If the proposal requires code implementation, then the relevant code will be assessed by community developers on request from the Editor. It is important to note that at this point in the workflow the Pillars have already assessed the intent of the proposal and have agreed that it is beneficial to the network.
When a Final ZIP has been proven to be valid and work as desired then the status will change to Implemented.
There are three kinds of ZIP:
- A Major ZIP describes any change that affects most or all Zenon implementations, such as a change to the network protocol, ledger architecture or any change that affects the interoperability of applications using Zenon.
- An Informational ZIP describes a Zenon design issue, or provides general guidelines or information to the Zenon community, but does not propose a new feature. Informational ZIPs do not necessarily represent a specific recommendation, so users and implementers are free to ignore Informational ZIPs or follow their advice.
- A Minor ZIP describes a process surrounding Zenon, or proposes a change to (or an event in) a process. Minor ZIPs apply to areas other than the Zenon protocol itself. They may propose an implementation, but not to the Zenon 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 Zenon development.
Additional categories may be suggested via consensus among the ZIP Editors.
What belongs in a ZIP
A complete ZIP should contain the following parts:
Each ZIP must contain a RFC822 style header that contains metadata bout the ZIP. The headers must appear in the following order.
|zip||ZIP number, or “?” when prior to Editor involvement|
|title||ZIP title (max 30 characters)|
|author||A comma separated list of the author’s (community forum handle is suitable)|
|status||Current status of the ZIP (draft, withdrawn, proposed, rejected, final, implemented)|
|created||Date created on, in ISO 8601 (yyyy-mm-dd) format|
|license||Each new ZIP must identify at least one acceptable license|
|link||URL to proposal discussion|
A short description of the technical issue being addressed or feature to be added.
The motivation should clearly explain why this change or improvement is required or why the existing protocol is inadequate to address the problem that the ZIP solves.
The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Zenon platforms
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.
The actual code implementing the ZIP’s specification or a link to the reference implementation of the ZIP’s specification. The reference implementation is mandatory to be included prior to the ZIP being given status “Final” or “Implemented”.
The ZIP must be explicitly licensed under acceptable copyright terms.
The Editor role is introduced into the ZIP process after the Proposed phase and the on-chain vote. It is the responsibility of the Editor to:
- Read the ZIP to ensure it is sound and complete.
- Ensure the title accurately describes the content.
- Ensure the licensing terms are acceptable for the ZIP.
- Assign a ZIP number to the proposal.
- Update the ZIP header as appropriate.
As the Editor only gets involved after the ZIP has successfully achieved on-chain consensus they should not need to review the ZIP for validity or suitability. If, however a ZIP requires updates they will inform the author via the community forum. The Editor will only reject a proposal at this stage (after engagement with the community) for the following reasons:
- it has significant security flaws (including being unrealistically dependent on user vigilance to avoid security weaknesses);
- it disregards compatibility with the existing Zenon blockchain or ecosystem;
- it is manifestly unimplementable;
- it includes buggy code, pseudocode, or algorithms;
- 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;
- an update to an existing ZIP extends or changes its scope to an extent that would be better handled as a separate ZIP;
The ZIP Editor 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.
Note that it is not the primary responsibility of the ZIP Editor to review proposals for security or correctness.
Comments on a ZIP should occur on the Zenon Community Forum or other static community channels that are publicly accessible.
Bitcoin Improvement Proposals: GitHub - bitcoin/bips: Bitcoin Improvement Proposals
Zcash Improvement Proposals: https://zips.z.cash/
It is recommended that all ZIP content are licensed under CC0 where applicable.