0960e43a45
**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)
108 lines
4.6 KiB
Markdown
108 lines
4.6 KiB
Markdown
# 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) :
|
||
|
||
```json
|
||
{
|
||
"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 :
|
||
|
||
```json
|
||
{
|
||
"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)
|