TronLink波宝钱包|IOSG：ZK 协处理器的入门课， 它究竟能做什么？

对于资料的查询与计算，链上计算所花费的成本可能是链下计算的好几倍，这也导致许多 web2 功能无法在 web3 上完全释放，而 ZK 协处理器或许能解决这一难题。 （前情提要：从Type1到Type4，各类型ZK-EVM的差异在哪？ ） （背景补充：DeFi也行！零知识+AI机器学习「ZKML」的优势和挑战 ）

ZK 协处理器是区块链领域一项激动人心的创新。它由 Brevis、Axiom、Lagrange 和 Herodotus 等专案率先推出，有望彻底革新我们在区块链上开发应用的方式。有了 ZK 协处理器，开发人员可以建立资料驱动的 dApps，可以利用 omnichain 资料的历史记录来执行复杂的计算，而不需要依赖任何额外的信任假设。更为重要的是，它引领了一种新的开发模式：非同步应用架构，这为 Web 3.0 软体框架带来了前所未有的效率和可扩容性。

在本系列文章中，我们将揭示 ZK 协处理器的神祕面纱。无论您是对其理念、实际应用、基础机制、面临的挑战，还是市场策略感兴趣，或是想要比较不同的专案，我们希望这些文章都能给您带来新的启发。

DEX 上缺少 VIP 交易员计划的案例

要理解 ZK 协处理器的基本思想，我们需要从现实世界中的激励性例项开始。

中心化交易所（CEX）和去中心化交易所（DEX）之间的一个明显区别是存在基于交易量的收费标準，也就是通常所说的「VIP 交易员忠诚度计划」。这些计划是留住交易者、提高流动性并最终增加交易所收入的有力工具。

有趣的是，虽然每个 CEX 都拥有至少一个这样的专案，但 DEX 却完全没有。为什么呢？

这是因为在 DEX 中实现这一功能要比在 CEX 中更具挑战性，成本也更高。

在 CEX 中，实施忠诚度专案需要：

• 在中心化资料库中记录所有使用者的交易历史 —— 这是一项 便于降低未来查询成本 的任务。
• 每月在高效能的中心化资料库中执行一次 直接查询 ，根据历史资料确定每个使用者的交易量和费用等级。

然而，DEX 在尝试遵循相同步骤时面临着重大挑战：

• 由于区块链的 储存成本过高 ，在智慧合约中直接储存每个使用者的交易历史并不可行。实施这种逻辑意味着使用者每笔交易的手续费 要高出 4 倍 。
• 即使我们进行了交易记录的资料储存，但对这些资料进行统计查询和计算的成本更高。例如，计算单个使用者 10K 笔交易的交易量资料将花费 156M Gas（对！我们计算过）。

你可能会说「等等，你到底在说什么？在区块链上，每个使用者的每笔交易都已自动储存（因为它是区块链！）。」在区块链上土生土长的智慧合约，应该可以随时访问所有这些资料，对吧？

很遗憾，不对！

区块链储存的资料 和 区块链虚拟机器内智慧合约可访问的资料 完全是两码事。

对于区块链的完整 / 存档节点来说，它们储存了区块链历史上的大量资料。通过这些节点，您可以轻鬆访问：

• 历史上任何给定时间内整个区块链的状态（例如，谁是 Cryptopunk 的第一个所有者）。
• 历史上任何给定时间内的交易和因交易而产生的事件（例如，Charlie 将 $1,000 兑换成 0.5 ETH）。

事实上，流行的 链外资料索引或分析工具 （如 Nansen 和 Dune Analytics）可利用这一广泛的资料集进行深入分析。

然而，对于嵌入区块链虚拟机器的智慧合约来说， 资料访问的限制要大得多 。它们不能使用链外索引解决方案生成的资料，因为这会给这些外部且通常是中心化的索引解决方案带来额外的信任问题。

事实上，智慧合约只能轻鬆且无需信任地访问以下资料:

• 虚拟机器状态中储存的资料（不包括交易或事件资料）。
• 最新区块中的资料（历史资料访问是受限的）。
• 通过「检视」功能公开的其他智慧合约的资料（不包括私有或内部合约资料）。

上述说法的一个关键细微差别在于「轻鬆」一词。

智慧合约并非完全不知道区块链上的全部资料。在 EVM 中，智慧合约可以访问最新 256 个区块的区块头hash值。这些区块头囊括了区块链上截至当前区块的所有活动，并通过默克尔树和 Keccak hash值浓缩成 32 位元组的hash值。

压缩过的东西可以解压缩… 只是并不容易