QN: Validator profile scope changes

[thesan]

Follow-up to #4823

Context

After discussing the Pioneer validator page it appeared that the initial scope was wrong:

1. The Validator accounts are bound to a membership profile using the members.addStakingAccountCandidate / members.confirmStakingAccount extrinsics. As a result the accounts are not stored in the QN (they should be just retrieved directly from the chain). So both QN and protobufs validatorAccount fields introduced in Fix/4823 validator profile #4849 should be removed.
2. The membership profile is what is being verified not the validator account. So the isVerifiedValidator from Fix/4823 validator profile #4849 should be kept but it should be reset to false whenever any membership metadata field is changed.
3. The verification is the membership working group responsibility (not the HR group).

Scope

• @chrlschwb please address (3) in the currently in progress Fix/4824 verify validator #4868 PR.
• (1) and (2) can be addressed in a new PR.

[eshark9312]

@thesan

2. The membership profile is what is being verified not the validator account. So the isVerifiedValidator from Fix/4823 validator profile #4849 should be kept but it should be reset to false whenever any membership metadata field is changed.
3. The verification is the membership working group responsibility (not the HR group).

AFAIK, there is no tx to verify the validator membership with membership working group role.
Do we need to update the runtime?
Can we name the transaction api.tx.membershipWorkingGroup.verifyValidatorMembership or verifyValidatorProfile?

[thesan]

AFAIK, there is no tx to verify the validator membership with membership working group role. Do we need to update the runtime? Can we name the transaction api.tx.membershipWorkingGroup.verifyValidatorMembership or verifyValidatorProfile?

No need to modify the runtime because this verification is pure metadata (it only leaves in the QN). Here's the issue for it: #4824 and here's the PR #4868.

In short these extrinsics will be used: api.tx.operationsWorkingGroupBeta.workerRemark(workerId, msg) api.tx.membershipWorkingGroup.workerRemark(workerId, msg) and api.tx.operationsWorkingGroupBeta.leadRemark(msg) api.tx.membershipWorkingGroup.leadRemark(msg)