zkLedger: Privacy-Preserving Auditing for Distributed Ledgers是2018年发表在Symposium on Network System Design and Implementation(NSDI)上的一篇文章。他们提出了zkLedger,在保护了分布式账本中参与方的隐私的同时允许快速可证明正确的审计。
作者 Neha Narula & Willy Vasquez & Madars Virza
优点:
- 使用的非交互的零知识证明无需可信设置
- 完备性
特点:
列式账本构造,通过一列可以查看一个银行所有的持有资产。
解决的问题:
传统类型的审计时间消耗大,因此无法达到实时性——>使用分布式账本
使用分布式账本会带来隐私性问题,现有的两种类型的解决方案:
- 对账本上交易的hash值进行承诺,由一个可信第三方独立验证交易
- 使用承诺方案隐藏交易的内容
第一种方案失去了分布式的性质,第二种方案无法隐藏交易图。
在zkLedger中,参与方在分布式账本中存储的是交易值的承诺而不是明文,其中使用的承诺方案是同态承诺方案。参与方可通过向审计员打开所有审计相关的交易承诺完成审计过程,并且审计回答与分布式账本保持一致。
挑战:
隐私和审计——使用Pedersen承诺隐藏交易值;使用交互式map/reduce范式结合非交互零知识证明回答复杂的审计询问。
审计完备性——审计完备性指的是在审计时,参与方不能向审计员隐藏资产,此外审计员也不能知道谁参与了交易。因此在对一个参与方进行审计时,审计员要验证每一个交易,使用commitment caches和audit token解决效率问题。
效率——除了上一个挑战中提到的commitment caches外,为了减少通信开销,zkLedger中交易的发起者独自创建交易,无需交互,为了避免恶意的发起者使用承诺加密错误的值,zkLedger中加入了证明,证明还可以保证每个参与者都有audit token,audit token允许在审计员询问时,与交易无关的其他参与者可以正确打开。通过使用析取证明,减少范围证明的开销。
概览
n个参与方称为银行Bank,一个审计员Auditor,一个Depositor或者一个集合的Depositers可以从系统中发行并且撤回资产。银行之间在账本之外交流交易细节,假设他们使用加密信道。zkLedger是一个仅追加账本。
密码学构建模块
承诺方案
是一个有个元素的循环群,令g和h是中两个随机生成元,Pedersen承诺中对一个整数的进行承诺:选择一个随机数,承诺值为
公钥加密
Schnorr签名密钥对
非交互零知识证明
威胁模型
不诚实的银行,在交易中的支出者和接收者都不与审计员串通时,交易的金额和参与者的隐私可以得到保护。
设计
承诺缓存是对所有交易值的和的承诺,可以加快新交易创建(在新交易创建时需要用到该参与者之前交易值的和)和审计者审计。
将参与者称为银行。
交易
账本为一张表,行对应的是每一条交易,列对应的是每一个银行。
列的每一项包括一个对交易值的承诺,表示借记或贷记到银行的资产的数量。时间的资产类别(欧元之类)明文显示。
每一条交易对每个银行都有一项,用大小为n的向量表示对值的承诺,每一个承诺都使用新的随机数。
账本必须满足:
- 交易不能生成或减少账本资产。
- 支出银行必须同意转账并且有足够的资产。
使用证明
Proof of Balance:证明交易没有成或减少账本资产,即。选择满足,验证者可以验证。
Proof of Assets:证明支出银行有足够的资产。支出者对包括新交易在内的所有交易它所在的列的值的和进行承诺,如果和大于等于0,它可以进行交易。在它的值为负的新交易中,银行在证明中包含一个它的私钥的知识证明表明它同意交易。因此使用析取证明,证明条目i的承诺要么或者交易的创建者知道的私钥。范围证明:因为承诺方案是在循环群中,,这两个无法区别,因此需要范围证明值在。方案中包括两个范围证明,承诺值的范围证明和列中的资产总和的范围证明,可以将它们压缩成一个承诺值。
审计协议
审计员有一个账本的副本,和银行交互进行审计计算。而恶意的银行作为支出者时,可以不通知其他银行打开承诺所需的随机数r,这时,其他银行无法为审计员打开承诺。
所有的银行必须有足够的交易信息为审计者打开承诺。
zkLedger要求支出银行在每一个条目里包括一个公开可验证的Token,。其他银行使用该token打开承诺,不需要知道。
假设审计员查询一个银行列中的值的和,一种回答的方法是告诉审计员和,审计员验证。但是当银行没有参与交易时,该银行不知道,需要交易支出者为银行加密,为了避免支出者将无效的密文放到账本上导致银行无法正确回答审计员的询问,需要用一个一致性的零知识证明,证明加密值和承诺值的一致性。
为了证明打开为,银行计算和,证明,等式两边都等于sk。
Proof of Consistency:证明中的r和中的一致。
最终的交易构造
对于一个在第m列的交易,每一个条目i包括:
- 承诺对传输值的Pedersen承诺
- Audit Token。用于在不知道承诺中随机数的情况下回答审计询问。
- Proof of Balance:零知识证明,验证
- Proof of Assets:一个新的承诺,对应的和一个零知识证明证明或者是的一个重承诺或者是对中值的和的重承诺并且包括范围证明,如果的承诺值是负数,则表明银行i同意转账。
- Proof of Consistency:两个零知识证明证明和中使用的随机数一样,和中的随机数一样。
增加或删除银行
zkLedger支持动态增加或删除银行。参与方向帐本中添加一个已签名的交易表明哪一个银行和对应的列应当被添加或者删除。
优化
为了更快地生成和验证这些证明,并且支持更快的审计。银行缓存自己的列中承诺的乘积能加快审计和证明创建速度。每家银行按行或者按资产存储承诺的滚动乘积。
大部分交易不会包括每一个银行,每个银行可以预生成许多对0的范围证明,并且通过并行化范围证明产生和验证加速交易。
审计
除了求和外,zkLedger还支持更多的通用查询模型,可分为两部分:map和reduce。
基本审计。审计员询问一个银行帐簿上有多少资产。审计员通过资产筛选行,将银行相对应的列的条目相乘,询问银行打开承诺。需要一轮通信和常数大小的信息。
Map/reduce.审计员进行更复杂的询问可能需要交换更多的数据或者需要参与者查看几乎所有的行。考虑审计员想知道一个银行和某种资产的平均交易大小。
- Filter。银行按照资产类别筛选行。
- 产生新承诺。对每一行,银行将会承诺1比特,1或0,表示银行是否参与这个交易中(即该交易中对应的银行的承诺值是否非0),并产生一个证明表明银行正确做了重承诺,并且值是正确计算的。这一步称作map。
- 计算非零交易的数量。银行计算对的新承诺的同态和。这一步称作reduce。这是计算平均值的正确的除数。
- 回答审计员。银行向审计员发送这些值的和,比特承诺向量和对应的NIZK证明。
- 验证。审计员先验证承诺是正确计算的,再验证非零交易的数量
- 计算答案。
审计员询问交易值的方差:
- 计算平均交易值。运行上面的协议计算非零交易的数量n,和他们的平均值。
- 使用平方map。对于该银行中的每一个,银行产生一个新的对的新承诺,并将这些承诺值和一个表明正确计算的NIZK证明发送给审计员。
- 使用reduce步骤。审计员计算承诺的乘积,银行打开承诺和。审计员确定承诺的乘积等于。审计员计算方差。