跳出「扩容」与「EVM兼容」迷思，ZK赛道的未来在于高级智能合约

ZK 赛道已经非常内卷了，几乎所有的评估指标都是围绕着「扩容」与「EVM 兼容」展开。这当然没有任何问题，事实上 2020 年 DeFi Summer 以来兴起的公链都是这样卷出来的。

但现在再盯着「扩容」与「EVM 兼容」，总会有一种行业没有发生任何变化的错觉——应用层依然是发币就完事儿了，公链层则是加服务器就完事儿了。

事实上我们应该跳出这种旧叙事下的公链迷思来看 ZK 赛道——它可以支持更高级的智能合约！

本次链茶访邀请了Sin7y 的 CEO XB，为我们介绍他们孵化的可编程性隐私网络Ola，相信会对刚开始的 ZK 赛道有更清晰的了解。

  1.团队是什么时候决定去做 Sin7y？当时是基于哪些判断而做出的决策？

这里需要先介绍一下Sin7y 和OlaVM 的关系。

Sin7y 是一个 Lab，这个Lab 的第一个项目是 OlaVM，你可以将 Sin7y 与 OlaVM 视为 MattersLab 与 ZkSync 的关系。 

我是 2018 年进入区块链领域，当时主要研究基于 ZK 的隐私交易，接着在 2019 年接触了以太坊扩容、Rollups，发现ZK 在区块链领域其实还处在非常早期的阶段，但我相信ZK 技术会发挥很大影响，不仅是隐私场景，还有扩容方案。

我很荣幸得到了我所在公司的支持，在 2021年成立了 Sin7y 研究院，专⻔围绕 ZK 技术去做研究、输出和孵化。

后来决定去做 OlaVM( 前期叫 OlaVM，现在叫 Ola)，是因为我们在接触一个做 DeFi 的 ZK Rollups 时发现它是只能跑特定应用的「数据孤岛」，资产只能用来交易，所以我们开始关注 Layer2 的可编程性，并调研了许多方案。

当时的解决方向都是朝着「约束虚拟机」发展，但虚拟机又有许多内存访问 (RDMA) 、各种控制流指令等复杂的设计，因此一开始在这个领域大家都觉得非常困难。 

后来以太坊自己也看到了 ZK 扩容的必要性，后续则有了以太坊基金会 PSE(Privacy and Scaling Exploration)、也发了一个关于 zkEVM 的设计，接着ZkSync、Polygon等ZK项目也陆续发布了自家的ZK架构。

我们在调研中发现，各个项目在设计上其实还有提升空间，尤其是在扩容、ZK-friendly 方面，因此我们决定孵化OlaVM。

2022 年 8 月份发布了 OlaVM 白皮书，2023年1 月完成了 OlaVM 的 POC。

扩容是一种技术手段，可以执行基于公开账本的任何交易逻辑，也可以执行基于隐私账本的任何交易逻辑，即可编程性隐私，OlaVM 的目标是支持用户根据自己的需求来选择交易类型（公开交易或者隐私交易），当选择隐私交易类型时，用户可以真正地掌控自己的链上数据。

  2.能否介绍下 Sin7y 团队现在的规模以及近期的工作重心？

Sin7y 团队目前有 14 人，10位技术人员来完成ZK基础理论、虚拟机执行、底层电路编写等，还有4 位 BD 和 PR。目前全员都在孵化 Ola，这也是我们唯一的项目。

目前的工作重心是一部分是zkVM 的收尾工作（如非确定性计算的支持、编译器和节点的开发），另一部分是今年年底就要上线的可编程式隐私的测试网的基于隐私的交易功能。

  3.相对其他以太坊系统的 zkEVM 解决方案，Ola 的优势是什么？

Ola 的定位为 ZK-ZKVM，与其他 ZK(E)VM 方案有部分重叠，但我们主打隐私部 署和 ZK-friendly，可以说是以 ZK-friendly 的方式来实现高 TPS，具体有以下方式：

编译器

无论是在Solity或其他编译器，目前都不支持非确定性计算式处理，除非先在以太坊加上预编译合约。但随之带来的问题是每新增一个预编译合约，都得单独增加一个电路，同时约束系统也要可以识别是哪个预编译。

而 Ola 则支持非确定性计算，基本上只需要利用一个第三方 (Prophet)计算方法把平方根算好，用户再用指令去校验结果与逻辑即可完成计算，只用了两个指令就可达到有效性的结果。 

虚拟机

虚拟机如果达到高 TPS，执行轨迹(execution trace)就要小，而 Ola 的虚拟机 OlaVM 是基于寄存器的，可大幅减少程序指令个数，从而减少 trace。 

约束设计

约束系统简洁性很重要，也就是不能有复杂多项式，而 Ola 对于指令的处理采用的是精简指令集设计，简化成只有十几个指令，包括单纯计算指令、控制指令等（具体可以在 GitHub 上看到），因为我们把虚拟机操作在有限域上面，只需要用「加」「乘」就可以完成指令( 遇上减除也换转换为加乘 ) 。

零知识证明

为了加速 ZK 执行过程，我们采用了基于 Godilocks 域的 STARK 算法，让所有执行计算的每一个元素都处在很小的区域，从而达到很快的执行速度。

  4.Sin7y 选择了 STARK 证明机制，那么相对于其它证明机制的优势是什么？

我们一开始选择的其实是 SNARK，后来才演变成 STARK，因为 ZK 技术不断迭代，出现了 Plonky2。 

Plonky2 是基于Plonky的约束系统加上STARK底层承诺的组合，本质上是一个不需要可信设置的零知识算法，也可把它归结为 STARK 的零知识算法。

我们目前以 Plonky2 作为 OlaVM 的 ZK 后端。并且我们最新发布的代码优化改进了 Plonky2，如以快一倍的速度实现哈希算法。

  5.Ola 是如何实现高 TPS？以及目前处在什么阶段？

从编译器到虚拟机、约束设计、零知识证明，我们花了很大精力以ZK-friendly 为原则去优化整体流程，TPS 自然就会变高。

Ola 刚完成了一个 POC，现阶段还需要完成ZK-friendly 的最后一块拼图——非确定性计算。

  6.Cairo 的编译器就将许多开发者拒之门外（至少对已有的产品而言提高了开发成本），Ola 的编译器是否也会有类似问题？

其实现在的 Cairo 1.0 已经封装了一个语法糖( 意指更加简洁流畅、 更好理解的语法 )，不仅允许开发者编写更安全的代码 ( 强类型化、所有权等 )，还引入了一种新的中间表示法 Sierra，确保每个 Cairo 运行都能被证明。

所以 Cairo 现在已经没有将开发者拒之⻔外的问题了。当然，对于其他生态上已有的项目而言，迁移过来确实需要重新写一遍智能合约。

Ola 也是用自定义的语言——Ola-lang 来写智能合约，对熟悉Solidity 和 Rust 语言的开发人员来说非常容易上手。

我们认为Ola 真正的优势在于支持复杂的用户定义类型以及其他功能，所以真正需要的是能实现更高级功能的智能合约。当然我们未来也会支持 Solidity 合约。

  7.你们准备如何繁荣自己的生态？

我们也知道构建生态非常困难，如果背后没有一个很强力的机构来推动，就要花很多的钱去吸引生态繁荣。

所以 Ola目前在 ZK 层面要支持 Solidity 合约，从而吸引外部已有的项目过来拓展出隐私合约。另外，Layer2 的低 Gas打开一个新世界——可以跑AI、机器学习等计算量庞大的程序。

总之我们未来会去支持许多更高级的应用来部署。 

  8.未来在融资上的规划是什么？

我们目前正在进行中，并且近期就会关闭。

计划给团队准备一年多的资金，来支撑今年年底上线 ZK-ZKVM 测试网，下一轮融资则会用来构建生态。 

  9.最后，您认为 Sin7y 未来的机遇与挑战可能是什么？

在这个行业里面只要坚持做下去就可以遇到很多机遇，何况是为区块链带来了质变的 ZK还在刚开始的阶段，但抓住好的机遇本身就是一个比较难的挑战。

我觉得技术方面只要愿意花费人力与时间去持续研究，最终问题都可以慢慢解决，问题就在于能否在最好的时机把技术贡献给行业，希望我们能有不错的结果。