Customize-able ParacnainInherentDataProvider

[kianenigma]

Related to #855, to #5588, #82

As more functionality is scheduled to live in AH (and system chains like coretime), it is more and more likely that a parachain would want to regularly access the state that is still left in the relay chain, such as:

• session, validators
• number of cores
• List of active paras

Some means already exist to achieve this:

1. Providing state proofs through a transaction. The parachain runtime has access to the parent relay state root and can accept proofs. These can come via normal signed transactions. Somewhat better, validators can submit this "automatically" as a custom inherent.

polkadot-sdk/cumulus/pallets/parachain-system/src/lib.rs

Lines 821 to 828 in 49fb2b1

	/// The state proof for the last relay parent block.
	///
	/// This field is meant to be updated each block with the validation data inherent. Therefore,
	/// before processing of the inherent, e.g. in `on_initialize` this data may be stale.
	///
	/// This data is also absent from the genesis.
	#[pallet::storage]
	pub type RelayStateProof<T: Config> = StorageValue<_, sp_trie::StorageProof>;

This proof is also passed to all other pallets via this hook, even though it is already public:

polkadot-sdk/cumulus/pallets/parachain-system/src/lib.rs

Lines 610 to 612 in 49fb2b1

	// Update the desired maximum capacity according to the consensus hook.
	let (consensus_hook_weight, capacity) =
	T::ConsensusHook::on_state_proof(&relay_state_proof);

2. Cumulus and parachain_system already enforce the presence of ParachainInherent in the runtime.

polkadot-sdk/cumulus/pallets/parachain-system/src/lib.rs

Lines 590 to 595 in 49fb2b1

	let ParachainInherentData {
	validation_data: vfp,
	relay_chain_state,
	downward_messages,
	horizontal_messages,
	} = data;

Moreover, this method is provided to read custom keys from the provided proof.

polkadot-sdk/cumulus/pallets/parachain-system/src/relay_state_snapshot.rs

Lines 352 to 361 in 49fb2b1

	/// Read an optional entry given by the key and try to decode it.
	///
	/// Returns `Err` in case the backend can't return the value under the specific key (likely due
	/// to a malformed proof) or if the value couldn't be decoded.
	pub fn read_optional_entry<T>(&self, key: &[u8]) -> Result<Option<T>, Error>
	where
	T: Decode,
	{
	read_optional_entry(&self.trie_backend, key).map_err(Error::ReadOptionalEntry)
	}

Yet, the missing piece here is that the ParachainInherentDataProvider has no easy means to be configured.

polkadot-sdk/cumulus/client/parachain-inherent/src/lib.rs

Lines 35 to 39 in 49fb2b1

	async fn collect_relay_storage_proof(
	relay_chain_interface: &impl RelayChainInterface,
	para_id: ParaId,
	relay_parent: PHash,
	) -> Option<sp_state_machine::StorageProof> {

My suggestion here is to make this a first-class functionality of Cumulus: Both in the old-school node, and in omni-node, a team should be able to easily alter the list of keys that are included in the inherent, and consequently be able to access them in the runtime.

Ideally, this customization would also allow for a frequency to be set: some relay chain keys need to be part of the ParachainInherent proof at all blocks, some every hour, and so on.

Even if this feature is not needed, we can manually implement for AH/coretime etc. if needed, and I tried to document the components involved above.

Open question: At the moment, looking at the coretime <> RC interactions, a lot of what I proposed above seemingly is happening over XCM Transacts (1). I find having the option to freely and reliably read the relay chain state via inherents better, but maybe they are more or less the same under the hood.

[bkchr]

This is basically a simple version of #82

But a reasonable way to take because an implementation should be fairly simple. Have a runtime api that returns the keys you are interested in and then add these keys to the inherent. Should be doable in one or two days.