始终欣赏推动生态系统隐私倡议的讨论 感谢提问 @officialabdulak > 用户如何在不暴露私人数据的情况下验证加密交换是否正确执行？ 用户的意图/订单在客户端本身上是加密的。在链上，它仅将这些订单显示为密文（彼此不可区分）。 我们有一个阈值网络（将会有经济支持）来保护这些密文的隐私。此外，对于我们协处理器的v1版本（TEE的一个），密文在AWS nitro中解密（具有AWS安全性）仅用于处理。PS：密文从未存储在TEE中。对于我们的v2协处理器，我们将用FHE替换这个计算引擎（考虑到我们基础设施的模块化），在处理时甚至不需要解密密文。 后处理时，对于用户进行的每个意图/交易/订单，我们有一个被动验证流程（用户/开发者可以将其视为验证执行是否在非恶意环境中正确发生的最终性） 具体来说，每个用户的意图/交易/订单在后处理后成为批处理树的一部分，这些批处理树以定期的方式累积，最终累积的根被发布在链上，现在任何用户都可以根据这些发布的根验证某个意图/交易/订单数据（这个机制与Sequencer在L1上发布其状态根以实现从L1到L2的原生代币桥接的方式非常相似） 我们在这里分享了整个机制的工作原理： > Encifher是否使用自己的加密流动性池，还是仅仅通过@JupiterExchange作为隐私中继？ 每当用户包装某些资产时，这些资产就成为加密池的一部分。目前，当前前端encrypt[.]trade并不利用本地订单匹配（使用加密代币进行订单解决），而是通过@JupiterExchange的高效流动性路线处理所有订单。 但@encifherio最终是一个完整的协议，能够在加密状态上进行计算，因此是的，我们可以在其上构建一个暗池，支持加密代币之间的订单匹配。这是我们的目标，一旦我们有足够的流动性被包装/加密，我们将开始组建/招募团队在这笔流动性上构建/引入用例，比如暗池。 > 你如何测试潜在的隐私泄露或元数据关联？ 这里有两个解决方案： 1. 用户的订单/意图/交易与他们的地址不相关联，这是用户隐私的第一道防线。 2. 我们有一个统一的订单数据结构设计，确保任何类型的订单（交换、借贷等）遵循相同的订单结构。虽然这些订单的输入将被加密，因此外部方不会知道某个属性是否实际持有一个值，或者它是否一直是空的。因此，防止了来自非统一订单的任何洞察。 3. 我们将确保使用服务，甚至会模糊下下单用户的IP地址。 > 随着用户活动的增长，你们如何保持强大的匿名性集合？ 简而言之 更多的DeFi原语将吸引用户将资金保持在Encifher中，因此活动将推动整体匿名性集合。 Encifher的近期愿景是成为Solana上隐私启用DeFi的生态系统。我们将在一个地方encrypt[.]trade提供多个DeFi原语。匿名性集合问题在用户立即从池中移除资产的情况下会被放大，但在我们的情况下，用户可以将他们的代币包装并保留在协议中，因为我们支持多个DeFi原语，通常通过这些原语的用户交易也会增加匿名性集合，外部实体将更难将解包与包装关联起来。 > 你认为Encifher会发展成Solana DeFi的完整加密计算层吗？ 是的，Encifher是从零开始设计的，考虑到Solana上的交易隐私需求。它不同于其他通用的隐私计算层，后者为所有用例提供隐私计算。相反，我们的主要关注点是启用私密DeFi，因此从头开始构建，考虑到交易隐私需求。