AZ-044 — Protocol Parameter Registry Canon v1

Status

Acest document definește canonul registrului de parametri protocolari pentru ATLAS ZERO.

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

specificația protocolului și a subsistemelor;
guvernanța, upgrade-urile și hard fork-urile;
launch discipline, monitoring, stabilization, archive și audit export;
threat canon, conformance claims, economic attack evaluation;
canonul constituțional al identității de rețea.

AZ-044 răspunde la întrebarea: cum definim, clasificăm, identificăm, activăm și arhivăm parametrii protocolari astfel încât modificările de parametri să fie auditabile, compatibile cu guvernanța, clar delimitate de schimbările de semantică și imposibil de confundat cu configurații locale sau cu reguli implicite ascunse?

Scopul documentului este să fixeze:

modelul canonic al parametrilor protocolari;
registrul lor de identitate și tip;
taxonomia parametrilor;
regulile de versionare, activare, deprecere și supersession;
relația dintre parametri, guvernanță, upgrade, launch, conformance și constitutional canon;
și verificarea pe termen lung a adevărului parametrilor activi și istorici.

Acest document se bazează pe:

AZ-002 până la AZ-043, cu accent direct pe AZ-003, AZ-006, AZ-009, AZ-016, AZ-021, AZ-022, AZ-024, AZ-034, AZ-039, AZ-040 și AZ-043.

Termeni:

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

1. Obiectiv

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

Ce este un parametru protocolar în ATLAS ZERO?
Ce clase de parametri există și cum sunt diferențiate?
Cum primește un parametru identitate canonică?
Cum se leagă parametrii de semantică, guvernanță și activare?
Cum distingem schimbarea de parametru de upgrade-ul incompatibil?
Cum verifică un nod setul de parametri activi pentru un scope dat?
Cum se păstrează istoricul activărilor și deprecărilor?
Cum se exportă și auditează adevărul parametrilor?
Cum se leagă registrul de corpusul de conformitate și de threat canon?
Cum evităm deriva parametrilor, dublurile, shadow config-urile și semantica implicită?

2. Principii

2.1 Protocol parameters are normative objects

Parametrii protocolari MUST fi tratați ca obiecte normative, nu ca simple setări dispersate în cod sau config.

2.2 Parameter identity must be stable across time

Un parametru SHOULD avea identitate canonică stabilă chiar dacă:

valoarea lui se schimbă;
statusul lui se schimbă;
se depreciază;
sau este înlocuit.

2.3 Parameter change is not semantic free-for-all

Nu orice schimbare numerică este doar „tuning”. Unele schimbări depășesc domeniul parametrilor și devin upgrade semantic sau hard fork. Această graniță MUST fi explicită.

2.4 Activation truth must be reconstructible

Pentru orice block/epoch/scope relevant, sistemul SHOULD putea răspunde:

ce parametri erau activi;
cu ce valori;
prin ce act de guvernanță;
și sub ce boundary de activare.

2.5 Parameter registry must dominate local convenience

Niciun config local MUST NOT suprascrie adevărul normativ al parametrilor protocolari activi.

2.6 Registry must support both governance and audit

Registrul SHOULD fi util simultan pentru:

activare și rollout;
validare și execuție;
audit și arhivare;
retrospective și postmortem.

3. Parameter canon purpose

3.1 The registry canon SHOULD answer:

ce parametri există oficial?
ce clasă și tip au?
care sunt valorile lor valide?
cine îi poate modifica?
când devin activi?
ce dependențe și limite au?
când au fost depreciați sau înlocuiți?
ce set era activ la momentul X?

3.2 Rule

Dacă registrul nu poate răspunde clar la aceste întrebări, este insuficient.

4. Parameter definition

4.1 A protocol parameter is a normative, scope-bound value or bounded rule selector that:

influențează validarea, execuția, economia, guvernanța, operarea sau alt comportament protocolar;
este activat prin reguli protocolare sau guvernanță;
și trebuie să fie verificabil între noduri.

4.2 Not parameters by default

Nu SHOULD fi tratate ca parametri protocolari:

setările strict locale de logging;
preferințele UI;
paths locale de fișiere;
opțiuni interne de debug;
tunables neexpuse normativ.

4.3 Rule

Dacă o valoare poate schimba verdictul protocolar, costul, activarea sau comportamentul normativ, ea SHOULD fi în registrul canonic.

5. Parameter classes

5.1 Recommended parameter classes

ATLAS ZERO SHOULD distinge cel puțin:

PARAM_CONSENSUS
PARAM_FINALITY
PARAM_VALIDATION
PARAM_BVM_EXECUTION
PARAM_BVM_BOUNDS
PARAM_WITNESS_AND_PROOF
PARAM_ECONOMIC_FEES
PARAM_ECONOMIC_RENT
PARAM_ECONOMIC_REWARDS
PARAM_ECONOMIC_SLASHING
PARAM_GOVERNANCE
PARAM_AGENT_CONTROL
PARAM_LAUNCH_AND_ROLLOUT
PARAM_MONITORING_POLICY
PARAM_ARCHIVE_AND_PRESERVATION
PARAM_COMPATIBILITY_GATING

5.2 Rule

Parameter class MUST be explicit and stable enough for tooling and audit.

6. Parameter type classes

6.1 Recommended type classes

unsigned_integer
signed_integer
rational_ratio
bounded_decimal
boolean
duration_ms
epoch_count
block_height
enum_selector
feature_flag
threshold_vector
registry_ref
policy_ref
curve_or_formula_ref
set_root_ref

6.2 Rule

Type class MUST define canonical encoding and validation rules.

7. Parameter identity model

7.1 Canonical structure

ParameterIdentityRecord {
  version_major
  version_minor

  parameter_id
  canonical_name
  parameter_class
  type_class
  owner_scope_class
  semantic_boundary_class
  creation_time_unix_ms?
  metadata_hash?
}

7.2 parameter_id derivation

parameter_id = H("AZ:PARAM_ID:" || canonical_parameter_identity_record)

7.3 Rule

parameter_id MUST remain stable across value changes. Changing the value MUST NOT create a new parameter identity.

8. Canonical naming policy

8.1 Names SHOULD be:

lowercase or normalized deterministically;
semantically precise;
non-ambiguous across subsystems;
stable over time.

8.2 Example pattern

consensus.proposer.max_candidate_bytes
economics.fees.base_tx_fee
governance.review.min_challenge_epochs
bvm.bounds.max_exec_units_per_call

8.3 Rule

Aliases MAY exist for migration convenience, but canonical name MUST be unique.

9. Owner scope classes

9.1 owner_scope_class examples

protocol_core
consensus_subsystem
economics_subsystem
governance_subsystem
witness_subsystem
launch_governance_scope
preservation_scope

9.2 Rule

Owner scope helps route responsibility but does not by itself authorize modification. Authorization still depends on governance and policy.

10. Semantic boundary class

10.1 Need

Some parameters are safe to tune, others are boundary-sensitive.

10.2 semantic_boundary_class examples

routine_tunable
guarded_tunable
compatibility_sensitive
launch_sensitive
upgrade_sensitive
constitution_adjacent

10.3 Rule

Boundary class SHOULD influence review and activation policy.

11. Parameter definition record

11.1 Canonical structure

ParameterDefinitionRecord {
  definition_id
  parameter_identity_ref
  allowed_range_root?
  enum_domain_root?
  default_value_hash?
  dependency_root?
  activation_constraints_root?
  deprecation_policy_root?
  documentation_hash?
}

11.2 Rule

Definition record MUST describe the valid domain of the parameter, not only current value.

12. Allowed range model

12.1 Canonical structure

ParameterAllowedRange {
  range_id
  parameter_id
  range_class
  lower_bound_hash?
  upper_bound_hash?
  step_hash?
  notes_hash?
}

12.2 range_class examples

closed_interval
half_open_interval
enum_set
ratio_domain
threshold_vector_domain
unconstrained_by_value_but_constrained_by_policy

12.3 Rule

If no useful mathematical range exists, policy constraints SHOULD still be explicit.

13. Dependency model

13.1 Some parameters depend on:

other parameters;
active features;
protocol versions;
governance modes;
upgrade boundaries.

13.2 Canonical structure

ParameterDependency {
  dependency_id
  parameter_id
  dependency_class
  dependency_ref
  constraint_hash
}

13.3 dependency_class examples

other_parameter
feature_flag
protocol_version
upgrade_proposal
governance_act
network_class

13.4 Rule

Dependencies MUST be explicit to avoid invalid parameter states.

14. Current value versus parameter identity

14.1 Identity is stable.

Current value is a time- and scope-dependent state.

14.2 Rule

The registry MUST distinguish:

what parameter is;
what values it can take;
what value is active at boundary X.

15. Parameter value record

15.1 Canonical structure

ParameterValueRecord {
  value_record_id
  parameter_id
  value_hash
  value_encoding_class
  value_scope_hash
  activation_boundary
  source_act_ref?
  status
}

15.2 status

pending
scheduled
active
superseded
revoked
deprecated_context_only

15.3 Rule

A value record MUST be scope-bound and boundary-bound.

16. Value scope model

16.1 Scope MAY bind:

network class
chain_id
genesis lineage
protocol version
release scope
upgrade scope
launch scope
testnet vs mainnet class

16.2 Rule

A parameter value without scope is too weak for serious protocol use.

17. Activation boundary for parameters

17.1 A parameter value SHOULD activate at one of:

epoch boundary
block height boundary
timestamp boundary
genesis time zero
upgrade activation boundary
hard fork boundary

17.2 Rule

Activation boundary MUST be explicit and consistent with the kind of parameter.

17.3 Recommendation

Consensus- and execution-relevant parameters SHOULD favor epoch or clearly protocol-defined boundaries.

18. Parameter set model

18.1 Need

Nodes usually consume consistent sets, not isolated values.

18.2 Canonical structure

ParameterSetRecord {
  parameter_set_id
  set_scope_hash
  parameter_value_root
  activation_boundary
  provenance_root?
  status
}

18.3 status

candidate
approved
active
superseded
revoked
historical

18.4 Rule

The active parameter set for a scope SHOULD be reconstructible exactly.

19. Parameter value root derivation

19.1 Derivation

parameter_value_entry_hash_i =
  H("AZ:PARAM_VALUE_ENTRY:" || canonical_parameter_value_entry_i)

parameter_value_root = MerkleRoot(parameter_value_entry_hash_i...)

19.2 Rule

Entries MUST be ordered canonically by parameter_id or deterministic registry order.

20. Registry canon object

20.1 Canonical structure

ProtocolParameterRegistryCanon {
  version_major
  version_minor

  registry_id
  registry_scope_hash
  identity_root
  definition_root
  active_parameter_set_ref
  historical_parameter_set_root?
  timestamp_unix_ms
}

20.2 Rule

This object SHOULD be the top-level canonical entry point for parameter truth in a given scope.

21. Registry snapshots

21.1 Need

Auditors and nodes may need historical views.

21.2 Canonical structure

ParameterRegistrySnapshot {
  snapshot_id
  registry_id
  snapshot_boundary_hash
  active_parameter_set_ref
  snapshot_root
  timestamp_unix_ms
}

21.3 Rule

Snapshots SHOULD enable exact reconstruction of active parameters at specific historical boundaries.

22. Parameter change classes

22.1 Recommended change classes

PCH_ROUTINE_TUNING
PCH_GUARDED_TUNING
PCH_FEATURE_ACTIVATION
PCH_COMPATIBILITY_SENSITIVE
PCH_LAUNCH_SENSITIVE
PCH_UPGRADE_LINKED
PCH_DEPRECATION
PCH_REPLACEMENT
PCH_CONSTITUTION_ADJACENT

22.2 Rule

Change class SHOULD drive review and activation requirements.

23. Parameter change proposal object

23.1 Canonical structure

ParameterChangeProposal {
  proposal_id
  parameter_id
  prior_value_ref?
  proposed_value_hash
  change_class
  activation_boundary
  justification_hash
  evidence_root?
  governance_path_ref?
}

23.2 Rule

Every material parameter change SHOULD be represented explicitly, not hidden in aggregate diffs only.

24. Routine tuning versus semantic upgrade boundary

24.1 Some changes are true tunables:

fee constants
reward ratios
epoch counts
bounded thresholds inside declared domain

24.2 Some changes are not mere tunables if they:

alter validation semantics incompatibly;
reinterpret encoding or state rules;
change BVM semantics beyond version-gated support;
alter identity-defining governance rules;
make old nodes semantically wrong.

24.3 Rule

If a parameter change crosses semantic boundary, it SHOULD be escalated to upgrade or hard fork process, not disguised as tuning.

25. Governance linkage

25.1 Parameter activation SHOULD link to:

governance proposal
review outcome
approval act
activation boundary
relevant risk review or economic evaluation where material

25.2 Rule

Mainnet-relevant parameter truth MUST NOT depend on local operator discretion.

26. Parameter approval record

26.1 Canonical structure

ParameterApprovalRecord {
  approval_id
  parameter_change_proposal_ref
  approval_scope_hash
  decision_root
  timestamp_unix_ms
  signature_envelopes
}

26.2 Rule

Sensitive parameter changes SHOULD require stronger approval than routine low-impact tunings.

27. Parameter deprecation model

27.1 Need

Parameters may become obsolete.

27.2 Canonical structure

ParameterDeprecationRecord {
  deprecation_id
  parameter_id
  deprecation_class
  effective_boundary
  replacement_parameter_ref?
  rationale_hash
}

27.3 deprecation_class examples

no_longer_used
replaced_by_new_parameter
merged_into_formula
upgrade_obsoleted
constitutional_cleanup

27.4 Rule

Deprecated parameters SHOULD remain historically queryable.

28. Parameter replacement model

28.1 Need

A new parameter may replace an old one while preserving traceability.

28.2 Canonical structure

ParameterReplacementRecord {
  replacement_id
  old_parameter_ref
  new_parameter_ref
  effective_boundary
  replacement_reason_class
  mapping_hash?
}

28.3 replacement_reason_class examples

naming_normalization
semantic_split
semantic_refinement
upgrade_required
type_change_required

28.4 Rule

Replacement MUST preserve lineage and avoid historical ambiguity.

29. Parameter status model

29.1 Recommended statuses

registered
defined
inactive
scheduled
active
deprecated
superseded
revoked
historical

29.2 Rule

Status MUST be explicit both for parameter identities and for parameter values where relevant.

30. Parameter legality and invalid states

30.1 The registry SHOULD prevent or flag:

values outside allowed domain
unresolved dependency cycles
two conflicting active values for same parameter and same scope
active parameter values without approval where approval required
scope-mismatched values
parameters referenced but undefined
local configs pretending to be protocol values

30.2 Rule

Illegal parameter states SHOULD fail closed for serious scopes.

31. Node verification path

31.1 A node SHOULD be able to:

load registry canon
verify identity and definition roots
resolve active parameter set for current scope/boundary
validate each value against definition and dependency rules
verify approvals and activation boundary
derive effective active parameter state
reject ambiguous or illegal parameter states

31.2 Rule

Node verification of parameter truth MUST be deterministic.

32. Relationship to genesis

32.1 Genesis SHOULD include or link:

initial parameter set
parameter root
relevant registry identities needed at time zero

32.2 Rule

The constitutional origin of active parameters at genesis MUST be reconstructible.

33. Relationship to launch and upgrades

33.1 Launch scope SHOULD bind to exact parameter set or parameter root.

33.2 Upgrades SHOULD declare:

parameter changes caused by upgrade
parameters whose meanings change
parameters deprecated or replaced
compatibility impact

33.3 Rule

Launch and upgrade packages SHOULD not leave parameter truth implicit.

34. Relationship to conformance corpus

34.1 Conformance SHOULD cover:

parameter domain validation
parameter activation boundaries
parameter dependency rules
parameter set reconstruction
deprecated/replacement behavior where relevant

34.2 Rule

Material parameter semantics SHOULD have corpus coverage or an explicit reason why not.

35. Relationship to threat canon and economic evaluation

35.1 Some parameter sets may materially affect:

spam economics
validator incentives
witness rewards
governance thresholds
rollout safety
archive verification burden

35.2 Rule

Threat canon and economic attack evaluation SHOULD reference exact parameter sets or snapshots when relevant.

36. Relationship to constitutional canon

36.1 Most parameters are not constitutional.

But some parameter families MAY be constitution-adjacent when they:

redefine governance legitimacy thresholds;
affect identity or hard fork boundaries;
redefine constitutional authority structure.

36.2 Rule

These cases SHOULD be explicitly marked and possibly linked into AZ-043 constitutional canon.

37. Parameter export and audit interface

37.1 External audit exports SHOULD support:

parameter identity subset
active parameter set proof
historical snapshot proof
approval and activation evidence
deprecation/replacement lineage

37.2 Rule

Auditors SHOULD be able to verify what parameter truth was active for a declared scope.

38. Parameter query model

38.1 Useful queries

what is the active parameter set for release X?
what changed between snapshot A and snapshot B?
which parameters are constitution-adjacent?
which parameters were deprecated by upgrade Y?
what approvals activated parameter Z at epoch E?
which parameters affect fee market or slashing?

38.2 Rule

Registry SHOULD be queryable by class, scope, boundary and lineage.

39. Anti-patterns

39.1 Systems SHOULD avoid:

parameter truth scattered across code comments and local configs
same logical parameter registered twice under different names
changing semantic rules via parameter that should be upgrade-class change
no explicit activation boundary
no historical snapshots
parameter replacement with no lineage
hidden dependency between parameters
export of current values only, with no identity or approval history
shadow local overrides acting like protocol truth
deprecating values or identities by deleting history

40. Formal goals

AZ-044 urmărește aceste obiective:

40.1 Stable parameter identity

The system knows exactly what each protocol parameter is across time.

40.2 Deterministic active parameter truth

For any scope and boundary, the active parameter set can be reconstructed and verified.

40.3 Clear boundary between tuning and semantic upgrade

The registry helps prevent semantic change from being smuggled in as ordinary parameter adjustment.

40.4 Audit-grade historical memory

Parameter activation, replacement and deprecation remain visible, queryable and exportable.

41. Formula documentului

Protocol Parameter Registry Canon = stable parameter identities + typed definitions + approved value records + boundary-based activation + historical snapshots + lineage for deprecation and replacement

42. Relația cu restul suitei

AZ-034 definește upgrade și hard fork discipline.
AZ-039 definește threat canon și residual risk.
AZ-040 definește claims de conformitate.
AZ-043 definește canonul constituțional.
AZ-044 definește adevărul normativ al parametrilor care fac toate aceste sisteme operabile și auditabile.

Pe scurt: AZ-044 este registrul oficial al valorilor și limitelor prin care protocolul își exprimă partea configurabilă fără să-și piardă identitatea.

43. Ce urmează

După AZ-044, documentul corect este:

AZ-045 — Formal Recovery Boundary and State Legitimacy Framework

Acolo trebuie fixate:

ce înseamnă recovery legitim;
unde este granița dintre recuperare și rescriere nelegitimă a istoriei;
cum definim starea legitimă după incidente grave;
și ce recorduri ratifică continuitatea sau ruptura de legitimitate.

Închidere

Un protocol matur nu este doar cod și consens. Este și capacitatea de a spune clar: aceștia sunt parametrii, acestea sunt valorile valide, acestea sunt activările lor, acestea sunt dependențele, și aceasta este istoria lor.

Acolo începe registrul real al parametrilor: nu când ai multe constante, ci când ai memorie normativă verificabilă despre ele.