# Résumé Exécutif : Système d'Identité et Processus 4NK **Document complet:** [4NK_IDENTITY_AND_PROCESS_SPEC.md](./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:** ```rust 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 ├─ 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 ```rust ProcessState { commited_in: OutPoint, // UTXO Bitcoin pcd_commitment: PcdCommitments, // Merkle tree des données state_id: [u8; 32], // Merkle root (identifiant) keys: BTreeMap, // Clés de déchiffrement validation_tokens: Vec, // 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 ```rust RoleDefinition { members: Vec, // Process IDs des membres validation_rules: Vec, // Règles de modification storages: Vec, // Storages autorisés } ``` **Exemple:** ```rust 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 ```rust 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:** ```rust 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:** ```rust // 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) ```rust // 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: ```rust // ✅ 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: ```rust // ✅ 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: ```rust // ✅ 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:** 1. Owner crée le processus avec le contrat 2. Validator valide le contrat 3. Client signe le contrat 4. 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. **Rôles:** - **Demandeur** : Crée la demande - **Manager** : Valide < 1000€ - **Directeur** : Valide ≥ 1000€ - **Comptable** : Enregistre le paiement **Règles:** ```rust ValidationRule::new( 1.0, // 100% consensus vec!["amount", "beneficiary"], // Champs concernés 0.5 // 50% des devices du membre ) ``` --- ## 8. Architecture technique ### 8.1 Stack technologique | Composant | Technologie | Rôle | |-----------|-------------|------| | **sdk_common** | Rust (WASM-ready) | Types partagés, logique métier | | **sdk_client** | Rust → WASM | Bibliothèque cliente pour navigateurs | | **sdk_relay** | Rust + Tokio + Tungstenite | Relais WebSocket | | **sdk_storage** | Rust + Actix-web | Stockage clé-valeur HTTP | | **ihm_client** | TypeScript + Web Components | Interface utilisateur | | **Bitcoin Core** | C++ | Node Bitcoin (RPC + ZMQ) | | **Blindbit** | Rust | Filtres BIP158 (optimisation scanning) | ### 8.2 Dépendances clés ```toml [dependencies] sp_client = "0.2" # Silent Payments bitcoin = "0.30" # Bitcoin primitives secp256k1 = "0.27" # Cryptographie EC tokio-tungstenite = "0.20" # WebSocket async serde = "1.0" # Sérialisation zstd = "0.12" # Compression aes-gcm = "0.10" # Chiffrement rs-merkle = "1.4" # Merkle trees ``` ### 8.3 Flux de compilation ``` ┌──────────────┐ │ Rust Code │ │ (sdk_client) │ └──────┬───────┘ │ ▼ wasm-pack build --target web ┌──────────────────────┐ │ WebAssembly Module │ │ + JS Bindings │ └──────┬───────────────┘ │ ▼ npm install ┌──────────────────────┐ │ ihm_client │ │ (TypeScript) │ └──────────────────────┘ ``` --- ## 9. Métriques de performance ### 9.1 Taille des données | Élément | Taille | Localisation | |---------|--------|--------------| | **state_id** | 32 bytes | On-chain (OP_RETURN) | | **Signature Schnorr** | 64 bytes | Off-chain (validation_tokens) | | **ProcessState sérialisé** | ~500 bytes - 50 KB | Off-chain (sdk_storage) | | **Transaction Bitcoin** | ~250 bytes | On-chain | ### 9.2 Coûts Bitcoin | Opération | Coût (testnet) | Coût (mainnet) | |-----------|----------------|----------------| | **Création Process** | ~2500 sats | Variable (frais réseau) | | **Update Process** | ~2500 sats | Variable (frais réseau) | | **Oblitération** | ~2500 sats | Variable (frais réseau) | **Note:** Frais mainnet dépendent du feerate (sat/vB). ### 9.3 Latence réseau | Opération | Latence typique | |-----------|-----------------| | **Connexion WebSocket** | < 100 ms | | **Handshake** | < 500 ms | | **Commit proposal** | < 200 ms | | **Accumulation signatures** | 1-5 secondes | | **Broadcast Bitcoin** | < 1 seconde | | **Confirmation on-chain** | 10 minutes (1 bloc) | --- ## 10. Roadmap et évolutions futures ### 10.1 Court terme (Q4 2025) - ✅ Optimisation scanning Silent Payments (Blindbit v2) - ✅ Multi-relays (connexions simultanées) - ✅ Rate limiting sur sdk_relay - ✅ Hardware wallet support (Ledger, Trezor) ### 10.2 Moyen terme (2026) - 🔄 Gossip protocol P2P (résilience réseau) - 🔄 Recovery social (M-of-N recovery) - 🔄 Taproot multi-signatures (MuSig2) - 🔄 Lightning Network integration ### 10.3 Long terme (2027+) - 🚀 Zero-knowledge proofs (privacy) - 🚀 Cross-chain bridges (Liquid, other L2) - 🚀 Decentralized PKI (web of trust) - 🚀 Smart contracts (Simplicity, Bitcoin L2) --- ## Conclusion Le système 4NK offre une infrastructure décentralisée complète pour: ✅ **Identité souveraine** : Contrôle total des clés, multi-device ✅ **Collaboration sécurisée** : Processus à états avec validation distribuée ✅ **Auditabilité** : Traçabilité Bitcoin immuable ✅ **Confidentialité** : Chiffrement bout-en-bout ✅ **Résilience** : Pas de point de défaillance unique **Points forts:** - Architecture élégante (identité = cryptographie Bitcoin) - Pas de serveur central de confiance - Interopérabilité Bitcoin native - Flexibilité des rôles et permissions **Défis restants:** - Performance du scanning SP (amélioration continue) - UX du pairing (simplification nécessaire) - Adoption (éducation des utilisateurs) - Coûts mainnet (optimisation des frais) --- **Document complet:** [4NK_IDENTITY_AND_PROCESS_SPEC.md](./4NK_IDENTITY_AND_PROCESS_SPEC.md) **Code source:** [GitHub 4NK](https://git.4nkweb.com/4nk/) **Contact:** dev@4nkweb.com