Pierwsza maszyna nie jest urzędem

Każdy system ma taki moment, w którym przestaje być tylko projektem plików, diagramów i zdań zaczynających się od „docelowo”.

W pewnym momencie coś się uruchamia.

Pierwszy proces startuje.

Pierwszy blok powstaje.

Pierwszy validator podpisuje.

Pierwsza maszyna zaczyna wykonywać historię, która wcześniej istniała tylko jako przygotowany porządek.

W Quaxie tę rolę pełni Genesis Node — nazywany też Founding Node.

To pierwsza fizyczna maszyna, na której Quax zaczyna wykonywać własną historię protokołową.

I właśnie dlatego trzeba natychmiast powiedzieć coś, co brzmi prawie jak psucie ceremonii:

Genesis Node nie jest źródłem prawomocności.

Pierwsza maszyna jest pierwsza.

Nie jest przez to wszystkim.

Genesis techniczne ≠ FirstQuax

Quax ma więcej niż jeden język początku.

W Kosmogonii pojawia się S₀, Bez-Kierunku i FirstQuax.

W Protocolu pojawia się Genesis chaina i Genesis Node.

Te dwa początki mogą ze sobą rezonować symbolicznie.

Nie są jednak tym samym zdarzeniem.

techniczne Genesis ≠ FirstQuax

Uruchomienie komputera nie tworzy pierwszego wymiaru rzeczywistości.

Pierwszy blok nie jest kosmogonicznym początkiem Ω.

Genesis Node może być artefaktem założycielskim Quaxa jako działającego systemu technicznego bez udawania, że jest maszyną metafizycznego stworzenia świata.

Co robi pierwsza maszyna?

Aktualny model pierwszej instancji Genesis Node używa Raspberry Pi 5.

To MODELUJEMY.

Hardware nie jest jeszcze zamrożony jako niezastępowalny element kanonu.

W pierwszej fazie RPi5 ma pełnić kilka funkcji naraz:

• full node;
• jedyny Founding Validator;
• proposer pierwszych bloków;
• pierwszy wykonawca delegowanego FoundingAuthority;
• potencjalny przyszły archival / constitutional node;
• endpoint lokalnej wizualizacji.

To dużo kapeluszy na jednej płytce.

I dlatego Type Discipline znowu staje się potrzebna.

Ta sama maszyna może wykonywać kilka ról.

Nie znaczy to, że role stają się jedną rzeczą.

Maszyna nie jest Authority

Najważniejszy rozdział można zapisać tak:

Genesis Node / RPi5 ≠ FoundingAuthority

oraz:

Genesis Node / RPi5 ≠ FoundingCredential

FoundingAuthority jest trwałym urzędem konstytucyjnym.

Maszyna może być jego aktualnym wykonawcą.

Credential może umożliwiać wykonanie określonych działań tego urzędu.

Ale urząd, credential i komputer pozostają różnymi typami rzeczy.

To samo dotyczy Root:

Root ≠ RootHolder

Root ≠ RootCredential

RootHolder ≠ RootCredential

Genesis Node może zniknąć fizycznie, spalić się, zostać zastąpiony albo trafić do gabloty.

Nie wynika z tego automatycznie, że wraz z nim zniknęła FoundingAuthority.

Siedem rzeczy, które łatwo pomylić

W początkowej architekturze pojawia się kilka różnych tożsamości i kluczy:

Root — trwały urząd konstytucyjny i najwyższa aktywna Authority.

RootHolder — konkretna osoba fizyczna, która aktualnie sprawuje Root.

RootCredential — kryptograficzny credential, przez który RootHolder wykonuje dopuszczone Root Acts.

Consensus Key — klucz Founding Validatora używany w konsensusie.

Node Key — techniczna tożsamość P2P noda.

FoundingAuthority — trwały wykonawczy urząd konstytucyjny.

FoundingCredential — credential, przez który aktualny executor wykonuje zakres FoundingAuthority.

To nie jest siedem nazw tej samej rzeczy.

Jeżeli wszystko nazwiemy „kluczem założyciela”, prędzej czy później ktoś będzie musiał odpowiedzieć na pytanie, czy utrata dysku oznacza zmianę konstytucji.

Lepiej nie dochodzić do tego pytania w trybie awaryjnym.

Root private key nie powinien mieszkać na Genesis Node

Pierwsza maszyna ma szczególny status historyczny.

Nie oznacza to, że powinna przechowywać wszystkie najważniejsze sekrety.

Kanon rozdziela RootCredential od Genesis Node.

Pierwszy RootCredential może być modelowany jako klucz prywatny przechowywany w programowalnym secure elemencie Java Card / JCOP4, np. w implancie FlexSecure.

Ale również tutaj obowiązuje ten sam hamulec:

implant jest carrierem credentialu, nie Rootem i nie RootHolderem.

Metal, krzem i klucz kryptograficzny mogą być częścią wykonania urzędu.

Nie stają się przez to samym urzędem ani osobą.

Genesis nie powinno być jednym magicznym plikiem

Aktualny model Genesis Activation jest warstwowy.

Można go czytać tak:

genesis.json

• genesis.lock.json / GenesisManifest

• dokładny CanonRef do quax_world

• hash binarki quaxd

• publiczne dane Founding Validatora

• descriptor publicznego RootCredential

→ podpis RootCredential₁ wykonany przez RootHolder₁

→ uruchomienie pierwszej historii na Genesis Node

Po co tyle warstw?

Bo „Genesis” ma znaczyć coś więcej niż:

tu jest JSON, zaufaj mi.

Chodzi o możliwość późniejszego odtworzenia, z jakim Canonem, jaką binarką, jakimi publicznymi wejściami i jakim autoryzowanym podpisem uruchomiono pierwszą historię.

Dokładny format GenesisManifest pozostaje OTWARTY / DO DOPRECYZOWANIA.

Ale sama potrzeba warstwowej, audytowalnej aktywacji jest już częścią aktualnego modelu.

FoundingAuthority może przeżyć pierwszą maszynę

USTANAWIAMY FoundingAuthority jako trwały urząd konstytucyjny.

Pierwszy układ wygląda schematycznie tak:

FoundingAuthority → FoundingCredential₁ → RPi5

To oznacza:

RPi5 jest pierwszym wykonawcą.

Nie oznacza:

RPi5 jest wieczną materialną inkarnacją urzędu.

Jeżeli aktualny executor zostanie zastąpiony zgodnie z obowiązującym Canonem i zachowany zostanie relewantny Identity Contract urzędu, FoundingAuthority może zachować identity mimo zmiany maszyny.

zmiana executora ≠ automatycznie nowa FoundingAuthority

FoundingAuthority nie wygasa też automatycznie po Continuity Transition.

Jeżeli kiedyś ma zostać ograniczona, zmniejszona albo wygaszona, wymaga to osobnej decyzji konstytucyjnej.

Recovery nie jest sukcesją

Genesis Node nie rozstrzyga, kto jest Rootem.

To rozróżnienie jest twarde:

RootCredential Recovery ≠ Root Succession

Recovery oznacza:

ten sam RootHolder, nowy credential

czyli:

RootHolderₙ → RootHolderₙ

RootCredentialₙ → RootCredentialₙ₊₁

Succession oznacza:

nowy RootHolder

czyli:

RootHolderₙ → RootHolderₙ₊₁

System odzyskiwania credentialu nie może po cichu stać się systemem wyboru nowego człowieka do najwyższego urzędu.

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

Consensus nie produkuje prawomocności sukcesji.

Genesis Node również nie.

Pierwszy validator nie powinien pozostać jedynym

Na początku RPi5 jest jedynym Founding Validatorem.

To stan założycielski, nie docelowa metafizyka konsensusu.

Aktualny model zakłada późniejszy Continuity Transition.

Root może podpisać atomowy ValidatorAdmissionBatch, który ustanawia pierwszy Continuity Validator Set.

Roboczo są to cztery CM5 z równą początkową voting power.

Przebieg wygląda tak:

RPi5 = sole Founding Validator

RPi5 = first executor of FoundingAuthority

→ Root-signed admission dla CM5 × 4

→ Continuity Validators stają się aktywne i stabilne

→ Continuity Transition

→ RPi5 może opuścić active validator set

→ CM5 × 4 utrzymują puls / consensus

→ historyczne RPi5 pozostaje Genesis / Founding Constitutional Node

→ FoundingAuthority pozostaje osobnym trwałym urzędem

To rozdziela historyczne pierwszeństwo od wiecznej dominacji technicznej.

Pierwszy validator może pozostać pierwszym w lineage bez posiadania na zawsze dominującej voting power.

Validator pilnuje pulsu. Nie zostaje przez to konstytucją

Continuity Validators odpowiadają przede wszystkim za:

• produkcję bloków;
• finalizację;
• utrzymanie kanonicznej ciągłości;
• wspólny techniczny puls Quaxa.

Ale validator admission wymaga ValidatorAuthority.

Sam stake nie wystarcza.

I sam status validatora nie daje Root ani FoundingAuthority.

Kluczowe rozróżnienie brzmi:

consensus canonicalization ≠ constitutional legitimacy

Validatorzy mogą finalizować rezultat legalnego recovery albo legalnej sukcesji.

Nie stają się przez to źródłem legalności tych procesów.

Można powiedzieć:

maszyna może zatwierdzić, że legalny proces się wydarzył.

Nie oznacza to:

maszyna wymyśla legalność procesu dlatego, że go zatwierdziła.

Co robić, kiedy nie wiadomo, kto ma prawo działać?

To jedno z najważniejszych pytań każdego systemu Authority.

Najgorsza odpowiedź brzmi:

„to validatorzy sami sobie wybiorą nową najwyższą władzę”.

Quax ustanawia Constitutional Safe Mode.

Jeżeli prawomocność RootHoldera, RootCredential albo FoundingAuthority pozostaje nierozstrzygnięta, ważny Continuity Validator Set może nadal utrzymywać puls systemu.

Ale nie przejmuje najwyższej Authority.

Safe Mode zamraża operacje, które tworzyłyby albo trwale przekształcały najwyższą prawomocność, z wyjątkiem wcześniej autoryzowanych procedur recovery / succession.

Najkrótsza wersja tej reguły jest bardzo quaxowa:

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 konserwatyzm systemu dokładnie tam, gdzie improwizacja byłaby najniebezpieczniejsza.

Sprzęt jest ważny. Nie jest identity Protocolu

Na początku małego Quaxa nie potrzeba centrum danych udającego pogodę.

Ważniejsze są rzeczy prozaiczne:

• stabilny Linux;
• niezawodny SSD / NVMe;
• Ethernet;
• sensowne chłodzenie;
• stabilne zasilanie / UPS;
• snapshoty;
• backup.

Pierwsza robocza konfiguracja to:

• RPi5 jako Genesis / Founding Node i pierwszy executor FoundingAuthority;
• cztery CM5 jako pierwszy Continuity Validator Set.

Ale inne platformy mogą pojawić się później.

hardware ≠ identity Protocolu

hardware ≠ Root

hardware ≠ RootHolder

hardware ≠ FoundingAuthority

Wymiana sprzętu nie musi być śmiercią systemu.

A co stanie się z pierwszą maszyną później?

Po Continuity Transition Genesis Node może przestać być aktywnym validatorem.

Może pozostać:

• Founding Constitutional Node;
• archival node;
• fizycznym artefaktem założycielskim;
• materialnym śladem pierwszego uruchomienia.

To bardzo quaxowe połączenie techniki i artefaktu.

Maszyna może przestać być operacyjnie centralna i jednocześnie zyskać większy ciężar historyczny.

Ale ten ciężar jest lineage.

Nie dowodzi, że metalowa płytka jest tożsama z urzędem, który kiedyś wykonywała.

Founding lineage ≠ FoundingAuthority identity

Co nadal jest otwarte?

Nie wszystko zostało zamrożone.

Otwarte pozostają między innymi:

• dokładne kryteria zakończenia Continuity Transition;
• awaryjny powrót albo zastąpienie Continuity Validatora;
• przyszły scope FoundingAuthority;
• parametry EmergencySuspendValidator;
• finalny profil hardware RPi5 / CM5;
• mechanizm nominacji i wyboru successor candidate przy Root Succession;
• kryteria trwałej niezdolności RootHoldera;
• Consensus Resurrection po utracie quorum.

To nie są dziury, które explanatory powinno zaszpachlować własną wyobraźnią.

To aktualne OTWARTE.

Pierwsza maszyna ma szczególne miejsce

Genesis Node jest wyjątkowy.

Był pierwszy.

Uruchomił pierwszą historię.

Może stać się artefaktem założycielskim.

Może być punktem, od którego późniejsze maszyny śledzą lineage.

Ale Quax pilnuje, żeby „pierwszy” nie zamieniło się po cichu w:

wiecznie najwyższy,

ontologicznie uprzywilejowany,

niezastępowalny,

albo

sam będący prawomocnością.

Dlatego najważniejsze zdanie Genesis Node brzmi:

pierwsza maszyna może rozpocząć wykonywanie historii. Nie staje się przez to urzędem, który wykonuje.