ZKP Applications
介绍一下ZKP的应用
Machine Learning
众所周知，机器学习是一个非常强大的工具，可以用于各种领域，但是许多场景中，机器学习模型都是保密的，企业并不希望公开所使用的机器学习模型（相当于商业机密）此时作为普通用户来说，如何确保这些模型确实执行了预期的行为就是一个问题
ZKP可以很好的解决这个问题，企业可以可以在不泄露模型的情况下，利用ZKP来构造一个证明，证明模型的公平性和完整性，之后所有的用户都可以验证这个证明来确定企业确实没有搞鬼搞怪
但是将ZKP用在ML上也有不少的挑战，现在的zkSNARK在构造规模约为10亿个门的电路时，需要数个小时来构造一个证明，内存开销高达64GB
举个例子，如果用VGG16架构处理CIFAR10这个数据集，模型中包含1500万个参数，对应到ZKP电路中就是11亿个门，构造证明的时间就是一个问题，而且即便是有足够长的时间来构造证明，内存又有可能吃不消，总的来说还是归约到了SNARK的效率和可扩展性问题
解决的办法是专用ZKP协议，或者针对特殊问题进行优化的ZKP协议，比如之前的博客提到的计算矩阵乘法的问题（相关例子可以看$[3]$的第三节）
这里可以看相关的论文$[Thaler13,LXZ21,ZDZD20,LKKO20,FQZ+21,WYX+21,WWT+22,KHSS22]$，笔者不懂机器学习
Program Analysis
ZKP还可以用于程序分析（印象中之前有一篇USENIX还是NDSS的paper就提到了将ZKP用到程序分析中，这一点之前的博客好像也有提到）
举个例子，如果将ZKP用于程序静态分析，这里的秘密值就是需要分析的程序$P$，公开输入为分析程序所使用的静态分析算法，然后服务器分析之后构造一个证明，从而做到在不泄露程序$P$的情况下向用户证明$P$满足特定的安全性质，比如没有缓冲区溢出漏洞或者越界漏洞
或者ZKP还可以用于揭示程序中的漏洞，但不泄露这个漏洞的相关信息，此时程序$P$就是公开的输入，然后利用ZKP来构造一个程序包含漏洞的证明，用以表明程序存在特定的输入下会崩溃或者出bug
此类场景也有一定的挑战，因为ZKP更多的是处理计算问题，而程序分析主要是针对RAM模型中的计算，这会导致最后生成的ZKP电路会很大，从而增大证明和验证的开销
解决的办法也很简单，让Prover提供一些额外的辅助输入，来提高ZKP协议的效率
相关的论文可以看下面这些
- 静态分析：$[FDNZ21,LAHPTW22]$
- 漏洞：$[GHHKPV22,CHPPT23]$
Middlebox
也是之前的USENIX的paper，提出了用ZKP来确保网络流量的匿名性，这里不再展开，可以看$[4]$这篇paper
但是用ZKP实现中间盒也存在一些问题，因为现在的加密通信大部分是基于TLS v1.3协议，其中包含了大量的常规密码学组件，比如AES、SHA系列等等，这些密码学组件都与SNARK不太适配，而为了确保TLS能正常运行，又不能将其替换为对SNAKR友好的加密或者Hash函数
尽管这些函数可以有效提高ZKP中间盒的效率，但是它并不是TLS协议标准，也不兼容所以不能换
zkBridge：Trustless Bridge Made Practical
区块链至今仍然是一项热门技术，现在有非常多的基于区块链开发的项目，为了将不同的项目串联起来，，有人提出了跨链的概念（Cross-chain Bridges）
跨链技术可以构建一个使不同区块链相互沟通的桥梁，使得多个区块链之间可以完成高效通信和数据交换
跨链的核心需求很简单，首先是需要足够的通用性，以支持多种不同的区块链项目，还有就是确保效率，确保安全性的同时将不同链之间的信任最小化
Common Approach
先来看一下现在常见的跨链技术如何实现的，现在最常见的跨链方式称为信任中介（Trust Intermediary）
信任中介的方式通常包含三个组成部分（协议）：侧链（比如PolyNetwork、Axelar），跨链委员会（Wormhole、Ronin），预言机（LayerZero），通过这三个部分相互配合来完成不同链之间的消息传输
此类方式需要有比较强的信任假设，也即假设跨链桥的结点有至少2/3是可信的，委员会中有至少2/3是可信的，且要求预言机和中间结点是独立的（不存在勾结）
信任中介模式的优点非常明显，其非常容易实现，而且链上验证的效率非常的高（比如多重签名的验证），但是缺点也很明显，不难看出它需要依赖于中介是否可信，如果中介不可信，那就会导致不安全的通信
2022年全年就有不少针对此类方式的攻击，攻击了包括上面提到的Ronin在内的多个跨链协议，损失超过20亿美元，而且有一部分还是因为私钥泄露导致的损失
Remove Trust on Intermediary
为了降低对中介的信任依赖，一个比较简单的方式是不让中介传输数据，而是让中介对数据进行签名，之后由接受数据的链对签名进行验证即可
这个思路有点类似于轻量级客户端验证，只要客户端验证并持续追踪验证状态即可
举个例子，Cosmos IBC是一个用于Cosmos链的跨链协议，这个协议会验证来自其他链的数据的区块首部，从而完成跨链数据的验证，不过此类方式也存在缺点，需要跨链的接收方部署这个IBC协议来完成数据验证（比如以太坊没有部署这个东西，就无法支持跨链）
或者向NEAR Rainbow bridge那样的做法，将其以智能合约的形式部署于以太坊来支持跨链，但是这会导致链上验证的开销非常大
Trustless Bridge
为了在消除中介的同时提供足够强的安全性，这里可以引入ZKP技术，主要思想和很多去中心化的协议类似，将对可信机构的信任转移至对密码学假设的依赖
基于这个思想，CCS 2022的paper提出了zkBridge的方案$[5]$
zkBridge结合了上述两种思想，首先需要中介扮演ZKP中的Prover的角色，接收链为Verifier
Prover持续跟踪发送链的状态，并为最新的区块的区块头$(h_t,h_{t+1})$和与这两个区块相关联的信息构造一个SNARK证明，将区块和证明发送至接收链
Verifier这边需要验证收到的区块头和相关的SNARK证明，然后利用更新合约（Updater Contract）来更新自己的链的状态
不难看出，zkBridge解决了上述两类方式中各自的缺点，zkBridge的主要优点如下
- 信任最小化：和上面提到的一样，将对可信机构的信任转移至了密码学假设
- 高效链上验证：SNARK的简洁性确保了链上验证不会太慢
- 去中心化和无授权：Prvoer不需要对任何结点进行信任
- 通用可扩展：开发者可以基于zkBridge开发自己的应用
但是zkBridge也有自己的问题
- SNARK很重：构造SNARK的主要开销来自于Prover，会影响跨链效率，而且每个区块中会包含大量的签名信息，为这些签名构造SNARK开销可太大了
- 区块链的架构对ZKP不是很友好：比如EdDSA数字签名难以用比较精简的算术电路表示
Making zkBridge Practical
为了提高效率，zkBridge利用了多种高效和并行技术，zkBridge引入了deVirgo（Virgo的分布式版本），deVirgo可以实现数据的高度并行，提速100倍，同时降低20%左右的Prover Time
deVirgo的Verifier使用Groth16来减少证明大小，并通过批处理的方式来进一步缩短证明大小与验证时间
大致的deVirgo架构图如下
对于扩展性，zkBridge分为两层，一层是基础链，主要是中介来处理数据，上层是应用层，用于部署各类不同的智能合约来完成链之间的通信
Others
后面有一些应用的例子，懒得看了，感兴趣可以看原视频$[2]$，后续有空的话会看看论文$[5]$
References
$[1]$ ZKP MOOC Lecture 14: ZKP Applications - YouTube
$[2]$ ZKP MOOC Lecture 14: ZKP Applications Overview & zkBridge - YouTube
$[3]$ 多项式扩展与和校验协议 - 三两老友杂的小岛 (snowolf0620.xyz)
$[4]$ Zero-Knowledge Middleboxes (iacr.org)
$[5]$ Tiancheng Xie, Jiaheng Zhang, Zerui Cheng, Fan Zhang, Yupeng Zhang, Yongzheng Jia, Dan Boneh, Dawn Song:zkBridge: Trustless Cross-chain Bridges Made Practical. CCS 2022: 3003-3017