Rococo: ability to programatically assign slots to teams

[stiiifff]

Resolves #3942

Added new assigned_slots pallet with calls to assign permanent or temporary parachain slots on Rococo:

pub enum SlotLeasePeriodStart {
  Current,
  Next,
}

/// Assign a permanent parachain slot
pub fn assign_perm_parachain_slot(origin: OriginFor<T>, id: ParaId) -> DispatchResult {}

/// Assign a temporary parachain slot
pub fn assign_temp_parachain_slot(origin: OriginFor<T>, id: ParaId, lease_period_start: SlotLeasePeriodStart) -> DispatchResult {}

/// Unassign a permanent or temporary parachain slot
pub fn unassign_parachain_slot(origin: OriginFor<T>, id: ParaId) -> DispatchResult {}

Flow

• After a para was initialized with parasSudoWrapper.sudoScheduleParaInitialize) and onboarded as a parathread.
• Assign a temporary parachain slot with assignedSlots.assignTempParachainSlot, specifying the para Id and lease period start (Current lease period or next one).
• This will create a lease and the parathread will be upgraded to a parachain when its start lease period begins.
• When a slot's lease ends, the parachain is automatically downgraded to a parathread.
• The assigned_slots pallet keeps track of temporary slots and distributes turns fairly between temp slots (best effort).
• You can also assign a permanent (or long-running) slot with assignedSlots.assignPermParachainSlot or unassign a slot (permanent or temporary) with assignedSlots.unassignParachainSlot (this clears any lease which downgrades the para back to a parathread).
• The implementation (in the assigned_slots pallet) relies on the existing slot lease mechanism in the slots pallet.
• The following parameters have to be configured (with suggested values for Rococo):

pub const LeasePeriod: BlockNumber = 7 * DAYS;
// The number of lease periods a permanent parachain slot lasts
pub const PermanentSlotLeasePeriodLength: u32 = 26; 
// The number of lease periods a temporary parachain slot lasts
pub const TemporarySlotLeasePeriodLength: u32 = 1;
// The max number of permanent slots that can be registered
pub const MaxPermanentSlots: u32 = 5;
// The max number of temporary slots that can be registered
pub const MaxTemporarySlots: u32 = 20;
// The max number of temporary slots to be scheduled per lease periods
pub const MaxTemporarySlotPerLeasePeriod: u32 = 5;

[al3mart]

Looks good to me

[stiiifff]

Still need to write tests, but requesting early feedback.

[apopiak]

I'm probably being too harsh for a pallet that will only end up on a test chain, but I don't like that atomicity isn't kept and that a weakly bounded storage map is iterated.
Apart from that 👍 for making this happen.

[shawntabrizi]

You are already placing a hard dependency on the slots pallet, so probably you can do a more efficient check here directly with the storage struct.

[stiiifff]

Using contains-key on the leases storage map would not be enough .. then I'd have to re-implement some of the logic that's nicely encapsulated (and tested) in T::Leaser::already-leased function. Also this call shouldn't be called that often, so I'd go for correctness over further optimisation, what you think ?

[shawntabrizi]

Where is the programatic part of this?

You will run some off-chain bot that can call these functions?

Also, might be worth just implementing a "permanent" lease into the main slots pallet. Something we are seeming to need anyway.

[stiiifff]

Thx @shawntabrizi, gonna revise the code as per your comments.

Where is the programatic part of this? You will run some off-chain bot that can call these functions?

That was the phrasing of the initial issue, I realise now it is confusing, thank you for pointing it out.
The idea for now is to have a simple mechanism to assign perm/temp slots manually (sudo or governance) as mentioned here: https://polkadot.network/blog/rococo-revamp-becoming-a-community-parachain-testbed/.
It might be automated at a later stage (no idea how as of now).

Also, might be worth just implementing a "permanent" lease into the main slots pallet. Something we are seeming to need anyway.

Fair enough. I took the approach of doing it in a separate pallet, which is only active on Rococo / Westend, so as to avoid borking the slots pallet in this first iteration. I'd rather get this out in this form, and then move perm slots to the slots pallet in a separare PR, what you think ?

[shawntabrizi]

Is the end result much different than force_lease?

https://github.com/paritytech/polkadot/blob/master/runtime/common/src/slots.rs#L164

Could just change root to some origin like you have

[stiiifff]

Not much indeed. Then I'd remove the permanent -related stuff in favour of just using slots.force_lease (w/ a configurable origin) for any arbitrarily assigned long-term slot.
The new pallet would then only contain logic for short-term slots assigned in a rolling manner (could rename the pallet to rolling_slots).

[shawntabrizi]

In general i don't see that much issue with this PR, especially if it is only going on Rococo, but the "automation" part of this PR is quite questionable :)

Feels like all of this can be automated with more flexibility using a permissioned origin and some off-chain application.

[stiiifff]

One could argue anything can be automated with more flexibility using a permissioned origin and some off-chain app 😉
Jokes aside, I think the current logic fits the current needs for Rococo (scratch my last comment).
Also, as recommended, I've added the ForceOrigin to the slots pallet, which adds flexibility for other chains as well.
Let me know what you think.

[stiiifff]

@shawntabrizi Anything else you'd like to see revised ?

[stiiifff]

@shawntabrizi ?

[shawntabrizi]

@stiiifff please remember to update the Substrate docs on the new process you and your team has established: https://docs.substrate.io/tutorials/v3/cumulus/rococo/

polkadot-developers/substrate-docs#665

[stiiifff]

Thx ! I had not seen that issue, I will update the docs.