Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adjust constitutionality down temporarily #4655

Closed
bedeho opened this issue Feb 22, 2023 · 2 comments
Closed

Adjust constitutionality down temporarily #4655

bedeho opened this issue Feb 22, 2023 · 2 comments
Assignees
Labels

Comments

@bedeho
Copy link
Member

bedeho commented Feb 22, 2023

Background

#4654

Proposal

A deeper fix will require substantial care and time, and in the interim it will get really slow to get runtime upgrades done the next few quarters, which is also the time where the need is likely highest, because we are so early in the lifetime of the system. Therefore, a temporary fix would be to just reduce the constitutionality of a set of proposals in Ephesus to reduce the magnitude of the problem.

Firs step here is to come up with some concrete set of proposals to change, and by how much, then we need to map out a new testing plan, and of course a JIP has to be prepared.

┆Issue is synchronized with this Asana task by Unito

@bwhm
Copy link
Member

bwhm commented Feb 24, 2023

Moved comment from #4654


To expand on the above, performing a runtime upgrade is a long and slow process - for a good reason.

Even assuming optimal conditions *, a constitutionality of 4 means the process will take anywhere between 35 and 57 days, with an (educated guess) expected average of about 45 days.
* means:

  • all council members for each of the 4 terms approves
  • none of them forgets, or has other issues
  • all elections proceeds perfectly
  • block freequency is at a perfect 6sec
  • etc.

As outlined #4653, temporarily lowering the constitutionality of runtime upgrades to 2 will not only allow faster improvements of the protocol in the early days, but also make it easier to plan around other proposals with a constitutionality > 1.

There are currently two other proposals with constitutionality > 2 - namely "Set Maximum Validator Count" and "Set Council Budget Increment" - both at 3. If these were kept at 3, it can be impossible to get any of them executed, even with planning, and it would make more sense to include the changes in a runtime upgrade proposal for speed.

The problem with runtime upgrade blocking other proposals, and the extra planning required, won't be fully resolved until a safe way of "migrating" non-finalized (and executed) proposals is researched, developed and finally added with a future runtime upgrade. It will at least reduce the problem.

In total, only three variables are changed for "production" as shown in the table below where "Current" refers and "Ephesus" refers to old and new Constitutionality values respectively:

Proposal \ Constitutionality Current Ephesus
Runtime Upgrade 4 2
Set Max Validator Count 3 2
Set Council Budget Increment 3 2

Given that these all have a grace period of 5 days, and all other proposals currently have a gracing period below that 5 days, it should always be possible to avoid having a proposal fail due to being "vetoed" at the time system.setCode is executed.

@bedeho
Copy link
Member Author

bedeho commented Mar 2, 2023

Done in #4653

@bedeho bedeho closed this as completed Mar 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants