ZKP用途?

1. 引言

本文重点关注当前区块链未解决问题,以及如何使用ZKP(Zero-Knowledge Proof)来解决这些问题。

当前区块链待解决问题有:

  • 1)可扩容zk-rollup
  • 2)更快的哈希函数
  • 3)跨链:trust、data以及隐私
  • 4)proof aggregation的通用层
  • 5)可验证游戏以及开放世界(Verifiable gaming and open world)
  • 6)ZK系统的形式化验证

2. 可扩容zk-rollup

生成ZKP可能需要相当长的时间,特别是当我们处理像以太坊这样的传统执行环境时。当前的ZK-rollup(ZKR)项目重点关注了生成proof的效率。某些项目,如StarkNet,为了提高证明者的效率,甚至引入了新的SNARK-friendly语言,

然而,我们认为证明者的效率并不重要。这里有两个潜在的问题:

  • 1)延迟:由于proving可高度并行化,延迟并不是太大问题。
  • 2)计算成本:

2.1 zk-rollup系统的延迟问题

由于proving可高度并行化,延迟并不是太大问题。
大多数证明系统的主要瓶颈在于:

  • 1)(基于FRI的系统)构建Merkle树
  • 2)能否自然扩展到多个CPU或GPU

当前有多种实用的proof aggregation方案:

  • Plonky2
  • Halo
  • SnarkPack
  • 等等

这些proof aggregation方案使得,可并行在不同的机器上生成各个交易证明,然后将这些交易证明进行聚合。

2.2 zk-rollup系统的计算成本问题

假设当前有一个效率很低的基于CPU的prover,生成一个典型的交易正需要一整个CPU时(a whole CPU-hour)。可 以仅$0.0125每vCPU-hour的价格从CoreWeave中租用一个VM,相比域本地执行典型交易的手续费,这个开销可忽略不计。

因此,若proving很容易扩展,是否意味着ZKR就解决了扩容问题?
答案是:并不完全是!现有的ZKR设计并为解决sequencing扩容,即,native execution。不同于proving,sequencing is not trivially parallelizable。

有多种方式来激活可并行化:

  • 1)交易声明其交互的状态,使得节点可根据交易的依赖graph很容易进行并行化。Solana为该模式的典型示例。
  • 2)若不想支持更多的动态交易,只有交易执行时才知道相应交互,可使用optimitic parallelism,类似Block-STM模式。

借助这些技术,仍然受限于单台机器的资源能力,且存储仍然是瓶颈。为进一步扩容,必须引入sharding。理想情况下,分片系统将仍然支持交易atomically interact with state on multiple shards。为此,与transactional databases一样,需在访问状态之前对状态进行锁定(locking)。

除了锁定(locking)之外,Vitalik在2018年也曾推荐过yanking——使得atomicity由应用开发者来控制,yanking方案并不理想。
另一个有趣的备选方案是2020年论文Ostraka: Secure Blockchain Scaling by Node Sharding——在单个节点内使用sharding,这样sharding更简单,但运行节点更困难,由于轻节点enjoy the same security in a succinct blockchain,这个问题并不大。

3. 更快的哈希函数

对于recursive FRI-based proofs,需要哈希运算在CPU和算术电路中均是高效的。某些最新的代数哈希在设计时考虑了算术电路,但其仍比希望的要昂贵。特别是,与类似BLAKE3这样的传统哈希运算相比,在CPU上运行这些最新的哈希运算仍是昂贵的。(如,相比于BLAKE3,代数哈希在CPU上运行要慢约10 ~ 100倍,而在证明系统中验证的效率通常要搞100~1000倍。)

似乎任何代数哈希都可能受 applying a root-finding algorithm to a low-degree CICO problem 攻击。如,Algebraic Attacks against Some Arithmetization-Oriented Primitives。尽管可通过多轮计算来缓解这样的攻击,但会令整体的permutation very high-degree,从而导致相当贵的哈希。

2021年论文Reinforced Concrete: A Fast Hash Function for Verifiable Computation 中提出了一种有趣的备选项:

  • 增加单个non-algebraic层,帮助缓解类似的algebraic攻击,引入algebraic permutation(使用查找表是阻止代数攻击的一种非常稳健的方法)

但是Reinforced Concrete仅支持permutation width of 3,使得其用途受限——其无法用于类似Goldilocks这样的small fields。能否找到更通用的混合方案么?
为解决该问题,以太坊基金会已开始致力于实现针对Goldilocks域的Reinforced Concrete版本(Goldilocks域为: 2 64 − 2 32 + 1 2^{64}-2^{32}+1 264232+1),详细可参看2022年9月视频 ZK8: New Directions in ZK hashing - Dmitry Khovratovich - Ethereum Foundation

Reinforced Concrete的最大特性在于:

  • 仅需要only one round with the lookup table;
  • 所有的其它round均为arithmetization-friendly的。

有大量的攻击技术可让你跳过最开始或最后的一轮,目前为止,没有任何攻击技术可跳过中间的某轮,但是如果未来有相应的攻击技术也不奇怪。如果哈希函数在多个循环中使用查找表(即,每一个循环或每隔一个循环),则会更加令人放心。

查找表某种意义来说也是昂贵的,因需要:

  • 对field element进行分解
  • 对looked up elements进行重构,使得整个流程为a permutation over the filed,而不是对lookup table本身进行counting。正确的分解和重构是算术昂贵的。

可将 2 64 − 2 32 + 1 2^{64}-2^{32}+1 264232+1素数域元素分解为2个具有provable correctness的u32,(并在后续对其重构,)但是,对于查找表来说,u32仍然太大——and even that only works if you find a u32 lookup table that sends pairs of u32’s that represent valid field elements to pairs of u32’s that represent valid field elements。我们能想出一些在算术复杂性方面与Rescue Prime不相上下的东西吗?对于泛型素数,我们认为这是完全没有希望的。

4. 跨链:trust、data以及隐私

ZKP可能可解决bridgeentity——即,在无需中心化交易所的情况下,将资产由链A转移到链B。
根据Vulnerabilities in Cross-chain Bridge Protocols Emerge as Top Security RiskA Year of Bridge Exploits 可知,2021和2022年因黑客攻击,跨链bridge已损失达20亿美金。在这些事件中,最主要的根本原因是操作员疏忽泄露私钥,以及跨链事件验证代码中的错误。

Bridge通常是在源链锁定资产,然后在目标链上释放等额资产。bridge问题的核心在于:目标链上的bridge合约如何可靠验证资产确实已在源链锁定。当伪造相应的证明(要么通过operator的私钥 或 通过利用bug),bridge被黑且在该bridge中锁定的所有资产可能会被盗。因此,需要创建机制来实现对 授权资金移动并生成proof实体 的信任最小化,并在释放任何资金之前对这些proof进行多层验证。新一代的bridge项目已在做相应实现,具体实现方法为:

  • 1)依赖trusted watchers来监听交易,在固化交易并释放资金之前,报告欺诈submission(如Nomad)。
  • 2)在trusted SGX enclaves中处理敏感操作(验证交易、签署资金释放),并在固化交易之前验证attestations of execution(如Avalanche)。
  • 3)使用独立的Validtors网络来跟踪时间和同步跨链通讯,对这些validators的信任建立在经济学机制之上——如存款和保释金(如Axelar,Map Protocol)。
  • 4)需要trusted多方共识(如LayerZero,Multichain)。

然而,这些解决方案主要关注如何以及在何处放置和分区信任。在每种方法的某些地方,都有一些用户可能不知道的可信第三方,但他们的安全性和他们角色的诚信表现对于bridge的安全至关重要。如果他们被黑客入侵,被锁在bridge中的用户资金可能会被完全窃取。例如,可以贿赂watchers或让他们暂时下线(加上用户必须等待很长时间等待欺诈挑战期)。SGX enclaves上每年都会发布数十种不同的黑客,这些黑客可以用来执行恶意交易。来自一个独立网络的验证者通常只发布数百万美元的保证金,而bridge下则锁定了数十亿美元。validator网络可能会崩溃或故障,validator自己可能会被贿赂。

理想情况下,应是“trustless的”——即在bridge流程中,消除信任任何第三方正确工作或不被黑客攻击的需要。第三方是源区块链和目标区块链外部的实体(以及它们的validators),用户已经隐含地信任了这些实体。这在ZKP中是可以实现的,因为我们可以使用ZKP证明中某事件已发生(例如资产锁定交易),并通过智能合约验证了该proof。在这里,挑战在于如何高效、经济地使用ZKP,并使所有用户都可以在各种区块链网络上普遍访问ZKP,例如:

  • 1)不同的区块链网络采用不同的共识机制、签名、曲线,且每种组合可能需要构建新的circuits;
  • 2)基于现有工具,为非常复杂的电路生成证明需要数百到数千GB内存,且需计算几个小时;
  • 3)在链上频繁验证ZKP和验证events将是非常昂贵的。

创建“trustless” bridge的想法不并新鲜,很多项目提出了类似的想法,且某些已取得成功:

  • NEAR的rainbow bridge 基于trustless架构,但其依赖经济激励和watchers来保证由NEAR到以太坊的资产桥接安全。
    例外情况在于:任何人在向 部署在以太坊链上的NEAR轻节点合约 提交NEAR区块头(汇总来自NEAR的events)之前,必须向该合约质押Ether,Watcher(任何人都可成为Watcher)对提交的区块头进行挑战,若证明了某些NEAR event是欺诈的,则可基于成功的挑战获得该提交者的质押金。
    这种设计的缺陷类似于之前提到的Nomad。交易必须推迟16小时才能最终固化,以创造足够的经济激励,并给Watchers足够的时间来质疑提交的区块头。如果Watchers花了很长时间来识别欺诈行为,那么其间的所有交易都必须回滚。它还建立了一种信任假设,即一些观察者将始终在线,并忠实地监控所有提交的事件,以捕捉欺诈行为。如果所有Watchers都受到攻击、贿赂或下线,这一机制可能会崩溃。

为避免以上例外情况,可使用ZKP来验证所提交的区块头。NEAR validators使用Ed25519对区块头进行签名。针对单个Ed25519签名的ZKP证明在链下仅需数秒钟就可生成,并在链上以少量gas就可验证(gas量与mint 3-5个NFT的gas量相当)。挑战在于:

  • 如何将所有(100+)validdators的签名高效进行验证和聚合
  • 如何便宜地提交、验证并承诺多个区块头

由于仅需使用ZKP证明事件的发生,“bridge”的功能可扩展为跨链通讯,如支持app由某链发送消息到另一链(类似基于LayerZero的app),而不仅仅是资产转移。某些通要求为隐私或半隐私的(如 a gaming application could use Ethereum for gaming asset trading and storage, and use another faster chain for game state update and interactions between players, which should not be revealed)。

为实现以上目标,需构建一些基础设施,对于开发者来说,机遇与挑战并存:

  • 1)验证签名的ZKP circuits
  • 2)跨链通讯数据格式
  • 3)标准的证明格式以及验证流程
  • 4)数据序列化软件包
  • 5)高效的跨链通讯和握手协议
  • 6)跨链消息加密软件包
  • 7)等等。

5. proof aggregation和proof composition的通用层

proof composition是一种强大的技术:

  • 支持生成proofs of proofs。

在高层次上看,proof composition允许开发人员更好地组合证明以平衡 final proof size和 verifier runtime。例如,一个简单的组合可能涉及将 来自具有快速Prover和large proof size的系统的证明 与 具有慢速Prover和small proof size的证明系统相结合,从而产生 小而快的最终证明。proof composition可以通过几种方法实现:

  • 递归recursion
  • 聚合aggregation
  • 累积accumulation

proof composition可能发生在同一证明系统内,也可能发生在不同证明系统之间。

proof composition在区块链领域的用例有:

  • Succinct blockchains
  • Proof compression before publishing a proof to an L1 blockchain。这常用于L2 rollups中,以节约L1 gas开销。
  • 支持用户构建具有隐私数据的交易,如Aztec的zk-rollup
  • 由StarkWare首次提出的Fractal scaling分形扩容

当前的proof composition通常是指同一个项目内的,未来将看到将来自于不同项目的proof进行proof composition。

proof composition存在以下开放问题:

  • 1)需要开发者构建seamless proof composition和跨不同证明系统通讯的工具。当前都是手工方式。
  • 2)当组合多个证明系统时,需理解组合后总体系统的安全性,需要形式化验证框架来对系统安全性进行认证。
  • 3)对所实现的证明系统以及组合后的系统,进行性能测试和优化。

Delendum当前关注该领域,且致力于合作解决该问题。还致力于与Risc zero和Miden建立一个统一、中立和社区驱动的地方,以对零知识证明系统的性能进行基准测试。我们从较小的计算开始(例如,哈希函数、签名、100到1000次哈希链、不同树深度的merkle包含证明和递归),最终将转到较大的端到端场景(例如,修改图像的完整性)。如果您有兴趣为这个基准做出贡献,我们将从社区收集所需的矩阵,并希望得到您的意见。

6. 可验证计算、游戏以及开放世界

从长远来看,可验证的计算将彻底改变电子游戏的本质。电子游戏经历了多轮演变,从早期的Atari、街机游戏、家庭游戏,到通过局域网和互联网进行的多人游戏,以及手游。这些演变塑造了我们现在认为理所当然的电子游戏的各种性质——丰富的互动性、社交连接性、竞争机制和配对、沉浸感、按需访问多巴胺驱动的游戏循环以及视听效果——所有这些都是在内存容量、计算能力、音频和视频保真度以及网络速度呈指数级增长的背景下实现的。然而,很明显,区块链将以不同于以往发展的方式影响电子游戏。
我们认为,现实世界体验与现有游戏体验的区别在于我们生活的世界的开放性,尽管有一些行业领袖认为,游戏革命的关键是打破其物理限制。我们不相信一个封闭的系统,即使具有最优越的感官效果和自适应的人工智能,也不会并且应该主导这个行业的下一个时代。
因此,一个预测是:区块链将带来游戏2.0。在强大的不可变执行平台上强制实施所有权,这些平台的计算能力随着可验证计算(验证系统、验证递归和聚合、汇总层架构、硬件加速等)的持续创新而扩展,其编程范式力求无许可的可组合性和互操作性,我们正朝着一个未来迈进,在这个未来中,大量人口以模块化的方式(可组合性)无边界地直接参与核心游戏系统的创建和演化,不仅是外观项目、游戏模式、地图,还有底层角色设计、AI系统和物理系统,并拥有跨环境和生态系统的创建(互操作性)。

根据以上逻辑,存在以下机会:

  • 1)创作者友好界面:包括高级编辑器和高级编程语言。作为编辑的一个例子,克里斯·赫克在十多年前提出了Photoshop of AI的概念。至于编程语言,即使是最现代的编程语言(如Rust)也被认为是低级的,因为它们需要对低级系统(内存、线程等)有深入的了解才能接近。汇聚到一个多层次的编译方案将非常有用,在最高层次上暴露出富有表现力的以创作者为中心的编程界面,让创作者省去“学习如何编码”和用机器术语思考的麻烦。
  • 2)核心引擎系统的本地实现:随着zkVM和rollup架构的不断发展,核心游戏引擎系统必须采用实时发明的最佳模式进行本地构建。这意味着我们需要本地智能合约模式来描述物理系统、AI系统和资源/实体管理系统,其方式是模块化的、可扩展的,并且足够强健和强大,最终成为标准-只有有了强大的标准,这些游戏2.0世界才能互操作。

历史上,游戏需求在推动硬件和计算机图形技术方面发挥了关键作用。我们认为,可验证游戏在证明系统、证明递归和聚合以及硬件加速方面具有类似的潜力。
计算和游戏之间的关系长期以来一直交织在一起。游戏是20世纪90年代计算机图形学的一个意外应用。GPU的创建初衷是为了在工业3D渲染领域(如航空航天、机械工程、建筑设计等领域)抢占利基市场。令人惊讶的是,市场规模呈指数级增长,因为人们喜欢游戏,他们总是需要更好的GPU来享受游戏。游戏开发商认识到了这一机遇,在当时不断突破GPU和计算机图形算法的界限,并开发出了新的游戏,尽管当时硬件和算法受到限制,但仍具有令人振奋的视觉体验。

GPU制造商随后抓住了这个机会,在GPU研发上进行了大量投资,并与游戏开发商合作,每1-2年将性能提高一倍。操作系统开发人员后来加入进来,为游戏定义了新的标准、编程接口和库(例如DirectX)。来自行业和研究机构的资源开始集中于计算机图形技术,以满足新的需求,如计算机视觉、3D渲染、物理、模拟等领域。在2010-2020年的十年中,由于在机器学习、自动驾驶、机器人、虚拟现实等领域的应用,发现了新的用例,GPU和计算机图形技术经历了一个新的变革时代。
如果可验证的游戏和ZKP在某种程度上重复了游戏在整个行业中的轨迹和动态,我们相信,用例和实际需求最终会导致这些技术的应用比我们今天所能想象的多得多。

7. 零知识技术栈的形式化验证

Delendum之前写过一篇零知识约束系统的形式化验证的文章,总的来说,需要做很多工作。安全行业对形式化验证的重视不够。根据该文章中的观察和论点,我们认为以下将是未来研究和开发的一些有趣方向:

  • 1)为零知识证明系统的形式化验证奠定基础:
    • 1.1)为所需的属性提供通用的证明技术的形式化验证。
    • 1.2)证明系统的可重用验证抽象,例如多项式承诺方案库
  • 2)改进规范语言并验证规范语言之间的翻译器
  • 3)了解如何创建在矢量化硬件(例如FPGA、GPU和/或ASIC)上运行的形式化验证程序
    4)我们能对用于自动提高ZK电路效率的系统进行形式化验证吗?
    • 4.1)例如:选择不同电路以使设置MPC更具并行性的系统,或允许事先了解部分witness的Prover部分评估电路并使用该信息更快地计算证明的系统。
  • 5)用K证明关于ZK约束系统的陈述:
    • 5.1)在K中定义circom/cairo的语义
    • 5.2)使用K中定义的Rust语义来证明arkworks程序的属性

8. Delendum的奖学金项目

可关注Delendum发起的奖学金项目,分为开发者和研究两部分。

参考资料

[1] Delendum 2022年11月博客 Part I: What to build next in Zero Knowledge?