
Co-fondateur de Cobo : Les lacunes du proof-of-reserve basé sur Merkle Tree et les pistes d'amélioration
TechFlow SélectionTechFlow Sélection

Co-fondateur de Cobo : Les lacunes du proof-of-reserve basé sur Merkle Tree et les pistes d'amélioration
Deux défauts fondamentaux des méthodes existantes de preuve de réserves basées sur l'arbre de Merkle.
Auteur : Jiang Changhao, cofondateur et CTO de Cobo
Suite à l'effondrement de FTX et à la crise de confiance qui a suivi vis-à-vis des institutions centralisées, CZ a appelé sur Twitter les exchanges à adopter une méthode de preuve de réserves basée sur l'arbre de Merkle afin de démontrer qu'ils n'avaient pas détourné les actifs de leurs utilisateurs. Plusieurs plateformes ont depuis répondu favorablement à cet appel en se préparant activement à publier leurs preuves de réserves, dans le but de rassurer leurs clients quant à la sécurité de leurs fonds. Toutefois, la méthode de preuve de réserves fondée sur l'arbre de Merkle présente certaines faiblesses structurelles. En particulier, les entités centralisées peuvent facilement contourner les vérifications contre le détournement d'actifs que cette méthode cherche à garantir.
Dans ce texte, j'exposerai deux défauts fondamentaux de la méthode actuelle de preuve de réserves et proposerai quelques pistes d'amélioration.
Fonctionnement actuel de la preuve de réserves
Afin d'atténuer l'asymétrie d'information entre les utilisateurs et les institutions centralisées, la preuve de réserves repose généralement sur une approche traditionnelle d'audit : une entreprise tierce, reconnue comme fiable par toutes les parties, produit un rapport attestant que les actifs détenus sur chaîne par l'institution (preuve de réserve) correspondent bien au total des soldes des utilisateurs (preuve de passif).
Concernant la preuve de passif, l'institution centralisée doit générer un arbre de Merkle contenant les informations des comptes utilisateurs ainsi que leurs soldes. L'arbre de Merkle constitue essentiellement une capture anonymisée et immuable des soldes des comptes. Chaque utilisateur peut alors calculer indépendamment le hachage de son propre compte et vérifier si celui-ci figure bien dans l'arbre.
Pour la preuve de réserve, l'institution doit fournir les adresses blockchain qu'elle détient, puis celles-ci doivent être validées et auditées. Une pratique courante consiste à exiger que l'institution fournisse des signatures numériques prouvant sa propriété des adresses sur chaîne.
Une fois la capture via l'arbre de Merkle et la vérification de propriété des adresses sur chaîne réalisées, l'auditeur compare les montants totaux respectifs du passif et de la réserve pour déterminer si l'institution a détourné ou non les fonds des utilisateurs.
Défauts de la méthode actuelle de preuve de réserves
1. Possibilité d'utiliser des fonds empruntés pour réussir l'audit
Un problème majeur de la méthode de preuve de réserves est que l'audit repose sur un instantané temporel précis, souvent réalisé tous les quelques mois, voire tous les quelques années. Ainsi, une bourse centralisée peut toujours détournement des fonds utilisateurs, puis aisément combler temporairement le manque grâce à des emprunts pendant la période d'audit.
2. Possibilité de collusion avec des tiers pour falsifier la preuve de réserve
La fourniture d'une signature numérique ne prouve pas nécessairement la propriété effective des actifs présents sur une adresse. Une institution centralisée peut s'entendre avec un tiers détenteur de fonds pour obtenir une preuve d'actifs sur chaîne. Ce tiers peut même utiliser les mêmes fonds pour appuyer simultanément plusieurs institutions différentes. Les méthodes d'audit actuelles peinent à détecter ce type de fraude.
Quelques idées pour améliorer la méthode de preuve
Un système idéal de preuve de réserves devrait permettre aux auditeurs et aux utilisateurs finaux de procéder à des vérifications en temps réel tant du côté des passifs que des réserves. Toutefois, cela impliquerait des coûts élevés et/ou un risque accru de divulgation des informations personnelles. Avec suffisamment de données, une société d'audit tierce pourrait même inférer, à partir de données anonymisées, les positions individuelles des utilisateurs.
Afin d'éviter la falsification de la preuve de réserve pendant les audits sans compromettre la confidentialité des utilisateurs, je propose ici deux grandes idées :
1. Audits aléatoires par échantillonnage
Effectuer des audits aléatoires à des intervalles imprévisibles rendrait très difficile pour une institution centralisée la manipulation des soldes de comptes et des actifs sur chaîne. Cette méthode dissuaderait également les comportements malveillants, car l'institution vivrait dans la crainte constante d'être prise en flagrant délit lors d'un audit inopiné.
Mise en œuvre concrète : la demande d'audit pourrait être envoyée aléatoirement par un organisme tiers de confiance à l'institution centralisée. À réception de l'instruction, celle-ci devrait générer un arbre de Merkle incluant les soldes des comptes utilisateurs à cet instant précis, identifié par une hauteur de bloc spécifique (preuve de passif).
2. Utilisation du schéma MPC-TSS pour accélérer la preuve de réserve
Durant un audit aléatoire, l'institution centralisée doit fournir rapidement la preuve de ses réserves. Cela constitue un défi important pour les plateformes (comme les exchanges) qui gèrent un grand nombre d'adresses sur chaîne. Même si l'institution stocke la majorité de ses actifs sur quelques adresses fixes (portefeuilles chauds ou froids), une part significative des fonds reste répartie sur de nombreuses adresses. Regrouper tous ces actifs vers quelques adresses publiques durant la période d'audit est une opération très longue. Ce délai laisse aux entités malhonnêtes le temps nécessaire pour recourir à des emprunts ou solliciter des aides financières afin de masquer un détournement.
Est-il possible pour une institution centralisée de prouver directement ses réserves depuis les adresses réelles où les actifs sont détenus, sans avoir à regrouper les fonds ? Une solution envisageable consiste à recourir à la technologie MPC-TSS (Multi-Party Computation Threshold Signature Scheme).
En résumé, le MPC-TSS est une technologie cryptographique avancée qui divise une clé privée en deux ou plusieurs fragments, chiffrés et détenus séparément par plusieurs parties. Ces détenteurs de fragments peuvent collaborer pour signer conjointement une transaction, sans jamais échanger leurs fragments ni reconstruire la clé privée complète. Cette technologie de coffrage MPC-TSS fait partie intégrante d’un produit récemment lancé par Cobo.
Dans ce cadre, un organisme tiers d'audit (cabinet d'avocats, cabinet comptable, fiduciaire, mandataire ou même autorité régulatrice) pourrait détenir un fragment de clé, tandis que l'institution centralisée conserverait les autres fragments. En fixant le « seuil » à une valeur supérieure à un, tous les actifs resteraient sous le contrôle de l'institution. Par ailleurs, afin de permettre à l'institution de générer un grand nombre d'adresses co-gérées par l'auditeur, la solution MPC-TSS doit supporter le protocole BIP32. Détenteur d'un fragment, l'auditeur peut ainsi identifier avec certitude l'ensemble des adresses blockchain de l'institution et calculer la taille totale de ses actifs à une hauteur de bloc donnée.
Remerciements
Je tiens à remercier mes collègues de Cobo, notamment Discus Fish (Shen Yu), Lily King, Jeanette, Tavia, Linfeng et Ellaine, pour leurs discussions enrichissantes et leurs suggestions constructives durant la rédaction de cet article.
Si vous êtes intéressé par la solution Cobo MPC WaaS (Wallet as a Service basé sur la technologie de signature seuil par calcul multipartite sécurisé, offrant des options d'autogestion ou de co-gestion), n'hésitez pas à contacter notre département Client Success. Nous serions ravis d’échanger avec vous sur les solutions de custody d’actifs Web3 et de sécurisation des positions DeFi.
Contactez Cobo : https://mpc.cobo.com/mpc-zh
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News













