AZ-004 — ENDC Consensus and Finality Specification v1

Status

Acest document definește consensul ATLAS ZERO: ENDC = Epoch Notarized Directed Consensus

Scopul ENDC este să ofere simultan:

• includere rapidă a tranzacțiilor;
• execuție deterministă a fronturilor candidate;
• finalitate hard în epoci scurte;
• audit clar al responsabilității;
• rezistență la conflicte, dublă propunere și validare frauduloasă.

Acest document se bazează pe:

• AZ-002 pentru structuri și hashing;
• AZ-003 pentru validarea tranzacțiilor și tranzițiile de stare.

Termeni:

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

1. Obiectiv

ENDC răspunde la 6 întrebări:

1. Cum este împărțit timpul protocolului?
2. Cine poate propune, verifica și finaliza?
3. Cum coexistă mai multe blocuri candidate înainte de finalitate?
4. Cum se alege frontul valid al unei epoci?
5. Când devine un front final?
6. Cum se pedepsește comportamentul adversarial?

2. Modelul de timp

2.1 Unități temporale

Protocolul definește trei unități:

• slot
• round
• epoch

Slot

Cea mai mică unitate de timp a protocolului. Un slot este fereastra minimă în care un proposer poate emite un bloc.

Round

Grup de sloturi folosit pentru agregarea voturilor și a observațiilor de rețea.

Epoch

Fereastra de finalizare. La sfârșitul fiecărei epoci, un front compatibil este notarizat.

2.2 Parametri de timp

Parametrii minimi:

slot_duration_ms
slots_per_round
rounds_per_epoch
epoch_duration_ms = slot_duration_ms * slots_per_round * rounds_per_epoch

2.3 Cerință

Toate nodurile MUST calcula epoch_index, round_index și slot_index identic din timpul logic de protocol.

3. Actorii consensului

ENDC definește trei roluri active pe epocă:

• Proposers
• Verifiers
• Notaries

3.1 Proposers

Responsabili pentru:

• construirea blocurilor candidate;
• includerea tranzacțiilor și obiectelor relevante;
• referirea la părinți și la starea observată;
• propagarea blocurilor în rețea.

3.2 Verifiers

Responsabili pentru:

• reexecutarea validărilor din AZ-003;
• detectarea conflictelor;
• emiterea de voturi de validare/invalidare;
• raportarea fraudelor și inconsecvențelor.

3.3 Notaries

Responsabili pentru:

• agregarea semnalelor valide;
• alegerea frontului final al epocii;
• emiterea EpochNotarization;
• transformarea unei stări candidate în stare hard-finală.

3.4 Principiu de separare

Un actor MAY deține mai multe roluri numai dacă protocolul permite explicit. Totuși, funcțiile logice ale rolurilor MUST rămâne separate. Un nod MUST putea demonstra sub ce rol a semnat fiecare obiect.

4. Participarea și stake-ul

4.1 Validator identity

Orice actor de consens are:

• validator_id
• chei separate pe roluri
• stake activ sau bond activ
• status de eligibilitate pe epocă

4.2 Stake state

Un actor este eligibil dacă:

• stake-ul său este activ și peste pragul minim;
• nu este slashed peste nivelul de eligibilitate;
• nu este în perioada de cooldown / quarantine;
• a publicat cheile și metadatele necesare.

4.3 Snapshot

Eligibilitatea pentru epoca E MUST fi calculată dintr-un stake snapshot deterministic de la un punct anterior fix:

stake_snapshot_epoch(E) = E - k

unde k este parametru de protocol.

Motiv: se evită manipularea stake-ului chiar înainte de selecția comitetului.

5. Selecția comitetelor

5.1 Componente

Pentru fiecare epocă, protocolul determină:

• setul de proposers;
• setul de verifiers;
• setul de notaries.

5.2 Determinism

Selecția MUST fi:

• deterministă;
• reconstructibilă offline;
• bazată pe seed de epocă;
• ponderată de stake/bond conform regulii active.

5.3 Seed de epocă

Seed-ul pentru epoca E este:

epoch_seed(E) = H("AZ:EPOCH_SEED:" || finalized_state_root(E-1) || notarization_hash(E-1) || committee_entropy(E-1))

Dacă epoca anterioară nu există, genesis definește seed-ul inițial.

5.4 Regula generală de selecție

Fiecare rol este selectat printr-o funcție:

SelectCommittee(epoch_seed, eligible_validators, role_params) -> ordered committee

5.5 Proprietăți obligatorii

Selecția MUST:

• fi deterministică;
• produce comitete cu mărimi fixe sau bounded;
• evita duplicarea excesivă a aceleiași entități;
• produce ordine clară a membrilor.

5.6 Sybil resistance

Selecția MUST depinde de stake/bond economic, nu doar de numărul de identități.

6. Structura rețelei de blocuri candidate

6.1 DAG limitat

ENDC nu presupune un singur lanț temporar înainte de finalitate. În timpul unei epoci, proposerii pot produce blocuri care formează un DAG limitat.

6.2 Definiție

Un bloc poate referi unul sau mai mulți părinți compatibili. Totuși:

• referințele ciclice sunt interzise;
• numărul de părinți MUST fi bounded;
• părinții MUST aparține aceleiași epoci sau unei ferestre imediat anterioare permise de protocol;
• blocurile MUST respecta ordinea temporală logică.

6.3 Scop

DAG-ul limitat permite:

• latență mai mică;
• toleranță la întârzieri de rețea;
• includere concurentă;
• finalizare ulterioară pe bază de front compatibil.

7. Structura blocului candidat

7.1 Block body

Fiecare bloc candidat conține:

• BlockHeader
• listă de tranzacții
• listă de witness objects / bundle refs după nevoie
• listă de machine call results sau date necesare reexecutării
• metadate de validare minimală

7.2 Block metadata

Blocul SHOULD include:

• frontier view observată de proposer;
• tx ordering commitment;
• mempool selection hints;
• dependency hints;
• proposer role proof.

7.3 Reguli

Un bloc MUST:

1. avea header valid;
2. respecta limitele de dimensiune;
3. conține numai obiecte decodabile canonic;
4. referi numai părinți valizi sintactic;
5. respecta slotul și epoca declarate.

8. Soft commit vs hard finality

8.1 Soft commit

Un bloc sau o tranzacție este soft committed când:

• a fost inclus(ă) într-un bloc valid propagat;
• a primit suficiente semnale preliminare de la verifiers;
• nu a fost încă finalizat(ă) prin notarizare.

Soft commit oferă:

• feedback rapid pentru UX;
• probabilitate practică de includere;
• posibilitate de pre-execuție și anticipare.

8.2 Hard finality

Un front devine hard-final numai când:

• există un EpochNotarization valid;
• semnăturile notarilor trec pragul de finalitate;
• frontul selectat este compatibil și reexecutabil;
• rădăcina de stare finalizată este deterministă.

8.3 Regula absolută

Nicio stare MUST NOT fi considerată finală înainte de notarizare validă.

9. Fronturi candidate

9.1 Definiție

Un front este un set ordonat de blocuri din DAG care:

• este aciclic;
• este intern compatibil;
• poate fi executat deterministic;
• produce o stare rezultată unică.

9.2 Compatibilitate

Două blocuri sunt compatibile în același front dacă:

• nu introduc conflicte ireconciliabile de tranzacții;
• nu produc tranziții incompatibile de stare de mașină;
• nu dublu-consumă Cells;
• nu conțin notarizări sau halt effects incompatibile.

9.3 Front maximal compatibil

Pentru epoca curentă, nodurile caută frontul compatibil care maximizează scorul protocolului.

10. Verifier votes

10.1 Obiectiv

Verifiers emit semnale deterministe despre:

• validitatea blocurilor;
• conflictele observate;
• executabilitatea fronturilor candidate;
• fraud proofs.

10.2 Tipuri de vot

Verifiers MAY emite:

• BLOCK_VALID
• BLOCK_INVALID
• BLOCK_CONFLICT
• FRONT_VALID
• FRONT_INVALID
• FRAUD_PROOF_NOTICE

10.3 Conținut minim

Un vot de verifier MUST conține:

• epoca și round-ul;
• obiectul votat;
• tipul votului;
• hash-ul justificării;
• semnătura rolului de verifier.

10.4 Regula

Un verifier MUST NOT semna simultan:

• BLOCK_VALID și BLOCK_INVALID pentru același bloc;
• FRONT_VALID pentru două fronturi incompatibile în același context de finalizare.

11. Fraud proofs

11.1 Definiție

Un fraud proof este un pachet verificabil care demonstrează comportament invalid, inclusiv:

• bloc invalid;
• validare contradictorie;
• dublă propunere;
• notarizare conflictuală;
• execuție neconformă cu AZ-003.

11.2 Cerință

Fraud proof-ul MUST fi:

• compact;
• reconstructibil;
• semnat sau derivabil suficient pentru slashing;
• validabil independent de noduri terțe.

11.3 Exemple

• același proposer emite două blocuri incompatibile pentru același slot;
• același notary semnează două notarizări incompatibile;
• un verifier validează un bloc demonstrabil invalid.

12. Scorarea fronturilor

12.1 Scop

ENDC nu alege „cel mai lung lanț”. Alege frontul compatibil cu scor maxim.

12.2 Funcția abstractă

FrontScore(F) =
  w1 * validity_weight(F) +
  w2 * stake_approved_weight(F) +
  w3 * tx_coverage_weight(F) +
  w4 * dependency_completeness(F) +
  w5 * conflict_penalty(F) +
  w6 * lateness_penalty(F)

Aceasta este formă abstractă; implementarea exactă trebuie să fie deterministă și parametrizată.

12.3 Proprietăți obligatorii

Scorarea MUST:

• favoriza fronturile complet valide;
• penaliza conflictele;
• penaliza blocurile întârziate excesiv;
• favoriza aprobarea stake-weighted;
• nu recompensa simpla dimensiune brută;
• produce același rezultat pe aceleași date.

12.4 Prioritate semantică

Un front complet valid cu ușor mai puține tranzacții MUST bate un front mai mare dar conflictual sau dubios.

13. Regula de selecție a frontului

13.1 Definiție

La închiderea epocii, notaries MUST selecta un front F* astfel încât:

1. F* este compatibil;
2. F* este executabil deterministic;
3. F* maximizează FrontScore;
4. la egalitate, se aplică tie-breakers canonice.

13.2 Tie-breakers

Tie-breakers SHOULD fi:

1. lexicographic order pe front_commitment_hash;
2. apoi minimizarea conflict set-ului;
3. apoi minimizarea latenței agregate;
4. apoi ordering deterministic al block IDs.

13.3 Interdicție

Notaries MUST NOT alege manual sau arbitrar un front dacă tie-breakers pot decide deterministic.

14. Execuția frontului

14.1 Principiu

Pentru un front selectat, nodurile MUST putea reexecuta întregul front și obține:

• aceeași ordine de aplicare a dependențelor;
• aceleași receipts;
• aceeași rădăcină finală de stare;
• aceleași rădăcini de tx și witness.

14.2 Ordine internă

Ordinea în front MUST respecta:

• dependențe explicite;
• dependențe implicite;
• regulile din AZ-003;
• tie-breakers interne dacă mai multe tranzacții independente coexistă.

14.3 Eșec

Dacă frontul ales de notaries nu poate fi reexecutat determinist, notarizarea este invalidă.

15. Notarization threshold

15.1 Prag

O EpochNotarization este validă numai dacă semnăturile notarilor eligibili depășesc pragul protocolului:

notary_signed_stake >= finality_threshold

unde finality_threshold este exprimat ca ratio din stake-ul notary eligibil pentru epocă.

15.2 Recomandare

Pentru rezistență BFT, pragul SHOULD fi supra-majoritar.

15.3 Semnături

Semnăturile notarilor MUST acoperi exact:

• epoca;
• frontul selectat;
• rădăcinile finalizate;
• comitetul relevant;
• metadata de conflict dacă există.

16. EpochNotarization body

16.1 Conținut normativ

Obiectul notarizării MUST conține:

• epoch_index
• selected_front_block_ids
• finalized_state_root
• finalized_tx_root
• finalized_witness_root
• notary_committee_root
• notary_signatures
• front_commitment_hash
• conflict_set_hash dacă relevant
• finality_proof_hash

16.2 front_commitment_hash

front_commitment_hash = H("AZ:FRONT:" || canonical_front_description)

16.3 finality_proof_hash

Leagă notarizarea de întregul pachet de validare necesar auditului.

17. Liveness conditions

17.1 Obiectiv

ENDC SHOULD continua să finalizeze epoci dacă:

• o fracțiune suficientă de stake e online;
• rețeaua nu este fragmentată peste toleranța proiectată;
• există quorum de notaries și verifiers.

17.2 Liveness degradation

Dacă rețeaua este sub stres, protocolul MAY:

• reduce throughput;
• extinde selecția de front către subseturi mai conservatoare;
• omite blocuri întârziate;
• penaliza actorii care nu participă.

Dar MUST NOT compromite finalitatea sau determinismul.

17.3 Epoch without finality

Dacă epoca nu poate fi finalizată:

• se produce NO_FINALITY pentru epoca respectivă;
• stările rămân soft-only;
• protocolul trece în modul de recuperare definit;
• următoarea epocă MUST trata explicit lipsa finalității anterioare.

18. Recovery mode

18.1 Declanșare

Recovery mode poate fi declanșat dacă:

• nu există prag de notarizare;
• există conflict masiv de rețea;
• există atac major de dublă semnare;
• există inconsistență de comitet demonstrată.

18.2 Efecte

În recovery mode, protocolul MAY:

• reduce setul eligibil temporar;
• crește conservator pragurile de acceptare a blocurilor;
• accepta numai un subset simplificat de tranzacții;
• cere witnessuri suplimentare pentru anumite acțiuni sensibile.

18.3 Interdicție

Recovery mode MUST fi deterministic și normativ, nu ad-hoc.

19. Slashing rules

19.1 Principiu

Orice rol de consens poate fi slashed pentru comportament demonstrabil adversarial sau grav neglijent.

19.2 Slashing offenses — Proposers

Un proposer MAY fi slashed pentru:

• dublă propunere incompatibilă în același slot;
• producere repetată de blocuri structural invalide;
• cenzură demonstrabilă unde protocolul definește astfel de dovezi;
• falsificare de metadata de front.

19.3 Slashing offenses — Verifiers

Un verifier MAY fi slashed pentru:

• validare și invalidare simultană a aceluiași obiect;
• semnarea repetată a unor blocuri demonstrabil invalide;
• front approvals incompatibile.

19.4 Slashing offenses — Notaries

Un notary MAY fi slashed pentru:

• semnarea a două notarizări incompatibile pentru aceeași epocă;
• semnarea unei notarizări demonstrabil imposibil de reexecutat;
• participare frauduloasă în comitete false.

19.5 Slashing levels

Protocolul SHOULD distinge:

• minor fault
• major fault
• slashable Byzantine fault

și să aplice penalități proporționale.

19.6 Consequences

Slashing MAY produce:

• pierdere de stake;
• pierdere de bond;
• excludere temporară;
• excludere pe termen lung;
• pierdere a reward-urilor epocii.

20. Non-participation penalties

20.1 Scop

Nu doar acțiunile frauduloase sunt relevante. Absența repetată erodează liveness.

20.2 Penalizare

Protocolul SHOULD penaliza:

• proposers care nu produc bloc când sunt programați;
• verifiers care nu votează repetat;
• notaries care nu participă la finalizare fără motiv.

20.3 Distincție

Non-participation MUST fi penalizată mai puțin sever decât comportamentul byzantin demonstrat.

21. Network assumptions

21.1 Model

ENDC presupune:

• întârziere de rețea bounded în condiții normale;
• propagare rezonabilă între validatori eligibili;
• lipsa unei adversități peste pragul BFT proiectat.

21.2 Nu presupune

ENDC MUST NOT presupune:

• ceas perfect sincron;
• mempool identic la toate nodurile;
• ordini locale identice de recepție a mesajelor.

De aceea front selection-ul și notarizarea sunt separate de simpla ordine de sosire.

22. Finality semantics

22.1 Proprietate

Dacă două noduri oneste au acceptat aceeași EpochNotarization validă, ele MUST accepta aceeași stare finală pentru acea epocă.

22.2 Irreversibilitate

După finalitate, rollback-ul acelei epoci este permis numai prin:

• upgrade constituțional explicit;
• recovery protocol excepțional deja prevăzut;
• mecanism de guvernanță cu reguli mai puternice decât consensul normal.

În execuția standard, rollback-ul MUST NOT exista.

22.3 Dependențe

Orice aplicație, mașină sau agent care cere finalitate MUST ancora acțiunile pe EpochNotarization, nu pe blocuri soft.

23. Rejection of invalid notarizations

23.1 O notarizare este invalidă dacă:

• semnăturile nu ating pragul;
• comitetul notarilor este greșit;
• frontul selectat nu este compatibil;
• reexecutarea nu produce rădăcinile declarate;
• există semnături duplicate sau neeligibile;
• front commitment-ul nu corespunde blocurilor indicate.

23.2 Regula nodului

Un nod MUST respinge integral notarizarea invalidă. Nu există „finalitate parțială”.

24. Committee proofs

24.1 Necesitate

Pentru audit și light clients, protocolul MUST putea demonstra:

• cine era eligibil într-o epocă;
• cine a semnat;
• de ce comitetul este corect.

24.2 Formă

Protocolul SHOULD folosi:

• committee root
• membership proofs
• stake weight proofs
• signature bundles compacte

25. Light client finality verification

25.1 Obiectiv

Un client ușor MUST putea verifica finalitatea fără reexecutarea completă a rețelei.

25.2 Cerințe minime

Light client-ul SHOULD verifica:

• EpochNotarization
• membership proofs pentru semnatari
• threshold de stake/notaries
• consistency dintre front commitment și rădăcinile declarate
• eventuale fraud alerts relevante

25.3 Limită

Light client-ul nu garantează validitatea completă a execuției decât dacă protocolul oferă și validity proofs suplimentare.

26. Rewards

26.1 Principiu

Rewards SHOULD favoriza:

• participarea corectă;
• disponibilitatea;
• notarizarea validă;
• comportamentul previzibil;
• contribuția la finalitate.

26.2 Categorii

Rewards MAY fi împărțite între:

• proposers
• verifiers
• notaries
• treasury/recovery reserve

26.3 Condiție

Niciun actor slashed pentru fault major nu SHOULD primi reward integral pentru epoca respectivă.

27. Handling cross-epoch dependencies

27.1 Regula

Un bloc din epoca E+1 MAY referi rezultate soft din E numai dacă protocolul permite și dacă aceste dependențe sunt marcate explicit ca pre-finality.

27.2 Recomandare

Aplicațiile sensibile SHOULD ancora deciziile pe stări finalizate, nu pe dependențe cross-epoch soft.

27.3 Finality boundary

La finalizarea epocii E, orice stare dependentă compatibilă din E+1 MUST fi revalidată dacă era ancorată pe ipoteze soft.

28. Canonical conflict set

28.1 Definiție

Pentru o epocă, protocolul MAY produce un conflict_set care descrie:

• blocurile conflictuale;
• tranzacțiile conflictuale;
• motivele excluderii;
• fraud proofs asociate.

28.2 Scop

Conflict set-ul ajută:

• auditul;
• slashing;
• explicarea alegerii frontului;
• debug de rețea.

28.3 Cerință

Dacă este inclus, conflict_set_hash MUST fi derivat canonic.

29. Safety theorem target

29.1 Ținta formală

ENDC urmărește proprietatea:

Dacă pragul adversarial rămâne sub limita BFT și nodurile oneste acceptă doar notarizări valide, atunci două stări finale incompatibile pentru aceeași epocă nu pot fi acceptate de două mulțimi oneste diferite.

29.2 Observație

Demonstrația formală completă aparține unui document separat de analiză matematică, dar specificația trebuie să fie compatibilă cu această țintă.

30. Liveness theorem target

30.1 Ținta formală

ENDC urmărește proprietatea:

Dacă o fracțiune suficientă din stake-ul eligibil participă și rețeaua respectă ipotezele de latență proiectate, atunci fiecare epocă produce în cele din urmă o notarizare validă sau un rezultat deterministic de no-finality/recovery.

31. Message families

31.1 Tipuri minime de mesaje de consens

• PROPOSE_BLOCK
• VERIFY_BLOCK
• VERIFY_FRONT
• REPORT_FRAUD
• PREPARE_NOTARIZATION
• FINALIZE_EPOCH

31.2 Cerință

Toate mesajele de consens MUST avea:

• identificator derivat;
• epocă/round/slot clar;
• semnătură de rol;
• payload canonic;
• reguli clare de replay protection.

32. Replay protection

32.1 Principiu

Niciun mesaj de consens nu trebuie să fie reutilizabil valid în alt context temporal sau alt rol.

32.2 Reguli

Mesajele MUST include:

• epoch_index
• round_index sau slot_index
• role binding
• domain separation prefix

33. Genesis and epoch zero

33.1 Genesis

Genesis MUST defini:

• validator set inițial;
• stake snapshot inițial;
• seed inițial;
• parametrii ENDC;
• finality threshold;
• slashing baseline.

33.2 Prima finalizare

Pentru epoch zero, protocolul MUST defini explicit dacă:

• finalitatea începe din epoca 0;
• sau epoca 0 este doar bootstrap pentru epoca 1.

34. Parameter upgrades

34.1 Parametri upgradabili

Protocolul MAY permite upgrade pentru:

• durata slotului;
• mărimea comitetelor;
• praguri de finalitate;
• ponderi în scoring;
• penalties și rewards.

34.2 Parametri cvasi-constituționali

Protocolul SHOULD trata drept greu modificabili:

• separarea rolurilor;
• necesitatea notarizării;
• interdicția finalității fără reexecutabilitate;
• condițiile de slashing pentru double-signing.

35. Failure examples

35.1 Double proposal

Același proposer emite două blocuri incompatibile pentru același slot. Rezultat:

• ambele sunt marcate conflictuale;
• fraud proof poate declanșa slashing;
• niciun avantaj nu trebuie obținut din ambiguitate.

35.2 Invalid front notarized

Un subset de notaries semnează un front nereexecutabil. Rezultat:

• notarizarea este invalidă;
• semnatarii pot fi slashed;
• nodurile oneste o resping.

35.3 Epoch timeout

Nu se atinge pragul de finalizare. Rezultat:

• epoca intră în NO_FINALITY sau recovery;
• sistemul continuă deterministic;
• nu inventează finalitate.

36. Deterministic local algorithm

36.1 Algoritm abstract per nod

For epoch E:
  derive committees(E)
  accept candidate blocks for E
  validate blocks and emit verifier signals
  build compatible candidate fronts
  compute FrontScore for each admissible front
  select best front F*
  if local node is notary and threshold coordination succeeds:
      sign EpochNotarization(E, F*)
  accept finality only when notarization threshold is met and reexecution matches

36.2 Cerință

Orice optimizare de implementare MUST păstra exact aceeași semantică observabilă.

37. Relația cu AZ-003

ENDC nu schimbă validitatea tranzacțiilor. ENDC decide:

• ce subset conflictual ajunge în frontul final;
• când devine acel subset final;
• cine răspunde pentru semnarea sa.

Cu alte cuvinte:

• AZ-003 decide valid / invalid;
• AZ-004 decide final / not final.

38. What ENDC is not

ENDC MUST NOT fi:

• longest-chain heuristic;
• finalitate bazată doar pe probabilitate de adâncime;
• sistem în care primul bloc văzut decide adevărul;
• sistem în care notarizarea poate ignora reexecutarea;
• sistem în care conflictele sunt rezolvate prin arbitraj manual.

39. Formula de consens

ENDC = DAG limitat pentru includere + verificare stake-weighted + selecție deterministică a frontului + notarizare de epocă + hard finality reexecutabilă

40. Ce urmează

După AZ-004, documentul corect este:

AZ-005 — Contract Language and Bounded Virtual Machine Specification

Acolo trebuie definit:

• limbajul de contracte;
• modelul de efecte;
• bytecode-ul;
• exec units;
• accesul la stare;
• restricțiile care fac mașinile bounded și auditabile.

Închidere

ENDC nu tratează rețeaua ca pe un șir unic de blocuri, ci ca pe un spațiu temporar de posibilități conflictuale din care, la fiecare epocă, este extras un singur front compatibil, reexecutabil și notarizat.

Acolo începe finalitatea reală.