Update substrate #370
Update substrate #370
Conversation
| @@ -195,6 +195,7 @@ pub fn new_partial( | |||
|
|
|||
| let (grandpa_block_import, grandpa_link) = grandpa::block_import( | |||
| client.clone(), | |||
| #[allow(clippy::redundant_clone)] | |||
There was a problem hiding this comment.
There was a problem hiding this comment.
Well done for getting through this, it looks like it was an absolute nightmare!
I certainly don't see any red flags, but i really don't understand the weights stuff, which looks like it has changed significantly, nor do i understand the substrate benchmarks. I'd like to take some time to get my head around it, but thats not gonna happen before i am away camping, so i defer to @jakehemmerle
| use subxt::{ | ||
| ext::{ | ||
| sp_core::{ | ||
| sr25519::{self, Pair}, |
There was a problem hiding this comment.
i don't understand whats going on here. we were getting sr25519, Pair and Bytes from sp_core and now we are getting them from subxt::ext::sp_core. Which looks to me like it is a re-export of the exact same version of sp_core
| sp-core ={ package="sp-core", git="https://github.com/paritytech/substrate", branch="polkadot-v0.9.31" } | ||
| subxt ={ package="subxt", git="https://github.com/paritytech/subxt.git", tag="v0.29.0" } | ||
| parity-scale-codec="3.4.0" | ||
| sp-core ={ version="21.0.0", default-features=false } |
There was a problem hiding this comment.
I am sure there is a good reason - but why does server and kvdb use a newer version of sp-core than entropy, entropy-shared and entropy-constraints?
There was a problem hiding this comment.
good find, tbh they are not used, have removed, I had to change sp-core to match the subxt version to save on a lot......a lot of errors lol
tbh most of it is auto generate, looks like they added some more precise calculation |
I'm not aware of the context of this code enough to immediately understand what changes to the devnet automations are needed. Can you list them out for me or maybe we touch base synchronously soon? |
There was a problem hiding this comment.
Nice PR, nothing really that I'd change.
Regarding the AccountId32 stuff, you might have seen this subxt CHANGELOG entry explaining is the subxt::utils::AccountId32 type. After further looking, it impls From<sp_core::crypto::AccountId32> and From<sp_runtime::AccountId32> (when using the substrate-compat feature which is enabled by default)
If that's not new information, then this is good to go. If it is, then there might be places we're using subxt::utils::AccountId32 where we could just be using sp_runtime::AccountId32 with an .into() or something.
ya, this PR is big enough as it is and there are things I wanna get done before our retreat, imma go with let's merge it and then put up a refactor card and come back to it with fresh eyes |
updates substrate, subxt as well as others
Notes
AccountId32 -> requiers conversions between the two, subxt no longer accepts sp_core, and sp_core is needed in PartyId because it implements hash while subxt does not
@vitropy this changes the devnet launch scripts slightly, no rush just tagging so you are aware (we talked offline about this)