本文将主要讨论ZKP作为扩容方案的发展现状，从理论层面描述产生证明过程中主要需要优化的几个维度，并引深到不同扩容方案对于加速的需求。然后再围绕硬件方案着重展开，展望zk硬件加速领域的摩尔定律。最后，关于硬件zk加速领域的一些机会和现状，会在文末阐述。首先，影响证明速度的主要有三个维度：证明系统，待证明电路规模，和算法软硬件优化。对于证明系统来说，凡是使用椭圆曲线的算法，也就是市面上主流的Groth16，目前都有时间长的瓶颈。对于FRI-based算法，如ZK-Stark，其多项式承诺产生方式是HashFunction，不牵扯EC，所以并不涉及MSM运算。证明系统是基础，待证明电路的规模也是核心的硬件优化的需求之一。近期讨论很火的ZKEVM据对以太坊的兼容程度不同，导致了电路的复杂程度的不同，比如Zksync/Starkware构建了与原生以太坊不同的虚拟机，从而绕开了一些以太坊原生的不适合利用zk处理的底层代码，缩小了电路的复杂长度，而Scroll/Hermez这样目标从最底端兼容的zkevm的电路自然也会更复杂。一个方便理解的比方是，电路的复杂性可以理解为一辆巴士上的座位，比如普通日子下需要搭载的乘客数在30人以下，有些巴士选择了30人的座位，这些巴士就是Zksync/StarkWare，而一年中也有一些日子有特别多的乘客，一般的巴士坐不下，所以有一些巴士设计的座位更多。但是这些日子可能比较少，会导致平时会有很多空余的座位。硬件加速对于这些电路设计更复杂的电路更迫切，不过这更多是一个Specturm的事情，对于ZKEVM也同样有利无弊。不同证明系统优化的需求/侧重点:基本：当一个待证明事物经过电路处理之后，会得到一组标量和向量，之后被用来产生多项式或者其他形式的代数形式如innerproductargument(groth16)。这个多项式依然很冗长，如果直接生成证明那么无论是证明大小或是验证时常都很大。所以我们需要将这个多项式进一步简化。这里的优化方式叫做多项式承诺，可以理解为多项式的一种特殊的哈希值。以代数为基础的多项式承诺有KZG,IPA，DARK，这些都是利用椭圆曲线产生承诺。FRI是以HashFunction为产生承诺的主要途径。多项式承诺的选择主要是围绕几点-安全性，Performance。安全性在这里主要是考虑到在setup阶段。如果产生secret所使用的randomness是公开的，比如FRI，那么我们就说这个setup是透明的。如果产生secret所利用的randomness是私密的，需要Prover在使用之后就销毁，那么这个setup是需要被信任的。MPC是一种解决这里需要信任的手段，但是实际应用中发现这个是需要用户来承担一定的成本。而上述提到的在安全性方面相对卓越的FRI在Performance并不理想，同时，虽然Pairing-friendly椭圆曲线的Performance比较卓越，但是当考虑将recursion加入时，因适合的曲线并不多，所以也是相当大的存在相当大的overhead。
图片来源：https://hackernoon.com
JustinDrakeonPolynomialcommitment,Part1行业现状：当前不管是的基于Plonk(matterlabs)或者基于Ultra-Plonk(Scroll,PSE)，他们最后的多项式commitment都是基于KZG，故而Prover的大部分工作都会涉及到大量的FFT计算(产生多项式）和ECC点乘MSM运算。在纯plonk模式下，由于需要commit的point数量不大，MSM运算所占的Prove时间比重不高，所以优化FFT性能能够短期带来更大的性能提升。但是在UltraPlonk框架下，由于引入了customergate，prover阶段设计的commit的point数量变多，使得MSM运算的性能优化也变得非常重要。不是特别友好，所以尽管GoldilocksField在机器word运算方面优势明显，但是依然难以判断Mir和PSE/Scroll方案谁是更好的方案。基于对Plonk,Ultraplonk,Plonky2的Prove算法的综合考量，需要硬件加速的模块大概率还是会集中在FFT，MSM，HASH三个方向。Prover的另一个瓶颈是witness的生成，通常普通非zk计算会略去大量的中间变量，但是在ZKprove的过程中，所有witness都需要被记录，并且会参与之后的FFT计算，所以如何高效的并行witness计算也会是prover矿机需要潜在考虑的方向。加速ZKP方面的尝试:recursiveproof-StarkNet的fractalL3概念基于recursiveproof的概念，Zksync的fractalhyperscaling，Scroll也有类似的优化。>RecursivezkSNARK概念是对一个ProofA的验证过程进行证明，从而产生另一个ProofB。只要Verifier能接受B，那么相当于也接受了A。递归SNARK可以也可以把多个证明聚合在一起，比如把A1A2A3A4的验证过程聚合为B；递归SNARK也可以把一段很长的计算过程拆解为若干步，每一步的计算证明S1都要在下一步的计算证明中得到验证，即计算一步，验证一步，再计算下一步，这样会让Verifier只需要验证最后一步即可，并避免构造一个不定长的大电路的难度。理论上zkSNARK都支持递归，有些zkSNARK方案可以直接将Verifier用电路实现，另一些zkSNARK需要把Verifier算法拆分成易于电路化的部分和不易电路化的部分，后者采用滞后聚合验证的策略，把验证过程放到最后一步的验证过程中。在L2的未来应用上，递归的优势可以通过对于带证明事物的归纳而进一步将成本与性能等要求进一步降低。第一种情况(application-agnostic)是针对不同的待证明的事物，比如一个是stateupdate另一个是MerkleTree，这两个待证明事物的proof可以合并成一个proof但是依旧存在两个输出结果除了recursiveproof以及下文主要讨论的硬件加速之外，还有其他的加速ZKP的方式，比如customgates,移除FFT等，但本文因篇幅原因不予讨论。硬件加速
硬件加速在密码学中一直是一种普遍的加速密码学证明的方式，无论是对于RSA，还是早期对于zcash/filecoin的zk-snark的GPU-based的优化方式。硬件选择
在以太坊TheMerge发生之后，不可避免将会有大量的GPU算力冗余，下图是英伟达GPU旗舰产品RTX3090的成交价格，也显示买方势力较为薄弱。
在GPU价格处于低点，同时大量GPU算力闲置，一个自然的问题就是，是否GPU是合适的加速zk的硬件呢？硬件端主要有三个选择，GPU/FPGA/ASIC.FPGAvsGPU:
先看总结：以下是trapdoor-tech关于GPU以及FPGA在几个维度的总结，非常重要的一点是：GPU在性能方面要高于FPGA,而FPGA在能源消耗则更具有优势。
一个更直观的来自于Ingoyama的具体的运行结果：
尤其是对于比特宽度更高的运算，GPU是FPGA运算速度的五倍，而消耗的电量同时也高很多。对于普通矿工来说，性价比也是一个衡量到底使用哪一个硬件的重要的因素。无论是U55C($4795)还是VU9P($8394)来说，相比于GPU(RTX3090：$1860)，价格都要高出很多。理论层面，GPU适合并行运算，FPGA追求可编程性，而在零知识证明生成的环境下，这些优势并不能完美适用。比如，GPU适用的并行计算是针对大规模图形处理，虽然逻辑上和MSM的处理方式类似，但是适用的范围与zkp针对的特定的有限域并不一致。对于FPGA来说，可编程性在多个L2的存在的应用场景并不明朗，因为考虑到L2的矿工奖励与单个L2承接的需求挂钩，有可能在细分赛道出现winnertakesall的局面，导致矿工需要频繁更换算法的情景出现的可能性不高。
ASIC是在性能与成本方面上权衡表现较优的方案，但是否是最好的方案仍然没有定论，其存在的问题是：开发时间长-需经历完整的芯片设计到芯片生产的过程，即使目前已经设计好了芯片，芯片生产也是一个冗长、烧钱并且良片率不一的过程。代工资源方面，台积电和三星是最好的芯片代工工厂，目前台积电的订单已经排到了两年后，与ZK芯片竞争代工资源的是AI芯片、电动车芯片这类web2早早做好芯片设计的已经被需求证明的产品，相比之下ZK芯片的需求并不明朗。其次，整颗芯片的性能和单个芯片的大小，也就是人们常说的20nm,18nm是成负相关的，也就是说单个芯片越小，晶片可以容纳的芯片的数量越多，即整颗的性能越高，而目前的制造高端芯片的的技术是被垄断的，对于一些中小型的代工厂这类技术方面落后顶尖一到两代，也就意味着从良品率以及芯片大小方面是落后于最好的代工厂的。这会导致对于ZK芯片来说，只能寻求一些次优的解决方案，当然也是在需求端不那么明朗的情况下基于成本的考虑，选择28nm左右的非高端芯片。目前的ASIC解决方案主要处理的是FFT以及MSM两个常见的ZK电路中算力需求比较高的算子，并不是针对具体的一个项目设计的，所以具体运行的效率并不是理论上最高的。比如，目前Scroll的prover的逻辑电路还没百分百实现，自然也不存在与之一一匹配的硬件电路。并且，ASIC是application-specific，并不支持后续的调整，当逻辑电路发生了变化，比如节点的客户端需要升级，是否存在一个方案也可以兼容，也是目前不确定的。同时，人才缺失也是ZK芯片的一个行业现状，理解密码学和硬件的人才并不好找，合适的人选是有同时具备较深的数学造诣以及多年的硬件产品设计以及维护经验。Closingthoughts-prover发展趋势EigenDA
以上都是行业对于加速ZKP的思考与尝试，最终意义就是运行prover的门槛会越来越低。周期性来讲prover需要经历大致的如下三个阶段：PhaseI:Cloud-basedprover
基于云的prover可以大大提高第三方prover的准入门门槛，类似于web2的aws/googlecloud。商业模式上来讲，项目方会流失一部分奖励，但是从去中心化的叙事讲这是一种经济以及执行层面吸引更多参与者的方式。而云计算/云服务是web2现有的技术栈，已有成熟的开发环境可供开发者使用，并且可以发挥云所特有的低门槛/高集群效应，对于短期内的proofoutsource是一种选择。目前，Ingoyama也有在这一方面的实现。但是，这依然是一个单个prover运行整个proof的方式，而在phaseII中proof可以是一种可拆分的形式存在，参与者数量会更多。PhaseII:Provermarketplace
proof生成的过程中包含不同的运算，有的运算对于效率有偏好，有的运算则对成本/能源消耗有要求。比如MSM计算涉及pre-computation，这需要一定的memory支持不同的pre-computation上的标量颗粒，而如果所有的标量都存在一个计算机上的话对于该计算机的memory要求较高，而如果将不同的标量存储在多个服务器上，那么不仅该类的计算的速度会提高，并且参与者的数量也会增加。Marketplace是一种针对上述外包计算的一种商业模式上的大胆的思考。但其实在Crypto圈子里也有先例-Chainlink的预言机服务，不同链上的不同交易对的价格喂送也是以一种marketplace的形式存在。同时，Aleo的创始人HowardWu曾经合作撰写过一篇DIZK，是一个分布式账本的零知识证明生成方法论，理论上是可行的。话说回来，商业模式上讲这是一种非常有意思的思考，但是可能在实际落地时一些执行上的困难也是巨大的，比如这类运算之间如何协调生成完整的proof，至少需要在时间以及成本上不落后于PhaseI。PhaseIII:Everyonerunsprover
未来Prover会运行在用户本地，如Zprize有基于webassembly/andriod执行环境的ZKP加速相关的竞赛和奖励，意味着一定层面上用户的隐私会得到确保，最重要的上-这里的隐私不仅局限于链上行为，也包括链下行为。一个必须要考虑的问题是关于网页端的安全性，网页端的执行环境相比硬件来说对于安全性的先决条件更高。除了链上数据链下证明外，以ZKP的形式将链下数据上传到链上，同时百分百保护用户隐私，也只有在这个Phase可能成立。目前的解决方案都难免面临两个问题-1.中心化，也就是说用户的信息依然有被审查的风险2.可验证的数据形式单一。因为链下数据形式多样且不规范化，可验证的数据形式需要经过大量的清洗/筛查，同时依旧形式单一。这里的挑战甚至不只是证明生成的环境，对于算法层面是否有能够兼容，以及成本/时间/效率都是需要思考的。但是同样需求也是无与伦比的，想象可以以去中心化的方式抵押现实生活的信用在链上进行借贷，并且不会有被审查的风险。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。