PD-53 — Expression de besoin¶

1. Contexte¶

ProbatioVault repose sur un mécanisme d'ancrage périodique des preuves cryptographiques via des Merkle roots générées à partir d'événements journalisés (append-only, WORM).

L'architecture probatoire prévoit :

1. Agrégation périodique des événements en arbre de Merkle
2. Signature HSM du Merkle root
3. Horodatage TSA qualifié
4. Ancrage sur blockchain publique ← PD-53
5. Génération de preuve composite vérifiable indépendamment

Ce besoin concerne uniquement la couche blockchain permettant d'inscrire publiquement l'empreinte Merkle.

Documents de référence¶

• Fiche brevet Preuve Composite Ancrée (805)
• Spécifications techniques Zero-Knowledge (42)
• Cahier d'Architecture Tech Lead v4.1 (41)
• PD-52 : Connexion Ethereum L2 (dépendance)

2. Objectif¶

Permettre à ProbatioVault d'ancrer de manière publique, immuable et vérifiable les Merkle roots générées par le système, via un smart contract déployé sur des blockchains compatibles Ethereum.

L'ancrage doit :

• Garantir l'intégrité publique des racines de Merkle
• Permettre la vérification indépendante hors système ProbatioVault
• Constituer une preuve opposable en cas de litige
• Être compatible avec la stratégie multi-chaînes (Polygon + Arbitrum)

3. Périmètre fonctionnel¶

3.1 Inclus¶

3.2 Exclus¶

4. Résultat attendu¶

À l'issue de PD-53 :

• Un smart contract Solidity existe et est déployé
• Il permet l'enregistrement d'un Merkle root via anchor(bytes32)
• Chaque ancrage produit une trace on-chain vérifiable
• Un tiers indépendant peut :
• Lire le contrat et les événements
• Récupérer la racine ancrée
• Vérifier qu'un hash donné a été ancré à une date donnée
• Vérifier la date via le timestamp du bloc

5. Exigences fonctionnelles¶

EF-1 — Enregistrement d'un Merkle Root¶

Le système doit permettre l'inscription d'un hash racine (bytes32) correspondant à un arbre de Merkle.

Signature : function anchor(bytes32 merkleRoot) external onlyOwner

Comportement : - Accepte un bytes32 non nul - Rejette si merkleRoot == bytes32(0) - Rejette si merkleRoot déjà ancré (unicité) - Émet un événement MerkleRootAnchored

EF-2 — Traçabilité publique¶

Chaque inscription génère un événement blockchain contenant :

event MerkleRootAnchored(
    bytes32 indexed merkleRoot,
    address indexed anchor,
    uint256 timestamp,
    uint256 blockNumber
);

EF-3 — Non-altérabilité¶

• Une racine déjà inscrite ne peut pas être modifiée
• Une racine déjà inscrite ne peut pas être supprimée
• Le contrat ne contient pas de fonction de mise à jour ou suppression

EF-4 — Vérifiabilité indépendante¶

Un tiers sans accès à ProbatioVault peut :

1. Lire le contrat via un explorateur (Polygonscan, Arbiscan)
2. Interroger les événements MerkleRootAnchored
3. Vérifier qu'un hash donné a été ancré : isAnchored(bytes32) → bool
4. Récupérer les métadonnées d'un ancrage : getAnchor(bytes32) → (address, uint256, uint256)

EF-5 — Identité contractuelle stable¶

Le contrat possède :

6. Exigences non fonctionnelles¶

ENF-1 — Coût maîtrisé¶

Le coût doit rester compatible avec le modèle économique mutualisé décrit dans la fiche brevet Preuve Composite.

ENF-2 — Scalabilité¶

ENF-3 — Pérennité¶

• Le contrat reste lisible et vérifiable indépendamment de ProbatioVault
• Le code source est vérifié et publié
• Aucune dépendance à un service externe (oracle, API)

ENF-4 — Simplicité¶

Le contrat doit rester minimaliste :

• Surface d'attaque minimale
• Coûts de gas minimaux
• Risques de bug minimaux
• Pas de pattern upgradable (doute probatoire)
• Pas de fonctions administratives complexes

7. Contraintes techniques¶

8. Hypothèses¶

9. Risques identifiés¶

10. Résultats inacceptables¶

11. Tensions à préserver¶

Simplicité vs Évolutivité¶

Un contrat minimaliste renforce la sécurité mais limite les évolutions futures.

Décision : Privilégier la simplicité. Un nouveau contrat peut être déployé si évolution majeure requise. L'historique reste accessible sur l'ancien contrat.

Coût vs Fréquence d'ancrage¶

• Ancrage fréquent = meilleure granularité probatoire
• Ancrage rare = réduction des coûts gas

Décision : Hors périmètre PD-53. La fréquence est déterminée par l'orchestrateur backend (PD-52).

Multi-chaîne vs Cohérence juridique¶

Multiplier les blockchains augmente la résilience mais complexifie la preuve judiciaire.

Décision : Deux chaînes (Polygon + Arbitrum) pour résilience. Un ancrage sur une chaîne suffit pour validité probatoire.

12. Indicateurs de validation¶

Le besoin sera satisfait si :

13. Synthèse¶

PD-53 crée la brique publique d'ancrage immuable du système Preuve Composite.

WORM → Merkle → HSM → TSA → [Blockchain] → Preuve Composite
                              ↑
                           PD-53

Le smart contract est un registre minimaliste d'empreintes garantissant :

• Immutabilité : aucune modification possible
• Transparence : événements publics et vérifiables
• Auditabilité : code source vérifié
• Opposabilité juridique : preuve indépendante de ProbatioVault

Livrables attendus¶

Auteur : Claude (orchestrateur) Date : 2026-02-16 Version : 1.0