The only production embedded contracts were designed, developed and deployed by @sumamu & co team. And I remember that the audit results for their Solidity contracts were flawless.
I agree. But maybe they’ve already tested everything in the meanwhile.
I agree with testing the code anywhere you want, my intention is not to work alone in this community and I am always teamed up with sumamu. I just hope there will be pillar activity on this testnet, explorer that can interpret the account block data, available RPC, faucets so that we could stress test the contract.
@georgezgeorgez I am unable to follow your replies, could you please respond here? Why would you open another thread?
As an asnwer to geroge’s questions, I believe it’s important that I answer, even though I am not a pillar. I cannot reply on that post.
| Question | Answer | Notes |
|---|---|---|
| Q1 | B | Yes to type1/type2 decisions |
| Q2 | A | The minimum requirement for sporks must be the consensus requirement, which I believe is 66% |
| Q3 | C | I think 45 days at most is enough so that all pillars can see the proposal and understand it. I would not let it unlimited, if there is no interest in it, there is no vote, simple. If pillars change their minds, just create the proposal again. |
| Q4 | B | I think 50% is fine, altough, very important, some changes for the bridge (and in the future other embeddeds) like orchestratorInfo should be made with someone that understands the implications for the orchestrator operators |
| Q5 | B | 30 days |
| Q6 | B | I like the idea of depositing and getting the ZNN back if the proposal is accepted, otherwise it’s just like burning them, because the ZNN will be stuck in the embedded. My choice is 5/10 ZNN. The only problem I see is: with 1 ZNN, one could replicate a proposal 100 times, same name, description, etc but other data and pillars won’t know what to vote. The original owner must come in the community and tell pillars what is his address so they know what to vote, meaning also pillar responsibility. The idea with only a pillar creating it could be good, as it decreases the chance of a malicious actor and everyone that creates a project here must should some people from the community, should create a forum post, ask for opinions, no one will just come and post a github link and create the proposal. |
| Q7 | ABC | I would exclude them from all voting in the future if they don’t produce for a long period of time. The only problem here is when do we start looking if the hasn’t produced lately? At the moment of the count? When the proposal was created? What interval? 1 day / week / month? It is also resource intensive to look up this much I believe |
| Q8 | B | Dynamic forum in this form no, as it means that proposals with no interest from the pillars have a high chance of being accepted after a few months. I agree that we need some kind of mechanism for black swans and for now we do, the spork address or hard fork. |
I think we also have the HTLC and PTLC embedded contracts. The HTLC code was tested for many months (maybe a year) and was adopted into go-zenon. The PTLC contract has been out there for more than a year and I think some devs have been reviewing it and testing it for a long time.
I’m in full support of a governance module. I just want to make sure we have enough testing and review before it gets adopted.
+1
Thank you, I value your input.
No matter what we talk about, things need to pass governance and AZ.
The Hyperqube incubator and forum category is restricted to the pillars to get a good sense of what is passable.
If it was easy to have one thread, but filter out non-pillars when it came to voting, I would do it.
The process is not meant to be exclusive for the sake of being exclusive.
Rather it is meant to be indicative.
Can you let sumamu know that his engagement is requested, please? His opinion as well as technical insights will be valued, as well as yours.
Regards,
Stark
Since the advent of NoM it has been discussed many times that protocol changes should be accompanied by a ZIP. Is there a ZIP in the works?
Regarding the proposed implementation, it more or less adheres to this: Universal governance module proposal - #25 by sumoshi21
Personally I’d want some changes to the implementation but it’s not just up to me.
I don’t want to be too idealistic in terms of reaching a supermajority consensus off-chain regarding a specification but we should at least give pillars the chance to voice their opinion on the specification.
One way to do this could be to ask pillars a set of questions about the specification similar to how the hyperqube spec voting is being carried out: WP1 Governance Spec Feature Vote
And ask pillars to include a signature in their reply. Of course not all pillars will reply but at least it would give developers a lot more confidence in what to implement and approve into the codebase.
The community can help spread the word so that pillars will hopefully respond in a timely manner. A pillar can also say that they are indifferent to the details of the specification delegating the responsibility to the pillars that do have an opinion.
The only developers who have approval rights into the go-zenon codebase right now are: 0x3639, George, MoonBaZZe and sumamu.
Other questions:
How are others supposed to test the implementation?
What is the course of action if MrK doesn’t create a spork? How long do we wait for him?
I want to clarify that I believe there’s two parts to reaching consensus for a protocol change:
The first one is pillars voting on the details of the change. I expect that only a smaller subset of pillars have interest in participating in this vote and that’s fine.
The second one is pillars voting on accepting the proposed changes that are based on the first vote. This part should require a supermajority.
Make Governance Great Again
I’ve come up with a way to prove the supermajority of Pillars support the integration of the Governance module.
Basically I will keep creating phases until more than 66% of Pillars (distinct Pillars) have voted on the Project and its Phases.
This is a simple and straightforward way to gather distinct votes using AZ proposals without using any off-chain mechanisms.
I have voted NO on the phase for now because there is no ZIP.
Edit: To elaborate further, an implementation neutral spec (ie a ZIP) and pillar supermajority consensus are a subset of my maintainer criteria for go-zenon which I have published here: User:George - Zenon Wiki
I support the idea of a governance module, but with testing, review, and meeting the criteria of the go-zenon maintainers. I also think any changes to go-zenon should require a ZIP.
I don’t understand what we are voting on TBH. The AZ passed. The next phase is to get adoption. The Pillars cannot merge the code, and we don’t want that.
So are we asking the Pillars to “force” the maintainers to accept the code without review and testing? Or are we asking Pillars to approve the AZ again, but with more votes this time?
Hi all, seems like if i vote yes then I’m a sheep and if I vote no then I’m against making Zenon Governance great again
What if you vote Absent? Asking for a friend.