158 lines
10 KiB
Markdown
158 lines
10 KiB
Markdown
# XION RELATIVISTE — spec v0 du protocole de réconciliation causale
|
|
|
|
> Deux space-cubions qui se retrouvent ont vécu des durées propres différentes, et aucune montre
|
|
> n'a raison contre l'autre (@ref{space-cubion:10}). Ce qu'on gèle ici : l'horloge logique de
|
|
> chaque space-cubion, l'estampille causale de chaque tsoin, et la sémantique de merge — dont la
|
|
> **décision RS-7 gelée** : le conflit est un **fork visible**, jamais un écrasement silencieux.
|
|
>
|
|
> J0bot · Août 2026 · AGPL-3.0 · **spec — v0** · `xion-relativiste-v0` · 🛸
|
|
> Convention : `[POSÉ]` = gelé/décidé · `[HYPOTHÈSE]` = attendu mais non prouvé.
|
|
> Régimes : RÉEL (physique/informatique établies) · PRÉSENT (à câbler dans le repo) · TURFU.
|
|
|
|
## 0. Ce que ce document gèle
|
|
|
|
La relativité interdit l'horloge universelle (relativité de la simultanéité, Einstein) ;
|
|
l'informatique distribuée a résolu exactement ce problème en l'abandonnant : ce qui compte n'est
|
|
pas le temps absolu mais l'**ordre causal** (Lamport, « Time, Clocks, and the Ordering of Events
|
|
in a Distributed System », CACM 1978). Le XION relativiste applique cette solution au réseau des
|
|
space-cubions : chaque événement est un tsoin estampillé d'un **vector clock**, le merge de deux
|
|
historiques est un **CRDT**, le transport est **DTN** (aucune simultanéité supposée, aucune
|
|
connexion permanente supposée). Tout est RÉEL au sens des régimes : chaque brique de ce protocole
|
|
est de l'informatique éprouvée — la seule nouveauté est de la brancher sur un problème de
|
|
physique. Le même mécanisme qui réconcilie deux forks d'une base réconcilie deux vaisseaux qui ont
|
|
vécu des temps propres différents.
|
|
|
|
## 1. L'horloge : le vector clock `[POSÉ]`
|
|
|
|
Chaque space-cubion `i` maintient un **vector clock** VC_i (Fidge 1988, Mattern 1989) : une map
|
|
`{id_cubion → compteur}` sur les cubions qu'il connaît. Règles gelées (les règles canoniques) :
|
|
|
|
1. **Événement local** (tout tsoin émis) : VC_i[i] += 1.
|
|
2. **Émission** : le tsoin part avec une copie du VC_i courant.
|
|
3. **Réception/merge** : VC_i ← max composante-par-composante(VC_i, VC_reçu), puis VC_i[i] += 1.
|
|
|
|
Ce que ça donne, et c'est tout ce qu'il faut (RÉEL) :
|
|
|
|
- **happened-before décidable** : e₁ → e₂ ssi VC(e₁) < VC(e₂) (≤ partout, < quelque part).
|
|
- **concurrence détectable** : e₁ ∥ e₂ ssi ni VC(e₁) ≤ VC(e₂) ni VC(e₂) ≤ VC(e₁). Deux tsoins
|
|
concurrents ont été émis dans des branches causalement disjointes — des lignes d'univers qui ne
|
|
se sont pas parlé. Le VC capture la **causalité complète**, pas une approximation.
|
|
|
|
Aucun champ « temps absolu » ne participe aux décisions du protocole. Le temps propre (horloge de
|
|
bord) reste enregistré à titre de témoin humain, jamais d'arbitre.
|
|
|
|
## 2. Le tsoin estampillé `[POSÉ]`
|
|
|
|
L'unité répliquée est le triplet gelé (@ref{adressage-generatif-triplet-v0:1}), enveloppé :
|
|
|
|
```
|
|
tsoin-relativiste = {
|
|
triplet : ( hash_générateur , coordonnées , hash_résidu ), // le format éternel, inchangé
|
|
vc : { id_cubion → compteur }, // l'estampille causale (§1)
|
|
auteur : empreinte GPG, // qui l'a émis
|
|
signature : GPG(triplet ‖ vc) // intégrité + non-répudiation
|
|
}
|
|
```
|
|
|
|
Le triplet lui-même **ne change pas** : le VC est une enveloppe de transport/merge, pas une
|
|
modification du format éternel. Le résidu reste chiffré GPG au repos et en transit ; les
|
|
générateurs restent des communs publics (@ref{adressage-generatif-triplet-v0:3}).
|
|
|
|
## 3. L'ALIGNEMENT décide quoi diffuser `[POSÉ]`
|
|
|
|
Au contact (amarrage §3 du CDS, ou simple passage radio), deux cubions comparent leurs
|
|
`hash_générateur` : l'ALIGNEMENT du triplet est une égalité de hash, décidable au bit. Tout
|
|
générateur commun ne sera jamais retransmis ; on ne diffuse que les tsoins dont le VC n'est pas
|
|
déjà dominé par le VC du récepteur, et pour ceux-là uniquement `(coordonnées, hash_résidu, vc,
|
|
signature)` + le résidu chiffré. C'est la réplication diff-only du triplet
|
|
(@ref{adressage-generatif-triplet-v0:5}), avec le VC comme filtre anti-doublon : **on ne
|
|
transporte que la surprise causalement neuve.**
|
|
|
|
## 4. Le merge `[POSÉ]` — et la décision RS-7 gelée
|
|
|
|
Le merge de deux historiques doit être **déterministe, commutatif, associatif, idempotent** — les
|
|
propriétés CRDT (Shapiro, Preguiça, Baquero, Zawirski, « Conflict-free Replicated Data Types »,
|
|
SSS 2011). Conséquence : l'ordre des retrouvailles ne compte pas, re-merger ne coûte rien, N
|
|
cubions qui se retrouvent dans n'importe quel ordre convergent vers le même état. C'est la
|
|
propriété qui rend l'essaim possible : aucun coordinateur, aucune session globale, jamais.
|
|
|
|
Cas par cas :
|
|
|
|
- **e₁ → e₂** (causalement ordonnés) : e₂ raffine e₁. Aucun conflit, le merge est l'union des
|
|
logs — l'histoire est simplement plus complète d'un côté.
|
|
- **e₁ ∥ e₂ sur des points différents** : union, trivialement.
|
|
- **e₁ ∥ e₂ sur le MÊME point** (même `hash_générateur` + mêmes `coordonnées`, résidus
|
|
différents) : c'est LE cas dur, la décision ouverte du triplet-v0 (« sémantique de merge des
|
|
résidus », @ref{adressage-generatif-triplet-v0}). **DÉCISION RS-7, GELÉE (11.08) :**
|
|
|
|
> **Multi-Value Register : les DEUX branches sont conservées et exposées comme FORK VISIBLE.**
|
|
> Jamais d'écrasement silencieux, jamais d'arbitrage automatique qui jette de l'information.
|
|
> **Divergence = branche, retrouvaille = merge, conflit = fork visible — au sens git.**
|
|
|
|
Le MV-Register est un CRDT spécifié (Shapiro et al. 2011 ; c'est la sémantique des « siblings »
|
|
de Dynamo/Riak, DeCandia et al., SOSP 2007) : la valeur d'un point devient l'ensemble des versions
|
|
concurrentes maximales, chacune avec son VC. La **résolution** d'un fork n'est jamais le fait du
|
|
protocole : c'est un **nouveau tsoin**, émis par un humain ou une règle de domaine explicite, dont
|
|
le VC domine toutes les branches — le fork se referme comme un merge commit, tracé, signé,
|
|
event-sourcé. Deux équipages qui ont pris des décisions incompatibles pendant des années de
|
|
désynchronisation relativiste retrouvent leurs deux histoires **intactes et côte à côte**, puis
|
|
tranchent en connaissance. Le protocole garantit qu'aucune branche ne disparaît sans un acte
|
|
explicite ; la gouvernance du choix reste politique, et c'est voulu (@ref{space-cubion:15}).
|
|
|
|
## 5. Le transport : DTN / Bundle Protocol `[POSÉ]`
|
|
|
|
Le réseau des space-cubions ne suppose **aucune simultanéité et aucune connectivité de bout en
|
|
bout** — exactement le modèle du Delay-/Disruption-Tolerant Networking : architecture RFC 4838
|
|
(Cerf et al., 2007), Bundle Protocol version 7 RFC 9171 (2022). Store-and-forward : chaque cubion
|
|
porte les bundles qu'il ne peut pas encore livrer, et tout contact (amarrage, survol, relais
|
|
laser @ref{space-cubion:11}) est une opportunité de livraison. Le DTN tourne déjà sur l'ISS —
|
|
« tsoin over Bundle Protocol » est une phrase de câblage, pas un programme de recherche. Latence
|
|
des heures, des années : indifférent — le VC ordonne, le bundle attend, le merge converge. Un
|
|
tsoin est un bundle ; un amarrage est un contact à très haut débit ; un cubion en croisière est
|
|
un nœud DTN qui muletise l'histoire de l'essaim.
|
|
|
|
## 6. Chemin de migration : du LWW au VC/MVR
|
|
|
|
**État réel du repo** : `StateReplicationController` (`app/Http/Controllers/StateReplicationController.php`)
|
|
fait du **newer-wins par horloge murale** — chaque entrée KV porte un `savedAt` ISO8601, `cmpAt()`
|
|
compare les instants, le plus récent gagne, et le cas « local plus récent » est déjà remonté dans
|
|
un tableau `conflicts` (kept: local). C'est du LWW : déterministe et idempotent, oui, mais il
|
|
**jette silencieusement une des deux écritures concurrentes** et fait confiance à des horloges
|
|
murales que la relativité (et le simple clock-skew) désynchronise. La STRUCTURE pull/apply est
|
|
bonne ; l'arbitre est le maillon à remplacer. Migration en quatre pas, chacun shippable :
|
|
|
|
1. **Double-estampille** : chaque entrée gagne un champ `vc` à côté de `savedAt` (les nœuds sont
|
|
les boxions/cubions du registre). Aucun comportement ne change — on pose l'horloge.
|
|
2. **VC d'abord, savedAt en secours** : `pull` compare les VC quand les deux entrées en ont un ;
|
|
dominance → apply/skip comme aujourd'hui. Sans VC des deux côtés, `cmpAt` reste l'arbitre
|
|
(rétrocompatibilité avec les nœuds non migrés — éternelle, comme il se doit).
|
|
3. **MVR** : VC concurrents → **plus d'écrasement ni de kept-local** : l'entrée devient
|
|
multi-branches `{branches: [{data, vc, savedAt, auteur}, …]}`, le rapport de pull expose le
|
|
fork, l'UI le montre comme git montre deux branches.
|
|
4. **Résolution = tsoin** : choisir/fusionner écrit une nouvelle valeur dont le VC domine toutes
|
|
les branches. Le fork se referme en merge tracé — jamais en oubli.
|
|
|
|
## 7. Garde-fous honnêtes `[HYPOTHÈSE]`
|
|
|
|
1. **Taille des VC.** Un VC croît avec le nombre de cubions rencontrés (O(n) par estampille). À
|
|
l'échelle de l'essaim (10⁶+ nœuds), il faudra de la compaction : deltas de VC, dotted version
|
|
vectors, ou VC hiérarchiques par agrégat (l'agrégat comme nœud composite). Non gelé — le
|
|
format §2 réserve la place, la stratégie reste ouverte.
|
|
2. **GC des branches et des logs.** Un MVR n'oublie jamais tout seul : sans résolution, les forks
|
|
s'accumulent. Politique de rétention/archivage à définir — mais l'oubli sera toujours un acte
|
|
explicite (droit au silence), jamais un effet de bord.
|
|
3. **Snapshots.** Rejouer un log de plusieurs années de croisière à chaque merge est absurde :
|
|
checkpoints d'état signés + log depuis le checkpoint. La profondeur de Bennett du triplet
|
|
s'applique ici aussi — déplier coûte du calcul, c'est le prix assumé.
|
|
4. **Perf du merge à l'amarrage.** Le handshake du CDS (§3) borne le temps d'ouverture du
|
|
passage ; le merge complet peut continuer en tâche de fond après l'ouverture — l'ordre causal
|
|
le permet, à prouver en charge.
|
|
5. **Sybil/identités.** Le VC fait confiance aux `id_cubion` ; la signature GPG de chaque tsoin
|
|
(§2) est la ligne de défense. Un cubion qui ment sur son VC signe son mensonge — détectable,
|
|
attribuable. L'audit systématique reste à spécifier.
|
|
|
|
---
|
|
|
|
*Ne pas nuire. Aucune montre n'a raison contre l'autre ; aucune branche ne meurt en silence.*
|
|
*AGPL-3.0 · Août 2026 · xion-relativiste-v0*
|