Proposal - AZ submission of first ZIP to validate process

Operations ╰ Funding | Submissions
1

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 https://forum2.zenon.org/t/proposal-zenon-improvement-proposals-zip-framework-development/592/17?u=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.

URL: https://forum2.zenon.org/t/proposal-az-submission-of-first-zip-to-validate-process/925

Team: n/a

Phases

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

Phase 1
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

Funding

Total Requested Funding = 10 ZNN and 100 QSR (minimum for A-Z proposals)
Project Duration = n/a

Other Information

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

SUBMISSION CONTENT

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.

image

Draft

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.

Proposed

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.

Final

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.

Implemented

When a Final ZIP has been proven to be valid and work as desired then the status will change to Implemented.

ZIP Types

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:

Header

Each ZIP must contain a RFC822 style header that contains metadata bout the ZIP. The headers must appear in the following order.

Field Description
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)
type ZIP type
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

Abstract

A short description of the technical issue being addressed or feature to be added.

Motivation

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.

Specification

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

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.

Implementation

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”.

License

The ZIP must be explicitly licensed under acceptable copyright terms.

ZIP Editors

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.

ZIP Comments

Comments on a ZIP should occur on the Zenon Community Forum or other static community channels that are publicly accessible.

ZIP References

Bitcoin Improvement Proposals: GitHub - bitcoin/bips: Bitcoin Improvement Proposals
Zcash Improvement Proposals: https://zips.z.cash/

ZIP License

It is recommended that all ZIP content are licensed under CC0 where applicable.

4 Likes
2
  • I support the recommendations in their current format
  • I support the recommendations with changes
  • I don’t support the recommendations
0 voters
3

To the technical developers out there who will use this process, can you please provide written support / objection / comments to post? I would like my vote to represent the feedback / opinions of the devs who will use the process the most.

1 Like
4

I’m also keen on additional feedback - I’ve spoken to quite a few on Telegram regarding individual aspects already so any additional thoughts would be greatly appreciated @devs

Worth noting also, this Stage 1 delivery of the ZIP process is aimed towards minimizing risk and isn’t looking to be too innovative or anything - following existing patterns in use in the crypto space

5

I voted yes on this and generally support the idea of moving forward with this as quickly as possible, as I think it’s a very good and practical first step, if not more. Keeping it simple it’s just the right approach for us now and it’s much better to identify potential deficiencies with the process when put to practice.

However, there’s one detail in the zip that directly contradicts this approach in my view.
My assumption is that we should try to limit the scope of zips as much as possible. It’s a bureaucratic process that brings administrative overhead and reduces flexibility in all things it concerns. It’s a process that’s absolutely necessary to organize consensus on changes to network critical components.

Syrius in particular does not fall into this category. More broadly, no software or other asset that depends on znnd, but on which znnd does not depend, falls into this category.
There are of course changes to znnd possible that don’t affect network operation; but since it concerns the same code I see every such change as necessary to go through a zip.
Znnd does not care about syrius, intuitively speaking, it does not know that it exists. The network does not know that it exists. It’s an auxiliary component with no relevance to network operation.

An external component that would fall into the zip-requiring category imo would be libpow. Like syrius, it’s an external software that can be built independently from znnd. Unlike syrius, znnd in its current iteration depends on it. Should znnd change in the future to eg depend on another powlib, libpow would no longer be subject to the zip process.
I’m more inclined to also exclude libpow than to include syrius in these processes.

I think we should edit the categories to make clear that only changes that directly concern the network operation or znnd have to undergo the zip process.
That would be a clarification and ultimately simplification, and I would prefer to do that now before stage 1.

That all said, should we decide to keep it like this I’m assuming we explicitly want to subject components that are not necessary or defining for the network to the zip process, and I’m fine with that.

4 Likes
6

@romeo I have a suggestion: To prevent the risk of Pillars

  • being mislead
  • colluding
  • approving a ZIP with material shortcomings simply due to a lack of knowledge or understanding
  • approving a ZIP without doing their due diligence

and hence vote on ZIPs that go against the general interests of the majority of the community, it would be good to add one additional step between the “Proposed” and “Final” stage called “Referendum”.

Referendum

A stage between Proposed and Final that gives the entire community (not only Pillars) a fixed timeframe until which they can veto any ZIP. If a certain quorum is achieved, the ZIP would be rejected. Only after that timeframe has lapsed, the ZIP may enter the Final stage.

To successfully challenge a ZIP during the Referendum a quorum would have to be reached. That quorum can be defined by a threshold in cumulative voting weight of Pillars signaling support for the Referendum. This means that Delegators are able to influence a Referendum/veto vote for a potentially harmful ZIP that goes against community interests by shifting their delegation power to the Pillars signaling support of the Referendum.

This would also act as a fail-safe mechanism for ZIPs (or Pillar votes in general) that are subject to controversy and e.g. passed only due to a very small margin.

This mechanism is based on Swiss democratic principles whereas the populace can challenge laws that were imposed by the parliament (= pillars). It requires 100k signatures (out of 8m Swiss citizens) to trigger a Referendum vote where every citizen (= delegators) can approve or reject the law in question.

Finally, this would also remove the burden from Editors to challenge the nature of ZIPs (rather than just their feasibility).

For this, we’d have to define a voting weight quorum that would trigger a proposal to be rejected.

Main Benefit: Protection of the protocol against the implementation of non-beneficial changes. This makes the entire governance process more resilient and stable.
Main Drawback: False negatives whereas veto voters could potentially reject genuinely beneficial ZIPs. To prevent false negatives, the required quorum for a Referendum must be sufficiently high.

2 Likes
7

I think this is a good idea too. For my smol brain, I wanted to clarify that you are proposing to “check” the approval with a weighted approval after the pillar vote. For example:

  • 30 pillars vote
  • 20 vote yes, and 10 vote no. Proposal passes.
  • Community hates the vote. They change their delegation to the 10 who voted no during the referendum period.
  • The 20 yes votes have 10B USD of delegation weight (total ZNN delegated). The 10 no votes have 100B of delegation weight.
  • The vote fails

I think this makes a lot of sense.

4 Likes
8

Referendum sounds great in principle, would love to hear what romeo thinks. Maybe there was a similar approach to it already implemented in other chains in his research.

1 Like
9

thanks Dumeril - for everyone’s info we discussed this in a bit more detail over PM and I agree with his thoughts on the matter. I’ll update the wording to be more clear and exclude aspects that don’t impact the core code

1 Like
10

Ok so I also like this idea. I need to think on this regarding it’s feasibility, my initial feel is this might be difficult to implement during this first iteration of the ZIP process and may be better suited to Stage 2. It would be best if this mechanism was also on-chain (both the delegation change which is already, and the subsequent tallying/collation of change).

I feel it also goes along with the original ethos of the Pillar model - where ZNN holders actually have influence over the direction of the system via their role as delegators - but would also need to overcome the issue of people delegating to maximize rewards only

11

I would like to see if there is another way of achieving this without it being weighted, as a large ZNN holder/s could in theory influence the referendum by moving their delegation around too.

Ideally, if it could be integrated into Syrius, you could have a veto/trigger re-vote button on ZIP proposals that have passed Pillar quorum. Clicking the button triggers a vote on the ZIP for all ZNN holders to participate in (not just Pillars) (similar to how phase voting works now for AZ).

It’s likely a large piece of work that requires significant thinking and assessment - but very promising

3 Likes
12

I’ve adjusted the wording to suit the ‘type’ recommendations from Dumeril and am updating the content of the Framework document to outline the idea of ‘referendum’ for future stages (but not submitting that for now, it will be included in a future revision of the framework doc).

I will look to submit this to A-Z shortly

3 Likes