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)
UserWallet API Relay
Serveur de relais pour le système de login décentralisé UserWallet.
Fonctionnalités
- Stockage des messages chiffrés (sans signatures ni clés)
- Stockage séparé des signatures
- Stockage séparé des clés de déchiffrement
- Relais entre pairs (inter-relay)
- Déduplication par hash
- Endpoints REST pour GET/POST
- Rate limiting (par IP)
- CORS configurable
- Logging structuré (Pino)
- Métriques Prometheus (
GET /metrics) - Compression des réponses (gzip)
- Indexation par
service_uuidpour GET /messages - Bloom filter des hash vus (
GET /bloom)
Installation
npm install
Configuration
Variables d'environnement :
PORT: Port d'écoute (défaut: 3019)HOST: Adresse d'écoute (défaut: 0.0.0.0)STORAGE_PATH: Chemin de stockage (défaut: ./data)PEER_RELAYS: Liste de relais pairs séparés par virgule (ex: http://relay1:3019,http://relay2:3019)SAVE_INTERVAL_SECONDS: Sauvegarde périodique (défaut: 300, 0 = désactivé)BODY_LIMIT: Taille max body JSON (défaut: 1mb)REQUEST_TIMEOUT_MS: Timeout requête HTTP (défaut: 30000)RATE_LIMIT_WINDOW_MS: Fenêtre rate limit (défaut: 60000)RATE_LIMIT_MAX: Requêtes max par fenêtre et par IP (défaut: 200)CORS_ORIGINS: Origines CORS autorisées, séparées par virgule (vide = toutes)LOG_LEVEL: Niveau log Pino (défaut: info, debug en dev)NODE_ENV: production | autre
Développement
npm run dev
Build
npm run build
npm start
Déploiement (systemd)
sudo cp api-relay.service /etc/systemd/system/
sudo systemctl daemon-reload
sudo systemctl enable api-relay
sudo systemctl start api-relay
start.sh build puis lance node dist/index.js.
Endpoints
Health
GET /health- Vérification de santé
Messages
GET /messages?start=<timestamp>&end=<timestamp>&service=<uuid>- Récupérer les messages dans une fenêtre temporellePOST /messages- Publier un message chiffréGET /messages/:hash- Récupérer un message par hash
Signatures
GET /signatures/:hash- Récupérer les signatures pour un messagePOST /signatures- Publier une signature
Clés
GET /keys/:hash- Récupérer les clés de déchiffrement pour un messagePOST /keys- Publier une clé de déchiffrement
Métriques
GET /metrics- Métriques Prometheus (relay_storage_entries par kind)
Bloom
GET /bloom- Bloom filter (JSON) des hash vus. Les clients peuvent l’utiliser pour éviter de demander des messages déjà connus.
Architecture
Le relais respecte la séparation stricte :
- Messages publiés sans signatures ni clés
- Signatures publiées séparément
- Clés publiées séparément
La déduplication par hash évite de relayer deux fois le même message.
Stockage
Stockage en mémoire avec persistance sur disque ({STORAGE_PATH}/messages.json). Sont persistés : messages, seenHashes, signatures, clés. Sauvegarde à l’arrêt (SIGINT/SIGTERM) et périodiquement si SAVE_INTERVAL_SECONDS > 0. En production, une base de données (SQLite, PostgreSQL, etc.) est recommandée.
Documentation
docs/synthese.md: synthèse (rôle, stack, structure, endpoints, config, stockage, déploiement, liens UserWallet).features/api-relay-evolutions.md: évolutions (build ESM, rate limit, CORS, métriques, bloom, etc.).