LeCoffre Deployment 56b602fcc3 docs+ops: vault sync workflow; deploy-all with live progress and URL checks; prompt updates

2025-10-01 19:27:49 +00:00

23 KiB

Raw Permalink Blame History

Résumé Exécutif : Système d'Identité et Processus 4NK

Document complet: 4NK_IDENTITY_AND_PROCESS_SPEC.md
Version: 1.0
Date: 1 octobre 2025

Vue d'ensemble en 5 minutes

Qu'est-ce que 4NK ?

4NK est un système décentralisé de gestion de processus collaboratifs qui utilise Bitcoin comme couche de consensus et les Silent Payments (BIP352) comme infrastructure d'identité cryptographique.

Concepts clés

┌─────────────────────────────────────────────────────────────┐
│                    SYSTÈME 4NK                              │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  IDENTITÉ                PROCESSUS              RÉSEAU     │
│  ┌─────────┐            ┌──────────┐          ┌─────────┐ │
│  │ Device  │───────────►│  State   │◄─────────┤ Relay   │ │
│  │ (SP)    │            │  Machine │          │ (WS)    │ │
│  └────┬────┘            └────┬─────┘          └─────────┘ │
│       │                      │                             │
│  ┌────▼────┐            ┌────▼─────┐                      │
│  │ Member  │            │  Roles   │                       │
│  │ (Pair)  │            │  Rules   │                       │
│  └─────────┘            └──────────┘                       │
│                                                             │
│  BLOCKCHAIN BITCOIN                                         │
│  ┌──────────────────────────────────────────────────────┐ │
│  │  UTXO → OP_RETURN(state_id) → UTXO → OP_RETURN ...  │ │
│  └──────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘

1. Système d'identité

1.1 Architecture d'identité à 3 niveaux

Niveau	Composant	Description	Exemple
1	Device	Appareil unique avec clés SP	Laptop, smartphone
2	Member	Groupe de devices pairés	Alice (laptop + mobile)
3	Process ID	Identifiant du pairing	OutPoint Bitcoin

1.2 Silent Payments (BIP352)

Pourquoi Silent Payments ?

✅ Adresses réutilisables sans compromettre la vie privée
✅ Dérivation cryptographique de clés publiques
✅ Interopérabilité native avec Bitcoin
✅ Multi-device via pairing process

Structure d'un Device:

Device {
    sp_wallet: SpWallet,                    // Portefeuille Bitcoin SP
    pairing_process_commitment: OutPoint,   // ID du processus de pairing
    paired_member: Member,                  // Groupe d'adresses liées
}

1.3 Pairing multi-device

Le pairing permet d'associer plusieurs appareils à une seule identité logique.

Flux simplifié:

1. Device A crée un processus "pairing"
   └─> State: { pairedAddresses: [addr_A] }

2. Device B scanne le QR code

3. Device B propose l'ajout
   └─> State: { pairedAddresses: [addr_A, addr_B] }

4. Device A signe (approuve)

5. Commit on-chain
   └─> Transaction Bitcoin avec OP_RETURN(state_id)

6. Les deux devices sont pairés
   └─> Peuvent signer au nom du Member

Sécurité:

Ajout : Signature des adresses existantes requise
Retrait : Consensus de tous les devices
Oblitération : Rôle "apophis" (destruction du processus)

2. Système de processus

2.1 Modèle de machine à états

Un Process est une succession d'états commitables sur Bitcoin.

Process = Vec<ProcessState>
  ├─ State 0: Empty (initial UTXO)
  ├─ State 1: Création (données + rôles)
  ├─ State 2: Update (modification)
  ├─ ...
  └─ State n: Empty (prochain UTXO)

Règle: Le dernier état est toujours vide, représentant l'UTXO à dépenser.

2.2 Structure d'un ProcessState

ProcessState {
    commited_in: OutPoint,              // UTXO Bitcoin
    pcd_commitment: PcdCommitments,     // Merkle tree des données
    state_id: [u8; 32],                 // Merkle root (identifiant)
    keys: BTreeMap<String, [u8; 32]>,  // Clés de déchiffrement
    validation_tokens: Vec<Proof>,      // Signatures
    public_data: Pcd,                   // Données publiques
    roles: Roles,                       // Rôles et permissions
}

Caractéristiques:

Immutable : Une fois committé on-chain, l'état est figé
Vérifiable : Merkle proofs pour chaque champ
Cryptographiquement prouvé : Signatures Schnorr obligatoires

2.3 Commitments cryptographiques

┌────────────────────────────────┐
│  Données privées (chiffrées)   │
│  ┌──────────┬─────────────┐    │
│  │  field1  │  "value1"   │    │
│  │  field2  │  "value2"   │    │
│  └──────────┴─────────────┘    │
└───────────────┬────────────────┘
                │
                ▼ Hash taggé
┌────────────────────────────────┐
│  PcdCommitments                │
│  ┌──────────┬─────────────┐    │
│  │  field1  │  hash1      │    │
│  │  field2  │  hash2      │    │
│  │  roles   │  hash_roles │    │
│  └──────────┴─────────────┘    │
└───────────────┬────────────────┘
                │
                ▼ Merkle Tree
┌────────────────────────────────┐
│  state_id (32 bytes)           │
│  = Merkle Root                 │
└───────────────┬────────────────┘
                │
                ▼ OP_RETURN
┌────────────────────────────────┐
│  Blockchain Bitcoin            │
│  Transaction avec state_id     │
└────────────────────────────────┘

Avantages:

Seul le state_id est on-chain (32 bytes)
Données privées restent off-chain (chiffrées)
Vérification cryptographique possible (Merkle proofs)

3. Validation et consensus

3.1 Système de rôles

RoleDefinition {
    members: Vec<OutPoint>,           // Process IDs des membres
    validation_rules: Vec<ValidationRule>, // Règles de modification
    storages: Vec<String>,            // Storages autorisés
}

Exemple:

Roles {
    "owner": RoleDefinition {
        members: [alice_pairing_id],
        validation_rules: [
            ValidationRule {
                quorum: 1.0,              // 100% des membres
                fields: ["roles"],         // Peut modifier les rôles
                min_sig_member: 1.0,      // Tous les devices
            }
        ],
    },
    "validator": RoleDefinition {
        members: [bob_id, carol_id],
        validation_rules: [
            ValidationRule {
                quorum: 0.67,             // 2/3 des membres
                fields: ["contract", "amount"],
                min_sig_member: 0.5,      // 50% des devices
            }
        ],
    },
}

3.2 Processus de validation

┌──────────────────────┐
│  Proposition d'état  │
└──────────┬───────────┘
           │
           ▼
┌──────────────────────────┐
│ Pour chaque champ modifié│
└──────────┬───────────────┘
           │
           ▼
┌─────────────────────────────┐
│ Trouver les rôles applicables│
└──────────┬──────────────────┘
           │
           ▼
┌────────────────────────────────┐
│ Vérifier le quorum              │
│ (proportion de membres)         │
└──────────┬─────────────────────┘
           │
           ▼
┌────────────────────────────────┐
│ Pour chaque membre validant:   │
│ Vérifier min_sig_member        │
│ (proportion de devices)         │
└──────────┬─────────────────────┘
           │
           ▼
┌────────────────────────────────┐
│ Vérifier les signatures Schnorr│
└──────────┬─────────────────────┘
           │
           ▼
      ✅ VALIDE ou ❌ REJETÉ

3.3 Signatures cryptographiques

Type: Schnorr (BIP340) sur secp256k1

Proof {
    signature: [u8; 64],    // Signature Schnorr
    public_key: PublicKey,  // Clé publique (33 bytes)
    message: [u8; 32],      // state_id
}

Messages signés:

ValidationYes : Approbation du state_id
ValidationNo : Rejet du state_id

Génération:

let message_hash = state.get_message_hash(true)?; // true = yes
let proof = Proof::new(message_hash, spend_key);
state.validation_tokens.push(proof);

4. Communication réseau

4.1 Architecture réseau

┌──────────────┐         WebSocket         ┌──────────────┐
│   Client A   │◄──────────────────────────►│  sdk_relay   │
│   (WASM)     │                            │   (Rust)     │
└──────────────┘                            └──────┬───────┘
                                                   │
┌──────────────┐                                   │
│   Client B   │◄──────────────────────────────────┤
│   (WASM)     │                                   │
└──────────────┘                                   │
                                                   ▼
                                           ┌───────────────┐
                                           │ Bitcoin Node  │
                                           │ (RPC + ZMQ)   │
                                           └───────────────┘

4.2 Types de messages (AnkFlag)

Flag	Direction	Description
Handshake	Relay → Client	Synchronisation initiale (peers, processes)
NewTx	Relay → Clients	Transaction Bitcoin détectée
Commit	Client ↔ Relay	Demande/validation de commit on-chain
Cipher	Client ↔ Clients	Données chiffrées (via relay)
Faucet	Client → Relay	Demande de fonds (testnet)
Sync	Client ↔ Relay	Synchronisation d'état

4.3 Flux de commit

Client A                Relay              Client B
   │                      │                    │
   │ 1. CommitMessage     │                    │
   │ (validation_tokens=[])                   │
   ├─────────────────────►│                    │
   │                      │ 2. Broadcast       │
   │                      ├───────────────────►│
   │                      │                    │
   │                      │ 3. Signature       │
   │                      │◄───────────────────┤
   │                      │                    │
   │ 4. CommitMessage     │                    │
   │ (validation_tokens=  │                    │
   │    [proof_A, proof_B])                    │
   ├─────────────────────►│                    │
   │                      │ 5. Validation      │
   │                      │    is_valid()      │
   │                      │                    │
   │                      │ 6. Tx Bitcoin      │
   │                      │    (broadcast)     │
   │                      │                    │
   │ 7. Confirmation      │ 7. Confirmation    │
   │◄─────────────────────┼───────────────────►│

5. Stockage et persistance

5.1 Niveaux de stockage

Couche	Type	Données	Chiffrement
Blockchain	Public	state_id (32 bytes)	❌ Non
sdk_storage	Semi-privé	Données volumineuses	✅ AES-256-GCM
Local	Privé	Wallet, clés	✅ Device-local

5.2 Format PCD (Private Collaborative Data)

┌─────────────────────────┐
│ Version: 0x01           │
├─────────────────────────┤
│ DataType:               │
│   0 = FileBlob          │
│   1 = JSON              │
├─────────────────────────┤
│ Data (compressed zstd)  │
└─────────────────────────┘

Utilisation:

// Insertion
let mut pcd = Pcd::new(BTreeMap::new());
pcd.insert_serializable("profile", &json!({"name": "Alice"}))?;

// Récupération
let profile: Value = pcd.get_as_json("profile")?;

5.3 Chiffrement

Algorithme: AES-256-GCM (AEAD)

// Génération clé
let key = Aes256Gcm::generate_key(&mut rng);

// Chiffrement
let cipher = Aes256Gcm::new(&key);
let nonce = Aes256Gcm::generate_nonce(&mut rng);
let ciphertext = cipher.encrypt(&nonce, plaintext)?;

// Stockage clé dans ProcessState
state.keys.insert("field_name", key.as_slice().try_into()?);

6. Sécurité

6.1 Garanties cryptographiques

Menace	Protection	Mécanisme
Usurpation d'identité	✅	Signatures Schnorr obligatoires
Modification non autorisée	✅	Validation multi-signatures + quorum
Replay attacks	✅	state_id unique (inclut outpoint)
Man-in-the-middle	✅	Messages signés cryptographiquement
Observation réseau	✅	Chiffrement AES-256-GCM
Perte d'un device	✅	Multi-device pairing

6.2 Modèle de confiance

Ce qui est vérifié cryptographiquement:

✅ Identité des signataires (Silent Payment addresses)
✅ Intégrité des données (Merkle commitments)
✅ Ordre des états (chaîne UTXO Bitcoin)
✅ Consensus (validation multi-signatures)

Ce qui nécessite de la confiance:

⚠️ sdk_relay (peut censurer, pas falsifier)
⚠️ sdk_storage (peut refuser de servir, pas modifier)
⚠️ Blindbit (optimisation, pas sécurité critique)

Aucune confiance requise:

✅ Bitcoin Core node (vérification SPV possible)
✅ Autres participants (signatures vérifiables)

6.3 Bonnes pratiques

Configuration des rôles:

// ✅ BON: Quorum élevé pour actions critiques
ValidationRule::new(0.67, vec!["roles"], 1.0)  // 2/3 consensus

// ❌ MAUVAIS: Quorum trop faible
ValidationRule::new(0.1, vec!["roles"], 0.1)   // 10% seulement

Pairing:

// ✅ BON: Au moins 2 devices
Member::new(vec![device1_addr, device2_addr])

// ⚠️ RISQUÉ: Un seul device (perte = perte d'accès)
Member::new(vec![device1_addr])

Chiffrement:

// ✅ BON: Données sensibles dans PCD privé
let private_data = json!({ "ssn": "123-45-6789" });

// ❌ MAUVAIS: Données sensibles en public
let public_data = json!({ "ssn": "123-45-6789" }); // Visible par tous!

7. Cas d'usage

7.1 Gestion de contrats

Scénario: Contrat de prestation entre une entreprise (3 signataires) et un client.

Rôles:

Owner : Entreprise (quorum 67%)
Validator : Service juridique (quorum 100%)
Client : Lecture + signature (quorum 100%)

Flux:

Owner crée le processus avec le contrat
Validator valide le contrat
Client signe le contrat
Commit on-chain (preuve horodatée immuable)

7.2 Signature électronique

Scénario: Signature de documents par plusieurs parties.

Avantages 4NK:

✅ Horodatage Bitcoin (immuable)
✅ Multi-signatures cryptographiques
✅ Traçabilité complète (audit trail)
✅ Documents chiffrés (confidentialité)

7.3 Identité décentralisée

Scénario: Gestion d'identité multi-device avec révocation.

Fonctionnalités:

Pairing/unpairing de devices
Attestations cryptographiques (signatures)
Révocation d'attestations (oblitération)
Portabilité (export/import du wallet)

7.4 Workflow d'approbation

Scénario: Processus d'approbation de dépenses dans une entreprise.