AZ-046 — Validator Set Legitimacy and Membership Canon v1

Status

Acest document definește canonul legitimității setului de validatori și al membership-ului validatorilor pentru ATLAS ZERO.

După AZ-001 până la AZ-045, există deja:

• specificația protocolului și a subsistemelor;
• modelul de guvernanță, launch, upgrade, hard fork, recovery și archive;
• disciplina cheilor și a recovery-ului;
• canonul constituțional al identității de rețea;
• registrul parametrilor protocolari;
• cadrul legitimității stării după recovery.

AZ-046 răspunde la întrebarea: ce înseamnă validator legitim într-un moment dat, cum este menținut și schimbat setul de validatori, cum se leagă membership-ul de chei, roluri, slashing, recovery și continuitatea rețelei și cum rămâne acest adevăr auditabil și constituțional clar peste timp?

Scopul documentului este să fixeze:

• modelul de identitate și membership al validatorilor;
• criteriile de legitimitate a setului activ;
• intrarea, ieșirea, suspendarea și re-autorizarea;
• relația dintre validator identity, keys, role bindings și validator set;
• relația cu slashing, guvernanță, recovery, constitutional canon și archive;
• și verificarea istorică a membership-ului și a seturilor active.

Acest document se bazează pe:

• AZ-002 până la AZ-045, cu accent direct pe AZ-004, AZ-006, AZ-009, AZ-014, AZ-015, AZ-020, AZ-022, AZ-025, AZ-030, AZ-034, AZ-035, AZ-043 și AZ-045.

Termeni:

• MUST = obligatoriu
• MUST NOT = interzis
• SHOULD = recomandat puternic
• MAY = opțional

1. Obiectiv

AZ-046 răspunde la 10 întrebări critice:

1. Ce este un validator legitim în ATLAS ZERO?
2. Ce definește setul activ de validatori pentru un scope și un boundary date?
3. Cum intră și iese un validator din membership?
4. Cum sunt legate identitatea validatorului, cheile și rolurile de consens?
5. Cum sunt tratate suspendarea, slashing-ul, revocarea și re-admiterea?
6. Cum se reconstruiește setul legitim de validatori la un moment istoric?
7. Cum interacționează membership-ul cu launch, upgrade, hard fork și recovery?
8. Când schimbarea setului este rutină și când devine constituțional semnificativă?
9. Cum se exportă și auditează adevărul validator set-ului?
10. Cum evităm membership ambiguu, dublu, latent sau nelegitim?

2. Principii

2.1 Validator membership is normative state

Membership-ul validatorilor MUST fi tratat ca stare normativă și nu ca listă operațională informală.

2.2 Validator identity is broader than hot signing keys

Identitatea validatorului MUST fi distinctă de cheile de rol temporare. Cheile se pot roti; identitatea și statutul de membership trebuie să rămână urmărite explicit.

2.3 Active set truth must be reconstructible

Pentru orice boundary relevant, sistemul SHOULD putea răspunde exact:

• care era setul legitim de validatori;
• cu ce roluri;
• cu ce chei active;
• sub ce autoritate și reguli.

2.4 Slashing and compromise must affect legitimacy explicitly

Slashing-ul, compromiterea, suspendarea sau revocarea MUST schimba explicit statutul de membership și/sau eligibilitatea de rol.

2.5 Membership continuity must follow network continuity

Dacă rețeaua intră în recovery excepțional sau hard fork, legitimitatea validator set-ului MUST fi re-evaluată și re-legată de noul scope de continuitate sau ramificare.

2.6 Validator canon must support both real-time operations and long-term audit

Canonul SHOULD fi util simultan pentru:

• consens live;
• operator actions;
• recovery;
• upgrade rollout;
• constitutional review;
• audit istoric.

3. Membership canon purpose

3.1 The canon SHOULD answer:

• cine este validator legitim?
• în ce stare de membership se află?
• în ce set activ sau inactiv?
• cu ce chei și roluri?
• când a intrat, când a ieșit, când a fost suspendat sau re-admis?
• ce autoritate a produs această schimbare?
• ce set era legitim la boundary-ul X?

3.2 Rule

Dacă acest canon nu poate răspunde clar la aceste întrebări, validator legitimacy rămâne ambiguă.

4. Validator identity model

4.1 A validator identity SHOULD be defined by:

• validator identity record
• actor identity or organizational identity ref if policy uses one
• validator membership status
• authorized role bindings
• associated stake or legitimacy basis if protocol uses stake-based model
• lineage of key bindings and status changes

4.2 Rule

Validator identity MUST NOT be reducible la o singură cheie hot sau la o simplă adresă operațională.

5. Validator identity record

5.1 Canonical structure

ValidatorIdentityRecord {
  version_major
  version_minor

  validator_id
  validator_name_hash?
  operator_identity_ref?
  admission_basis_class
  creation_scope_hash
  metadata_hash?
}

5.2 admission_basis_class examples

• genesis_member
• governance_admitted
• stake_authorized
• constitutional_recovery_member
• fork_specific_member

5.3 Rule

validator_id SHOULD remain stable across key rotation and role rebinding unless constitutional rupture says otherwise.

6. Validator membership classes

6.1 Recommended membership classes

ATLAS ZERO SHOULD distinge cel puțin:

• VM_CANDIDATE
• VM_ADMITTED
• VM_ACTIVE
• VM_ACTIVE_RESTRICTED
• VM_SUSPENDED
• VM_SLASHED_LIMITED
• VM_REVOKED
• VM_EXITED
• VM_RECOVERY_PENDING
• VM_BRANCH_SPECIFIC
• VM_HISTORICAL

6.2 Meaning

VM_CANDIDATE

Încă neactiv, în proces de evaluare/admitere.

VM_ADMITTED

Legitim admis, dar poate încă neinclus în setul activ curent.

VM_ACTIVE

Validator legitim și activ în setul curent.

VM_ACTIVE_RESTRICTED

Legitim activ, dar cu restricții de rol sau comportament.

VM_SUSPENDED

Temporar exclus din roluri sau set activ.

VM_SLASHED_LIMITED

Legitim în registru, dar cu limitări serioase post-slashing.

VM_REVOKED

Legitimitatea de membership retrasă explicit.

VM_EXITED

Ieșire legitimă și completă din set.

VM_BRANCH_SPECIFIC

Legitim numai pe o anumită ramură constituțională.

6.3 Rule

Membership class MUST be explicit and scope-bound.

7. Validator role classes

7.1 Core validator role classes

• validator_validation_only
• proposer
• verifier
• notary
• archive_validator_observer
• recovery_participant_if_policy_permits

7.2 Rule

Un validator poate avea identitate legitimă fără toate rolurile active. Membership și role eligibility MUST remain separate concepts.

8. Membership status record

8.1 Canonical structure

ValidatorMembershipStatusRecord {
  status_record_id
  validator_ref
  membership_class
  status_scope_hash
  effective_boundary
  reason_class
  authority_ref?
  evidence_root?
}

8.2 reason_class examples

• genesis_activation
• governance_admission
• routine_rotation_of_set
• temporary_suspension
• slashing_outcome
• key_compromise_containment
• recovery_revalidation
• fork_branch_assignment
• voluntary_exit
• constitutional_revocation

8.3 Rule

Membership status MUST be explicit and historically preserved.

9. Admission model

9.1 Admission SHOULD require:

• validator identity record
• admission basis
• required key registrations or key plan
• membership approval or governance act as policy requires
• parameter and network scope compatibility
• readiness or qualification evidence if policy defines it

9.2 Rule

No validator SHOULD become active by mere local configuration or discovery.

10. Admission record

10.1 Canonical structure

ValidatorAdmissionRecord {
  admission_id
  validator_ref
  admission_scope_hash
  admission_basis_class
  key_plan_root?
  approval_root
  activation_boundary
  timestamp_unix_ms
}

10.2 Rule

Admission MUST bind validator identity to exact network/scope and activation boundary.

11. Active validator set model

11.1 A validator set is the canonical set of validators eligible for defined roles at a defined boundary.

11.2 Canonical structure

ValidatorSetRecord {
  version_major
  version_minor

  validator_set_id
  set_scope_hash
  validator_membership_root
  role_assignment_root
  activation_boundary
  status
  provenance_root?
}

11.3 status

• candidate
• approved
• active
• superseded
• revoked
• historical

11.4 Rule

The active validator set for any scope SHOULD be uniquely derivable.

12. Validator membership root

12.1 Derivation

validator_membership_entry_hash_i =
  H("AZ:VALIDATOR_MEMBERSHIP_ENTRY:" || canonical_entry_i)

validator_membership_root = MerkleRoot(validator_membership_entry_hash_i...)

12.2 Each entry SHOULD bind:

• validator_ref
• membership_class
• effective role eligibility root
• active key binding root if relevant

12.3 Rule

Canonical ordering MUST be deterministic.

13. Role assignment root

13.1 Need

Active set and active roles are related but not identical.

13.2 Canonical structure

ValidatorRoleAssignment {
  assignment_id
  validator_ref
  role_class
  role_binding_ref
  assignment_status
}

13.3 assignment_status

• active
• pending
• disabled
• suspended
• superseded

13.4 Rule

Role assignment MUST be derived from legitimate key bindings and membership status.

14. Validator set scope

14.1 Scope MAY include:

• network class
• chain_id
• genesis lineage
• protocol version
• upgrade boundary
• constitutional branch id
• recovery boundary if relevant

14.2 Rule

A validator set without exact scope is weak and operationally dangerous.

15. Genesis validator set

15.1 Genesis SHOULD define the initial legitimate validator set or the initial admission basis from which it is derived.

15.2 Canon SHOULD preserve:

• genesis validator members
• their initial roles or initial eligibility
• their initial key linkage or key plan linkage
• their genesis membership authority

15.3 Rule

Genesis validator truth is constitutionally important and MUST remain reconstructible.

16. Routine validator set changes

16.1 Routine changes MAY include:

• scheduled entry or exit
• bounded rotation of membership
• planned operator changes
• key rotations that do not change identity
• role enablement/disablement within same legitimate member set

16.2 Rule

Routine changes MUST still generate explicit records, but are not automatically constitutional events.

17. Membership change classes

17.1 Recommended change classes

• VCH_ADMISSION
• VCH_ACTIVATION
• VCH_SUSPENSION
• VCH_RESTRICTION
• VCH_SLASH_LIMITATION
• VCH_VOLUNTARY_EXIT
• VCH_REVOCATION
• VCH_REACTIVATION
• VCH_RECOVERY_REVALIDATION
• VCH_BRANCH_ASSIGNMENT

17.2 Rule

Change class SHOULD drive review, monitoring and archive policy.

18. Suspension model

18.1 A validator MAY be suspended due to:

• key compromise suspicion
• upgrade lag
• operational instability
• investigation pending
• recovery uncertainty
• temporary governance action
• slashing-related temporary consequence

18.2 Rule

Suspension SHOULD be explicit and SHOULD not silently imply permanent revocation.

18.3 Rule

Suspended validators MUST NOT continue in roles forbidden by their suspension scope.

19. Suspension record

19.1 Canonical structure

ValidatorSuspensionRecord {
  suspension_id
  validator_ref
  suspension_scope_hash
  suspension_reason_class
  effective_boundary
  expected_review_boundary_hash?
  authority_ref
  evidence_root?
}

19.2 suspension_reason_class examples

• suspected_key_compromise
• signer_instability
• upgrade_noncompliance
• incident_containment
• recovery_dispute
• governance_temporary_restriction

19.3 Rule

Suspensions SHOULD be reviewable and not open-ended by accident.

20. Slashing and membership

20.1 Slashing outcome MAY affect:

• economic state only
• role restrictions
• temporary suspension
• permanent revocation
• branch-specific exclusion after recovery or fork

20.2 Rule

The protocol MUST state whether a slash event automatically changes validator legitimacy, and if so, how.

20.3 Rule

Membership consequences of slashing SHOULD be explicit, not inferred socially.

21. Slashing membership consequence record

21.1 Canonical structure

SlashingMembershipConsequenceRecord {
  consequence_id
  validator_ref
  slash_record_ref
  resulting_membership_class
  role_limitation_root?
  effective_boundary
  authority_ref?
}

21.2 Rule

This record SHOULD link slash economics to validator legitimacy changes.

22. Voluntary exit model

22.1 Voluntary exit SHOULD include:

• explicit exit request or act
• effective boundary
• residual obligations if any
• key deactivation or binding changes
• resulting membership status

22.2 Rule

Exited validators SHOULD remain historically preserved and queryable.

23. Revocation model

23.1 Revocation is stronger than suspension.

It means validator legitimacy is withdrawn for the declared scope.

23.2 Causes MAY include:

• confirmed malicious behavior
• constitutional governance action
• unrecoverable key/control compromise
• invalid admission discovered
• fork branch exclusion
• severe policy violation

23.3 Rule

Revocation MUST be explicit, scope-bound and archived.

24. Revocation record

24.1 Canonical structure

ValidatorRevocationRecord {
  revocation_id
  validator_ref
  revocation_scope_hash
  revocation_reason_class
  effective_boundary
  authority_ref
  evidence_root?
}

24.2 revocation_reason_class examples

• malicious_consensus_behavior
• malicious_operator_behavior
• invalid_membership_basis
• constitutional_exclusion
• confirmed_compromise_without_recovery
• branch_legitimacy_split

24.3 Rule

Revoked validators MUST NOT remain ambiguously active in same scope.

25. Reactivation model

25.1 A suspended or limited validator MAY be reactivated only if:

• grounds for suspension resolved;
• role bindings and keys are legitimate;
• recovery or upgrade conditions are satisfied;
• reactivation authority exists;
• evidence supports restored safety.

25.2 Rule

Reactivation SHOULD be explicit and SHOULD not occur by timeout alone unless policy formally says so.

26. Reactivation record

26.1 Canonical structure

ValidatorReactivationRecord {
  reactivation_id
  validator_ref
  prior_status_ref
  resulting_status_ref
  activation_boundary
  authority_ref
  evidence_root?
}

26.2 Rule

Reactivation MUST preserve lineage from prior restricted state.

27. Key binding interaction

27.1 Membership canon SHOULD link to:

• validator identity
• active key bindings
• role assignments
• key compromise or rotation records
• key reauthorization state

27.2 Rule

A validator MAY remain legitimate while a specific role key is not. Membership truth and key truth MUST remain coupled but distinct.

28. Upgrade and mixed-fleet interaction

28.1 During upgrade rollout:

• some validators MAY remain admitted but signing-ineligible;
• some MAY be validation-only;
• some MAY be suspended for noncompliance;
• some MAY be branch-specific in hard fork context.

28.2 Rule

Validator legitimacy and version compatibility MUST be jointly evaluated.

28.3 Rule

Old validators MUST NOT continue signing after forbidden boundary just because their identity remains admitted historically.

29. Recovery interaction

29.1 Severe recovery MAY require re-validation of:

• who counts as legitimate validator at resulting state;
• which validators remain active;
• which validators are excluded due to compromise, lag or dispute;
• whether branch-specific assignment applies.

29.2 Rule

Recovery SHOULD generate validator legitimacy review for material scopes.

30. Branch-specific validator legitimacy

30.1 After hard fork or constitutional split, a validator MAY be:

• legitimate on both branches;
• legitimate on one branch only;
• suspended on one branch pending review;
• revoked on one branch while historical on another.

30.2 Rule

Branch-specific legitimacy MUST be explicit to avoid replay and authority ambiguity.

31. Validator legitimacy review object

31.1 Canonical structure

ValidatorLegitimacyReviewRecord {
  review_id
  review_scope_hash
  validator_set_ref
  legitimacy_assessment_class
  evidence_root
  finding_root?
  timestamp_unix_ms
}

31.2 legitimacy_assessment_class

• sufficient
• sufficient_with_restrictions
• insufficient
• disputed
• requires_constitutional_review

31.3 Rule

Major launch, recovery and hard fork events SHOULD have validator legitimacy review.

32. Membership authority model

32.1 Membership changes MAY be authorized by:

• genesis truth
• ordinary governance
• constitutional governance
• recovery ratification
• slashing authority path
• operator-level local action only for temporary local disable, not normative membership change

32.2 Rule

Normative membership change MUST be authorized by protocol/governance path, not local operator preference.

33. Membership canon object

33.1 Canonical structure

ValidatorMembershipCanon {
  version_major
  version_minor

  canon_id
  canon_scope_hash
  validator_identity_root
  active_validator_set_ref
  historical_validator_set_root?
  status_change_root
  timestamp_unix_ms
}

33.2 Rule

This object SHOULD be the top-level canonical entry point for validator membership truth.

34. Historical reconstruction

34.1 The canon SHOULD support reconstructing:

• validator set at genesis
• validator set at launch window
• validator set during each major upgrade
• validator set during and after recovery
• branch-specific sets after hard fork
• timeline of admission, suspension, revocation and reactivation

34.2 Rule

Historical membership MUST remain reconstructible even after many key rotations and upgrades.

35. Query model

35.1 Useful queries

• who were active notaries at boundary X?
• which validators were suspended during incident Y?
• which validators were reactivated after recovery Z?
• which branch-specific exclusions existed after hard fork H?
• what validator set was legitimate for release R?
• what membership consequences followed slash S?

35.2 Rule

Canon SHOULD be queryable by validator, role, scope, boundary and change class.

36. Relationship to constitutional canon

36.1 Most membership changes are operational or governance-level, not constitutional.

36.2 They become constitutionally relevant when they:

• affect initial genesis validator truth;
• ratify branch-specific validator legitimacy after split;
• participate in constitutional recovery;
• alter legitimacy of governing validator body itself.

36.3 Rule

Constitutionally relevant validator set changes SHOULD be linked into AZ-043 canon.

37. Relationship to parameter canon

37.1 Membership behavior MAY depend on parameters such as:

• validator set size
• quorum thresholds
• slash severity thresholds
• reactivation delays
• upgrade compliance thresholds
• governance voting thresholds

37.2 Rule

Validator legitimacy decisions SHOULD bind to the active parameter truth of their scope.

38. Relationship to archive and audit export

38.1 Audit exports SHOULD support:

• active validator set proof
• historical membership proof
• role assignment proof
• admission/suspension/revocation lineage
• branch-specific legitimacy proof
• validator legitimacy review proof

38.2 Rule

External auditors SHOULD be able to verify membership truth without direct access to live infrastructure.

39. Anti-patterns

39.1 Systems SHOULD avoid:

1. treating hot signing key as whole validator identity
2. active validator list existing only in operator docs or dashboards
3. suspension by informal message with no record
4. slashing consequences for membership left implicit
5. reactivation by habit after downtime or compromise
6. mixed-fleet laggards still signing because identity not revoked
7. recovery that reuses validator legitimacy assumptions with no review
8. branch-specific legitimacy left unstated after hard fork
9. deleting historical exited or revoked validators
10. no canonical mapping from validator identity to role bindings

40. Formal goals

AZ-046 urmărește aceste obiective:

40.1 Validator legitimacy clarity

The system can state exactly who is a legitimate validator and in what capacity.

40.2 Deterministic active set truth

For any scope and boundary, the active validator set is reconstructible and auditable.

40.3 Clear interaction with keys, slashing, recovery and forks

Validator membership remains coherent through the hardest lifecycle transitions.

40.4 Durable membership memory

The history of admission, suspension, revocation and branch-specific legitimacy remains preserved.

41. Formula documentului

Validator Membership Canon = stable validator identities + explicit membership status records + active validator set records + role/key linkage + historical status lineage + legitimacy review for major transitions

42. Relația cu restul suitei

• AZ-035 definește disciplina cheilor.
• AZ-043 definește constitutional identity canon.
• AZ-045 definește state legitimacy after recovery.
• AZ-046 definește cine are dreptul legitim să participe la consens și cum rămâne această participare clară în timp.

Pe scurt: AZ-046 este memoria normativă a corpului validator care susține rețeaua vie.

43. Ce urmează

După AZ-046, documentul corect este:

AZ-047 — Treasury, Reserve and Public Financial Truth Canon

Acolo trebuie fixate:

• ce este adevărul financiar public al protocolului;
• cum se reprezintă treasury, reserve, rewards, slashing flows și obligațiile publice;
• și cum devin aceste lucruri auditate, exportabile și constituțional clare.

Închidere

O rețea nu știe cu adevărat cine o validează dacă are doar chei active și liste operative. Știe cine o validează când are memorie normativă clară despre: identitate, admitere, rol, suspendare, revocare, reactivare și continuitate pe ramurile ei legitime.

Acolo începe canonul real al validatorilor.