AZ-034 — Governance Upgrade and Hard Fork Protocol v1

Status

Acest document definește protocolul de upgrade guvernat și de hard fork pentru ATLAS ZERO.

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

• specificația protocolului și a subsistemelor lui;
• modelul de guvernanță, activare și emergency powers;
• readiness, launch ceremony, launch window și stabilizare post-launch;
• vault-ul de artefacte, pachetele release/genesis și arhiva completă de audit.

AZ-034 răspunde la întrebarea: cum schimbăm protocolul după lansare fără ambiguitate normativă, cum distingem upgrade-urile compatibile de hard fork-urile incompatibile și cum executăm această tranziție sub control de guvernanță, cu identitate de rețea și reguli de activare suficient de clare încât nodurile să nu intre în haos semantic?

Scopul documentului este să fixeze:

• clasele de upgrade;
• diferența dintre soft evolution și hard fork;
• obiectele de propunere, review, aprobare și activare;
• regulile de compatibilitate și de version gating;
• procedura de rollout și cutover;
• regulile de chain identity, archive și audit pentru fork-uri incompatibile;
• comportamentul nodurilor și operatorilor în tranziție.

Acest document se bazează pe:

• AZ-002 până la AZ-033, cu accent direct pe AZ-009, AZ-015, AZ-016, AZ-017, AZ-021, AZ-022, AZ-026, AZ-028, AZ-030 și AZ-033.

Termeni:

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

1. Obiectiv

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

1. Ce este un upgrade guvernat și ce este un hard fork?
2. Ce tipuri de schimbări sunt compatibile și ce tipuri sunt incompatibile?
3. Cine poate propune și activa un upgrade?
4. Ce review și dovezi sunt necesare înainte de activare?
5. Cum se stabilește momentul de activare?
6. Cum știu nodurile dacă suportă upgrade-ul sau trebuie să se oprească?
7. Cum tratăm incompatibilitatea de versiune și chain split-ul intenționat?
8. Cum se schimbă chain identity în cazul unui hard fork incompatibil?
9. Cum se păstrează auditabilitatea și arhivarea unui upgrade sau fork?
10. Cum evităm upgrade-urile informale, activările ambigue și split-urile accidentale?

2. Principii

2.1 Governance must own protocol evolution explicitly

Evoluția protocolului MUST trece prin obiecte și pași expliciți de guvernanță. Nu prin patch-uri tăcute, practici de facto sau acorduri informale.

2.2 Compatibility class must be declared before activation

Orice schimbare SHOULD declara explicit dacă este:

• configurare compatibilă;
• activare de feature compatibilă;
• schimbare de validare compatibilă condiționat;
• schimbare incompatibilă care cere hard fork.

2.3 Nodes must never guess upgrade semantics

Un nod MUST NOT ghici dacă o schimbare este compatibilă sau dacă poate continua. Trebuie să existe semnal protocolar și release-level suficient.

2.4 Hard fork means identity boundary, not just “big upgrade”

Dacă schimbarea produce incompatibilitate normativă de stare, validare sau consens, ea MUST fi tratată ca hard fork cu tratament explicit de identitate și de tranziție.

2.5 Versioning is not enough without activation discipline

Doar creșterea versiunii nu rezolvă problema. Trebuie:

• reguli de activare;
• reguli de suport;
• semnal de compatibilitate;
• și comportament fail-closed pentru nodurile incompatibile.

2.6 Audit trail matters as much as the code change

Pentru orice upgrade sau fork, trebuie să poată fi reconstruit:

• ce s-a schimbat;
• de ce;
• cine a aprobat;
• când s-a activat;
• ce rețea și ce identitate rezultă.

3. Upgrade taxonomy

3.1 Recommended classes

ATLAS ZERO SHOULD distinge cel puțin:

• UG_PARAM_COMPATIBLE
• UG_FEATURE_FLAG_COMPATIBLE
• UG_EXECUTION_SEMANTICS_COMPATIBLE_GATED
• UG_VALIDATION_RULE_COMPATIBLE_GATED
• UG_STATE_LAYOUT_MIGRATION_COMPATIBLE
• UG_HARD_FORK_INCOMPATIBLE
• UG_EMERGENCY_RESTRICTION_TEMPORARY
• UG_EMERGENCY_HARD_FORK

3.2 Meaning

UG_PARAM_COMPATIBLE

Schimbă doar parametri deja prevăzuți de modelul activ, fără a schimba semantica fundamentală a consensului.

UG_FEATURE_FLAG_COMPATIBLE

Activează sau dezactivează feature-uri deja definite și suportate, fără ambiguitate semantică.

UG_EXECUTION_SEMANTICS_COMPATIBLE_GATED

Modifică comportamente de execuție doar prin versiune/flag/namespace clar și cu suport explicit.

UG_VALIDATION_RULE_COMPATIBLE_GATED

Adaugă reguli noi dar într-un mod delimitat de activare care nu introduce ambiguitate pentru nodurile compatibile.

UG_STATE_LAYOUT_MIGRATION_COMPATIBLE

Necesită migrare controlată a layout-ului intern, dar fără schimbare de adevăr protocolar incompatibil, dacă protocolul a prevăzut-o explicit.

UG_HARD_FORK_INCOMPATIBLE

Produce o schimbare incompatibilă de consens, validare, execuție, identity sau state truth.

UG_EMERGENCY_RESTRICTION_TEMPORARY

Măsură restrictivă temporară, fără schimbare definitivă a identității de lanț.

UG_EMERGENCY_HARD_FORK

Hard fork accelerat de urgență, numai sub condiții constituționale stricte.

4. Hard fork definition

4.1 A hard fork SHOULD be declared when one or more are true:

• nodurile vechi și noi pot ajunge la verdicturi diferite pentru aceleași obiecte;
• regulile de consens/finality diferă incompatibil;
• regulile de execuție sau state transition diferă incompatibil;
• chain identity trebuie separată pentru a evita replay sau ambiguitate;
• migrarea necesită nou genesis-like boundary sau nou activation boundary incompatibil.

4.2 Rule

Dacă există incertitudine serioasă asupra compatibilității, schimbarea SHOULD fi tratată conservator ca incompatibilă până la clarificare.

5. Upgrade object model

5.1 Canonical structure

GovernanceUpgradeProposal {
  version_major
  version_minor

  proposal_id
  upgrade_class
  target_network_class
  target_chain_id
  current_protocol_version
  proposed_protocol_version
  compatibility_class
  activation_mode
  activation_boundary
  change_bundle_root
  review_requirements_root
  rollout_requirements_root
  evidence_root?
  metadata_hash?
}

5.2 compatibility_class

• COMPATIBLE
• COMPATIBLE_GATED
• INCOMPATIBLE_HARD_FORK
• TEMPORARY_RESTRICTION
• EMERGENCY_INCOMPATIBLE

5.3 activation_mode

• AT_EPOCH_BOUNDARY
• AT_BLOCK_HEIGHT_BOUNDARY
• AT_TIMESTAMP_BOUNDARY
• AT_GENESIS_REPLACEMENT
• AT_EMERGENCY_BOUNDARY

5.4 Rule

Upgrade proposal MUST declare compatibility and activation mode explicitly.

6. Activation boundary

6.1 Canonical structure

UpgradeActivationBoundary {
  boundary_class
  epoch_index?
  block_height?
  timestamp_unix_ms?
  replacement_genesis_hash?
  replacement_chain_id?
}

6.2 Rule

Exactly the fields required by boundary_class MUST be set. No ambiguous partially-filled boundary.

6.3 Recommendation

Epoch boundary SHOULD be preferred where protocol naturally reasons in epochs.

7. Change bundle

7.1 Purpose

Defines exact semantic payload of upgrade.

7.2 Change bundle MAY include

• parameter diffs
• feature flag diffs
• new registry entries
• deprecated registry entries
• execution version upgrades
• validation rule set changes
• migration routines or migration descriptors
• release package refs
• conformance corpus refs
• monitoring profile changes
• operator manual delta refs

7.3 Rule

A proposal without explicit change bundle is incomplete.

8. Review requirements root

8.1 Purpose

States what review is mandatory before approval.

8.2 MAY include requirements for:

• security review
• conformance update
• performance/simulation evidence
• migration dry-run evidence
• operator readiness update
• public testnet soak window
• external audit or expert review
• constitutionality review

8.3 Rule

Higher-risk upgrade classes SHOULD require stronger review bundles.

9. Rollout requirements root

9.1 Purpose

Defines what must be true operationally before activation.

9.2 Examples

• minimum validator upgrade threshold
• mandatory operator confirmation threshold
• release package freeze
• monitoring profile update complete
• restart/rejoin guidance published
• public advisories published
• launch-style ceremony required for fork

9.3 Rule

Rollout requirements MUST be explicit for incompatible upgrades and SHOULD be explicit for major compatible ones.

10. Compatibility matrix

10.1 The protocol SHOULD maintain a version compatibility matrix describing:

• old version -> new version relation
• simultaneous operation possibility
• mixed fleet tolerance window
• whether validation-only nodes may lag
• whether consensus-signing nodes may lag
• required cutover or stop behavior

10.2 Rule

Operators MUST be able to answer: “Can this version coexist with current active network state after activation?”

11. Versioning model

11.1 Recommended version fields

• protocol major
• protocol minor
• execution profile version
• feature flag profile version
• conformance corpus version
• release artifact version

11.2 Rule

A major version boundary SHOULD signal possible incompatible semantics, but MUST NOT replace explicit compatibility classification.

12. Upgrade governance flow

12.1 Canonical order

1. propose upgrade
2. classify compatibility
3. attach change bundle and evidence
4. review constitutionality and scope
5. review security/conformance/ops requirements
6. publish operator-facing upgrade guidance
7. approve through governance path
8. freeze upgrade release artifacts
9. confirm rollout readiness
10. activate at boundary
11. observe post-activation stabilization

12.2 Rule

Emergency flows MAY compress time but MUST NOT erase the need for explicit classification, decision objects and audit.

13. Operator-facing upgrade package

13.1 For serious upgrades, SHOULD publish:

• release package id
• upgrade proposal id
• compatibility class
• activation boundary
• required operator actions
• mandatory minimum version
• stop/sign-disable guidance for unsupported nodes
• rollback or recovery guidance if applicable

13.2 Rule

Upgrade communications MUST be tied to exact artifacts, not prose alone.

14. Compatible upgrade semantics

14.1 Compatible upgrade SHOULD mean:

• compliant updated nodes and previously compliant nodes that remain supported do not disagree on active protocol truth after activation; or
• disagreement is prevented by clear gating that old nodes understand as unsupported and therefore fail closed before signing.

14.2 Rule

“Compatible” MUST NOT be used casually for changes that merely seem small.

15. Compatible gated semantics

15.1 Some changes MAY be compatible only if:

• old nodes understand feature flag inactive/active boundary;
• execution namespace or version field disambiguates semantics;
• unsupported objects are cleanly rejected pre-activation or post-activation as designed.

15.2 Rule

If old nodes can silently mis-evaluate upgraded semantics, the change is not safely compatible.

16. Incompatible hard fork semantics

16.1 A hard fork MUST define:

• exact cutover boundary
• required new release package
• node behavior for unsupported versions
• new chain_id or equivalent identity treatment if required
• replay protection strategy
• operator ceremony or cutover process
• archive and audit continuation plan

16.2 Rule

Hard fork semantics MUST be explicit enough to prevent accidental dual truths.

17. Chain identity rules for hard fork

17.1 If a hard fork creates incompatible network truth, protocol SHOULD define one of:

• new chain_id
• new genesis-like replacement boundary and derived chain identity
• explicit fork domain separation fields that achieve same replay isolation

17.2 Rule

If replay or cross-fork confusion is plausible, new identity separation MUST be used.

17.3 Rule

Forks that pretend to be same identity while changing incompatible truth are unsafe.

18. Genesis replacement and fork packages

18.1 Some incompatible upgrades MAY require:

• replacement genesis package
• fork transition package
• migration snapshot package
• new release package set

18.2 Rule

These artifacts MUST be frozen, attested and archived similarly to launch-critical artifacts.

19. Node behavior across upgrade classes

19.1 For compatible upgrades

Nodes MAY continue if:

• they support the active version/flags;
• they remain inside compatibility matrix;
• their role policy allows continued signing.

19.2 For incompatible hard fork

Unsupported nodes MUST:

• fail closed;
• disable signing roles before boundary;
• avoid pretending compatibility;
• require explicit upgrade or withdrawal.

19.3 Rule

Consensus-signing nodes MUST behave more conservatively than passive observers.

20. Mixed fleet rules

20.1 The compatibility matrix SHOULD define whether mixed fleets are allowed:

• before activation
• during transition window
• after activation

20.2 Rule

If mixed fleets are unsafe post-boundary, nodes that are not upgraded MUST stop signing or leave consensus role before boundary.

20.3 Recommendation

Hard forks SHOULD minimize ambiguous mixed periods.

21. Activation objects

21.1 After approval, system SHOULD produce:

• UpgradeApprovalRecord
• UpgradeActivationRecord
• UpgradeReadinessRecord
• UpgradeCutoverRecord
• UpgradeObservationRecord

21.2 Rule

Approval is not activation. Activation is not observation. These phases SHOULD remain distinct.

22. UpgradeApprovalRecord

22.1 Canonical structure

UpgradeApprovalRecord {
  approval_id
  proposal_id
  approval_scope_hash
  approval_time_unix_ms
  signer_refs
  signature_envelopes
  blocker_root?
  evidence_root?
}

22.2 Rule

Approval MUST bind exact proposal version and exact change bundle root.

23. UpgradeReadinessRecord

23.1 Canonical structure

UpgradeReadinessRecord {
  readiness_id
  proposal_id
  operator_threshold_root
  release_package_id
  conformance_bundle_ref
  rollout_status_hash
  timestamp_unix_ms
}

23.2 Rule

For significant upgrades, activation SHOULD require explicit readiness record.

24. UpgradeActivationRecord

24.1 Canonical structure

UpgradeActivationRecord {
  activation_id
  proposal_id
  activation_boundary
  activation_scope_hash
  effective_protocol_version
  timestamp_unix_ms
}

24.2 Rule

This object states what becomes active and when. It MUST NOT be ambiguous.

25. UpgradeCutoverRecord

25.1 Purpose

Operational bridge for the actual transition moment.

25.2 Canonical structure

UpgradeCutoverRecord {
  cutover_id
  proposal_id
  activation_record_id
  target_release_package_id
  operator_instruction_root
  timestamp_unix_ms
}

25.3 Rule

Hard forks and serious compatible upgrades SHOULD have explicit cutover records.

26. UpgradeObservationRecord

26.1 Purpose

Captures early post-activation health.

26.2 Canonical structure

UpgradeObservationRecord {
  observation_id
  proposal_id
  observed_window_hash
  health_class
  anomaly_root?
  decision_implication
  timestamp_unix_ms
}

26.3 decision_implication

• continue
• hold_feature
• quarantine_scope
• open_incident
• rollback_if_possible
• prepare_fork_followup

27. Rollout stages

27.1 Recommended stages

• proposal published
• review active
• approval pending
• approved
• release artifacts frozen
• operator readiness in progress
• activation scheduled
• cutover active
• post-activation observation
• stabilized
• archived

27.2 Rule

Each stage SHOULD be explicit in records and advisories.

28. Emergency upgrade and emergency fork

28.1 Emergency restriction temporary

May be used to constrain unsafe scope without incompatible identity split.

28.2 Emergency hard fork

MUST be reserved for severe cases:

• systemic exploit;
• consensus insecurity;
• catastrophic boundedness or authorization break;
• identity-preserving continuation deemed unsafe.

28.3 Rule

Emergency hard fork MUST still:

• classify incompatibility explicitly;
• create exact artifacts;
• produce audit records;
• define boundary and operator guidance.

29. Migration and state transition rules

29.1 If upgrade involves migration, proposal SHOULD define:

• migration trigger boundary
• input state assumptions
• deterministic migration outputs
• rollback or recovery posture if migration fails
• conformance cases for migration path

29.2 Rule

A migration that cannot be deterministically replayed is dangerous and SHOULD be treated conservatively.

30. Operator instructions for upgrades

30.1 Upgrade guidance SHOULD include:

• exact minimum supported version
• whether restart required
• whether signing roles must be disabled before boundary
• whether validation-only mode recommended first
• whether snapshots/backups required before cutover
• what to do on mismatch or lagging state

30.2 Rule

Operators MUST NOT improvise upgrade semantics from release notes alone.

31. Monitoring profiles for upgrades

31.1 Significant upgrades SHOULD define dedicated monitoring deltas:

• new anomaly classes
• new thresholds
• new readiness signals
• temporary stricter monitoring window after activation

31.2 Rule

A major upgrade without monitoring adjustments is operationally weak.

32. Incident interaction

32.1 If anomalies occur during rollout or immediately after activation:

• preserve evidence
• classify whether local, rollout-related or protocol-semantic
• possibly open incident
• possibly hold feature/fork progression
• possibly quarantine or rollback if protocol path allows

32.2 Rule

Upgrade rollout MUST integrate with incident runbooks and decision ledger.

33. Decision ledger interaction

33.1 Upgrade and fork decisions SHOULD be recorded in an operational decision ledger similar to launch-critical decisions.

33.2 Recommended decision classes

• upgrade_hold
• upgrade_proceed
• upgrade_go
• upgrade_defer
• upgrade_abort
• fork_cutover_authorized
• rollback_authorized
• scope_quarantined

33.3 Rule

Critical upgrade/fork transitions MUST be auditable as decisions, not only code commits.

34. Conformance requirements

34.1 Serious upgrades SHOULD require:

• new or updated conformance corpus entries
• regression cases for changed semantics
• version-boundary tests
• mixed-fleet behavior tests if any coexistence allowed

34.2 Rule

If semantics changed, corpus MUST change or an explicit explanation MUST be archived.

35. Public testnet and soak requirements

35.1 For major compatible upgrades and hard forks, SHOULD require:

• testnet exercise
• operator dry run
• cutover rehearsal
• mixed-version observation if applicable
• issue intake window

35.2 Rule

Skipping public or at least adversarial soak for major change SHOULD require explicit justification.

36. Hard fork archive and audit

36.1 Every hard fork SHOULD produce archive package containing:

• original proposal
• compatibility classification
• new release package refs
• new genesis or transition artifacts if applicable
• approval and activation records
• operator guidance bundle
• cutover and observation records
• post-upgrade stabilization review

36.2 Rule

Fork history MUST remain reconstructible as carefully as original launch history.

37. Anti-patterns

Systems SHOULD avoid:

1. calling incompatible change “compatible enough”
2. upgrading by social convention with no activation object
3. mixed fleets after activation when semantics diverge
4. hard fork with no identity separation where replay/confusion possible
5. migration with no deterministic replay plan
6. operator guidance that only says “please upgrade soon”
7. security/emergency fork with no archived rationale or evidence
8. corpus unchanged after semantic change
9. ambiguous boundary definitions
10. deleting prior upgrade decisions or artifacts after supersession

38. Formal goals

AZ-034 urmărește aceste obiective:

38.1 Explicit protocol evolution

Changes to protocol truth are classified, reviewed and activated explicitly.

38.2 Safe incompatibility handling

Hard forks and incompatible upgrades are separated by clear identity and operator behavior rules.

38.3 Upgrade auditability

Future reviewers can reconstruct exactly what changed, why and how it was activated.

38.4 Controlled rollout

Operators and nodes can transition safely without guessing compatibility.

39. Formula documentului

Governance Upgrade / Hard Fork Protocol = explicit change classification + exact activation boundary + compatibility matrix + frozen upgrade artifacts + operator cutover guidance + post-activation observation

40. Relația cu restul suitei

• AZ-009 definește guvernanța și activările.
• AZ-028 până la AZ-033 definesc disciplina de launch, monitoring, review și arhivare.
• AZ-034 extinde aceeași disciplină pentru evoluția post-launch a protocolului.

Pe scurt: AZ-034 este pentru schimbarea controlată a rețelei vii ceea ce AZ-026–AZ-033 au fost pentru lansarea ei controlată.

41. Ce urmează

După AZ-034, documentul corect este:

AZ-035 — Key Rotation, Key Compromise and Recovery Protocol

Acolo trebuie fixate:

• clasele de chei;
• rotația normală și rotația de urgență;
• compromiterea de chei;
• invalidarea, revocarea și re-autorizarea rolurilor;
• și cum evităm atât downtime inutil, cât și continuarea sub chei nesigure.

Închidere

Un protocol matur nu este doar capabil să pornească. Este capabil să se schimbe fără să se mintă singur despre compatibilitate.

Acolo începe upgrade-ul real: când spui clar dacă schimbi parametri, activezi un feature, migrezi un comportament, sau tai lumea în două printr-un hard fork — și tratezi fiecare dintre aceste lucruri cu nivelul de disciplină pe care îl merită.