Awaria nie daje nowych uprawnień

Awaria ma pewien brzydki zwyczaj.

Najpierw zabiera systemowi coś ważnego.

Klucz.

Kartę recovery.

Validatora.

Pewność, kto właściwie ma prawo działać.

A chwilę później podsuwa bardzo kuszący pomysł:

„skoro normalna procedura nie działa, zróbmy teraz nową”.

Quax odpowiada:

nie tak.

Kryzys może wymagać procedury awaryjnej.

Nie może jednak sam stać się źródłem nowej prawomocności.

To jedna z najważniejszych zasad technicznej konstytucji QUAX-a.

awaria może uruchomić wcześniej ustanowione uprawnienie

awaria nie może sama tego uprawnienia stworzyć

Najpierw jedna rzecz: podpis ma typ

RootCredential nie jest magicznym długopisem, którym można podpisać dowolny hash i powiedzieć:

„Root zatwierdził”.

Root wykonuje Root Acts — typowane akty o określonej semantyce i zakresie.

Roboczo mogą to być między innymi:

• GenesisManifest;
• ValidatorAdmissionBatch;
• ValidatorPermanentRevocation;
• RootRecoveryPolicy;
• RootSuccessionPolicy;
• RootRecoveryIntent;
• RootSuccessionIntent;
• RootChallenge;
• ConstitutionalChange;
• GrantHighestAuthority.

To ważne, bo dwa poprawne podpisy kryptograficzne mogą oznaczać zupełnie inne rzeczy konstytucyjnie.

Akt powinien mówić przynajmniej:

• jakiego jest typu i wersji;
• czego albo kogo dotyczy;
• jaki ma zakres;
• w jakiej sieci / chain_id obowiązuje, jeżeli jest sieciowy;
• jak chroni się przed replay;
• czy ma termin ważności;
• do jakiej wersji Canonu albo Protocolu odnosi swoją semantykę, jeśli to potrzebne.

Dokładny canonical encoding pozostaje OTWARTY.

Ale sama zasada jest prosta:

RootCredential potwierdza podpis Root Actu. Nie zamienia nieokreślonego komunikatu w najwyższe prawo.

Authority nie jest jednym suwakiem

QUAX modeluje Authority jako zestaw typowanych i ograniczonych capabilities.

Można mieć kompetencję do:

• dopuszczenia validatora;
• trwałego odwołania validatora;
• czasowego awaryjnego zawieszenia validatora;
• propozycji upgrade'u Protocolu;
• zmiany konstytucyjnej;
• recovery RootCredential;
• uruchomienia Root Succession;
• zmiany Recovery Set;
• nadania najwyższej Authority.

Posiadanie jednej nie daje automatycznie pozostałych.

capability A ≠ general Authority

To szczególnie ważne przy awarii.

Ktoś, kto dostał prawo do awaryjnego zawieszenia validatora, nie powinien przez sam fakt kryzysu dostać prawa do trwałego odwołania Roota.

FoundingAuthority może mieć czasową kompetencję EMERGENCY_SUSPEND_VALIDATOR.

Ale jeśli ją ma, ma być ona wcześniej delegowana, ograniczona, odwracalna i audytowalna.

Awaryjne nie znaczy bezgraniczne.

Recovery Cards nie są zapasowym rządem

QUAX modeluje Recovery Set złożony z trzech niezależnych credentiali:

Recovery A / Recovery B / Recovery C.

Każdy ma własny klucz.

Taka karta jest:

artefaktem + credentialem proceduralnym.

Nie jest:

• Rootem;
• RootHolderem;
• general Authority;
• źródłem Truth;
• prawem do Emission;
• prawem do dowolnego Canon Merge;
• uniwersalnym kluczem administracyjnym.

Recovery Set ma bardzo wąskie znaczenie:

może uczestniczyć w procedurach, które wcześniej jawnie przewidziała konstytucja.

Nie może powiedzieć:

„mamy dwa podpisy z trzech, więc od dziś wolno nam również coś, czego żadna wcześniejsza policy nie przewidywała”.

Podpisy wykonują regułę.

Nie produkują jej ex nihilo.

Kiedy ginie credential, ale nie człowiek

Najprostszy przypadek:

RootHolder nadal jest tą samą osobą.

Urząd nadal jest przez niego legalnie sprawowany.

Problemem jest RootCredential.

Został utracony, zniszczony albo nie może być użyty.

To RootCredential Recovery.

RootHolderₙ → RootHolderₙ

RootCredentialₙ → RootCredentialₙ₊₁

Człowiek się nie zmienia.

Urząd się nie zmienia.

Zmienia się credential.

Normal recovery — MODELUJEMY

Obecny model kandydujący wygląda mniej więcej tak:

2-of-3 Recovery
+ FoundingAuthority
+ nowy RootCredential
+ timelock

To nie jest jeszcze zamknięty protokół produkcyjny.

Progi, czasy i szczegóły są otwarte.

Istotny jest wzór:

kilka niezależnych przesłanek + czas na wykrycie błędu + wcześniej ustanowiona policy.

A jeśli recovery jest sporne?

Możliwy mocniejszy wariant:

3-of-3 Recovery
+ FoundingAuthority
+ nowy RootCredential
+ dłuższy timelock

Stary credential może mieć prawo złożenia RootChallenge.

Czyli formalnego zakwestionowania trwającej procedury w granicach wcześniej ustanowionej policy.

Szczegóły RootChallenge — terminy, czas weta, dokładne skutki — pozostają OTWARTE.

Ale sama idea jest ważna:

procedura recovery powinna mieć sposób odróżnienia „odzyskujemy dostęp” od „ktoś właśnie próbuje przejąć urząd”.

Katastrofa też musi być przewidziana przed katastrofą

Może być gorzej.

RootHolder jest nadal tą samą osobą, ale zwykła ścieżka recovery również nie działa.

Brakuje któregoś organu.

Credentiale zostały utracone.

Normalny flow jest niedostępny.

QUAX dopuszcza modelowanie catastrophic credential recovery.

Na przykład:

3-of-3 Recovery
+ długi timelock
+ druga, świeża ceremonia 3-of-3
→ nowy RootCredential

To jest jednak legalne tylko wtedy, kiedy taka ścieżka była ustanowiona przed kryzysem i da się ją zrekonstruować z dostępnej historii, Dowodów i reguł.

Nie wolno po katastrofie napisać:

„od zawsze mieliśmy procedurę katastroficzną, właśnie ją wymyśliliśmy”.

Zasada anty-post-hoc nie bierze urlopu w czasie pożaru.

A jeśli ma zmienić się człowiek?

To już nie recovery.

To Root Succession.

RootHolderₙ → RootHolderₙ₊₁

RootCredentialₙ → RootCredentialₙ₊₁

Urząd Root może zachować swoją identity, jeśli zachowane zostało relewantne Kᶜ urzędu i procedura jest legalna.

Ale poprzedni i nowy RootHolder pozostają dwiema różnymi osobami.

ciągłość urzędu ≠ ciągłość człowieka

Recovery Set może uruchomić wcześniej ustanowioną procedurę sukcesji.

Nie znaczy to, że staje się kolegium posiadającym general Authority.

Ma wykonać konkretną procedurę.

Potem kończy się zakres tej konkretnej kompetencji.

Co w sukcesji nadal jest otwarte?

Między innymi:

• kiedy poprzedni RootHolder jest uznawany za trwale niezdolnego do sprawowania urzędu;
• kto może nominować successor candidate;
• jak kandydat jest wybierany albo zatwierdzany;
• jakie obowiązują progi i timelocki;
• jak działa RootChallenge przy spornej sukcesji.

To nie są drobiazgi do dopisania po fakcie.

To właśnie rzeczy, które trzeba ustalić zanim będą potrzebne.

QUAX może również kiedyś mieć wysokoprogową catastrophic Root Succession.

Ale znowu:

catastrophic ≠ post-hoc

Constitutional Safe Mode: kiedy odpowiedź brzmi „nie wiemy”

Najtrudniejsza awaria nie zawsze jest techniczna.

Czasem serwery działają świetnie.

Podpisy się zgadzają.

Chain finalizuje bloki.

Tylko nie wiadomo, kto ma legalne prawo wykonać najwyższy akt.

Możemy mieć:

• konkurencyjne claimy sukcesyjne;
• utracony RootCredential bez legalnej drogi recovery;
• niedostępne FoundingAuthority tam, gdzie reguły go wymagają;
• sprzeczne Evidence;
• niemożliwą do jednoznacznego odtworzenia Recovery Policy;
• sporną historię Identity Contract;
• niejasność co do samych Rules^R_λ.

Wtedy QUAX nie powinien rozwiązać problemu prostym:

„validatorzy są online, więc niech oni zostaną najwyższą władzą”.

Wchodzi Constitutional Safe Mode.

W warunkach nierozstrzygniętej prawomocności QUAX zachowuje ciągłość tego, co już ustanowione, ale nie tworzy sam sobie nowej prawomocności.

To jest USTANAWIAMY.

Co nadal może działać?

Continuity Validators mogą utrzymywać puls.

Mogą wykonywać operacje ledgerowe, których legalność nie zależy od spornej najwyższej Authority.

Czyli system nie musi natychmiast umrzeć tylko dlatego, że konstytucja weszła w stan nierozstrzygnięty.

Ale techniczna ciągłość nie staje się nowym źródłem prawa.

continuity ≠ sovereignty

Co zostaje zamrożone?

Co najmniej operacje tworzące albo zmieniające najwyższą władzę bez bezspornego wcześniejszego upoważnienia:

• recovery poza wcześniej autoryzowaną policy;
• succession poza wcześniej autoryzowaną policy;
• zmiana Recovery Set;
• validator admission;
• permanent validator revocation;
• GRANT_HIGHEST_AUTHORITY;
• konstytucyjny UpgradeProtocol;
• zmiana Identity Contract Root / RootHolder;
• zmiana Recovery Policy / Succession Policy.

Awaryjne zawieszenie validatora może istnieć tylko wtedy, gdy było wcześniej delegowane jako ograniczona, czasowa kompetencja.

Safe Mode nie mówi:

„odkryliśmy prawdziwą historię”.

Mówi:

„nie mamy wystarczającej podstawy do wykonania tych klas aktów, więc ich nie wykonujemy”.

Safe Mode = preserve permitted continuity

Safe Mode ≠ truth oracle

Safe Mode ≠ cross-history adjudication

Monitor widzi kartę. Nie widzi prawomocności

QUAX może mieć system monitorowania custody Recovery Cards.

Taki monitor może emitować sygnały typu:

• PRESENT_VERIFIED;
• CARD_MISSING;
• MONITOR_OFFLINE;
• TAMPER;
• STALE.

To bardzo przydatne.

I bardzo łatwe do przecenienia.

Custody Monitor ≠ Authority

Custody Monitor ≠ Truth oracle

Custody Monitor ≠ automatic recovery trigger

Custody Monitor ≠ automatic succession trigger

Sygnał monitora jest Evidence.

Może być poprawny.

Może być błędny.

Może wymagać dalszej procedury.

Czujnik drzwi nie zostaje królem tylko dlatego, że pierwszy zauważył, że sejf jest otwarty.

Jedna zgubiona karta to nie to samo co dwie

Recovery Set może wejść w stan zdegradowany.

Minimalny guardrail jest taki:

• utrata jednej z trzech Recovery Cards powinna prowadzić do pilnej rotacji / odtworzenia zestawu zgodnie z wcześniej ustanowioną policy;
• utrata dwóch kart nie pozwala po prostu obniżyć progu z 2-of-3 do 1-of-1 albo „cokolwiek nam zostało”.

utrata credentiali ≠ prawo do osłabienia reguł post hoc

Dokładna polityka Degraded RecoverySet pozostaje OTWARTA.

A jeśli umrze consensus?

To jeszcze inny problem.

Można stracić quorum Continuity Validators.

Chain przestaje osiągać normalną finality.

To nie jest:

• RootCredential Recovery;
• Root Succession;
• Recovery Set failure.

To problem Consensus Resurrection.

QUAX nie ma jeszcze zamkniętej procedury jego rozwiązania.

OTWARTE.

Jedna rzecz jest jednak ustalona jako granica:

key recovery nie może po cichu zastąpić procedury odtworzenia consensus.

Jeśli kiedyś powstanie Consensus Resurrection, musi mieć własne reguły, własne Authority i własne warunki bezpieczeństwa.

Nie może wyjść bokiem z procedury stworzonej do czegoś innego.

A-002 nadal stoi w pokoju

Cała ta architektura mówi często:

„wcześniej ustanowiona policy”.

A A-002 natychmiast pyta:

„wcześniej — w której wersji historii?”

Dlatego Protocol wykonuje takie claimy względem dostępnego:

H_λ / E_λ / Rules^R_λ.

Czyli historii, Dowodów i reguł, które można zrekonstruować jako relewantne dla danego wykonania.

To nadal nie daje dostępu do cross-history truth.

ProtocolFinality_λ ↛ CrossHistoryTruth

Jeżeli sama historia Recovery Policy stała się sporna, Safe Mode może być właśnie właściwym wynikiem.

Nie dlatego, że Protocol „wie, że nie ma odpowiedzi”.

Dlatego, że nie ma wystarczającej podstawy, żeby legalnie wykonać konkretną klasę działania.

Najważniejsza zasada

System odporny na awarie nie jest systemem, który zawsze potrafi coś zrobić.

Czasem bezpieczeństwo polega właśnie na tym, że potrafi powiedzieć:

„tego teraz nie wolno mi zrobić”.

QUAX chce, żeby recovery odzyskiwało credential.

Succession zmieniało holdera według ustanowionych reguł.

Safe Mode ograniczał system przy sporze.

Custody monitoring dostarczał Evidence.

Consensus Resurrection kiedyś miało własną procedurę.

A żadna z tych rzeczy nie dostawała w prezencie cudzej Authority tylko dlatego, że wydarzyła się awaria.

kryzys testuje konstytucję

nie powinien jej pisać za nas