-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Explicit Para Lifecycle w/ Upgrades and Downgrades #2354
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks fine but needs a guide change.
With this approach I do want to note that once #2300 is implemented, Upgrade
and Downgrade
will take at least 2 full sessions but probably 3 or more, whereas really they only need to take at least 1 full session - the important thing is that the Upgrade
and Downgrade
are irreversibly on-chain during that 1 full session.
However that's not a pattern we expect often so it's fine if it takes longer than necessary.
This should be ready to review |
The Paras module is responsible for storing information on parachains and parathreads. Registered parachains and parathreads cannot change except at session boundaries. This is primarily to ensure that the number of bits required for the availability bitfields does not change except at session boundaries. | ||
The Paras module is responsible for storing information on parachains and parathreads. Registered | ||
parachains and parathreads cannot change except at session boundaries. This is primarily to ensure | ||
that the number of bits required for the availability bitfields does not change except at session |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why would the number of bits alter when upgrading/downgrading between parthread and parachain?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Every availability core gets its own bit in the bitfield. Parathreads are multiplexed over a fixed number of cores (configured per-session), whereas Parachains each get their own dedicated core. Upgrading from parathread to parachain would alter the amount of availability cores, which would alter the division of validators into groups, which could lead to consensus issues across forks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems ok. Would be nice to revisit at a later stage when we're thinking about more exotic scheduling systems (e.g. static slot scheduling where two or more parachains occupy slots in a fixed and repetitive pattern).
Would it be convenient to build in parachain/thread swap logic in here now? |
@gavofyork In a way, that could be done already with the higher-level code (slots) triggering a downgrade of one and an upgrade of the other. |
@rphmeier @gavofyork yeah, this is what I did in Registrar. A swap is just a scheduled upgrade and downgrade. I think that is granular enough. |
This reverts commit b2e9011.
There is more that needs to be updated in future PRs, but this is a reasonable checkpoint i think for the direction we are headed. Some more notes on what is next here: https://hackmd.io/XDkKzaYMSYumhNWzRMEvCQ |
This PR introduces an explicit lifecycle tracking for paras within the
runtime_parachains::paras
module.Changes to parachains are delayed by a session, and as such, tracking exactly what is happening to a Para ID was not very easy.
This introduces a new storage item
ParaLifecycles
which tracks the current lifecycle of any known Para Id. This replaces theParathreads
storage item since that data is now redundant.The possible lifecycle states are as follows:
Additionally, this PR introduces the workflow for upgrading a parathread into a parachain, and downgrading a parachain into a parathread.
This will be used for both the Slots/Auction module (which will perform upgrades/downgrades based on parachain auctions and offboarding slots), and also for swaps between parachains and parathreads.