ncantu 0960e43a45 Optimisation mémoire api-anchorage avec base de données SQLite

**Motivations:**
- Réduction drastique de la consommation mémoire lors des ancrages
- Élimination du chargement de 173k+ UTXOs à chaque requête
- Stabilisation de la mémoire système sous charge élevée (50+ ancrages/minute)

**Root causes:**
- api-anchorage chargeait tous les UTXOs (173k+) via listunspent RPC à chaque ancrage
- Filtrage et tri de 173k+ objets en mémoire pour sélectionner un seul UTXO
- Croissance mémoire de ~16 MB toutes les 12 secondes avec 50 ancrages/minute
- Saturation mémoire système en quelques minutes

**Correctifs:**
- Création du module database.js pour gérer la base de données SQLite partagée
- Remplacement de listunspent RPC par requête SQL directe avec LIMIT 1
- Sélection directe d'un UTXO depuis la DB au lieu de charger/filtrer 173k+ objets
- Marquage des UTXOs comme dépensés dans la DB après utilisation
- Fermeture propre de la base de données lors de l'arrêt

**Evolutions:**
- Utilisation de la base de données SQLite partagée avec signet-dashboard
- Réduction mémoire de 99.999% (173k+ objets → 1 objet par requête)
- Amélioration des performances (requête SQL indexée vs filtrage en mémoire)
- Optimisation mémoire de signet-dashboard (chargement UTXOs seulement si nécessaire)
- Monitoring de lockedUtxos dans api-anchorage pour détecter les fuites
- Nettoyage des intervalles frontend pour éviter les fuites mémoire

**Pages affectées:**
- api-anchorage/src/database.js (nouveau)
- api-anchorage/src/bitcoin-rpc.js
- api-anchorage/src/server.js
- api-anchorage/package.json
- signet-dashboard/src/bitcoin-rpc.js
- signet-dashboard/public/app.js
- features/optimisation-memoire-applications.md (nouveau)
- features/api-anchorage-optimisation-base-donnees.md (nouveau)

2026-01-27 21:12:22 +01:00

4.6 KiB

Raw Blame History

Complément de specs – Champs obligatoires et attributs CNIL

Author: Équipe 4NK
Date: 2026-01-26

Référence : specs.md (Contrat, Champ, MessageBase, DataJson).

1. Champs obligatoires des contrats

Tous les contrats ont certains des champs (objets Champ) suivants. Chaque type correspond à un usage métier précis ; un contrat donné en possède un sous-ensemble selon le contexte.

Type de Champ	Description
Partage avec les institutions	Champ dédié au partage de données avec des institutions
Messages au RSSI	Messages au RSSI de la société responsable du service
Messages au Correspondant CNIL	Messages au Correspondant CNIL de la société responsable du service
Messages au Responsable cybersécurité	Messages au Responsable cybersécurité au bord de la société responsable du service
Messages de support infogérant	Messages de support de l'infogérant du service (peut inclure un membre du miner pour la gestion des clés API)
Messages de support administrateur système	Messages de support de l’administrateur système du service
Messages de support niveau 1	Messages de support de niveau 1 du service
Messages de support niveau 2	Messages de support de niveau 2 du service
Messages de support niveau 3	Messages de support de niveau 3 du service

Les Champ sont des MessageAValider avec contrats_parents_uuid (au moins 1).
L’identification du type (partage, RSSI, CNIL, cybersécurité, support N1/N2/N3, etc.) se fait via types.types_names_chiffres / types_uuid ou via des métadonnées dans datajson, selon les conventions du catalogue.

2. Attributs CNIL dans `datajson`

Pour les objets concernés (ex. contrats, champs), la partie datajson peut contenir des attributs CNIL supplémentaires. Ceux-ci sont optionnels au sens du schéma de base mais requis pour la conformité CNIL lorsqu’ils s’appliquent.

2.1 Usage et partage avec les tiers

Raisons de l’usage avec les tiers et description du tiers
Tableau de couples [raisons, tiers] : pour chaque usage avec un tiers, les raisons et la description du tiers.
Raisons du partage avec les tiers et description du tiers
Tableau de couples [raisons, tiers] : pour chaque partage avec un tiers, les raisons et la description du tiers.

Structure suggérée (à préciser dans le catalogue) :

{
  "raisons_usage_tiers": [
    { "raisons": ["…"], "tiers": "…" }
  ],
  "raisons_partage_tiers": [
    { "raisons": ["…"], "tiers": "…" }
  ]
}

2.2 Conditions de conservation

Conditions de conservation
Objet JSON contenant au moins le délai d’expiration (durée de conservation des données).

Exemple :

{
  "conditions_conservation": {
    "delai_expiration": "P1Y",
    "unite": "annees"
  }
}

(P1Y : ISO 8601 duration, ou équivalent selon le catalogue.)

3. Synthèse

Domaine	Contenu
Champs obligatoires	Sous-ensemble des 9 types (partage, RSSI, CNIL, cybersécurité, support infogérant / admin / N1 / N2 / N3) selon le contrat
`datajson` CNIL	`raisons_usage_tiers`, `raisons_partage_tiers` (tableaux [raisons, tiers]) ; `conditions_conservation` (JSON avec au moins `delai_expiration`)

4. Types (userwallet)

DataJson : champs optionnels raisons_usage_tiers, raisons_partage_tiers (RaisonsTiers[]), conditions_conservation (ConditionsConservation), membre_miner_uuid (référence au membre du miner pour les champs infogérant). Voir src/types/message.ts.

4.1 Membre du miner dans les champs infogérant

Pour les champs de type "Messages de support infogérant", le datajson peut contenir un champ membre_miner_uuid qui référence un membre du miner.

Caractéristiques du membre du miner :

Membre unique (sans 2FA, seul)
Créé spécifiquement pour le miner
Fait office de backend pour les clés API qu'il recevra et devra gérer (fonctionnalité à implémenter ultérieurement)

Usage :

Le champ membre_miner_uuid est optionnel dans DataJson
Il doit référencer un Membre valide avec types_names_chiffres incluant "membre"
Ce membre sera utilisé pour la gestion des clés API du miner (à documenter et implémenter ultérieurement)

5. Références

userwallet/docs/specs.md (MessageBase, DataJson, Champ, Contrat)
userwallet/docs/specs-champs-obligatoires-cnil.md (ce document)
userwallet/src/types/message.ts (DataJson, RaisonsTiers, ConditionsConservation)
userwallet/src/types/contract.ts (Champ)

4.6 KiB Raw Blame History Unescape Escape