The crate interfaces and structures are experimental and may be subject to changes.
Nevertheless, the strategy here is to incrementally drain the main PR by upstreaming smaller components in order to make the overall protocol inclusion and analysis more manageable.
The structures and functions were found to satisfy the requirements of the protocol.
A more in depth analysis of the structures obviously requires to dig into the client and frame pallets in the main PR.
Because minor changes may be required, IMO is useful to keep this stuff behind an experimental feature flag, mostly to explicitly assert that the this is still a WiP.
This crate requires to enable bandersnatch-experimental feature in some of its dependencies.
This feature ends up being transitively enabled in:
sp-consensus-sassafras → sp-application-crypto → sp-io → sp-keystore
Thus the bandersnatch experimental api is exposed in the Keystore trait.
Follows that we require to expose these functions implementation in the client keystore as well.
At this stage, by default, we don't want this.
IMO is better to keep Sassafras crates (and thus bandersnatch feature) out of workspace default build and optionally enable them via the sassafras-experimental feature.
I haven't found a better technique, but IMO makes sense to keep sassafras behind the sassafras-experimental until is not a bit more mature.
This PR introduces a new crate with the primitives required by Sassafras consensus.
Quoting the crate
README:Nevertheless, the strategy here is to incrementally drain the main PR by upstreaming smaller components in order to make the overall protocol inclusion and analysis more manageable.
The structures and functions were found to satisfy the requirements of the protocol.
A more in depth analysis of the structures obviously requires to dig into the client and frame pallets in the main PR.
Because minor changes may be required, IMO is useful to keep this stuff behind an experimental feature flag, mostly to explicitly assert that the this is still a WiP.
This crate requires to enable
bandersnatch-experimentalfeature in some of its dependencies. This feature ends up being transitively enabled in: sp-consensus-sassafras → sp-application-crypto → sp-io → sp-keystore Thus the bandersnatch experimental api is exposed in theKeystoretrait. Follows that we require to expose these functions implementation in the client keystore as well.At this stage, by default, we don't want this. IMO is better to keep Sassafras crates (and thus bandersnatch feature) out of workspace default build and optionally enable them via the
sassafras-experimentalfeature.I haven't found a better technique, but IMO makes sense to keep sassafras behind the
sassafras-experimentaluntil is not a bit more mature.Step towards: https://github.com/paritytech/polkadot-sdk/issues/41
Extracted from: https://github.com/paritytech/substrate/pull/11879