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

feat: upgrade to Polkadot v0.9.29 #416

Merged
merged 25 commits into from
Oct 6, 2022
Merged

Conversation

wischli
Copy link
Contributor

@wischli wischli commented Sep 21, 2022

fixes KILTProtocol/ticket#2200

  • Upgrades to latest Polkadot v0.9.29
  • Updates weights to v1.5 (a one dimensional struct instead of u64), supersedes feat: add weights v2 #403
  • Changes execution order of pallets in construct_runtime! macro because our former trait AllPalletsReversedWithSystemFirst is now deprecated. To the best of my knowledge, only the staking related pallets have a dependent order which I reversed to replicate the current behaviour. Thanks to the pallet indices, there should be no side effects.

Note worthy Substrate PRs

This removes the --state-cache parameter and adds the new --trie-cache-size cli parameter. Parachain operators should now be able to just drop --state-cache 0 and are not required to add the --trie-cache-size as the cache is enabled by default.

Checklist:

  • I have verified that the code works
    • No panics! (checked arithmetic ops, no indexing array[3] use get(3), ...)
  • I have verified that the code is easy to understand
    • If not, I have left a well-balanced amount of inline comments
  • I have left the code in a better state
  • I have documented the changes (where applicable)

@wischli wischli self-assigned this Sep 21, 2022
Comment on lines 920 to 924
AuraExt: cumulus_pallet_aura_ext = 24,
Aura: pallet_aura = 23,
Session: pallet_session = 22,
ParachainStaking: parachain_staking = 21,
Authorship: pallet_authorship::{Pallet, Call, Storage} = 20,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Weirdly, when running benchmarks, an error is thrown with this config under AllPalletsWithSystem:
Thread 'main' panicked at 'AuRa authorities empty, maybe wrong order in `construct_runtime!`?', /home/willi/.cargo/git/checkouts/cumulus-59522f43471fa161/35dd14f/pallets/aura-ext/src/lib.rs:96

When reverting the order (:= REV = Authorship -> Staking -> Session -> Aura -> AuraExt), the benchmarks work. That does not make sense though, as we would then run everything in reverse order compared to our current execution. Moreover, there was a user on Discord having problems with REV and AllPalletsWithSystem. The issue there was that session keys were not propagated in --dev environment.

Need to investigate locally...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After intensive testing, I can say that Aura -> Session -> Staking -> Authorship is fine. However, AuraExt needs to be after Aura because the latter sets the authorities which are queried by AuraExt. Should hopefully be fixed now, see 134d428

@ntn-x2
Copy link
Member

ntn-x2 commented Oct 4, 2022

@wischli maybe we can wait to see if paritytech/substrate#12351 gets backported into 0.9.29, so that we can push the fix with the next runtime upgrade.

@ntn-x2
Copy link
Member

ntn-x2 commented Oct 4, 2022

@wischli the fix has been backported now. So we should update dependencies and test that the new origin fix works.

@wischli wischli added the next release This PR is required for the next release. label Oct 5, 2022
@wischli wischli added this to the 1.7.5 milestone Oct 5, 2022
@wischli wischli changed the base branch from develop to master October 5, 2022 08:54
@wischli
Copy link
Contributor Author

wischli commented Oct 5, 2022

@wischli the fix has been backported now. So we should update dependencies and test that the new origin fix works.

Should be fixed in 68056c6

@wischli wischli changed the base branch from master to develop October 5, 2022 08:58
Copy link
Member

@ntn-x2 ntn-x2 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had few comments that I just noted were pending.

pallets/parachain-staking/src/lib.rs Show resolved Hide resolved
runtimes/common/src/constants.rs Show resolved Hide resolved
runtimes/common/src/xcm_config.rs Outdated Show resolved Hide resolved
runtimes/peregrine/src/lib.rs Show resolved Hide resolved
runtimes/peregrine/src/lib.rs Show resolved Hide resolved
rpc/did/runtime-api/Cargo.toml Show resolved Hide resolved
runtimes/spiritnet/src/lib.rs Show resolved Hide resolved
runtimes/spiritnet/src/lib.rs Show resolved Hide resolved
support/src/relay.rs Outdated Show resolved Hide resolved
@@ -197,8 +196,8 @@ impl pallet_transaction_payment::Config for Runtime {
}

parameter_types! {
pub const ReservedXcmpWeight: Weight = constants::MAXIMUM_BLOCK_WEIGHT / 4;
pub const ReservedDmpWeight: Weight = constants::MAXIMUM_BLOCK_WEIGHT / 4;
pub const ReservedXcmpWeight: Weight = constants::MAXIMUM_BLOCK_WEIGHT.saturating_div(4);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we not saturate here but fail since these are constants?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could but I wanted to stay in sync with Parity, see Cumulus

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've seen few PRs where people have pointed out that compilation time should rather panic than silently do something like saturating. Can't find one easily now though. I personally think it would be better not to saturate.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overflow doesn't panic tho do they? And these are not "consts" in a sense of rust "consts". This gets expanded to a function that returns constants::MAXIMUM_BLOCK_WEIGHT / 4. So the compiler might optimize that, but he doesn't need to.

The only overflow that can happen while using div is when dividing with -1 anyways and that's not possible since this is a u64. So I actually might also remove the saturating_div.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose the reason for the saturated div here is that the compiler does not accept just dividing, e.g. it throws cannot call non-const operator in constants for constants::MAXIMUM_BLOCK_WEIGHT / 4.

I am unhappy with panicking here. But if you prefer, we can do that.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

aha interesting! So it's actually a const function. Didn't look close enough then.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is a constant hence using a simple / should be enough, as any invalid case would be caught at compilation time (when compiled in release mode, any overflow or division by zero is also caught). A saturating division would, potentially, saturate without giving any notice. I don't see why we would want to replace a simple division with a saturating one. Or am I missing something else?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also don't see a strong case for the saturating_div here.

Copy link
Contributor Author

@wischli wischli Oct 5, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reposting from above:

[... the compiler] throws cannot call non-const operator in constants for constants::MAXIMUM_BLOCK_WEIGHT / 4.

The issue is that division is currently not implemented for Weight, on purpose.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh sorry. Yes I totally didn't get that 🙈! Weight is not a u64 any more and they don't implement that for const. But saturating_div

I was blind but now i can see!

Comment on lines 122 to 125
#[cfg(not(feature = "disable-runtime-api"))]
apis: RUNTIME_API_VERSIONS,
#[cfg(feature = "disable-runtime-api")]
apis: sp_version::create_apis_vec![[]],
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

interesting. Do you know why this was added?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I honestly did not think beyond "yeah maybe we want to be able to disable the runtime API for some testing at some point" since this is part of all relaychain runtimes. However, that has been the case for a long time which I overlooked. So I am perfectly fine with reverting these changes.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@weichweich Should I remove it? Else I would like to merge.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's standalone so keep it in. We might find a use for it someday. 😂

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Its also in the other runtimes 🙈

Copy link
Contributor

@weichweich weichweich Oct 6, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In that case i wouldn't want something in our spiritnet runtime if we don't have a use case for it. 😰

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed it for all runtimes in 2560d7a

Copy link
Contributor

@weichweich weichweich left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

The saturating thing should be resolved so that everyone is happy and I would like to know why the disable-runtime-api feature was added to the standalone.

@wischli wischli enabled auto-merge (squash) October 6, 2022 08:19
@wischli wischli merged commit 93fb3ab into develop Oct 6, 2022
@wischli wischli deleted the wf-2020-polkadot-v0.9.29 branch October 6, 2022 08:29
@wischli wischli mentioned this pull request Oct 7, 2022
6 tasks
wischli added a commit that referenced this pull request Oct 17, 2022
* chore: bump deps

* wip: migrate pallets and runtimes

* chore: bump more versions

* wip: fix clients

* fix: runtime tomls

* style: ignore clippy in default weights

* fix: client pt2

* fix: runtimes, clippy

* feat: switch pallet execution order

* tests: merge delegation from wf-2168-polkadot-v0.9.28

* chore: bump deps to polkadot-v0.9.29

* fix: weights 1.5 for new stuff

* fix: cp mistake

* fix: update weight templates

* fix: pallet order instruction

* chore: bump deps

* feat: add backported batch fix

* refactor: same serde versions

* fix: UnitWeightCost type

* fix: CI regex for versions

* fix: remove disable-runtime-api feat
@wischli wischli mentioned this pull request Oct 18, 2022
5 tasks
b-yap added a commit to pendulum-chain/pendulum that referenced this pull request Jun 12, 2023
The order of the pallets during runtime construction has changed.
see KILTprotocol/kilt-node#416
b-yap added a commit to pendulum-chain/pendulum that referenced this pull request Jun 12, 2023
The order of the pallets during runtime construction has changed.
see KILTprotocol/kilt-node#416
b-yap added a commit to pendulum-chain/pendulum that referenced this pull request Jul 5, 2023
The order of the pallets during runtime construction has changed.
see KILTprotocol/kilt-node#416
b-yap added a commit to pendulum-chain/pendulum that referenced this pull request Jul 6, 2023
The order of the pallets during runtime construction has changed.
see KILTprotocol/kilt-node#416
b-yap added a commit to pendulum-chain/pendulum that referenced this pull request Jul 6, 2023
The order of the pallets during runtime construction has changed.
see KILTprotocol/kilt-node#416
ebma pushed a commit to pendulum-chain/pendulum that referenced this pull request Jul 6, 2023
* first iteration: fixes the development-runtime package.

* fixed some errors in foucoco runtime. Not yet finished.

* new iteration, fixing `foucoco-runtime`

* set network to None

* fix foucoco runtime and update spacewalk tag

* bring back `FungiblesAdapter`

* fix amplitude-runtime

* fix pendulum-runtime

* fix node

* cleanup some test build errors

* add .lock

* fix test build issues

* fix test build issues of parachain-staking.
The order of the pallets during runtime construction has changed.
see KILTprotocol/kilt-node#416

* #242 (comment),
#242 (comment),
#242 (comment),
#242 (comment)

* partially fixed test integration test cases

* fixed test integration test cases

* remove extern crate core

* revert comment println

* tried to fix the benchmark, but to no avail.

* fix benchmark and added weights

* add cargo lock

* #242 (comment),
#242 (comment),

* change spec versions

* revert version
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
next release This PR is required for the next release.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants