AZ-001 — Protocol Identity, Purpose and System Boundary v1

Status

Acest document este documentul de fundație al suitei ATLAS ZERO.

El definește:

• ce este protocolul;
• de ce există;
• ce probleme încearcă să rezolve;
• care este boundary-ul sistemului;
• ce intră și ce nu intră în scope;
• cine sunt actorii principali;
• și ce proprietăți trebuie să rămână adevărate indiferent de implementare.

Acest document NU definește încă:

• obiectele canonice concrete;
• serializarea;
• regulile detaliate de validare;
• consensul complet;
• bytecode-ul BVM;
• sau procedurile operaționale.

Acestea apar în documentele următoare.

Rolul lui AZ-001 este să spună: ce este ATLAS ZERO ca protocol și unde îi sunt granițele.

Termeni:

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

1. Obiectiv

ATLAS ZERO este un protocol de rețea pentru:

• valoare transferabilă și auditabilă;
• logică programabilă limitată și controlată;
• memorie verificabilă pentru atestări, procese și agenți;
• coordonare economică și operațională sub risc explicit și bounded.

Scopul protocolului nu este doar “să mute valoare” și nici doar “să ruleze contracte”. Scopul lui este să unească trei tipuri de adevăr într-o singură rețea coerentă:

1. adevărul de valoare
   cine deține ce, în ce condiții și cu ce conservare a valorii;

2. adevărul de logică
   ce tranziții de stare sunt permise, în ce limite și cu ce efecte maxime;

3. adevărul de memorie verificabilă
   ce afirmații, aprobări, dovezi, jurnale și atestări pot influența normativ comportamentul sistemului.

Prin această combinație, ATLAS ZERO urmărește un protocol în care:

• execuția este deterministă;
• riscul este explicit și bounded;
• memoria utilă pentru procese și agenți este nativă, nu improvizată off-chain;
• iar interacțiunea dintre utilizatori, operatori, validatori, guvernanță și agenți poate fi guvernată fără ambiguitate.

2. Problema pe care protocolul încearcă să o rezolve

2.1 Limita protocoalelor de valoare pure

Protocoalele centrate doar pe transfer de valoare rezolvă bine conservarea și posesia, dar devin insuficiente când apar:

• procese multi-step;
• aprobări condiționate;
• atestări și dovezi externe;
• acțiuni automate controlate;
• și nevoia de memorie verificabilă între mai multe momente și mai mulți actori.

2.2 Limita mașinilor de logică nelimitate

Protocoalele cu execuție arbitrară tind să împingă complexitatea în:

• cost de analiză greu predictibil;
• suprafață mare de atac;
• boundedness slab;
• efecte greu de înțeles;
• și diferență mare între ce “pare posibil” și ce poate fi sigur operat la scară.

2.3 Limita memoriei externe necanonice

Multe sisteme folosesc:

• baze de date externe;
• jurnale auxiliare;
• aprobări semi-officiale;
• sau atestări neuniforme.

Când acestea devin material relevante, apare o problemă: adevărul normativ este împărțit între lanț și sisteme laterale, iar auditul și controlul devin mai slabe.

2.4 Nevoia de acțiune automată controlată

În practică, utilizatorii, operatorii și instituțiile au nevoie de:

• delegare condiționată;
• agenți care acționează sub mandate și limite;
• automatizare cu envelope de risc;
• memorie a aprobărilor și a justificărilor;
• și mecanisme de oprire, revocare și audit.

ATLAS ZERO există pentru a trata aceste nevoi ca elemente de protocol, nu ca adăugiri improvizate.

3. Ce este ATLAS ZERO

3.1 Definiție

ATLAS ZERO este un protocol de stare distribuită cu:

• strat de valoare;
• strat de logică bounded;
• strat de witness / memorie verificabilă;
• și capacitate nativă de a exprima delegare, aprobare, risc și procese automate într-o formă auditată și verificabilă.

3.2 Caracter de bază

Protocolul MUST fi:

• determinist;
• canonically serializable;
• auditabil;
• bounded în execuție și efect;
• extensibil prin mecanisme explicite;
• și capabil de export public și audit extern fără pierderea adevărului normativ.

3.3 Ce nu este

ATLAS ZERO nu este, prin definiție:

• un simplu L1 de contracte arbitrare fără limitări de efect;
• un simplu sistem de baze de date distribuite;
• un sistem în care “adevărul real” trăiește în dashboard-uri sau procese off-chain;
• o platformă în care agenții au control nativ nelimitat;
• sau o rețea în care governance-ul poate rescrie tăcut istoria fără recorduri constituționale.

4. Principiile fondatoare

4.1 Determinism first

Pentru orice intrare relevantă și orice stare legitimă, rezultatul validării și al execuției MUST fi unic și reconstructibil.

4.2 Canonical truth over local interpretation

Adevărul protocolar MUST fi mai puternic decât:

• configurația locală;
• interpretarea locală;
• convenția socială neînregistrată;
• sau UI-ul prin care utilizatorul vede protocolul.

4.3 Boundedness over expressive chaos

Expresivitatea logică este valoroasă doar dacă:

• resursele sunt bounded;
• efectele sunt bounded;
• și envelope-ul de risc poate fi declarat și verificat.

4.4 Memory must be useful and normatively meaningful

Memoria verificabilă nu este decor. Ea există pentru a participa normativ la:

• aprobare;
• autorizare;
• audit;
• delegare;
• risc;
• și procese multi-step.

4.5 Automation without sovereign ambiguity

Agenții și automatizările MAY acționa, dar numai:

• sub mandat;
• sub capabilități și limite explicite;
• sub politici de revocare;
• și sub condiții care pot fi auditate.

4.6 Governance with constitutional boundaries

Guvernanța MAY schimba parametri, reguli sau chiar identitate constituțională, dar numai:

• explicit;
• auditabil;
• cu boundary clar;
• și fără a ascunde o ruptură sub aparența unei simple continuități.

4.7 Public verifiability matters

Rețeaua SHOULD putea spune public:

• ce rețea este;
• ce parametri sunt activi;
• cine este validator legitim;
• care este adevărul financiar public;
• și ce branch constituțional este activ.

5. Proprietățile urmărite

ATLAS ZERO urmărește cel puțin următoarele proprietăți mari:

5.1 Finalitate clară

Sistemul SHOULD converge spre finalitate clară și auditată.

5.2 Conservarea valorii

Valoarea MUST fi conservată conform regulilor activelor și fluxurilor autorizate.

5.3 Execuție bounded

Orice logică programabilă relevantă MUST fi bounded în:

• resurse;
• efecte;
• stare;
• și risc.

5.4 Autorizare explicită

Nicio mutație normativă importantă MUST NOT depinde de permisiuni implicite.

5.5 Memorie verificabilă

Aprobările, atestările și jurnalele normative SHOULD fi reprezentabile și verificabile.

5.6 Auditabilitate

Protocolul SHOULD putea produce:

• evidență;
• arhive;
• exporturi externe;
• și proiecții publice coerente.

5.7 Recoverability with legitimacy

În caz de incident grav, recuperarea SHOULD putea fi făcută fără a pierde posibilitatea de a spune ce stare este legitimă și de ce.

6. System boundary

6.1 Ce intră în boundary-ul protocolului

În boundary-ul protocolului intră:

• obiectele canonice și serializarea lor;
• regulile de validare;
• tranzițiile de stare;
• consensul și finalitatea;
• logica bounded și mașina ei de execuție;
• witness/proof/attestation semantics;
• parametrii normativi;
• validator set legitimacy;
• guvernanța normativă;
• adevărul financiar public;
• launch, upgrade, recovery și canonul constituțional;
• exporturile și bundle-urile normative care păstrează și proiectează acest adevăr.

6.2 Ce nu intră în boundary-ul protocolului prin definiție

Nu intră automat în boundary:

• interfețe UI;
• un anumit explorer;
• un anumit wallet UX;
• tool-uri auxiliare fără autoritate normativă;
• analize private;
• componente locale de logging;
• sau preferințe de implementare care nu afectează verdictul protocolar.

6.3 Regula esențială

Dacă un element poate schimba:

• validitatea;
• starea;
• identitatea;
• autoritatea;
• obligațiile publice;
• sau verdictul de conformitate, atunci acel element SHOULD fi în boundary-ul normativ al protocolului sau în extensiile lui formal recunoscute.

7. Actorii principali

7.1 Utilizator

Actor care:

• deține valoare;
• emite intents;
• aprobă sau deleagă anumite acțiuni;
• și poate consuma proiecții publice ale adevărului protocolului.

7.2 Validator

Actor sau entitate legitimă care participă la:

• validare;
• propunere;
• verificare;
• notarizare;
• sau alte roluri de consens definite ulterior.

7.3 Operator

Actor care rulează infrastructură și procese operaționale. Operatorul MAY controla noduri și rollout-uri, dar nu devine automat autoritate normativă globală.

7.4 Guvernanță

Actor colectiv sau mecanism care poate:

• aproba anumite schimbări;
• ratifica recovery sau continuitate;
• modifica parametri sau reguli;
• și emite acte constituționale în limitele definite ulterior.

7.5 Auditor / Verificator extern

Actor care:

• citește exporturi;
• verifică bundle-uri;
• și validează anumite afirmații fără acces privilegiat complet la infrastructura internă.

7.6 Agent

Actor software delegat care poate acționa:

• numai sub mandate;
• sub capabilități și limite explicite;
• și sub audit și revocare.

8. Cele trei adevăruri ale protocolului

8.1 Value truth

Ce valoare există, unde există și în ce condiții poate fi mutată.

8.2 Logic truth

Ce mutații de stare sunt valide și în ce envelope de efect și risc.

8.3 Witness truth

Ce afirmații și dovezi sunt suficient de valide încât să poată influența normativ comportamentul rețelei.

8.4 Relația dintre ele

Protocolul există tocmai pentru a le ține coerente. Valoarea, logica și memoria verificabilă MUST NOT trăi ca trei lumi incompatibile sau prost legate între ele.

9. Primitivele conceptuale ale sistemului

La nivel de identitate de protocol, ATLAS ZERO presupune existența următoarelor primitive conceptuale:

• obiecte finite de valoare;
• mașini de logică bounded;
• înregistrări de witness/attestation;
• intents declarative;
• politici de owner/spend/expiry/upgrade/halt;
• recorduri de rol și autoritate;
• și recorduri de continuitate și legitimitate.

AZ-001 nu le definește încă formal. Doar spune că protocolul este construit din astfel de familii de obiecte și politici, nu din “trucuri” locale de implementare.

10. Ce înseamnă bounded în filosofia protocolului

10.1 Resurse bounded

Execuția și validarea MUST avea limite verificabile de:

• timp;
• memorie;
• mărime;
• și complexitate relevantă.

10.2 Efecte bounded

O tranziție sau o mașină MUST avea limită asupra:

• numărului de obiecte afectate;
• cantității de valoare expuse;
• tipului de efecte permise;
• și suprafeței de permisiune.

10.3 Risc bounded

Pentru domeniile relevante, protocolul SHOULD putea exprima:

• pierdere maximă posibilă;
• expunere maximă;
• condiții de halt;
• și envelope de control.

11. Ce înseamnă memorie verificabilă

11.1 Nu doar stocare

Memoria verificabilă nu este doar “date puse undeva”. Ea este memorie care poate fi:

• referită;
• verificată;
• expirată;
• revocată;
• și consumată normativ de politicile și mașinile protocolului.

11.2 Exemple de funcții

• aprobări;
• atestări de risc;
• dovezi operaționale;
• jurnale de execuție;
• claims de oracle;
• voturi și acte de guvernanță;
• și urme de acțiuni agentice.

12. Ce înseamnă delegare și control agentic

ATLAS ZERO presupune că automatizarea reală este utilă, dar periculoasă dacă nu este modelată nativ.

Prin urmare, protocolul SHOULD permite:

• mandate;
• capabilități delimitate;
• risk caps;
• time windows;
• revocare;
• audit trail;
• și politici de stop.

Protocolul MUST NOT presupune că agentul este “de încredere” doar pentru că este software sau pentru că utilizatorul l-a pornit.

13. Adevăr intern, adevăr public, adevăr de audit

13.1 Adevăr intern normativ

Este adevărul complet al protocolului și al canoanelor lui.

13.2 Adevăr public proiectat

Este proiecția verificabilă publică a unei părți suficient de importante din adevărul intern.

13.3 Adevăr de audit

Este setul de bundle-uri și dovezi care permit verificare externă mai adâncă și mai strictă.

13.4 Regula

Aceste trei niveluri MAY diferi în volum și expunere, dar MUST NOT se contrazice semantic pentru același scope.

14. Continuitate, upgrade, recovery, fork

ATLAS ZERO presupune de la început că:

• rețeaua va evolua;
• pot exista upgrade-uri compatibile;
• pot exista hard fork-uri incompatibile;
• pot exista incidente grave și recovery.

Prin urmare, încă de la nivelul AZ-001, protocolul trebuie înțeles ca:

• sistem evolutiv;
• sistem cu memorie constituțională;
• și sistem care trebuie să poată spune clar când continuă aceeași identitate și când apare o ramură sau o ruptură.

15. Security posture de bază

Protocolul pleacă de la premisa că există:

• adversari economici;
• adversari operaționali;
• compromitere de chei;
• configurări greșite;
• proiecții publice stale;
• și riscul ca adevărul să se fragmenteze între mai multe straturi.

Prin urmare, designul SHOULD favoriza:

• explicitness;
• canonicalization;
• determinism;
• replayability;
• provenance;
• boundedness;
• și audit-grade memory.

16. Ce va fi detaliat ulterior

Pe baza lui AZ-001, restul suitei va detalia:

• AZ-002: din ce obiecte exacte este făcut protocolul și cum sunt validate canonic;
• AZ-003: cum se validează tranzacțiile și tranzițiile de stare;
• AZ-004: cum funcționează consensul și finalitatea;
• AZ-005: cum funcționează mașina bounded și limbajul ei;
• AZ-006: cum funcționează witness/proof/attestation;
• AZ-007: modelul economic;
• AZ-008: modelul de delegare și control agentic;
• AZ-009: modelul de guvernanță și puteri constituționale;
• și apoi toate disciplinele de launch, archive, public truth, recovery și closure.

17. Ce este în mod explicit în afara promisiunii acestui document

AZ-001 nu promite încă:

• că protocolul este complet implementat;
• că toate trade-off-urile sunt rezolvate;
• că toate formulele economice finale sunt înghețate;
• că BVM-ul este deja specificat la nivel de opcode;
• sau că există deja suficiente dovezi de siguranță practică.

El promite doar cadrul de identitate: ce fel de sistem este acesta și în ce direcție trebuie să rămână coerent.

18. Anti-patterns pe care AZ-001 le interzice de la nivel de identitate

Protocolul SHOULD avoid încă de la nivel de fundație:

1. adevăr normativ împărțit informal între on-chain și off-chain fără model explicit;
2. execuție arbitrară fără boundedness;
3. automatizare fără mandat și fără envelope de risc;
4. guvernanță cu putere de rescriere tăcută a istoriei;
5. proiecții publice nelegate de surse canonice;
6. memorie “utilă” dar nevalidabilă;
7. local config tratat de facto ca adevăr protocolar;
8. lipsă de diferență între citire, verificare și autoritate;
9. upgrade-uri și recovery-uri fără model de continuitate;
10. sistem documentar fără ieșire spre bundle-uri și verificare machine-readable.

19. Obiective formale ale documentului

AZ-001 urmărește aceste obiective:

19.1 Identity clarity

Protocolul poate spune ce este și ce nu este.

19.2 Scope clarity

Boundary-ul sistemului este explicit.

19.3 Design orientation

Restul documentelor au o fundație coerentă peste care să detalieze.

19.4 Long-term compatibility of meaning

Chiar dacă implementările și bundle-urile evoluează, sensul de bază al protocolului rămâne recognoscibil și auditabil.

20. Formula documentului

ATLAS ZERO = valoare auditabilă + logică bounded + memorie verificabilă + delegare controlată + guvernanță constituțională + adevăr public exportabil

21. Relația cu Protocol Skeleton

Documentul ATLAS_ZERO_protocol_skeleton_v1.md este complementar lui AZ-001.

• AZ-001 spune: ce este protocolul și care este boundary-ul său.
• Protocol Skeleton spune: cum se împarte arhitectural în straturi și primitive conceptuale.
• AZ-002 va spune: care sunt obiectele exacte și regulile canonice.

Pe scurt:

AZ-001 = identitate
Skeleton = arhitectură conceptuală
AZ-002 = obiecte canonice

22. Ce urmează

După acest document, următorul document corect este:

AZ-002 — Data Structures and Canonical Validation

Acolo protocolul încetează să fie doar identitate și devine structură concretă:

• tipuri;
• hash-uri;
• obiecte;
• serializare;
• și reguli de validitate.

Închidere

Înainte să existe obiecte, blocuri, bytecode, ceremonii sau bundle-uri, protocolul trebuie să poată răspunde la o întrebare simplă:

ce este el, de fapt?

AZ-001 fixează acel răspuns.

De aici încolo, tot restul suitei poate fi citit ca o dezvoltare disciplinată a acestei identități: valoare, logică, memorie, control, continuitate și adevăr verificabil.