一个堪比POW矿业的全新市场？ZK硬件加速大讨论

主持人：Faust，极客web3

嘉宾：Vincent，DevRel of Scroll;

Leo，Co-founder of Cysic;

Siyuan,TechLead of ABCDE Capital;

Kiwi，Researcher of OKXVentures;

Marco，DevRel of Aleo;

Lynndell,Cryptography Expert of Bitlayer

本次Space涉及的详细问题包括：

1.Cysic和Lumoz两个项目都把ZK加速作为核心愿景，Cysic也提出了实时生成ZK证明的口号，那么这些技术会对以太坊的Danksharding路线有什么影响？

2. 听说Aleo有更改挖矿算法的传言，Aleo最早是一条隐私公链，挖矿算法和ZK直接相关，有人传言说Aleo好像又换回了类似于主流PoW公链的哈希算法（嘉宾们对此事进行了澄清）

3. ZK挖矿未来的愿景如何，ZK-DePIN赛道将以怎样的方式走下去？

4. 如何看待ZK-DePIN的商业化和市场化，还没有解决的痛点有哪些？

5. ZK挖矿的矿工收益模型

6. 各位老师认为如何解决不同矿工的证明生成效率差异太大的问题？

正文：1. Faust:请问ZK硬件加速对于以太坊Danksharding路线图有什么影响？

背景补充：Danksharding路线图提出了Verkle Tree和无状态客户端的概念，届时普通的以太坊节点/客户端不必在本地存储完整的状态树，区块中会直接提供每笔交易关联的状态数据，并用ZK证明这些数据出自以太坊的状态树（Verkle Tree）。而Verkle Tree对以太坊现行的Merkle Tree式存储结构进行了大幅改进，以便于生成ZK证明某段数据出自Verkle Tree中。

Leo:简单来说，就是实时生成的ZK证明可以极大地提高轻客户端和Verkle Tree的效率。Verkle Tree相对于Merkle Tree，它产生的分支/路径更多一些，如果你通过Merkle Proof证明某个数据片段出自Verkle Tree上的某个分支，你要连带打开很多个其他分支。

如果你用ZK替代Merkle Proof，可以极大程度地提高效率，可以把很多数据压缩得很小。但你如果只是单纯用一般的CPU或者GPU去生成ZKP的话，其实是非常复杂的。

我以前在Algorand做过一个项目，就叫Algorand state proof，它就要通过Merkle Proof来打开Merkle Tree上的很多分支，但这样做的效率非常低。所以你要通过ZK的Real Time Generation，或者说用这种Specialize Prover去让zk证明的生成效率大幅提升。

Vincent：4月的Web3香港大会上面，Vitalik发言提及ZK证明对协议效能最大化的重要性，他以往的发言和技术探索也体现出了其对ZK的重视。过去Scroll生成一个full compatible zkevm的Proof需要两三个小时左右，采用现有的硬件加速方案后提高到了10分钟。但这还是达不到我们想要的生成速度。

在理想化的环境下，对ZK的采用度会非常高，会渗透到方方面面，而过去ZK生成速度还不够支撑起巨大的采用率。如果ZK证明实时生成成为现实，我们就不必在安全性和免信任、可验证性等方面做任何妥协，直接用ZK来解决过去无法解决的诸多问题。在此之后的项目创新，包括应用的创新肯定会轻量化。在ZK硬件加速相关的社区内，大家都充满信心，希望能一起在这个方向上进行突破。

Siyuan：我认为Layer2，尤其是用到ZK的二层，最核心的是要做快速的Finality（交易最终确认）。只有更快地将Layer2的交易痕迹（Trace）变成ZK Proof，发送到L1上做verification，L2的最终状态才能敲定下来。有些公司为了成本考虑，不会把每个L2的区块或者很少个区块打包生成proof。此外，按照Vitalik的愿景，一层换成Verkle tree后希望每个块都生成一个即时的ZKP，离开了ZK硬件加速这样的愿景就很难实现，因此我们非常看好Cysic。

2. Faust:听说Aleo有更改挖矿算法的传言，因为Aleo最早是一条隐私公链，挖矿算法和ZK相关，现在好像又换回了像大多数PoW公链的哈希算法。想问一下嘉宾们对这个传言的看法。

Marco：是这样一个情况，近期Aleo的Testnet Beta 的话，它那个POW算法确实现是一个哈希算法，然后加进Merkle Tree去了，给了一个Root Data来算最后的大小。但是这个版本只是一个暂时版，并不是最终的版本。最终版本Aleo官方将在7月发布，希望能大家能耐心等待。

然后，其实Aleo Foundation 的 CEO Alex 曾经在一次会议上说过，他理想中的PoW算法，主要有两个要求，一是希望能够推动ZK算法的实际应用发展，解决更实际的问题，另外一个希望能保证挖矿的公平性，所以他们会按这个思路进行调整，希望大家及时保持关注。

Leo：就这个话题我想补充一下，Aleo挖矿之前的Coinbase puzzle是用MSM来做的多项式承诺，然后只是说从MSM换成了用Merkel tree 来做多项式承诺。其实从ZK的角度来看没有太大差别，只是说你里边的一个部件从之前的MSM based 变成了一个Hash based，然后这个Hash based它有各种各样的hash function，其实是一个 a mix of hash function。

Vincent：我个人也挺想问Marco老师，就是从Aleo的角度来看，对整个ZK硬件加速的生态有什么见解？现在包括像Cysic的ASIC芯片，或是Ingonyama的基于FPGA的ZK加速方案，他们的这些产品对于Aleo的发展或是未来的一些规划，是否有产生一些影响？

Marco：我个人感觉是有的，毕竟现在困扰整个ZK领域的核心问题就是ZK Proof生成太慢了，不久前Vitalik说到，通过SNARK证明系统为一个以太坊区块生成证明，需要20分钟，但以太坊12秒就会生成一个区块，这里面有很大很大的gap。我希望能有更多好的ZK加速方案来解决上述问题。

3. Faust :接下来想讨论一下ZK挖矿或者ZKDePIN相关的话题。首先想问Leo老师有关于ZK挖矿的愿景，ZK-DePIN赛道将会以怎样的方式跑下去？

Leo：我们其实是给一些ZK项目方提供了ZK proof generation的服务，而Cysic本身是个初创公司，我们不可能有那么多钱去自己购买服务器或租服务器，我们就想着团结社区的力量来整合资源。其实我们现在有几百台服务器，这几百台服务器都是在满负荷运行的状态，这个跟传统的AI-Depin项目有很大区别。

AI-Depin里面很多机器只是在那里空转，人们只是追求一个比较高的uptime，然后去撸个空投，但如果是Cysic Network的话，你的机器会真正赋能实际应用场景，不会出现空转，资源利用率更高，而且你能拿到的奖励不只是Cysic Token，还有各大ZK项目方的激励。

而且这对于ZK Prover的去中心化也有好处，让多个Prover去生成一个Proof也能减少对单个Prover的依赖。我们不但会rely on大矿工的设备，还会动员社区成员把自己闲置的硬件接进来，给整个ZK生态提供服务。

Siyuan:Cysic其实有两种客户，一种是专业的ToB大客户，另外一种比较有趣，Cysic推出了一款小型的ZK加速卡，你可以在家里的电脑上快速生成ZKP，方便开发人员甚至是普通用户。

Leo：思远刚才提到的是，应该是我们自己的设备，Cysic在明年是会大规模出货自己的ZK硬件的，这个硬件有两个样子，第一个就是ZK air，就像刚才思远提到的，差不多就是一个苹果笔记本充电器那么大，可以通过Type-C接到你的电脑上面，在本地去帮你跑ZK的generation。它的速度应该也很快，比4090卡的性能高8~10倍，利于开发者去做很多事情。

Vincent：关于ZK-Depin，其实传统Depin的想象空间往往局限在手机挖矿、手表挖矿这类东西上，但ZK硬件加速截然不同。我们Scroll很快就会有一个去中心化的Prover Market，这个在我们的路线图中有公布。我们未来的Prover部分会是Permissionless的市场模式，当然这里面会涉及到一些复杂的收益模型，目前这块的细节还在完善。但我们的方向是确定的，要向着ZK快速生成的这个方向演进，并极力避免马太效应。

Marco：关于刚才那个Cysic的ToC小设备，可以补充两点，就是Aleo转账对这种客户端本地的ZK生成有需求，如果你在自己的浏览器本地生成ZKP的话特别慢， 可能需要十几分钟甚至更久。但因为Aleo主打隐私交易，对ZKP生成有刚需，所以Cysic的那种ToC小设备还是很有意义的。

4. Faust:目前的ZK硬件加速赛道上，商业化或者市场化上还没有解决的痛点有哪些？

Leo :其实我们可以把ZK加速想象成是在做一种Proof of Work，你希望以最快的速度生成ZKP来换取奖励，这个其实跟传统PoW公链哈希算法的ASIC没有本质区别。但ZK的相关算法很多变，它不像哈希函数那样比较固定，在ZK生态里，不同项目方用的ZK证明系统基本都不一样，有的是基于KZG承诺，有的基于FRI，反正基本都不一样。

作为一个硬件厂商，Cysic其实很希望大家能够趋于统一，向一个确定的ZK证明系统靠拢，然后我们可以对这个证明系统持续优化并做到极致的加速比，而不是像现在这么多元化，因为这对ZK加速非常不利。

Marco:我个人觉得其实在算法改进和性能优化这两方面有些挑战与机会并存。去年在ZPrize竞赛中的MSM最佳GPU实现方案，按照那个ZPrize 2023年MSN这个GPU的最佳实践，StorSwift和那个yrrid在2^20的数据量的计算上来看，现在还是在360毫秒以上。如果能再缩小一个数量级的话，ZK更容易被推广。上一个嘉宾提到的证明系统不统一，确实在硬件加速这块是一个顾虑。考虑到投入产出比，各个项目都不敢做太大投入。

Leo:我们其实就是ZPrice今年MSM加速赛道的architect，今年的确比去年有了差不多20%-30%左右的提升。但MSM还需要跟ZK证明生成的其他模块来进行交互，PCIE的效率会成为数据搬运方面的瓶颈。去年我们做了一个很强大的FPGA机器，可以在10毫秒左右完成2的26次方左右的MSM计算。这已经是可以实现的最大速度了，但依然做不到真正的实时zk证明生成，很多计算步骤还是在几分钟的耗时。在我们看来的“实时生成”，是要把任意ZK电路的证明生成时间控制在1-5秒左右，这需要更优秀的方法来实现。

5. Faust:对于ZK Prover Market或者说ZK挖矿的矿工收益模型，各位怎么看？

Leo:矿工的主要收益来自于项目方的代币，比如Scroll、Zksync和Starknet，矿工的收益很大程度取决于项目方的币价。长期来看会是一个很大的市场，特别是在比特币减半之后，我觉得ZK应该整个硬件或者对于ZK挖矿来说应该是一个逐渐扩大的市场。

Vincent:我们Scroll在ProverMarket有一些研究。ProverMarket市场的大小将取决于ZK项目的数量和需求。随着越来越多的项目采用零知识证明技术，对Prover的需求也会相应增加。这种需求是相辅相成的，意味着零知识证明技术的普及和应用将推动ProverMarket的增长。

在通用性问题上，多种不同的应用和算法都有zk硬件加速的需求，比如我们熟知的Snark算法。但能否实现ZK系统的大统一在于能否开发出覆盖所有ZK项目的通用应用场景，这需要评估和优化算力的分配，避免算力的分散导致小型项目资源不足，同时防止已经具有强大算力的项目过度集中资源。

Marco：其实从Aleo这个角度来看的话，我们也在构思Prover Market的方案。如果我要隐私转账，那我确实需要人帮我把ZKP算出来，因为我本地算的话太慢了，需要很长时间。那谁帮我算ZKP我愿意付钱，其实有一些产品在陆续的提出来，但关键的问题在于安全的保障，因为你叫别人帮你算ZKP，你就要把数据提供给他，这里面有隐私泄露的麻烦。现在有一些提案在思考如何解决这类问题。

6. Faust：最后是CKB/Nervos公链联合创始人Jan问过的一个问题，像Lumoz还有Polygon都提过Prover Market的概念，但这里有马太效应，硬件设备比其他人强的矿工，永远比其他人先生成ZK证明，绝大多数的挖矿收益最后都会被那么一两个大矿工来控制。各位老师认为如何解决不同矿工的证明生成效率差异太大的问题？

Leo:我觉得这是一个亘古不变的话题，就是怎么平衡效率与公平。这个其实在不同阶段可以用不同的做法，可能在一个在初期的阶段我们更注重效率一点。就是说我们希望给客户提供更优质、更快速的一个服务，吸引更多的客户，这样整个的雪球才会越滚越大。在雪球越滚越大的时候，就可以开始注重公平了。Cysic自己的硬件就已经开始出货了，在开始出货的时候其实是可以购买一些这种性价比挺高的一个硬件，来达到跟大家差不多的一些效率。

从协议设计的角度，你也是可以做出一些相应的调整的。因为在那个时候大家的硬件的速度都有了一个不错的一个提升。在有不错的提升的时候，比如说我们假设a是速度最快的，b是速度第二快的，然后c是速度第三块，就注意这里a可能是一个群体，b可以是一个群体，c可以是一个群体。你可以通过一些调度来调整，速度稍微慢一些的群体依旧是可以参与的，依旧是可以从中分得一些利益的。

当然公平不能强求，比如说他的投入没有大矿工的prover那么高，其实从公平的角度来看也不应该获得那么大的一个利润。这是我们后面会使用的一个设计哲学。

Marco:这是一个挺难回答的问题。如果从PoW的角度来说，我们会希望把门槛降低，就像Aleo的testnet3的时候，一个proof既可以被4090计算，也能被一个mobile计算，收益是按照能力比来算出来的。如果是为实际业务需求服务，还是希望做的又快又好，谁先算出来谁就赢得激励，大矿工卷硬件对于ZK需求方是有好处的，但真要解决公平问题，其实很难。

Lynndell：我觉得这个问题顺其自然就好，现在比特币也是这样，谁的算力大或者矿池的算力，挖到的矿就很多。其他普通用户根本就没戏，就只能提供算力去加入矿池。所以ZK这边也是一样，它跟Pow几乎是相同的，就是靠算力，这么一来的话顺其自然就行。