东评 | Zether:以太坊隐私智能合约层

斯坦福大学的博士生Benedikt Bunz、斯坦福大学教授Dan Boneh以及Visa研究部门,联合提出了一种针对以太坊智能合约平台的隐私协议: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内,所对应的匿名集不能先于他接收新的交易之前进行更新,否则会导致失败。

作者简介:北京之东,公众号:bjzdblockchain。微信号:beijingzhidong。资深区块链投资者,从事技术研究工作,多家基金顾问。

转载须保留以上信息。

参考文档

[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/

转载声明:本文 由CoinON抓取收录,观点仅代表作者本人,不代表CoinON资讯立场,CoinON不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。若以此作为投资依据,请自行承担全部责任。

声明:图文来源于网络,如有侵权请联系删除

风险提示:投资有风险,入市需谨慎。本资讯不作为投资理财建议。

(0)
打赏 微信扫一扫 微信扫一扫
上一篇 2019年3月4日 下午11:42
下一篇 2019年3月5日 上午8:44

相关推荐

东评 | Zether:以太坊隐私智能合约层

星期二 2019-03-05 0:42:21

本文不构成任何投资建议,投资有风险,入市需谨慎!

一、什么是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内,所对应的匿名集不能先于他接收新的交易之前进行更新,否则会导致失败。

作者简介:北京之东,公众号:bjzdblockchain。微信号:beijingzhidong。资深区块链投资者,从事技术研究工作,多家基金顾问。

转载须保留以上信息。

参考文档

[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/