-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make compatible with Polkadot, Kusama and Rococo #217
base: ilya/parachain-update
Are you sure you want to change the base?
Make compatible with Polkadot, Kusama and Rococo #217
Conversation
node/src/command.rs
Outdated
[RelayChainCli::executable_name().to_string()].iter().chain(cli.relaychain_args.iter()), | ||
); | ||
|
||
let id = ParaId::from(cli.run.parachain_id.or(para_id).unwrap_or(200)); | ||
let id = ParaId::from(cli.run.parachain_id.or(para_id).unwrap_or(2000)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we need to specifically request this Parachain ID?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure. In rococo-v1
, it was 200 https://github.com/substrate-developer-hub/substrate-parachain-template/blob/40b858149b212e493da08d80e0fc5b06a6b0b72d/node/src/command.rs#L274
But in polkadot-v0.9.8
, they replaced it with 2000.
Please see these 2 commits
https://github.com/substrate-developer-hub/substrate-parachain-template/commit/cdc5e5e0bee250f7c14ca8249f0f0e0e63d068b5#diff-8ce03a5a2b79f3021ff2d6322d13448db8cfd5fb9267517ab4b96d0d299ed45f
@ltfschoen please let me know if you want me to roll back it to 200.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
well this PR is for our parachain that connects to Kusama, so i'd imagine the default parachain id that it'd fallback to in the cli would be our DataHighway parachain id. so far it displays the live Kusama parachain id's that are being used here https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fkusama.api.onfinality.io%2Fpublic-ws#/parachains, and it looks like 2000 has already been taken by Karura, so i think we should use expect("Missing ParaId")
. i don't know why they switched to a fallback to the Karura parachain id in what's supposed to be a "template".
i'd suggest finding out how to register a parachain id in the Parachain Technical room on Matrix.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it appears that para id 2000 may be Rococo-specific, according to https://substrate.dev/cumulus-workshop/#/en/3-parachains/2-register, please double check in Parachain Technical room on Matrix if it applies to Kusama too.
Note that in the README it says "When registering to Rococo, ensure you set a ParaId > 1000, below 1000 is meant for system parachains."
https://github.com/substrate-developer-hub/substrate-parachain-template/tree/40b858149b212e493da08d80e0fc5b06a6b0b72d#register-on-the-relay-with-sudo, so please find out what rules apply when registering to Kusama
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please find out how to reserve a parachain id as specified here https://substrate.dev/cumulus-workshop/#/en/3-parachains/2-register?id=registration-transaction. it has a link to "paraID being reserved" but it returns 404, so i'd suggest asking in Parachain Technical room on Matrix how to do it and then create a PR to fix the broken link in their docs.
it also mentions how to do it here in the README of the 'master' branch https://github.com/substrate-developer-hub/substrate-parachain-template/tree/40b858149b212e493da08d80e0fc5b06a6b0b72d#register-on-the-relay-with-sudo, did you try registering on a relay chain to test it like they mention?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ltfschoen Got some responses from community https://matrix.to/#/!WuksvCDImqYSxvNmua:matrix.parity.io/$14W9j8ksOWo3FekiHjEAu6yZoPzd1jSeZVC24ByapeI?via=matrix.parity.io&via=matrix.org&via=web3.foundation
We can take any > 1999 & < max (if no one has already taken it).
Here is parachain guide https://substrate.dev/substrate-how-to-guides/docs/parachains/overview/
Here is guide to reserve paraId https://substrate.dev/substrate-how-to-guides/docs/parachains/c-registration/register-paraid
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
minor comments
aeb5687
to
d9341d3
Compare
any idea we can allow the users in Supernodes to also participate in governance ? |
Co-authored-by: Luke Schoen <ltfschoen@users.noreply.github.com>
Co-authored-by: Luke Schoen <ltfschoen@users.noreply.github.com>
Co-authored-by: Luke Schoen <ltfschoen@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
-
- in
rococo_development_config
function, change name from "Development" to "DataHighway Rococo Development Testnet", and id from "dev" to "datahighway-rococo-dev" -
- in
rococo_local_testnet_config
function, change name from "Local Testnet" to "DataHighway Rococo Local Testnet", and id from "local_testnet" to "datahighway-rococo-local" (horizontal dash rather than an underscore) -
- in
chachacha_development_config
function, change name from "Development" to "DataHighway ChaChaCha Development Testnet", and id from "dev" to "datahighway-chachacha-dev" -
- in
chachacha_local_testnet_config
function, change name from "Development" to "DataHighway ChaChaCha Local Testnet", and id from "local_testnet" to "datahighway-chachacha-local" (horizontal dash rather than an underscore) -
- in
rococo_parachain_config
function, change name from "DataHighway Spreehafen Parachain Testnet" to "DataHighway Spreehafen Rococo Parachain Testnet", and id from "datahighway_spreehafen" to "datahighway-spreehafen-rococo-parachain-testnet" (horizontal dash rather than an underscore) -
- in
chachacha_parachain_config
function, change name from "DataHighway Spreehafen Parachain Testnet" to "DataHighway Spreehafen ChaChaCha Parachain Testnet", and id from "datahighway_spreehafen" to "datahighway-spreehafen-chachacha-parachain-testnet" (horizontal dash rather than an underscore) -
- in
westend_development_config
function, change name from "Development" to "DataHighway Westend Development Testnet", and id from "dev" to "datahighway-westend-dev" -
- in
westend_local_testnet_config
function, change name from "Local Testnet" to "DataHighway Westend Local Testnet", and id from "local_testnet" to "datahighway-westend-local" (horizontal dash rather than an underscore) -
- in
polkadot_development_config
function, change name from "Development" to "DataHighway Polkadot Development Testnet", and id from "dev" to "datahighway-polkadot-dev" -
- in
polkadot_local_testnet_config
function, change name from "Local Testnet" to "DataHighway Polkadot Local Testnet", and id from "local_testnet" to "datahighway-polkadot-local" (horizontal dash rather than an underscore) -
- in
westend_parachain_config
function, change name from "DataHighway Baikal Parachain Testnet" to "DataHighway Baikal Westend Parachain Testnet", change id from "datahighway_baikal" to "datahighway-baikal-westend-parachain-testnet" (horizontal dash rather than an underscore) -
- in
westend_parachain_config
function, i think we should use a different token other than DHX, since the token on Westend is supposed to be valueless.
On some parachains they actually have a faucet for their parachain testnet and give users the opportunity to win NFTs if they have over a certain amount of their parachain testnet tokens- Update 26 Oct - Luke asked team internally about their thoughts on this
- Update 27 Oct - Ayush - I took follow up on same thread and suggested token name based on testnet name
- Update 27 Oct - Ayush - After getting confirmation on discord, we changed it to BKL token
-
- in
westend_parachain_config
function, the relay chain is not "chachacha", its "westend" -
- in
polkadot_parachain_config
function, change name from "DataHighway Tanganika Parachain Testnet" to "DataHighway Tanganika Polkadot Parachain", and id from "datahighway_tanganika" to "datahighway-tanganika-polkadot-parachain" (horizontal dash rather than an underscore) -
- in
polkadot_parachain_config
function, the relay chain is not "chachacha", its "polkadot" -
- "in node/src/command.rs please check that all the CLI commands work"
- Update 26 Oct:
- - running the following:
cargo build --release ./target/release/datahighway-collator --alice --collator --tmp --chain dev
gives error:
Error: Input("Relay chain argument error: Invalid input: `rococo-dev` only supported with `rococo-native` feature enabled.")
- Update 1 Nov: Luke - Done based on feedback obtained by Ayush below
- - running the following:
cargo build --release ./target/release/datahighway-collator --alice --collator --tmp --chain rococo-local
gives error:
Error: Input("Relay chain argument error: Invalid input: `rococo-local` only supported with `rococo-native` feature enabled.")
-
Update 1 Nov: Luke - Done based on feedback obtained by Ayush below
-
Update 27th Oct Ayush: @ltfschoen Regarding above errors, I did an investigation. Earlier I thought, we are getting this error because of this condition https://github.com/paritytech/polkadot/blob/v0.9.10/cli/src/command.rs#L116. I also tried to remove rococo word after seeing the code but that didn't make any difference. I reported the issue here Error: Input("Relay chain argument error: Invalid input:
rococo-dev
only supported withrococo-native
feature enabled.") paritytech/subport#257
I am getting the same error in Substrate Parachain Template as well. -
Update 28th Oct Ayush: @ltfschoen I did a further investigation on this error. here is my finding: According to this https://docs.substrate.io/tutorials/v3/cumulus/connect-parachain/#start-the-collator-node, we have to pass
relay chain raw chain spec
.
We can either use preconfigured files from here https://docs.substrate.io/tutorials/v3/cumulus/start-relay/#pre-configured-chain-spec-files or we can build using these steps https://docs.substrate.io/tutorials/v3/cumulus/start-relay/#generate-a-plain-chain-spec for
rococo-dev
andrococo-local
I downloaded https://docs.substrate.io/assets/tutorials/cumulus/chain-specs/rococo-custom-2-raw.json and executed this command
./target/release/datahighway-collator --alice --collator --tmp -- --execution wasm --chain rococo-custom-2-raw.json
Its working fine.
- Update 29th Oct Ayush: @ltfschoen I didn't get answer from the community yet. However, I continued my investigation.
For
rococo-dev
,rococo-local
andrococo
, we have to specify the spec path in chain argument. Forrococo-dev
andrococo-local
, as I mentioned above We can either use preconfigured files from here https://docs.substrate.io/tutorials/v3/cumulus/start-relay/#pre-configured-chain-spec-files or we can build using these steps https://docs.substrate.io/tutorials/v3/cumulus/start-relay/#generate-a-plain-chain-spec forrococo-dev
andrococo-local
.I tried this on local and connected parachain. Parachain is able to produce blocks.
For
rococo
, we can use https://raw.githubusercontent.com/paritytech/polkadot/v0.9.10/node/service/res/rococo.json. It is also working fine.- Update Ayush 1st Nov: @ltfschoen We got the answer here Error: Input("Relay chain argument error: Invalid input:
rococo-dev
only supported withrococo-native
feature enabled.") paritytech/subport#257 (comment)
- - running the following:
cargo build --release ./target/release/datahighway-collator --alice --collator --tmp --chain chachacha-dev
gives error:
Error: Input("Relay chain argument error: Invalid input: Error opening spec file: No such file or directory (os error 2)")
- Update 1 Nov: Luke - Done based on feedback obtained by Ayush below
- - running the following:
cargo build --release ./target/release/datahighway-collator --alice --collator --tmp --chain chachacha-local
gives error:
Error: Input("Relay chain argument error: Invalid input: Error opening spec file: No such file or directory (os error 2)")
- Update 1 Nov: Luke - Done based on feedback obtained by Ayush below - if ChaChaCha community doesn't know we'll just use rococo-local instead of chachacha-local until they respond
-
Update 28th Oct Ayush: Regarding I have asked on element here https://matrix.to/#/!bNsgeAIUuMfcyVXKAu:matrix.org/$JmjWzn7CHu8ims6E7i7Gibx91d-GfR_pTaY2WyIHPsw?via=matrix.org&via=matrix.parity.io&via=web3.foundation
-
Update 29th Oct Ayush: @ltfschoen In order to connect
chachacha-dev
andchachacha-local
, I got the suggestion in chachacha community that I need to run chachacha dev network somewhere. I tried but I am not able to generate chain spec for chachacha-dev and chachacha-local so its not working.
I have asked again here https://matrix.to/#/!bNsgeAIUuMfcyVXKAu:matrix.org/$E7LOxMMmfskN9pI4eEbCjxpoHcuFtlBhXpCYI4HHXlg?via=matrix.org&via=matrix.parity.io&via=web3.foundation -
Update 1st Nov Ayush: @ltfschoen I got this answer https://matrix.to/#/!bNsgeAIUuMfcyVXKAu:matrix.org/$FTN3A2OXWVdOUAPYGcC9crgCwSjmU-E2n_kdDj80_1M?via=matrix.org&via=matrix.parity.io&via=web3.foundation from Chachacha community.
They said that Rococo and Chachacha are identical so if it works via rococo local your already 80-90% confident it'll work on Chachacha. However they didn't tell why I can't test Chachacha locally.
- - running the following:
cargo build --release ./target/release/datahighway-collator --alice --collator --tmp --chain rococo
successfully runs a node, but why does it mention Babe when we're using Aura instead? are empty Babe epoch changes necessary?
Creating empty BABE epoch changes on what appears to be first startup.
- - running the following:
cargo build --release ./target/release/datahighway-collator --alice --collator --tmp --chain chachacha
gives error:
Error: Input("Relay chain argument error: Invalid input: Error opening spec file: No such file or directory (os error 2)")
- Update 1st Nov Luke: closing on the assumption that we just "have to specify the spec path in chain as argument" as mentioned above by Ayush, "use preconfigured files" or "build ..." using the steps specified. Or use rococo otherwise
- - running the following:
cargo build --release ./target/release/datahighway-collator --alice --collator --tmp --chain westend-dev
gives error:
Error: Input("Relay chain argument error: Invalid input: `westend-dev` only supported with `westend-native` feature enabled.")
- Update 1 Nov: Luke - Done based on feedback obtained by Ayush
- - running the following:
cargo build --release ./target/release/datahighway-collator --alice --collator --tmp --chain westend-local
gives error:
Error: Input("Relay chain argument error: Invalid input: `westend-local` only supported with `westend-native` feature enabled.")
- Update 1 Nov: Luke - Done based on feedback obtained by Ayush
- - running the following:
cargo build --release ./target/release/datahighway-collator --alice --collator --tmp --chain westend
successfully runs a node, but why does it mention Babe when we're using Aura instead? are empty Babe epoch changes necessary?
Creating empty BABE epoch changes on what appears to be first startup.
- - running the following:
cargo build --release ./target/release/datahighway-collator --alice --collator --tmp --chain polkadot-dev
successfully runs a node, but why does it mention Babe when we're using Aura instead? are empty Babe epoch changes necessary?
Creating empty BABE epoch changes on what appears to be first startup.
- - running the following:
cargo build --release ./target/release/datahighway-collator --alice --collator --tmp --chain polkadot-local
successfully runs a node, but why does it mention Babe when we're using Aura instead? are empty Babe epoch changes necessary?
Creating empty BABE epoch changes on what appears to be first startup.
- - running the following:
cargo build --release ./target/release/datahighway-collator --alice --collator --tmp --chain polkadot
successfully syncs with polkadot relay chain, but why does it mention Babe when we're using Aura instead? are empty Babe epoch changes necessary?
Creating empty BABE epoch changes on what appears to be first startup.
- Update 28th Oct: Ayush: Regarding this, I am getting same while running substrate parachain template. However I have asked to community here why does it mention Babe when we're using Aura instead? are empty Babe epoch changes necessary? paritytech/subport#258
- Update 1 Nov Ayush: @ltfschoen we got the answer here why does it mention Babe when we're using Aura instead? are empty Babe epoch changes necessary? paritytech/subport#258 (comment)
-
- rename all the functions so they are prefixed with datahighway, i.e.
-
rococo_development_config -> datahighway_rococo_development_config
-
rococo_local_testnet_config -> datahighway_rococo_local_testnet_config
-
chachacha_development_config -> datahighway_chachacha_development_config
-
chachacha_local_testnet_config -> datahighway_chachacha_local_testnet_config
-
rococo_parachain_config -> datahighway_rococo_parachain_config
-
chachacha_parachain_config -> datahighway_chachacha_parachain_config
-
westend_development_config -> datahighway_westend_development_config
-
westend_local_testnet_config -> datahighway_westend_local_testnet_config
-
polkadot_development_config -> datahighway_polkadot_development_config
-
polkadot_local_testnet_config -> datahighway_polkadot_local_testnet_config
-
westend_parachain_config -> datahighway_westend_parachain_config
-
polkadot_parachain_config -> datahighway_polkadot_parachain_config
-
- why aren't the aura accounts endowed in the
rococo_parachain_config
,chachacha_parachain_config
functions?-
Update 26 Oct - i don't know where the aura keys that are used in these configs were obtained from, please check that you are using the correct keys, then endow like it did it for the other configs
-
Update 26 Oct- @ltfschoen I have shared keys again. let me endowed aura accounts.
-
-
- why aren't the aura accounts endowed in the
westend_parachain_config
,polkadot_parachain_config
functions?- Update 26 Oct - Luke pushed commit addressing this
-
- why aren't there comments above each accounts (public key hex) that you are endowing for
rococo_parachain_config
andchachacha_parachain_config
? they don't appear to correspond to the aura authority accounts you've used- Update 26 Oct - i don't know where the keys that are used in these configs were obtained from, so i don't know which ones are stash, controller, aura, treasury, sudo, or something else
-
- why aren't there comments above each accounts (public key hex) that you are endowing for
westend_parachain_config
andpolkadot_parachain_config
? they don't appear to correspond to the aura authority accounts you've used- Update 26 Oct - Luke pushed commit addressing this
-
- do we only need a Protocol ID to be provided in the
polkadot_parachain_config
? Why don't we need it on the other configurations?-
Update 26 Oct - @ayushmishra2005 if no protocol id is specified then when you run the node it says: "Using default protocol ID "sup" because none is configured in the chain specs", please find out why providing a protocol id is important, and propose what protocol id we should use in each of the other relevant configs
-
Update 27 Oct - Ayush - @ltfschoen I have asked here why providing a protocol id is important in
ChainSpec::from_genesis
? paritytech/subport#256 -
Update 29 Oct - Ayush- @ltfschoen I am marking this as done since we got the answer here why providing a protocol id is important in
ChainSpec::from_genesis
? paritytech/subport#256 (comment). Should I keep one protocol id for all our parachains (testnet and maininet ) or different? -
Update 1 Nov- Ayush We need protocol id as per https://docs.substrate.io/how-to-guides/v3/parachains/pre-launch/#1-set-a-unique-protocolid. This is the first requirement for pre-launch
-
-
- do we still need to get an answer about whether we need more than just the Aura key?
- Answer by Luke: 26th Oct - still waiting, see Should we use this format
Vec<(AccountId, AccountId, GrandpaId, AuraId, ImOnlineId, AuthorityDiscoveryId)>
, or onlyVec<AuraId>
forinitial_authorities
in the chain specification for a Parachain, where the 1st and 2nd elements of the tuple would represent the Stash and Controller keys for controlling its funds paritytech/subport#250 - Update by Ayush 1st Nov: @ltfschoen We got the answer Should we use this format
Vec<(AccountId, AccountId, GrandpaId, AuraId, ImOnlineId, AuthorityDiscoveryId)>
, or onlyVec<AuraId>
forinitial_authorities
in the chain specification for a Parachain, where the 1st and 2nd elements of the tuple would represent the Stash and Controller keys for controlling its funds paritytech/subport#250 (comment). Looks like we don't need more than just Aura Key. I am marking this as done please let me know if you have any concern.
- Answer by Luke: 26th Oct - still waiting, see Should we use this format
-
- Added 26 Oct - datahighway_rococo_parachain_config function hasn't been updated with the new keys in (i.e. authority keys, sudo key, endowed accounts) that you shared for rococo.
- Answer by Ayush: 26th Oct - @ltfschoen I have shared keys again. New keys have already been updated
- - Added 26 Oct - datahighway_chachacha_parachain_config function hasn't been updated with the new keys in (i.e. authority keys, sudo key, endowed accounts) that you shared for rococo (assuming we're using the same keys for rococo and chachacha)
- Answer by Ayush: 26th Oct - @ltfschoen I have shared keys again. New keys have already been updated
- Update 1 Nov Luke: checked all latest keys that were added match those that we have secretly stored
Co-authored-by: Luke Schoen <ltfschoen@users.noreply.github.com>
Co-authored-by: Luke Schoen <ltfschoen@users.noreply.github.com>
Co-authored-by: Luke Schoen <ltfschoen@users.noreply.github.com>
Co-authored-by: Luke Schoen <ltfschoen@users.noreply.github.com>
Co-authored-by: Luke Schoen <ltfschoen@users.noreply.github.com>
Co-authored-by: Luke Schoen <ltfschoen@users.noreply.github.com>
Co-authored-by: Luke Schoen <ltfschoen@users.noreply.github.com>
…n_config functions
|
@ltfschoen I have updated the checklist based on recent discussion with community. |
resolves #216
This PR contains the changes to update parachain code to be compatible for Kusama.
1. - update only codebase to be compatible with Kusama version ... based on confirmation from the community
1.1. - Upgrade to Polkadot 0.9.10
1.2. - Upgrade to Polkadot 0.9.11
1.3. - Upgrade to Polkadot 0.9.12
2.1. - testing has been performed but limited to building the code and executing test-cases including .
2.2. - removed use of rustfmt to be consistent with substrate-parachain-template and DataHighway-DHX/node 'master' branch to maintain ease of developability
2.3. - test against polkadot (not westend) running in --chain <dev|local|staging> using polkadot-launch
2.4. - Test registering parachain locally before attempting to connect to Rococo!
3.1.1 - requested rococo tokens
3.1.2 - register paraId on Rococo testnet
3.1.3 - other relevant testing on Rococo to check that our desired parachain functionality works on a parachain testnet
3.2 - optionally repeat 3.1.1 - 3.1.4 for Westend
4. - repeat 3.1.1 - 3.1.4 for Polkadot
5. request to merge update into 'ilya/parachain'