Maszyna zaczyna pamiętać

Do tej pory Quax głównie patrzył.

Na świat.

Na projekcje.

Na cele.

Na tarcie.

Na to, co nazywamy Prawdą, kiedy mamy do niej tylko kawałek dostępu.

A teraz na scenę wchodzi maszyna.

Nie po to, żeby rozstrzygnąć metafizykę.

Nie po to, żeby wiedzieć lepiej od świata.

Po to, żeby pamiętać ustalone reguły, wykonywać operacje i pozwalać wielu maszynom uzgodnić wspólny stan.

To jest Protocol.

I dobrze, żeby był trochę nudniejszy niż Kosmogonia.

Ktoś musi pilnować kluczy.

Stan. Ruch. Nowy stan.

Najprostszy techniczny obraz QUAX-a wygląda tak:

Sₙ → Bₙ₊₁ → Sₙ₊₁

Mamy stan Sₙ.

Pojawia się kolejny blok Bₙ₊₁ z operacjami.

Reguły Protokołu mówią, jak te operacje wykonać.

Powstaje nowy stan Sₙ₊₁.

To jest maszyna stanu.

Brzmi okazale.

W praktyce oznacza coś bardzo konkretnego:

jeżeli dwie poprawnie działające maszyny startują z tego samego kanonicznego stanu, dostają te same poprawne operacje i wykonują te same reguły, powinny dojść do tego samego następnego stanu.

MODELUJEMY / PROJEKTUJEMY technicznie.

I od razu granica:

stan Protokołu ≠ stan całej rzeczywistości

Chain może wiedzieć, że konto ma 17 quaxów.

Nie musi wiedzieć, czy właściciel konta jest szczęśliwy.

Może zapisać deklarację celu.

Nie dostaje przez to dostępu do metafizycznie „prawdziwego” celu osoby.

Może zapisać zdjęcie Kaczki.

Kaczka nadal prowadzi własne życie.

Księga, która ma kilka kopii

QUAX Protocol jest projektowany jako rozproszona księga i maszyna stanu.

Nie istnieje tylko jedna kopia historii na jednym komputerze.

Różne nody mogą utrzymywać i sprawdzać jej kopię.

To daje kilka ważnych ról.

Node

Maszyna uczestnicząca w sieci i posiadająca albo wykonująca stan.

Full node

Node, który potrafi sam sprawdzić historię zamiast tylko wierzyć komuś innemu.

Validator

Full node posiadający dodatkową kompetencję udziału w consensus.

Proposer

Validator, który w danym momencie proponuje kolejny blok.

Worker

Wykonuje pracę, która może później stać się przedmiotem weryfikacji.

Attestor

Poświadcza coś zewnętrznego według jawnych zasad.

Wallet

Zarządza kluczem i podpisuje operacje.

I jedna z najważniejszych małych granic:

Node ≠ Validator

Każdy validator jest nodem.

Nie każdy node jest validatorem.

Posiadanie kopii księgi nie daje automatycznie prawa do decydowania, co stanie się następnym kanonicznym blokiem.

Consensus: wiele maszyn próbuje mówić jednym rytmem

Proposer przygotowuje blok.

Validatorzy go sprawdzają.

Wykonują zawarte w nim operacje.

Sprawdzają, czy wynik zgadza się z regułami.

Jeżeli zostaje osiągnięty wymagany próg consensus, blok staje się częścią kanonicznej historii Protokołu.

Czyli bardzo skrótowo:

propozycja → weryfikacja → consensus → Canon

I teraz zdanie, które będziemy powtarzać do znudzenia:

kanonizacja ≠ stworzenie Prawdy

Consensus mówi:

„według reguł tej sieci to jest obowiązujący wynik”.

Nie mówi automatycznie:

„Całość właśnie ujawniła nam swój ostateczny stan”.

To rozróżnienie jest fundamentem Protokołu QUAX-a.

Większość nie dostaje korony tylko dlatego, że jest większością

Validatorzy mogą wspólnie finalizować bloki.

Nie oznacza to, że consensus staje się najwyższą Authority konstytucyjną.

W Quaxie rozdzielamy:

consensus canonicalization ≠ constitutional legitimacy

Może istnieć poprawny technicznie consensus wykonujący wcześniej ustanowione reguły.

Ale validatorzy nie powinni móc po prostu zagłosować:

„od dziś sami jesteśmy źródłem wszystkich reguł, bo akurat mamy quorum”.

Nie tak działa ta architektura.

Authority jest typowana i nadawana wcześniej.

Stake może mieć znaczenie dla voting power, ale:

posiadanie quaxów ≠ automatyczne prawo do zostania validatorem

Roboczo:

Authority → Stake → VotingPower

Najpierw odpowiednia kompetencja.

Potem mechanika udziału.

Nie odwrotnie.

Genesis: ten drugi

Quax ma problem ze słowem Genesis.

Bo oczywiście ma dwa.

Jest Genesis Kosmogonii.

Bez-Kierunku.

FirstQuax.

Pierwsze „dokąd”.

I jest techniczne Genesis chaina.

To drugie jest znacznie mniej poetyckie.

Zawiera rzeczy w rodzaju:

• identyfikatora sieci;
• początkowego zestawu validatorów;
• kluczy publicznych;
• początkowego Authority;
• parametrów podaży;
• pierwszej wersji reguł;
• początkowych obiektów i domen.

Czyli:

FirstQuax ≠ Genesis block

FirstQuax może być kanonicznym obrazem początku możliwości kierunku.

Genesis chaina jest technicznym startem konkretnej księgi.

Jedno może symbolicznie rozmawiać z drugim.

Nie są tym samym mechanizmem.

Genesis Node: pierwsza maszyna

Każda historia techniczna potrzebuje miejsca, w którym zacznie się wykonywać.

W aktualnym modelu pierwszym takim miejscem ma być Genesis Node / Founding Node.

MODELUJEMY pierwszą realizację na Raspberry Pi 5.

To nie znaczy:

Raspberry Pi jest Quaxem.

Ani:

jeżeli Raspberry Pi umrze, umrze konstytucja.

Pierwszy Genesis Node ma pełnić kilka ról:

• full node;
• pierwszy i początkowo jedyny Founding Validator;
• proposer pierwszych bloków;
• pierwszy wykonawca FoundingAuthority;
• później możliwy archival / constitutional node.

To sporo kapeluszy na jeden mały komputer.

Dlatego Type Discipline znowu jest potrzebna.

Genesis Node ≠ FoundingAuthority

Genesis Node ≠ FoundingCredential

Maszyna wykonuje urząd.

Nie staje się urzędem.

Tak samo jak laptop prezesa nie zostaje prezesem po jego urlopie.

Root private key nie mieszka na Genesis Node

To ważny techniczny guardrail.

Genesis Node może uruchamiać pierwszą historię.

Nie powinien przez to przechowywać wszystkiego, co daje najwyższą Authority.

Root, RootHolder i RootCredential zostały już rozdzielone w Urząd nie jest człowiekiem.

Tutaj wystarczy pamiętać:

pierwsza maszyna ≠ najwyższy urząd ≠ osoba ≠ jej credential

Awaria sprzętu ma być awarią sprzętu.

Nie automatycznym kryzysem ontologicznym.

Najpierw jeden puls, potem kilka

Na początku Genesis Node może być jedynym validatorem.

To jest faza założycielska, nie docelowy model trwałej dominacji jednej maszyny.

Później QUAX ma przejść Continuity Transition.

W aktualnym modelu Root dopuszcza pierwszy zestaw Continuity Validators — cztery CM5.

Obraz wygląda mniej więcej tak:

RPi5 sam → dopuszczenie CM5 ×4 → stabilny consensus → Continuity Transition → CM5 ×4 utrzymują puls

Historyczny RPi5 może później przestać aktywnie walidować.

Może zostać artefaktem założycielskim, nodem archiwalnym albo konstytucyjnym.

Ale jego historyczne pierwszeństwo nie oznacza wiecznego monopolu.

I FoundingAuthority również nie znika tylko dlatego, że validator set się zmienił.

Znów:

lineage, urząd, sprzęt i aktualna rola to różne osie.

Puls może trwać, nawet kiedy prawo do wielkich ruchów jest niejasne

Tutaj wraca Constitutional Safe Mode.

Jeżeli powstaje poważny spór o najwyższą prawomocność — na przykład o RootHoldera, RootCredential albo FoundingAuthority — validatorzy nie mają po prostu przejąć całej władzy „dla dobra systemu”.

Mogą utrzymywać to, co da się bezpiecznie utrzymywać.

Puls.

Zwykłe operacje, których legalność nie zależy od spornego najwyższego Authority.

Ale nie mogą wyprodukować sobie nowej prawomocności.

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 jedna z tych zasad, które brzmią mniej spektakularnie niż FirstQuax.

A mogą uratować znacznie więcej danych.

Cztery rzeczy, które wszystkie nazywają się „branch”, jeśli nie uważasz

Technologia lubi słowo branch.

Quax też.

Niestety różne rzeczy mogą wyglądać podobnie językowo.

Dlatego Protocol twardo rozdziela:

Consensus fork

Techniczny rozjazd historii chaina / consensus.

Application branch

Alternatywna historia albo dane utrzymywane świadomie wewnątrz aplikacji.

A-002 branch

Spekulatywna metafizyczna możliwość rozgałęzienia historii rzeczywistości.

Canon Merge

Proceduralne połączenie albo reinterpretacja gałęzi Canonu.

Mogą się inspirować.

Mogą wyglądać dobrze na jednym diagramie.

Nie dostają przez to wspólnego silnika.

analogia ≠ mechanizm

Upgrade może być legalny i nadal zmienić tożsamość

Wyobraź sobie, że Protocol przechodzi dużą aktualizację.

Nowe API.

Nowe reguły consensus.

Nowa konstytucja.

Czy to nadal „ten sam Protocol”?

Zależy, o jaki rodzaj tożsamości pytasz.

Dlatego przed dużą transformacją QUAX chce używać Identity Contract.

Najpierw deklarujemy, co ma zostać zachowane.

Potem wykonujemy zmianę.

Dopiero później oceniamy wynik.

Nie odwrotnie.

Może się okazać, że upgrade:

• zachował lineage;
• zachował konstytucyjną tożsamość;
• zerwał kompatybilność API.

Albo odwrotnie.

Lineage ≠ Identity

Legalność zmiany również nie gwarantuje zachowania każdego rodzaju identity.

Protocol może przejść do nowej wersji bez udawania, że nic się nie zmieniło.

A-002 nie dostaje implementacji przez podobieństwo

Quax ustanawia spekulatywną możliwość plastyczności fizycznej przeszłości.

To nie znaczy, że blockchain QUAX-a implementuje dziś przycisk:

REWRITE REALITY.

Nie implementuje.

Nie ma obecnie obowiązkowego history_id opisującego metafizyczne gałęzie.

Nie ma mechanizmu consensus dla A-002.

Nie ma oracle mówiącego, która historia jest „naprawdę prawdziwa”.

Ale działa też druga strona.

Protocol nie dostaje metafizycznego immunitetu tylko dlatego, że jest kryptograficzny.

Jeżeli literalny A-002 dotyczy fizycznej historii świata, to dyski, podpisy, klucze i maszyny również należą do tego świata.

Dlatego kanoniczna granica brzmi:

protocol finality ≠ cross-history truth-ground

Finality mówi nam, co jest finalne w relewantnym wykonaniu Protokołu.

Nie ustanawia odporności na wszystkie możliwe historie, które dopuszcza filozofia Quaxa.

Protocol nie jest automatem do materializowania metafor

To być może najważniejsza granica tej warstwy.

Jeżeli Quax wymyśli coś ważnego filozoficznie albo mitycznie, nie oznacza to automatycznie, że trzeba natychmiast dodać pole do blockchaina.

FirstQuax nie jest transakcją Genesis.

S₀ nie jest numerem bloku.

Tarcie Wymiarowe nie jest consensus signal.

Kaczka nie dostaje specjalnej voting power.

Przodek Przyszły nie tworzy kanału P2P w czasie.

Requax Celu nie jest oracle prawdziwego przeznaczenia.

Myth Canon nie jest Protocol Canon.

To nie jest brak odwagi technologicznej.

To jest Type Discipline.

Jeżeli kiedyś któraś z tych rzeczy ma mieć skutki protokołowe, potrzebuje:

• jawnego schema;
• określonego Evidence;
• określonego Authority;
• określonych konsekwencji;
• i istotnej decyzji architektonicznej.

Czyli zwykle także ADR.

Po co więc Protocol?

Żeby Quax mógł mieć pamięć techniczną bez udawania pamięci absolutnej.

Żeby kilka maszyn mogło wspólnie utrzymywać stan.

Żeby można było odróżnić:

kto coś proponuje, kto sprawdza, kto ma Authority i co naprawdę zostało kanonizowane.

Żeby zmiana była wersjonowana.

Żeby urząd nie był sprzętem.

Żeby consensus nie był Bogiem.

Żeby piękny mit nie dostał przypadkiem uprawnień administratora produkcyjnego.

I żeby, kiedy Quax zaczyna działać w świecie technicznym, można było powiedzieć:

maszyna pamięta to, co kazaliśmy jej pamiętać.

Nie wszystko, co istnieje.