采访者：Nickqiao & Faust，极客 Web3

受访者：YeZhang，Scroll 联创

编辑：Faust、Jomosis

来源：极客web3

6 月 17 日，极客 Web3 和 BTCEden 在 Scroll 的 DevRel——Vincent Jin 的帮助下，有幸邀请到了 Scroll 的联创张烨，来解答关于 Scroll 和 zkEVM 的诸多问题。

期间双方不但谈到了很多技术话题，还谈到了 Scroll 的一些趣事，以及其赋能亚非拉实体经济的宏大愿景。本文是此次访谈的文字版记录，超过 1 万字，共包含至少 15 个话题： ZK 在传统领域的应用空间 zkEVM 和 zkVM 在工程难度上的差异 Scroll 在实现 zkEVM 过程中遇到的难题 Scroll 对 Zcash 的 halo2 证明系统作出的改进 Scroll 是怎么和以太坊 PSE 小组展开合作的 在代码审计层面 Scroll 如何确保自己的电路安全可靠 Scroll 对未来的新版 zkEVM 及证明系统的简单规划 Scroll 的 Multi Prover 设计以及其 Prover 生成网络（zk 矿池）的搭建方式等。

除此之外，张烨老师在最后谈到了Scroll 将扎根在非洲、土耳其、东南亚等金融系统落后地区，打算为该地区人民创造实体经济场景以「脱虚入实」的宏大愿景。本文可能是让更多人更好理解 Scroll 的绝佳资料之一，推荐大家仔细阅读。

1.Faust: 请问张烨老师对于 ZK 在 Rollup 之外的应用怎么看？不少人习以为常地认为，ZK 的主要用处在混币器、隐私转账或 ZK Rollup 和 ZK 桥这些地方，但在 Web3 之外，比如传统行业里对 ZK 的应用还是很多的。您觉得未来 ZK 最有可能在哪些方向上被采用？

YeZhang：这是一个好问题，传统行业里做 ZK 的人，在五、六年前就在探索 ZK 的各种场景，区块链中用到 ZK 的场景其实非常小，这也是为什么 Vitalik 觉得十年后，ZK 的场景会和 blockchain 一样大。

我觉得在那些需要信任假设的场景中，ZK 会有很多用武之地。假设你现在需要处理一些繁重的计算任务，如果你在 AWS 上租服务器，运行自己的任务并得到结果，相当于你在自己控制的设备上做计算，然后你要支付租服务器的钱，但这笔钱往往并不便宜；

但如果我们搞计算外包的模式，很多人可以用自己闲置的设备或资源分担你的计算任务，你付出的成本可能比自己租服务器更便宜。但这里存在信任问题，你不知道别人返回给你的计算结果是否正确。现在假设说你在做一个很麻烦的计算，然后你把计算交给我来做，再给我钱。我过了半小时后随便交给你一个结果，你也没有办法相信这个结果是有效的，因为我可以随便编个结果。

但如果我能向你证明，交付的这个计算结果是对的，那你就可以放心了，并且也敢把更多计算任务外包给我来做。ZK 可以把很多不可信的数据来源变为可信的，这个功能非常强，通过 ZK，你可以把不可信但很便宜的第三方计算资源更高效的运用起来。

我觉得这个场景非常有意义，可以催生类似于外包计算的商业模式。在一些学术文献里，称其为可信计算（verifiable computation），就是把一个计算变得值得信任。除此之外，ZK 可以应用到数据库领域，假设在本地运行数据库太贵了，你决定走外包的路子，恰好一个人有富余的数据库资源，然后你把数据存储在他那边。你会担心对方更改你托管在他那的数据，或者说你一个 SQL query 后得到的结果对不对？

对此，你可以让对方生成一个 proof，如果这件事能做到，你可以把数据存储也外包出去，并得到一个 trustworthy 的结果。这和前面的可信计算彼此都是一大类应用场景。

此外还有很多应用实例，我记得有篇论文讲了 Verifiable ASIC，在生产芯片的时候，可以把 ZK 算法写到你的芯片上，当你用芯片运行程序的时候，产生的结果默认会带一个 Proof。这样一来我觉得很多东西都能代理给任何一台设备，生成可信的结果。

还有一个有点扯的东西，叫 Photo Proof 照片证明。比如说很多图片，你不知道是不是 P 过的，但我们可以通过 ZK 去证明相片没有被篡改过，比如可以在相机软件中加一些设置，自动生成一些数字签名，你拍完照片后，这个签名相当于给照片盖了章。如果有人把你拍的照片拿去 PS，搞「二次创作」，我们验证下签名就能识别出图片是被改动过的。

这里面我们可以引入 ZK，当你对原图进行了些许改动后，你可以用 ZK Proof 向别人证明自己只是对照片做了旋转、平移等简单操作，并没有篡改照片的原始内容，证明自己微调后的图片和原版图片基本一样，也就是证明自己没有篡改图片的核心内容搞「二次创作」。

这个场景还可以拓展到视频音频上，通过 ZK，你不必告诉对方自己对原版视频做了哪些改动，但可以证明自己没有篡改原版的核心内容，证明自己只做了一些无伤大雅的调整。此外还有很多有意思的应用，都是 ZK 能插一脚的。

目前，我觉得ZK 的应用场景还没有被广泛接纳的原因，在于其成本太高，现有的 ZK 证明生成方案，还不能做到对任意计算都实时生成证明，因为 ZK 的开销一般是原始计算的 100 倍到 1000 倍，当然我说的数字已经是压的比较低的了。

所以你想象一下，一个计算任务本来要算 1 小时，你现在给它生成个 ZK Proof，Overhead 可能是 100 倍，也就是要花 100 个小时来生成证明，虽然你可以用 GPU 或 ASIC 把这个耗时给缩短，但还是要付出巨大的计算开销，如果你要求我算一个很麻烦的东西，还要求我为此生成 ZK Proof，我可以拒绝这么做，因为这要额外耗费 100 倍的计算资源，最后落实到经济账上就很不划算。所以对于一对一的场景来说，生成一次性的 ZK 证明很昂贵。

不过，这也是为什么对于 Blockchain 来说，非常适合用 ZK，原因是区块链做的是冗余计算，有很多 1 对多的场景。区块链网络中不同节点做的是相同的计算任务，如果有 1 万个节点，那么相同的任务要被执行 1 万次。但如果你在链下完成任务，生成 ZK 证明，1 万个节点只验证 ZK 证明而不重跑任务，就不必再把原始计算重放 1 万遍了，相当于你用自己 1 个人的计算成本，和 1 万台节点搞冗余计算的成本做了置换，从整体的角度看，可以让更多人节约资源。

所以，其实链越去中心化越适合搭配 ZK，因为任何人都能近乎零成本的验证 ZKP，我们只要在初始生成证明的时候付出一定成本，就可以换来对大多数人的解放，这就是为什么区块链的公开可验证性非常适合 ZK，因为区块链里有很多 1 对多的场景。

还有一个上面没提到的点。现在区块链领域用到的 Overhead 比较大的这种 ZK 证明，都是非交互式的，就是你给我一个东西，我给你证明，然后就结束，因为在区块链中，你不可能反复的去跟链上交互。但有一种更高效、开销更低的证明生成方式，也就是交互式证明。比如说，你给我发一个 Challenge，我给你发一个东西，你再给我发一个东西，我再给你发一个，通过这种双方多次交互的方式，有可能把 ZK 的计算量级再降低下来。如果这种方式可以，就有可能解决大的 ZK 应用场景的证明生成问题。

Nickqiao：如何看待 zkML，也就是 ZK 和机器学习相结合的发展前景？

YeZhang：zkML 也是一个很有趣的方向，能把 Machine Learning 给 ZK 化，但我觉得这方面还是缺乏杀手级的应用场景。大家普遍认为随着 ZK 系统的性能提升，未来能够支持 ML 这个级别的应用，目前 zkML 的效率能够支持 gpt2 这种级别的应用，在技术上能做到，但只能做 ML 中的推理。归根结底，我觉得大家还是在摸索这块的应用场景，也就是到底什么样的东西才需要你证明其推理过程是对的，这个事情是挺刁钻的。

2.Nickqiao: 想请教下张烨老师，zkEVM 和 zkVM 在工程实现难度上的差异具体有多大？

YeZhang：首先，无论是 zkEVM 还是 zkVM，本质都是为某个虚拟机的操作码 / 指令集生成定制的 ZK 电路，而 zkEVM 的工程落地难度取决于你实现它的方式，在我们刚启动项目时，因为 ZK 的效率还没那么高，通过为 EVM 的每个操作码都写一个对应的电路，然后把电路组合起来，定制一个 zkEVM 是最高效的方式。

但这种方案的工程实现难度肯定很大，比 zkVM 大很多，毕竟 EVM 的指令集有超过 100 个操作码，每个操作码都要定制一套东西，然后组合起来，一旦有 EIP 为 EVM 增添新的操作码，比如 EIP-4844，zkEVM 都要相应的加新东西。最后你要写很长的电路并进行漫长的审计工作，所以开发难度和工作量要比 zkVM 大很多很多。

反之，zkVM 是自己定义了一套指令集 / 操作码，它自定义的指令集可以做的很简单，可以很 ZK friendly，你做出来一套 zkVM 后，不必频繁的更改底层代码，就能支持各种升级和预编译。所以zkVM 的主要工作量和后续升级维护的难度，就放在了编译器也就是把智能合约转化为 zkVM 操作码的那一步，这和 zkEVM 有很大不同。

所以，从工程难度来看，我觉得 zkVM 要比定制化的 zkEVM 更容易实现，但是如果要在 zkVM 上跑 EVM 的话，总体性能比定制化的 zkEVM 低很多，因为后者是专门定制的。但目前，Prover 生成证明的效率在过去两年间有了至少 3~5 倍甚至 5~10 倍的飞跃，zkVM 的效率在随之提升，现在用 zkVM 去跑 EVM，整体效率已经慢慢提上来了，未来 zkVM 在性能上的劣势可能被它易于开发维护的优势给掩盖住。毕竟对于 zkVM 和 zkEVM 而言，除去性能外的最大瓶颈就在开发难度上，必须要有一个非常强大的工程团队，才能维护好这样一套复杂的系统。

3.Nickqiao: 能否讲一下 Scroll 在 zkEVM 落地的过程中，是否遇到一些技术难题，又是怎么解决的？

YeZhang：一路走来的话，最大的挑战还是在于，最初启动项目时的不确定性太大。我们刚启动项目时，基本没有其他人做 zkEVM，我们是最早探索 zkEVM 从不可能变成可能的一个团队。在理论层面，项目刚开始的 6 个月就基本确定了一套可行的框架，而在后续实现的过程中，zkEVM 的工程量非常大，还有一些非常技术性的挑战，比如说你怎么动态的支持不同的 Pre-Compile（预编译），怎么去更高效地聚合操作码（opcode），这涉及到很多工程上的难题。

而且我们是唯一一个，也是最早支持 EC Pairing 椭圆曲线配对这个 Pre-Compile 的，像 Pairing 这种电路实现起来难度非常大，涉及到很多数学等错综复杂的难题，对写电路的人的密码学 / 数学功底，以及工程能力要求都很高。

然后在后期发展上，还要考虑技术栈的长期可维护性，以及要在什么样的时间节点，升级到下一代的 zkEVM 2.0。我们有一个专门的研究团队，一直在研究此类方案，比如通过 zkVM 的方式来支持 EVM，我们也有相关的论文去做这方面的一些讨论。

总结下来，我觉得之前的难点在于把 zkEVM 从不可能变为可能，面临的难题主要在工程落地和优化上。而下一阶段，更大的难点是在什么时候、通过什么样的具体方式，切换到一个更高效的 ZK 证明系统，以及我们怎么把目前的这套代码库过渡到下一代 zkEVM 身上，以及下一代的 zkEVM 能给我们提供什么样的新 Feature，这里面有大的探索空间。

4.Nickqiao: 听起来是 Scroll 已经考虑切换到别的 ZK 证明系统上了。据我了解，目前 Scroll 用的是基于 PLONK+Lookup 的一套算法，那么这套算法在目前是否是最适合实现 zkEVM 的，以及未来 Scroll 打算换用什么证明系统？

YeZhang: 首先我来简单回答下关于 PLONK 和 Lookup 的问题，目前这一套还是最适合实现 zkEVM 或者 zkVM 的系统，大部分的实现跟具体的 PLONK 和 Lookup 是绑定的。一般提到 PLONK 时，其实更多是用 PLONK 的 arithmetization，也就是电路的算术化表达方式去写 zkVM 的电路。

Lookup 是写电路时用到的一种方式，一种约束类型。所以当我们提到 PLONK + Lookup，指的是在写 zkEVM 或 zkVM 电路时，使用 PLONK 的约束格式，这种方式目前是最常见的。

而在后端方面，PLONK 和 STARK 的界限已经变得模糊，它们只是用了不同的多项式承诺方式，但其实很类似。即使采用 STARK + Lookup 的组合，跟 PLONK + Lookup 也是类似的，大家看的只是算法，两者的差别主要体现在 Prover 的效率、证明大小等方面。当然，就前端而言，Plonk + Lookup 来实现 zkEVM 还是最适合的。

关于第二个问题，就是 Scroll 未来打算切换到什么证明系统。因为 Scroll 的目的是永远让自己的技术和链的框架保持在 zk 领域里最顶尖的位置，所以我们肯定会用最新的一些技术。我们一直以安全性、稳定性作为最优先的目标，所以不会过于激进地切换自己的 ZK 证明系统，可能先通过一些 Multi Prover 做过渡，一步一步的摸索递进，来完成下一版的升级迭代。Anyway，要保证说这是一个平稳的过渡流程。

但就现在来说，切换到新的证明系统还很早，这其实是下一阶段比如未来 6 个月到 1 年的发展方向。

5.Nickqiao: Scroll 在当前基于 PLONK 和 Lookup 的证明系统上，有没有一些独特的创新？

YeZhang: 目前在 Scroll 主网上运行的是 halo2，halo2 最早源于 Zcash 这个项目团队，他们最早做了一个能支持 Lookup，支持灵活地写电路格式的一套后端系统。然后，我们和以太坊的 PSE 小组一起改造了 halo2，把它采用的多项式承诺方案从 IPA 换到了 KZG，把 Proof Size 变小了，从而能在以太坊上更高效的验证 ZK Proof。

然后我们在 GPU 硬件加速上做了很多工作，跟用 CPU 生成 ZKP 来对比的话，能让 ZKP 生成速度快 5~10 倍。总体来说，我们把原版 halo2 的多项式承诺方案替换成了更易于被验证的版本，并做了很多关于 Prover 的优化，在工程化落地上下了不少功夫。

6.Nickqiao: 所以 Scroll 现在是和以太坊 PSE 团队共同维护 KZG 版本的 halo2。您能否给我们讲一下，你们是怎样和 PSE 团队合作的？

YeZhang：Scroll 在启动项目前，我们本来就认识一些 PSE 团队的工程师，我们就有和他们聊，说自己想做 zkEVM，我们估计了一下这个效率是 ok 的。刚好在同一个时间节点，他们也想做同样的事，然后大家一拍即合。

所以，我们是从以太坊社区，从 Ethereum Research 那边认识了一起想做 zkEVM 的人，大家都想把 zkEVM 产品化落地，都有为以太坊服务的想法，所以很自然地开始了开源合作的模式。这种合作方式更像开源社区，而不是商业化的公司，比如我们每周都会通一次电话，同步一下进度，讨论遇到了哪些问题。

我们以这种方式去开源地维护了这套代码，从改进 halo2 到实现 zkEVM，这中间有很多探索的过程，我们相互会帮忙 Review 代码。你从 Github 的代码贡献量能看出来，PSE 他们写了一半，Scroll 这边写了一半，后续我们完成了代码的审计，并实现了一版真正产品化落地并在主网上运行着的代码。总结下来，我们和以太坊 PSE 的合作模式，更像是一个开源社区的路径，是自发的形式。

7.Nickqiao: 您刚才提到，要编写 zkEVM 的电路，对数学和密码学的要求非常高，既然如此，能摸清楚 zkEVM 的人估计很少。那么 Scroll 怎么保证电路编写的正确性以及少出 bug？

YeZhang：因为我们是开源的代码，基本上每一个 PR 都会有我们的人和以太坊的一些人，以及一些社区成员去 Review，有比较严格的审计过程。同时我们在电路审计方面也花了很多钱，超过 100 万美元，找了这个行业里最专业的密码学和电路审计机构，比如 Trail of Bits，Zellic 等。我们链上智能合约的部分也找了 openzepplin 来审计，基本上所有和安全相关的东西都动用了最高档的审计资源。我们内部还有专门的安全团队去做测试，持续提升 Scroll 的安全性。

Nickqiao: 除了这种审计方式，有没有形式化验证等在数学上比较严谨的方式？

YeZhang：我们其实很早就看过就 Formal Verification（形式化验证）这个方向，包括以太坊最近也在思考，怎么给 zkEVM 做形式化验证，这其实是一个很好的方向。但就目前来说，要给 zkEVM 做完整的形式化验证还比较早，只能从一些小的模块开始摸索，因为 Formal Verification 运行是有成本的，比如你要给一套代码去运行 Formal Verification，你要给它先写一个 spec，但写 spec 并不容易，这套东西要完善需要很长时间。

所以我觉得目前还没有到给 zkEVM 做完整的形式化验证的阶段，但我们会持续的跟以太坊在内的外部合作者去积极探索怎么做 zkEVM 的形式化证明。

目前来说，最好的方式其实还是人工审计，因为你就算有了 spec，有了 Formal Verification，如果 spec 写错了，那你还是会出问题。所以我觉得，目前最好还是先通过人工审计，然后通过开源和漏洞悬赏的方式，确保目前 Scroll 代码的稳定性。

但是，在下一代 zkEVM 中，关于怎么去做形式化验证，怎么去设计一个更好的 zkEVM 进而更容易的写出来 spec，通过形式化验证的方式去证明它的安全性，是以太坊的终极目标。就是说，当一个 zkEVM 被形式化验证以后，他们就可以彻底放心地将其实施到以太坊主网上。

8.Nickqiao: 关于 Scroll 采用的 halo2，如果要支持 STARK 等新的证明系统，开发成本会不会很大。能否实现一种插件化的体系，同时支持多个证明系统？

YeZhang:halo2 是一个非常模块化的 ZK 证明系统，你可以替换它的域、多项式承诺等，只要把它用的多项式承诺从 KZG 换成 FRI，基本就可以实现一个 halo2 版本的 STARK，这个事也确实有人做了，所以halo2 要支持 STARK，这种兼容是完全 ok 的。

然后在实际落地中会发现，如果你要追求极致效率的话，越模块化的框架越可能导致一些效率问题，因为你为了模块化牺牲了定制化的程度，会有付出一些代价。我们在持续关注一个问题，就是未来的发展方向该是模块化的框架，还是非常定制化的框架，尤其像我们有足够强的 ZK 开发团队，可以维护一个独立的证明体系，然后让 zkEVM 变得更高效。当然上述问题需要做出一些权衡，但就 halo2 而言，它可以支持 FRI。

9.Nickqiao: 目前 Scroll 在 ZK 方面主要的迭代方向是什么？是优化目前的算法、增加一些新的 feature 之类的？

YeZhang：我们的工程团队核心在做的事情，还是要把目前的 Prover 性能再提升一倍，然后 EVM 兼容性也要做到最好。在下一版升级中，我们会继续保持自己在 ZK Rollup 里最 EVM 兼容的这样一个位置，现在其他所有的 zkEVM 应该都没有我们的兼容性好。

所以这是 Scroll 工程团队一方面在做的，就是继续优化 Prover 和 Compatibility，并且要降低费用。我们现在已经投入了很多人力，去研究下一代 zkEVM，大概投入了一半的工程力量，以实现分钟级甚至秒级的 ZK 证明生成，让 Prover 的效率变得高起来。

同时，我们在探索新的 zkEVM 执行层，我们的节点之前用的是 go-ethereum，但现在有性能更好的 Rust 版本以太坊客户端 Reth。所以我们在研究，怎么把下一代 zkEVM 跟 Reth 客户端更好地结合，把整个链的性能给提升上来。我们会考察 zkEVM 如果围绕着新的执行层，该用什么样的实现方式和过渡形式最好。

10.Nickqiao: 那么像 Scroll 在考虑支持的多样化证明系统，有没有必要在链上实现多个 Verifier 合约呢？比如做交叉验证

YeZhang：我觉得这是两个问题，首先就是说，有没有必要去做模块化的证明系统和多样化的 Prover，我觉得这么做是有意义的，因为我们从始至终，就是开源项目。你把开源出去的这套框架做的越通用化，会吸引来越多人帮你造轮子，你的社区也会因此壮大，后面在项目开发或者工具使用上，可以自然而然的引用外部力量。所以我觉得，如果能做一个不光给 Scroll 自己使用，还能给其他人用的 ZK 证明框架很有意义。

然后第二个事情，就是在主网上做交叉验证这个事，这其实和证明系统本身是否是多样化的，是否支持 STARK 或 PLONK 是正交的话题。一般很少有项目把同样的 zkEVM 用 PLONK 验证一遍，再用 STARK 验证一遍，这是很少的，因为这么做对安全性的提升不大，反而会让 Prover 付出更高成本，所以一般不会出现这种交叉验证的情况。

我们其实在做一个东西叫 Multi Prover，可以有两套 Prover 一起证明相同的一个 Block，但是会在链下把两个 Proof 聚合到一起再放到链上去验证。所以，并不会在链上做 STARK 和 SNARK 之间的交叉验证。我们的多 Prover 方案，是为了保证在其中一套 Prover 的代码出问题时，另一套代码可以兜底，一套系统出了 bug 另一套能照常运行，所以这和交叉验证是另一个话题。

11.Nickqiao: Scroll 的 Multi Prover，每个 Prover 运行的证明程序会有什么不同？

YeZhang：首先，假设我有一个正常的、用 halo2 写的一套 zkEVM，有一个正常的 Prover 生成 ZKP 再去链上做验证，但这里有个问题，zkEVM 很复杂，有可能出现 bug。如果出现 bug，比如被黑客或者项目方拿去利用这个 bug 生成一个 Proof，最后能把大家的钱提走，这肯定是不好的。

Multi Prover 的核心思想，其实是 Vitalik 最初在 Bogota 活动上第一次提出的。意思是说，如果一个 zkEVM 可能出现 bug，那你可以同时跑不同种类的 Prover，比如说可以用 TEE 的基于 SGX 的 Prover（Scroll 目前用了这套），或是基于 OP，或用 zkVM 运行 EVM 的方式去跑一个 Prover。Anyway，这些 Prover 要同时去证明一个 L2 Block 的有效性。

假设有 3 个不同类型的 Prover，当且仅当它们生成的 3 个不同 Proof 都通过验证，或者说 3 个 Proof 中至少 2 个通过验证时，你才能在以太坊链上敲定 Layer2 的最终状态。Multi Prover 可以保证在一个 Prover 出问题时，其他两个 Prover 能够顶替，最后整个 Prover 系统的稳定性会很好，使 ZK Rollup 的安全性得到提升。当然这也会引入其他缺点，比如 Prover 的整体运行成本会提高，我们有一篇专门的 Blog 介绍了这些概念。

12.Nickqiao: 那现在关于 Scroll 的 ZK 证明生成这块，其证明生成网络（ZK 矿池）是怎么建设的，是自建的，还是会把一些计算外包给如 Cysic 的第三方？

YeZhang：就我们目前来说，整个设计其实很容易，我们想让更多的 GPU 持有者或者矿工参与进我们的这个证明网络（ZK 矿池）里，但目前来说，Scroll 的 Prover Market 还是我们自己运营的，我们会和第三方的一些有 GPU 集群的人合作，他们去运行 Prover，但这是为了主网的稳定性，因为你的 Prover 一旦去中心化后，会有很多问题。

比如说，你的激励机制设计不好的话，如果没有人给你产生 Proof，网络会在性能上受到影响。前期我们选择了相对中心化的方式，但是整个接口和框架的设计，非常容易切换到去中心化的模式。人们完全可以用我们的技术框架做一个去中心化的 Prover 网络，再加一些激励就行了。

但目前来说，为了 Scroll 的稳定性，我们的 Prover 生成网络还是中心化的，未来我们会更大范围的把 Prover 网络给去中心化，每个人都可以去运行自己的 Prover 节点，包括我们也在跟诸如 Cysic，Snarkify network 等等第三方平台合作，看一下如果有人想通过我们的技术栈去启动自己的 Layer2，可以去接到第三方的 Prover Market 里去直接调用对方的 Prover 服务。

13.Nickqiao: Scroll 在 ZK 硬件加速方面有没有什么投入或者产出成果？

YeZhang：这其实就是我之前提到的，Scroll 最初做的两大方向，第一个就是把 zkEVM 从不可能变成可能，第二个就是我们为什么能把它从不可能变成可能，是因为 ZK 硬件加速的效率提升了。

我其实在做 Scroll 之前的 3 年，就开始做 ZK 硬件加速方面的工作，我们也有关于 ASIC 或是 GPU 硬件加速的论文。我们对 zk 硬件这块非常了解，无论从芯片还是从 GPU，无论是从学术还是从实践上，都有非常强的 Credibility。

但是Scroll 自己会专注于 GPU 方面的硬件加速，因为我们没有专门做 FPGA 或是做硬件的资源，也没有流片的专门经验。所以我们会选择跟 Cysic 这类硬件公司合作，他们去专门做硬件这块，我们就关注 GPU 加速这样一个偏软件的领域。我们自己的团队会 GPU 硬件加速做优化，然后将成果开源，外部的合作伙伴可以去做专门的如 ASIC 等芯片，我们也会经常的讨论交流一下彼此遇到的问题。

14.Nickqiao: 您刚才提到，Scroll 未来会切换到其他的证明系统。那像一些新的证明系统，比如说 Nova 或其他的一些算法，您能不能给我们科普一下？他们有什么优点？

YeZhang：对。我们目前正在内部探索的一种方向，是使用更小的域，能跟我们目前的这些证明系统结合，比如说像 PLONKy3 这样的一些库，它可以很快的实现小域上的一些运算。这是一个 Option，怎么能从我们原来的大域切换到小域，这是一种。

我们内部也在看一些方向，比如一个叫 GKR 的证明系统，它生成证明的耗时是线性级别的，在复杂度上面比其他的 Prover 要低很多，但目前没有特别成熟的工程落地方式。这块要做的话，要投入更多的人力物力。

但 GKR 的好处是，在处理重复计算时效率很高，比如说一个签名计算了 1000 次，GKR 可以很高效的给这样的东西生成证明。ZK 桥 Polyhedra 就是用 GKR 去证明签名的，效率很高。然后，EVM 有很多重复的计算步骤，可以通过 GKR 更好的把生成 ZK 证明的成本降低下来。

然后还有一些好处，就是说GKR 这套证明系统，它需要的计算量确实要比其他系统小很多。比如说，你通过像 PLONK 或 STARK 这样的方式，去证明一个 keccak 哈希函数的计算流程，你需要把中间所有的变量、keccak 整个计算过程中产生的所有东西，全部 Commit 一遍、全部算一遍。

但是 GKR 的话，你只需要 Commit 它很短的输入那一层，它可以把中间的这些参数全部通过传递关系给表示出来，不需要你去 Commit 中间的这些变量，会让计算成本降低很多。GKR 背后的这个 sum check 协议，也被 Jolt 或者 Lookup argument 或比较火的一些新框架所采用，所以这个方向是比较有潜力的，我们也在认真研究这个方向。

最后就是你提到的 Nova。感觉 Nova 在几个月前大火了一阵，因为 Nova 也比较适合处理这种重复计算，比如你本来要证明 100 个任务，对此的 overhead 是 100。但 Nova 的做法是，我可以把这 100 待证明的任务一个叠一个，一个叠一个，每两个随机进行线性组合，最后组合出来一个最终要证明的东西，然后只要证明最终这个任务，就可以证明前面那 100 个任务都有效，这样的话可以把原本为 100 的证明 overhead 大幅压缩。

然后，后续的一些 Hyper Nova 之类的工作，可以把 Nova 扩展到除了 R1CS 以外的一些证明系统，一些其他的写电路的格式，可以支持 lookup 或是别的东西，这样才能让一个 VM 更好的被 Nova 这类 ZK 证明系统给证明。但目前来说，Nova 和 GKR 的产品化完善程度不够，目前市面上没有很好的关于 Nova 的高效的库。

并且因为 Nova 是这种折叠的方式，它的设计思路和其他的证明系统不太一样。我觉得它还很不成熟，只是一个比较有潜力的备选方案。但目前来看，从 Production Ready 的角度来说，还是最常见的那几套 ZK 证明系统更早被投入市场，但长期来看说不好说哪个最好。

15.Faust: 最后想聊一下价值观的问题。记得您去年说去了一趟非洲后，觉得区块链最有可能在非洲这种经济落后的地方被大规模采用，可以谈谈这方面的想法么？

YeZhang：我其实一直有一个非常强的信念，就是区块链在经济落后的国家真的有应用空间。其实你现在看到，区块链这个行业里各种 Scam 比较多，让很多人对行业的信心都动摇了，就是为什么要在一个没有实际价值的行业里工作，区块链这个东西到底有没有用。除了炒币或者说赌博行为外，有没有一些更实际的应用场景？

我觉得去一些经济落后的地方，尤其像非洲，你更能感受到区块链的潜力。因为在中国或西方国家生活的人，其货币体系、金融体系非常健全，比如中国人民用微信和支付宝就很开心，人民币也相对稳定，你没有必要通过区块链的方式去做支付。

但在像非洲这样的地方，他们是真的对区块链和链上稳定币有需求，因为他们的货币通胀真的非常严重，举个例子，某些非洲国家的通胀率每半年就能达到 20%，这样的话每次你隔半年买菜，价格就要提升 20%，如果是一年就可能提升更多。这样的话它们的货币是一直在严重贬值的，资产也在贬值，所以很多人都希望拿美元拿稳定币或是拿其他发达国家的稳定的货币。

但非洲人很难去申请发达国家的银行账户，稳定币对于他们来说是一种刚需，就哪怕没有区块链，他们也想拿着美元这类东西。显然，对于非洲人来说，持有美元最好的方式就是拿稳定币，他们每次一发工资，就可以去币安把这个钱赶紧换成 USDT、USDC，需要用钱的时候再把它取出来，这样的话会导致他们有对区块链的真实需求和实际应用。

其实你去了非洲后，会明显感到像币安很早就在非洲布局了，做的非常的扎实，在那里很多非洲人真的对稳定币有依赖，就是大家宁可信任交易所，都不一定信任自己本国的货币体系，因为很多非洲人在本地可能都申请不了贷款。假设你要借 100 块钱，银行会开出各种手续和条件，最后你可能搞不到贷款，但在交易所或者其他的一些链上平台，对此要灵活的多，所以我觉得在非洲，人们对区块链有更多更实际的应用和需求。

当然，我说的这些大多数人并不太了解，因为大多数用 Twitter 的人不关心这个，或者也不会在 Twitter 上看得到这些。像非洲这样比较落后的地区有很多，包括在币安的用户量比较多的一些国家，如土耳其、一些东南亚国家、阿根廷，你会发现这些地区的人用交易所的次数非常多。所以我觉得，在这些地方，币安的案例已经证明了人们对区块链有非常强的需求。

所以我觉得这些地区的市场和社区是真的很有必要去做的，包括我们也有专门在土耳其的团队，我们在土耳其有一个非常大的社区，然后我们要去慢慢的在前面提到的非洲、东南亚、阿根廷等国家去过渡。而且我觉得，在所有的 Layer2 里面，Scroll 最有可能成功的在上述国家扎根，因为我们的团队文化就相当多元，虽然三个创始人是华人，但我们整个 team 大概包含至少二三十个国家的人，虽然我们总共也就七八十人，每个地区基本上都有至少两三个人，所以整体文化很多元。相比之下，你可以想到的其他 Layer2，基本都是西方人为主，像 OP、Base 和 Arbitrum 就是完全西方化的。

综上，我们希望能在非洲这种经济落后、对区块链有实际刚需的地方，给这些地方的人做一套真的有实际应用场景的基础设施，有点像「农村包围城市」的感觉，去慢慢地把 Mass Adoption 给做起来。所以我觉得，我在非洲之行中的感触还是很深的，但目前来说，Scroll 对于一些人而言使用成本还是有些贵，所以我还是挺希望能进一步地把成本降低，比如说十倍或者更多，然后通过一些其他的方式，把用户带到区块链里来。

其实还有一个前面没提到的、可能有些不恰当的例子，就是波场 Tron。大家对它可能有一些不好的印象，但确实很多经济落后的国家的人都在用它，因为 HTX 之前的交易所策略和很多其他的营销策略，慢慢的让波场真的有自己的网络效应。我觉得，如果以太坊生态里面能有一条链，能把这些用户带到以太坊生态里，就是一个非常大的成就，而且也是在给这个行业做一些非常正面的事情，我觉得这是很有意义的。

现在很多以太坊二层在卷 TVL 数据，卷来卷去，你是 6 亿美金，我们可能 7 亿美金，它是 10 亿美金，但我觉得相比于这些东西，更震撼的消息是，泰达突然说我在这个二层或者哪条链上又增发了 10 亿枚 USDT，或者说发行了多少多少钱的稳定币。一条链如果自然增长到了这样一个程度，不需要通过空投预期来捕获用户需求，那个时候才算是比较成功的状态，至少是我比较满意的一个状态，就是能让用户的真实需求大到一定程度，使得越来越多的人真的在日常使用你这条链。

最后我其实想插个题外话，接下来 Scroll 生态会有很多活动，希望大家多关注一下我们的后续进展，多参与一下我们的 defi 生态。