Introduce config param for state version instead using a StateVersion::V0 for extrinsic root derivation

[vedhavyas]

Description

Please include a summary of the changes and the related issue. Please also include relevant motivation and context,
including:

• What does this PR do?
  Adds Extrinsinc root state version as config parameter so that users can pick V0/V1 depending on the use case.
• Why are these changes needed?
  Currently extrinsic root is derived using StateVersion::V0. In order to generate the extrinsic root, we would need to have access to full extrinsic data. We have a use case where, domains extrinsic root need to be derived on consensus runtime and passing all the extrinsic data through Fraud proof will exceed block limit. We are planning to use StateVersion::V1 so that we can just use extrinsic hashes if the extrinsic data is more than 32 bytes.
• How were these changes implemented and what do they affect?
  Config parameter for ExtrinsicRootStateVersion can be passed through runtime and I have set it to StateVersion::V0 so this should not change the extrinsic root derivation for existing projects.

Checklist

• My PR includes a detailed description as outlined in the "Description" section above
• My PR follows the labeling requirements of this project (at minimum one label for T
  required)
• I have made corresponding changes to the documentation (if applicable)
• I have added tests that prove my fix is effective or that my feature works (if applicable)

[vedhavyas]

Hey folks,

I could use some help in fixing the failing test and I'm not sure if this is related to my changes. Not to say the cliched thing but the following cargo build --locked --profile testnet -p polkadot-test-malus --bin malus --bin polkadot-prepare-worker --bin polkadot-execute-worker succefully builds on my mac and my rust version is rustc 1.71.0-nightly same. as the one used in the gitlab ci.

Thanks!

[cheme]

Hey folks,

I could use some help in fixing the failing test and I'm not sure if this is related to my changes. Not to say the cliched thing but the following cargo build --locked --profile testnet -p polkadot-test-malus --bin malus --bin polkadot-prepare-worker --bin polkadot-execute-worker succefully builds on my mac and my rust version is rustc 1.71.0-nightly same. as the one used in the gitlab ci.

Thanks!

Will be reviewing the pr next week, but at first glance the CI error does not look related (also not a required one), probably no need to check before reviews (not a 'required' test).

[bkchr]

Yeah. Generally I think this is fine. It will break everybodys runtime, but sadly we can not do better right know. However, I would re-export StarteVersion from frame_system to not require people to pull in sp_core.

[cheme]

No idea yet if doable or fine, but would it be suitable to put this state version as part of RuntimeVersion (type Version) as a new field or a specific api version (as a specific api version, could default to 0 when missing so there would be no need to change existing pallets).

[vedhavyas]

Apologies for the delay. The PR should be updated per review suggestions @bkchr

[vedhavyas]

@bkchr Bump

[vedhavyas]

No idea yet if doable or fine, but would it be suitable to put this state version as part of RuntimeVersion (type Version) as a new field or a specific api version (as a specific api version, could default to 0 when missing so there would be no need to change existing pallets).

@cheme you are correct, adding an extrinsic_state_version field to RuntimeVersion was indeed a good idea and feels more correct to me. I have opened another PR with this approach. I can close this PR if team agrees with the changing RuntimeVersion approach instead of adding a config parameter.