论文Anonymous Zether实验复现（持续更）

附上论文地址：https://github.com/ConsenSys/anonymous-zether/blob/master/docs/AnonZether.pdf

以太坊隐私智能合约层Zether概述

什么是Zether？

斯坦福大学的博士生Benedikt Bunz（Bulletproofs防弹证明方案作者之一）、斯坦福大学教授Dan Boneh以及Visa研究部门，联合提出了一种针对以太坊智能合约平台的隐私协议：Zether。

Zether是一个以太坊上的匿名支付协议，以智能合约Zether Smart Contract（ZSC）的形式部署在以太坊上，并且具有称为Zether令牌（ZTH）的代币，其在作为ElGamal公钥的Zether账户之间传输的载体，并支持匿名的智能合约交互。

Zether的论文首发于斯坦福密码应用小组，地址是：
https://crypto.stanford.edu/~buenz/papers/zether.pdf

论文的其中一位作者Benedikt Bunz，已开源了Zether协议的部分代码及测试代码，有兴趣的读者可以了解一下，地址如下：

https://github.com/bbuenz/BulletProofLib/tree/master/src/main/java/edu/stanford/cs/crypto/efficientct/zetherprover
https://github.com/bbuenz/BulletProofLib/tree/master/src/test/java/edu/stanford/cs/crypto/efficientct/zether

二、Zether的特点

在论文中，开发人员总结了他们的贡献，同时结合作者自己理解，总结Zether的特点如下（需要注意隐私和匿名是不同的两个概念，该项目均能实现，为了方便阅读，统一称为隐私）：

1、代币属于刚需：代币ZTH不是ERC20的代币，是其内生代币，如果没有的话，技术上其隐私功能无法实现，属于刚性需求。

2、具备隐私性：Zether的交易是保密的，账户余额和交易地址始终是加密的。

3、新的隐私算法：为了让Zether变得更有效，研究者提出了一种新的零知识证明机制，称为Σ-Bullets，结合了Bulletproofs（防弹协议）与Σ协议特性，以此为基础创建了其隐私账户体系，并且不需要Zcash的可信启动。

4、易于实现：理论上，支持智能合约的链均可以实现该项目，目前团队已经在以太坊上进行了初步实现和测试。

5、互操作性：Zether支持智能合约的交互。在论文当中，作者们展示了Zether可构建的四种应用，分别是：保密竞拍应用、保密支付通道、保密权益投票、以及私密权益证明（private proof-of-stake）。

6、基于账户模式：目前门罗、Zcash等各种隐私币都是基于UTXO的，而Zether是基于账户模型的，有可能是第一个。

三、Zether方案概述

以下部分略显枯燥，如果纯投资考虑的话，可以直接看第四部分：Zether面临的挑战。

一个基本的Zether功能：

Zether账户使用ElGamal加密进行标识，这些公钥存储在ZSC的内部状态当中。用户通过Fund transaction存入以太币到指定一个Elgamal公钥，来创建一个Zether账户。例如：通过公钥y，用户将b ETH发送到这个智能合约，可以获得b ZTH的账户。用户通过Transfer transaction将ZTH从Zether帐户转移到另一个帐户。用户通过Burn transaction将Zether帐户相关联的所有ZTH换成以太坊地址中的以太币。若干连续的区块组成一个Zether的epoch，各项交易都需要在当前的epoch内完成。

所有的交易通过Σ-Bullets来有效地证明各方交易余额。

Front-running（非正常预先交易）：

Zether简化版本的第一个问题，就是零知识证明需要保证合约和账户状态不变，例如，转账交易中的零知识证明，需显示剩余余额为正。用户Alice将生成与其当前账户余额相关的证明，以加密形式存储在合约当中。然而，如果另一个用户Bob将一些ZTH传输给Alice，并且Bob的交易首先得到处理，则Alice自己的交易将被拒绝，因为余额证明将不再有效。请注意，Bob可能是一个诚实用户，但在这种情况下，Alice因为处理自己交易失败而失去其支付的费用。论文将这种情况称为非正常预先交易（Front-running）。Burn transactions也有类似的问题：如果密文发生变化，加密某个值的密文证明将会失效。

为了解决这一问题，论文可引入一种新的交易类型，它只锁定账户，以防任何传入的转账。Alice可等到自己的交易写入区块链后，再开始其他交易。虽然这似乎解决了问题（需两步流程为代价），但它为像Bob这样希望将ZTH发送给Alice的用户，带来了新的问题。当Bob发布传输交易Tx时，Alice的帐户可能不会被锁定，但它可能在Tx进入之前被锁定，从而导致Tx被拒绝。

当引入匿名机制后，任何一种锁定方法都变得更加不可靠。如果Alice想隐藏自己，为了确保她的交易通过，她必须锁定匿名集中的所有帐户。显然，这是不允许的：Alice不能有权利锁定其他用户的帐户。另外，Alice只能将锁定的帐户放在她自己的匿名集中。但是，如果有人在Alice的交易完成之前，解锁了他们的帐户，那么Alice的匿名程度就会降低了。

Pending transfer（待处理交易）：

为了解决非正常预先交易（Front-running）问题，论文把所有的传入传输保留在一个等待状态中。这些转账会不时地转入账户，以便转入的资金可被使用。这种滚动法不能在任意时间发生，否则证明将会再次失效。

为了解决这个问题，协议作者将时间分为epoch时期，其中一个epoch由k个连续区块组成。k的选择取决于两个因素：a）区块链最新状态与任何用户视图之间的间隔；b）将交易纳入区块链所需的时间。在每一个epoch周期结束时，待处理的转账将转入相应的账户。用户需要在epoch周期开始时发布他们的交易。因此，即使他们没有看到区块链的最新状态，他们