Haven Deep Dive: Cracking le code xUSD

Neac (responsable du protocole de Haven) et moi avons passé les derniers mois à préparer le lancement du réseau principal de xUSD. Tout au long de nos tests, nous nous sommes concentrés sur la manière de vérifier le plus en toute sécurité les échanges xUSD pour assurer un lancement en douceur et un succès à long terme pour ce premier stablecoin privé.

Ce travail a abouti à une refonte complète de la base de code de Haven. Comme nous l'avons appris dans nos réseaux de test, la structure de Monero s'est avérée particulièrement difficile pour la signature et la vérification des transactions xUSD. Cela a été fastidieux, lent et parfois carrément frustrant. Mais nous sommes fiers de dire que nous avons développé une solution innovante qui garantira l'exactitude, la fiabilité et la confidentialité des transactions xUSD maintenant et à l'avenir. Vous trouverez ci-dessous un aperçu détaillé du processus qui nous a conduit à cette solution.

Haven premier testnet a calculé une valeur approximative pour indiquer aux utilisateurs combien de xUSD ils recevraient pour le XHV qu'ils auraient demandé à échanger. En effet, dans Monero (et Cryptonote), lorsque les utilisateurs soumettent une transaction, ils envoient un engagement à un certain nombre de pièces: à la fois entrées et sorties. Ces entrées et sorties doivent être égales ou la transaction échouera toujours.

Cette structure Monero est devenue un problème pour Haven lorsque nous avons commencé à implémenter des échanges xUSD. Au départ, nous ne pouvions pas garantir le final le montant de xUSD échangé équivaudrait au approximatif montant de xUSD indiqué avant la soumission d'une transaction. En effet, le prix XHV change de manière dynamique. Le prix XHV (et donc le taux de change xUSD) pouvait changer entre le moment où un utilisateur soumettait une transaction et le moment où la transaction était confirmée.

La première façon dont nous avons abordé une solution à ce défi a été de ne plus rechercher l'égalité des intrants et des extrants. Mais pour éviter toute manipulation, il fallait que l'expéditeur soit incapable de spécifier un faux montant. Nous avons donc décidé de retirer entièrement cette étape des mains de l'expéditeur et de confier cette responsabilité au mineur.

Cette solution, mise en œuvre dans un testnet ultérieur, a ajouté un retard dans la fourniture du taux de change exact de xUSD. L'expéditeur devrait attendre qu'un bloc soit extrait et le mineur doit inclure le prix d'échange dans l'en-tête du bloc. Cependant, il y avait des trous dans cette solution - des vilains.

Imaginez un attaquant adversaire avec à la fois l'argent et la connaissance de cette partie du code de Haven. Après avoir mis en place l'infrastructure pour obtenir 51% du hachage de Haven, ils pourraient devenir à la fois le mineur et l'expéditeur et ainsi définir leurs propres taux de change xUSD. Cette possibilité était, dirons-nous, sous-optimale!

Donc dans le prochain testnet, nous avons décidé de renvoyer la responsabilité à l'expéditeur, mais uniquement pour qu'il puisse prendre le dernier enregistrement de prix vérifié déjà dans la chaîne de Haven (l'enregistrement de prix du bloc supérieur) et spécifier le bloc utilisé dans la transaction. Cela pourrait être vérifié et vérifié par les mineurs et les démons, qui pourraient également vérifier que les entrées et les sorties étaient égales non pas en pièces de monnaie, mais en valeur en dollars (critique pour xUSD).

Ce preuve de valeur est devenu la clé du succès de Haven. Mais le modèle décrit ci-dessus s'est également révélé vulnérable aux attaques. Plusieurs leçons sont ressorties des quelques prochains testsnets xUSD menés avec notre équipe et notre communauté. Tout d'abord, nous avons appris qu'une chaîne plus courte pouvait jouer avec le système. Deuxièmement, nous avons appris que nous avions besoin d'un moyen de montrer l'offre en circulation de xUSD (et des futurs xAssets) ou nous ne pourrions jamais déterminer la santé du réseau de Haven.

La prochaine étape de développement nous a emmenés sur une voie différente. Comme indiqué ci-dessus, prouver la valeur d'une transaction était la clé, et nous devions remplacer la preuve des entrées Monero = sorties par la preuve de la valeur en dollars pour les échanges xUSD.

Nous avons essayé plus d'une douzaine de preuves, de vérifications et de validations différentes. Mais nous avons constaté qu'à moins que vous n'envoyiez réellement XHV et aucun autre type d'actif, ce que nous faisions dans les tests privés, tout le système est confus après quelques transactions en amont et en aval. Plus les échanges sont complexes, plus il est difficile de vérifier la valeur monétaire d'une transaction. Ensuite, lancez plusieurs transactions, qui devaient couvrir de grandes quantités d'entrées, et les choses se sont vraiment enchevêtrées.

Ces défis étaient tous liés au fonctionnement des signatures d'engagement, qui est une exigence absolue dans Monero. À moins que vos engagements ne soient valides, vous ne pouvez jamais vérifier que l'argent n'a pas été créé de nulle part.

À ce stade, nous avons décidé de revoir l'ancien modèle de "pièces colorées»Qui a déjà été superposé au-dessus de Bitcoin, créant un nouvel ensemble d'informations sur les pièces échangées. En utilisant des pièces de monnaie colorées, les transactions pourraient être «colorées» avec des attributs spécifiques. Cela transforme efficacement les pièces colorées en jetons, qui peuvent être utilisés pour représenter n'importe quoi. Mais - et c'est essentiel - les pièces de couleur ne peuvent fonctionner que si vous n'êtes pas lié à la structure d'engagement de Monero.

C'est donc le défi que nous avons relevé: modifier la structure d'engagement de Monero pour permettre l'utilisation de «pièces colorées» qui permettent de distinguer XHV, xUSD et les futurs xAssets sur une seule chaîne basée sur Monero. Et je suis fier de partager cela pour la première fois, c'est exactement ce que nous avons fait.

Nous avons dû remplacer Monero groupe anonyme spontané à liaison multicouche (MLSAG) signatures avec le plus récent groupe anonyme spontané compact pouvant être lié (CLSAG) pour ce faire. Mais avec un peu d'aide de l'un des meilleurs développeurs de Monero, Sarang Noether, la solution fonctionne désormais comme prévu. Nous tenons à remercier Sarang pour son aide en nous aidant à naviguer dans ce nouveau schéma de cryptage.

Le résultat de tous ces tests et bricolages est donc le suivant: nous avons créé une nouvelle structure de transaction avec des entrées authentiques comme XHV et des sorties authentiques comme xUSD. Pour convertir XHV en xUSD, nous donnons en fait XHV comme entrées et xUSD comme sorties. Les démons vérifient ensuite que le nombre de sorties est égal en fonction du taux de change indiqué dans le bloc que l'expéditeur a spécifié comme enregistrement de prix. Cela se fait uniquement en additionnant les masques d'engagement et le taux de change récupérés indépendamment par les vérificateurs.

La logique est qu'un vérificateur obtiendra toujours son propre taux de change. Ainsi, la seule façon pour un expéditeur de faire passer une transaction est de connaître à la fois ce taux de change exact et le nombre exact d'entrées (ce qu'ils sont seuls à pouvoir connaître car il est dans leur portefeuille et illisible ailleurs). Le vérificateur additionne ensuite les engagements de sortie et, en tenant compte de leur taux de change acquis indépendamment, le compare aux entrées. Ils doivent être égaux pour réussir. Bien sûr, toutes les valeurs sont cryptées afin que personne ne puisse voir ou modifier les montants.

Remarque: l'expéditeur ne peut utiliser qu'un dossier de tarification déjà vérifié, qui est actuellement créé via L'oracle XHV de Chainlink. Les démons lisent le numéro d'enregistrement de prix dans la transaction et récupèrent l'enregistrement (le prix réel) à partir de l'en-tête du bloc. Cela signifie que les prix sont déjà immuables au moment de l'utilisation.

C'est exactement le type de solution que nous recherchions après avoir réfléchi à la manière de relever les défis associés à la vérification des échanges xUSD dans le tout premier réseau de test. Cette solution fonctionne bien dans nos tests privés et sera partagée dans notre prochain stagenet public dans les prochains jours.

En supposant qu'aucun autre problème ne soit identifié lors des tests, c'est la solution que nous utiliserons pour lancer xUSD en direct sur le réseau principal de Haven. Dans le cadre du processus de lancement, nous sommes impatients de partager publiquement le code d'échange xUSD que nous avons développé en privé au cours de la dernière année pour créer le tout premier stablecoin privé.

En attendant, rejoignez la communauté Haven et faites partie de l'avenir de la confidentialité financière. Vous pouvez rejoindre notre Discorde et suivez-nous sur Twitter.