区块链隐私保护文献 An Efficient NIZK Scheme for Privacy-Preserving Transactions over Account-Model Blockchain[通俗易懂]

区块链隐私保护文献 An Efficient NIZK Scheme for Privacy-Preserving Transactions over Account-Model Blockchain[通俗易懂]读论文《AnEfficientNIZKSchemeforPrivacy-PreservingTransactionsoverAccount-ModelBlockchain》,一篇写的很好的关于区块链隐私保护的文章

读:An Efficient NIZK Scheme for Privacy-Preserving Transactions over Account-Model Blockchain

本文的目的

  • 找到一种适用于轻量级设备及智能合约的高效零知识证明

前人的工作

不能直接迁移UTXO模型的隐私保护方案的原因

在考虑用户余额的隐私时,以前基于 UTXO 的研究可能由于以下原因而行不通。首先,密码承诺方案可能会给系统中的并发余额更新带来困难。其次,高计算复杂度极大地限制了它们在轻量级但广泛使用的设备(例如手机)中的应用。最后,它们都不支持以太坊的智能合约系统,它提供了在区块链中运行的更灵活和任意的交易操作。因此,我们有动力提出一种具有 Account 模型的机制,用于创建具有上述隐藏和更新功能的表达性去中心化智能合约 (DSC) 系统。

Gregory Maxwell

比特币核心开发者Gregory Maxwell首先将保密交易概念化,作为保持交易金额不被披露的解决方案。他们的解决方案是基于Pedersen承诺方案,其中交易金额在发送给收件人之前被随机遮蔽的因素所掩盖,并由收件人最近公证。清楚的是,这些被掩盖的金额仍然可以用于某些类型的计算,这意味着一个交易的所有输入和输出可以分别加起来,这两个和可以被比较,以确保在验证过程中的权衡,而不透露真实的价值。

RingCT(基于环签名的环保密方案)的不可行性

RingCT方案通过允许将交易中发送的金额隐藏在一个匿名集合中,提高了区块链的隐私。此外,可链接机制的配备可以确保任何重复消费行为都能被及时发现。

然而,基于CT的方案对输入和输出有一定的限制,而这可能会导致随机性降低,降低整个方案的安全性。此外,模糊因素可能需要以某种方式同步到双方,这可能会导致并发问题,并且在实施到金融系统(如BDSCF)时有一点困难。

Zerocash的不可行性

Zerocash采用了零知识的简洁非交互式知识论证(zkSNARKs)和加密承诺方案来实现最高级别的隐私保护和基于UTXO模型的加密货币的匿名性。交易包括对一个新币(Zerocoin)的加密承诺,其中指定了币的价值、所有者地址和唯一的序列号。当消耗输入硬币时,需要零知识证明和序列号来证明输入硬币的所有权以及输入和输出之间的权衡。 zkSNARKs用常数组元素生成证明,并且具有非常快的验证时间。

然而,一方面,由单向散列函数产生的加密承诺不支持账户模型,因为在设计Zerocash时没有考虑同态操作(并行问题,一个账户可能同时发起多笔向不同账户的交易支出)。

另一方面,zkSNARKs的证明生成过程和可信设置过程相当昂贵,导致效率下降,不适合轻量级设备(如移动电话)。此外,它们还依赖于强大的不可证实的假设,如指数知识假设。

后续还有一些基于zerocash的研究,但是均未能解决性能上的问题。

Kosba 方案的不可行性

Kosba等人实现了一个加密套件,可以用可编程的逻辑掩盖交易。它应用智能合约来存储用户产生的承诺币,并决定支付的分配。一旦用户打开承诺并将信息透露给经理(他被信任为不会泄露用户的私人数据),经理就会与智能合约互动,生成新币并支付给收款人。新币最近将被提交到区块链上,其合法性为零知识证明。这种情况提供了可编程性,而不向公众暴露明确的交易信息。

但是类似中心化混币的概念,这种方案所有的交易金额这个中心经理都会知晓,在金融领域这种方案不适合对交易金额和余额的隐私保护。

一些概念

UTXO模型

一个未花费的交易输出(UTXO)就代表一定数量的比特币。多个 UTXO 可以组合、单个 UTXO 也可以拆分,做出支付所需的任何面额。

我们可以将 UTXO 理解成实物货币,因为它们必须作为完整的一个单元来使用。如果你想花 5 毛钱,你不可能掰开一个 1 块钱的硬币来付款。相反,你必须花掉整个 1 块钱,然后拿 5 毛钱的找零。但是,不同于实物货币,UTXO 没有标准面额。一个 UTXO 可以是任意数量的比特币。

顾名思义,一个 UTXO 就是一个比特币交易的输出。输出以 UTXO 的形式存在,直到被用作另一个交易的输入为止,这时就不再是未花费的。

在任意时间点,现有 UTXO 的集合都被称为 UTXO 集。比特币节点会追踪 UTXO 集,从而确定哪些代币未被花费,以及哪些人可以花费它们。该系统可以让比特币解决多重支付(Double Spend)问题。双重花费问题是长期困扰数字货币尝试的一大难题。

总得来说,一笔交易由输入和输出以及剩余数组成,例如:A挖矿得到了10BTC,给B 5BTC,这笔交易中输入就是10,输出就是5,剩余就是5。这笔UTXO就是5BTC,而所有的UTXO都是完整的不可分割的。

和比特币系统中的UTXO模型不同,以太坊引入了账户模型,和一个运行在区块链中的去中心化的任意用户定义的编程系统,命名为智能合约系统。这一理念的引入导致一些之前在比特币系统中能正常使用的隐私保护方案不再有效。

UTXO模型和Account模型的对比

UTXO 与账户余额模型_元宇宙iwemeta的博客-CSDN博客_utxo和账户模型

同态加密

同态加密演示网站(Pedersen Commitment

非交互式零知识证明

零知识证明
在密码学中,零知识证明(zero-knowledge proof)或零知识协议(zero-knowledge protocol)是一种方法,通过该方法,一方(the prover, 证明者)可以向另一方(the verifier, 证明者)证明他们知道值x,而无需传达任何信息,除了他们知道值 x 。
Jean-Jacques Quisquater 等人在他们的论文“如何向孩子解释零知识协议”中首次发表了一个介绍零知识证明的基本思想的著名故事(阿里巴巴洞穴):

区块链隐私保护文献 An Efficient NIZK Scheme for Privacy-Preserving Transactions over Account-Model Blockchain[通俗易懂]

在这个故事中,小女孩(Peggy)发现了用来在山洞中打开魔法门的秘密单词。洞穴的形状像一个环,入口在一侧,魔术门挡住了另一侧。小男孩想知道小女孩是否知道这个秘密词。但小女孩(Peggy)是一个非常私密的人,不想向小男孩(Victor)透露自己的知识(秘密词)或向整个世界透露自己的知识事实。
他们标记了从入口A和B进入的左右路径。首先,当小女孩(Peggy)进入时,小男孩(Victor)在山洞外等着。小男孩(Victor)不允许她走哪条路。然后,小男孩(Victor)进入山洞,大喊他想让她用来返回的路径名称,随机选择A或B。只要她确实知道魔术字,这很容易:她在必要时打开门,然后沿着所需的路径返回。
但是,假设她不知道这个词。然后,如果小男孩(Victor)给出与她输入的路径相同的路径的名称,则她只能按命名路径返回。由于Victor会随机选择A或B,因此她有50%的机会正确猜测。如果他们要重复多次(连续说20次),她成功预期到Victor的所有请求的机会就会越来越小(大约百万分之一)。
因此,如果小女孩(Peggy)反复出现在小男孩(Victor)的名字出口处,他可以得出结论,小女孩确实很可能知道这个秘密词。

这里的例子是交互式零知识证明,是说需要小男孩去指导小女孩做什么才能证明
还有一种也就是文章中用到的非交互式的零知识证明,就是利用哈希算法之类的代替小男孩的角色,只需要保证小女孩不能作假即可。

SHRANK原理讲解

浅谈零知识证明之二:简短无交互证明(SNARK)

GSW全同态加密系统

初探全同态加密之三:构建GSW全同态加密系统

基于GSW的NIZK

格密码学进阶08:基于GSW的NIZK(上)

sigma协议与Fiat-Shamir变换

区块链中的数学(七十四)–sigma协议与Fiat-Shamir变换(一篇来自blocksight大佬的文章)

性能

  • libsnarkHyrax都是ZK-SNARKs的变型
  • Zcash采用了多方计算的对策。可信设置还有一个问题就是必须为每个电路分别完成设置,譬如,现在想证明自己知道2个因数,首先得有一个可信设置。后来,想证明知道3个因数,还得再来一遍可信设置,因为约束(条件)变了。使用Bulletproofs构建的R1CS系统则不需要这种可信设置,因此避免了上述2个问题。

不同零知识证明方案的对比

寒武纪密码学证明大爆发,数十个零知识证明系统该如何选?

比libSNARK好的原因

  • setup阶段只需要生成一次公共参数

一些待解决的疑惑

  • Zerocash没考虑重放问题么?

今天的文章区块链隐私保护文献 An Efficient NIZK Scheme for Privacy-Preserving Transactions over Account-Model Blockchain[通俗易懂]分享到此就结束了,感谢您的阅读。

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
如需转载请保留出处:https://bianchenghao.cn/63778.html

(0)
编程小号编程小号

相关推荐

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注