Should we use this format Vec<(AccountId, AccountId, GrandpaId, AuraId, ImOnlineId, AuthorityDiscoveryId)>, or only Vec<AuraId> for initial_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

[ayushmishra2005]

Should we use this format Vec<(AccountId, AccountId, GrandpaId, AuraId, ImOnlineId, AuthorityDiscoveryId)>, or only Vec<AuraId> for initial_authorities in testnet_genesis function?

https://github.com/substrate-developer-hub/substrate-parachain-template/blob/master/node/src/chain_spec.rs#L128

[ltfschoen]

Vec<(AccountId, AccountId, GrandpaId, AuraId, ImOnlineId, AuthorityDiscoveryId)>

in the DataHighway standalone chain Vec<(AccountId, AccountId, GrandpaId, AuraId, ImOnlineId, AuthorityDiscoveryId)> is used where the 1st and 2nd elements in the vector represent the Stash and Controller account of the session keys that are used by each validator
https://github.com/DataHighway-DHX/node/blob/master/node/src/chain_spec.rs#L1334
https://github.com/DataHighway-DHX/node/blob/master/node/src/chain_spec.rs#L813

however parachain collators maintain parachains by aggregating parachain transactions from users into parachain block candidates and producing state transition proofs for relay chain validators based on those blocks.

so i believe we need the Aura session key to produce the parachain block candidates, but i'm not sure if the collator needs the Grandpa session key since the relay chain validator is the one that finalises the blocks.

collators maintain a full node for the relay chain and a full node for their particular parachain in order to retain all necessary info to be able to collate and execute transactions to produce/author and provide unsealed new blocks to validators on the relay chain for proposing and finalization of parachain blocks.

the collators' set (and their nominators) are selected to produce blocks with a valid set of transactions based on their stake in the network, and part of each block reward goes to the collator that produced the block, who then shares it with the nominators. collators also get stashed if they misbehave

so why shouldn't parachain collators need to have both a Stash and Controller session key?

for example, Karura is a parachain on the Kusama network, and in their chain spec here https://github.com/AcalaNetwork/Acala/blob/master/node/service/src/chain_spec/karura.rs#L99 they use initial_authorities: Vec<(AccountId, AuraId)>,.
maybe the AccountId is the collator account for controlling funds where tokens are sent if the collator gets part of the block reward and where they lose tokens from if they get slashed if they misbehave, whereas the AuraId is the "hot key" for signing to produce blocks? https://docs.substrate.io/v3/concepts/session-keys

why doesn't the substrate-parachain-template include an AccountId key to control funds for rewards/slashing?
even the substrate-template doesn't include AccountId's for control of funds for stash and controller, for some reason.

as for the ImOnlineId key it says here https://docs.substrate.io/v3/runtime/frame#im-online that it allows validators to gossip a heartbeat transaction with each new session to signal that their node is online.
don't collators need to do the same thing?

the documentation says that unlike validators, collator nodes do not secure the network, so if a parachain block is invalid, it will get rejected by validators, but don't collators still need to send heartbeats too to signal that their node is online each session in a similar way even if they aren't currently providing unsealed new blocks to validators on the relay chain?

as for the AuthorityDiscoveryId key it says here https://docs.substrate.io/v3/runtime/frame#authority-discovery that it's used in parachain logic to retrieve the current and the next set of authorities, isn't that something that a collator needs to know?

[ltfschoen]

@ayushmishra2005 , could you highlight in the title of this issue that your question is Parachain-specific.
i.e. you are asking whether we should we use this format Vec<(AccountId, AccountId, GrandpaId, AuraId, ImOnlineId, AuthorityDiscoveryId)>, or only Vec<AuraId> for initial_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

[nuke-web3]

AuraId = https://github.com/substrate-developer-hub/substrate-parachain-template/blob/master/runtime/src/lib.rs#L36

not sure if the collator needs the Grandpa session key since the relay chain validator is the one that finalises the blocks.

Right, it does not.

the collators' set (and their nominators) are selected to produce blocks with a valid set of transactions based on their stake in the network, and part of each block reward goes to the collator that produced the block, who then shares it with the nominators. collators also get stashed if they misbehave

so why shouldn't parachain collators need to have both a Stash and Controller session key?

The devhub parachain template uses no slashing, it is pure vanilla aura-extention https://github.com/paritytech/cumulus/blob/master/pallets/aura-ext/src/lib.rs#L17-L34
you are confusing concepts with a BABE & GRANDPA configuration that this is not.

initial_authorities needs to map from the ChainSpec::from_genesis(...) correctly and it is up to you to set and read things properly for your configuration. AFAIK The order is not important, so long as you map them correctly.

Another example: https://github.com/paritytech/polkadot/blob/dcccd9671191f54831b6b0d9c44170d0eb184700/node/service/src/chain_spec.rs#L296

One idea about collator selection for sovereign chains you might get a lot from: Sub0 Online: Limited Delegated Proof of Stake for Parachains in the Polkadot Ecosystem