J’ai relu la documentation sur Dusk hier soir, et j’en suis ressorti(e) avec un intérêt plus marqué pour les questions de conception que pour les affirmations techniques.

La première chose qui m’a sauté aux yeux est la séparation entre Moonlight et Phoenix. Moonlight est basé sur un compte, avec une clé publique, un nonce et un solde, tandis que Phoenix utilise des UTXO comme « notes » à l’intérieur d’un arbre de Merkle. Les champs de transaction de Moonlight incluent from, to, value, nonce, deposit, data, gas_limit, gas_price et signature, avec un gas maximum calculé comme gas_limit × gas_price.

Phoenix devient ensuite vraiment intéressant. Il utilise la courbe Jubjub, avec des clés publiques (A,B), des clés secrètes (a,b) et une clé de vue (a,B). La structure de la note inclut type, com, enc, npk, R et encsender. La clé de note à usage unique est dérivée comme npk = H(rA)G + B, tandis que la clé de dépense est nsk = H(aR) + b.

J’essaie encore de comprendre la frontière de confiance autour de la génération de preuves ZK et du scanning délégué. La documentation indique que des tiers peuvent générer des preuves ou scanner à l’aide des clés de vue sans obtenir d’autorité de dépense, mais quels sont les points de défaillance ?

Et avec les nullifiers, les racines Merkle récentes et un gas géré à l’intérieur de la preuve, comment cela se comporte-t-il dans des conditions réseau adverses ? Quelles parties sont décentralisées, et quelles hypothèses les utilisateurs devraient-ils examiner de près ?

#dusk $DUSK @Dusk