feat: add collator peer ID to ParachainInherentData#8708
Conversation
|
All GitHub workflows were cancelled due to failure one of the required jobs. |
bkchr
left a comment
There was a problem hiding this comment.
I'm against adding some things to structures without having the underlying approach approved.
The underlying approach is the whole collator protocol revamp, which has been reviewed for quite some time (I sent you the doc and several fellows reviewed it, as well as someone from the auditing team) and the implementation is under way (parts of it already merged). We're doing an incremental development plan to avoid big bang implementations that are hard to review |
| pub relay_parent_descendants: Vec<RelayHeader>, | ||
| /// Contains the collator peer ID, which is later sent by the parachain to the | ||
| /// relay chain via a UMP signal to promote the reputation of the given peer ID. | ||
| pub collator_peer_id: Option<ApprovedPeerId>, |
There was a problem hiding this comment.
@sw10pa just a dq, I am not sure about now, when we add this field here, doesn't it change encoding or with None no? I am thinking about when the runtime with this change is enacted, what about older validators/collators without this change, do they still work? Will the ParachainInherentData with collator_peer_id: None produce the same data as ParachainInherentData without collator_peer_id field? Will both validators/collators produce the same state_root or whatever? Other words, is this change backwards-compatible? Will the older validators/collators still work?
There was a problem hiding this comment.
@skunert added this new inherent data type in #8299 in a backwards compatible way. This new data type is written at a different key. This PR piggy-backs on that logic.
- Old collators, old runtime. This is the present state, which works just fine.
- Old collators, new runtime. New runtime will attempt to decode both data types. If the new one fails, it will fall back to the old one.
- New collators supply both inherent data types (most of the data being duplicated). Old runtime will decode the old one, new runtime will decode the new one
* master: omni-node: fix `benchmark pallet` to work with `--runtime` (#8594) Handle and suppress "New unknown `FromSwarm` libp2p event" warning (#8731) Implement detailed logging for XCM failures (#8724) [pallet-revive] contract's nonce starts at 1 (#8734) sync/fix: Clear gap sync on known imported blocks (#8445) [PoP] Add personhood tracking pallets (#8164) client/net: Use litep2p as the default network backend (#8461) Unflake `returns_status_for_pruned_blocks` (#8709) [AHM] Report the weights of epmb pallet to expose kusama and polkadot weights (#8704) Remove all XCM dependencies from `pallet-revive` (#8584) Docker master image tag fix (#8711) Record ed as part of the storage deposit (#8718) [pallet-revive] update dry-run logic (#8662) feat: add collator peer ID to ParachainInherentData (#8708) Nest errors in pallet-xcm (#7730) pallet-assets ERC20 precompile (#8554) Broker: Introduce min price + adjust renewals to lower market. (#8630) [AHM] Staking async fixes for XCM and election planning (#8422) Staking (EPMB): Add defensive error handling to voter snapshot creation and solution verification (#8687)
## Issue [[#7749] Collator Protocol Revamp: send PeerId via UMP](#7749) ## Description Adds an optional `collator_peer_id` field to the new version of `ParachainInherentData` struct from [PR #8299](#8299). This field is currently unused and defaults to `None`, but is added proactively to avoid introducing yet another version of the inherent data after the current release. ## Next Steps ### In a follow-up PR: - Populate `collator_peer_id` on the collator side; - Handle the field in the `parachain-system` pallet and sends a UMP signal to the relay chain.
## Issue [[#7749] Collator Protocol Revamp: send PeerId via UMP](#7749) ## Description Adds an optional `collator_peer_id` field to the new version of `ParachainInherentData` struct from [PR #8299](#8299). This field is currently unused and defaults to `None`, but is added proactively to avoid introducing yet another version of the inherent data after the current release. ## Next Steps ### In a follow-up PR: - Populate `collator_peer_id` on the collator side; - Handle the field in the `parachain-system` pallet and sends a UMP signal to the relay chain.
Issue
[#7749] Collator Protocol Revamp: send PeerId via UMP
Description
Adds an optional
collator_peer_idfield to the new version ofParachainInherentDatastruct from PR #8299. This field is currently unused and defaults toNone, but is added proactively to avoid introducing yet another version of the inherent data after the current release.Next Steps
In a follow-up PR:
collator_peer_idon the collator side;parachain-systempallet and sends a UMP signal to the relay chain.