我们邀请了四名 ZK 赛道的资深从业者,就 ZK Summer 发展与哪些方向值得关注展开了讨论。
整理:Frank,Foresight News
4 月 10 日,由 Foresight Ventures 与 Foresight News 联合主办的「FORESIGHT 2023 」年度峰会上,在《Long China, Long Crypto》圆桌论坛中,Celer Network 联合创始人梁清凯、Polyhedra Network 联合创始人 James Zhang、Opside 联合创始人兼 CEO 刘声、Ola CEO White Young、StarkWare 开发者关系亚太负责人 Seabook 与主持人 Maggie(Foresight Ventures Tech Lead)就 ZK Summer 发展与趋势展开了讨论。
以下为圆桌实录:
主持人:请大家聊一聊在 ZK 领域中大家比较关注的细分赛道,觉得最可能先爆发的会是哪个赛道?
Seabook:我觉得 ZK 赛道有各式各样的应用,作为 Layer2,我们 StarkWare 最主要的是帮助以太坊进行扩容,在这个赛道上也有很多类似的公司,大家都是为了帮助以太坊扩容。
为什么我们觉得这块非常重要?因为以太坊是现在是非常安全的一条链,以太坊可以给我们安全性和去中心化的保证,但是以太坊的速度很慢。我们在 2016、2017 年就有扩容的想法,StarkWare 是 2018 年成立的,致力于为以太坊扩容,这是我们孜孜不倦追求的方向。ZK 赛道也包含隐私方向,很多人会认为我们是不是能在隐私方面做一些事情?答案是肯定的,但是我们现在注重的是扩容。
White Young:在我看来,对于这个赛道而言,最应该首先爆发的就是扩容,如果扩容没有解决,说再多的 ZK 游戏,扩容速度上不去都是无法支撑其他的应用,所以扩容是必须要急需解决的问题,无论是通过供应链的方式,还是以太坊本身也在往这个方向迭代——但以太坊的迭代速度比较慢,所以出现很多 Layer2 的扩容方案。
我在这里说的扩容更多地是一种技术特点,无论我们的扩容上是跑什么合约还是隐私,可编程性仍然是比较核心的部分。Ola 在底层最重要的模块上也是主打高性能虚拟机的设计,我们在设计上也参考了许多 ZK 的设计,所以我的观点是,扩容仍然是最应该爆发的赛道。
刘声:除了扩容以外,我还想补充一个容易被大家忽略的角色。大家都知道,ZK - Rollup 是为应用、项目方去提供支持的,相当于产品有组件和材料,材料提供商我们也不要忽略了,我想说的是 ZK 尤其需要的是矿工的角色。
ZK 和 OP 中非常大的不同,就是需要有一个强大的算力来支撑零知识证明的生成。在此过程中如何激励矿工加入这个生态做出他的贡献?从以太坊 PoW 转向 PoS 以后,有很多矿机处于闲置状态,从资金规模上来讲,矿机的价值就有 120 亿美元,处于完全闲置的状态,有可能需要一个支点把它撬动起来重新运转,所以我们觉得 ZK 是很好的赛道,ZKP 也需要 FPGA、GPU 等硬件和矿机的支持,比如 Opside 所做的混合共识,也就是 PoS 和 PoW 的混合共识,除了激励验证者去提供数据可用性以外,我们也用 PoW 机制激励矿工进来提供 ZK 的算力,从而为 ZK 提供完整的硬件设施,有了经济模型之后,所有的角色都能够在这个经济模型当中获得利益,包括用户、项目方、矿工,这也就是 Opside 要做的事情。
James Zhang(同事):可交互性是我们看好的方向之一,什么是 ZK 的可交互性呢?就是通过 ZK 进行跨链的交互,不同的链之间可以相互通信。
传统方案也可以做到,但是里面存在一些问题,比如传统跨链的安全性,ZK 可以提供零知识证明的安全性,可以通过 ZKP 的算法来验证跨链桥所需要的内容,替代传统 MPC 需要信任的第三方节点,这也是现在 StarkWare 所做到的,就是 zkBridge。
我们怎么能够做到这点呢?用 ZK 做跨链有很大的挑战,就是得够快,在大规模的应用中这是非常难做到的,我们的创新之一就在于所做的算法是分布式的 ZK 证明,在传统的 ZK 证明中,生成证明还是得用单一的机器来做,而我们的算法可以使用多台机器来共同生成 ZK 证明,这就使得生成证明的速度非常快。
还有刚才提到的矿工挖矿问题,如果一排排机器能够同时生成 ZK 证明,这里面就有新的职业,就是 ZK 矿工,每一个人可以领一部分计算任务,可以共同生成证明,然后这个证明背后的价值所产生的激励可以分发给不同的矿工,这就既解决了跨链的安全性问题,也把市场上闲置的矿机给使用起来。
梁清凯:ZK 技术有什么爆发的赛道,我觉得至少要达到两个标准,一是短期内可以有落地的可能性,技术上是能够做到的;二是落地之后,得有用。
在我现在的观察下,大概有 3 个方向是满足这两个标准,一是扩容;二是互动性;三是 ZKDID,用 ZK 解决链上身份的问题。
其实很多项目发币或者是做活动,存在很大的痛点,就像我们做空投,需要做一些设计,这点在链上现在是没有办法很好的解决,如果引入 ZKDID,就可以在链上无须信任去验证这个用户有没有做过 KYC,或者去验证他有没有在某一个链上去做过某一些操作。
比如空投就是针对一些用户,可以在 ZK 上无须验证许可,就知道他在链上交易过超过 100 万美元,又比如我新发了产品,他在我这里交易可以给他一些折扣,我们可以在链上识别用户和验证用户的身份,如果没有 ZKDID 之前,是没有办法做到这样的功能。
主持人:ZK 目前的生态还不够完善,大家觉得 ZK 距离大规模的应用还有哪些瓶颈和挑战呢?
梁清凯:我个人认为 ZK 最主要的两个问题,一是它还是比较贵,虽然最近有很多技术上的进步,已经把性能提到了两年前无法想象的程度,但是仍然是非常底层的算力,为了能够让你在链上简洁地验证一件事,你在链下所做的工作量可能是很原始的。包括刚才提到的 zkBridge,因为每一个 Block 都要去做一个证明,需要有专门的硬件加速,或者是更好的 ZK 算法,不仅需要把时间降下来,也要把成本降下来。
二是 ZK 的教育,这个领域比较新,而且发展比较快,新人想要入门系统学习 ZK 的知识是有一定的难度,虽然现在也开了一些课,但是对于想进入这个领域推动这个领域发展的新开发者或者是大众而言,ZK 还是门槛比较高的技术。所以,成本和教育的进入门槛是目前的挑战。
James Zhang(同事):刚才提到贵的问题,我也觉得这是一个问题,还有慢,这也是需要我们着手解决的。
针对贵的问题,主要是我们每跑每一个区块都要验一遍,成本很高。那如果我们用几个区块一起去验、几百个块一起去验,比如用户愿意等这几十个区块一起提交,就能降低成本,这个时候就发现一个有意思的问题——zkBridge 和 ZK-Rollup 在某些地方是殊途同归,很多区块可以一起去验,验完之后再把它放到链上,比如你验几十个 Layer2 交易后再把它放到 Layer1 上去,这种 bridge 的过程某种情况下也是近似于 Rollup 的解决方案,这是解决贵的问题。
关于慢的问题,ZK 很多时候的流程非常复杂,你首先得有原始的数据,之后得根据这个去生成证明,还得去验证这个证明,拿到验证结果之后才要基于这个验证结果去做很多事情。这中间有非常漫长的过程,这个过程是我们致力于去加速的——通过并行计算、硬件加速的方式,我们希望能够让 ZK 变得可用。
ZK 的产品是要好用,不能为了 ZK 而 ZK。ZK 可以有很好的算法,但是我们的落地产品一定要是用户易用的,这对用户来说,还有教育的问题,我们希望用户不需要了解 ZK。当然我们希望开发者能够知道 ZK,多来开发,但是对于普通人来说 ZK 的教育是一个大的问题。你不需要懂 ZK,但是用的时候知道好用,我们要先让用户体验到产品、知道好用,再让更多开发者进入这个生态。
刘声:刚才也提到了贵和慢的问题,以及教育的问题。除了从技术上做优化以外,可以从经济模型上对机制进行改进。我们现在提的理念是要让 ZK-Rollup 的安全性继承以太坊,也要让 ZK-Rollup 的去中心化程度也继承以太坊。
以太坊现在是全球最大规模的去中心化网络,有超过 50 多万个节点,我们如何让 Rollup 的去中心化程度也达到这个级别,而不是由一个单节点去完成中心化的打包?其实很好的做法是让以太坊的出块者同时出 Rollup 的区块,同时打包 Layer2 链下的区块,这也是我们提的想法,在 Opside 里面,我们把它叫原生的 Rollup。
那如何在激励模型上激励更多的算力进来,还是要有一个激励的机制,比如在我们提出的 Opside 架构当中,将区块的奖励分成两部分,比如 50% 的奖励给 PoS,50% 的奖励给 PoW,这可以动态调整,根据算力的多与少动态调整。
这样的话两边都能受益,比如电脑是有两个核心组件,一个是硬盘,一个是 CPU,PoS 提供的数据可用性就相当于是硬盘,PoW 提供的算力就相当于是 CPU,所以我们需要在当中找到一个平衡,从而让每一个角色都能从中受益,然后让 ZK 的网络得到更大的应用。
White Young:我算是一个比较资深的 ZK 研究者,我 2018 年开始就用 ZK。这几年我见证了 ZK 本身的发展速度和迭代速度非常快,所有的技术都在迭代,快到我想用它的时候它可能又有了新的技术方案出现。所以我觉得对于 ZK 来讲,它目前的瓶颈可能很快会得到解决。
但是如果想被很快的解决,我就很同意前面几位老师说的意见,就是关于 ZK 的科普,或者是教育的问题。因为我本身就是学了将近一年的零知识证明,从理论上学零知识证明到底是什么,但是我学了一年,我知道它是怎么运行,它的算法是怎么跑的时候,我仍然不会去写,我不知道怎么去写它的电路,对我来说非常的抽象。
所以无论是概念上,还是功能上,它都有一定的入门门槛。当然现在比较好的是,大家都是基于 ZK 去做的项目,大家都在关注并且已经在社区内有具体的措施,去做一些 ZK 的科普活动,这点就很好。
Seabook:我最后补充一下,站在我们的角度,我们认为现在主要是三大块,一是人才,据传全世界真正懂 ZK 的人大概也就 1000 多人,这个数量级是非常少的,真正懂 ZK 的人才非常少,普及程度也比较慢,ZK 最重要的是数学,数学是支撑 ZK 的逻辑。
二是现在的速度比较慢,当然现在有非常聪明的人在解决这个问题,底层我们也发布了新的语言,整个生态和架构也都正在调整当中。
三是生态,站在我们的角度,我们构建了全新的语言 Cairo,最重要的环节之一就是需要开发者的支持。我是技术出身,2017 年 就开始写 Solidity,2017 年大多数都是 ERC20,Bug 也很多。但是随着这五六年的发展 Solidity 成为了非常成熟的语言,整个以太坊的基金会教育是非常好的,当然其中也有很多非常聪明的年轻人愿意奉献他们的时间。
Cairo 也是如此,作为 StarkWare 生态上的开发语言,我们觉得它是能够更高效地编译,能够大大降低将来编译 ZK 电路的成本。现在大家去写电路,就像写天书一样,比如有些团队写的 ZK 电路都是几万行。
在未来的几年当中,我们希望越来越多的人可以拥抱 Cairo,它的风格非常像 RUST。这是一个机遇,也是一个挑战,机遇就是像五年前的 Solidity,五年后 Cairo 可能成为 ZK 里面的 TOP,挑战是因为刚刚开始,有很多的坑,这也是我的职责所在,帮助大家把所有的坑全部填平,帮助大家更好地发展。
主持人:接下来有分别的问题问各位嘉宾。首先是梁清凯博士,上个月 Celer Network 发布了 ZK 全链数据计算和验证平台 Brevis,可以帮助 DApp 访问各个区块链的任意数据,现在有了这个功能之后,您觉得它会催生什么样的有创新的 DApp 呢?
梁清凯:我解释一下为什么我们要解决这个问题?现在的区块链,尤其是区块链上面开发的智能合约,它其实就是瞎子,它现在只能看到当前链的当前状态,并且这些状态可能要通过其他智能合约已经定义好的规则来做,它完全看不到区块链历史上的状态和数据。
同时,区块链上面的智能合约也看不到其它区块链上发生的一些事情,更别说链上的智能合约也看不到 Web2 里面发生的事情。所以 Brevis 要解决的是通过 ZK 技术让区块链上的智能合约开天眼,能够去访问区块链上历史数据,能够去访问其他链上的全链数据,甚至访问 Web2 上的数据,并且不需要信赖任何的第三方。
Brevis 能够催生的新 DApp 有几类:
一是刚才提到的 zkBridge,上个月我们发布的时候也上线了一个 zkBridge 的建模。
二是 ZKDID,可以衍生各种各样很有意思的东西,比如在链上去验证用户在某个 DApp 的交易量,再比如它之前某在个借贷协议被清算的历史,这样你可以在链上借助这些数据设计很多新的应用,比如说设计一些忠诚度计划,甚至是设置一些链上声誉系统去做信用贷,这些都是之前在链上没有办法或者是需要信任第三方才能做到的事。
三是可以用来去做比较创新型的用户获取,比如你现在发了一个新的 DApp,你需要有用户,传统的 Web2 做法可能是到各个有流量的渠道投放,不过你买来的用户,到下载安装这一步了就结束——用户一下载,你可能就付给合作者钱。
但是在 Web3,比如接入了 Brevis,你可以去记录用户使用 DAPP 之后的情况,比如说有些是忠实的用户,有些可能是薅毛的用户,我们可以记录这些用户的链上行为,从而无限信任地给合作者付费,这样可以做到更加高效。
主持人:Polyhedra 上周发布了 zkBridge 主网 Alpha 版本,在 Layer1 交易确认的过程中 ZKP 就生成完了,它是同步进行。我们也听说 Layer1 是有局限性的,所以用 zkBridge 去桥接独立的链是更好的选择,您怎么看?
James Zhang(同事):对于我们来说,现在做 zkBridge 所依托的和 EVM 也没有太大的关系,对于发送链来说,只要我们能够去验证共识就能够把你加入发送链,对于接受链来说,只要你的接受链能跑智能合约也就可以。
其实 Polyhedra zkBridge 还支持了一个未来的可能性,我们打破了 EVM 和非 EVM 之间的隔阂,也打破了 Layer1 和 Layer2 之间的隔阂,因为对于我们来说,跨链不需要基于 EVM 或者是否取决于你是 Layer1 还是 Layer2,只要你有可以被验证的共识,只要你可以去支持智能合约,我们就可以把链连接在一起。
对于 Polyhedra Network 来说,我们所畅想的未来是无论你是不是 EVM,是 Layer1 还是 Layer2,我们所提供的方向是可互操作性,我们希望所有链都是这样连接在一起的,链上的无论是资产、数据、还是代码,我们都可以帮助你非常轻松、快速低成本地从一条链转到另外一条链。
而现在 zkBridge 主网 Alpha 版本已经初步达成了这一点,可以把资产从以太坊边币跨到 Optimism 这样的 Layer2 上,也可以跨到 Layer1 上,而且可以跨 NFT,也可以只发一条消息,这个消息可以是一个打招呼的邮件,甚至也可以发一段你的代码或者是数据,对于我们来说,未来会加入更多的链,涵盖 EVM 的或者非 EVM 的生态,都可以被兼容进来,而这一切都是可以通过 zkBridge 轻松实现。
所以对于这个问题的看法,我们认为未来的 Web3 的世界一定可互连接、可互操作地,这样的话没有隔阂,开发者、用户可以在所有的链上自由地进行应用的开发和体验。
主持人:互操作性是非常重要的,刘声先生,我知道 Opside 是在做 ZK-Rollup as a Service,请问您觉得哪一类的项目适合独立发一个 Rollup,或者是做一个 App Chain ?
刘声:Opside 做的 ZK-Rollup as a Service 主要针对对象是高频的应用,比如游戏、社交网络、金融衍生品等。但是在这个过程中,我们也要去观察到每一个项目他们有不同的需求,比如有的项目就要求用户不承担任何的成本,所有的成本都是由一个经济模型去做,比如让项目方或者是让其他的角色去出这个成本。
在我们的设计当中,这有点像阿里云或者是 AWS。比如我是 Web2 的开发者,我要租赁一个云服务器,我会去阿里云上,我选择一年的套餐,然后只需要点击付款,这个云服务器就为我生成好了。但是对于游戏、项目方来讲,他们不懂 ZK,也不懂链、节点,这些概念对他们来说都太抽象,都是基础设施。
所以,我们要做的是区块链领域里的阿里云,让用户只需要让他在我们的页面上选择他需要的配置,比如选择哪一种 ZKEVM,我们提供了 Starknet 等不同的解决方案,同时他也可以配置一些白名单的地址,只有这些地址才能够部署合约,这样的话,就屏蔽掉了其他的应用和他竞争,同时整个执行环境只有这一个应用的话,就可以实现零 Gas 费。
当我们把配置交给项目方自己决定的时候,他接触到的只是一些配置项,整个的 ZK-Rollup 或者是 ZKVEM 就能够自己去启动,以及其他的桥、浏览器都能够为它自动的生成。对于一个应用开发者来讲,他接触到的只不过是另外一个 EVM 兼容的链而已,这也是我们要做的,也是我们的目标群体。
因为 Opside 刚完成 400 万美元的种子轮融资,也会马上在 5 月份上线新的测试网,上面也会有一个演示的视频,可以展示一个应用开发者如何在一分钟之内就能够发他自己的 ZKVEM。
主持人:昨天 Ola 发布了第二版白皮书, 对于 ZK Rollup 您如何看待「零知识证明友好」以及「EVM 等价」这两点之间的权衡的呢?
White Young:这是一个非常好的问题。当我们在正式立项之前,就一直考虑这个问题,也即我们想做一个扩容项目的时候,到底应该从哪一点出发。在我看来,现在所有做 ZKEVM 的项目,有两个技术路线。
第一个方向就是把这个平台做出来之后,这个项目怎么迁移,很多项目就是在二层实现 EVM,这种情况下项目方可以直接部署过来。在这种情况下,你再去实现 ZK 扩容,因为它本身会存在性能的差别,所以这个时候就考虑怎么把 ZK 加速,去实现硬件或者是并行优化,这些都是可以的;另外一个方向就是去设计一个完成 ZK 友好的虚拟机,在这个层面上再考虑我们怎么样更好地发展生态,因为如果你能兼容以太坊的生态,就能够更好的发展生态。
这两种不同的技术路线是两种不同的出发点,我觉得都是 OK 的,只是我们目前选择的路线,认为扩容本身更需要,所以 Ola 也只有设计了 ZK 友好的虚拟机 OlaEVM,在上面支持隐私和扩容。
主持人:我们想替观众朋友们问一下 Seabook,你在做 Starkwar 的开发者关系工作过程中,您觉得哪些是最关键的呢?
Seabook:我们现在有一批早期的开发者粉丝,已经扎根了 Cairo,但就像前面所说的有机遇也有挑战,挑战就是我们一直在变,从之前的 Cairo 到现在的 Cairo 1.0,包括现在主网的速度都是比较慢,这些都是我们急需解决的问题,导致早期的开发者要从头重新学,这是我们区块链绕不开的坎,必须每天更新,错过一天的资讯就感觉差了很多,我们每天都要不断的在区块链领域学习。
所以在 StarkWare 开发者生态上,我们要维护好比较忠实的开发者群体,他们在我们的生态上做出了很大的贡献,上面还有一位朋友搭了一个 ZKVEM 开源项目。在座的各位,如果大家对 Cairo 有兴趣,对 StarkWare 有兴趣,可以积极参与到我们的生态。
总结起来就是两点,一是维系好在 StarkWare 生态上已经有的开发者;二是需要在座各位一起努力,帮助我们招揽更多新的 StarkWare 开发者,一起为生态做出贡献。
【免责声明】市场有风险,投资需谨慎。本文不构成投资建议,用户应考虑本文中的任何意见、观点或结论是否符合其特定状况。据此投资,责任自负。