前言
如果大家读过我前面写的那篇杂谈隐私币的文章[林19]，也许您会注意到我提到过 Zcash 在设计上从隐私交易角度看存在一些 over-engineering，本文将在这方面展开叙述。
可审计的
前文中提到 Zcash 实际上对 Zerocoin 的修正版，而这两个方案的核心思想都可以在[ST99]中找到。[ST99]文章名字叫“Auditable, anonymous electronic cash”。可以看出这篇文章除了意在设计一个匿名电子货币，重点还在于要保证这个匿名货币是可审计的（Auditable）。
[ST99]是这样定义可审计性的：“An electronic cash system that has a complete report of transactions allows monitoring the same way the banking system is monitored today. ”翻译成中文意思是：“一个能够对所有交易有完整的报告且能像现有传统银行系统那样对交易进行监视的电子现金系统”。
[ST99]定义的需要记录在案的系统事件包括：用户开户，用户从银行提钱，用户转账给一个商家，商家往银行存储从用户手中所得的货币。这篇论文对可审计性更精确的定义如下：“设计者必须可以描述系统中发生的所有事件。尤其是必须能报告谁在某个时刻取了钱。”
如何保证可审计性?
那么具体可审计性这个性质是如何保证的呢？主要就是通过Merkle tree(见图1)来记录上述事件。这里简单介绍下Merkle tree是什么：Merkle tree实际就是哈希树，只是被冠名成Merkle tree。
我们可以想象下图中的Merkle tree每个叶节点对应一个未被花掉的Zcash。当有一个用户在区块链上生成或花掉某个货币，Merkle tree会将这个操作和用户使用地址，即对应公钥链接起来记录在Merkle tree上。这也是为何Zcash的承诺如此复杂的原因：
从图2中, 我们可以看到这里Zcash对应的承诺是将用户地址公钥和数值 v 本身绑定到一起了，这就相当于在审计时可以将用户身份和存取记录绑定起来了。
如何实现可审计性?
[ST99]的Theorem 1是这样论述该方案如何实现可审计性：“Auditability: We have already shown that if a polynomial time player can spend a coin c then it must have appeared as a leaf in the tree. As all the leaves in the tree are different, this shows that a one to one correspondence between usable coins and leaves in the tree (and therefore withdrawals) exists. 我们已经证明一个多项式时间参与者一旦花费一个货币c，那么该货币必然作为一个树叶出现。由于树上所有叶子都不同，这意味着树上叶节点（因此对应的取钱事件）和可用货币之间一一对应”。
换句话说，这里之所以用了Merkle tree 很大程度上是为了保证在审计时通过查询Merkle tree的操作记录时有迹可寻。为了保证用户在使用所取得电子货币的隐私性，用户在支付这个操作上需要使用零知识证明来对应地证明用户知道Merkle tree对应的某个叶节点的秘密，从而证明他对货币的所有权和货币的合法性。
Zcash
在Zcash中则是用零知识证明证明用户执行Zcash pour操作时知道Merkle tree对应叶节点承诺的输入。这也是为何我认为Zcash在可审计性上是和[ST99]这篇论文一脉相承的原因。
如果硬要说这两个方案有什么不同的话，那就是Zcash为了适应区块链这个对通信量和吞吐量（Throughput）有强要求的应用环境在技术细节上做了些改动，比如他们用了从Pinocchio[PHGR13]这篇文章衍生出来的零知识证明方案来保证常数级别的通信量。
但我们注意到由于Zcash必须满足上述可审计性的要求，由Merkle tree及Zcash承诺相关零知识证明所带来计算量是相当高的，由这张从Zcash文章[SCGGMTV14]摘录的图3中可见，93%以上的计算都是Merk tree及其和可审计性相关的运算导致的。
由于Zcash提供隐私保护的交易（Shielded transaction）计算量如此之大，用户在生成证明上需要花费非常长的时间，而同时Zcash又提供了无隐私保护的透明交易（transparent transaction ）, 很多用户就干脆不选择使用shielded transaction而直接使用透明交易。
换句话说，大部分时候由于Zcash在Usability上所存在的缺陷，很多用户使用Zcash是无法保障其隐私性的。
另外一个颇为吊诡的地方是，[ST99]这篇文章设计一个很重要的出发点就是系统中没有任何密钥存在，进而保证能抵抗由此可能引发的针对密钥信息的诸如勒索之类的攻击。
然而，由于Zcash设计中可审计性导致对应零知识证明的命题过于复杂，为了保证对应通信量足够小，结果对应的零知识证明反倒需要trusted setup，这个实际上违背了[ST99]的初衷。
很多人可能会问什么是trusted setup，这个如果展开讲可能又需要另外一篇文章，通俗地说，零知识证明的trusted setup过程可以类比成数字签名方案的选择公私钥对的过程，负责初始化的人能掌握系统私钥，换句话说他能用该私钥合法生成对应该公钥的签名，这个性质映射到零知识证明系统中意味着可以合法生成证明。
如上文中提到的那样，Merkle tree所用到的零知识证明的意义在于证明货币的合法性和用户对货币的持有权，系统私钥在手就可以合法地无限量伪造（或者说制造）货币且无法被人侦测。这显然违背了区块链去中心化的宗旨。
事实上Merkle tree在去中心化隐私支付中起的作用基本上可抽象成聚合器（粗略定义见本人前文[林19]），文献中需要trusted setup基于bilinear pairing group无需Merkle tree的聚合器，且比Zcash中所用方案计算上更高效，且通信量相当的还是有几个的。
Zcash非得用这个在计算量上负担如此之大的方案，除了可能存在的知识产权上的纠纷，我唯一能想到的理由就是Merkle tree在可审计性方面的优势，但这总给人一种得不偿失的感觉。
Suterusu项目将重点关注基于无需trusted setup常数级别通信量的零知识证明的隐私保护区块链方案，尤其是基于Mimblewimble协议和Cryptonote方案的改进和实现。
我们将重点使用基于group of unknown order的代数结构来设计实现无需trusted setup的常数级别通信量的零知识证明方案，在此基础上我们的技术模块将让开发人员可以一键发更为高效安全的上述两大类型隐私保护区块链方案。
最后，我们还将提供跨链协议来保证对应匿名数字资产的流通性和可交换性。