Based on the conversations the Zeitgeist team had with TC in the last days, and taking into account the same issue appeared for the team on Kusama and the fix was approved by the community (see HERE), this proposal is now submitted as external motion for consideration of the Council, before making it to referenda queue for the final decision.
You can find the contextual information on this proposal by the Zeitgeist team HERE or below:
The runtime that is now deployed on Polkadot was prepared before the ParaId was obtained. During local testing rococo-local was used as the relay chain. The parachain was onboarded using another ParaId than the one within the runtime and the parachain was capable of producing blocks and functioning as expected. Assuming that everything is fine, the same runtime was used to bid in the parachain auction using a different ParaId than the one noted in the prepared runtime. As it turns out, the parachain is uncapable of producing blocks on Polkadot due to a ParaId mismatch.
About the same time Zeitgeist also bid for a slot on Kusama to execute a slot lease swap. The testing procedure was the same and also resulted in success, however the chain was also uncapable of producing blocks. If those two events were temporaly further apart, the human error would only have happened once. Unfortunately we are forced into the highly aggrevating situation to ask the governance body twice to fix our Parachain, once for Kusama (proposal) and once for Polkadot.
To fix the bricked chain, the chainspec used for Zeitgeist’s parachain on Polkadot must use 2092 within ParachainInfo::ParaId. To inform Polkadot about the new state root that results from the updated chainspec, paras.forceSetCurrentHead(2092, genesisHead) has to be invoked by the Root origin, whereas genesisHead is set to the resulting genesis state head that is derived from the new chainspec.
We also want to supply a new runtime. It is much more recent (polkadot-v0.9.29 instead of polkadot-v0.9.19).
We are aware of the recent discussion around the technical council circumventing due process on governance here: https://forum.polkadot.network/t/how-to-recover-a-parachain/673/23 and withdrawing from fixing broken parachains. However there is currently not a best practice solution other then avoiding mistakes.
Our humble request to the Technical Committee is to fast-rack this proposal, this is purely a technical hotfix to get the chain started the first time.
To proof that this request is authentic, the manager of ParaId 2092 does provide a signed statement of approval.
Manager (registrar.paras(2092)): 15Q7heNtPy5vaZ79c3eUt7M42Ao3okf7PKKdRDULBz3Z4UyF
Statement: [1675099734007] I hereby approve the deployment of the genesis state 0x000000000000000000000000000000000000000000000000000000000000000000c2e17f26b505c2be4dcefd0ebfd3abe4536fcc86ded7329af33ddd0a9496db9a03170a2e7597b7b7e3d84c05391d139a62b157e78786d8c082f29dcf4c11131400 and the genesis wasm with the blake2-256 hash 0xa4fe96b65d8f78a7f92d1b7eb917ca501518b6910bee573565d16a911fb91a14 for ParaId 2092 on Polkadot
Signature: 0x6a87523b11d4dd17411c3d9ebed91175dafed6b570014b164074b54b3b2c2b147574a9a5e3f2a25dfcd15340617c4df0730302f51016d5264257e7e8b0c39880
PLEASE NOTE THIS PROPOSAL IS SUBMITTED AS AN EXTERNAL MOTION: MEANING IF/AFTER COUNCIL APPROVAL, THE COMMUNITY WILL HAVE THE FINAL DECISION ON THE PROPOSAL IN REFERENDA QUEUE. ALSO NOTE REFERENDUM 103, SUBMITTED BY THE ZEITGEIST TEAM, AIMS TO EXECUTE THE SAME PROPOSAL: HOWEVER THE TEAM HAS PUBLICLY DISCUSSED 56 DAYS FOR ENACTMENT IS A LONG TIME TO WAIT FOR A FIX. IF THIS PROPOSAL PASSES, THEN REFERENDUM 103 WILL NEED TO BE CANCELED OR DOWNVOTED.
Make sure to review and vote at you convenience!