AZ-003 — Transaction Validation and State Transition Rules v1

Status

Acest document definește regulile normative pentru:

• validarea tranzacțiilor;
• ordinea validărilor;
• tranzițiile de stare;
• conflict detection;
• compunerea efectelor între Value Layer, Logic Layer și Witness Layer.

Acest document presupune că:

• structurile de date din AZ-002 sunt deja definite;
• convențiile canonice de hashing și serializare sunt deja stabilite;
• consensul ENDC complet va fi specificat separat.

Termeni:

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

1. Obiectiv

AZ-003 răspunde la 5 întrebări fundamentale:

1. Când este o tranzacție sintactic validă?
2. Când este o tranzacție semantic validă?
3. În ce ordine se aplică validările?
4. Cum modifică o tranzacție starea globală?
5. Cum se tratează conflictele între tranzacții concurente?

2. Modelul de stare

2.1 Componentele stării

Starea protocolului la un front candidat este definită prin următoarele componente:

GlobalState {
  utxo_set: Map<Hash32, Cell>
  machine_registry: Map<Hash32, MachineDescriptor>
  machine_state_index: Map<Hash32, MachineStateRef>
  witness_index: Map<Hash32, WitnessRecord>
  intent_index: Map<Hash32, IntentStatus>
  policy_index: Map<Hash32, PolicyObject>
  proof_index: Map<Hash32, ProofBundleRef>
  spent_cell_index: Set<Hash32>
  halted_machine_index: Set<Hash32>
  epoch_notarization_index: Map<uint64, EpochNotarization>
  protocol_param_state: ProtocolParamState
}

2.2 Separarea componentelor

• utxo_set este sursa de adevăr pentru Cells active;
• machine_registry conține descriptorii mașinilor deployate;
• machine_state_index conține referința la ultima stare validă a fiecărei mașini;
• witness_index conține Witness Records active și istorice, conform politicilor de retenție;
• intent_index conține statusul intenturilor: active, parțial executate, executate, anulate, expirate;
• policy_index conține politicile cunoscute sau inline-published;
• spent_cell_index poate fi derivat din utxo_set, dar MAY fi menținut explicit pentru eficiență;
• halted_machine_index marchează mașinile oprite normativ;
• epoch_notarization_index conține finalizările de epocă;
• protocol_param_state conține parametrii activi ai versiunii curente.

2.3 Stare activă vs istoric

Nodurile MUST separa:

• starea activă necesară validării curente;
• istoricul necesar auditului și reconstrucției.

Un obiect scos din starea activă MAY rămâne accesibil în indexul istoric.

3. Faze de validare

Orice tranzacție MUST trece prin aceste faze, în această ordine:

1. Admission checks
2. Canonical decoding checks
3. Integrity checks
4. Authorization checks
5. Reference existence checks
6. Temporal checks
7. Conflict checks
8. Semantic checks by tx_type
9. Resource/risk bound checks
10. State transition derivation
11. Post-transition invariant checks

Dacă o fază eșuează, validarea se oprește și tranzacția este invalidă.

4. Admission checks

4.1 Mempool / candidate front admission

Înainte de validare completă, nodul SHOULD verifica minim:

1. dimensiunea totală a tranzacției;
2. versiunea de protocol suportată;
3. tx_type cunoscut;
4. fee minimă estimabilă;
5. lipsa unor câmpuri top-level lipsă;
6. lipsa unor blob-uri imposibil de decode-at.

4.2 Eșecuri

Exemple:

• tx prea mare;
• versiune incompatibilă;
• tip necunoscut;
• body lipsă;
• blob corupt.

Acestea generează invalidare imediată.

5. Canonical decoding checks

5.1 Decodare

Nodul MUST:

1. decode Transaction în AZ-CBOR canonical;
2. verifica lipsa cheilor duplicate;
3. verifica ordinea canonică a cheilor;
4. verifica tipurile pentru toate câmpurile;
5. verifica structura specifică tx_type.

5.2 Eșecuri tipice

• encoding necanonic;
• integer overflow;
• string invalidă;
• enum necunoscut;
• listă peste limită;
• body_blob care nu corespunde schemelor versiunii.

6. Integrity checks

6.1 Hash consistency

Nodul MUST verifica:

• body_hash == H("AZ:..." || canonical_body)
• hash-urile structurilor inline;
• corespondența dintre identificatori derivați și conținut.

6.2 Root consistency

Dacă tranzacția conține sub-structuri cu hash derivat, nodul MUST verifica consistența dintre:

• obiectul inline;
• hash-ul său;
• referințele care îl indică.

6.3 Bundle integrity

Pentru orice auth_bundle_ref, proof_ref, witness_ref sau machine_call_ref, nodul MUST verifica că referința:

• există în starea accesibilă sau payload-ul asociat există inline prin mecanism permis;
• corespunde conținutului canonical;
• nu este structural coruptă.

7. Authorization checks

7.1 Regula generală

Nicio tranzacție MUST NOT producă efecte fără satisfacerea completă a politicilor relevante.

7.2 Politici posibile

În funcție de tipul tranzacției, pot fi necesare:

• control pe fee inputs;
• satisfacerea spend_policy pentru Cells consumate;
• satisfacerea operator_policy / upgrade_policy / halt_policy pentru mașini;
• satisfacerea issuer_policy pentru witness emission;
• satisfacerea creator_policy / cancel_policy pentru intenturi.

7.3 Verificare

Pentru fiecare policy cerută, nodul MUST:

1. rezolva PolicyRef;
2. verifica faptul că politica există și nu este expirată;
3. determina payload-ul exact ce trebuia semnat / aprobat;
4. verifica semnăturile, witnessurile și proof-urile cerute;
5. verifica threshold-ul și fallback-urile, dacă există.

7.4 Principiu

O autorizare parțială sau ambiguă este invalidă. Nu există „aproape suficient”.

8. Reference existence checks

8.1 Regula generală

Orice referință critică MUST exista în starea candidat curentă sau în indexurile istorice permise.

8.2 Exemple de referințe critice

• referenced_cell_id
• machine_id
• prior_state_ref
• witness_ref
• proof_ref
• policy_ref
• intent_id
• epoch_index referit implicit de unele operațiuni

8.3 Reguli

1. O Cell consumată MUST exista în utxo_set.
2. O mașină apelată MUST exista în machine_registry.
3. prior_state_ref MUST egala exact starea curentă activă a mașinii.
4. Un Witness cerut MUST exista și fi accesibil.
5. O politică referită MUST exista.
6. Un intent anulat MUST exista și fi anulabil.

9. Temporal checks

9.1 Obiecte temporale

Nodul MUST verifica ferestrele temporale pentru:

• policy expirată;
• witness expirat;
• proof expirat;
• intent expirat;
• timelock neajuns;
• rent prepaid expirat pentru mașini, dacă regula locală o cere pentru operare.

9.2 Timpul de validare

Temporal checks MUST folosi:

• timpul logic de protocol (epoch/slot) pentru reguli de consens și stare;
• unix_ms doar în limitele definite de protocol, nu timpul local arbitrar.

9.3 Toleranță

Dacă protocolul definește o toleranță de ceas, nodurile MUST aplica aceeași toleranță.

10. Conflict checks

10.1 Tipuri de conflict

A. Cell spend conflict

Două tranzacții consumă aceeași Cell.

B. Machine state conflict

Două TX_MACHINE_CALL folosesc același prior_state_ref și produc două stări alternative incompatibile.

C. Intent exclusivity conflict

Două execuții încearcă să consume același intent în mod incompatibil cu starea sa.

D. Nonce conflict

Două operațiuni folosesc același nonce în domeniul unde nonce-ul trebuie să fie unic.

E. Halt/live conflict

O tranzacție încearcă să invoce o mașină oprită sau concurent cu o tranzacție de halt în același front incompatibil.

10.2 Regula generală

Într-un front candidat compatibil, conflictele MUST fi rezolvate prin excluderea uneia sau mai multor tranzacții. Tranzacții conflictuale MAY coexista în mempool, dar MUST NOT coexista în aceeași execuție de front compatibil.

10.3 Prioritate

AZ-003 nu fixează încă ordinea de alegere a câștigătorului în toate conflictele. Aceasta este rolul consensului și/sau al motorului de clearing. Dar orice nod MUST detecta conflictul în mod identic.

11. Semantic checks by tx_type — overview

Pentru fiecare tip de tranzacție:

• există validări comune;
• există validări specifice;
• există o funcție normativă de state transition.

Tipuri:

• TX_VALUE_TRANSFER
• TX_MACHINE_DEPLOY
• TX_MACHINE_CALL
• TX_WITNESS_EMIT
• TX_INTENT_SUBMIT
• TX_INTENT_CANCEL
• TX_GUARD_HALT
• TX_EPOCH_NOTARIZE

12. TX_VALUE_TRANSFER

12.1 Obiectiv

Consumă un set de Cells și creează un set nou de Cells, fără logică programabilă generală.

12.2 Validări specifice

Nodul MUST verifica:

1. toate CellInput referă Cells active;
2. toate politicile de cheltuire sunt satisfăcute;
3. fiecare input este consumat o singură dată în tranzacție;
4. fiecare output Cell este sintactic validă;
5. niciun output cell_id nu colizionează cu un cell_id deja activ;
6. conservarea valorii per activ;
7. politicile speciale de asset sunt respectate;
8. fee inputs și fee outputs sunt coerente.

12.3 Conservarea valorii

Pentru fiecare asset_id:

sum(inputs[asset_id]) >= sum(outputs[asset_id]) + fees[asset_id] + burns_declared[asset_id]

Dacă activul este mintable sub policy specială, regula se modifică doar dacă tranzacția conține dovada explicită de mint/burn autorizat.

12.4 State transition

Dacă validarea trece:

• toate input Cells sunt scoase din utxo_set;
• spent_cell_index este actualizat;
• toate output Cells sunt adăugate în utxo_set.

12.5 Postconditions

• niciun input nu rămâne activ;
• toate output-urile sunt active;
• conservarea valorii rămâne adevărată.

13. TX_MACHINE_DEPLOY

13.1 Obiectiv

Înregistrează o Bounded Machine nouă.

13.2 Validări specifice

Nodul MUST verifica:

1. machine_id derivă corect din deploy body;
2. mașina nu există deja;
3. code_hash, abi_hash, initial_state_root sunt structurale valide;
4. state_bound_bytes > 0;
5. effect_bound este coerent și non-zero;
6. loss_envelope există și este permisă de policy-ul protocolului;
7. permission_surface nu conține combinații interzise de versiunea curentă;
8. politicile upgrade_policy, halt_policy, operator_policy există și sunt valide;
9. storage rent / fee de deploy este suficientă;
10. dacă deploy-ul consumă capital de inițializare, Cells asociate sunt valide și autorizate.

13.3 State transition

• descriptorul mașinii este adăugat în machine_registry;
• machine_state_index[machine_id] = initial_state_ref;
• eventuale Cells de capitalizare sunt mutate conform definiției deploy-ului;
• dacă deploy-ul emite witness normativ, acesta este adăugat.

13.4 Postconditions

• mașina există exact o singură dată;
• starea inițială este activă și consistentă cu descriptorul;
• rent state este înregistrată.

14. TX_MACHINE_CALL

14.1 Obiectiv

Invocă o tranziție de stare într-o mașină existentă.

14.2 Validări specifice

Nodul MUST verifica:

1. mașina există;
2. mașina nu este halted;
3. prior_state_ref egalează starea activă curentă;
4. selectorul este permis;
5. caller-ul este autorizat pentru selector;
6. toate Cells atașate există și sunt consumabile;
7. toate witnessurile atașate există și sunt valide;
8. toate proof-urile sunt valide;
9. max_exec_units este în limitele protocolului;
10. mașina executată determinist produce exact rezultatul reclamat sau reconstructibil;
11. noua stare respectă state_bound_bytes;
12. efectele respectă effect_bound;
13. loss_envelope nu este încălcat;
14. permission_surface permite toate efectele observate;
15. conservarea valorii este respectată pentru activele conservate.

14.3 Executarea deterministă

Nodul MUST putea reconstrui:

• input-ul efectiv;
• contextul de stare;
• efectele;
• noua rădăcină de stare.

Nodul MUST NOT accepta efecte declarate care nu pot fi reproduse deterministic.

14.4 Efecte permise

Un machine call MAY:

• consuma Cells;
• crea Cells;
• emite Witness Records;
• modifica starea internă a mașinii;
• bloca sau debloca valoare în limitele declarate;
• arde valoare doar dacă can_burn_value = true.

14.5 State transition

Dacă validarea trece:

• starea veche a mașinii este înlocuită în machine_state_index;
• Cells consumate ies din utxo_set;
• Cells emise intră în utxo_set;
• Witness Records emise intră în witness_index;
• contoarele / rent / bookkeeping-ul mașinii se actualizează.

14.6 Postconditions

• starea mașinii este unică și neambiguă;
• toate efectele sunt complet reprezentate în stare;
• nu există side effects implicite.

15. TX_WITNESS_EMIT

15.1 Obiectiv

Publică un Witness Record autonom sau derivat dintr-un proces.

15.2 Validări specifice

Nodul MUST verifica:

1. witness_id derivă corect;
2. issuer_policy este satisfăcută;
3. statement_type este permis pentru issuer, dacă există astfel de restricții;
4. subject_ref este bine formată și, dacă regula o cere, obiectul referit există;
5. proof_bundle_ref, dacă există, este validă;
6. ttl, dacă există, este validă;
7. nu există o regulă de unicitate încălcată pentru același issuer/subject/type unde protocolul sau aplicația o cere.

15.3 State transition

• Witness Record este adăugat în witness_index.

15.4 Postconditions

• witnessul devine utilizabil imediat sau de la epoca definită, conform protocolului;
• orice revocation rule rămâne doar potențială până la emiterea unei revocări valide.

16. TX_INTENT_SUBMIT

16.1 Obiectiv

Înregistrează un intent declarativ pentru clearing ulterior.

16.2 Validări specifice

Nodul MUST verifica:

1. intent_id derivă corect;
2. creator_policy este satisfăcută;
3. time_window este validă și neexpirată;
4. risk_limit este sintactic valid;
5. target_domain și action_type sunt suportate;
6. required_witness_refs, dacă există, sunt prezente și valide;
7. max_fee_by_asset este coerentă;
8. cancel_policy este validă;
9. nonce-ul intentului nu intră în conflict în domeniul creatorului, dacă schema locală cere unicitate.

16.3 State transition

• se adaugă o intrare în intent_index:

IntentStatus {
  status = ACTIVE
  filled_ratio = 0
  remaining_constraints = original
}

16.4 Postconditions

• intentul poate fi consumat doar de clearing/executori compatibili;
• intentul nu mută singur valoare.

17. TX_INTENT_CANCEL

17.1 Obiectiv

Anulează un intent activ.

17.2 Validări specifice

Nodul MUST verifica:

1. intentul există;
2. statusul său permite anularea;
3. cancel_policy este satisfăcută;
4. intentul nu este deja fully executed;
5. intentul nu este deja anulat;
6. dacă protocolul cere, anularea respectă regulile de timp și fee.

17.3 State transition

• intent_index[intent_id].status = CANCELLED
• se înregistrează timestamp/epoch de anulare.

17.4 Postconditions

• intentul nu mai poate fi executat după momentul efectiv al anulării.

18. TX_GUARD_HALT

18.1 Obiectiv

Oprește normativ o mașină sau un domeniu logic.

18.2 Validări specifice

Nodul MUST verifica:

1. ținta există și este haltable;
2. halt_policy este satisfăcută;
3. condițiile de halt definite de protocol sau aplicație sunt îndeplinite;
4. tranzacția nu încearcă să haltez un obiect deja halted în mod redundant incompatibil;
5. dacă halt-ul e de urgență, contextul și dovada cerută există.

18.3 State transition

• ținta este adăugată în halted_machine_index sau alt index de halt relevant;
• dacă există efecte asociate de freeze, acestea se aplică conform descriptorului mașinii și politicilor sale.

18.4 Postconditions

• apelurile noi către mașina halted sunt invalide până la reluare, dacă reluarea este permisă de alt document.

19. TX_EPOCH_NOTARIZE

19.1 Obiectiv

Sigilează un front compatibil și finalizează o epocă.

19.2 Validări specifice

Nodul MUST verifica:

1. epoch_index nu este deja finalizat incompatibil;
2. selected_front_block_ids descriu un front compatibil;
3. execuția deterministică a frontului produce exact:
   • finalized_state_root
   • finalized_tx_root
   • finalized_witness_root
4. semnăturile notarilor ating pragul cerut;
5. comitetul de notari este corect pentru acea epocă;
6. conflict set-ul, dacă există, este consistent;
7. nu există notarizare dublă validă pentru aceeași epocă.

19.3 State transition

• intrarea epoch_notarization_index[epoch_index] este setată;
• frontul devine hard-final;
• stările anterioare nefinalizate conflictuale sunt marcate ca respinse.

19.4 Postconditions

• nodurile MUST trata epoca ca finală;
• orice tranzacție dependentă de finalitate poate continua.

20. Fee validation

20.1 Regula generală

Orice tranzacție MUST plăti fee suficientă conform:

• dimensiunii;
• exec units;
• rent impact;
• witness/proof overhead;
• priorității sau clasei de intent, dacă este cazul.

20.2 Fee assets

Protocolul MAY permite fee în mai multe active, dar v1 SHOULD favoriza activul nativ pentru simplitate.

20.3 Insuficiență

Dacă fee este sub minimul calculat, tranzacția este invalidă sau inadmisibilă, conform contextului.

21. State transition function

21.1 Definiție abstractă

ApplyTx(GlobalState S, Transaction T) -> (GlobalState S', TxReceipt R) | ProtocolError

21.2 Proprietăți

ApplyTx MUST fi:

• deterministă;
• pură conceptual (fără side effects externe);
• dependentă doar de S, T și parametrii activi de protocol.

21.3 TxReceipt

TxReceipt {
  tx_id: Hash32
  status: enum { APPLIED, REJECTED }
  consumed_cell_ids: [Hash32]
  created_cell_ids: [Hash32]
  touched_machine_ids: [Hash32]
  emitted_witness_ids: [Hash32]
  touched_intent_ids: [Hash32]
  fee_paid_by_asset: [(asset_id: Hash32, amount: uint128)]
  exec_units_used: uint64
  state_delta_hash: Hash32
  error_code: uint32?
}

Dacă tranzacția este aplicată, error_code MUST lipsi. Dacă este respinsă, receipt-ul complet MAY exista doar în contexte de audit/debug, nu în starea finală.

22. Ordinea într-un front de execuție

22.1 Principiu

Execuția unui front candidat MUST produce același rezultat pe toate nodurile.

22.2 Ordinea normativă minimă

În lipsa unui motor special de clearing, ordinea de execuție într-un pachet determinist SHOULD fi:

1. topological order by dependencies;
2. apoi lexicographic by tx_id pentru conflicte altfel egale;
3. excluderea celor care devin invalide din cauza efectelor tranzacțiilor anterioare.

22.3 Intent clearing

Pentru TX_INTENT_SUBMIT, înscrierea intenturilor în stare este directă. Executarea lor efectivă într-un batch special va fi definită în documentul de clearing, dar MUST urma aceleași principii de determinism.

23. Dependency rules

23.1 Dependințe explicite

O tranzacție depinde explicit de altă tranzacție dacă:

• consumă un Cell creat de ea;
• folosește un witness emis de ea;
• folosește o mașină deployată de ea;
• folosește un intent creat de ea.

23.2 Dependințe implicite

Există dependență implicită dacă:

• două tranzacții folosesc aceeași stare anterioară a unei mașini;
• două tranzacții consumă același Cell;
• o tranzacție halteză o mașină pe care alta o apelează.

23.3 Regula

Ordinea finală MUST respecta dependențele explicite și MUST rezolva dependențele implicite prin excludere sau regulă deterministă.

24. Rollback conceptual în front candidat

24.1 Mempool/front execution

Într-un front candidat nefinalizat, nodul MAY:

• aplica tranzacții speculative;
• recalcula;
• reconstrui ordinea.

24.2 După notarizare

După TX_EPOCH_NOTARIZE validă:

• rollback-ul frontului finalizat MUST NOT fi permis în execuția normală;
• orice stare alternativă devine respinsă sau istoric conflictual.

25. Resource and risk bound checks

25.1 Resource bounds

Orice tranzacție MUST respecta:

• limite de dimensiune;
• limite de număr de inputs/outputs;
• limite de witness/proof count;
• exec units;
• state write bytes;
• per-epoch caps dacă există.

25.2 Risk bounds

Pentru tranzacții ce ating Logic Layer sau intents, nodul MUST verifica:

• envelope de pierdere;
• max locked duration;
• dependency count;
• asset scope;
• contrapartide permise;
• obligații de jurnalizare/witness.

25.3 Principiu

Dacă un efect e logic permis, dar depășește un bound declarat, tranzacția este invalidă.

26. Witness validity during transition

26.1 Witness active

Un witness este activ dacă:

• există;
• nu e expirat;
• nu e revocat;
• statement-ul și subject-ul se potrivesc cerinței policy;
• dovada sa este validă.

26.2 Witness consumed vs referenced

ATLAS ZERO v1 tratează witnessurile în mod normal ca obiecte referențiale, nu consumabile. Dar anumite statement_type MAY fi definite ulterior ca single-use.

26.3 Revocare

Dacă un witness a fost revocat valid înainte de punctul temporal relevant, el MUST NOT satisfice o condiție.

27. Machine call transition semantics

27.1 Single-state lineage

Fiecare mașină are o singură linie activă de stare. Două stări succesoare incompatibile din același prior_state_ref nu pot coexista active.

27.2 Derived effects

Toate efectele mașinii MUST fi derivabile din:

• descriptor;
• starea veche;
• call input;
• witness/proofs;
• parametrii protocolului.

27.3 No hidden external reads

Execuția MUST NOT depinde de:

• mempool local;
• HTTP calls;
• random extern;
• ceas liber;
• stări nehash-uite și nereferențiate.

27.4 Oracle/witness reads

Citirea de date externe este permisă numai prin:

• witnessuri;
• proof bundles;
• alte obiecte protocolare validate.

28. Intent status machine

28.1 Stări

IntentLifecycleStatus =
  ACTIVE
  PARTIALLY_FILLED
  FULLY_FILLED
  CANCELLED
  EXPIRED
  REJECTED_BY_CLEARING

28.2 Tranziții permise

• ACTIVE -> PARTIALLY_FILLED
• ACTIVE -> FULLY_FILLED
• ACTIVE -> CANCELLED
• ACTIVE -> EXPIRED
• PARTIALLY_FILLED -> FULLY_FILLED
• PARTIALLY_FILLED -> CANCELLED
• PARTIALLY_FILLED -> EXPIRED

FULLY_FILLED, CANCELLED, EXPIRED sunt terminale.

28.3 Regula

Nicio execuție nouă MUST NOT atinge un intent în stare terminală.

29. Error precedence

29.1 Motiv

Aceeași tranzacție poate încălca mai multe reguli. Pentru consistență, nodurile SHOULD produce aceeași clasă primară de eroare.

29.2 Ordinea recomandată

1. syntax / decoding errors
2. hash mismatch
3. unknown reference / object missing
4. expired object
5. invalid authorization
6. direct conflict
7. semantic invalidity
8. bound exceeded
9. post-invariant failure

Această ordine reduce ambiguitatea între noduri.

30. Deterministic receipts

30.1 Principiu

Dacă două noduri aplică aceeași tranzacție validă la aceeași stare, ele MUST produce același TxReceipt, cu excepția câmpurilor explicit non-consensus, dacă vor exista.

30.2 Câmpuri deterministe

• consumed cells
• created cells
• touched machines
• emitted witnesses
• fees
• exec units
• state delta hash

31. Canonical state delta

31.1 Definiție

Orice tranzacție aplicată MAY fi rezumată printr-un delta canonic:

StateDelta {
  removed_cells: [Hash32]
  added_cells: [Hash32]
  updated_machine_states: [(machine_id: Hash32, old_state: Hash32, new_state: Hash32)]
  added_witnesses: [Hash32]
  updated_intents: [(intent_id: Hash32, old_status: uint8, new_status: uint8)]
  added_policies: [Hash32]
  halted_objects: [Hash32]
}

31.2 Utilizare

Acest delta:

• ajută auditul;
• ajută calculul de state_delta_hash;
• ajută debugging și light verification.

32. Revalidation after dependency changes

32.1 Regula

Dacă o tranzacție A face invalidă semantic o tranzacție B în același front, B MUST fi revalidată sau exclusă.

32.2 Exemple

• A consumă Cell pe care B o consuma;
• A mută starea mașinii, iar B folosea prior_state_ref vechi;
• A anulează intentul pe care B voia să-l execute;
• A halteză mașina apelată de B.

33. Multi-asset rules

33.1 Conservare per activ

Conservarea MUST fi evaluată per asset_id, nu global agregat.

33.2 Asset-specific logic

Anumite active MAY avea:

• transfer restrictions;
• mint/burn policy;
• freeze flags;
• regulatory tags.

Acestea trebuie verificate în plus față de regulile generale.

34. Storage rent and liveness

34.1 Mașini

O mașină cu rent expirată MAY:

• rămâne existentă istoric;
• deveni neapelabilă;
• necesita top-up;
• intra în halt economic.

Comportamentul exact final va fi fixat într-un document economic, dar nodurile MUST verifica regula activă de protocol.

34.2 Witness și alte obiecte

Witnessurile nu au rent persistent implicit, dar pot avea TTL și reguli de retenție.

35. Validation pseudocode

35.1 Generic pipeline

ValidateAndApply(S, T):
  check_admission(T)
  decode_canonical(T)
  check_integrity(T)
  check_references_exist(S, T)
  check_temporal_validity(S, T)
  check_authorization(S, T)
  check_conflicts(S, T)
  check_semantics_by_type(S, T)
  check_resource_and_risk_bounds(S, T)

  (delta, receipt) = derive_state_transition(S, T)

  S' = apply_delta(S, delta)
  check_post_invariants(S, S', T, delta, receipt)

  return (S', receipt)

35.2 Observație

Ordinea exactă a check_authorization și check_references_exist MAY fi implementată intern diferit pentru optimizare, dar semantica observabilă MUST rămâne aceeași.

36. Post-transition invariant checks

După aplicare, nodul MUST verifica:

1. toate Cells eliminate au dispărut din utxo_set;
2. toate Cells adăugate există în utxo_set;
3. toate stările de mașini actualizate sunt consistente;
4. conservarea valorii rămâne adevărată;
5. niciun bound nu a fost depășit;
6. orice witness emis este indexat corect;
7. orice intent atins are status valid;
8. hash-urile de receipt și delta, dacă sunt produse, sunt consistente.

Dacă oricare dintre aceste verificări eșuează, tranzacția este invalidă, chiar dacă toate fazele anterioare au trecut.

37. Minimal rejection rules

O tranzacție MUST fi respinsă imediat dacă:

• are encoding necanonic;
• referă obiecte inexistente;
• consumă o Cell deja consumată;
• folosește o stare veche de mașină;
• violează o policy;
• violează effect_bound;
• violează loss_envelope;
• încalcă conservarea valorii;
• este expirată;
• cere efecte nepermise de permission_surface.

38. Reorg semantics before finality

38.1 Pre-finality

Înainte de notarizare:

• nodurile MAY reconstrui frontul candidat;
• receipts speculative MAY fi invalidate;
• tranzacțiile respinse într-un front MAY redeveni eligibile într-altul.

38.2 Post-finality

După notarizare:

• receipts finalizate devin definitive;
• statusurile speculative incompatibile sunt aruncate.

39. Security consequence of validation order

Ordinea validărilor nu este doar optimizare. Este parte din securitatea protocolului.

Exemple:

• dacă verifici efecte înainte de existența referințelor, poți crea canale de ambiguitate;
• dacă verifici conservarea înainte de autorizare, poți produce inconsistență de erori;
• dacă nu verifici întâi canonical form, două noduri pot semna payload-uri semnatic egale dar binar diferite.

Prin urmare, ordinea din AZ-003 SHOULD fi tratată ca normativă de interoperabilitate.

40. Ce urmează

După AZ-003, documentul corect este:

AZ-004 — ENDC Consensus and Finality Specification

Acolo trebuie fixate:

• structura epocii;
• rolurile proposer/verifier/notary;
• alegerea comitetelor;
• regula exactă de selecție a frontului;
• pragul de finalitate;
• slashing;
• comportamentul la conflicte și latență.

41. Formula documentului

AZ-002 a fixat obiectele. AZ-003 fixează verbul protocolului:

ce se verifică, în ce ordine, și cum starea trece din S în S' fără interpretări locale.

Închidere

Un protocol devine real nu când are idei bune, ci când două noduri independente ajung inevitabil la aceeași concluzie despre aceeași tranzacție.

AZ-003 definește exact această inevitabilitate.