I think we’ll have to iterate on the governance embedded.
But I want us to be conscious and transparent about what we are putting off until later.
My personal goal is to have the first iteration ready to ship by end of July.
So I want to first delineate 3 different scopes:
We currently have existing centralized admin functions. We need to quickly mitigate the possible harm without getting rid of any possible benefits.
It is likely that future embedded contracts will adopt an admin pattern as well so that it doesn’t have to duplicate governance logic. We should think about what a scalable solution looks like and consider different options in terms of sophistication vs delivery time.
A good on-chain governance system could be extended to many areas and applications. For example, as reflected in Sol’s post, we have had discussions before about how we can turn what are currently hard-coded constants into dynamic on-chain values which can be subject to governance. I’m also thinking with extension chains and chain relay that higher layers can utilize governance from the root chain.
Governance Framework: Theory
In terms of theory and a governance framework, we can look at real world governance systems and the balance of power. We have the legislative branch which writes the law, the executive branch which applies the law, and the judicial branch which interprets the law.
I think it’s useful to think about how these concepts and concerns translate to decentralized networks overall and in particular to NoM. Maybe later, we can talk about pillar burn vs delegation in terms of governance.
But in terms of actionable discussion, I want to point out that legislatures are often slow to act, if they can come to agreement to at all. However in many situations, e.g. war, quick and decisive action is needed. So legislatures often have means to grant additional temporary executive power.
And I think we will have to design with this as a consideration, especially given the maturity of our current pillar set.
To solve for the first scope, we can very quickly create an embedded contract with a set of pass through functions, for each admin interface.
For example, an embedded governance contract that has a CreateSpork, ActivateSpork, bridge/liq methods, which creates proposals for voting and that calls the relevant downstream functions if the proposal passes.
The main design question here would be what are the specific parameters for voting? E.g. time period, quorum, majority vs super-majority. Do different methods have different voting params?
Some possible concerns/limitations:
It gets into a slightly different topic of inactive pillars, but what happens if proposal can never reach quorum?
What if there’s an urgent bugfix where the time period doesn’t make sense?
Here, some sort of admin could make sense, likely the existing spork address to start.
As alluded to by scope 2, a possible downside to this simple approach is that every new embedded contract requiring admin functionality requires an extension of the governance contract interface.
A generic approach could be having the governance embedded expose one method “SendTx” which takes in the arguments of destination and downstream data. Maybe also fields to attach ZTS to the transaction.
However, this would make it more challenging to have different voting parameters for different types of transactions.
The most sophisticated and scalable option imho, is a templating system. It could expose two functions: ProposeTemplate, SendTemplate
The propose template method would take in a data structure defining a tx template, which fields are variable, and voting parameters. It’s like another layer of ABI.
The template would then undergo a vote for acceptance by the pillars. This voting threshold is defined by the governance contract.
If accepted, the template is stored on-chain/in the local db and given an ID.
The send template function would take in a template id and the parameters to render the template. It would then undergo a vote for acceptance by the pillars. This voting threshold is defined by the template.
A system like this likely would not need to be adjusted as new governance capabilities became available.
In terms of the the third scope, I have some ideas on how to migrate hardcoded constants to be on-chain data. But I want to first develop the first two scopes and get a sense of how much harder a sophisticated but scalable system would be over the simple option.