Expression de Besoin — PD-52 : Setup connexion Ethereum L2¶
Story : PD-52 — Setup connexion Ethereum L2 (Polygon/Arbitrum) Epic : PD-187 — BLOCKCHAIN Date : 2026-02-12 Auteur : Claude (orchestrateur IA) Statut : Étape 0 — Expression de besoin
1. Problème et besoin utilisateur¶
Le problème fondamental : la dépendance au tiers de confiance¶
ProbatioVault garantit aujourd'hui l'intégrité et l'horodatage des documents via deux mécanismes :
- Signature HSM (CloudHSM, ECDSA P-384) : preuve cryptographique d'intégrité
- Horodatage TSA (RFC 3161) : preuve d'antériorité certifiée par une autorité externe
Ces deux mécanismes reposent sur des tiers de confiance centralisés. Si l'autorité TSA disparaît, si le HSM est compromis, ou si ProbatioVault cesse d'opérer, la vérifiabilité des preuves est fragilisée. Un adversaire sophistiqué pourrait théoriquement contester la neutralité du dispositif.
Le besoin : une ancre publique, décentralisée et inaltérable¶
L'ancrage blockchain répond à un besoin précis : publier un engagement cryptographique (hash Merkle root) sur un registre décentralisé que personne ne contrôle, créant ainsi une preuve d'existence indépendante de ProbatioVault.
Un utilisateur (ou un tiers vérificateur — juge, auditeur, expert) pourra :
- Récupérer la preuve Merkle d'un document
- Remonter jusqu'à la transaction blockchain publique
- Vérifier que le hash ancré correspond, sans aucune interaction avec ProbatioVault
Pourquoi PD-52 en premier¶
PD-52 est la fondation technique de l'ensemble de l'epic blockchain. Sans connexion L2 opérationnelle, aucune des stories suivantes (smart contract PD-53, worker d'ancrage PD-55, preuves Merkle PD-56, vérification composite PD-57) ne peut être implémentée.
2. Valeur ajoutée par rapport au dispositif TSA existant¶
| Dimension | TSA seul (actuel) | TSA + Blockchain (cible) |
|---|---|---|
| Indépendance | Dépend d'une autorité TSA centralisée | Preuve vérifiable sur registre public décentralisé |
| Pérennité | Liée à la survie de l'autorité TSA | Blockchain publique : pas d'entité unique à craindre |
| Vérification tierce | Nécessite accès au certificat TSA | Toute personne peut vérifier via un explorateur blockchain |
| Résistance à la contestation | Contestable si le TSA est compromis | Double preuve indépendante : TSA + blockchain |
| Conformité réglementaire | eIDAS (horodatage qualifié) | Complémentaire — enrichit le dossier probatoire |
| Transparence | Opaque pour les tiers | Transaction publique, auditable par quiconque |
En résumé : la blockchain ne remplace pas le TSA. Elle le complète en ajoutant une couche de preuve publique, décentralisée et résiliente — un filet de sécurité supplémentaire pour les cas de contestation les plus exigeants.
3. Critères de succès mesurables¶
| # | Critère | Mesure | Seuil |
|---|---|---|---|
| CS-1 | Connexion RPC opérationnelle | Appel eth_blockNumber réussi sur Polygon et Arbitrum | 100% de succès sur 10 appels consécutifs |
| CS-2 | Wallet fonctionnel | Création/chargement d'un wallet avec clé gérée HSM | Signature d'un message vérifiable on-chain |
| CS-3 | Estimation de gas | Estimation du coût d'une transaction type | Résultat cohérent (< 50% d'écart vs gas réel) |
| CS-4 | Envoi de transaction | Envoi d'une tx de test sur testnet (Polygon Amoy / Arbitrum Sepolia) | Confirmation en < 30 secondes |
| CS-5 | Résilience RPC | Failover automatique si le provider RPC primaire tombe | Bascule en < 5 secondes, transparent pour l'appelant |
| CS-6 | Monitoring | Métriques exposées : balance wallet, gas price, latence RPC | Dashboard ou endpoint /health dédié |
| CS-7 | Tests | Couverture unitaire ≥ 80%, tests d'intégration sur testnet | CI verte |
4. Contraintes techniques connues¶
Infrastructure existante à respecter¶
- NestJS : module
BlockchainModuleexistant (stub) avecAnchorServiceetMerkleService - HSM CloudHSM : le module crypto (PD-36) est opérationnel — les clés de wallet doivent être gérées via PKCS#11, pas en mémoire
- Jobs asynchrones : l'infrastructure BullMQ est en place avec les types
BLOCKCHAIN_ANCHORetBLOCKCHAIN_VERIFYdéjà définis - TypeORM : schéma
vault_secure, conventions UUID,timestamptz - Configuration : pattern
registerAs()avec variables d'environnement
Contraintes de sécurité¶
- Clé privée : JAMAIS en clair dans le code, les env vars, ou les logs. Stockage HSM ou HashiCorp Vault exclusivement
- Données on-chain : UNIQUEMENT des hash (SHA3-256). Aucune donnée utilisateur, aucun metadata identifiant
- Séparation des réseaux : testnet en dev/test, mainnet en production uniquement
- Rate limiting : les RPC publics limitent à ~25 req/s — prévoir provider payant ou fallback
Contraintes opérationnelles¶
- Volume : < 100 tx/jour — pas de batching obligatoire au lancement
- Budget gas : monitoring du solde wallet, alertes si < seuil critique
- Latence acceptable : l'ancrage est asynchrone (via jobs), pas de contrainte temps-réel
5. Alternatives et variations possibles¶
Choix de la librairie Web3¶
| Option | Avantages | Inconvénients | Recommandation |
|---|---|---|---|
| Ethers.js v6 | TypeScript natif, léger (~400 KB), API moderne, excellente doc | Écosystème plugins plus petit | Recommandé — alignement TypeScript/NestJS |
| Web3.js v4 | Historique, large communauté, plugins nombreux | Plus lourd (~1 MB), types moins précis | Viable mais moins idiomatique |
| Viem | Ultra-typé, performant, tree-shakeable | Plus récent, moins de recul en production | Alternative intéressante à considérer |
Choix du provider RPC¶
| Option | Coût | Fiabilité | Recommandation |
|---|---|---|---|
| Alchemy | Free tier (300M compute units/mois) | 99.9% SLA | Recommandé — supporte Polygon + Arbitrum |
| Infura | Free tier (100K req/jour) | 99.9% SLA | Backup viable |
| QuickNode | Free tier limité | Excellent | Trop limité en free tier |
| RPC publics | Gratuit | Variable, rate-limited | Fallback uniquement |
Stratégie de wallet¶
| Option | Sécurité | Complexité | Recommandation |
|---|---|---|---|
| HSM signing + Ethers.js Signer custom | Maximale (PKCS#11) | Élevée — custom Signer à développer | Recommandé — cohérent avec l'existant PD-36 |
| KMS AWS signing | Haute (AWS manage) | Moyenne — SDK AWS KMS + Ethers.js | Alternative si HSM trop complexe |
| Vault Transit engine | Haute (Vault gère les clés) | Moyenne | Alternative viable |
| Clé chiffrée en env var | Modérée | Faible | Non recommandé — insuffisant pour du probatoire |
Réseau L2 — double ou unique ?¶
| Option | Coût | Résilience | Recommandation |
|---|---|---|---|
| Polygon + Arbitrum (dual) | ~$0.002/tx cumulé | Maximale — si un L2 tombe, l'autre prend le relai | Recommandé — cohérent avec l'epic PD-187 |
| Polygon seul | ~$0.001/tx | Suffisante pour démarrer | MVP acceptable |
| Arbitrum seul | ~$0.001/tx | Bonne sécurité (rollup optimiste) | MVP acceptable |
6. Risques identifiés¶
| # | Risque | Impact | Probabilité | Mitigation |
|---|---|---|---|---|
| R-1 | Clé privée compromise | Critique — transactions non autorisées, perte de fonds | Faible (HSM) | Stockage HSM exclusif, audit d'accès, rotation de clé planifiée |
| R-2 | Provider RPC indisponible | Modéré — ancrage temporairement bloqué | Moyenne | Multi-provider avec failover automatique, file d'attente BullMQ avec retry |
| R-3 | Spike de gas price | Modéré — coût inattendu, transactions bloquées | Moyenne (événements réseau) | Gas price ceiling configurable, alertes budget, pause automatique si seuil dépassé |
| R-4 | Incompatibilité HSM ↔ secp256k1 | Élevé — CloudHSM supporte ECDSA P-256/P-384 mais Ethereum utilise secp256k1 | Élevée | Évaluer le support secp256k1 de CloudHSM ; si absent, basculer sur Vault Transit ou dérivation hybride |
| R-5 | Réorganisation de chaîne (reorg) | Modéré — transaction "confirmée" puis annulée | Faible (L2 finality rapide) | Attendre un nombre suffisant de confirmations avant de considérer l'ancrage comme final |
| R-6 | Évolution des L2 | Faible — changement d'API ou de modèle de gas | Moyenne à long terme | Architecture provider-agnostique, abstraction réseau |
| R-7 | Dépendance critique sur Ethers.js | Faible — librairie mature mais single-maintainer | Faible | Couche d'abstraction fine, migration possible vers Viem si nécessaire |
| R-8 | Conformité réglementaire | Modéré — régulation blockchain en évolution (MiCA, etc.) | Moyenne | Veille réglementaire, ancrage uniquement de hash (pas de données personnelles) |
Focus risque R-4 : compatibilité HSM / secp256k1¶
C'est le risque technique le plus structurant. Ethereum utilise la courbe secp256k1 pour ses signatures, tandis que CloudHSM AWS supporte principalement P-256 (secp256r1) et P-384 (secp384r1). Trois scénarios :
- CloudHSM supporte secp256k1 → intégration directe via PKCS#11, scénario idéal
- CloudHSM ne supporte pas secp256k1 → basculer sur AWS KMS (qui supporte secp256k1 via
ECC_SECG_P256K1) ou HashiCorp Vault Transit - Approche hybride → dérivation d'une clé secp256k1 à partir du HSM, stockée chiffrée dans Vault
Ce risque doit être investigué dès le début de la phase de spécification (étape 1).
Périmètre de PD-52 vs stories suivantes¶
Pour clarifier les frontières :
| Élément | PD-52 (cette story) | Story suivante |
|---|---|---|
| Connexion RPC Polygon/Arbitrum | Oui | |
| Wallet management (create/load/sign) | Oui | PD-177 (gestion avancée) |
| Gas estimation | Oui | |
| Envoi de transaction basique (testnet) | Oui | |
| Smart contract deployment | Non | PD-53 |
| Worker d'ancrage périodique | Non | PD-55 |
| Preuve Merkle individuelle | Non | PD-56 |
| Vérification composite | Non | PD-57 |
| Fallback Tezos | Non | PD-58 |
Synthèse¶
PD-52 pose les fondations techniques de l'ancrage blockchain de ProbatioVault. La story livrera :
- Un provider L2 multi-réseau (Polygon + Arbitrum) avec failover
- Un service de wallet intégré au HSM existant (avec investigation de compatibilité secp256k1)
- Un estimateur de gas avec monitoring des coûts
- Un service de transaction capable d'envoyer et confirmer des transactions sur testnet
Le tout dans le respect de l'architecture NestJS existante, de la sécurité HSM, et du modèle asynchrone via BullMQ — prêt à être exploité par les stories suivantes de l'epic PD-187.