xcm-emulator: advance relay block number by relay_blocks_per_para_block

[sigurpol]

After AuraDigestProvider was introduced, emulated integration tests for parachains with slot_duration != relay_slot_duration (e.g. 12s Polkadot/Kusama chains) panic because FixedVelocityConsensusHook derives a parachain slot that doesn't match CurrentSlot.

Fix by advancing the relay block number by slot_duration / RELAY_CHAIN_SLOT_DURATION_MILLIS per parachain block (instead of always +1), and computing the aura digest slot inline using both durations.
This removes the DigestProvider associated type from the Parachain trait and the AuraDigestProvider struct — the emulator now handles the digest automatically.

Downstream users must remove DigestProvider: AuraDigestProvider, from their decl_test_parachains! invocations.

[sigurpol]

/cmd prdoc --audience runtime_dev --bump patch

[sigurpol]

This is needed to unlock runtime 2.1.0 PR where all integration emulated tests are currently failing see polkadot-fellows/runtimes#1065 (comment)

I've locally patched the 2.1.0 PR to contain this fix and integration emulated tests pass now.

[skunert]

Hey, thanks for looking into this.

Your fix should work. However thought about it a bit and propose to use this: 7f240f1

I would consider it more in line with our logic in the dev mode.

[sigurpol]

Your fix should work. However thought about it a bit and propose to use this:

let me cherry-pick that and run tests in the runtime with your fix. Keep you posted (and thx)

[sigurpol]

Hey, thanks for looking into this.

Your fix should work. However thought about it a bit and propose to use this: 7f240f1

I would consider it more in line with our logic in the dev mode.

@skunert thanks for the reply. I went for your approach and tested in the runtime.
With my original commit - no changes were needed in the runtime beside relying on the new xcm-emulator pallet.

With your neater approach, I need to replace in the test AuraDigestProvider with an ad-hoc one like below:

pub struct SlotAdjustedDigestProvider<const PARA_SLOT_MS: u64>;

impl<const PARA_SLOT_MS: u64> Convert<(u32, u32), Digest>
	for SlotAdjustedDigestProvider<PARA_SLOT_MS>
{
	fn convert((_block_number, relay_block_number): (u32, u32)) -> Digest {
		let slot: Slot =
			(relay_block_number as u64 * RELAY_CHAIN_SLOT_DURATION_MILLIS / PARA_SLOT_MS).into();
		let mut digest = Digest::default();
		digest.logs.push(DigestItem::PreRuntime(AURA_ENGINE_ID, slot.encode()));
		digest
	}
}

which is perfectly fine by me as well. Wdyt?
With your SDK fix + test using AuraDigestProvider as digest provider:

• relay_block_number = 3 (first para block: initial 1 + 2)
• AuraDigestProvider sets digest slot = 3 (it uses relay_block_number
  directly)
• on_initialize reads digest → CurrentSlot = 3
• timestamp = 3 * 6000 = 18000
• pallet_aura::OnTimestampSet asserts: timestamp / slot_duration = 18000 / 12000 = 1
• 1 ≠ 3 → panic

They diverge because AuraDigestProvider puts the raw relay block number in the digest, but the timestamp now uses RELAY_CHAIN_SLOT_DURATION_MILLIS (6000) instead of slot_duration (12000).

In the SDK, this works because the SDK's test chains have slot_duration = 6000. In the runtime repo, Polkadot/Kusama parachains have slot_duration = 12000, so we need a DigestProvider that divides accordingly: slot = relay_block_number * 6000 / 12000. Does it make sense?

[skunert]

Hey, thanks for looking into this.
Your fix should work. However thought about it a bit and propose to use this: 7f240f1
I would consider it more in line with our logic in the dev mode.

@skunert thanks for the reply. I went for your approach and tested in the runtime. With my original commit - no changes were needed in the runtime beside relying on the new xcm-emulator pallet.

With your neater approach, I need to replace in the test AuraDigestProvider with an ad-hoc one like below:

pub struct SlotAdjustedDigestProvider<const PARA_SLOT_MS: u64>;

impl<const PARA_SLOT_MS: u64> Convert<(u32, u32), Digest>
	for SlotAdjustedDigestProvider<PARA_SLOT_MS>
{
	fn convert((_block_number, relay_block_number): (u32, u32)) -> Digest {
		let slot: Slot =
			(relay_block_number as u64 * RELAY_CHAIN_SLOT_DURATION_MILLIS / PARA_SLOT_MS).into();
		let mut digest = Digest::default();
		digest.logs.push(DigestItem::PreRuntime(AURA_ENGINE_ID, slot.encode()));
		digest
	}
}

which is perfectly fine by me as well. Wdyt? With your SDK fix + test using AuraDigestProvider as digest provider:

* relay_block_number = 3 (first para block: initial 1 + 2)

* AuraDigestProvider sets digest slot = 3 (it uses relay_block_number
  directly)

* on_initialize reads digest → CurrentSlot = 3

* timestamp = 3 * 6000 = 18000

* pallet_aura::OnTimestampSet asserts: timestamp / slot_duration = 18000 / 12000 = 1

* 1 ≠ 3 → panic

They diverge because AuraDigestProvider puts the raw relay block number in the digest, but the timestamp now uses RELAY_CHAIN_SLOT_DURATION_MILLIS (6000) instead of slot_duration (12000).

In the SDK, this works because the SDK's test chains have slot_duration = 6000. In the runtime repo, Polkadot/Kusama parachains have slot_duration = 12000, so we need a DigestProvider that divides accordingly: slot = relay_block_number * 6000 / 12000. Does it make sense?

Yes, fine by me. You could make the default AuraDigestProvider do this. Then it would be fixed automatically.

Maybe I shouldn't even have introduced the DigestProvider but directly add the digest in xcm-emulator, in the end we have both slot durations available there already. But fine for now.

[sigurpol]

Maybe I shouldn't even have introduced the DigestProvider but directly add the digest in xcm-emulator, in the end we have both slot durations available there already. But fine for now.

Good point @skunert - removed here 8c05dc2

[ggwpez]

(approving to unblock 2.1.0)

[paritytech-release-backport-bot]

Successfully created backport PR for stable2512:

• [stable2512] Backport #11031 #11036