ATLAS ZERO — Protocol Skeleton v1

Status

Acest document transformă conceptul fondator într-o specificație de nivel protocol. Nu este încă whitepaper matematic complet și nu este cod. Este forma în care fantezia devine arhitectură implementabilă.

1. Obiectiv

ATLAS ZERO este o rețea cu trei straturi native:

Value Layer — valoare transferată prin obiecte finite și auditabile;
Logic Layer — mașini de stare limitate, cu efecte și risc plafonate;
Witness Layer — memorie verificabilă, atestări și jurnale semnate.

Rețeaua urmărește 5 proprietăți:

finalitate rapidă și clară;
execuție deterministă și analizabilă;
risc maxim declarabil și verificabil;
memorie utilă pentru oameni și agenți;
compatibilitate nativă cu acțiuni automate controlate.

2. Primitivele fundamentale

2.1 Cell

Cell este unitatea de valoare de bază.

O Cell are:

cell_id
asset_id
amount
owner_policy
spend_policy
expiry_policy
metadata_hash
origin_ref

Semnificație

owner_policy definește cine are drept legitim asupra valorii;
spend_policy definește condițiile concrete de consum;
expiry_policy definește ce se întâmplă dacă nu este consumată până la momentul T;
metadata_hash permite atașare minimă de context fără a umfla starea globală;
origin_ref leagă Cell-ul de sursa sa criptografică.

Proprietăți obligatorii

o Cell nu poate fi cheltuită decât o singură dată;
suma valorii din outputs nu poate depăși suma valorii din inputs minus taxe;
o Cell nu poate deveni „parțial ambiguă” între două stări notarizate;
orice Cell consumată trebuie să aibă dovada completă a politicii de cheltuire.

2.2 Bounded Machine

Bounded Machine este unitatea de logică programabilă.

Are:

machine_id
machine_code_hash
state_root
state_bound
effect_bound
loss_envelope
permission_surface
upgrade_policy
halt_policy

Semnificație

state_bound = limita maximă de stare persistentă;
effect_bound = limita explicită a efectelor pe tranzacție sau epocă;
loss_envelope = pierderea maximă posibilă conform designului declarat;
permission_surface = ce tipuri de active / calls / witnessuri poate consuma sau emite;
upgrade_policy = dacă și cum poate fi modificată logica;
halt_policy = condiții de oprire de urgență.

Principiu

O Bounded Machine nu poate produce efecte care nu sunt declarate în permisiunile și limitele sale. Dacă o tranzacție ar depăși limitele, ea este invalidă chiar dacă logic „ar avea sens”.

2.3 Witness Record

Witness Record este unitatea de memorie verificabilă.

Conține:

witness_id
subject_ref
issuer_policy
statement_type
statement_hash
proof_bundle_ref
timestamp
ttl
revocation_policy
visibility_class

Exemple de statement_type

approval
attestation
execution_log
risk_ack
oracle_claim
committee_vote
agent_action
settlement_confirmation

Proprietăți

Witness Record nu transferă direct valoare;
poate fi cerut de o politică de cheltuire sau de o mașină;
poate expira;
poate avea reguli clare de revocare;
poate fi public, restricționat sau doar hash-anonimizat.

2.4 Intent

Intent este cererea declarativă de execuție.

Conține:

intent_id
creator_policy
target_domain
action_type
constraints
risk_limit
time_window
acceptable_routes
required_witnesses
max_fee
cancel_policy

Ideea

Utilizatorul nu descrie doar pașii. Descrie și ce condiții trebuie respectate. Rețeaua, executorii și motoarele de clearing rezolvă intentul în cadrul acestor limite.

3. Straturile protocolului

3.1 Value Layer

Rol:

emitere de transferuri;
conservarea valorii;
escrow simplu;
politici de cheltuire.

Nu execută:

bucle arbitrare;
logică complexă de piață;
memorie persistentă grea.

Tranzacții valide în Value Layer

transfer simplu
split / merge
timelock spend
covenant spend
escrow release
mint / burn autorizat pentru active suportate

3.2 Logic Layer

Rol:

găzduiește Bounded Machines;
validează tranziții de stare;
impune limite de risc și efect;
emite Cells și Witness Records ca rezultat controlat.

Nu permite:

stare nelimitată;
recursivitate necontrolată;
efecte ascunse;
consum de resurse neanunțat.

Tipuri de aplicații

escrow programabil
vault
lending cu envelope fixă
AMM cu expunere limitată
auction / RFQ
treasury governance
orchestration pentru agenți

3.3 Witness Layer

Rol:

memorie verificabilă;
aprobări și dovezi;
reputație pseudonimă;
audit pentru execuție automată.

Acest strat este critic pentru:

agenți;
procese multi-step;
guvernanță;
atestări de risc;
oracle accountability.

4. Tipuri de tranzacții

4.1 TX_VALUE_TRANSFER

Consumă Cells și creează Cells noi.

4.2 TX_MACHINE_DEPLOY

Înregistrează o Bounded Machine nouă. Necesită:

hash cod
descriere limite
loss envelope
policy surface
upgrade policy
cost de stocare

4.3 TX_MACHINE_CALL

Invocă o tranziție într-o Bounded Machine. Trebuie să specifice:

metoda
input hash
consum maxim de resurse
efecte declarate
witnessuri atașate
limită de fee

4.4 TX_WITNESS_EMIT

Publică un Witness Record semnat și valid.

4.5 TX_INTENT_SUBMIT

Înregistrează un intent pentru clearing.

4.6 TX_INTENT_CANCEL

Anulează intentul în condițiile declarate.

4.7 TX_EPOCH_NOTARIZE

Sigilează frontul de stare valid pentru epocă.

4.8 TX_GUARD_HALT

Oprește o mașină sau un domeniu logic dacă politicile permit.

5. Invariants globale

Aceste reguli trebuie să fie adevărate mereu.

5.1 Conservarea valorii

Pentru orice activ conservativ: sum(inputs) >= sum(outputs) + fees + burns_declared

5.2 Unicitatea consumului

Nicio Cell nu poate fi consumată de două ori în stări notarizate compatibile.

5.3 Limita de stare

Nicio Bounded Machine nu poate depăși state_bound.

5.4 Limita de efect

Nicio tranziție nu poate produce efecte în afara effect_bound.

5.5 Plicul de pierdere

Nicio stare validă nu poate permite pierdere peste loss_envelope, conform modelului declarat.

5.6 Determinism

Aceeași stare + același input + aceleași witnessuri valide => același rezultat.

5.7 Finalitate

După notarizare de epocă, frontul sigilat nu poate fi înlocuit fără cost economic catastrofal și invalidare criptografică.

5.8 Jurnalizare

Orice acțiune automată executată de un agent delegat trebuie să poată emite sau referi cel puțin un Witness Record verificabil.

6. Modelul de consens — ENDC

6.1 Obiectiv

Consensul trebuie să permită:

latență mică pentru includere;
finalitate scurtă și clară;
audit ușor;
rezistență la propunători rău intenționați.

6.2 Roluri

Într-o epocă există trei roluri:

Proposers
Verifiers
Notaries

Proposers

Produc blocuri sau micro-blocuri.

Verifiers

Execută validarea de protocol:

validitatea tranzacțiilor;
compatibilitatea frontului;
respectarea limitelor.

Notaries

Semnează frontul final al epocii. Notarizarea transformă starea în finală.

6.3 Fluxul epocii

utilizatorii și executorii emit tranzacții și intenturi;
proposerii le includ într-un DAG limitat;
verifierii marchează incompatibilitățile și fraudele;
la închiderea ferestrei, notaries aleg frontul valid cu scor maxim conform regulilor;
frontul este notarizat;
starea devine hard-final.

6.4 Regula de selecție a frontului

Frontul selectat maximizează:

validitatea;
compatibilitatea;
total stake-weight de aprobare;
respectarea ordinii de clearing;
lipsa conflictelor nereconciliate.

Nu maximizează pur și simplu numărul de tranzacții.

6.5 Slashing

Se aplică pentru:

semnare dublă;
notarizare conflictuală;
validare frauduloasă;
neparticipare repetată;
includere sistematică a tranzacțiilor invalide.

7. Batch clearing și anti-MEV

7.1 Motiv

Ordinea strict secvențială favorizează front-running și ordine privilegiate.

7.2 Mecanism

Intenturile compatibile sunt grupate în ferestre discrete.

Pentru fiecare fereastră:

se colectează intenturile;
se verifică restricțiile;
se calculează execuția compatibilă;
se aplică o regulă deterministă de clearing;
se generează execuțiile și witnessurile relevante.

7.3 Proprietăți

prioritate redusă a actorului care vede primul intentul;
transparență mai mare;
cost mai mic pentru utilizatorii non-HFT;
posibilitate de audit a motivului pentru care un intent a fost sau nu executat.

8. Delegare pentru agenți

8.1 Chei și roluri

Un cont sau o entitate poate delega roluri diferite:

TRADE_EXECUTOR
WITNESS_EMITTER
RISK_MANAGER
VAULT_OPERATOR
HALT_GUARD
SETTLEMENT_AGENT

8.2 Politici de delegare

Politicile trebuie să poată exprima:

plafon de valoare per zi;
active permise;
contrapărți permise;
ore / intervale permise;
tipuri de tranzacții permise;
obligația de witness logging;
condiții de auto-stop.

8.3 Principiu de siguranță

Un agent nu trebuie să primească „putere totală”. Primește numai:

suprafața minimă de acțiune;
limite cuantificate;
obligație de jurnal;
posibilitate de oprire.

9. Model economic AZR

9.1 Funcții

AZR este utilizat pentru:

taxe;
staking;
bond pentru operatori și executori;
acces la resurse persistente;
garanție pentru anumite tipuri de witness / oracle / clearing.

9.2 Fluxuri de taxare

Taxele se împart în:

securitate protocol;
burn parțial;
storage maintenance;
recovery reserve.

9.3 Taxa de stare

Persistența nu este gratuită. Orice stare persistentă consumă o taxă recurentă sau preplătită. Astfel se evită umflarea permanentă a stării.

9.4 Recovery reserve

O fracțiune din taxe și penalități poate alimenta un fond protocolar cu scop strict:

bug bounties;
incidente sistemice aprobate prin guvernanță;
migrare de urgență.

10. Limbajul contractelor

10.1 Cerințe

Limbajul trebuie să fie:

tipat strict;
determinist;
compilabil în bytecode analizabil;
fără efecte ascunse;
cu acces limitat la stare;
cu cost predictibil.

10.2 Constrângeri

Interzicem sau limităm sever:

recursivitate generală;
alocare dinamică nelimitată;
apeluri externe arbitrare;
dependență de ordine implicită;
nondeterminism temporal sau de mediu.

10.3 Model de execuție

O funcție de contract declară explicit:

ce citește;
ce scrie;
ce Cells poate consuma;
ce Cells poate crea;
ce Witness Records poate cere sau emite;
ce limite de efect are.

11. Witness format minimal

11.1 Structură

WitnessRecord {
  version
  witness_id
  subject_ref
  issuer_policy
  statement_type
  statement_hash
  proof_bundle_ref
  issued_at
  ttl
  revocation_policy
  visibility_class
  signature_bundle
}

11.2 Cerințe

hash canonical;
semnături standardizate;
formă compactă pentru verificare;
suport pentru expirare;
suport pentru revocare demonstrabilă.

12. Guvernanță

12.1 Ce se poate guverna

parametri de rețea;
onboarding / offboarding roluri speciale;
recovery actions;
upgrade paths permise.

12.2 Ce nu se poate schimba ușor

conservarea valorii;
finalitatea;
determinismul execuției;
limitele modelului bounded.

Acestea trebuie tratate ca aproape constituționale.

12.3 Model

Guvernanța ideală folosește:

proposal Cells;
committee Witness Records;
timelock;
supermajority notarized outcome;
emergency brake limitată.

13. Securitate conceptuală

13.1 Clase de risc

risc de consens
risc de execuție
risc economic
risc de delegare
risc oracle / witness
risc de guvernanță

13.2 Regula structurală

Protocolul nu promite eliminarea riscului. Protocolul promite că:

riscul este clasificat;
limitele sunt declarate;
efectele sunt auditable;
traiectoriile de avarie sunt controlabile.

14. MVP-ul real

Prima implementare care merită numită viață a protocolului trebuie să conțină doar:

Cells cu transfer și timelock;
Bounded Machine minimală pentru escrow;
Witness Record pentru approval și execution_log;
consens ENDC simplificat;
clearing minimal pentru intents simple;
delegare pentru un agent cu plafon;
block explorer cu verificare de witness și machine bounds.

Orice în plus înainte de asta este zgomot.

15. Ce urmează

Următoarele documente necesare sunt:

AZ-002 Data Structures
AZ-003 Transaction Validation Rules
AZ-004 ENDC Consensus Spec
AZ-005 Contract Language and VM
AZ-006 Witness Rules
AZ-007 Economic Model
AZ-008 Agent Delegation Policy
AZ-009 Governance Constitution
AZ-010 Security Assumptions

16. Decizia de etapă

Fantezia nu mai este doar narațiune. Din acest punct există deja o bază pentru:

whitepaper;
specificație;
implementare;
audit viitor.

Formula scurtă

ATLAS ZERO = Value Cells + Bounded Machines + Witness Memory + Epoch Notarized Finality + Intent Clearing + Delegated Agents

Închidere

Aceasta este forma în care ideea poate fi păstrată, extinsă și apărată ca arhitectură coerentă.

ATLAS ZERO nu încearcă să facă totul. Încearcă să facă riguros ceea ce majoritatea sistemelor actuale fac haotic: valoare, logică, memorie și agenți, toate sub limite verificabile.