1.3.0 Release

[bkontur]

TODO for removing older stuff

• DMPQueue Upgrade to latest [email protected] release #137 (comment)
  • remove pallet Remove DMP Queue and Allow system::authorize_upgrade in XCM #280

  impl cumulus_pallet_dmp_queue::Config
  ...
  DmpQueue: cumulus_pallet_dmp_queue = XY,
  

  • clean storage data (add migration or kill_storage) Remove DMP Queue and Allow system::authorize_upgrade in XCM #280
• remove duplicated check_sane_fees_values / diff_as_percent when [email protected]
• remove hack for skipping check-migrations for Encointer (based on Upgrade to latest [email protected] release #159 (comment))
• remove penpal-runtime-dotsama and instead fix like this when [email protected]
• fix Replace Snowbridge test helper methods once polkadot-sdk 1.8.0 has been released #234
• check runtimes-matrix.json and add uri for people-kusama and coretime-kusama - Add uri for people chains to the runtimes-matrix.json #425
• remove helpers module from inegrations-tests and re-use from polkadot-sdk Remove emulated test macros #363

[bkchr]

• Consider non-zero default nonce #248

[eskimor]

• Make sure this gets in. Either by using upcoming polkadot-sdk 1.10.0 or backporting 3714.

[bkchr]

• Coretime, depending on how the migration works on Kusama

[joepetrowski]

• Add Vesting to Asset Hubs #269

[rossbulat]

I've noticed pallet-staking has been bumped to 29.0.2 in the workspace, but just wanted to check paritytech/polkadot-sdk#2589 will be deployed in 1.3.0 as to move forward with controller account deprecation.

[s0me0ne-unkn0wn]

• Enable 6 second block times for people chain #308

[brenzi]

• [encointer] introduce collator selection and send fees to authors instead of treasury #270

[eskimor]

What is the current plan for this release. Like with what node release do we want to cut this one?

For Coretime we need node 1.14 for Polkadot (the one after the one that is currently being cut). Do we want to wait for that or do we want to cut a release earlier already?

[joepetrowski]

• Fellowship-core: add fast promote paritytech/polkadot-sdk#4877 & Fast Fellowship Promote Tracks #356
• Update to SDK 1.13 #322 (at least)
• Remove Identity from Polkadot Relay #415
• [Assets] Call implementation for transfer_all paritytech/polkadot-sdk#4527 (merged into SDK but not pinned release, can do 1.3 without it)

[the-right-joyce]

• Include migration for all existing parachains to coretime

[bkchr]

• Add Integritee's lease to the coretime migration

@the-right-joyce is there more information on this?

[joepetrowski]

^I think we should just change it to, "Include migration for all existing parachains to coretime"

[SBalaguer]

• Add Integritee's lease to the coretime migration

@the-right-joyce is there more information on this?

@bkchr the biggest problem is that the current auction model allows for chains to have 'future' leases (a.k.a. a lease that starts sometime in the future) and the new coretime model does not (a.k.a. teams can't have a core that starts in the future, it needs to start now and for a given amount of time). Therefore we need to find a solution to make these two things work.

If the migration takes a snapshot of the system at a given point in time, it will find:

• Parachains that currently hold a slot for a given amount of time.
• Parachains that don't have a slot currently and have one starting sometime in the future. This future can be anything from the immediate next lease period, up to 7 lease periods in the future (~1y).

What I would suggest then, is to compromise on giving a core to every team that either currently has a slot now, or that has a slot starting in the upcoming lease period. From my point of view, migrating this way would make it more compatible with the current auctions happening on Polkadot. This would mean giving 'free coretime' to the teams that start in the upcoming lease period (which with current estimates of launch is ~1mo).

Example: Integritee
Integritee has been a parachain on Polkadot since August 2022 when they won auction #23, which gave them a slot that expired on LP17. Unfortunately, this team didn't manage to secure an auction that would allow them to have a slot for LP17, yet they did win auction 69 that granted them a lease for LP18-24.

If the migration of coretime happens anytime during LP17 (as it's expected) and it only considers teams holding a lease, then Integritee would be left without a core. However, if we pursue a migration as I'm suggesting by which every team that has a slot now, or has one starting on LP18 gets a core, then Integritee would be having a core.

Open Questions
The biggest item to discuss potentially on this is load (i.e.: having more cores allocated in the future than the current amount of slots). I don't see this as a potentially big issue as the new teams that win an auction in the current set of auctions would replace those that don't manage to extend their lease, but might be worth it to double-check the numbers.

[eskimor]

• Enable Coretime on the relay chain

[bkchr]

@bkchr the biggest problem is that the current auction model allows for chains to have 'future' leases (a.k.a. a lease that starts sometime in the future) and the new coretime model does not (a.k.a. teams can't have a core that starts in the future, it needs to start now and for a given amount of time). Therefore we need to find a solution to make these two things work.

I would have thought we do the same as on Kusama? Everyone that hasn't an active lease, gets the lease returned and the locked funds are free. They are then able to buy the core on the open market.

[brenzi]

@bkchr I'm obviously biased here, but Integritee has won an auction at a certain price for a range of lease periods. What you suggest is breaking this "contract", leaving Integritee worse off (just to avoid technical extra work by the fellowship for the migration). Kusama had no similar case AFAIK.

Let me just suggest the most simple possible solution: Grant Integritee a few weeks of coretime ahead of their official lease LP18 and save a lot of hassle (migrate as if it was active in LP17). With all the usual delays to be expected, this will make very little difference for anyone. Integritee's DOT are locked already anyway.

[eskimor]

@brenzi I am looking into it, but to explain the reasoning: The original assumption was, that if a lease has not yet started, then we are also not causing any liveness issues, so refunding and going directly with Coretime should be acceptable and seemed like the fairest solution at the time. (E.g. otherwise people could buy part time leases on purpose to get free coretime.) Also we might end up with significantly more cores than what we planned to support.

[seadanda]

• Enable Coretime on Polkadot Relay #401
• Add the Polkadot Coretime runtime #410

[eskimor]

• Run benchmarks
• Final tests (with finalized weights)

[skunert]

This should go in too: #423

[seadanda]

Last bits before triggering the release:

• Coretime Chain: mitigate behaviour with many assignments on one core #434
• Proper handling for legacy parachain leases with gaps in coretime migration #426
• Fresh weights #433
• [Coretime] Always include UnpaidExecution, not just when revenue is > 0 paritytech/polkadot-sdk#5369 bump when released to crates

[olanod]

It would be nice to get this small Kusama addition #430

[joepetrowski]

It would be nice to get this small Kusama addition #430

It was merged so it is in.