原文标题:《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 的匿名程度就会降低了。

Pendingtransfer (待处理交易):

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

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

Rolling over on a smart contract (智能合约刷新):

不幸的是,刷新智能合约并不像看起来那么简单,因为除非向其发送交易,否则智能合约不会做任何事情。人们不能指望每个用户都为每个 epoch 发送刷新消息,而且他们也无法在合适的时间获得这样的信息。

第一个想法是在收到 epoch 中的第一条消息时翻转所有帐户的待处理转帐。 然而,这给该消息的发送者带来了不合理的负担:它将不得不支付刷新其不拥有的帐户的成本,这可能非常多的 GAS。 此外,用户无法知道他们的交易是否是一个 epoch 的第一个,因此他们无法估计合适的 GAS。

当收到来自此帐户的第一条消息时,我们在一个 eopch 中刷新一个帐户 ; 因此,一条消息仅覆盖一个帐户。 为了实现这一点,论文定义了一个单独的(内部)方法来进行刷新,而每个其他方法所做的第一件事就是调用这个方法。由于没有从它们发起任何交易,因此可能存在几个连续时期没有刷新的帐户。 这不是问题,因为帐户持有人,比如 Alice,并不是想用她的钱。在稍后的某个时间点,当 Alice 想要对她的帐户进行操作时,她将发布交易。 自上次滚存以来转入其帐户的所有资金将立即转入并可用于支出。实际上,当 Alice 创建一个 ZK 证明时,她会假设她的帐户状态是当所有待处理的转移都转入其中时的状态。

重放攻击保护(Replayprotection):

与任何其他支付机制一样,Zether 需要处理重放攻击。 以太坊通过将 nonce 与每个帐户相关联来提供自己的重放保护,这需要在每个事务中签名。不幸的是,由于两个原因,Zether 的这种保护水平是不够的:(1) Zether 帐户有自己的公钥 ; 它们与以太坊地址无关。 (2) Zether 事务包含非交互式 ZK 证明。恶意行为者可以窃取这些证据并将其置于新的交易中。 如果帐户的状态没有改变,那么新的交易也将成功处理,导致资金损失。

为了防止此类问题,我们将 nonce 与每个 Zether 帐户相关联。随着事务的处理,随机数增加。来自帐户的新交易必须与交易数据一起签署与该帐户相关联的随机数的最新值,该交易数据包括任何 ZK 证明。此方法将事务的所有组件绑定在一起并确保最新。 ZK 证明无法导入恶意事务,无法重播有效事务。

有一种方式正尝试是否有办法使用以太坊自身作为 Zether 帐户。然后,帐户将使用与地址对应的密钥进行操作,这样将免费获得重放保护和签名验证。但是,这会强制用户从固定的以太坊地址操作 Zether 帐户。他们无法将帐户委托给不同的地址,例如将帐户锁定到智能合约时。此外,以太坊地址只是公钥的哈希,而不是完整形式,零知识中哈希的证明非常昂贵。最后,为 Zether 帐户提供单独的公钥也有助于使设计更加模块化和独立于平台。

与智能合约交互:

Zether 的主要设计目标是与任意智能合约互操作,这些智能合约可能包含错误甚至是恶意设计。与常规智能合约之间的一个重要区别是普通合约无法生成 ZK 证明,因为它们没有任何秘密状态,无法启动 ZTH 转移。

我们通过引入锁定 / 解锁功能使 Zether 与其他智能合约互操作。举个例子,假设 Alice 拥有一个帐户 acc。 她可以锁定自己的账户到到任意智能合约,比如说合约 SC。实际上,这会将 acc 的所有权转移给 SC。现在,Zether 将仅处理来自 SC 的 acc 交易。Alice 和其他用户或其他合同发送的任何交易都将被拒绝。但是,如果需要,ZK 证明仍将由 Alice 生成,并通过 SC 转移到 Zether 智能合约 ,SC 最终可以解锁 acc 以将其控制权返回给 Alice。

四、Zether 面临的挑战

同样的,该技术由于刚起步,也面临很多挑战。

1、GAS 消耗量过大,成本过于高昂。目前一笔最简单的转账需要 0.014ETH 的手续费,如果进行智能合约的交互,则手续费会成为天价。幸运的是,随着算法改进和以太坊升级,手续费可能会大幅下降。

2、以太坊的 GAS 机制可能会导致隐私泄露。因为部署在以太坊上的智能合约需要支付 GAS 来运行,一旦一个地址转移 ZTH 代币,他就需要同时向矿工支付 GAS,这个时候他的以太坊地址就暴露了。有两种可能的解决方法,一个是用户不停的更换地址来保持匿名,但这样很麻烦,另一个是让矿工接收 ZTH 作为手续费。最后如何解决,还要看团队的思路。

3、网络繁忙可能会导致交易失败。对于传统以太坊交易,网络繁忙可以一直等待,直到网络不再拥堵来完成交易,但在 Zether 则不行,因为每个 epoch 都有自己对应的唯一的证明集合,交易必须在自己的 epoch 完成,如果不能完成,则证明集合会发生变化导致交易失败。

4、同样的,为保证成功,发送账户需要保证在当前 epoch 内,所对应的匿名集不能先于他接收新的交易之前进行更新,否则会导致失败。

参考文档

[1] https://crypto.stanford.edu/~buenz/papers/zether.pdf

[2] https://medium.com/coinmonks/notes-on-zether-towards-privacy-in-a-smart-contract-world-6c4333f975d

[3] https://blockonomi.com/privacy-protocol-zether-conceal-ethereum-transactions/

[4] https://www.8btc.com/article/364578

[5] https://dapplife.com/zether-developers-from-stanford-aim-to-add-new-layer-of-privacy-to-ethereum/