因此,我理解如何使用Fiat将HVZK协议转化为随机预言模型中的非交互式zk协议。但我的问题是我不明白为什么这有用。
如果我想在某件事情上使用NIZK,我选择一个基于Fiat-Shamir的协议,这意味着我必须选择一个哈希函数,它肯定会使ROM中的zk证明无效。那么,我是否了解我当时正在使用的这个实例化协议的zk特性呢?
通常,对于使用ROM的证明,我相信这样的想法是,即使你必须选择一个真正的散列函数,如果你做了一个很好的选择,你的散列函数模拟的随机性足够接近于安全性的证明,因此你有一些理由/信念,你使用的是安全的。但是对于NIZK,情况似乎并非如此,如果您必须选择一个散列函数,zk的证明就会完全崩溃。
如果是这样的话,那么为什么人们会费心通过Fiat创建NIZK方案,而这些方案只在ROM中得到了证明?
发布于 2023-02-16 15:06:43
但是对于NIZK,情况似乎并非如此,如果您必须选择一个散列函数,则zk的证明会完全崩溃。
你为什么这么说?
最初的HVZKP模拟器是菲亚特-沙米尔NIZK模拟器的一个很好的起点,因为哈希输出足够均匀。附加的要求是RO必须是可编程的模拟器(保持一致性),考虑到事实上,模拟器经常玩的东西不正常。ROs (和散列)将它们的输出提交到输入端,因此它们不是可编程的,它们强制执行消息的时间顺序;但是请记住,模拟器不使用协议规则,它们可以根据协议规则生成假记录,随机Oracle/Hash可编程性是它们的“超级能力”之一。
因此,IMHO,从理论RO到实际Hash,ZK的唯一附加假设就是哈希输出的足够均匀性。
菲亚特-沙米尔规定,验证者和验证者使用的随机甲骨文是相同的。仿真器是一个使用协议规则的实体,但验证者必须遵循这些规则。所以在菲亚特-沙米尔,当模拟器在开发随机预言时,它会为验证者和验证者编写程序。想象验证者使用“原始”甲骨文,而不是仿真器-程序-一个使他脱离协议,所以它超出了我们的界限。
使用哈希来模拟RO意味着验证器和验证器有自己的指定哈希实现,但这并不意味着它们可以使用不同的哈希(如果他们想遵循协议);模拟器必须同时编程验证器和验证器的哈希实现。
当然,这听起来很奇怪,但如果考虑到在交互验证中模拟器的回绕能力有时表示为计算机中的VM,模拟器是VMs管理程序,能够暂停和重复运行,操作它们的状态:在这种情况下,模拟器可以暂停和回绕时间流.我要说的是一个相当大的超级大国:)
回到我们的验证者称之为哈希..。现在,验证器和验证器都是VM,它们从不交互(从验证器到某个地方让验证者读取它的一部分),但是它们都调用它们实现哈希的函数。现在我们的“管理程序”模拟器可以改变这两种功能的工作方式.为什么这比暂停和回放时间更糟糕?
您的中心观点似乎是使用“原始”哈希(模拟器未编程的)验证器会识别模拟器的假记录:
https://crypto.stackexchange.com/questions/104257
复制相似问题