Principaux points à retenir

  • En novembre 2022, Binance a publié son système de preuve de réserves utilisant la cryptographie arborescente Merkle pour permettre aux utilisateurs de vérifier leurs avoirs.

  • Binance a maintenant amélioré sa solution en implémentant des zk-SNARK, une forme de preuve sans connaissance.

  • Les utilisateurs peuvent désormais vérifier que le solde net total de chaque compte n'est pas négatif et que tous les actifs des utilisateurs font partie du solde net total des actifs des utilisateurs revendiqué par Binance – de manière privée et sécurisée.

Jetez un œil sous le capot de la nouvelle solution de preuve de réserves de Binance. Combinant les informations des zk-SNARK et de l'arbre Merkle, il offre aux utilisateurs un moyen nouveau et amélioré de vérifier l'état des réserves de Binance.

Au cours des derniers mois, l’équipe de développement de Binance a travaillé dur pour créer des solutions avancées de preuve de solvabilité. De tels outils sont devenus essentiels pour les échanges cryptographiques centralisés au milieu de la crise de confiance qui a englouti le secteur à la suite de l’effondrement de FTX. Les fonds des utilisateurs stockés sur Binance sont garantis selon un ratio de 1:1, plus les réserves, et trouver un moyen de le prouver au public de manière transparente est devenu un élément majeur du plan de Binance visant à restaurer la confiance de l'industrie.

En novembre 2022, nous avons lancé notre système de preuve de réserves utilisant une technique cryptographique d'arbre Merkle pour permettre aux utilisateurs de vérifier leurs avoirs sur Binance. Bien qu’il s’agisse d’une avancée dans la transparence des fonds des utilisateurs de Binance, la conception initiale de cette solution présentait deux lacunes :

  1. Pour protéger la confidentialité des utilisateurs, les nœuds feuilles dans la preuve Merkle représentaient le hachage des avoirs des utilisateurs – ainsi, la racine Merkle ne pouvait pas refléter la somme des informations de solde de ses nœuds feuilles.

  1. L'entité dont les réserves étaient vérifiées pourrait potentiellement ajouter un solde négatif sous un faux compte quelque part dans l'arborescence pour faire paraître le total des réserves requises plus petit. Le diagramme suivant du blog de Vitalik Buterin montre un exemple d’un tel arbre Merkle malveillant (bien que, dans ce cas, la racine reflète la somme des soldes de tous les nœuds feuilles, ce qui peut introduire des problèmes de confidentialité).

Nous disposons désormais d’une solution qui peut remédier à ces lacunes et ainsi renforcer le système de preuve de réserves de Binance. En nous appuyant sur des protocoles à preuve de connaissance nulle, les zk-SNARK, nous pouvons prouver que :

  1. Tous les nœuds feuilles de l’arbre Merkle ont contribué au solde utilisateur total revendiqué par Binance pour chaque actif.

  2. Aucun utilisateur n'a un solde net total négatif (une valeur globale en USD de tous les actifs détenus par l'utilisateur) inclus dans l'arborescence Merkle.

Un mot sur les soldes négatifs et les performances

Étant donné que Binance propose des produits sur marge, des prêts cryptographiques et des produits de trading à terme, le solde de chaque utilisateur de chaque actif cryptographique peut être composé d'actifs et de passifs. Le solde d’un utilisateur sur un actif cryptographique particulier peut être négatif, mais son solde net total sur tous les actifs cryptographiques ne doit pas être négatif (car tous les prêts sont entièrement garantis).

Dans ce scénario hypothétique, disons qu'Alice a déposé 10 000 BUSD sur Binance, puis a utilisé 4 000 BUSD comme garantie pour emprunter 2 BNB (au taux de 1 BNB = 1 000 BUSD, en supposant que Binance sur-garantit toujours). Le tableau suivant présente le bilan d’Alice.

BNB (prix : 1000 BUSD)

BUSD (prix : 1 BUSD)

Solde net total (BUSD)

Actifs

Passifs

Actifs

Passifs

Alice

2

2

10000

0

10000

Si Alice échange ensuite 1 BNB contre 1 000 BUSD avec Bob (qui a également déposé 10 000 BUSD), leur bilan ressemblerait à ceci une fois la transaction appariée :

BNB (prix : 1000 BUSD)

BUSD (prix : 1 BUSD)

Solde net total (BUSD)

Actifs

Passifs

Actifs

Passifs

Alice

1

2

11000

0

10000

Bob

1

0

9000

0

10000

Dans ce cas, le solde BNB d’Alice s’élèvera à -1, ce qui n’est pas un nœud valide dans un arbre Merkle et qui ne couvre qu’un seul actif : le BNB. Cependant, si nous regardons les soldes nets totaux, Alice est toujours à 10 000.

Un autre défi vient de l’ampleur de la base d’utilisateurs de Binance. Une solution viable doit générer une preuve utilisateur et une preuve zk-SNARK pour des dizaines de millions d’utilisateurs, dont certains peuvent détenir plus de 300 actifs cryptographiques sur notre plateforme.

Au total, nous souhaitons apporter la preuve des faits suivants dans un délai raisonnable :

  1. Les actifs de chaque utilisateur de Binance font partie de notre solde utilisateur total déclaré indiqué dans l'instantané. Les utilisateurs peuvent vérifier notre solde total d'utilisateur revendiqué par rapport aux actifs détenus aux adresses contrôlées par Binance à l'aide d'un explorateur de blockchain (comme Etherscan pour les portefeuilles Ethereum ou BscScan pour les portefeuilles BNB Chain).

  2. Le solde net total de chaque utilisateur n'est pas négatif, ce qui signifie que Binance n'a pas créé de comptes factices avec un solde négatif pour réduire artificiellement la taille de nos réserves vérifiées.

Que sont les zk-SNARK ?

Avant de plonger dans les détails de notre solution, un bref aperçu du mécanisme de preuve sans connaissance s'impose. Les protocoles à connaissance nulle comme zk-SNARK permettent à une partie, le prouveur, de démontrer à une autre partie, le vérificateur, que le prouveur a exécuté certains calculs avec précision avec certaines entrées sous certaines contraintes, le tout sans divulguer les entrées. Le calcul peut prendre du temps, mais le mécanisme mathématique sous-jacent peut aider le vérificateur à évaluer la preuve rapidement et en toute sécurité.

Le prouveur (Binance) commence par définir un ensemble de contraintes du calcul qu'il souhaite prouver. Les contraintes sont définies dans des circuits qui peuvent être exprimés dans un langage de programmation de niveau supérieur (dans notre cas, une version forkée de gnark.)

Le prouveur exécute ensuite le calcul lourd, hachant les identifiants et les bilans de tous les utilisateurs, et génère la preuve du calcul répondant aux contraintes énoncées précédemment. Pour ce faire, il utilise la trace de calcul (témoin) et des entrées publiques ou privées.

Le vérificateur (utilisateur) obtient la preuve et la vérifie avec l'entrée publique du circuit pour s'assurer que le calcul a été exécuté avec précision avec toutes les contraintes respectées. Le calcul de vérification prend un temps extrêmement court par rapport au temps de preuve. Si le prouveur ne génère pas la preuve sur les circuits prédéfinis, il ne peut pas produire une preuve valide pour réussir la vérification.

Pour approfondir le capot des zk-SNARK, vous pouvez vous référer à cette série d'articles.

Notre solution

L’élément fondamental de la solution de preuve de réserves améliorée reste l’arbre Merkle. Pour l’exemple ci-dessus, cela ressemblerait à ceci :

En plus de l'arbre Merkle, nous maintenons également un état global qui représente une liste des soldes nets totaux de chaque actif détenu par chaque client Binance.

Pour prouver nos réserves, nous générerons une preuve zk-SNARK pour la construction de l'arbre Merkle. Pour l’ensemble d’équilibre de chaque utilisateur – un nœud feuille de l’arbre Merkle – notre circuit garantirait que :

  1. Le solde de chaque actif de cet utilisateur est inclus dans la liste d’état globale mentionnée ci-dessus.

  2. Le solde net total de l’utilisateur n’est pas négatif.

  3. La modification de la racine de l'arborescence Merkle est valide après la mise à jour des informations de cet utilisateur avec le hachage du nœud feuille.

Veuillez vous référer à cette spécification technique et à notre code source du circuit (contraintes) pour les détails de mise en œuvre.

A chaque preuve de nos réserves, nous publierons :

1. La preuve Merkle : les hachages pour chaque utilisateur (pour Alice, représentés par des nœuds bleus dans l'image ci-dessus).

2. Preuves zk-SNARK et entrée publique (un hachage de la liste des soldes nets totaux de chaque actif et la racine Merkle) du circuit pour tous les utilisateurs.

En vérifiant la preuve Merkle, les utilisateurs peuvent s'assurer que leur bilan est inclus dans la racine de l'arbre Merkle. En vérifiant la preuve zk-SNARK, les utilisateurs peuvent s'assurer que la construction de l'arbre Merkle répond aux contraintes définies dans le circuit.

La sécurité de cette solution repose en grande partie sur la configuration de la clé de preuve et de la clé de vérification. Nous travaillons sur une configuration décentralisée des clés. En ce qui concerne les cérémonies de configuration de confiance décentralisées existantes, la cérémonie Ethereum offre un bon exemple. Nous sommes sur le point d’avoir une solution MPC pour rendre la configuration sans confiance.

Performance

Compte tenu du nombre d’utilisateurs de Binance dont les soldes doivent être inclus, il n’existe aucun moyen d’obtenir une seule preuve de la construction de l’arbre Merkle qui couvrirait tous les utilisateurs à la fois. Une solution à ce problème consiste à diviser les utilisateurs en lots de 864 chacun afin de disposer d'un circuit à plus petite échelle et de procédures de preuve parallèles.

Pour un lot contenant 864 utilisateurs, chaque utilisateur possédant 350 actifs différents, supposons que le solde de chaque actif soit compris dans la plage [0, 2 ^ 64-1]. Avec un serveur à 32 cœurs de 128 Go, le temps de génération de la preuve zk est d'environ 110 secondes et le temps de vérification de la preuve est inférieur à 1 milliseconde.

Binance lancera 1 000 prouveurs en même temps afin de générer des preuves pour tous les comptes en 2 heures. Le coût de ce serveur de preuve pour une heure est d'environ 0,56 USD, donc le coût total de génération de toutes les preuves zk couvrant tous les utilisateurs serait d'environ 1 000 USD.

Conclusion

Nous fournirons la première itération de preuve pour les utilisateurs générés par cette nouvelle solution dans une annonce ultérieure de preuve de réserves. En outre, nous avons ouvert notre processeur de données utilisateur, notre prouveur, notre circuit et notre vérificateur, afin que chaque échange centralisé s'appuyant sur le même modèle que nous puisse générer facilement des preuves pour ses utilisateurs et ses actifs.

Nous espérons que cela contribuera à pousser la transparence du secteur des actifs numériques à un nouveau niveau. Nous travaillons également à implémenter la solution mentionnée dans le blog de Vitalik pour obtenir de meilleures performances, ce qui nous permettra de fournir les preuves plus fréquemment et à moindre coût.

Comme il s'agit de la première version de notre zk-SNARK, nous sommes impatients de recevoir les commentaires de la communauté afin de pouvoir continuer à améliorer le système.

Code et lectures complémentaires

  • Notre code source

  • Preuve de réserves Binance : Qu'est-ce qu'un arbre Merkle

  • Binance Academy - Améliorer la transparence cryptographique avec une preuve sans connaissance

  • Le blog de Vitalik : Avoir un CEX sécuritaire : preuve de solvabilité et au-delà