"Slot number mismatch" after runtime upgrade

Question

I'm upgrading a Parachain from Polkadot v1.6 to v1.8 (in one go). I followed all the instructions provided on the Polkadot wiki and I'm now applying the changes in step 3. I start a local network (with the async backing configurations for Rococo):

1. start network with latest binary Parachain node and runtime (v1.8).
2. do runtime upgrade to runtime wasm blob of live running chain (v1.6).
3. do runtime upgrade to latest version of runtime wasm blob (v1.8).

After step 3 I get the error: slot number mismatch:

assertion `left == right` failed: slot number mismatch
  left: Slot(142568897)
  right: Slot(285137795)

As you can see the para_slot_from_relay is twice as big than the slot obtained from here. The slot duration of both relay and para is set to 6000. I don't understand why it is failing.

Answer 1

The problem is the following change in the guide:

pub const MILLISECS_PER_BLOCK: u64 = 6000;

Before your parachain was running with 12s per block and after the runtime upgrade with 6s per block. However, the node side needs to know this time to calculate the correct slot to find out the correct slot author.

As you can see the para_slot_from_relay is twice as big than the slot obtained from

Given what I said above this also makes sense. The node divides the time by 12s to get the slot and the runtime by 6s to get the slot. So, the node will give you a 2 times smaller slot as what the runtime calculates.

Now, to the solution. I assume you are running your own node software? Otherwise the fixes should be in the polkadot-parachains binary from 1.8/1.9. You need these fixes. So, switch to the lookahead collator and ensure that the slot_duration is fetched inside of the closure to always fetch the correct value from on chain. Another solution is also to just restart the collator after the runtime has upgraded.

Answer 2

It looks like there is a mismatch between node and runtime, node produces slots at 12s clip and runtime expects them at 6s rate.

Are you getting this just once on upgrade or continuously, if it is just once it can be safely ignored.

If you can point us to your parachain codebase after the migration we can have a look to try to ping point the mismatch.

Answer 3

So I haven't been able to unravel the error but I have been able to upgrade the Parachain. I needed the collator to run on the new node binary (Polkadot 1.8 in stead of v1.6) with the older runtime. I did this with the following steps:

1. Start a local network with the latest release of Parachain and rococo-local on v1.8:

pop up parachain --f ./rococo-local-config.toml -r v1.8.0 -v (using pop cli)

1. Build new release of Parachain
2. Stop collator killall <parachain binary> (local network will keep running)
3. Copy command with which the Parachain collator was launched by Zombienet and use it to launch the new collator on new release. In this case it will launch the newly built node with async backing activated (Polkadot v1.8) and have it use previously generated chainspecs, effectively allowing it to take over running the network with the older runtime version.
4. Do the runtime upgrade.

If there are better ways to do this, I'm very interested!