AD
首页 > 数字货币 > 正文

干货 | 要给智能合约增添隐私性并不简朴_数字货币

[2021-02-10 09:14:22] 来源: 编辑:wangjia 点击量:
评论 点击收藏
导读: 当涉及表达能力,信任和效率时,在智能合约的隐私保护上进行的探索提出了很多有趣的理论和实践挑战。 两大设计偏向,寻找对冲高Gas费的方式Gas 作为在链上过路收费的“通行证”,其风险管理工具将会变得越
当涉及表达能力,信任和效率时,在智能合约的隐私保护上进行的探索提出了很多有趣的理论和实践挑战。

两大设计偏向,寻找对冲高Gas费的方式

Gas 作为在链上过路收费的“通行证”,其风险管理工具将会变得越来越重要

作者 :RAVITAL SOLOMON
翻译 校对 : 戡乱 阿剑

对用户来说,通俗买卖的隐私珍爱(译者注:文中有时也会简称为隐私买卖)基本上算是一个已解决了的问题(只管在研究上仍然遗留了一些挑战)。若是我们想在不透露账户余额或转账金额的前提下转移密码学钱币,我们有诸如大零币(Zcash)或门罗币(Monero)这样可接受的选项。不外,对于去中央化应用或者智能合约来说,隐私珍爱仍是一个尚未解决的问题。

是什么让智能合约与通俗买卖在输入 / 输出(I/O)的隐私珍爱上有所差别呢?

在本文中,我们将解密隐私珍爱从通俗买卖拓展到智能合约上会遇到哪些挑战。为此,我们将考察应用于隐私币的常用密码学工具,并探讨为什么这些工具不太适合更庞大的隐私应用。最后,我们将简要先容最近提出的一些智能合约隐私珍爱方案。


隐私珍爱的界说


隐私珍爱」到底是什么意思?

我们将从函数的角度来界说隐私珍爱。例如,我们可以把买卖看作是一些函数,它以账户余额和转账金额作为输入。然后它输出更新后的余额。

图 1:以函数来示意买卖历程。

(要实现隐私珍爱)我们可以思量隐藏函数的输入和输出。就买卖而言,这可以让我们隐藏账户余额和转账金额。你会愿意公然你的账户余额和转账历史吗?可能不会吧。因此,我们至少要支持函数(以及随后的智能合约)的 I/O 隐私珍爱。

图 2:隐藏函数的 I/O。

我们也可以思量隐藏函数的_调用者_信息。有时候,函数输入会留下关于函数调用者身份的线索。在实践中,隐藏函数的输入和输出通常会和隐藏函数调用者的身份 相结合。

图 3:隐藏函数调用者。

最后,我们可以思量隐藏函数自己。这在密码学钱币领域不太常见,其通常与隐藏函数的输入 / 输出相结合。

图 4:隐藏函数自己。

当你在本文中看到 「隐私珍爱」这个词时,请把它当成一个总称,指的是_至少支持 I/O 隐私珍爱_的器械。


好吧,但我们要在那里用到隐私珍爱呢?


我们可以以为通俗买卖的隐私珍爱已被解决(至少在可行性方面确实云云,可扩展性又是另一回事了),以是让我们直接转到智能合约的隐私珍爱。

不外,我们先绕个弯子,回首一下以太坊 ……

以太坊支持用户自界说的合约,合约以代码的形式执行(也就是 「智能合约」)。这些合约用以太坊自己的图灵完整的语言编写,每执行一个操作都要支付一些(预设的)用度。因此,每笔买卖都要附上买卖费,以激励矿工打包买卖。


应用的隐私珍爱


智能合约让我们在区块链上得以构建厚实的应用 —— 从用户可买卖种种密码学钱币及其衍生品的去中央化买卖所(DEX),到允许权益持有者对提案举行投票的去中央化自治组织(DAO)。

我以为没需要长篇大论解说为什么 DAO 需要隐私珍爱;在现实生活中,投票通常都是私下举行的,以是想要隐藏我们的虚拟投票也是异常合理的。

另一方面,去中央化买卖所的隐私珍爱需要注释一下。争先买卖(front-running)无论是对中央化买卖所照样去中央化买卖所都是一个问题。在区块链天下里,争先买卖者亲切考察已提交的订单,并通过支付更高的买卖费(行贿矿工)实现插队。这使得争先买卖者 Eve 能够抢在 Bob 之前买到 Bob 想买的证券,并随后以更高的价钱卖给 Bob。封锁式拍卖 是解决这个问题的一个可能的设施。对于有兴趣的读者,可以在这里找到更多关于在去中央化买卖所的争先买卖的信息。

不外,以太坊的智能合约并没有提供任何形式的开箱即用的隐私珍爱。所有的信息都是公然可查看的 —— 合约的输入 / 输出,合约的功效,介入的用户,等等。为以太坊的智能合约_添加_隐私珍爱不是一件容易的事情,由于以太坊从一最先就没有被设计成支持隐私珍爱。虽然在以太坊上可以实现隐私买卖(通过 1,2),然则更庞大的隐私珍爱操作往往过于昂贵,甚至跨越以太坊单个区块的用度限额(即 gas limit),以至于无法实现。

岂非我们就不能设计一种新的密码学钱币,从一最先就支持任何函数的隐私珍爱吗?究竟,大零币和门罗币就是这样做的。

现在我们还不清晰若何在密码学钱币中支持随便函数(例如在投票和买卖所中需要的函数)的 I/O 隐私珍爱。为了明白这些挑战,我们需要考察密码学钱币是若何支持隐私买卖的。


通往隐私珍爱之路


我们先考察用于_通俗买卖_I/O 隐私珍爱的密码学工具。我们将关注账户模子而非 UTXO 模子的加密钱币。账户模子在支持智能合约的场景下尤其有用,不外账户模子对于隐私盘算来说不是必须的(我们将在后面看到)。

工具 1:同态加法

大多数密码学钱币的隐私珍爱方案都依赖于具有_加法同态_的加密或答应方案。为了简朴起见,我们将专注于加密方案,但同样的原则也适用于答应方案。

在加法同态加密方案下,我们有以下等式:Enc(a) + Enc(b) = Enc(a + b)。

因此,加法同态加密方案允许_任何人_这样验证买卖的有用性:Enc(balance) + Enc(transfer amount) = Enc(balance + transfer amount) (余额的加密值与转账额的加密值之和,恰即是两者之和的加密值)。

图 5:Alice 在不透露账户余额或转账金额的情况下转账。

Alice 有自己的的公钥 —— pk_a。她用自己的公钥加密账户余额 bal_a (这样就只有她自己知道账户余额)。我们用 β_a 示意她加密后的余额,β_a = Enc(pk_a, bal_a)。Alice 的公钥 pk_a 和加密后的余额 β_a 都公然在网上,任何人都能查看。

Bob 同样云云;他也有自己的公钥 pk_b,只有他自己知道的账户余额 bal_b,以及用他的公钥加密后的余额 β_b,β_b = Enc(pk_b, bal_b)。

若是 Alice 想在不透露转账金额(amnt)或她自己的账户余额的情况下向 Bob 转账,她只需要宣布用她自己的公钥加密后的转账金额,以及用 Bob 的公钥加密后的转账金额。我们划分用 c_a = Enc(pk_a, amnt) 和 c_b = Enc(pk_b, amnt) 来示意这些值。

现在任何人都可以盘算更新后的余额。Alice 更新后的账户余额是 β_a - c_a,Bob 更新后的账户余额是 β_b + c_b。

等一下!若是所有这些值都被加密了,我们怎么知道 Alice 的账户里有没有足够的钱支付 amnt 金额的转账呢?我们又怎么知道 c_a 和 c_b 加密的金额是不是一样的呢?

这就要用到我们的下一个工具 —— 零知识证实了。

工具 2:零知识证实(ZKP)

为了确保 Alice 没有在上述买卖中作弊,她需要在买卖中附上一个证实。这个证实需要注释她的账上有足够的资金以完成买卖,她没有向 Bob 转一笔负数的金额(无论是意外照样恶意),而且 c_a 和 c_b 确实加密了相同的金额。

固然,Alice 不想透露她真实的账户余额和转账金额;因此,她附上了一个零知识证实 π,让所有其他用户信赖需要的条件已经被知足,而无需透露任何分外的信息(如她的账户余额或转账金额)。

现在把所有的工具放在一起 ...

图 6:现在给隐私买卖附上需要的 ZKP

Alice 用她和 Bob 的公钥划分对转账金额举行加密,得到了 c_a 和 c_b。她提供了一个 ZKP,π,证实她在买卖中没有作弊。矿工们会验证所有的需要条件是否被知足,ZKP 是否有用。然后,他们会使用同态加法划分更新 Alice 和 Bob 的加密余额:β_a = β_a - c_a,β_b = β_b + c_b。注重,虽然用户提供了加密后的输入和一个 ZKP,然则矿工需要卖力执行盘算以及更新加密后的余额。在区块链中,我们假设大多数矿工是老实的,以是我们知道他们会准确地更新 Alice 和 Bob 的余额。

注:这是一个大大简化的注释(例如,省去了为 确保加密平安 所需要的随机性)


将通俗买卖的隐私珍爱手艺拓展到智能合约上面临的挑战


以是我们刚刚已经看到了,我们可以执行隐藏输入和输出的买卖。那么我们可以把在隐私买卖中用到的手艺,用于支持应用的 I/O 隐私珍爱吗?换句话说:

隐私盘算和隐私买卖是否差别?若是是,为什么? 问题 1

需要注重的是,隐私买卖需要知足设定的条件才是准确的(即发送方要有足够的资金,转账金额必须为正数,等等)。我们若何能弄清晰一个随便的合约需要知足哪些条件?这些条件显然受特定的应用影响。在投票中,我们可能希望证实我们隐藏的投票是在准确的范围内举行的,而对于拍卖,我们可能希望证实我们的账上有足够的资金用于封锁投标。

对问题 1 的潜在解决方案

这个问题也没那么严重;只是需要用户做更多的事情。去中央化应用的开发者必须明确他们的特定应用需要知足哪些条件,并将这些条件转达给用户。为了能够证实林林总总的条件,我们可能希望在方案中支持一些通用的 ZKP。所谓_通用_的 ZKP 就是能够证实随便的声明(不像那些现在用在大零币里的 ZKP,它们是非通用的)。

问题 2

在通俗买卖中,我们只对属于同一个用户的值举行操作(即使用同一个密钥加密)。好比在图 6 中,矿工把用 Alice 的公钥加密后的余额与用 Alice 的公钥加密后的转账金额相加。若是我们想对属于差别用户的输入值举行隐私盘算呢?这并不是一个何等牵强的需求,好比我们思量对投票做隐私珍爱时就会涉及。

对问题 2 的潜在解决方案

现在还不清晰若何在用户相互之间不透露输入明文的情况下,支持对差别用户的输入举行盘算。有一些先进的密码学元件(好比平安多方盘算和基于多密钥的全同态加密 FHE),允许用户对差别密钥加密的输入举行盘算。然而,这些方案的成本都异常高,而且有许多瑕玷。在密码学钱币的应用场景下,现在似乎没有人有一个很好的解决方案来解决这个问题(除了与介入盘算的其他用户共享明文,然后在同一个密钥下加密)。

问题 3

通俗买卖只需要同态加法,由于我们只需要将加密的转账金额加到加密的余额上。若是我们想举行更庞大的盘算,可能涉及到乘法呢?

对问题 3 的潜在解决方案

同态乘法允许我们将加密的输入相乘,使得 Enc(a)*Enc(b) = Enc(a*b) 。通过同态加法和同态乘法,我们可以示意随便多项式函数。以是,我们很自然地想到这个问题:

我们能够支持同态乘法吗?

一个既能支持同态加法,又能支持同态乘法的加密方案是全同态加密(FHE)。使用 FHE,我们仍然可以遵照图 6 中所描绘的模子。也就是,用户指定加密输入,要运行的函数,以及证实加密输入知足需要条件的 ZKP。矿工能够验证 ZKP。他们使用同态加法和同态乘法直接对用户提供的密文举行操作。

不幸的是,FHE 方案使用基于格(lattice)的加密手艺,这(在现在)与密码学钱币中使用的超高效的 ZKP 并不兼容。我们曾经写过关于 FHE 及其问题的 文章。现在,由于 FHE 存在一些瑕玷,还没有人提出基于 FHE 的解决方案。

这样,我们现在就只剩下两种方式来解决问题 3 了。

*接受我们只能支持同态加法的现状,遵照隐私买卖模子。

图 7:遵照隐私买卖模子

在这里,用户提供加密后的输入和一个 ZKP,证实他们的输入知足特定应用的一些指定条件。矿工验证证实,使用同态加法对输入举行操作。需要注重,应用于输入的函数只能用加法来示意。因此,只要函数只需要用到同态加法,我们就可以要求矿工对我们加密的输入执行随便知足该条件的函数。这就是__Zether__所接纳的方式。

*要求用户线下盘算。这样我们就不需要为加密 / 答应支持同态乘法了。

图 8:将事情外包给用户

在这里,我们要求用户 Alice 将对明文的险些所有盘算都放到线下举行。她会宣布盘算的加密输入和加密输出。由于盘算是在线下完成的(因此我们并不知道 Alice 是否老实),她同样需要提供一个 ZKP 证实盘算历程是准确的。注重,这一步对隐私买卖来说是不需要的,由于矿工会执行盘算,而我们假设大多数矿工是老实的。就应用而言,她可能还需要另一个 ZKP,证实应用指定的条件已被知足。矿工所需要做的就是验证 ZKP 是否有用,然后赞成 Alice 提出的状态调换。这就是 Zexe 和 Zkay 所接纳的设施。

我不会在这里讨论哪种方式(图 7 与图 8)更优;只想说明它们是_差别_的。


智能合约的隐私珍爱


前面我们已经谈到了在区块链中支持随便函数的隐私珍爱要面临的一些问题,现在让我们来看一看一些已有方案的组织。

若是前面说得还不够清晰,我再重申一下,这个领域距离解决问题另有很长的路要走。设计这些组织的论文(即 Zether,Zkay,Zexe)都是在已往两年中揭晓的。

Zether 是一个建立在以太坊上的隐私买卖方案。它可以延伸到支持有限的智能合约的 I/O 隐私珍爱 —— 即那些可以通过同态加法示意的合约。这使得我们可以执行简朴的封锁式拍卖(假设竞拍者会一次买下所有单元)和隐私投票(假设投票选项非 0 即 1)。遗憾的是,由于 gas 的限制,现在在以太坊上只能实现在买卖中隐藏用户余额和转账金额。与接下来的两种组织差别,Zether 使用的是 「透明」 的 ZKP (即 ZKP 不需要可信的启动设置)。

Zkay 同样延伸了以太坊的设计以支持智能合约的隐私珍爱。他们依赖 ZKP 保障隐私盘算的准确性,从而可以将大部分事情丢给用户在线下完成。因此,这种设计选择使得它们能够支持比 Zether 更多类型的函数。

Zexe 则试图延展大零币的设计,以支持随便剧本。与前两者差别,Zexe 还可以支持函数自己的隐私珍爱。

方案隐私珍爱类型模子表达能力基于哪条链设计ZetherI/O图 7加法函数以太坊Zkay*I/O图 8随便函数以太坊Zexe*I/O, 函数**图 8随便函数大零币

Zkay 和 Zexe (如前所述)使用的是带有可信设置的 ZKP 方案。不外,这些 ZKP 方案固然可以被不需要 可信设置 的方案替换。 在区块链的场景中,I/O 隐私珍爱似乎比函数隐私珍爱更有意义,由于用户很可能希望在决议是否介入合约之前先对合约举行审计。

请注重,另有其他一些用于智能合约隐私珍爱的组织(即 Ekiden、Hawk、Arbitrum),然则这些方案都需要某种准-受信托(semi-trusted)的管理器或受信托的硬件。

大多数智能合约的隐私珍爱方案都需要分外的平安假设 —— 无论是受信托的启动设置(trusted setup),准-受信托的管理器照样受信托的硬件。然而,ZKP 是一个快速生长的领域,更高效透明的组织很可能会被缔造出来。



当涉及表达能力,信托和效率时,在智能合约的隐私珍爱上举行的探索提出了许多有趣的理论和实践挑战。现在,很难说在图 7 或者图 8 所代表的方式中,哪种(若是有一种的话)可能会在区块链的隐私盘算中胜出。此外,未来全同态加密的希望能否转化到区块链中以解决问题 3,这也是一个很有趣的看点。

加入新手交流群:每天早盘分析、币种行情分析

添加助理微信,一对一专业指导:chengqing930520

上一篇:两大设计偏向,寻找对冲高Gas费的方式
下一篇: DeFi艺术周报:Messari 最近的看法越来越有道理了

加入新手交流群:每天早盘分析、币种行情分析,添加助理微信

一对一专业指导:chengqing930520

最新资讯
提供比特币数字货币以太坊eth,莱特币ltc,EOS今日价格、走势、行情、资讯、OKEX、币安、火币网、中币、比特儿、比特币交易平台网站。

2021 数字货币 网站地图

查看更多:

为您推荐