作者：Yooma；来源：MetaCat

遇到的问题

PopCraft 是一款全链上的消除游戏，每局游戏时长 4 分钟，玩家在规定时间内消除棋盘上所有元素，会获得代币奖励。

由于全链上的特性，玩家在游戏过程中的每次操作都需要跟区块链交互。以太坊二层的区块时间通常为 2 秒，导致玩家在游戏中每次操作需要至少等待 2 秒才能完成，这远远超过同类 Web2 游戏中的等待时间，从而使 PopCraft 游戏体验欠佳。

PopCraft 游戏主界面

设想的方案

我们设想在 PopCraft中利用零知识证明技术（以下简称 ZKP），减少玩家在游戏过程中与区块链的交互次数。

预期的方式是：游戏过程不上链，但有机制可以确保无作弊风险。玩家在游戏中每一步操作都会生成 ZKP，后一步操作的 ZKP基于前一步的 ZKP 来生成，从而形成一种类似区块链结构的自包含 ZKP，游戏结束时将最后一步操作的 ZKP 发送到链上，交由智能合约验证其结果。

方案调研与推导

1. 游戏过程与结果的防作弊：仅对游戏结果生成 ZKP 是不够的，因为游戏的过程同样存在作弊可能。因此，既要对游戏结果生成 ZKP，也要对游戏过程进行验证。

2. 逐步生成 ZKP 的技术挑战：为了防作弊，需要对玩家在游戏中的每一个操作都生成 ZKP，在游戏结束时将最后一个 ZKP 上链进行验证。这个过程中，每一步的 ZKP 都会依赖于前一步的 ZKP，直到游戏结束为止。

但难点是：

1> 新的 ZKP 生成需要依赖前一步的 ZKP，这使得验证过程复杂且不确定能否可实现。此外， ZKP 验证通过智能合约（链上）来做，后一步生成 ZKP 时该如何去验证前一步的 ZKP 是正确的。

2> 在通过智能合约验证每一步的 ZKP 是否正确时，如何确保每个 ZKP 与前一个 ZKP 的连贯性，该问题不确定是否有方案可以解决。

3. 公开游戏数据的问题：PopCraft 的游戏数据是公开的，因此通过 ZKP 做信息隐藏没必要。如果上述验证步骤均可实现的话，下一步需要考虑在合约端保存游戏数据。然而问题在于 ZKP 的性质无法解出具体的游戏数据，此时也不可直接相信客户端传给智能合约的游戏结果数据，这意味着智能合约无法直接存储这些数据。

4.PopCraft 中消耗游戏道具（消耗Token）的问题：当游戏过程涉及到通过游戏道具完成孤立元素的消除时，本质上对应的是 Token 消耗，需要将用户钱包中对应的Token 转移，如何处理这一步 ZKP 生成和验证也是一个问题。

1> 一个可能的解决方案是：这一步继续按照之前的流程生成 ZKP，验证消耗的 Token 数量并最终发送给智能合约。然而，由于智能合约无法通过ZKP 得到具体游戏数据，因此无法判断应该转移的 Token 数量。

此外，假设玩家拥有 3 个 Token A，却尝试在游戏中消耗 4 个 Token A，这种错误会在游戏结束时才被发现，而不是在用户操作实时被发现。

2> 另一个可能的解法是：在使用 Token 完成孤立元素的消除时，直接与智能合约交互完成消除，然后更新玩家的 Token 余额。生成的 ZKP 只负责保存此时游戏操作和状态的证明。

那么此时在转移 Token 成功之后，还需要像前面操作一样继续生成 ZKP，如果不生成，那么在转移 Token 操作的上一步生成的 ZKP 与下一次生成的 ZKP 中间，多了一次与智能合约交互的步骤，那么 ZKP 中的游戏状态就会冲突，这样游戏结束时生成的 ZKP 是否有效也是一个悬而未决的问题。

5. ZKP 的数据隐藏问题：对于 PopCraft 这种不需要隐藏游戏数据的场景来说，通过 ZKP 做数据隐藏是多余的，且增加了游戏数据获取的难度以及工程实现方案的不确定性。PopCraft 只需确保游戏过程和结果无作弊风险即可，并不需要隐藏游戏过程数据。

结论

在 PopCraft 这样的游戏中，游戏数据不需要隐藏，因此通过 ZKP 做信息隐藏没有必要。为了通过缩短响应时间来提升游戏体验，可以考虑游戏过程不上链，仅将最终结果上链。关键在于找到一种方法，可以确保从玩游戏的第一步到最后一步都没有作弊可能，最后将正确的结果上链验证即可。

如果通过 ZKP 进行信息隐藏，反倒是增加了工程实现难度。其次是如何确保游戏过程无作弊风险，使用 ZKP 能确保单个游戏操作无作弊风险，但为了减少跟区块链的交互次数，又不能生成一次 ZKP 就提交一次。所以从游戏开始的第一步操作到游戏结束整个过程，又该如何保证无作弊风险，目前看来 ZKP 无法解决该问题。

从我们的调研来看，游戏领域 ZKP 适合做两类事情：

1. 非完全信息博弈类游戏的信息隐藏，比如：黑暗森林、德州扑克、狼人杀、炉石传说等。

2. 游戏过程为单步的游戏结果证明，比如：彩票、猜数字、石头剪刀布、骰子游戏等。

由于我们在零知识证明技术上的储备有限，本文内容可能存在事实性错误或不合理的工程设想，恳请具备丰富经验的零知识证明领域专家批评指正。