ZIP:deeZNNutz-0001 Final

0x3639 · September 8, 2022, 12:15pm

Field	Description
zip	ZIP:deeZNNutz-0001
title	Zenon Improvement Proposal Process
author	@cryptocheshire @0x3639 @georgezgeorgez
status	Final
type	Informational ZIP
acceptance	upon usage by the community
activation	upon usage by the community
created	2022-09-17
license	GPL v3.0
link	https://forum2.zenon.org/t/zip-deeznnuts-0001-draft/991

Abstract

Inspired by Laanwj’s thoughts on decentralized Bitcoin core code maintenance and distribution, we are proposing a web of BIPs hosted by Pillars - the main validator nodes of the Zenon Network of Momentum.

Any Pillar can sponsor and host BIPs that should conform to certain standards. Unlike Bitcoin’s BIP Standard which gives that authority to one central entity, we are proposing to decentralize that central authority to every Pillar that wants to engage. And that web of BIPs is the Zenon Improvement Proposal - ZIP - process.

Motivation

Prior to this initiative,

An AZ Project to research and present a ZIP process was submitted to the community.
That work was completed and presented to the community for input.
The process was iterated and presented to the Pillars for a vote.
The Proposed ZIP Process was approved with 26 yes votes and the community asked Mr. Kaine to setup a ZIP repo in the Official Zenon Network repository. He was unresponsive.

We can only assume Mr. Kaine and his team

want the community to own and manage the ZIP process independently
want a ZIP format, but not to host the ZIP repo and/or provide centralized editor services

As a result, various community members iteratively developed this new ZIP framework which

does not rely on the Founding Team in any way
replaces most of the central editor role with decentralized Pillar ZIP sponsorships
proposes Spork creation and activation through the AZ address to activate protocol changes, as suggested by the founding developers.

With that background, we propose a more fault-tolerant and decentralized ZIP Process.**

What is a ZIP?

A Zenon Improvement Proposal (ZIP) is a design document that intends to provide information and justification for a proposed change or improvement to the Network of Momentum (NoM). A ZIP should provide a clear and concise technical specification of the change or feature.

The ZIP process is the primary mechanism for proposing new features, 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. This document formalizes the standard ZIP process.

ZIP Principles

ZIPs should not rely on any central editor or repository
Indexing of ZIPs should be fault tolerant
The ZIP process should be flexible enough to allow for continuous improvement
ZIPs should aim to improve the Zenon Network of Momentum in line with its core principle of progressive decentralization

ZIP Types

Informational ZIPs

describe procedural guidelines to the Zenon community, e.g. how to write and activate a ZIP (e.g. this ZIP:deeZNNutz-0001)
propose a behavioral protocol (or change of such) but do not affect the technical protocol
constitute best practices used by the community

Implementation ZIPs

describe a change in a protocol implementation
do not propose a protocol change
are done to improve node efficiency or to extend supported programming languages
do not require consensus to activate - any node can adopt the proposed change (or not)

Soft Forks

describe backward-compatible network changes
require a majority (>50%) of Pillars to enforce the new rules
non-upgrading Pillars will not be forked out but Momentums violating new rules may become invalid
do not require any nodes to upgrade to maintain consensus, since all Momentums with the new soft forked-in rules also follow the old rules

Spork Creation Threshold (= Pillar Acceptance Vote)

Pillar Majority (>50%)

Timeout: 4 weeks after voting begins

Spork Activation Threshold (= Pillar Activation Vote)

Pillar Majority (>50%)

Timeout: 4 weeks after voting begins

Hard Forks

are non-backward compatible changes that can affect the network protocol, consensus mechanism, ledger architecture, or any change that affects the interoperability of applications using Zenon
require a supermajority (67%-90%+) of consensus nodes to upgrade their software to activate
non-upgrading Pillars will be forked out

Spork Creation Threshold (= Pillar Acceptance Vote)

Low Pillar Majority (>67%)

Timeout: 4 weeks after voting begins

Spork Activation Threshold (= Pillar Activation Vote)

High Pillar Supermajority (>90%)

Timeout: 8 weeks after voting begins

Miscellaneous ZIPs

ZIPs that don’t fall in the above-mentioned categories
e.g. a community-requested change in S Y R I U S to create and activate Sporks
The community may signal consensus on a change request to maintainers of public repos

ZIP Activation

There are two ways to activate ZIPs

Implicit consensus
Community members individually decide to adopt changes proposed by Informational, Implementation, or Miscellaneous ZIPs.
Explicit consensus
A majority of Pillars reach a consensus to enforce a protocol change (Soft or Hard Fork) through a Spork.

What is a Spork?

A Spork is an embedded on-chain contract that activates a protocol change (Soft or Hard Fork) based on a conditional trigger, e.g. a certain amount of Pillars vote (through an on-chain voting mechanism) to activate the Spork object contained in the upgraded node software.

Who can introduce a Spork?

Any community member will be able to create and contribute to the activation of a Spork. As of this date [September 16th 2022], however, only one address is allowed to create and activate Spork Objects. It is specified in the genesis file as a hardcoded user address assumed to belong to the founding developers.

Accelerator Z - The first Zenon Spork

The founding team used the hardcoded Spork address to create the first Zenon Spork to activate the Pillar-governed project funding mechanism “Accelerator Z” (AZ).

The founding developers waited until they were confident that a supermajority (>67%) of Pillars had upgraded their node software which contained the Spork object to introduce the following conditional logic to the network:

Someone submits an AZ proposal in S Y R I U S
Pillars vote on intermittently locking funds from the Zenon Fabric address as a potential grant for the AZ applicant. The consensus threshold is:

“if >33% of Pillars vote & >50% of the votes are yes, then accept the AZ grant submission and lock requested funds”

Upon presenting his/her work, the applicant requests the release of the locked funds by the Pillars who again have to achieve the same consensus on the delivered work being satisfactory.

Creating & activating Sporks through the AZ address

Based on the founding developers’ indication that network changes could be voted on through AZ, ZIP co-author @georgezgeorgez outlined the following ZIP idea that would allow anyone in the community to create Spork-activated ZIPs:

Since the original Spork address to create and activate Sporks is hardcoded in the genesis file, it would have to be changed to a different address so that it can be used by the community to create and activate Sporks.

Accelerator Z already has some functionality to create transactions based on votes. Therefore, the community proposes to change that hardcoded Spork creation address to Accelerator Z contract address.

This would allow us to then change the Spork Contract so that only the AZ address can create and activate Sporks.

Then we can modify the conditional logic of the AZ contract to something like

“When Pillars vote and certain thresholds are met, then the contract sends a transaction to the spork contract to create or activate Sporks.”

This would give us community-activated Sporks that can be used for Soft and Hard Forks right from the S Y R I U S wallet through the Accelerator Z tab.

ZIP Process

Stage 1 - ZIP IDEA


Stage Content	Initial ZIP Proposal & Specification
Exit Criteria	ZIP proposal including arguments outlining feasibility and logically explaining why it results in an objective improvement of Zenon NoM is published for community discussion.

Stage Description

The ZIP process begins with a new idea for Zenon NoM. Each potential ZIP must have one or several authors who

write the ZIP in a standard format
recruit a sponsoring Pillar
shepherd the discussions in the appropriate forums
implement community feedback
build community consensus around the idea.

The ZIP author(s) should first attempt to ascertain whether the idea is ZIP-able. Ideas should be proposed in the ZIP Category of the forum so they can be found and indexed easily. The author of the idea should solicit feedback from the community and refine the idea. Posting to the main Zenon telegram chat and the Development & Technical Discussion forum is the best way to go about this.

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.

Vetting an idea publicly before going as far as writing a detailed ZIP specification is meant to save both the potential author and the wider community time. Asking the Zenon community first if an idea is original helps prevent too much time from being spent on something that is guaranteed to be rejected.

Stage 2 - PUBLIC DEBATE & REVISION


Stage Content	Public discourse on the merit and feasibility of the ZIP proposal.
Exit Criteria	Author has gauged community interest and support for the proposal has been sufficient to merit finding a sponsoring Pillar.

Stage Description

The author(s) should gather community feedback to iteratively refine and flesh out their ZIP idea until it can be specified with a sufficiently high degree of conformity with opinions voiced in the community.

The community should reject a ZIP proposal for the following reasons:

duplication of effort
refusal to refine the ZIP idea based on critical community feedback
being too unfocused or too broad
being technically unsound
not providing proper motivation or addressing backward compatibility
not being feasible
not in line with the principle of progressive decentralization

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 not complicate the protocol unduly

Before drafting an official ZIP, the author will have to identify a Pillar willing to sponsor the ZIP and add it to their ZIP repository for indexing by the Community Pointer repo.

Stage 3 - OFFICIAL ZIP PROPOSAL


Stage Content	- ZIP publication in sponsoring Pillar’s Git repository - ZIP indexing by Community Pointer Repo - Spork submission through AZ contract - ZIP Finalization in case of Informational (text) or Implementation (code) ZIP
Exit Criteria	- Author has found a sponsoring Pillar that has publicly announced ZIP sponsorship by adding the draft ZIP to its public repo. - Informational / Implementation ZIP has been finalized, or Spork has been proposed through the modified AZ contract (the new Spork contract address)

Stage Description

Once the author has gauged initial community interest, a Pillar must be found to endorse the ZIP through sponsorship by adding the ZIP to its public repository. This ensures the ZIP was critically reviewed by a Pillar holder who is willing to back it with its brand and reputation in the community.

Once a sponsoring Pillar has been found,

the author writes a properly formatted Draft ZIP. The Draft ZIP formatting standards used and outlined in this ZIP should be used as a reference.
the sponsoring Pillar publishes the Draft ZIP in its own public Git repository.
the author and sponsoring Pillar (the “Sponsors”) inform the community about the draft ZIP publication and endorsement through public channels (Github, IPFS, Gitlab, Telegram, Zenon Forum, etc.).
In case the ZIP proposes a protocol change requiring a Spork (for Soft or Hard Forks), the Sponsors must submit the ZIP proposal for an on-chain vote by Pillars through the (yet to be) modified AZ contract.
the Sponsors continue working with the community to solicit and implement feedback via pull requests or through public or private channels.

Decentralizing central editors with a Community Pointer Repo

We propose a repository structure that is fault-tolerant and resilient against censorship from central editors and/or hosting software providers. Pillars who want to sponsor ZIPs should set up a repository that can host the ZIP and accompanying code. Ideally, repositories are established across multiple service providers and sources: Github, Gitlab, Gitea, IPFS, and others.

Sponsoring Pillars must provide a Proof of Pillar (a signed message from the Pillar address) in the repo to prove participation and get indexed by the Central Pointer Repo that is established by the community and maintained at https://github.com/Zenon-Netowrk-ZIPs. This repo simply points to verified Pillar repos as a convenience to those searching for ZIPs.

The role of official editors in Zenon

maintain an official pointer repository that indexes pillar repos and the ZIPs in there
verify pillar ownership of their ZIP repositories (through signature file)
add them as a submodule to the Zenon Community repo
implement redundancy protocols or backups to replace a compromised pointer repo with another

The community pointer repo points to a ZIP folder hosted by each sponsoring Pillar. Anything added to it will appear in the pointer. It’s like a repo with shortcut folders to Pillar repositories.

Each sponsoring pillar maintains its own ZIP numbering while adhering to established formatting standards. The editor repo maintains standard format templates and best practice recommendations for sponsoring Pillars to use.

Note that individual Pillars can also choose to act as a pointer service by adding the repos of other Pillars as submodules to their own.

The Draft ZIP should be written in standard ZIP style as described below to ensure uniform ZIP proposal formatting across sponsoring Pillars. Sponsoring Pillars assign their own sequential numbering to ZIPs and maintain a list of ZIPs they sponsor(ed).

The ZIP naming and numbering convention must adhere to the following format:

[ZIP-PillarName-PillarZIPNumber]

e.g.

“ZIP:deeZNNutz-0001"

“ZIP:deeZNNutz-0002"

“ZIP:ZenonORG-0001”

“ZIP:ZenonORG-0002”

In addition, the sponsoring Pillar will assign a ZIP label “Informational ZIP”, “Implementation ZIP”, “Soft Fork”, “Hard Fork” etc., and give it the status “Draft”, “Accepted”, “Rejected”, “Withdrawn”, “Final”, “Replaced”, or “Active”.

The Community Pointer repo could thus look like this:

Name	Title	Label	Status
ZIP:deeZNNutz-0001	ZIP Process	Informational ZIP	Draft
ZIP:deeZNNutz-0002	Bitcoin<>Zenon merge mining	Soft Fork	Active
ZIP:ZenonORG-0002	RPC data compression for nodes 2.0	Implementation ZIP	Replaced

There are different ZIP statuses.

For Informational ZIPs and Implementation ZIPs which only require implicit consensus:

For Sporks that require explicit consensus by Pillars to be accepted and activated:

Status	Description
Idea	ZIP idea is circulated in the community in no specific format
Draft	ZIP idea is published in draft stage, adhering to formatting best practices
Rejected	ZIP proposal was rejected by the community
Withdrawn	ZIP proposal was withdrawn by the Sponsors
Accepted	Spork proposal acceptance vote reached required Pillar quorum
Final	Final ZIP implementation published and ready for activation
Replaced	ZIP implementation has been replaced by a newer or alternative version
Active	ZIP implementation has been activated

ZIPs relying on implicit consensus are finalized in step 4

Once an Informational, Implementation or Miscellaneous ZIP has been iteratively refined, and a reference Implementation in form of text or code published, it can be marked as “Final”. Once they are actively used (e.g. this ZIP:deeZNNutz-0001) or a pull request to a public repo (e.g. for a change to the S Y R I U S wallet) has been performed, the ZIP can be marked as “Active”.

ZIPs relying on explicit consensus kick off in step 4

On the other hand, ZIPs which propose protocol changes that lead to Soft or Hard Forks, and have to be activated by Pillars via a Spork, should pass the Pillar Acceptance vote before the reference implementation is completed.

This ensures that

all Pillars are informed about the proposed network change
all Pillars are given the opportunity to signal their support for it
ZIP sponsors can gauge Pillar support before engaging in significant implementation work

Reaching a majority quorum in the Pillar Acceptance vote marks a ZIP as “Accepted” and tells the authors there is significant interest for the Spork so that they may begin with the implementation work if it has not already started.

Any ZIP can also be “Rejected” or “Withdrawn” due to lack of community support or explicit opposition. It is important to have a record of this fact for future ZIP authors.

Some Informational ZIPs may also have a status of “Active” if they are never meant to be completed, E.g. this ZIP:deeZNNutz-0001.

The ZIP process for Informational, Implementation, and Miscellaneous ZIPs ends here. The following stages only apply for ZIPs leading to Sporks.

Stage 4 - SPORK CREATION


Stage Content	- Spork creation via AZ address - Community Acceptance signaling via signed messages - ZIP Acceptance Vote via modified AZ contract
Exit Criteria	Pillar Acceptance quorum reached / not reached within voting timeframe

Stage Description

Just like when someone submits a new Accelerator Z proposal, the ZIP author submits a Spork creation proposal through the modified AZ contract from within S Y R I U S.

Pillars can then vote on its Acceptance. If it passes, the Spork is created and “waits” for the ZIP authors to submit the Spork activation proposal (which is analogous to Pillars voting for an AZ phase, just with different activation criteria).

The point of the Acceptance vote is to

“lock in” the creation of a Spork on-chain
for a Spork ZIP to pass a first consensus filter
give the ZIP supporters the confidence to commit to the Spork activation, start planning for it, and accept that validators who don’t follow might be forked out

By helping Pillars make a qualified decision during the on-chain Acceptance vote, ZIP authors can increase their chances for a successful Spork activation. For this, they should reach out to the community and ask any ZNN holder to sign a message in S Y R I U S, e.g.

“ACCEPT ZIP:deeZNNutz-0001”

Community-provided signaling trackers (similar to taproot.watch) can record all signed messages, and cross-reference them with the amount of ZNN held in the addresses from which the signatures originated and whether the addresses are used by a “Delegator”, “Staker”, “Sentinel”, or “Pillar”.

This technique allows the entire community to indicate their support for a Spork ZIP, thus helping Pillars make a better voting decision while allowing the ZIP Sponsors to get some polling data on the community-wide support of their proposed network change.

If the Acceptance vote fails due to a timeout or too many negative Pillar votes, the ZIP Sponsors are free to choose whether they should redraft or abandon it.

If the Acceptance vote passes, it is a signal to the community developers that Pillars support the initiative and they will run the code after proper vetting. Developers should feel confident in spending time writing code to support the ZIP at this stage.

Stage 5 - IMPLEMENTATION DISTRIBUTION


Stage Content	- Reference implementation - Downloadable binaries
Exit Criteria	Reference implementation published on sponsoring Pillar Git repo

Stage Description

Once the reference implementation has been built, the sponsoring Pillar

publishes it on its Pillar Git repo
merges the ZIP code into its mainline repo
builds the binary and ensures other Pillars will be able to download and install it

The implementation contains the Spork Object whose activation is triggered by the Pillar Activation vote reaching the threshold defined in the paragraph ZIP TYPES.

Example: Spork Object for a Hard Fork would contain the following conditional activation trigger:

“activate if >90% of Pillars indicate they have updated their node software with the reference implementation of ZIP:deeZNNutz-0002 through the Activation vote”.

Anyone can also merge in the changes into their repo copies and build themselves. People can verify if it’s the same binary through hashes.

Stage 6 - COMMUNITY AUDIT


Stage Content	Audit timeframe & community feedback
Exit Criteria	Timeout of audit timeframe

Stage Description

Once the Sponsors announce the publication of the Final ZIP implementation they should include a soft deadline until community audits should be concluded.

Community members may comment on the implementation or directly push changes via pull request to the sponsoring Pillar’s ZIP repo. Once the code is complete and vetted by a process similar to the Bitcoin Contribution Criteria, the ZIP can be marked “Final”.

Stage 7 - PILLARS UPGRADE NODES & VOTE


Stage Content	Call to Pillars to signal ZIP implementation support
Exit Criteria	ZIP activation lock-in by reaching the activation vote quorum threshold

Stage Description

The ZIP Sponsors now submit an activation request for the proposed Spork in S Y R I U S. Pillars now have to upgrade their node software (if not already done so) and then vote on the activation of the Spork. Reaching the voting threshold will trigger the Spork activation transaction.

What happens if the Spork fails to activate in time? ZIP Sponsors will have to assess the reason for it and either extend the activation timeline or revise the ZIP if needed.

Stage 8 - SPORK ACTIVATION


Stage Content	Spork activation is triggered
Exit Criteria	ZIP is activated

Stage Description

Once sufficient Pillars have voted to reach the activation threshold the Spork is activated and non-supporting network participants may be forked out until they opt into the protocol change.

To prevent Pillars from voting on the activation without upgrading their node software, the following security mechanism will be implemented as a standard procedure as suggested by @georgezgeorgez:

When a Spork Acceptance vote passes, a Spork gets created with a unique ID. That unique ID gets added to a list in go-Zenon as part of the code change.

Now, when the Activation vote happens, a Pillar node won’t send the transaction to vote for Sporks unless it knows about it locally, by checking if its ID is in that hardcoded list of spork IDs in go-Zenon.

It’s like an account whitelisting. In general, the network allows you to send tx to whatever address but you can configure your wallet to only allow sending to preset addresses. Basically, we can do the same thing with spork IDs by configuring S Y R I U S to only allow voting for Sporks in its list. And the list gets updated when they download the new version.

This allows making sure a Pillar doesn’t sign the activation vote unless the upgrade happened.

Upon activation of the Spork, the sponsoring Pillar may now update the ZIP label to “Active” or “Replaced”.

Annex

Conditions for realization:

Modification of Spork Contract and change of Spork Creation Address
Spork ID whitelisting mechanism

Areas to improve and expand over time

Emergency ZIPs
Acceptance signaling tooling
Prepare contribution criteria for code submission

ZIP Format Guideline

Pillars should try to adhere to the same ZIP format and metadata requirements. The outline below is a guideline and can be used if a Pillars has not established their own.

Header

Each ZIP should contain a header that contains metadata about the ZIP. The headers should appear in the following order.

Field	Description
zip	Pillar Name + ZIP number, or “?” when prior to Pillar involvement
title	ZIP title
author	A comma-separated list of the authors (anon is acceptable)
status	Current status of the ZIP (draft, accepted, rejected, withdrawn, final, replaced, active)
type	ZIP type (Informational, Minor, Major)
acceptance	A minimum quorum threshold for acceptance signaling
activation	A minimum quorum threshold for activation of a spork object
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.

License

The ZIP should be licensed under GNU General Public License v3.0 to match the Zenon.network license.

ZIP Comments

Comments on a ZIP should occur where the draft was posted. There should be no requirement to exchange ideas on a specified medium.

ZIP References

ZIP License

This ZIP is licensed under GNU General Public License v3.0.

Change Log

dat_she_pepe · September 8, 2022, 4:38pm

Is the code implementation decentralised and automated in this kind of implentation ? Proposals could be code, like ethOS ? I’m thinking about Radicle when it comes to decentralized code. It would make ZNN a way to own code and not just tokens.

cryptocheshire · September 8, 2022, 4:42pm

Can you post a link to what you’re referring with radicle? In the current proposal the code is insofar decentralized as ZIP implementations would be published by sponsoring Pillars in their own repos. How they host these repos is up to them. Although Idk if the pointer service is also able to link to self-hosted repos (then again I wouldn’t know why not). @0x3639 maybe you know?

dat_she_pepe · September 8, 2022, 5:21pm

romeo · September 9, 2022, 2:10am

I’ve gone through it at a high level and my comments are below, in order of the post. No need to respond individually it’s just food for thought. TLDR I think it’s too complicated and requires significant manual intervention and effort at multiple stages.

acceptance >50% of Pillars
or >50% delegation weight
or >25% of Pillars AND >25% of delegation weight

I don’t think letting authors choose the consensus level and mechanism is appropriate. It should be predefined and clear.

We can only assume Mr. Kaine and his team wants the community to own and manage the ZIP process independently.

This is an assumption and should be excluded

Before drafting an official ZIP, the author will have to identify a Pillar willing to sponsor the ZIP. Pillars are responsible for upgrading the network and without their support, a ZIP will likely fail to get adopted.

How does one identify a sponsor? How do people get in contact with Pillar operators? Most are not involved in the community currently - you run the risk of ZIPs failing at the first stage unless a small (consistent) sub set of Pillar operators continue to be involved and sponsor. This has a high risk of being a central failure point - relies on small number of active pillar operators who would be required to continue to be engaged and active

Unlike core protocol changes, small enhancements or patches of Zenon implementations do not require standardization across all validators and public nodes; these don’t need a ZIP

This contradicts earlier statements and the defined ZIP categories: "The ZIP process is 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. "

The community should reject a ZIP proposal for the following reasons:
not in keeping with the Zenon philosophy

what is the zenon philosophy? Is this defined? To me it’s subjective in nature and could lead to proposals failing due to unmeasurable criteria.

Stage 3

Stage 3 is increasingly handraulic and puts a big onus of effort onto Pillar operators (who already maintain infrastructure and participate in AZ). Pillar participation is currently low, how do you ensure Pillars continue to participate? Many Pillars may not want (or have the skills) to participate in hosting a repo or creating a github account. Can they still “sponsor” the ZIP without any extra effort (that would be a better outcome imo)?

There is also no explanation of which ZIP status relates to what stage (Draft = stage 2 etc.)

Each sponsoring pillar maintains their own ZIP numbering and there is no strictly enforced ZIP format. However, the editor repo maintains standard format templates and best practice recommendations for sponsoring Pillars to use.

How does the editor ensure linkage between their own numbering/naming standard and whatever is on the Pillars own private repos? What if numerous ZIPs are active at once? Significant interaction required here and could be an avenue for human error. Who is the editor? Who votes them in? Are they reimbursed and if so who covers the cost?

Stage 4

Stage 4 is unnecessary imo and complicates matters significantly. For starters a 2/3 supermajority of ZNN is near impossible to achieve. How would you ensure voter participation?

The ZIP author is free to define in the Draft ZIP what is considered a sufficient quorum threshold; it may be lower for Minor or Informational ZIPs. Depending on the type of ZIP

This needs to be defined and not left up to the author (otherwise what’s stopping them from saying a 5% vote is enough)

To signal acceptance of the ZIP proposal, network participants can sign a transaction in S Y R I U S with a message generated in a community-developed tool (currently in development) with a message in a specific format such as “ACCEPT ZIP:deeZNNutz-0001” before the network reaches a certain predefined momentum, the Acceptance Snapshot Momentum Height.

You’re proposing a ZIP process that currently can’t be successfully undertaken due to this tool not existing

For Liquidity Providers who hold funds on other networks than Zenon NoM, the ZIP Sponsors should define corresponding block heights for the Acceptance Snapshots. Liquidity Providers will thus use their Private / Public Key Pair of their wZNN holding address to sign a transaction with the corresponding message before the block lapses.

This process is underdefined. Who counts the votes? Who validates that the keypair matches the LP holder? What about the orbital fund etc.? Will the tool automatically achieve all of this?

If the community has signaled a sufficiently high acceptance to continue pursuing a Major ZIP activation, a reference implementation must be built in the form of code, a patch, or a URL to the same.

What if its not a Major ZIP?

The sponsoring Pillar will further merge the ZIP code that has a conditional trigger into its mainline repo. Then the sponsoring Pillar owner needs to build the binary and make sure other Pillars will be able to download and install it

What validation occurs at this stage to ensure the safety of the binary? Who informs the Pillars it’s ready and at what date to install it? Who and how follows up with those who haven’t participated?

The sponsoring Pillar changes the label of the ZIP in their repo from “Draft” to “Final”.

What exactly triggers the change from Draft to Final? What metric has to be met?

Overall I’m concerned this will result in a highly involved process that could be hard to track, enforce and follow. You’ve essentially replaced the role of the editor in other BIP processes to that of the Pillar operators, which has the same drawbacks. I feel it needs to be streamlined and shortened to give it a better chance of success.

I’ve looked at this through the lens of the core teams expected upcoming protocol upgrade - i.e. will they engage to identify a Pillar sponsor and how etc.? How long would this process take to be finalized? Given they haven’t responded to the call to utilize the existing GitHub what makes you think they’ll want to be even more hands on with this process?

cryptocheshire · September 9, 2022, 7:57am

Hi @romeo thank you very much for the extensive feedback! I will still address all of it because it could be valuable for others to see the points you raised discussed.

#1

I would disagree here for a few obvious reasons:

different ZIPs need different quora
overall voting participation can significantly vary depending on the stage of the project and type of participant needed for a quorum (e.g. today, voting participation will probably be relatively low - in the future, this might change. Hence, it’s necessary to stay flexible)
This ZIP proposes general guidelines for quora thresholds. Generally, majorities should be the goal in any case. For Acceptance votes that affect Informational or Minor ZIPs, a simple majority of Pillars or all addresses (weighted by ZNN balance), may be sufficient. This is what ZIP:deeZNNutz-0001 proposes. For Acceptance votes of Major ZIPs, this threshold should probably be higher. Regarding the Activation of a Spork, a 2/3 supermajority should be the minimum (e.g. in Bitcoin the Taproot upgrade required a >90% miner participation to lock in) to prevent bad chain splits.
The fact that authors can choose consensus thresholds forces them to enter a discourse with the community. If the community opposes their proposition, they will have to adjust.

#2

It’s part of the motivation for this ZIP and it states that it’s an assumption. Removing it would question the motivation for this ZIP.

#3

How to get in touch with a sponsoring Pillar? By reaching out to Pillar holders through chat or the repos of sponsoring Pillars.
Pillars are among the most active network participants since they have to maintain infra and vote on proposals. They are also the ones who will ultimately have to upgrade their node software for ZIP activation (esp. Sporks). Pillars have the most skin in the game and they are the type of network participants who are most incentivized to sponsor network improvements. Pillars also need a certain technical savvyness and they tend to have the longest investment horizon among all network participants. Sponsoring ZIPs is also a way of brand-building for them and can help them attract delegators. I don’t see a better alternative tbh. Other network participants don’t have as high an incentive to sponsor ZIPs - and getting rid of sponsors means more responsibility for a central editor (THIS is definitely a central point of failure) or accepting there will be a lot of low-quality ZIP proposals that just waste everyone’s time.

#4

Thanks for spotting, that should say “Spork”, not “ZIP”. Edited.

#5

Fair point, though this was inspired by the BIP standard. We can specify this with e.g. “Going against the principle of progressive decentralization” or other examples. But overall I feel core community members who engage in ZIP debates know this refers to the cypherpunk / bitcoin ethos which Zenon emulates.

#6

Given that Pillars know how to run infra I don’t think it’s a big challenge for them to maintain a repo. The editor repo which runs the Pointer Service automatically tracks all sponsoring Pillar repos and changes in it. No extra effort from Pillars is needed beyond signing up on Github and creating a repo with a list of ZIPs they sponsor + give each ZIP a name & number. This is barely more difficult than creating an excel spreadsheet. The downloadable node binaries for major ZIPs can also be provided by the ZIP author, the Pillar just has to upload them into their repo so that the Pointer service can index them.

If the Pillars want to host their Git repo elsewhere than GitHub, more effort is needed.

Regarding Pillar participation: in theory, even a single Pillar is enough to sponsor ZIPs. Over time, the goal is to have multiple so that the ZIP process becomes more decentralized. Again, the key goal is to minimize dependence on central editors as much as possible. Running a pointer service is doesn’t create a single point of failure either.

“There is also no explanation of which ZIP status relates to what stage (Draft = stage 2 etc.)” thanks, will try to clarify this.

#7

The linkage is done by adding sponsoring Pillar repos as submodules to the editor’s Pointer Service repo. Once added, any changes on the Pillar’s repo are automatically synced with the editor’s repo.

The number of simultaneously active ZIPs is irrelevant – the Pointer Repo indexes it all.

There is no manual interaction required beyond adding a Pillar repo to the Pointer repo as a submodule after the editor has verified the Pillar owns that repo through a signed message.

Any dedicated community member can run a Pointer repo or help maintain the existing one. Efforts to do so can be covered through AZ or donations.

#8

Stage 4 is critical to get community acceptance for Informational and Minor ZIPs that don’t lead to a Spork. Voter participation depends on awareness creation – just like in every human political system.

The suggested supermajority of 2/3 is for Major ZIPs leading to a Spork which will split the network if the acceptance threshold is set too low. Then again, authors can set the necessary thresholds for Acceptance Votes themselves – this prevents a too rigid framework that imposes arbitrary quora.

With this step we want to ensure EVERY network participant can signal their support for ANY ZIP.

#9

This is why they need a sponsoring Pillar. A 5% acceptance quorum would be way too low and it would be very hard to find a sponsoring Pillar to back it with their name. Also, other community members will oppose the Draft ZIP after publication, preventing the ZIP proposal from getting the support needed.

Unless I’m mistaken, Informational or Minor ZIPs technically don’t need on-chain consensus by a supermajority to activate because they don’t lead to a Spork that can split the chain. Only Major ZIPs need a majority of Pillars (and maybe Sentinels in the future) to upgrade their node software in consensus.

#10

As stated in the quote the necessary tools are currently being developed and will be available in a few weeks. We will use this time to improve this Draft ZIP.

#11

While this might not be available from day 1. the tooling for vote counting should eventually be network agnostic and reliably validate/count votes of LPs on other chains too.

#12

The “Implementation” of Informational ZIPs is not code based but simply the description of the ZIP itself. This is the case for this very ZIP:deeZNNutz-0001
The implementation of Minor ZIPs doesn’t lead to a Spork the majority of nodes needs to support in order to become active. Minor ZIPs are more like a soft fork that is backwards compatible and can be supported by any number of nodes. The ZIP author will nevertheless want to know if enough nodes will run his reference implementation before building it.
For a Major ZIP it’s critical that a reference implementation is built after acceptance voting because the majority of Pillars have to support it.

#13

The code for the reference Implementation has been published and audited by the community. To ensure that files have not been tampered with you can either sign or hash them (see here for the description of this process). The answers to your other questions are answered in the subsequent stages.

#14

See table in stage 3

Needless to say, the current goal is to improve and streamline the process based on community feedback.

0x3639 · September 9, 2022, 10:53am

I’m going to try a different approach to responding. I’m going to make one post per item. Not sure if that will make it easier to review. But here goes:

Romes States

I wonder if this could be an attack vector. ZIP author proposes a low threshold for a ZIP to be adopted that could fracture the network. For example, a Spork that activates with just 50% of physical Pillars will confuse the network as to which fork is more relevant.

Should we propose a mandatory minimum to spork the network? 90% of functioning pillars (like taproot) or 90% of all Pillar weight (sum of all pillar delegation). Or if 90% is too high, propose another number.

0x3639 · September 9, 2022, 11:01am

Romeo States

This assumption is the premises of rethinking the ZIP process. The Community did prepare a ZIP that required Kaine to create a repo and become the editor of that repo. We know specifically that he wants a ZIP process because he asked for it after being absent for months. And to ignore our direct request to create the repo can only lead to one logical conclusion. In addition, the team started to spike LP rewards, as to say, yes, we are here working.

These facts tell me: (1) the team is working, and (2) the team does not want to create and manage a repo in /zenon-network on github.

I do not think we can ignore these signals in creating a ZIP process.

cryptocheshire · September 9, 2022, 11:03am

For a Spork to activate in the first place, Pillars must upgrade their node software so that it can activate. If Pillars upgrade their node software that contains a spork element that already activates if 50% of the Pillars run it, they would either be dumb or collude to intentionally split the network.

Note that no ZIP process will ever prevent this collusion from happening hence it’s not possible to enforce minimal thresholds (a central editor à la BIP doesn’t have that power either - miners can collude one way or the other if they want). This is why this ZIP can only provide best practice recommendations for consensus thresholds.

It’s to be assumed that Spork proposals with intentionally low consensus thresholds will simply not be accepted by the majority of Pillars. Leading the ones who do to fork themselves out.

0x3639 · September 9, 2022, 11:11am

Romeo States

Pillars who engage in the process will be available through public contact information. We can make that a stated requirement to host a repo.

This proposed process is far more decentralized and resilient than BTC’s BIP process. BIPs concentrate their entire process in one channel and one repo. It’s one failure point.

Our proposed process distributes that load across multiple Pillars. I hope we can get 5 to participate initially. That means we can loose the participation of 4 Pillars before the process fails. It’s resilient and distributed.

0x3639 · September 9, 2022, 11:28am

This comments approach sucks. I’m just going to add notes below:

Pillars can host repos in any public channel. It does not need to be Github. They could create a wordpress site and host it there. Or a gitbook, IPFS, bittorrent…

I think we should reconsider the minimum vote needed. What if someone tries to attack the network, or just F with it by getting a pillar and passing dumb ZIPs that only require one Pillar to approve it. Imagine some BTC whale maxi who hates us because we improve the lightning watchtowers… he gets a Pillar and makes life hell. something to think about.

Until tooling is available, we can always use an AZ vote temporarily.

0x3639 · September 9, 2022, 11:36am

I wonder how taproot set the 90% threshold. I will look into how they decided that number.

zyler9985 · September 9, 2022, 11:57am

I’m not as big-brained as you chads, but here’s my 2 cents on this …

I think they spiked LP rewards to reassure people that they are aware of the issue and will fund people fully eventually. We are close to phase 1 and they are probably going flat out, why spend time and energy fixing something when it may just change again anyway when phase 1 happens?

And Kaine ignored the request … did he? Isn’t it fair to speculate that the core team runs pillars, and they may have already voted to approve Romeo’s work? Maybe the timing isn’t right, and if we wait 3 months then Kaine will respond? Long silences are not anything new from the core team, they operate on their own time and want to wean us off of them.

I share romeo’s concerns about pillar participation, it’s unwise to assume that issue will organically disappear over night. And I share romeo’s other concern about the process possibly being convoluted – there’s wisdom in making things as easy and as simple as possible for people and pillars to follow.

And the point about your proposed process for ZIPs being theoretically far more decentralised and resilient than BTC’s BIP process … can this comparison be discussed more? As what you’re comparing is the ZIPs in theory, vs BIPs in practice … is there any real-world examples that already do basically what you’re proposing? Because when you actually try it, there can be unforseen difficulties and issues which you only learn about from doing it. If there are no analogous real-world examples, why not? Is that because it sounds good, but is not practical for some reason?

Finally, I love the ambition of improving on the way Bitcoin does it, my main concern would be on how practical this is, and do we have a list of unforeseen issues we may run into

cryptocheshire · September 9, 2022, 11:59am

For GitHub Submodules to work, the repo has to be on Git, no?

Regarding the BTC maxi whale “attack vector”: That’s not how it works. Nothing will happen if just a single Pillar implements e.g. a Spork. They will only fork themselves out. They can also not spam the community with ZIPs. BUT they could spam the Pointer Repo if it doesn’t have some indexation criteria implemented.

If the Pillar implements a non-spork node upgrade (e.g. a Minor ZIP) it will only affect their own node.

The acceptance vote tooling has zero influence on the network either. It’s just used to gauge sentiment.

0x3639 · September 9, 2022, 12:08pm

Rather than add a submodule, we could add a markdown file with a link to the repo hosted on IPFS, Bittorrent, etc…

0x3639 · September 9, 2022, 12:12pm

I’m just thinking about the instance where a Pillar does a bunch of informational / Minor ZIPs that are garbage. They would have a repo full of crap that does not follow the process, etc…

I suppose in that case, the Pointer repo would remove them or notify the community they are a spam repo and to ignore it. They could continue to create spam ZIPs, but the network would ignore them. And no author would approach them to host honest ZIPs. I assume this will happen.

I am concerned about the case where there is a controversial spork that gets proposed at 51% of Pillars. And the network fractures. Think BTC block warz.

cryptocheshire · September 9, 2022, 12:14pm

But that’s only for the downloadable binaries, no? The specs and code would still have to be hosted on Git otherwise the Pointer can’t index and integrate it into the consolidated ZIP list

0x3639 · September 9, 2022, 12:23pm

Yes, hosting the code on Git and referencing it with a submodule is idea. I don’t think anyone is going to post code in a wordpress blog TBH.

I think in the case of informational and some Minor ZIPs, they can easily be hosted anywhere with a pointer from the Main Pointer Repo.

Also regarding Romeo’s original concern about Pillars having the ability to host repos - Many of the Pillars are technical or coders. And many have repos today. I can think of 4 or 5 pillars that already have github accounts. And so long as we have one pillar repo for ZIPs we are in business. Also, if pillars leave or take down github, we can fork or restore their ZIP repos. As part of this process we plan to run a community backup of all repos. I have setup a test implementation here:

ToKR · September 9, 2022, 12:33pm

I don’t think the voting threshold should be defined by the author of a given proposal. Obvious potential for abuse imo. Low thresholds also seem to lend themselves to an attack by a malicious or
self serving party. (25% pillars with 25% weight could theoretically be just 25%) Maybe a definition of an “active pillar” would help solve the threshold dilemma? Achieving a 90% quorum of active pillars might be possible.

cryptocheshire · September 9, 2022, 12:35pm

This is great to know - should we include that in the process as “redundancy protocol” or something like that?