·尽管零知识验证（ZKPs）可以为区块链带来更多的隐私保护和更大的发展空间，但是零知识验证的很多方面都存在误区，或者与一般理解的实现方法存在差异。
· ZKPs的特点有二：“无知识”和“简单”。尽管这个观点是正确的，但是大部分 ZK插件只是简单的使用了 ZK的特性，而且交易数据和帐户信息也不是完全透明的或者是保密的。
· ZK插件也许不是多种 DApps的最佳开发栈。例如， ZKPs的产生对于Web3游戏的快速结束来说是一个瓶颈，这会导致Web3游戏的表现下降，同时， DeFi贷款协议中的基于 Status Difference发行的数据可用性保障方法也会对 DeFi贷款协议造成影响。
区块链产业目前的状况可比作 ZK （Zero Knowledge）时期。ZK在任何地方都是非常显眼的，而寻找一个没有 ZK名字的新一代区块链项目则更加困难。从技术上来说， ZK无疑是一种很有前途的科技，它可以帮助构建一个更大、更安全的区块链环境。然而，因为 ZK公司的科技背景比较复杂，很多投资者，不管是个人投资者，或是机构投资者，往往会因为“觉得” ZK公司很酷，很新颖，很可能会解决区块链的“三大难题”而对 ZK公司进行投资，却并未真正了解 ZK公司的科技对各个项目的好处。
在本 ZK系列文章中，我们将探索 ZK编程的一些不可忽略的特点（优点和不足之处），以及 ZK编程的一些有用的用途。首先，本文分析了基于区块链的 ZK证明的两大特性：“无知识”和“简单性”。然后我们将探讨为什么目前在 Web服务中存在的许多 ZK调度器并不能有效地利用“零知识”的一面。然后，我们会讨论 ZK rollup在什么地方使用是弊大于利的，以避免一些已知的问题，如实现的复杂性。最后，我们会重点介绍一些出色的案例，这些案例充分反映了 ZK的理念，并且通过 ZK的技术得到了显著的收益。
ZK流中的事务生命周期
Rollup是一个可扩充的解决方法，它可以在链路之外完成事务束，然后把L2最近的状态汇总成数据保存到L1中，从而克服L1的处理能力有限的问题。其中， ZK Rollups最大的特色就是它可以在区块链上迅速地进行融资，只需在区块链的底层进行验证就可以了。在我们进一步探讨 ZK流媒体的问题前，我们先来看一看 ZK流媒体的交易周期。
1.每一L2使用者产生及递交其事务至串行器。
2.串行器聚集和分类许多事务，并且接着在该链条下面执行该事务来计算新的调度状态。接着，串行器将此新的控制状态作为“批”递交给链条上的状态智能合同，同时将对应的L2事务资料进行压缩，形成资料区块，以保证资料的可用性。
3.将此批处理传送到验证器，验证器产生对所述批处理的执行的有效性的验证（或者 ZKP）。该验证证书随后与附加的数据（即，先前的状态根）一起被传送给L1的确认器智能合同，所述附加的数据（先前的状态根）帮助确认器标识其所认证的是什么。
4.在确认器契约检验证实是正确的之后，则 rollup的状态将会得到更新，并且L2事务处理在所递交的批处理中将会被认为是完整的。
（注意，此说明是 ZK Rollup流程的一种简化形式，并且每个实施方案可以根据协议而变化。）如果我们对角色进行划分，那么在L2中就会有较多的实体，比如聚合器，执行器，和建议器。数据块的分层结构也可以根据其目的而变化，例如块、块组和批。上述说明假定中央顺序装置具有强制进行事务处理的权力，同时也产生以批的形式存在的一致的块。）
由于 ZKPs （比如ZK-SNARKs和ZK-STARKs）的存在， ZK Rollups与 Optimistic Rollups不一样， ZK Rollups只需要确认一个简单的论证，就能确认成千上万的事务是否正确地进行了操作，而且不用回放每一个事务。那么， ZKP究竟是什么？ ZKP又有哪些特点？
零知识与简单是 ZKP的重要特征。
正如它的名字所暗示的， ZKP本质上是一个证明过程。证明文件可以是完全支持提供程序陈述的任意文件。假设 Bob （提供方）希望使 Alice （确认方）确信他在他的膝上型计算机上具有权限。最容易的例子就是 Bob只是把口令交给 Alice，然后 Alice把口令输入他的笔记本电脑，然后确认 Bob有授权。然而，对于爱丽丝和鲍勃而言，该认证程序并不令人满意。如果 Bob设定了一个很长很复杂的口令，爱丽丝就很难（假定她不会拷贝和粘贴）正确地键入它。实际上，鲍勃也许不想向爱丽丝暴露他的口令来证实他的权利。
如果有一个认证程序，爱丽丝不需要鲍勃提供他的口令就能快速地对电脑进行认证，那会怎么样？例如， Bob可在 Alice的前面通过使用图3 （请注意，这并非 ZKP的理想例子）的指纹来打开膝上型计算机。这就是为什么爱丽丝和鲍勃都能从 ZKP中获益的原因： ZKP的“无知识”特性和“简单”特性。
源： imgflip
零知系统（ZK）
零知识特性是指，提供方产生的证书在证书的有效性之外不会暴露与保密的证据相关的信息，也就是保密的数据，认证方不知道该数据。在区块链的情况下，该特性可被用来保护个别使用者的私密性。如果 ZKPs适用于每次交易，则使用者在不将其交易信息（例如转账、更新账户余额、部署智能合约、履行智能合约等）公开的情况下，能够向外界证实其行为的正当性（也就是使用者有充足的资金来进行交易）。
设计的简洁性
ZK的简洁特性是指 ZK能以较长的语句产生较短的、可迅速确认的证明。换言之， ZK把较长的语句精简为较短的语句。在区块链的情况下，这尤其适用于调度。在 ZKPs的情况下，在L2中的认证器能够通过将简明的证书提供给L1中的认证器而主张事务的适当处理（对于 TB级别的事务的有效性能够由10 KB到100 KB之间的证书表达）。验证器于是能够在很小的时间段（即，10 ms到1 s）中容易地通过验证该简明的证书来证实该执行的有效性，而不是重放全部事务。
ZK Rollup是伟大的，但是它不代表隐私。
ZKRollups良好地使用了上面提到的 ZKP的特征。尽管验证器不能根据供应器所收到的 ZKPs来推导出原来的事务信息，但是验证的简明的证据使得它们能够对供应器的宣告（也就是，对新的L2状况）进行有效的验证。换句话说，宣称 ZK Rollups目前的特性是完全不需要任何知识和简单的，这可能会引起误解。如果关注提供者和验证者的交互，这也许是对的，但是 ZK流媒体中还有其它的组件，比如序列器、提供者以及流媒体节点。那么“无知识”原则是否也保证了这一点呢？
在 ZKRollups中使用 ZKPs来获得完整的私密性，所面临的挑战是，当 ZK的其它功能仍然是公共的，但 ZK的一些功能变成了私密的时候，就会产生一些折衷。考虑一下 ZK Rollups的事务处理过程，在事务处理过程中，用户向序列化程序传递信息的过程中，隐私没有受到影响吗？供应商的情况如何？或者，在L2批处理被递交给 DA级的时候，个人帐户的资料的私密性被保证了吗？现在，没有一种情形是正确的。
在大部分 ZK Rollups中，串行器或服务提供商（或者拥有较高特权的其它集中实体）对包括转移金额、帐户平衡更新、合同部署和合同实施在内的事务详细信息都是透明的。比如，你很容易就能在 ZK Rollup的任何一个区块链浏览器上看到这些详细信息。而且，假设中央序列管理器由于某种原因无法正常工作，而其他的 rollup节点尝试重新获得 rollup的状态。它将对L2数据进行 DA （通常是L1源）级的信息抽取和重构。在此流程中，只要是 DA层级所储存的L2事务可被回放的节点，就可还原出各使用者帐号的状况。
因此，在 ZK Rollups目前的版本中，“零知识”的概念被分解了。尽管这并不能说明问题，但是显然，这与“ZK就是零知识等于绝对保密”这一流行观点是有区别的。目前 ZK Rollups的创新是使用了“简单”特性，而非“零知识”。 ZK Rollups的流程是在数据链中进行事务处理，然后为验证器产生简单的证据，这样，验证器就能迅速、可伸缩地验证事务处理的正确性，不需要再对其进行重复处理。
正因为如此，有些 ZK插件，比如 Starknet，自称“验证插件”，以免引起混乱，而其他插件，比如 Aztec，则保证了真实的 ZK隐私，自称“ZK-ZK插件”。
ZK Rollups的实际应用的深度思考
如前所述，大部分 ZK插件都没有充分利用 ZK的私密性。那我们接下来要去做什么？将 ZK部署到 Rollup的所有地方，以获得完整的事务私密性？其实，也不是那么容易的事情。除了需要重大的科技进步才能让 ZK的技术更加成熟之外， ZK的思想上（比如私下的不合法利用）和实际应用上（比如 ZK是否真的有效）也存在问题。有争议的问题仍然存在。考虑到对完整的交易隐私进行伦理上的探讨不在本文的讨论范围之内，因此我们将重点放在 ZK Rollups在进行区块链项目的过程中所面临的两个实际问题上。
第1：快速确定中 ZKP产生的瓶颈
首先我们来看看 ZK滑块自身的功能。得益于 ZKP的帮助， ZK Rollups的一个显著的优势就是通过“迅速结束”的方式来减少资产取出的延时。更高的 TPS水平和更低的交易成本是附加的优势。在游戏产业中， ZK Rollups的这一功能将会得到最大程度的发挥，在那里，玩家们会在游戏中进行频繁的货币进出，并且每天都会有很多的在线交易发生。
但是 ZK的 Rollups是否真的是这款游戏中最好的一款呢？对于这一点，我们有必要对 ZK赛车中“迅速结束”的理念进行进一步的探讨。试想一下，有一个玩家喜欢使用 ZK Rollup开发的Web3游戏，它是以 ZK Rollup为基础的。用户以游戏货币交换游戏中的项目，并且尝试从该游戏中移除资产。
为了取出财产，必须终止游戏内的事务。这就意味着，为了确保该交易不可撤销，该交易必须包括在 Rollup的新状态中，对应的 ZKP应该在L1中进行申报，并在L1中等待验证的结束。如果这一切都能在刹那间完成，我们就可以做到 ZK Rollups经常夸耀的“即时成交”，让客户可以马上拿回自己的钱。
但是，事实并不是这样的。根据L2beat对各种 ZK Rollups结束时间的统计， ZkSync Era的结束时间为约2个小时， Linea的结束时间为3个小时， Starknet的结束时间平均约为8个小时。这是由于产生 ZKP所需的时间，以及在单个批（即，单个证书）中包括较多事务来降低事务成本所需的额外时间。换而言之，对于 ZK Rollups的快速结束来说，证明的产生和提交速度是一个潜在的瓶颈，而这将导致Web3的玩家体验下降。
另一方面，类似 Ronin这种专门针对游戏而设计的区块链技术（它可以支持诸如 Pixels和 Axie无限之类的Web3游戏），在以分散和安全为代价的情况下，保证了快速结束。Ronin并不是 ZK或者 Rollup上的区块链，而是一个 EVM的区块链，运行的是 PoA+ DPoS (Delivery Equity Authority Authority Protocol）的共识算法。它基于被授权的股票的数目来选择22个验证器，所述验证器随后在 PoA模式下（即，在只有22个验证器的情况下的表决处理）产生并验证块。因此， Ronin平台上的事务可以很快地结束，在数据块中包括的延迟非常少，而且只需要非常少的确认。在 Shillin进行了硬切换之后，结束一笔交易的时间平均为6秒。Ronin在没有 ZKP的情况下实现了全部功能。
当然，罗宁也有不足之处。由中央认证服务器来进行管理，使得它在51%的攻击下更加脆弱。而且，因为不把 Ebitz用作清算平台，所以不能继承 Ebitz的安全特性。跨海链桥的应用也有其安全性问题。但是，站在用户的立场上，他们是否关心呢？ZK Rollups目前还不具备分散的分类功能，它也有单一失败（SPOF）的问题.以太币通过降低交易的回退概率来保障 ZK流，但是一旦中央串行器或验证程序失败， ZK流也会陷入停滞状态。再次请注意，“ZK运行”中的“ZK”仅仅是为了确认运行的正确性。如果有其他的项目可以做到同样的效果，而且速度和价格都比 ZK Rollups要低，那么 ZK Rollups就不会再是Web3玩家和开发人员的首选了。
第2：不同的发行状态是一柄双刃剑
另外， ZK Rollup协议的实际应用也是本文研究的重点。其中，我们在此将注意力集中在 StateDifference Publishing上，它是 ZK编程中保证数据可用性的一种方式（见 Jaehyun Ha 12Apr24, Unlocking Dencun Upgrade: Scaling DA布局的未知真相）。
要了解 Rollups中的数据的可用性，有一个很容易的办法，那就是设想一下，一个业余登山爱好者正在为自己的珠穆朗玛峰之行进行认证和存档。最容易的办法，就是将他们由营地出发，一路走到山巅的过程，全部拍下来。即使是一个庞大的视频档案，每个人都能确认爬行者的攀爬，并且有可能重放影像。这一隐喻类似于初始事务数据发行方式，它保证了数据的可用性。Optimistic Rollups也采用了这个方式，这样当序列化程序的状态不可信时，单个的挑战者就可以回放，并且确认是否正确执行。在 ZKRollups中， Polygon、 zkEVM和 Scroll都使用了该技术，将原来的L2事务处理数据以压缩的形式保存在L1上，这样，如果有必要，任何人都能重放L2事务处理，使 Rollups重新运行。
再回过头来看业余登山爱好者，另外一个证实的方式就是让一个知名的登山运动员和他们一同爬上珠峰来向全世界证明这次登山真的成功了。因为登山的过程都是经过可靠的人确认的，所以攀岩者不必为了做纪录而把每个步骤都写下来。只要在开始的地方和顶峰各拍一次，别人就会以为攀登者已经爬上顶峰了。这一隐喻反应了状态区别的方式，以保证数据的可用性。在 ZKRollups中， ZkSync Era和 StarkNet使用了这样一种方式，即在L1处理L2事务之前和之后，只储存L1处理L2事务之前和之后的状态之差，这样，如果需要的话，任何人都能根据最初的状态来计算所述状态之差，从而还原 Rollups的状态。
这样的状态差分方式，由于能够省略对中介事务的保存，因此能够降低L1的保存费用，因此与初始事务信息的公布方式相比，在费用方面是肯定的。虽然这并不常见，但是有一个潜在的缺点：对于一些 DApps来说，这个办法不能还原出整个L2事务的历史记录。
就拿 DeFi贷款协议 Compound来说吧，假定该协议基于 ZK的 Rollup堆栈，该堆栈基于状态差。这些协定要求有全面的贸易历史，以计算每秒钟的供给和借款比率。如果 ZK Rollup串行器失败了，而其它 Rollup节点尝试重新获得最近的状态，那该怎么办呢？它可以还原状态，但是不会精确还原比率，原因是它只会追踪批处理之间的快照，而不会追踪每一笔中间的交易。
结论：
本文的主要观点是，“ZK”不会出现在今天的大部分 ZK编程中，并且 ZKP和 ZK编程在 DApp的许多方面都不是最好的。ZK技术或许觉得自己很清白，因为 ZK自身没什么毛病，只不过是在开发 DApps时使用了一些先进的技术，导致了 DApps性能的降低。不过， ZK科技并非对业界没有帮助。随着 ZKP和 ZKrollups的技术不断完善，他们一定能为“区块链的三大难题”提供更加完善的解决方案。事实上，已经有很多 ZK项目在使用 ZK技术来保护 ZK的私密性，同时也有很多 DApps在使用 ZKP技术和 ZK卷积技术的时候能够很好的发挥 ZK技术的优点。
tag：OKBOK币 web3钱包下一个区块链延伸领域： ZK Rollups的深度剖析