ZK协处理器如何打破智能合约数据壁垒

作者: Mike@Foresight Ventures

一、概念介绍

关于协处理器这个概念，一个很浅显易懂的例子就是电脑和显卡的关系，CPU可以完成大部分任务，但是一旦遇到特定任务，就需要显卡的帮助，因为CPU算力不够，比如说机器学习，图形渲染，或者是大型游戏的运行，我们玩大型游戏的时候如果不想掉帧或者卡顿，那肯定就需要一块性能很好的显卡。那在这个场景中，CPU就是处理器，显卡就是协处理器。映射到区块链上，智能合约就是CPU，ZK协处理器就是GPU。

关键点就是把特定任务交给特定的协处理器做，就像一个工厂里，老板知道每个环节的步骤，也可以自己做，也可以教员工整个生产过程，但是这样效率就很低，只能一个一个生产，一个生产完了才能生产下一个，于是他雇了很多特定的员工，他们各司其职，在自己的车间做着生产链条上自己擅长的工作，链条的环节之间可以互相进行通信协同但互不干涉对方的工作，只做自己最擅长的事，手速快体力好的就打螺丝，懂操作机器的就去操作机器，懂财会的就去计算生产量和成本，异步协同工作从而最大化工作效率。

在工业革命的时候，资本家们就已经发现这种模式能给自己的工厂带来最大的产能，但可能因为技术或者别的原因，生产环节中的一步遇到壁垒的时候，可能要外包别的专门的生产商去做，比如说一个生产手机的公司，芯片可能由别的专门的芯片公司生产，手机公司就是中央处理器，芯片公司就是协处理器。协处理器能够轻松异步处理中央处理器自身难以处理的壁垒较大和繁琐的特定任务。

ZK协处理器广义上比较宽泛，有的项目叫自己协处理器，有的叫ZKVM，但是都是同一个思路：允许智能合约开发者在现有的数据上无状态地证明链下计算。简单来说就是把一些链上计算的工作丢到链下，降本增效，同时用ZK保证计算的可靠性，并保护特定数据的隐私。在数据驱动的区块链世界里，这显得尤为重要。

二、为什么我们需要ZK协处理器

智能合约开发者面临的最大瓶颈之一仍然是与链上计算相关的高昂成本。由于每次操作都要计量Gas，因此复杂应用逻辑的成本很快就会变得高到没法执行，因为区块链的DA层中的存档节点虽然确实能够存储历史数据，这也是为什么像Dune Analytics，Nansen，0xscope，Etherscan这些链外分析应用能有那么多来自区块链上的数据，并且可以追溯到很久以前，但对于智能合约来说要访问所有的这些数据并不简单，它只能够轻松访问虚拟机状态中储存的数据，最新的区块数据，以及其他公开的智能合约的数据。对于更多的数据，智能合约可能要耗费很大的功夫去访问：

智能合约在以太坊虚拟机（EVM）中能够访问最近的256个区块的区块头哈希值。这些区块头包含了区块链中直到当前区块为止的所有活动信息，并通过默克尔树和Keccak哈希算法被压缩成了32字节的哈希值。

虽然这些数据被哈希打包过了，但其实它们是可以解压的——只是这并不容易实现。例如，如果你想利用最近的区块头来无需信任地访问上一个区块中的特定数据，这涉及一系列复杂的步骤。首先，你需要从存档节点获取链外数据，然后构建一个默克尔树和区块的有效性证明，以验证该数据在区块链上的真实性。随后，EVM会处理这些有效性证明，进行验证和解释，这种操作不仅繁琐而且时间长，Gas还特别贵。

这个挑战的根本原因在于，区块链虚拟机（如EVM）本身并不适合处理大量数据和密集型计算任务，比如上述的解压缩工作。EVM的设计重点是在保证安全和去中心化的同时，执行智能合约代码，而非处理大规模数据或进行复杂的计算任务。因此，当涉及到需要大量计算资源的任务时，通常需要寻找其他解决方案，比如利用链下计算或其他扩展技术，这时候，ZK协处理器应运而生。

ZK rollups 其实就是最早的ZK协处理器，以更大的规模和数量支持在 L1 上使用的同类型计算。这个处理器是协议层面上的，现在我们说的ZK协处理器是dapp层面上的。ZK 协处理器通过允许智能合约使用 ZK 证明无信任地委托历史性链上数据访问和计算来增强智能合约的可拓展性。开发者可以将昂贵的操作转移到 ZK 协处理器上，并简单地使用链上的结果，而不是在 EVM 中执行所有操作。通过将数据访问和计算与区块链共识解耦，这为智能合约提供了一种新的扩展方式。