-
Notifications
You must be signed in to change notification settings - Fork 15
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: state chain upgraded to substrate 2022-05 #1650
Conversation
Old substrate version: monthly-2021-09+1 New substrate version: monthly-2022-05 Main change: TypeInfo added to all storage types. See https://github.com/paritytech/substrate/releases for a full list of changes.
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.
Will let some other eyes go over this ofc.
engine/src/state_chain/client.rs
Outdated
state_chain_runtime::Call::from(extrinsic.clone()).encode(), | ||
)); | ||
let expected_hash = BlakeTwo256::hash_of(&unsigned_tx); | ||
let call = call.into(); |
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.
In the signed version above, you changed it so in the errors the call
variable is formatted as it is passed into the function. Instead of turning the call
into a state_chain_runtime::Call
(using the into first) and then formatting that. I like this change, but you also need to do the same thing here.
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.
We can't do it the same way here because we need the state_chain_runtime::Call
to calculate the expected_hash
. I agree it's better to be consistent though. I'll re-shuffle a bit.
Add AURA digest and change block execution order.
Note - runtime integration tests are currently failing - would like to merge recent changes from PR paritytech/substrate#1538 into develop and then merge develop back into this before fixing them. |
} | ||
{{~/each}} | ||
} | ||
{{#if (eq pallet "frame_system")}} |
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.
If you format the file in this way it will produce rust files with no valid format.
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.
Did you try it?
I merged this from core substrate - apparently there used to be a bug in the handlebars implementation that required pre/post-fixing ~
everywhere to handle newlines properly. This should no longer be required. Maybe we need to bump our version of handlebars?
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.
Do you mean the extra tab of indentation? I'll take a look.
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.
So the problem is the generated weights files will end up like the format in the hbs file. Back then when I created this I had to ensure that the file has a proper format that matches our fmt rules.
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 like format-on-save messed up the formatting. I've reverted it and fixed the formatting, should be good now.
This includes TypeInfo derivations for new types in auction resolver and backup triage.
frame_system::CheckEra::from(Era::Immortal), | ||
frame_system::CheckNonce::from(nonce), | ||
frame_system::CheckWeight::new(), | ||
state_chain_runtime::ChargeTransactionPayment::from(0), |
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.
What does this zero mean?
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.
It's the tip - normally this is used to increase transaction priority, but we ignore it in our runtime since there's no fee market, and we don't want anyone manipulating the execution order.
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.
(I'll add a comment)
engine/src/state_chain/client.rs
Outdated
state_chain_runtime::Call::from(extrinsic.clone()).encode(), | ||
)); | ||
let expected_hash = BlakeTwo256::hash_of(&unsigned_tx); | ||
let runtime_call = call.clone().into(); |
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.
You could inline this like you did above.
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.
Not sure how, I need it in two places, once to calculate the expected_hash
, then again to construct the extrinsic.
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.
Ah wait I think I made a mistake in the encoding, i need the hash of the extrinsic, not of the call.
See 762810b
Error reported in #1650 (comment) is actually due to another problem (#1658). I'll double check again in the morning, but I think this one is good to merge otherwise. Awesome stuff. |
Old substrate tag: monthly-2021-09+1
New substrate tag: monthly-2022-05
This latter tag has been recreated as
chainflip-2022-05
in our substrate fork, and the recent grandpa fix cherry-picked. Our grandpa fork has also been updated.The main changes to our code:
TypeInfo
added to all storage types.TypeInfo
can be derived alongsideEncode
andDecode
and is required for all types in storage. It allows auto-generated type metadata for front-end tools. See the scale-info docs for more details.MaxEncodedLen
has been added where it was easy to add / derive. See here and here for details onMaxEncodedLen
. The idea is that every storage item should have statically-determined maximium size. This implies that everywhere we store aVec
orBTreeSet
etc. we should convert this to theBounded*
equivalent. The reason for this, as far as I can tell, is to have deterministic worst-case performance bounds for benchmarking. It also allows derivation of theStorageInfo
trait, although not sure benefits this brings. Judging by this issue, it seems related to parachains. I considered adding this for our entire runtime to be out of scope for this PR, so for now I have annotated most pallets aswithout_storage_info
- however we may want to slowly move towards enforcingMaxEncodedLen
everywhere. I'll raise an issue to track this.construct_runtime
no longer need to list all the items that it exports (Call, Event, Storage..
).subxt
in the Cfe.Also one last note about
secp256k1
: there was a conflict because all parity crates, and web3 have updated their dependency to0.21
while our signing code still uses 0.20. I didn't want to dive too deep into this, so for now have settled on importing two versions of the crate to keep the changes here minimal.For a full list of substrate changes, see https://github.com/paritytech/substrate/releases.
types.json
up to date? Types.json is no more.