问题 1：隐私交易需要满足设定的条件才是正确的（即发送方要有足够的资金，转账金额必须为正数等）。我们如何能弄清楚一个任意的合约需要满足哪些条件？这些条件显然受特定的应用影响。在投票中，我们可能希望证明我们隐藏的投票是在正确的范围内进行的，而对于拍卖，我们可能希望证明我们的账上有足够的资金用于封闭投标。

　　对问题 1 的潜在解决方案：问题并不严重；只是需要用户做更多的工作。去中心化应用的开发者必须明确他们的特定应用需要满足哪些条件，并将这些条件传达给用户。为了能够证明各式各样的条件，我们可能希望在方案中支持一些通用的 ZKP。所谓 通用 的 ZKP 就是能够证明任意的声明（不像那些目前用在大零币里的 ZKP，它们是非通用的）。

　　问题 2：在普通交易中，我们只对属于同一个用户的值进行操作（即使用同一个密钥加密）。如果我们想对属于不同用户的输入值进行隐私计算呢？这并不是一个多么牵强的需求，比如我们考虑对投票做隐私保护时就会涉及。

　　对问题 2 的潜在解决方案：目前还不清楚如何在用户相互之间不透露输入明文的情况下，支持对不同用户的输入进行计算。有一些先进的密码学元件（比如安全多方计算和基于多密钥的全同态加密 FHE），允许用户对不同密钥加密的输入进行计算。然而，这些方案的成本都非常高，而且有很多缺点。在密码学货币的应用场景下，目前似乎没有人有一个很好的解决方案来解决这个问题（除了与参与计算的其他用户共享明文，然后在同一个密钥下加密）。

　　问题 3：普通交易只需要同态加法，因为我们只需要将加密的转账金额加到加密的余额上。如果我们想进行更复杂的计算，可能涉及到乘法呢？

　　对问题 3的潜在解决方案：同态乘法允许将加密的输入相乘，也就是Enc(a) * Enc(b) = Enc(a * b) 。通过同态加法和同态乘法可以表示任意多项式函数，所以有个问题浮上台面：能够支持同态乘法吗？

　　一个既能支持同态加法，又能支持同态乘法的加密方案是全同态加密（FHE）。使用 FHE，我们仍然可由用户指定加密输入，要运行的函数，以及证明加密输入满足必要条件的 ZKP。矿工能够验证 ZKP。他们使用同态加法和同态乘法直接对用户提供的密文进行操作。

　　不幸的是，FHE 方案使用基于格（lattice）的加密技术，在目前与密码学货币中使用的超高效的 ZKP 并不兼容，而由于 FHE 存在一些缺点，还没有人提出基于 FHE 的解决方案。

　　这样，目前就只有两种方法来解决问题 3 了：接受我们只能支持同态加法的现状，或是遵循隐私交易模型。 (责任编辑：admin)