Decred 即将发布其隐私功能及计划。Decred 隐私功能的目标是简单、适应性强及具有创造性。我们决定不采用以隐私为重点的项目所采取的隐私功能（如环形签名、zk-SNARKs 或 Mimblewimble），而是将 mixnet 与我们的 PoS 治理系统集成在一起。目前，只有 50％多的流通 DCR 参与了 PoS，说明它需要一个稳定的购票流程。此交易流程为 Decred 特有，并充当 mixnet 的自然基础。Decred 的 PoS 治理系统方法是一个“一石多鸟”之计：权益持有者获得匿名，同时还能够创建大量充当背景的交易，权益持有者及非权益持有者可将常规交易混合其中。以下是 Decred 的 mixnet 概要：
- 它基于由 Ruffing、Moreno-Sanchez 和 Kate 提出的“P2P 混合和不可链接比特币交易”中的 CoinShuffle++协议。
- 此混合过程与购票过程相集成，因此运行购票钱包的权益持有者可以匿名购买选票。
- 除了当前票价的面额外，较小固定面额用于混合找零和常规交易。
- 混合过程的找零需要特殊处理，以避免链接未花费交易输出（“UTXO”）。
- 使用隐私功能时，链上交易存储量增加约 12 倍。
- 初始版本仅为命令行界面（“CLI”），仅支持个体选民和非抵押交易。
本文以下部分将介绍系统决策背后的动机、系统的具体工作原理以及此隐私功能初始版本的后续工作。动机自 2017 年年中以来，隐私工作一直停滞不前，这得说明一下。那时候，我观察到门罗和 Zcash 都提供大量的隐私功能，但我发现了一个严重的问题：他们无法删除全节点的历史交易（即修剪），因为无法知道一笔交易输出（“TXO”）是否被花费。虽然这两个项目都觉得这不是什么大问题，但我认为，这对于想要长期可持续发展的项目来说是一个巨大的问题。如果一条区块链过于庞大，难以下载和复制，那么它就很难发挥其长期价值存储的作用，从而降低其安全性。
然而，加密货币领域中的大多数人似乎都不认同我的这种观点，所以我觉得还是保留我自己的看法，不到处宣扬，也不去暗示别人实施解决方案。除了认为破坏修剪是一个糟糕的长期工程决策，可能会对可持续性产生负面影响，尽管它对短期隐私性有利，但我比较担忧这两种方法的复杂性：环形签名有点复杂，zk-SNARKs 较为复杂，因此我想找到一种不破坏修剪的简单方法。
最初，我计划通过 Heilman、AlShenibr、Baldimtsi、Scafuro 和 Goldberg 合作撰写的文章《TumbleBit：一个去信任的比特币兼容匿名支付中心》来实现 TumbleBit。在 2017 年冬至 2018 年春期间，我让一位在加密工程项目方面有着丰富经验的开发人员 Mikhail Belopuhov 用 Go 实现了 TumbleBit。当他完成最初实现并准备集成代码的时候，我渐渐意识到 TumbleBit 存在弊端，即混合服务器容易遭受拒绝服务（DoS）攻击，并且针对这一点（匿名费用凭证）所采取的对策就意味着要添加更多代码，复杂性也随之增加。尽管我们没有将 TumbleBit 代码集成到 Decred 中，但发布此代码是为了公共利益。因此，我认为需要仔细研究一下 Ruffing、Moreno-Sanchez 和 Kate 提出的“P2P 混合和不可链接比特币交易”中的 CoinShuffle++协议，它比 TumbleBit 要简单得多。CoinShuffle ++基于常见的加密原语，例如密钥交换、会话密钥、哈希函数、签名和有限域算法。在仔细研究过 CoinShuffle++之后，可以明显看出它比 TumbleBit 更简单、更抗 DoS，所以我们转向了 CoinShuffle++。因为简单的代码及原语意味着它们也不易出错或被破坏。由于工程资源的限制，这项研究工作直至 2018 年 12 月才开始，经过我们几个月的努力，现已准备发布。CoinShuffle++仅解决隐私的可追踪性组件，而不解决交易金额问题。由于 CoinShuffle++无需任何共识变更，因此这项工作可以在私下完成。但对于混淆交易金额的技术来说，情况截然不同。为了混淆交易金额，必须按照权益持有者的意愿进行共识变更，并且这些变更必须作为 Decred 公共流程的一部分。Decred 建立在区块链安全性、内置治理和自筹区块奖励的原则之上，这使得它成为优秀的价值存储平台。有了这些基础，我们迫切希望构建隐私功能，增强用户的安全性。尽管混淆交易金额需要公共流程，但我认为在权益持有者的安全方面，可追踪性问题要重要得多，因为这需要更多的隐私性。
CoinShuffle++的工作原理 **Decred 在其钱包中实现了 CoinShuffle++变体。尽管它可以以完全点对点（“P2P”）的方式执行此过程，但这就忽略了通过公共互联网路由的约束，因此我们还创建了一个服务器——csppserver，并将客户端集成到 dcrwallet 中。为了更深入了解 CoinShuffle++的工作原理，我们来通过一个简单例子来说明该过程背后的概念。除了本文所描述的内容之外，钱包中还具有巨大面额及找零处理功能，可处理常规交易和购票。此初始版本有几个缺陷需要注意，因为它只是 CLI，需要独立抵押或非抵押配置，而混合可以被攻击者撤消，攻击者还可破坏离散对数问题（“DLP”）。预计在未来几个月内，约 12.5％的流通 DCR 将使用隐私功能。不过为 dcrwallet 配置隐私功能需要一些配置文件编辑。CoinShuffle++CoinShuffle++是用于创建混币（CoinJoin）交易的非托管流程，其输出地址通过 mixnet 匿名化。输出地址被匿名化的过程就称为 DiceMix Light，它是 Ruffing 最初在 CoinShuffle++论文中提出的 DiceMix 过程的迭代。注意，若混币交易隐私遭到泄露，那么泄露的是某些输入及找零地址属于服务器的某些点，而不是参与混合的其他点。输出地址是完全匿名的，这样就没有点或服务器能分辨出哪个输出是属于哪个点的。混合过程在纪元（epoch）中进行，初始主网纪元设置为 20 分钟（1200 秒）。架构我们选择的主从式架构（client-server architecture）是常用的网络基础架构，主要是因为网络地址转换意味着用户可能无法直接跟与之混合的其他点通信。这个问题很常见，主要归结为端口转发问题，或 UDP 打洞方法是否可接受，我们认为这些问题都太过复杂。此外，使用直接 P2P 意味着每个点都能看到其他所有点的公共 IP，这对隐私不大友好。服务器 csppserver 需要 JORD-RPC 来访问 dcrd （Decred 的共识 daemon），以验证 TXO （交易输出）确实未花费。
初始 csppserver 将托管在 cspp.decred.org，但也可运行自己的服务器。不过运行自己的服务器会使得实用程序有限，由于我们的目标是在每次混合中获得尽可能多的点，因此最好不要这样做。未来我们有计划使服务器具有高可用性。DiceMix 简单示例为了理解 DiceMix 协议的工作原理，来看看这个名为“Secure Sum （安全总和）”的简单算法。本示例将使用 Alice、Bob 和 Carol 这 3 个点来进行说明，不过要扩展到多点也是非常简单易懂的。假设 Alice、Bob 和 Carol 各有一个数字，他们想要计算这三个数字的总和，但是他们都不想透露自己的数字是多少。于是 Alice 将她的数字分成 A1+A2+A3，Bob 将其数字分成 B1+B2+B3，Carol 将其数字分成 C1+C2+C3。然后 Alice 向 Bob 发送 A2，向 Carol 发送 A3，Bob 向 Alice 发送 B1，向 Carol 发送 B3，Carol 向 Alice 发送 C1，向 Bob 发送 C2。Alice 计算 A1+B1+C1，Bob 计算 A2+B2+C2，Carol 计算 A3+B3+C3，然后他们将各自的部分总和广播给其他人。现在，他们就可以通过将各个部分总和相加来计算出所有数字的总和，假设他们之间没有同谋，那么他们每个人就无法得知对方的数字是多少。以上例子利用的是“水平和的总和等于垂直和的总和”这一技巧，看以下图表就更为清晰明了了：使用 DiceMix 可以增加额外的复杂性，但核心概念保持不变。使用 DiceMix，每个点都要创建其支付地址的指数向量，将填充项添加到每个向量组件中（基于密钥交换过程的成对会话密钥），并将每个点的向量求和以创建方程组，然后解出支付地址的方程组。这里的诀窍是，当被选择的填充项在对所有点的向量进行求和时，会被撤销。当我们有了匿名支付地址列表，各个点就可以开始进行标准的混币（CoinJoin）流程。
面额及找零处理 DiceMix 可将 CoinJoin 交易的输出地址进行匿名，但它不会使输出难以区分。若要使输出难以区分，它们必须对每种混合固定一个面额。2012 年 CryptoNote 的白皮书中指出，固定输出面额是必需的，因此显而易见，使用相同的输出金额才能够保护隐私。Decred 使用的面额是当前的选票价格（加上费用），有几个固定面额还低于选票价格。选票价格每 144 个区块变化一次，也就是大约每 12 个小时变化一次，所以这个面额会随着时间的推移而变化。如果票价在纪元（epoch）期间发生变化，则此混合被撤销并由各点进行下一个混合。正如密码学和隐私领域中所说的“细节决定成败”，CoinShuffle++的混合找零也不例外。CoinShuffle++在匿名输出地址方面表现得十分优秀，但是如果找零没有处理好，它甚至可以链接到混合和未混合的 UTXO。在很多情况下，通过对部分总和进行分析，可以将找零输出与其输入相关联。例如，输入子集总和为 12.34，匿名输出为 10，费用为 0.001，找零 2.339。这意味着如果将 2.339 的找零包含在带有匿名输出的输入中，它会在总和为 12.34 的输入与那些匿名输出之间创建一个链接，从而降低或消除我们的隐私。为此，混合中的找零发送至单独的钱包账户时会被混合成较小面额，直至找零金额小于最小的混合面额。选择固定面额是为了平衡链上交易存储的平均大小、混合质量和执行乘法的简易性。
假设面额为基数 N，有 M 个面额，那么在最坏的情况下，给定面额将会有 N-1 个输出，单个找零输入会有 M（N-1）个总输出。若基数为 10，这意味着 99.999 的找零金额将需要最多 5（10-1）=45 个混合输出，因此链上交易存储预计大约增加 22 倍。若我们将基数定为 4，低于票价的有 8 个面额，那么在最坏的情况下，找零需要 8*（4-1）=24 个输出，使得链上存储增加约 12 倍。除了已包含的票价外，还有另外 2 个面额，但它们的使用范围估计有限。一个是最小面额，为 4^9 个 atom=0.00262144，另一个低于当前票价，为 4^16 个 atom=42.94967296。局限性此初始代码仅支持 CLI 钱包、dcrwallet 和独立选民，不支持投票服务提供商（“VSP”）和常规交易。不过我们很想为 GUI 钱包添加隐私支持，例如 Decrediton 钱包，使它支持 VSP。GUI 钱包的局限性就在于用户体验（“UX”）不是很好，因为新接收的支付或找零的混合过程要求用户钱包解锁长达 10 秒左右。VSP 也有其局限性，因为当用户在 VSP 上注册帐户时会拥有一个身份，而且每个帐户都有一个固定的 1/2 多重签名脚本。如果攻击者破坏 DLP 并记录混合客户端和服务器之间的所有信息，他们就可以揭露出输入、输出和找零之间的链接。而且攻击者不会导致静默通胀。预期所有隐私功能的重点都在于用户能够从中获得什么，特别是在选择性隐私方面。目前 Decred 的选票价格约为 128 个 DCR，若想要购票状态稳定，我们的权益持有者必须每天花费 128 个 DCR5 票288 区块 =184,320 个 DCR。目前流通的 DCR 大约为 1028.2 万个，因此这种稳定购买量约占每天购票总量的 1.8％。大约 50％的选票都是独立抵押的，也就是说 50％的个体抵押者将使用隐私功能，且约 50％的 decred 被抵押，这就意味着估计 12.5％的 decred 将使用初始隐私功能。不过参与率要达到这个水平估计还要几个月的时间，因为随着时间的推移，投票速度会放缓，并且只有新选票才可以选择使用隐私功能。权益持有者和非权益持有者都可以使用隐私系统，并可对稳定的交易流放心，因为我们已经将这些交易与我们治理系统中稳定的购票流相结合。有了上述系统，选择隐私功能的用户能够合理拒绝接收及支付，而这种情况只有当我们改进用户体验和提高参与水平时才会进行改善。第三方能够看到混合 UTXO 的集合被花费了，但他们无法将这些交易联系到某个身份。配置**说到隐私的运作方面，一些读者肯定想知道隐私如何配置及工作的吧。首先要在 dcrwallet.conf 中设置以下几个新选项：
- csppserver=cspp.decred.org:15760，这是用于监听的 FQDN 及端口 csppserver
- csppserver.ca=cspp.decred.org.pem，这是 csppserver 的 CA 证书。
- purchaseaccount=mixed，这用于设置购买选票的帐户
- mixaccount=mixed/1，当混合进行时，混合输出地址将来自此帐户的内部分支
- changeaccount=unmixed，每组混合输入都使用此帐户的找零地址
- mixchange=1，指导 dcrwallet 将 changeaccount 中的付款混合到 mixedaccount 中
- ticketbuyer.votingaccount=voting，指导钱包在设置投票地址时使用哪个帐户
除了在 dcrwallet.conf 中设置这些新选项外，还必须创建两个新帐户：混合账户和非混合账户。若也想让 ticketbuyer 钱包投票，则可以在本地创建投票账户，或者从外部投票钱包为投票账户导入扩展 pubkey。若运行 ticketbuyer 的权益持有者想要设置第二个 ticketbuyer，并使两个同时运行，配置过程如下：使用在第一个钱包中新购买的选票将第二个钱包中的混合帐户分支 0 设置为它们的混合帐户。大型权益持有者可能需要 4.7 个月左右，即全部选票失效才能完全迁移到新的混合钱包。非权益持有者也可以设置以上选项，省去 purchaseaccount 这一步骤，不购买选票来参与混合。若要接收付款，得从非混合帐户中生成新地址，然后将这些付款混合到混合帐户中。请注意，在混合过程中，钱包需要长时间处于解锁状态，以便它可以参与每 20 分钟发生一次的混合。ticketbuyer 钱包解锁后，非抵押钱包也需长时间保持解锁状态才能完成混合。
未来工作进展在改进和增加初始隐私功能方面，还有很多工作尚未完成。GUI 钱包的 UX，如 Decrediton 就需要将 GUI 组件与 dcrwallet 进行集成。要使 VSP 与隐私兼容，需要将基于帐户的系统转为直接基于选票的系统，这就得对 dcrstakepool 和 dcrwallet 进行修改。此初始版本依赖于单个服务器进程，但我们可以使用集群或 dcrd 中的混合 mempool 替换此单个服务器。在找零处理具有高复杂性后，就可以添加机密交易（“CT”）支持，这就需要共识变更。由于混合过程不在链上进行，因此可修改 DiceMix 以支持 Post-Quantum 加密，这将使混合过程更为安全，防止攻击者破坏 DLP。
GUI 钱包集成如上所述，dcrwallet 必须进行一些更改，以便与 Decrediton 混合后，其用户体验能更为完善。但这里存在一个问题，在一个时长约 20 分钟的纪元中，混合钱包对混币交易进行签名至少需要 20 分钟。而最简单方法就是让钱包长时间解锁，但这样极度缺乏安全性。但是可以通过一些方法，使 dcrwallet 一次只解锁一个帐户，例如非混合帐户，并对所有涉及签名的钱包 RPC 设置密码。进行了这些更改后，就能够轻松将隐私功能整合到 Decrediton 钱包中了。
VSP 变更 **VSP 目前按每个帐户进行操作，例如用户有一个登录名、该帐户的固定 1/2 多重签名地址，以及一组投票偏好选项，但为了正确支持隐私功能，VSP 必须按每张票进行操作。这就需要用户向 VSP 提供每张选票的独立私钥，支付 VSP 费用，并设置每张票的投票偏好。此外，如果通过 Tor 或类似方式将选票委托给 VSP，那就更为理想化了。这就需要更改 dcrwallet 和 dcrstakepool。由于大约 50％的选票由 VSP 持有，这就意味着隐私功能的使用率几乎倍增，使用隐私功能的流通 decred 从 12.5％上涨至 25％。混合服务器群集操作单个混合服务器其实很简单，虽然它能够处理大量交易，但它的配置并不是很有弹性。更具弹性的长期配置是高可用性集群，或者甚至是将服务器集成到 dcrd 中，从而创建一个混合 mempool。然而不将服务器集成到 dcrd 中考虑了多方因素，因此还需进一步研究。机密交易使用 CoinShuffle++正确处理找零所需的复杂性和链上交易存储增加都说明应该要对交易金额进行混淆。混淆金额会淘汰部分总和分析以及相应的面额混合。它使得每个纪元只有一笔混合交易，而不是不同面额的多笔独立混合交易。由 Ruffing 及 Moreno-Sanchez 合著的《混合机密交易：比特币的全面交易隐私》白皮书就正好讲到了这一改进。如果使用防弹协议（“BP”），那么使用 CT 的交易大小很可能会降低链上交易存储要求。但 CT 会使得攻击者能够破坏 DLP，造成静默通胀，这将对 Decred 的 PoS 治理系统及其作为价值存储服务器的能力造成灾难性的影响。虽然通过公共信息可以得出一个有效论点，开发一台运行良好的大型量子计算机仍需很多年的时间，但是大型国家政府却有巨大的动机秘密开发这种技术，并用它来解密各种加密数据。该白皮书作者建议，可以实现计算隐藏且完全绑定的防弹协议，而不是简单的完全隐藏且计算绑定的防弹协议。我们将对这一方案进行研究，因为静默通胀的这一失败模式将严重损害 Decred。抗量子密码学 CoinShuffle ++及其相关 DiceMix 协议的主要优势之一就是，它能够被修改成支持 PQ 加密，从而使混合过程免受攻击者攻击。DiceMix 要求参与各方执行成对密钥交换，为方便起见，他们建议以非交互式密钥交换进行，因为交互式密钥交换会创建额外的通信轮。通过添加额外通信轮，使用 PQ 加密技术可以保证密钥交换过程的安全性。基于 Bernstein、Chuengsatiansup、Lange 和 van Vredendaal 的工作，Company 0 已实现了一个更完善的 PQ 加密系统——Streamlined NTRU Prime 4591^761，这将成为此类应用的自然选择。由于混合过程在链下进行，因此 PQ 加密技术通常不会考虑传统交易大小，例如，PQ 公钥通常为 1 KB 或更大。但要注意，这并不能阻止攻击者破坏 DLP，获取相应公钥，从而窃取资金，但可以防止他们被动撤消混合，剥夺隐私权。
结语**将 Decred 工作公开化，并向权益持有者提供初始隐私功能，能够使所有的 Decred 用户受益。在 GitHub 的 dcrwallet 改进请求中可测试这些功能，我们鼓励更多技术用户与我们共同测试此代码。不过在整个开发过程中，该代码已在测试网上接受了大量测试，因此它应该已经相当稳定了。在经过更多测试以后，此代码将成为主分支的一部分，并包含在下一版本 1.5.0 中。我们一直在寻找才华横溢的开发人员，如果你对这项隐私工作感兴趣，请与我们联系。虽然我们已完成了大量实质性工作，但仍有许多工作尚未完成。我们的目标是保持隐私代码的简易性，无论是加密原语还是对 Decred 区块链的隐式约束。Decred 将继续迭代并适应周遭变幻莫测的隐私环境，且会根据权益持有者的意愿，在必要时集成新功能，以应对新挑战。一如既往，我们致力于最大限度提高 Decred 区块链及其用户的安全性，并将以可持续的方式实现这一目标，使 Decred 成为一个卓越的长期价值存储平台。下图为更新后的隐私技术项目列表：
By 头等舱