Background: ZIPs are Zenon Improvement Proposals. They are a document for introducing features or information to the NoM. The ZIP framework should become the standard way of formally communicating ideas about potential Zenon improvements.
Most projects maintain some central repository for improvement proposals. Editors review proposals based on established standards and publish those proposals after community engagement and debate. After an improvement proposal is published, developers can chose to write code to implement the proposal. And node operators are expected to upgrade.
NoM Zips: I believe that NoM should take a different approach to ZIPs. To understand why, let’s review how NoM sporks (upgrades) happen. But first, what is a spork? A spork is a mechanism used to safely deploy new features to the network through network-level variables to avoid the risk of unintended network forking during upgrades.
Today, Mr. Kaine holds the only address that is hard coded to accept sporks. Meaning, only the core team can activate a network upgrade. For example, the AZ framework was enabled by Pillars upgrading their node software and the core developers activating it. But in the future, that will change. The Pillar community will remove the hard coded address and enable on-chain Pillar voting to activate a spork.
Why create a ZIP framework that vests any control in central editors or the core team if that will need to change in the near future? Pillars will be responsible for upgrading and activating sporks. And it’s possible that delegators will come into play in sporks too. What if the threshold to activate a spork required 2/3 of Pillar vote by delegator weight?
Active Pillars will need to work with the community to hear, debate, and publish ZIPs they support. And once they support a ZIP, Pillars and the community will need to spread the word to garner additional network support.
In my opinion, if Pillars are responsible for upgrading the network, they should be responsible for managing ZIPs. We just need a few Pillars to engage in the process. Some might even delegate the responsibility to engaged community members. deeZNNutz.com is willing to participate. And I know others will too.
Potential ZIP Process:
Community Proposes ZIP in a public channel > Community debates and revises > Community finds a Pillar to sponsor the ZIP > Pillar publishes ZIP in repo > Pillar and community gets support of other Pillars > Pillars vote on ZIP with some on or off chain tool that “settles” results to the blockchain > If approved by some TDB metric official support is signaled > community then knows Pillars support the ZIP and can spend time to implement it > if code is necessary, the community creates code and audits > Pillars upgrade their node software > Pillars then vote to enable to spork based on TBD metric > if approved upgrade goes live
Pillars that do not upgrade after a spork will get forked away into a second chain. They can either run the second, smaller chain, or upgrade.
Note: I think we should try a spork ourselves. Some people have made changes to Syrius. Someone added a message field I believe. We can run through the ZIP process, upgrade our node software, and ask the devs to enable it. We need to accept the fact the core devs are not going to be here forever. I think they are withholding LP rewards as a message to us. GET THE ZIP FRAMEWORK DONE. They released one day of rewards and then stopped, so as to say, we are still here dumb asses. Do you job and we will release LP rewards.
I tried to synthesize these thoughts from George’s post on Github and me asking lots of questions about how this stuff works. I hope I have not made a super stupid mistake in all this. If so, I’m learning so please excuse me.