AZ-010 — Security Assumptions, Threat Model, Failure Domains, and Verification Strategy v1

Status

Acest document definește modelul de securitate al ATLAS ZERO.

Scopul lui nu este să pretindă securitate absolută. Scopul lui este să fixeze explicit:

ce presupunem despre sistem;
ce adversari modelăm;
unde pot apărea defecte și eșecuri;
ce proprietăți vrem să demonstrăm;
cum verificăm practic că protocolul este suficient de sigur pentru lansare.

Acest document se bazează pe:

AZ-002 pentru structuri canonice;
AZ-003 pentru validare și tranziții de stare;
AZ-004 pentru consens și finalitate;
AZ-005 pentru BVM;
AZ-006 pentru witness/proof/attestation;
AZ-007 pentru economie și slashing;
AZ-008 pentru agenți;
AZ-009 pentru constituția guvernanței.

Termeni:

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

1. Obiectiv

AZ-010 răspunde la 10 întrebări de securitate:

Ce presupuneri minime face protocolul?
Ce adversari modelăm?
Care sunt proprietățile de siguranță critice?
Care sunt proprietățile de liveness critice?
Care sunt domeniile principale de eșec?
Ce atacuri sunt în scope și ce atacuri rămân în afara scope-ului?
Cum se compun riscurile între consens, VM, economie, witness și agenți?
Ce înseamnă „suficient de sigur” pentru testnet și mainnet?
Cum se verifică implementarea?
Cum se tratează incertitudinea, bugurile și modelele incomplete?

2. Principii de securitate

2.1 Explicit assumptions

Protocolul MUST își declare presupunerile. Securitatea care depinde de presupuneri ascunse nu este securitate serioasă.

2.2 Security by boundedness

ATLAS ZERO urmărește să reducă suprafața de atac prin:

bounded state;
bounded effects;
bounded governance;
bounded agent authority;
explicit memory semantics;
priced persistence.

2.3 No security by obscurity

Protocolul MUST NOT depinde de:

secrete de implementare;
„dacă atacatorul nu se uită”;
lipsa de interes a adversarilor;
toolchains opace.

2.4 Layered defense

Securitatea SHOULD exista pe mai multe straturi:

consens;
validare;
VM;
economie;
witness;
agent control;
guvernanță;
operațiuni.

2.5 Fail explicit

Când nu putem garanta siguranța, sistemul SHOULD:

refuza acțiunea;
intra în safe mode;
intra în halt;
intra în recovery; nu să continue ambiguu.

3. Security goals

3.1 Core safety goals

ATLAS ZERO urmărește aceste proprietăți centrale:

State integrity
stări diferite incompatibile nu trebuie acceptate simultan ca finale în condițiile de securitate presupuse.
Deterministic execution
aceleași inputuri și aceeași stare trebuie să producă același rezultat.
Conservation and bounded loss
valoarea nu trebuie creată sau distrusă în afara regulilor explicite; mașinile bounded nu trebuie să depășească envelope-urile declarate.
Authorization soundness
nicio acțiune nu trebuie să treacă fără policy satisfăcută.
Witness soundness
witnessurile și proof-urile folosite normativ trebuie să fie valide, în scope și în timp.
Agent control soundness
agenții nu trebuie să poată acționa dincolo de mandat.
Governance boundedness
guvernanța nu trebuie să poată ocoli ușor fundamentele de siguranță.

3.2 Core liveness goals

Protocolul urmărește și:

finalizarea continuă a epocilor în ipotezele proiectate;
posibilitatea de recovery după fault-uri majore;
posibilitatea de halt sigur pentru subsisteme compromise.

4. Assumption classes

4.1 Cryptographic assumptions

Protocolul presupune că:

funcțiile hash folosite sunt rezistente la coliziuni și preimage în parametrii aleși;
schemele de semnătură sunt rezistente la falsificare în modelul standard relevant;
schemele de aggregated signatures, dacă sunt folosite, sunt corect implementate și securizate;
schemele ZK, dacă sunt folosite, sunt sound în parametrii aleși.

4.2 Network assumptions

Protocolul presupune:

rețeaua are latență bounded în condiții normale;
există suficientă conectivitate între nodurile oneste eligibile;
adversarul nu controlează permanent și complet propagarea între toate nodurile oneste;
timestamp drift rămâne în toleranțele proiectate.

4.3 Economic assumptions

Protocolul presupune:

stake-ul și bond-urile slashable sunt suficient de valoroase încât fault-ul să fie costisitor;
actorii economici reacționează parțial la penalități și rewards;
sistemul de fee/rent nu permite spam persistent extrem de ieftin;
participanții critici nu pot ieși instant din stake înainte de detectarea fault-ului.

4.4 Operational assumptions

Protocolul presupune:

cheile rolurilor critice sunt gestionate rezonabil;
implementările majore nu sunt compromise masiv simultan;
operatorii urmează proceduri minime de securitate;
comitetele și rolurile sunt configurate conform specificației.

4.5 Human/governance assumptions

Protocolul presupune:

procesele de review și emergency nu sunt complet capturate;
actorii de guvernanță nu pot ocoli instant constituția prin procedural abuse;
suficienți participanți observă și contestă schimbări nocive în ferestrele de challenge.

5. Threat model overview

5.1 Adversary categories

Modelăm cel puțin următorii adversari:

external network attacker
malicious proposer
malicious verifier
malicious notary
colluding validator cartel
malicious contract deployer
malicious witness issuer / oracle
malicious or compromised agent operator
economically rational spammer
governance manipulator
compromised implementation vendor
privileged insider

5.2 Adversary capabilities

În funcție de clasă, adversarul MAY:

întârzie mesaje;
eclipseze parțial noduri;
producă blocuri sau voturi invalide;
emită atestări false;
încerce double-signing;
spameze mempool și starea;
abuzeze complexitatea VM;
manipuleze governance timing;
exfiltreze chei sau abuzeze de configurații.

5.3 Non-omniscient model

Protocolul nu presupune adversar omnipotent. Dar SHOULD modela adversari capabili, coordonați și motivați economic.

6. Trust boundaries

6.1 Protocol core boundary

Acest boundary include:

regulile de validare;
consensul ENDC;
BVM semantics;
canonical encoding/hashing;
economic rules active;
governance activation rules.

6.2 Off-chain boundary

În afara boundary-ului direct de consens se află:

wallet UI;
explorer tooling;
operator infrastructure;
market data ingestion;
logging aggregation;
recovery coordination tooling.

6.3 Rule

Tot ce trece granița dintre off-chain și on-chain MUST fi ancorat prin obiecte canonice dacă devine normativ.

7. Safety assumptions for consensus

7.1 Honest threshold assumption

ENDC presupune că proporția sau greutatea actorilor byzantini rămâne sub pragul de securitate proiectat.

7.2 Committee correctness assumption

Selecția de comitete trebuie să fie corectă și reconstructibilă. Dacă selecția comitetului este coruptă, consensul este compromis.

7.3 Reexecution assumption

Nodurile oneste verifică reexecutabilitatea înainte de a accepta notarizarea. Dacă acceptă notarizare fără reexecutare, finalitatea poate deveni falsă.

7.4 Slashing enforceability assumption

Double-signing și notarizările conflictuale trebuie să fie detectabile și slashabile într-o fereastră suficientă.

8. Safety assumptions for BVM

8.1 Deterministic runtime assumption

Implementările BVM diferite trebuie să păstreze aceeași semantică observabilă.

8.2 Static analysis soundness assumption

Manifestul și verificatorul static nu trebuie să accepte programe nebounded ca și cum ar fi bounded.

8.3 Host isolation assumption

Host interface nu trebuie să permită acces la surse nondeterministe sau efecte nedeclarate.

8.4 Versioning assumption

Schimbările de VM trebuie versionate astfel încât bytecode vechi să nu capete semantică ambiguă.

9. Safety assumptions for Witness Layer

9.1 Issuer policy correctness

Issuer policies trebuie să fie corecte și verificabile.

9.2 Proof verifier correctness

Verificatorii pentru proof_type trebuie să fie corecți și identici semantic între implementări.

9.3 Freshness and revocation correctness

Revocarea, supersession și TTL trebuie aplicate identic de toate nodurile.

9.4 No hidden semantics assumption

Tipurile de witness nu trebuie să aibă sensuri „sociale” suplimentare față de standardul protocolar.

10. Safety assumptions for agents

10.1 Mandate integrity

Mandatele trebuie să fie corecte, active și evaluate consistent.

10.2 Journaling integrity

Jurnalizarea obligatorie trebuie să fie verificabilă și să nu poată fi eludată fără efect normativ.

10.3 Cap enforcement

Expunerile agregate și cap-urile trebuie măsurate corect. Caps doar „estimate local” fără ancorare relevantă sunt insuficiente.

10.4 Operator compromise assumption

Compromiterea operatorului este în scope. Protocolul trebuie să permită halt, revoke și rotate.

11. Threats in scope

11.1 Consensus threats

double proposal
double notarization
conflicting verifier approvals
committee equivocation
front selection manipulation
block withholding / selective inclusion
no-finality griefing
partial eclipse around committee members

11.2 Execution threats

nondeterministic VM behavior
integer overflow / underflow bugs
out-of-bounds memory paths
effect bound bypass
loss envelope bypass
malformed bytecode acceptance
host call abuse

11.3 State threats

double spend
stale machine state reuse
replay of expired/revoked witness
invalid reference acceptance
state root mismatch
storage bloat attack

11.4 Witness/oracle threats

contradictory oracle claims
stale but apparently valid data
replay cross-context
unauthorized revocation
forged attestation
quorum fraud in committees

11.5 Agent threats

execution beyond mandate
fake logs
omission of required logs
cap evasion through fragmentation
operator-key takeover
acting after revoke or halt

11.6 Governance threats

hidden structural change in economic proposal
emergency power abuse
rushed activation
chamber capture
challenge window bypass
retroactive semantic reinterpretation

11.7 Economic threats

cheap intent spam
cheap witness spam
rent underpricing
slash-evading fast exit
manipulation of congestion pricing
proposer-dominated fee extraction

12. Threats partly in scope but only mitigated, not eliminated

12.1 MEV-like extraction

Batch clearing reduce anumite forme de extractable value, dar nu garantează eliminare completă.

12.2 Data/oracle corruption

Protocolul poate cere corroboration, bonds și TTL. Nu poate garanta adevărul lumii externe fără surse bune.

12.3 Operator incompetence

Protocolul poate limita damage și cere journaling, dar nu elimină erorile umane operaționale.

12.4 Governance social capture

Constituția și camerele reduc riscul, dar nu elimină complet capturarea politică pe termen lung.

13. Threats explicitly out of scope

13.1 Perfect endpoint security

Protocolul nu poate garanta securitatea dispozitivului fiecărui utilizator/operator.

13.2 Perfect legal/jurisdictional safety

Protocolul nu garantează conformitatea legală universală.

13.3 Perfect market truth

Protocolul nu poate ști „prețul adevărat” al activelor fără surse externe bune.

13.4 Omnipotent adversary

Dacă adversarul controlează peste pragul de securitate relevant, plus rețeaua, plus implementările, protocolul poate eșua.

13.5 Catastrophic cryptographic break

Dacă schemele criptografice fundamentale se rup, modelul de securitate de bază cade.

14. Failure domains

14.1 Consensus failure domain

Apare dacă:

comitetele sunt corupte;
notaries dublează semnături;
reexecutarea e ocolită;
committee selection este compromis.

Impact:

finalitate conflictuală;
liveness scăzut;
recovery dificil.

14.2 Validation failure domain

Apare dacă:

noduri diferite validează diferit;
canonical encoding nu este uniformă;
error precedence sau semantics diverge;
references sunt tratate diferit.

Impact:

chain split logic;
inconsistent receipts;
incompatibilitate de noduri.

14.3 VM failure domain

Apare dacă:

runtime-urile diferă;
static checker acceptă cod interzis;
bytecode verifier are bug;
exec cost nu este identic.

Impact:

non-determinism;
state divergence;
exploatarea bounds.

14.4 Witness failure domain

Apare dacă:

revocarea nu e tratată consistent;
proof verifier greșește;
semantics sunt ambigue;
issuer policies sunt slabe.

Impact:

approvals false;
settlement fals;
agenți cu mandat fals.

14.5 Economic failure domain

Apare dacă:

fee/rent sunt prea mici;
bond-urile sunt insuficiente;
rewards distorsionează comportamentul;
no-finality nu este penalizată corect.

Impact:

spam;
atacuri ieftine;
degradare progresivă.

14.6 Agent failure domain

Apare dacă:

caps nu sunt agregate corect;
journaling este opțional unde nu ar trebui;
operator compromise nu poate fi oprit rapid.

Impact:

pierderi locale mari;
comportament neauditat;
trust erosion.

14.7 Governance failure domain

Apare dacă:

emergency powers sunt prea largi;
challenge windows sunt inutile;
proposal classes sunt prost separate;
constitutional review e doar formal.

Impact:

protocol drift;
political override;
distrugerea predictibilității.

15. Security properties by layer

15.1 Value Layer properties

no unauthorized spend
no double spend in final state
per-asset conservation
policy satisfaction
timelock correctness

15.2 Logic Layer properties

deterministic machine transition
state bound respected
effect bound respected
loss envelope respected
no hidden side effects

15.3 Witness Layer properties

valid issuer authorization
proof validity
no unauthorized reuse
revocation and expiry soundness
statement semantic clarity

15.4 Agent Layer properties

mandate soundness
cap enforcement
journaling continuity
halt/revoke effectiveness
no action after terminal mandate state

15.5 Governance Layer properties

classified changes only
required review respected
timelock respected
constitutional inadmissibility blocks activation
emergency restriction bounded and expiring

16. Security invariants

Aceste invariants SHOULD fi tratate ca obiective formale de verificare:

două notarizări incompatibile pentru aceeași epocă nu pot fi acceptate simultan de două noduri oneste în modelul de securitate proiectat;
aceeași tranzacție și aceeași stare dau același rezultat;
niciun contract valid nu poate produce efecte în afara permission_surface;
nicio mașină bounded nu poate depăși loss_envelope fără invalidare;
niciun witness expirat/revocat nu satisface o condiție normativă;
niciun agent nu poate acționa valid în afara mandatului activ;
nicio schimbare structurală/constituțională nu devine activă fără procedura corespunzătoare;
nicio stare hard-finală nu este rescrisă de execuția normală.

17. Composed attack scenarios

17.1 Consensus + governance attack

Adversarul încearcă:

să creeze no-finality repetat;
apoi să forțeze emergency power larg;
apoi să introducă schimbare structurală rapidă.

Mitigări:

emergency powers limitative only;
expiry obligatorie;
review post-activare;
constitutional separation.

17.2 Oracle + agent attack

Adversarul:

livrează oracle data stale dar formal semnată;
agentul execută în mandat aparent valid.

Mitigări:

freshness caps;
corroboration;
journaling;
exit-only / auto-halt.

17.3 VM + economic attack

Adversarul:

găsește cale de cost disproporționat față de exec units;
produce block validation DoS.

Mitigări:

cost model conservator;
bounded loops;
fuzzing și gas grief tests;
per-object admission caps.

17.4 Witness + governance semantic attack

Adversarul:

redefinește subtil semantics ale unui statement type prin upgrade „minor”.

Mitigări:

versioning clar;
review constituțional;
incompatibility analysis;
no retroactive semantics.

18. Denial-of-service threat model

18.1 Network DoS

Atacatorul încearcă să blocheze propagarea. Mitigări:

DAG limitat;
slot/epoch windows;
committee redundancy;
conservative admission.

18.2 Validation DoS

Atacatorul trimite obiecte aproape valide dar costisitoare. Mitigări:

phased validation;
strict size bounds;
canonical decoding early reject;
fee floor.

18.3 VM DoS

Atacatorul trimite machine calls maxime. Mitigări:

bounded exec units;
static bounds;
capability pricing;
per-block/resource caps.

18.4 Witness/Proof DoS

Atacatorul trimite proof bundles mari sau complexe. Mitigări:

proof size limits;
proof type whitelists;
verification fee;
retention fee.

18.5 Governance DoS

Atacatorul flood-ează propuneri sau challenge-uri. Mitigări:

proposal bonds;
class-based admission;
bounded review queues;
governance fees.

19. Key compromise threat model

19.1 Classes

user wallet key compromise
validator role key compromise
notary key compromise
oracle key compromise
agent operator key compromise
governance signer compromise

19.2 Required responses

Protocolul SHOULD susține:

rotation;
revoke;
quarantine;
halt;
reduced-scope recovery;
audit trail.

19.3 Principle

Compromiterea unei chei nu trebuie să implice automat compromiterea întregului sistem dacă separarea rolurilor și rotation paths există.

20. Supply chain and implementation threat model

20.1 Scope

Atacuri relevante:

compiler bug
verifier bug
divergent serialization library
node implementation mismatch
malicious dependency
operator misconfiguration
hardware/OS nondeterminism leaks

20.2 Mitigations

multiple independent implementations where feasible;
consensus test vectors;
canonical serialization conformance suites;
reproducible builds;
code hashing;
differential testing.

20.3 Rule

Securitatea protocolului MUST include și securitatea toolchain-ului relevant, nu doar specificația ideală.

21. Formal verification targets

21.1 Consensus targets

SHOULD exista modele sau dovezi pentru:

safety under threshold assumptions;
liveness under bounded delay assumptions;
slashing soundness for double-signing.

21.2 VM targets

SHOULD exista dovezi sau verificări pentru:

determinism;
no out-of-bounds state mutation;
bounded execution;
effect soundness.

21.3 Validation targets

SHOULD exista proprietăți pentru:

canonical encoding uniqueness;
invariant preservation;
conservation;
reference and policy correctness.

21.4 Governance targets

SHOULD exista verificări pentru:

class-appropriate activation paths;
timelock enforcement;
constitutional admissibility gates.

22. Testing strategy layers

22.1 Unit testing

Obligatoriu pentru:

hash derivation
serialization
policy evaluation
proof verification
effect accounting
fee/rent math
cap enforcement

22.2 Property-based testing

Obligatoriu sau puternic recomandat pentru:

transaction invariants
state transitions
witness lifecycle
mandate lifecycle
upgrade activation logic

22.3 Differential testing

Necesar între:

independent node implementations
independent BVM runtimes
reference and optimized verifiers

22.4 Fuzzing

Necesar pentru:

decoders
proof parsers
bytecode verifier
VM runtime
mempool admission
governance objects

22.5 Adversarial simulation

Necesar pentru:

committee faults
network partitions
delayed propagation
no-finality epochs
oracle divergence
agent compromise
governance abuse scenarios

23. Security review pipeline

23.1 Before testnet

Trebuie să existe:

internal spec review
conformance suite
invariant checklist
fuzzing baseline
threat model review
dangerous feature disable-by-default list

23.2 Before public testnet

Trebuie să existe în plus:

external review on consensus/VM
economic abuse simulation
incident response draft
key rotation and halt drills

23.3 Before mainnet

Trebuie să existe în plus:

at least one deep external audit on consensus/core validation;
audit on BVM and bytecode verifier;
audit on witness/proof critical types;
governance and emergency path review;
bug bounty;
formal artifacts or strong model checking for the most critical invariants;
disaster recovery exercises.

24. Security severity classes

24.1 Critical

Poate duce la:

false finality;
unauthorized value movement;
deterministic split;
bypass of mandate or governance constitution;
unbounded VM exploit.

24.2 High

Poate duce la:

bounded but serious loss;
repeated no-finality;
witness/oracle misuse affecting critical flows;
major DoS.

24.3 Medium

Poate duce la:

degraded liveness;
partial service denial;
audit trail failure;
limited policy bypass.

24.4 Low

Cosmetic, observability or non-critical tooling issues.

24.5 Rule

Mainnet readiness MUST require zero known criticals and a controlled posture on highs.

25. Mainnet security gates

25.1 Mandatory gates

Mainnet SHOULD NOT launch unless:

no known unresolved critical consensus bugs;
no known unresolved deterministic divergence bugs;
no known unresolved authorization bypasses;
no known unresolved boundedness bypass in BVM;
emergency halt/recovery path has been exercised;
key rotation paths have been exercised;
governance activation and challenge paths have been tested;
slashing and fraud proof flows have been tested end-to-end;
conformance suite passes across supported implementations;
economic spam simulations are acceptable.

25.2 Additional gate

At least one independent security review SHOULD explicitly confirm that assumptions and implementation align.

26. Testnet security posture

26.1 Goal

Testnet nu trebuie să fie perfect sigur. Trebuie să fie:

instrumentat;
bounded;
capabil să expună defecte;
suficient de protejat încât testele să fie relevante.

26.2 Allowed on testnet

reduced bonds;
simplified economics;
lower-value assumptions;
selected features behind flags.

26.3 Not allowed even on serious testnet

hidden nondeterminism;
absent slashing path for obvious consensus faults;
no halt/recovery plan;
inability to distinguish final from soft state.

27. Incident classes

27.1 Consensus incident

Exemple:

conflicting notarization observed
deterministic split
persistent no-finality

27.2 Execution incident

Exemple:

BVM divergence
effect bound bypass
loss envelope bypass

27.3 Witness incident

Exemple:

invalid revocation accepted
oracle contradiction not detected
false settlement confirmation path

27.4 Agent incident

Exemple:

action outside mandate validated
mandatory journaling missing but accepted
halt ineffective

27.5 Governance incident

Exemple:

activation before timelock
emergency action without expiry
constitutional inadmissible change activated

28. Incident response philosophy

28.1 First principle

Incidentele critice nu trebuie „argumentate”. Trebuie:

detectate;
clasificate;
limitate;
comunicate;
tratate prin mecanisme deja definite.

28.2 Response ladder

detect
confirm
scope
contain
safe mode or halt if needed
emergency restriction if constitutionally allowed
recovery plan
postmortem
patch / upgrade
re-enable cautiously

28.3 Rule

Response paths SHOULD fi exersate înainte de mainnet.

29. Safe mode and halt strategy

29.1 Motivation

Nu toate incidentele trebuie să ducă la stop total. Uneori este suficient:

safe mode;
exit-only;
feature freeze;
issuer quarantine.

29.2 Rule

Sistemele sensibile SHOULD avea moduri graduale de degradare controlată, nu doar pornit/oprit.

30. Security telemetry

30.1 Need

Operațiunile au nevoie de semnale timpurii.

30.2 Examples

rising invalid block rate
repeated committee conflicts
witness contradiction spikes
abnormal proof failure rate
agent journaling omissions
abnormal no-finality frequency
cap breach near-miss events
governance proposal anomaly patterns

30.3 Rule

Telemetry off-chain MAY exista, dar semnalele normative critice SHOULD avea posibilitatea de ancorare protocolară prin witness/event dacă este necesar.

31. Residual risk model

31.1 Principle

După toate verificările, rămâne întotdeauna risc rezidual:

bug necunoscut;
model incomplet;
adversar social;
degradare lentă economică;
supply chain compromise.

31.2 Rule

Mainnet readiness nu înseamnă risc zero. Înseamnă:

risc înțeles;
risc măsurat;
mitigări pregătite;
recovery posibil;
cost al fault-ului redus.

32. Security posture by maturity stage

32.1 Prototype stage

Accent pe:

correctness of ideas
deterministic cores
simplification
threat inventory

32.2 Internal testnet

Accent pe:

conformance
fuzzing
failure discovery
operational drills

32.3 Public testnet

Accent pe:

adversarial exposure
ecosystem integration
economic attack discovery
governance rehearsal

32.4 Mainnet phase 1

Accent pe:

conservative parameters
feature restrictions
strong telemetry
rapid safe-mode capability

32.5 Mature mainnet

Accent pe:

broader decentralization
stricter external assurance
parameter optimization
controlled feature expansion

33. Verification matrix

33.1 Matrix concept

Fiecare subsistem SHOULD avea o matrice:

assumptions
invariants
tests
audits
formal proofs
runbooks
emergency hooks

33.2 Example dimensions

consensus
validation
BVM
witness/proof
economics
agents
governance
tooling

34. Attack-cost reasoning

34.1 Principle

Pentru anumite clase de atac, protocolul SHOULD estima:

costul adversarului;
beneficiul potențial;
detectabilitatea;
latența slashing/recovery;
blast radius-ul.

34.2 Goal

Ideal, atacurile grave trebuie să fie:

foarte costisitoare;
detectabile;
limitabile;
reputațional și economic dureroase.

35. Blast radius control

35.1 Need

Nu putem garanta absența completă a bugurilor. Putem controla cât de mult rău poate produce un bug.

35.2 Mechanisms

bounded VM
loss envelopes
capability tiers
mandate caps
safe mode
scoped halts
time delays
multi-chamber governance
rent and fee throttles

35.3 Goal

Bugurile locale SHOULD rămâne locale cât mai mult posibil.

36. Canonical security checklist before enabling a feature

Orice feature nou SHOULD răspunde clar la:

ce obiecte noi introduce?
ce invariants noi introduce?
ce poate merge prost?
cum se oprește?
ce bonds/fees/rent adaugă?
cum afectează finalitatea și determinismul?
cum se testează?
ce review constituțional/economic necesită?
ce telemetry produce?
cum se dezactivează dacă devine periculos?

37. Formal threat inventory by subsystem

37.1 Consensus

equivocation
partition
quorum failure
non-deterministic front selection
invalid notarization acceptance

37.2 Validation

canonicalization mismatch
ref resolution mismatch
expiration/revocation mismatch
policy ambiguity
state transition mismatch

37.3 BVM

verifier acceptance mismatch
hidden host dependency
instruction semantics mismatch
boundedness proof unsoundness
cost model underestimation

37.4 Witness/Proof

proof parser bug
replay context omission
statement semantics ambiguity
stale proof acceptance
revocation race

37.5 Economics

underpriced persistence
underbonded issuers
slash non-enforcement
perverse reward incentive
spam externality

37.6 Agents

cap fragmentation
role conflation
journaling bypass
compromised operator persistence
stale mandate caches

37.7 Governance

class mislabeling
hidden changeset
emergency sprawl
challenge suppression
semantic retroactivity

38. Security formula

Security posture = explicit assumptions + bounded components + deterministic validation + priced abuse + slashable authority + constrained governance + tested recovery

39. Relația cu restul suitei

AZ-002 a fixat obiectele.
AZ-003 a fixat validarea și tranzițiile.
AZ-004 a fixat finalitatea.
AZ-005 a limitat execuția.
AZ-006 a limitat memoria normativă.
AZ-007 a legat securitatea de cost economic.
AZ-008 a limitat agenții.
AZ-009 a limitat guvernanța.
AZ-010 fixează explicit ce înseamnă să credem că toate acestea sunt suficient de sigure.

40. Ce urmează

După AZ-010, pașii corecți nu mai sunt doar încă un document narativ.

Următoarele artefacte serioase sunt:

AZ-011 — Conformance Test Vectors and Canonical Examples
AZ-012 — Reference Node Architecture
AZ-013 — BVM Bytecode and Opcode Tables
AZ-014 — Fraud Proof and Slashing Evidence Formats
AZ-015 — Incident Response and Recovery Runbooks
AZ-016 — Genesis Specification
AZ-017 — Mainnet Readiness Checklist

Închidere

Un protocol devine periculos atunci când vorbește despre inovație, dar nu spune clar în ce condiții se poate rupe.

ATLAS ZERO trebuie să facă opusul: să numească explicit presupunerile, adversarii, limitele și mecanismele de verificare, astfel încât siguranța să nu fie o promisiune vagă, ci o disciplină verificabilă.

Acolo începe maturitatea reală a securității.