What inherent checking does the `Verifier` actually do?

[JoshOrndorff]

My question is about this code

cumulus/consensus/src/import_queue.rs

Lines 61 to 82 in 464e54a

	let inherent_data = self
	.inherent_data_providers
	.create_inherent_data()
	.map_err(|e| e.into_string())?;
	let block = Block::new(header.clone(), inner_body);
	let inherent_res = self
	.client
	.runtime_api()
	.check_inherents(
	&BlockId::Hash(*header.parent_hash()),
	block.clone(),
	inherent_data,
	)
	.map_err(|e| format!("{:?}", e))?;
	if !inherent_res.ok() {
	inherent_res.into_errors().try_for_each(|(i, e)| {
	Err(self.inherent_data_providers.error_to_string(&i, &e))
	})?;
	}

The Verifier requires inherent data providers. When importing a block it seems to reconstruct the inherent data and confirm that it matches the block? Is that right?

Even if my explanation is right, I'm still confused. The rococo collator inserts a timestamp, but the timestamp inherent data provider is not even part of what is passed to the Verifier. We're running into a similar confusion about our author inherent that includes the address of the block author.

So I guess my questions are:

1. Can you give an example of an inherent that would make sense to check in the Verifier?
2. Can we remove that requirement for the Verifier to take inherent data providers?

[bkchr]

The runtime decides if an inherent should be checked. You can just skip checking your author inherent. Why isn't that passed as digest to the runtime?

In general, I need to rework the inherent handling in the next time and make it a little bit easier to use (hopefully).

[JoshOrndorff]

Okay, I understand. Previously I was confused about how the ProvideInherent trait worked. I've made paritytech/substrate#7941 to try to clear it up.

Why isn't that passed as digest to the runtime?

You mean a PreRuntime digest like in Aura or Babe? We will probably do that when cumulus supports it. I might take a look in that direction next.