J'apprécie toujours les discussions qui font progresser les initiatives de confidentialité dans l'écosystème Merci pour les questions @officialabdulak > Comment les utilisateurs peuvent-ils vérifier que les échanges chiffrés s'exécutent correctement sans exposer de données privées ? Les intentions/ordres des utilisateurs sont chiffrés sur le client lui-même. Sur la chaîne, ces ordres ne sont affichés que sous forme de texte chiffré (indiscernable les uns des autres). Nous avons un réseau de seuil (qui serait économiquement soutenu) en place qui protège la confidentialité de ces textes chiffrés. De plus, pour la version v1 de notre coprocesseur (celui des TEE), le texte chiffré est déchiffré au sein d'AWS Nitro (avec la sécurité d'AWS) JUSTE POUR le traitement. PS : le texte chiffré n'est jamais stocké dans les TEE. Pour notre coprocesseur v2, nous remplacerons ce moteur de calcul par FHE (étant donné la modularité de notre infrastructure) où nous n'aurions même pas besoin de déchiffrer le texte chiffré pour le traitement. Après le traitement, pour chaque intention/txn/ordre que les utilisateurs effectuent, nous avons un flux de vérification passive (que les utilisateurs/développeurs pourraient considérer comme une finalité pour vérifier que l'exécution a eu lieu correctement et dans un environnement non malveillant) Pour être précis, chaque intention/txn/ordre des utilisateurs après traitement devient une partie d'un arbre de lot. Ces arbres de lot sont accumulés de manière périodique et la racine finale accumulée est publiée sur la chaîne, et maintenant tout utilisateur pourrait vérifier certaines données d'intention/txn/ordre par rapport à cette racine publiée (ce mécanisme est très similaire à la façon dont les séquenceurs publient leur racine d'état sur L1 pour permettre le pontage natif des tokens de L1 à L2) Nous avons partagé comment tout le mécanisme fonctionne ici : > Est-ce qu'Encifher utilise ses propres pools de liquidités chiffrées ou agit-il uniquement comme un relais de confidentialité via @JupiterExchange ? Chaque fois qu'un utilisateur enveloppe certains actifs, ces actifs deviennent une partie d'un pool chiffré. En ce moment, le frontend actuel encrypt[.]trade n'utilise pas le matching d'ordres natif (résolution d'ordres avec des tokens chiffrés) et traite tous les ordres via des routes de liquidité efficaces par @JupiterExchange. Mais @encifherio, à la fin de la journée, c'est tout un protocole qui permet le calcul sur un état chiffré, donc oui, nous pouvons construire un dark pool par-dessus cela qui supporterait le matching d'ordres parmi des tokens chiffrés. C'est l'objectif, une fois que nous aurons suffisamment de liquidités enveloppées/chiffrées, nous commencerons à constituer une équipe pour développer des cas d'utilisation comme un dark pool sur cette liquidité. > Comment testez-vous les fuites potentielles de confidentialité ou la corrélation des métadonnées ? Deux solutions ici : 1. Les ordres/intentions/txns des utilisateurs ne sont pas liés à leurs adresses, ce qui constitue la première défense pour la confidentialité des utilisateurs. 2. Nous avons une conception de structure de données d'ordres unifiée en place qui garantit que tout type d'ordre (échange, prêt, etc.) suit la même structure d'ordre. Alors que les entrées de ces ordres seraient chiffrées, les parties externes ne sauraient pas si une certaine propriété a réellement une valeur ou si elle est juste nulle tout le temps. Et donc, cela empêche toute information provenant d'ordres non uniformes. 3. Nous veillerons à utiliser des services qui obfusqueront même l'adresse IP du client qui passe l'ordre. > Quelle est votre approche pour maintenir un ensemble d'anonymat fort à mesure que l'activité des utilisateurs augmente ? TL;DR Plus de primitives DeFi attireraient les utilisateurs à garder leurs fonds enveloppés au sein d'Encifher, et donc l'activité augmenterait l'ensemble d'anonymat global. La vision à court terme d'Encifher est de devenir un écosystème DeFi habilité à la confidentialité sur Solana. Nous proposerons plusieurs primitives DeFi en un seul endroit encrypt[.]trade. Le problème des ensembles d'anonymat se magnifie dans les scénarios où les utilisateurs retirent immédiatement des actifs du pool, mais dans notre scénario, les utilisateurs pourraient simplement envelopper leur token et les garder au sein du protocole, étant donné que nous soutenons plusieurs primitives DeFi et en général, les transactions des utilisateurs via ces primitives augmenteraient également l'ensemble d'anonymat et il serait beaucoup plus difficile pour des entités externes de lier le déballage à l'emballage. > Voyez-vous Encifher évoluer en une couche de calcul entièrement chiffrée pour Solana DeFi ? Oui, Encifher est conçu depuis le départ en tenant compte des besoins de confidentialité transactionnelle sur Solana. Ce n'est pas comme d'autres couches de calcul de confidentialité à usage général qui permettent le calcul de confidentialité pour tous les cas d'utilisation. Au lieu de cela, notre principal objectif est de permettre un DeFi privé et donc construit de manière à répondre aux besoins de confidentialité transactionnelle.