PD-177 — Expression de besoin : Configurer wallet Ethereum et gestion clés privées¶

1. Contexte¶

L'architecture ProbatioVault prévoit un ancrage probatoire périodique sur blockchain publique (Ethereum L1 ou L2). Cet ancrage repose sur :

• La publication d'un Merkle root
• L'obtention d'un tx_id
• L'intégration de cette transaction dans une preuve composite auto-vérifiable

La plateforme doit disposer d'un wallet Ethereum opérationnel, permettant : - La signature et l'émission de transactions - La gestion sécurisée des clés privées associées - La traçabilité et l'audit des opérations blockchain

Ce besoin est structurant : sans wallet maîtrisé, l'ancrage blockchain ne peut être opéré de manière souveraine.

Dépendances existantes¶

PD-177 s'inscrit dans l'epic BLOCKCHAIN (PD-187). Deux stories précédentes cadrent l'environnement :

• PD-52 (Ethereum L2 Setup) : a défini une interface CustodyStrategy avec 3 modes de custody (S1=CloudHSM, S2=AWS KMS, S3=Hybrid). Seul S2 (AWS KMS secp256k1) est actif en V1 ; S1 et S3 sont des stubs.
• PD-55 (Worker ancrage blockchain) : consomme le wallet via TransactionService.sendAnchorTransaction() — il délègue 100% de la signature à la couche wallet sans jamais signer directement.
• PD-245 (Format preuve multi-chain) : a ajouté un champ blockchain: 'ethereum_l2' | 'tezos' au format de preuve, impliquant que le wallet doit être identifiable par type de blockchain.

2. Objectifs principaux¶

2.1 Identité blockchain maîtrisée¶

• Existence d'au moins une adresse Ethereum officielle ProbatioVault
• Cette adresse doit être documentée, traçable, et identifiable comme source d'ancrage probatoire
• Les transactions d'ancrage doivent pouvoir être publiquement associées à ProbatioVault

2.2 Capacité d'émission de transactions¶

• Signature cryptographique de transactions Ethereum
• Envoi de transactions vers Ethereum mainnet ou réseau L2 sélectionné (Polygon, Arbitrum — cf. PD-52)
• Chaque ancrage Merkle doit produire : un tx_hash, une confirmation réseau, une inclusion vérifiable dans un bloc

2.3 Gestion sécurisée des clés privées¶

• Les clés privées doivent être protégées contre : extraction, duplication, accès non autorisé
• Les clés doivent être isolées des autres composants applicatifs
• Les clés ne doivent jamais être exposées en clair dans les logs ou bases de données
• La compromission d'un serveur applicatif ne doit pas entraîner la compromission des fonds ni de l'identité blockchain

2.4 Auditabilité des opérations¶

• Chaque transaction blockchain doit être : journalisée, associée à un Merkle root interne, intégrée au mécanisme de preuve composite, traçable via un registre append-only
• Un tiers doit pouvoir vérifier : quel Merkle root a été ancré, à quelle date, via quelle transaction, avec quelle signature

2.5 Continuité d'exploitation¶

• Mécanisme de récupération du contrôle du wallet
• Procédure en cas de : perte d'accès, compromission suspectée, rotation planifiée
• ProbatioVault doit conserver la maîtrise durable de son identité blockchain sur plusieurs décennies

3. Non-objectifs (exclusions explicites)¶

• Pas de multi-wallet : un seul wallet actif à la fois (la gestion de multiples wallets n'est pas dans le périmètre)
• Pas de Tezos : le support Tezos (Ed25519) est prévu pour PD-58, hors périmètre PD-177
• Pas de DEX / DeFi : le wallet ne sera pas utilisé pour des interactions DeFi, uniquement pour l'ancrage probatoire
• Pas de gestion de tokens ERC-20 : seules les transactions natives (ETH/MATIC) sont concernées
• Pas de trading / transfert de fonds : le wallet sert exclusivement à publier des hashes sur la blockchain

4. Contraintes¶

4.1 Souveraineté¶

• L'architecture ProbatioVault exige une souveraineté infrastructurelle (principalement OVH, France, environnement restreint UE)
• Tension identifiée : Blockchain publique internationale vs souveraineté infrastructurelle — le wallet interagit avec un réseau public mondial tout en devant être hébergé souverainement

4.2 Cohérence avec le modèle HSM¶

• La plateforme repose sur un modèle HSM Cloud pour les signatures probatoires
• Tension identifiée : Les signatures blockchain (secp256k1) doivent-elles être alignées sur l'infrastructure HSM existante (qui ne supporte pas nativement secp256k1) ou isolées via AWS KMS ?
• Le besoin impose une cohérence cryptographique globale, sans redondance fragile

4.3 Modèle économique¶

• L'ancrage est mutualisé (toutes les 10 minutes ou 24h selon plan)
• Le wallet doit supporter un volume de transactions périodique
• Gestion maîtrisée des coûts (gas)
• Le service d'ancrage ne doit pas être interrompu pour des raisons opérationnelles liées au wallet (manque de fonds, gas trop élevé)

4.4 Compatibilité PD-52¶

• PD-52 a défini l'interface CustodyStrategy et le TransactionService. PD-177 doit s'inscrire dans cette architecture, sans la casser.
• Le mode S2 (AWS KMS) est le seul actif. Toute évolution doit rester compatible.

5. Scénarios d'échec et résultats inacceptables¶

Les situations suivantes sont explicitement inacceptables :

6. Tensions et conflits non résolus¶

7. Questions ouvertes¶

1. Rotation de clé : Quelle est la politique de rotation de la clé du wallet ? Une rotation implique un changement d'adresse — comment maintenir la continuité de l'identité blockchain ?
2. Seuil d'alerte gas : Quel seuil de solde minimum déclenche une alerte ? Quel mécanisme de refill ?
3. Multi-environnement : Comment gérer la distinction wallet testnet / wallet mainnet en termes de sécurité ?
4. Backup / disaster recovery : La procédure de récupération du wallet en cas de perte d'accès à AWS KMS est-elle documentée ?
5. Custody S1/S3 : Quand les modes S1 (CloudHSM) et S3 (Hybrid) seront-ils activés ? PD-177 doit-il préparer le terrain ?
6. Compliance : L'adresse Ethereum officielle doit-elle être déclarée quelque part (registre public, documentation juridique) ?

8. Indicateurs de succès¶

La story sera considérée comme satisfaisante lorsque :

• Une adresse Ethereum officielle est active
• Une transaction d'ancrage test a été émise et confirmée
• La clé privée est protégée selon les standards de sécurité internes
• Les transactions sont intégrées au registre probatoire append-only
• Un protocole de gestion / rotation / récupération est documenté

9. Intention stratégique¶

Ce besoin ne concerne pas uniquement un composant technique. Il engage :

• La crédibilité probatoire de la plateforme
• La continuité juridique des preuves
• La confiance investisseurs
• La pérennité sur 10–50 ans

Le wallet Ethereum constitue une brique d'identité publique irréversible. Sa configuration doit être pensée comme un élément fondateur de l'architecture ProbatioVault.