附上论文地址: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周期开始时发布他们的交易。因此,即使他们没有看到区块链的最新状态,他们