Slot request for Zeitgeist

[sea212]

You completed the Parachain Tutorials for your parachain and tested locally?

• Yes, we have successfully tested our chain on rococo-local.

Team Name

Zeitgeist

Parachain Name

Zeitgeist

ParaID

2101

Is this for a short or long term slot?

Long-term: we have a matching paraID in use on Polkadot or Kusama.

Upload your Genesis Head (genesis state)

battery_station_rococo_genesis_state.zip

Upload your Validation Code (genesis runtime Wasm)

battery_station_rococo_genesis_wasm.zip

(Optional) Upload your Chain Specification

battery_station_rococo.zip

Anything else we should know?

We want to test XCM integrations with other parachains.

Register your Rococo parachain details for polkadot-js/apps

• Polkadot-js Apps UI PR completed
  • Available here: Update Zeitgeist entry for Rococo polkadot-js/apps#8231

[al3mart]

registering parathread

[al3mart]

I have assigned your para 30 slots, as the long-term paras are capped atm, we are performing a runtime upgrade shortly to bump this value. This should get you going until the new runtime is enacted.

[sea212]

@al3mart The genesis state and gensis wasm provided here were tested on rococo-local v0.9.26 and v0.9.30 and the parachain successfully produced blocks. However, on the live network it cannot produce the first block. What could be the reason for that?

[al3mart]

Looks at this line
Oct 29 17:36:25 battery-station-xcm-test-servers zeitgeist[476963]: Thread 'tokio-runtime-worker' panicked at 'Invalid messaging state in relay chain state proof: DmqMqcHead(Proof)', /home/sea212/.cargo/git/checkouts/cumulus-a92b011ec2b4c70b/82c9c1f/pallets/parachain-system/src/lib.rs:352 It looks like there is some mismatch between the mqcHeads state. The storage on the relay side seems clean, as we are doing a fresh onboarding for this para.
Could you check if on your side you might have populated some storage related to this ?

[al3mart]

Other option, but I guess you have already checked this. Are the wasm and state submitted in the issue the correct ones ? 🤔

[Chralt98]

Other option, but I guess you have already checked this. Are the wasm and state submitted in the issue the correct ones ?

Thank you so much. We checked them and they are correct.

Apart from that:

When I query the rococo relay chain for storage -> dmp -> downwardMessageQueueHeads(u32): H256 for parachain id 2101 (or 2050) I get no hash back. That's what you meant above with The storage on the relay side seems clean, as we are doing a fresh onboarding for this para., right? Maybe the call sudo_queue_downward_xcm is required? Or where does the setup of the downward message queue head happen?

fn read_entry<T, B>(backend: &B, key: &[u8], fallback: Option<T>) -> Result<T, ReadEntryErr>
where
	T: Decode,
	B: Backend<HashFor<relay_chain::Block>>,
{
        // WHERE DOES THIS BACKEND GET WRITTEN WITH dmq_mqc_head(self.para_id) ?
	backend
		.storage(key)
                 // IT FAILS TO READ THE KEY (DmqMqcHead(Proof))
		.map_err(|_| ReadEntryErr::Proof)?
.
.
.
let dmq_mqc_head: relay_chain::Hash = read_entry(
	&self.trie_backend,
	&relay_chain::well_known_keys::dmq_mqc_head(self.para_id),
	Some(Default::default()),
)
.map_err(Error::DmqMqcHead)?;

Inside the trie_backend there isn't the key well_known_keys::dmq_mqc_head(self.para_id), so that's why I expected to get a value when I queried the storage for downwardMessageQueueHeads on the rococo relaychain. The para_id is in our collator node from parachain_info. You can query it on the Battery Station: It is 2050 (parachainInfo -> parachainId) there instead of 2101. This is a misconfiguration and needs to be solved. But we can't verify if this is the cause of the problem, because we did start a local rococo chain with the collator and it produced blocks (with the same genesis configuration as here). Does the local rococo setup somehow fill the trie_backend with the dmq_mqc_head (downwardMessageQueueHead) (with the specified paraId from here) ?

I think this test from polkadot github was interesting:

#[test]
fn verify_dmq_mqc_head_is_externally_accessible() {
	use hex_literal::hex;
	use primitives::v2::well_known_keys;

	let a = ParaId::from(2020);

	new_test_ext(default_genesis_config()).execute_with(|| {
		let head = sp_io::storage::get(&well_known_keys::dmq_mqc_head(a));
		assert_eq!(head, None);

		queue_downward_message(a, vec![1, 2, 3]).unwrap();

		let head = sp_io::storage::get(&well_known_keys::dmq_mqc_head(a));
		assert_eq!(
			head,
			Some(hex!["434f8579a2297dfea851bf6be33093c83a78b655a53ae141a7894494c0010589"].to_vec())
		);
	});
}

[sea212]

Looks at this line Oct 29 17:36:25 battery-station-xcm-test-servers zeitgeist[476963]: Thread 'tokio-runtime-worker' panicked at 'Invalid messaging state in relay chain state proof: DmqMqcHead(Proof)', /home/sea212/.cargo/git/checkouts/cumulus-a92b011ec2b4c70b/82c9c1f/pallets/parachain-system/src/lib.rs:352 It looks like there is some mismatch between the mqcHeads state. The storage on the relay side seems clean, as we are doing a fresh onboarding for this para. Could you check if on your side you might have populated some storage related to this ?

Thanks for the fast response @al3mart. What exactly do we have to check? parachainSystem.lastDmqMqcHead and parachainSystem.lastHrmpMqcHeads return nothing. Are there any obvious reasons why it could work on a local rococo instance (using the same version as the live instance) but not on the live one? Are there any requirements in regards to the Cumulus/Polkadot dependency version within the parachain runtime? The genesis wasm contains a runtime that's based on v0.9.19, we could provide another at v0.9.26 shortly.

[al3mart]

dmq_mqc_head only gets populated when messages are going into the queue.
Fix your paraId for the parachain_info module, and let's see the behaviour of your runtime based on v0.9.26

[sea212]

@al3mart Can you please update the genesis code and head to the following:

• State: bs_parachain_rococo_genesis_state.zip
• Wasm: bs_parachain_rococo_genesis_wasm.zip

We also need a lease extension.

For the sake of completeness, here is also the chainspec: bs_parachain_rococo.zip

[al3mart]

All of the above have been addressed.
Onboarding happening in 1h aprox from now

[sea212]

The chain produces blocks now, thanks for the quick update @al3mart .