Proof of reserve

La construction comporte deux moitiés. Côté actifs, la plateforme publie les adresses on-chain qu'elle contrôle, et chacun peut lire leurs soldes directement sur la chaîne, le contrôle étant généralement démontré par la signature d'un message depuis chaque adresse. Côté clients, la plateforme hache chaque solde de compte dans une feuille d'un arbre de Merkle, combine les feuilles vers le haut et publie la racine, qui résume une longue liste de valeurs en un seul hash court.

Ce que cela apporte à un client individuel est réel: avec le chemin de preuve de sa propre feuille, il peut vérifier que son solde figurait dans le total revendiqué, sans qu'aucun solde d'un autre client ne soit divulgué. Remontez les soldes inclus jusqu'à la racine, comparez le total aux actifs on-chain, et la plateforme a montré que les actifs qu'elle détient couvrent les soldes qu'elle a inclus. Tout repose sur ce dernier mot.

Une preuve de Merkle montre que la plateforme détient assez d'actifs on-chain pour couvrir un instantané des soldes qu'elle a choisi d'inclure. Une preuve de Merkle ne dit rien de ce que la plateforme doit ailleurs, et les omissions sont précisément là d'où vient une défaillance. Une déclaration de solvabilité complète exige l'instantané des réserves, l'arbre des passifs et un audit par un tiers de tout ce qui est hors chaîne, y compris les prêts, les retraits en attente et les obligations envers les contreparties. Des actifs peuvent être empruntés et présentés comme réserves pendant que le prêt reste hors chaîne. Des actifs de clients peuvent être prêtés ou remis en garantie. Des dettes peuvent être dues en monnaie fiduciaire à des prêteurs, des contreparties ou des sociétés liées. Rien de tout cela n'apparaît dans une publication type.

Une plateforme peut donc réussir une proof of reserve et être insolvable, et ce n'est pas un point théorique: c'est ce que la construction permet. Une preuve digne de ce nom comporte trois parties, l'instantané des réserves on-chain, l'arbre de Merkle des passifs envers les clients et un audit par un tiers de tous les autres passifs, y compris la dette hors chaîne, les retraits en attente et les obligations envers les contreparties. Une publication qui contient les deux premières et pas la troisième répond à la moitié de la question.

Une proof of reserve est une photographie à un moment donné. Le lendemain matin, la plateforme peut déplacer des fonds, contracter de nouvelles dettes ou modifier son portefeuille de négociation, et la preuve publiée reste vraie pour un moment révolu. Une plateforme pourrait en principe emprunter des actifs, exécuter la preuve et les rendre, et rien dans l'élément publié ne le montrerait.

C'est pourquoi la fréquence et l'imprévisibilité comptent plus que la cryptographie. Une preuve mensuelle à une date choisie par la plateforme est plus faible qu'un flux continu, et une preuve à un moment aléatoire ou fixé de l'extérieur est plus difficile à contourner. Pour une contrepartie qui évalue une plateforme, les questions utiles sont la fréquence, qui choisit le moment, et si la série des preuves passées reste disponible pour comparaison.

Un flux de réserves transforme l'instantané en quelque chose de continu et de lisible par machine. Un réseau d'oracles lit les adresses de réserve et, dans certaines conceptions, une attestation sur des avoirs hors chaîne, puis publie le chiffre obtenu on-chain, où un smart contract peut le lire et agir en conséquence. Un protocole de prêt peut refuser de frapper des tokens contre un actif encapsulé dont le flux de couverture est devenu obsolète ou insuffisant, une exécution sans humain dans la boucle.

Le flux hérite des hypothèses de confiance du réseau qui le publie, si bien que les questions de la page sur la sécurité des réseaux d'oracles s'appliquent directement: quels opérateurs rendent compte, comment les valeurs sont agrégées, les conséquences d'un flux devenu obsolète. La page sur les réseaux d'oracles explique comment ces réseaux fonctionnent, et la page sur les réseaux eux-mêmes indique lesquels publient des données de réserve.

Les deux mots sont employés comme des degrés d'une même chose alors que ce sont des missions différentes. Une attestation est un rapport à une date donnée dans lequel un expert-comptable confirme des chiffres précis présentés par l'entreprise, selon le périmètre convenu par l'entreprise. Un audit financier examine les registres, les pratiques comptables et les opérations sur une période, et produit une opinion sur les états financiers dans leur ensemble.

La lecture d'une attestation commence donc par son paragraphe de périmètre et non par sa conclusion, car le périmètre est ce que l'entreprise a choisi. Quelles entités entraient dans le périmètre, quels actifs et quels passifs, à quelle date, et ce que l'expert-comptable n'a explicitement pas vérifié. Une attestation qui couvre les actifs à une date, avec les passifs hors périmètre, est exacte et presque inutile pour une question de solvabilité. Le nom du cabinet sur le rapport n'y change rien.

La construction de Merkle laisse fuir de la structure: le nombre de feuilles et la forme de l'arbre apprennent quelque chose à un observateur sur la clientèle, et un client qui vérifie sa propre feuille voit des hashes voisins. Les preuves à divulgation nulle de connaissance y répondent en permettant à une plateforme de prouver une affirmation, par exemple que le total des passifs est inférieur au total des réserves, sans révéler les soldes individuels ni leur nombre.

Ce que cela améliore, c'est la confidentialité et l'exhaustivité du contrôle, puisqu'une preuve peut être construite sur l'ensemble des soldes plutôt que client par client. Ce que cela ne change pas, c'est le problème des passifs: une preuve cryptographique sur les chiffres que la plateforme y a fait entrer hérite de tout ce qui a été laissé de côté. Une plateforme qui omet la dette hors chaîne des données d'entrée produit une preuve élégante d'une affirmation incomplète.

Pour un jeton de monnaie électronique ou un jeton se référant à un ou des actifs au sens de MiCA, l'adéquation de la réserve est une obligation supervisée et non une publication volontaire. L'émetteur doit maintenir une réserve d'actifs, la séparer de ses propres actifs et la faire détenir par des tiers, suivre une politique d'investissement limitée à des instruments liquides de haute qualité et publier régulièrement la composition et le montant de la réserve. Un droit de remboursement au pair s'y ajoute.

C'est un instrument différent de la preuve publiée par une plateforme elle-même, car un superviseur peut exiger les registres et agir en conséquence. Pour une banque qui évalue un stablecoin en euros, la lecture utile porte donc d'abord sur les publications réglementaires de l'émetteur et ensuite seulement sur une éventuelle preuve volontaire, et la réponse du hub sur les réserves des stablecoins traite la question de la composition. La page stablecoins en Europe présente les émetteurs qui opèrent dans ce cadre.

Un token représentant de l'or, un bon du Trésor ou un bien immobilier pose une version plus difficile du problème, car l'actif ne peut pas du tout être lu sur une chaîne. La vérification dépend des registres d'un dépositaire, d'un audit de coffre ou d'une inscription dans un registre, et tout ce qui arrive sur la chaîne est une attestation faite par quelqu'un au sujet de quelque chose situé ailleurs.

Les questions qui décident si un tel token vaut la peine d'être détenu portent donc sur la partie hors chaîne: qui détient l'actif, selon quel droit, si la détention est séparée du bilan propre de l'émetteur, qui l'audite et à quelle fréquence, et quelle est réellement la créance juridique du détenteur du token si l'émetteur fait défaut. La page sur l'or tokenisé traite ces questions pour une classe d'actifs, et les réponses diffèrent nettement d'un émetteur à l'autre.

Oui, pour ce qu'elle couvre, et l'erreur est de la traiter comme une déclaration de solvabilité. Une preuve confirme que des adresses précises détenaient des montants précis à un moment précis et que le solde d'un client faisait partie de l'ensemble. C'est plus que ce que la plupart des plateformes offraient avant que la pratique n'existe. Combinée à un audit des autres passifs, à un calendrier fréquent et à un moment que la plateforme ne contrôle pas, elle devient une preuve significative. Seule, c'est une publication d'actifs.

Cinq choses, dont la proof of reserve. Des états financiers audités couvrant les passifs et les capitaux propres, pas une attestation d'actifs. La confirmation de la manière dont les actifs des clients sont séparés et dans quelle juridiction. Le statut réglementaire et les autorisations de l'entité qui détient réellement les actifs. La fréquence et le contrôle du moment de la publication des réserves. Enfin, l'analyse juridique de ce que la contrepartie possède en cas d'insolvabilité, la question que tout le reste sert pour un établissement. La page sur la conservation de crypto-actifs présente les dispositifs qui répondent aux deuxième et troisième points.