帐篷中的隐私：关于私密求解策略的概述

在本文中，我们定义了什么是私密求解，解释了为什么我们关心它，并讨论了可以在对手发现阶段增强隐私的各种方法

意图的引入将创建、共享和匹配意图的过程提升到了协议层面：以交易为中心的协议期望用户提交交易作为输入，并将意图排除在外；以意图为中心的协议期望用户提交意图，而匹配意图则成为协议的一部分。如果以意图为中心的协议恰好也是保护隐私的，比如 Anoma 协议，那么在意图匹配阶段就存在隐私问题。

如何从想要某物（你的意图）到实际获得它（已结算的交易）？在 Anoma 的背景下，这个过程大致可以描述如下：

• •将你想要的东西表达为意图，
• •分享意图
• •意图与其他用户的意图进行匹配；匹配的结果是产生一笔交易
• •交易已结算

该过程大致可分为两个阶段：交易对手发现阶段（意图→交易）和结算阶段（交易→已结算交易）。

结算隐私与交易对手发现隐私

结算隐私与交易对手发现隐私

那么，我们如何在这些阶段实现隐私呢？结算阶段的隐私已经得到了充分理解：多年来一直有人在研究，已经开发出一些提供生成屏蔽交易和信息流控制方法的解决方案。而对于交易对手发现阶段，情况则不太明确，主要是因为目前还没有通用的以意图为中心的协议，更不用说具有隐私保护功能的协议了。

对立方发现隐私本质上是指在向解决者分享意图的上下文中的隐私。由于解决者是满足意图的行为者，他们需要知道你的需求，这与隐私的概念并不相符——为什么我必须告诉任何人我的需求？因此，对立方发现隐私的问题在于：我们如何在不实际告诉对方我们需求的情况下告诉他们我们的需求？

我们考察了多种可能用于在对立方发现阶段提供隐私的方法。

设置

我们考虑两种类型的参与者：

• •求解器 ，解决意图的角色。求解器有解决策略，这些策略可以是公开的或私有的
• •用户 ，拥有意图并希望它们被解决的角色。用户的意图是私密的

目标是创建一个协议，用户将源自意图的一些非敏感数据（例如加密的意图）发送给求解器，求解器匹配意图并输出屏蔽交易。

方法与结果

我们考虑了各种密码学方法：

• •TEE，
• •多方计算，
• •FHE，
• •见证加密,
• •函数加密,
• •可搜索加密,
• •协作 SNARKs，

以及一些非密码学方法来缓解这些问题。

好的

• •TEE

可信执行环境，或称为 TEE，是指硬件计算设备中的一个隔离环境，允许进行安全计算。为了实现私密求解，求解者的策略将被加载到 TEE 中，用户会发送其加密的意图，这些意图将在 TEE 中解密并由求解策略处理，最终输出一个受保护的交易。

TEE 路径的缺点在于，由于存在且不断发现大量漏洞，将 TEE 视为主要安全来源可能并非最优选择。

• •MPC

多方计算，或称 MPC，允许多个参与方使用他们不公开的某些私有数据（份额）共同计算一个公共函数。要使用 MPC 实现私有求解，用户会将其意图作为私有份额保留，而求解者的策略则会被编码在 MPC 协议本身中。

MPC 的缺点在于其成本高昂，需要大量数据传输，且数据传输量会随着参与方数量、策略复杂性和所需执行的计算量而增长。

丑陋的

全同态加密，或 FHE，指的是一种允许在加密数据上执行任意计算的加密类型。FHE 不适用于隐私求解问题，因为求解者始终可以是用户。接收其他用户的加密意图，求解者总能创建自己的意图并尝试与用户的意图匹配。如果意图匹配，用户的意图就会对求解者可见（这与求解者创建的意图相反），否则求解者可以重复此过程，直到找到与用户意图匹配的意图。

请注意，与全同态加密不同，这对 TEE 和 MPC 来说不是核心问题，因为在协议中，意图与其他意图进行测试的次数可以程序化地限制，在隐私（允许的测试次数较少→匹配的机会较低）和灵活性（更多的测试会导致找到匹配的机会更高，这可能来自求解者）之间进行权衡。

糟糕的

见证加密和协同 SNARKs 无法执行隐私计算。在我们的上下文中使用可搜索加密会导致搜索关键词与被保护的数据相匹配。功能性加密目前似乎不太有前景。

注意事项

求解者是用户

每个求解者都可以是用户这一事实使事情变得复杂。匹配的相对方会自然地了解对方的意图：如果我想用橙子换苹果，而我们的意图相匹配，这意味着你打算用苹果换橙子。我们不希望求解者利用这个机会猜测我们的意图，但我们也不能阻止求解者成为用户。

阶段隐私重叠

由于对手方发现层的输出是一个交易，而 Anoma 协议提供结算隐私，因此该交易受到保护。这意味着无论我们采取何种方法，都需要调用所有必要的密码学技术来生成受保护交易（零知识证明、签名、加密），这可能需要非平凡的安排且成本高昂。

结论

隐私求解很困难。它尚未得到探索，存在局限性，但我们可以改进它。除了密码学方法外，还有多种非密码学方法可以减少共享数据的量，最佳解决方案很可能是两者的结合。