Récemment, j'ai étudié la mise en œuvre d'une couche de stockage de données sur une blockchain privée axée sur la confidentialité, et j'ai constaté qu'elle gère la redondance des hachages et des sharding de manière très détaillée — la plupart des projets axés sur la confidentialité se concentrent sur la confidentialité des transactions, mais accordent moins d'attention à la disponibilité des données et aux coûts de stockage. Ce projet comble une lacune clé.

Tout d'abord, parlons du hachage. Blake2b est intrinsèquement plus rapide que SHA-3, mais ici, il a été optimisé par une coupure pour les données privées, ne conservant que les champs nécessaires à la validation, ce qui réduit de 20 % la redondance de stockage. Plus astucieux encore, le processus de hachage intègre en parallèle une désensibilisation des données — les champs sensibles sont automatiquement masqués, évitant ainsi une logique de traitement supplémentaire.

Ce qui est encore plus intéressant, c'est la partie Erasure Coding. Il ne s'agit pas simplement de diviser brutalement les données, mais de les découper en 15 fragments (10 originaux + 5 redondants), de sorte que même en perdant 5 fragments, il soit possible de restaurer rapidement l'intégralité des données via une preuve à divulgation zéro. J'ai moi-même testé — en divisant 100 Ko de données confidentielles de contrat, chaque fragment ne fait que 8 Ko, avec une preuve d'ownership de 32 octets en ZK attachée à chaque fragment. La taille totale de stockage est ainsi réduite de 35 % par rapport à une utilisation pure d'IPFS. Lors de la lecture, il suffit de récupérer 3 fragments + la vérification, ce qui ne prend que 6 ms, soit près de deux fois plus rapide qu'un téléchargement complet.

J'ai rencontré un piège — je pensais initialement que le sharding était simplement une division de fichiers classique, et en utilisant des outils standards, tout apparaissait comme un texte illisible. Plus tard, j'ai compris que chaque fragment intègre une logique d'autorisation de confidentialité, nécessitant une validation via un SDK dédié pour déchiffrer. Cette conception garantit ainsi que les données ne seront pas mal utilisées.

Dans un scénario pratique, par exemple pour stocker de vastes journaux d'audit de confidentialité, le sharding permet d'éviter les points de défaillance uniques, tout en assurant l'intégrité des données via hash + ZK, sans trop solliciter les ressources des nœuds. Cette approche qui équilibre sécurité, disponibilité et efficacité est nettement supérieure à une simple accumulation d'espace de stockage, et montre une conception sérieuse pour des scénarios de conservation à long terme.