4nk/4NK_env
5
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
4NK_env/docs/ARCHITECTURE_ANALYSIS.md

11 KiB
Raw Blame History

Analyse Architecturale Complète - 4NK Environment

Date : 2025-01-27 Version : 1.0 Contexte : Analyse complète de l'architecture 4NK et du projet LeCoffre

📋 Vue d'ensemble

Cette analyse présente l'architecture complète de l'environnement 4NK, incluant tous les modules 4NK, le projet LeCoffre, et le système de gestion des configurations via 4NK_vault.

🏗️ Architecture Générale

Environnement de Développement Centralisé

4NK_env/                           # Environnement centralisé
├── 4NK_modules/                   # Modules 4NK (SDK, services)
├── projects/lecoffre/             # Projet LeCoffre (notaires)
├── IA_agents/                     # Agents IA et documentation
├── docs/                          # Documentation centralisée
├── scripts/                       # Scripts de gestion centralisés
└── confs/                         # Configurations déployées (4NK_vault)

🔧 Modules 4NK - Analyse Complète

1. sdk_relay - Service de Relais WebSocket

Rôle : Relais central pour les communications WebSocket et la synchronisation mesh

  • Port : 8090 (WebSocket), 8091 (HTTP health)
  • Fonctionnalités :
    • Serveur WebSocket configurable
    • Synchronisation mesh entre relais
    • Gestion des processus et membres
    • Interface avec Bitcoin Core (RPC + ZMQ)
    • Intégration Blindbit pour Silent Payments
  • Dépendances : Bitcoin Core, Blindbit Oracle
  • Architecture : Rust avec gestion d'état locale

2. sdk_storage - Service de Stockage Temporaire

Rôle : Stockage temporaire sécurisé avec TTL

  • Port : 8081
  • API :
    • POST /store : Stockage avec clé/valeur/TTL
    • GET /retrieve/:key : Récupération des données
  • Fonctionnalités :
    • Stockage temporaire avec expiration
    • Clés hexadécimales 64 caractères
    • Valeurs hexadécimales
    • TTL optionnel (permanent si non spécifié)

3. sdk_signer - Service de Signature

Rôle : Service de signature TypeScript pour l'écosystème 4NK

  • Fonctionnalités :
    • Gestion des processus et signatures
    • Communication sécurisée
    • Compatibilité WASM (stub temporaire)
    • Interface avec le réseau de relais
  • Architecture : TypeScript avec support WASM
  • État : Compatible avec stub sdk_client

4. sdk_client - Client SDK

Rôle : Client SDK pour l'interaction avec l'écosystème 4NK

  • Fonctionnalités :
    • Interface avec les services 4NK
    • Gestion des connexions WebSocket
    • Support des processus et transactions
  • Architecture : Rust avec interface WebAssembly

5. sdk_common - Composants Communs

Rôle : Bibliothèque commune partagée entre tous les modules

  • Fonctionnalités :
    • Types et structures communes
    • Utilitaires partagés
    • Protocoles de communication
  • Usage : Importé par tous les autres modules

6. sdk-signer-client - Client Signeur

Rôle : Client pour l'interaction avec le service de signature

  • Fonctionnalités :
    • Interface avec sdk_signer
    • Gestion des signatures
    • Communication sécurisée

7. ihm_client - Interface Homme-Machine

Rôle : Interface utilisateur pour la gestion des clés et processus

  • Port : 3003
  • Fonctionnalités :
    • Interface de gestion des clés Bitcoin
    • Gestion des processus
    • Interface utilisateur web
  • Dépendances : sdk_relay, sdk_storage

8. 4NK_vault - Système de Gestion des Configurations

Rôle : API sécurisée pour la gestion centralisée des configurations

  • Port : 6666 (HTTPS)
  • Fonctionnalités :
    • Authentification par clés utilisateur
    • Chiffrement quantique résistant (ChaCha20-Poly1305)
    • Rotation automatique des clés
    • Résolution des variables d'environnement
    • Isolation par environnement (dev, prod)
  • Sécurité :
    • HTTPS obligatoire
    • Authentification par ID utilisateur
    • Clés individuelles par utilisateur/environnement
    • Rotation automatique (toutes les heures)
  • Déploiement : Synchronise les configurations vers confs/ dans le docker de contrôle

9. 4NK_certificator - Service d'Ancrage Cryptographique

Rôle : Ancrage périodique sur Bitcoin mainnet des empreintes des échanges

  • Fonctionnalités :
    • Surveillance des messages du relay 4NK
    • Détection des paiements Bitcoin
    • Enregistrement périodique sur blockchain
    • Métriques de volume de données
  • Architecture : Rust avec base de données SQLite
  • État : MVP complet implémenté

10. 4NK_miner - Service de Minage

Rôle : Service de minage Bitcoin (développement/test)

  • Fonctionnalités :
    • Minage sur réseau Signet
    • Génération de blocs de test
    • Interface avec le réseau Bitcoin

11. 4NK_web_status - Service de Statut

Rôle : Service de monitoring et statut des services

  • Fonctionnalités :
    • Monitoring des services
    • Interface de statut
    • Métriques de santé

12. blindbit-oracle - Oracle Bitcoin

Rôle : Service pour les paiements silencieux (Silent Payments)

  • Port : 8000
  • Fonctionnalités :
    • Génération d'adresses Silent Payments
    • Validation des transactions
    • Interface HTTP REST
  • Dépendances : Bitcoin Core

13. rust-silentpayments - Implémentation Silent Payments

Rôle : Implémentation Rust des Silent Payments

  • Fonctionnalités :
    • Génération d'adresses Silent Payments
    • Validation des transactions
    • Utilitaires cryptographiques

🏢 Projet LeCoffre - Architecture Notariale

Contexte Métier

Le projet LeCoffre est une plateforme de gestion de documents sécurisée pour les notaires, utilisant l'infrastructure 4NK pour la sécurité et l'intégrité des documents.

Composants du Projet LeCoffre

1. lecoffre_node - Orchestrateur Principal

Rôle : Docker de contrôle et déploiement pour LeCoffre

  • Architecture : Docker Compose avec Nginx intégré
  • Services déployés :
    • lecoffre-front (interface utilisateur)
    • ihm_client (gestion des clés)
    • sdk_relay (relais WebSocket)
    • sdk_storage (stockage temporaire)
    • bitcoin-signet (nœud Bitcoin)
    • blindbit-oracle (oracle Bitcoin)
    • tor-proxy (proxy anonyme)
    • Services de monitoring (Grafana, Loki, Promtail)
  • Configuration : Centralisée dans confs/ (synchronisée depuis 4NK_vault)
  • Déploiement : Scripts automatisés avec phases de démarrage

2. lecoffre-front - Interface Utilisateur

Rôle : Frontend Next.js pour l'application LeCoffre

  • Technologie : Next.js avec React
  • Fonctionnalités :
    • Interface utilisateur pour les notaires
    • Gestion des documents
    • Intégration avec l'écosystème 4NK
  • Déploiement : Conteneur Docker sur port 3004

3. lecoffre-back-mini - Backend Centralisé

Rôle : Backend centralisé pour les besoins spécifiques des notaires

  • Fonctionnalités :
    • APIs avec Stripe (paiements)
    • Intégration Mailchimp (email marketing)
    • Intégration OVH (SMS)
    • Intégration IdNot (HMR dev3 ↔ dev4 via OAuth2)
  • Déploiement : Sur dev3.4nkweb.com
  • Architecture : Service centralisé indépendant

🌐 Architecture de Déploiement

Environnements

  • dev4.4nkweb.com : Machine principale (LeCoffre)
  • dev3.4nkweb.com : Nœud de bootstrap (signer centralisé, mini back)

URLs et Services

Architecture de Déploiement par Phases

Phase 1: Services de Base (Parallèle)

  • tor, sdk_storage, status-api

Phase 2: Services Blockchain (Séquentiel)

  • bitcoin → blindbit → sdk_relay

Phase 3: Services Applicatifs (Séquentiel)

  • lecoffre-front, ihm_client

Phase 4: Services de Monitoring (Indépendant)

  • loki → promtail → grafana

Phase 5: Services Utilitaires

  • watchtower

🔐 Sécurité et Configuration

4NK_vault - Gestion Centralisée des Configurations

  • Rôle : API sécurisée pour la gestion des configurations
  • Sécurité : Chiffrement quantique résistant, authentification par clés
  • Déploiement : Synchronise vers confs/ dans le docker de contrôle
  • Isolation : Variables d'environnement protégées, fichiers .env inaccessibles

Protection des Secrets

  • Fichiers .env : Inaccessibles pour des raisons de sécurité
  • Variables : Séparées des secrets, remplacées dans storage/
  • Configurations : Copie déployée dans confs/ pour visualisation

🤖 Agents IA - Organisation

Structure IA_agents/

  • README.md : Documentation principale et règles obligatoires
  • deployment-architecture.md : Architecture de déploiement par phases
  • best-practices-deployment.md : Bonnes pratiques et interdictions
  • prompts/ : Prompts spécialisés pour différents aspects
  • todo.md : Liste des améliorations et optimisations

Règles Critiques pour les Agents IA

  1. Interdictions absolues : Pas de docker compose up -d direct
  2. Scripts obligatoires : Utilisation des scripts spécialisés
  3. Phases respectées : Ordre de démarrage par phases
  4. Monitoring indépendant : Services de monitoring séparés
  5. Surveillance continue : Suivi de progression obligatoire

📊 Monitoring et Observabilité

Stack de Monitoring

  • Grafana : Dashboards et visualisation
  • Loki : Collecte et stockage des logs
  • Promtail : Agent de collecte des logs
  • Watchtower : Mise à jour automatique des images

Dashboards Disponibles

  • Vue d'ensemble LeCoffre
  • Bitcoin & Miner
  • Services Applications
  • SDK Services
  • Frontend Services

🔄 CI/CD et Déploiement

Branches et Tags

  • Branche unifiée : ext pour tous les dépôts
  • Tag Docker : ext pour toutes les images
  • Déclenchement : Push sur ext → Build automatique

Scripts de Déploiement

  • start.sh : Démarrage complet avec phases
  • validate-deployment.sh : Validation du déploiement
  • maintenance.sh : Menu de maintenance interactif
  • backup-data.sh : Sauvegarde des données
  • update-images.sh : Mise à jour sécurisée

📚 Documentation Centralisée

Structure docs/

  • Architecture : Spécifications techniques
  • Déploiement : Guides de déploiement
  • Services : Documentation par service
  • Scripts : Documentation des scripts

Mise à Jour Continue

  • IA_agents/ : Documentation pour les agents IA
  • docs/ : Documentation technique centralisée
  • Alignement : Synchronisation entre code et documentation

🎯 Points Clés de l'Architecture

1. Séparation des Responsabilités

  • Services applicatifs indépendants du monitoring
  • Monitoring observant sans impacter
  • Dépendances uniquement métier

2. Sécurité Multi-Niveaux

  • 4NK_vault pour la gestion centralisée des configurations
  • Chiffrement quantique résistant
  • Isolation des secrets et variables

3. Déploiement Optimisé

  • Phases de démarrage respectées
  • Scripts spécialisés obligatoires
  • Surveillance continue et diagnostic facilité

4. Maintenance Facilitée

  • Redémarrage sélectif possible
  • Scripts de maintenance interactifs
  • Documentation centralisée et à jour

Document créé le 2025-01-27 Version : 1.0 Usage : Documentation architecturale complète pour les agents IA et l'équipe de développement