Thanks for the proposal. I think overall it’s well rounded and makes sense, albeit being a bit more complex than Sumoshi’s proposal. The additional mechanisms seem to be well thought out and justified.
The dynamic quorum idea was criticized before, but using the mechanism you’ve outlined seems to address most of the concerns and I think it works well as a backstop to bypass dead/uninterested pillars otherwise potentially blocking all proposals.
I wonder though, will the Major proposals requiring supermajorty run into the problem of not being able to reach quorum?
Regarding Major and Minor proposals, I agree that drawing a line on what is major and what is minor can be difficult but requiring a supermajority for bridge maintenance for example seems pretty cumbersome also.
I think one use case for this feature would be that in some cases we’d want to atomically update multiple variables at the same time within a contract. For example if the dynamic plasma variables are configurable via governance then it’s highly likely we’ll want to change more than one variable at once.
To me it would seem that if you signal you’re running the updated node, it’s the same as a yes vote and it should be counted. And in this case I think the grace period also makes sense, so that pillars have time to update if the 2/3 signalling threshold is met quickly.
Thank you for the analysis @vilkris
You are right that my proposal adds a bit more complexity.
Hopefully people find it justified, (and we can implement it quickly enough)
My rationale is that sporks really are so special with their own risks that they deserve their own lane and logic, especially around activation.
The updating of contract variables will be very important later on as we tune the network, but right now could be considered more of a convenience/future proofing feature. Would have to make sure data type and range verifications are working as well. This is possibly something to carve out as future work if we’re running into time constraints.
Thank you for bringing up atomic updates for multiple variables. I hadn’t fully considered that. You’re right that for some updates, it’ll be necessary to make multiple changes at once to prevent unintended behavior.
With regards to major vs minor changes, if we have a minor category, I would like to come up with at least some sort of decision tree on how to categorize the action. I think there’s room for subjectivity, but some sort of guiding principles are needed.
And in terms of reaching quorum for major, perhaps in the future, we can take pillar momentum production into account for the active voting set. I think for sporks, we’ll keep it at total pillars no matter what though, with linearly decreasing yes vote requirement.
In terms of changing the bridge admin specifically on mainnet, is the idea to have a one time change to set the admin to the governance contract? If so, we might be able to just include that in our mainnet spork/hardfork.
I think I should quickly mention:
based on my suggested variable values, once an update is ready, it will take a minimum of 2 months to get activated on mainnet.
Spork creation phase 0 will take a month to evaluate, and if that passes, the Activation min length will be another month.
2 months feels okay to me.
1 Like
2 months feels more than sufficient IMO. Assuming we collectively get better at marketing updates, and offering support I think we can meet the requirements you proposed.
I dont know that I have a preference for Major vs Minor. My immediate thought is to start simple and only add complexity if needed
1 Like
Thanks, George, for the detailed spec.
“The number of YES votes must be >= double the number of NO votes no matter what phase.”
“Phase 8: 0% minimum YES votes required.”
“Votes do not reset between phases.”
I don’t think it matters too much, but under these conditions, if no pillars vote at all ( 0 YES votes, 0 NO votes), the proposal technically satisfies these criteria:
- 0 YES votes are ≥ 2 * 0 NO votes (0 ≥ 0)
- Phase 8 explicitly requires 0% YES votes
Thus, with zero participation, a spork proposal would automatically pass in Phase 8.
To avoid this scenario, it might help to set a minimum quorum or require at least one affirmative vote for the proposal to pass.
Interesting point!
I hadn’t thought of that.
Remember that a pillar has to propose the spork and make a large deposit.
That action is an implicit YES vote.
But maybe it would make sense to make it explicit.
When the spork is proposed, we can automatically make a yes vote for the pillar who proposed it.
The pillar can change it to a NO vote later.
But this means that there is always at least 1 vote.