解析 ZK-Pollup 的不足，探索区块链的扩容方向

Posted 2022-05-21 区块链星际社

2017年，在以太坊上由 CryotoKitty 引发区块链拥堵以来，如何实现区块链的扩容成为了区块链开发者们一个重点关注的内容。在经过了数次优化和改进之后，在当前的区块链领域，普遍采用的是名为“Pollup”的扩容方案。

Pollup 的原理是在区块链主链之外构建一个额外的子链，将交易的执行和处理在子链中进行，而主链负责验证交易的有效性和提供安全性。主链和子链通过一个（或多个相关联）的合约进行连接。子链利用默克尔树将执行和处理的结果，并通过根哈希每隔一段时间将数据上传到主链当中。

主链需要对子链提交的数据进行验证，审查子链数据的真实性和可信度。在目前，这种验证方式主要有两种：一种称之为欺诈性验证；另一种称之为有效性证明。前者验证时需要由用户对数据发起挑战，往往需要花费数天时间，而后者子链在提交数据时，需要额外提供一个 ZK-SNARK 证明（零知识证明），使主链不需要花费额外的验证时间。更重要的是， ZK-SNARK 证明让我们可以不用提交所有的数据都可以证明交易有效性。ZK-SNARK 的优势，让许多区块链扩容方案都更青睐它，即所谓的 ZK-Rollup。

但是，在实际执行的过程中，目前很多解决方案依然采用的是利用欺诈证明的 OR（Optimstic Rollup），ZK-Rollup 的研发进度和实际应用都要比 OR 更慢。这其中最为关键的在于，ZK-Rollup 是一个拥有高复杂性的方案。

在互联网中，生成一个可验证的 ZK-SNARK 并不是一个简单的事，根据相关经验，它比直接验证一个默克尔树花费的时间和算力都要多。时间成本的增加，便会导致数据处理和执行的效率变得更低，而算力成本的增加，在区块链中，便会让用户的资金成本增加。因此，当前很多研发者都在尝试解决这一问题。

另一方面，对于早期的区块链开发者而言，他们并没有意识到区块链的拥堵情况，也同样没有意识到可以采用 ZK-SNARK 作为解决方案。因此，在设计区块链的代码语言、编程环境等时，对于 ZK 的兼容性都并不高。这是限制 ZK-Rollup 发展的一个十分重要的原因。目前主流的区块链扩容解决方案几乎全是 OR，便是因为 OR 能够和编译环境进行兼容。开发者在进行 ZK-SNARK 验证之时，通常都还需要进行额外的配适。

尽管 ZK-Rollup 无论从执行效率、时间成本，还是从安全性等方面，都比 OR 更为优秀。它存在的这两大不足，却让它在当前的应用不如 OR。

不过，ZK-Rollup 面临的都是一些技术上的问题，随着技术的不断完善和进步，这些问题都将会得到解决，届时，ZK-Rollup 或将全面超越 OR 的应用。