基本信息
| 会议/期刊 | NSDI |
|---|---|
| 年份 | 2018 |
| 机构 | MIT Media Lab |
| 一作 | Neha Narula |
| 领域 | Blockchain，Zero Knowledge Proof，Auditing |
主要贡献
本文提出了一种支持对链上密文数据进行实时审计的区块链系统zkledger。zkledger上记录着多个银行间进行场外交易的交易记录，链上记录的交易内容是加密的。通过zkledger提出的审计协议，审计方可以实时地对任意银行进行质询，以验证银行间的交易行为符合监管当局的规定和法律要求。zkledger的证明机制确保银行无法向审计方撒谎，也无法合谋转移资产。
背景
为什么要用区块链平台做审计？
传统审计方式的缺点：
- 劳累、耗时，而且监管方没有办法实时地获取信息
- 审计方可能出错，造成巨大损失
区块链审计的优点：
- 减少验证（审计方的人力消耗）和协调（审计方和被审计方的交互）的开销
- 支持实时验证
- 区块链本身的优势：避免单点故障、匿名性、不可伪造、不可抵赖……
已有的区块链平台做审计有哪些缺陷？
早期工作（不支持加密数据的区块链审计系统）的缺点：
- 可能暴露交易方的关系
- 缺乏对隐私信息（GDPR规定的隐私信息、知识产权等）的保护
支持加密数据的区块链审计方法：
- 要么只用区块链记录交易的hash，而导致无法对链上数据进行审计
- 要么在链上记录加密数据，但可能暴露交易图，被攻击后可能被注入恶意交易记录
- 以上两种方法都不支持实时审计
系统设计
平台
本文认为，审计本身的作用是，引入被信任的第三方来证明自己的行为合法合规。因此，zkledger假设该区块链平台可以运行在某个受信任的第三方上，节点之间的通信或与外部的通信在点对点加密信道上完成。
zkledger假设系统的参与方既包括投资银行Bank1，Bank2，Bank3，…，Bankn，又包括审计方Auditor。其中，Auditor的角色是不定的，Bank也可以承担Auditor的职责。系统内的节点允许动态地增加/减少。
zkledger的Bank参与方允许向区块链平台发起交易，Auditor参与方允许对其他Bank发起质询，并将质询结果与链上数据对比，确保Bank没有撒谎。另外，zkledger还允许外部用户Depositor从Bank中取钱/向Bank中存钱，而内部的参与方却不能修改某项资产的总量（没有外部输入输出的情况下，内部资产既不能凭空增加，也不能凭空消失）。
交易
在审计业务中，区块链作为交易数据的分布式账本，应该记录的是资产法定保管权的变更，而不是所有权的变更。
一条zkledger的交易表示为：Banki向Bankj转移v股t资产。而在zkledger链上记录的交易信息里，交易的参与方和资产数量是隐藏的，而交易发生的时间和资产类型是公开的。另外，交易的拓扑顺序也是隐藏的。
zkledger使用Pedersen Commitments来对交易的资产数量进行加密。Pedersen Commitments满足additively comitment的性质。大概可以表示为，对资产数量v（非负整数）和随机数r，用以下方式加密：
zkledger中所有的交易记录合在一起，可以看做是以交易为行，以Bank为列的表，这种设计下，在表中查询某Bank的资产持有量会非常方便（相比比特币采用的UTXO机制，zkledger的方法更加适合审计场景）。
虽然每笔交易一般只与两个Bank有关（spender Bank和receive Bank，其中spender Bank负责向区块链发起交易），但在每个zkledger的交易行中，会包含所有Bank的entry和所有Bank的证明信息（因为不能暴露交易的参与方）。
验证
当交易由某个Bank发起并对外广播后，其他节点需要验证交易的合法性和准确性，通过验证的交易才能被加到链上。
Proof of Balance：由于交易不能创建新的资产、也不能销毁现有的资产，因此节点需要验证交易内的总资产变化之和为0。
Proof of Assets：交易的spender Bank手中已有的资产必须要>=此次交易所花费的资产，这一操作可以通过遍历spender Bank的column里所有对应资产之和来计算出spender Bank账上的资产余额。
Range Proof：交易的资产数量要比密码体制规定的取模运算的底数小，防止恶意节点利用计算溢出导致资产的总量发生变化。
审计
审计行为和交易的广播、验证行为都涉及节点之间的交互，为了节省交互行为的开销，zkledger采用了Non-interactive Zero-knowledge Proof（NIZK）技术，在每笔交易行中的每个entry上加入多个proof来保证交易的准确性和完整性。
在zkledger上，审计协议可以保证Bank无法向Auditor隐藏已有的交易记录，因为Auditor可以访问table中Bank对应的整个列。而且Bank之间难以做到合谋，因为Auditor可以检查过去任意时刻的记录，而合谋掩盖资产转移的行为也只能掩盖一时。
审计在数学上可以被归纳为，对某项资产数据进行求和、滑动平均、方差、标准差、比例等运算。zkledger采用的Pedersen Commitments天然支持加减法运算。每种审计操作可以看做是多个加减法运算通过乘除组合在一起。其中，加减法运算在链上，由Auditor和Bank之间的交互来完成，并且与链上数据对比来验证，而乘除运算由Auditor在本地完成。（这一段是我在强行解释，目前还完全不懂零知识证明orz）
Token机制：由于记账操作只需要spender来完成，因此可能有恶意的spender在未告知receiver的情况下进行交易，从而导致receiver的本地数据与链上数据不一致。为防止这种情况，zkledger要求spender在交易中，为每个Bank对应的entry都增加一个公共可见的token，这样的话其他bank就可以通过该token来核查自己在交易后的资产变化/资产总量。
Proof of Consistency：审计行为需要Auditor和Bank之间的交互，而Bank并不想让Auditor知道自己每笔交易的资产转移数目的细节，只想让Auditor知道最后运算得到的结果（可以理解为，如果Auditor向知道sum=v1+v2+v3+…+vn，但是Bank只会帮Auditor算好sum，并不想让Auditor知道v1、v2、v3…的具体值）。为了达到这个目的，bank就不能把它所使用的随机数r告诉Auditor，而只会把自己过去每笔相关交易所使用的随机数r的和暴露给Auditor，因此在每个Bank的entry中的token项会被利用起来，token中蕴含了随机数的和的相关性质。为了防止恶意节点伪造这个信息，还需要在entry中引入一个新的证明，证明token中蕴含的随机数和之前使用过的随机数是一致的。
性能
为了提高审计过程的效率，zkledger为每个节点都设计了cache，cache中存储了节点所属的Bank当前的资产余额信息，以及Bank参与的交易信息。当Auditor向Bank发起质询时，Bank可以利用cache快速回答。
zkledger在工程实现上还引入了Map-Reduce的方法。因为Auditor可能想知道Bank平均每笔交易的信息，而Bank无法直接证明是否具体参与了某项交易。因此，审计过程被分成map和reduce两阶段。以下假设Auditor想知道Bank参与的交易总数。
map阶段：Bank对自己是否参与某笔交易做出NIZK证明。
reduce阶段：Bank在本地计算出NIZK证明的同态加密之和，并且只公开该证明内蕴含的交易总数信息。
之后，Bank将参与的交易信息、NIZK证明、参与交易的数目和随机数r发送给Auditor，Auditor负责与链上数据对比，验证准确性。