3.2 AW Engine

AW Engine 是针对游戏的实时性和连贯性，而设计的区块链纵向的扩容方案。

3.2.1 AW 运行方式

近年来，游戏行业正在迅速变化，基于区块链的 Web3 游戏有望带来新的商业模式，但传统游戏完全拥抱web3仍然面临很多挑战：

1. 吞吐量：很多的游戏需要的快速操作，并且连贯无干扰，这与区块链形成了强烈的冲突。一些快节奏的射击游戏，其动作以毫秒为单位，然后目前最快的区块链也需要2s一个区块，这就意味着游戏中的每一步，都需要至少等待 2s。因此，在链上构建快节奏的游戏是不可行的。

2. 可扩展性：游戏可以支持多少玩家，而不会使区块链拥堵并导致 Gas 价格飞涨。如果玩家的每一个动作都要上链，那么区块链将非常拥堵。

为了解决这个问题，我们开发了一套 AW Engine，其通过零知识证明将游戏中的操作进行打包，一次性上传到链上并进行验证，这意味着玩家可以在与区块链交互之前进行更多的动作并玩更长的时间，从而减少主区块链上的交易成本和拥塞。例如，在回合制游戏中，玩家可以进行多次动作，允许多次动作生成证明。正式来说，我们有：

验证此类迭代计算的最直接方法是将 n 个动作放入单独的电路中，然后使用 SNARK 来完成证明，从而显着增加可放置在单个事务中的动作数量。这为更多类型的游戏开发为完全链上游戏提供了可能性。 这里，我们以单人游戏和多人游戏为例。

单人游戏：以2048、淘汰赛等游戏为例，如果将玩家的详细动作和淘汰逻辑全部上传到链上，将会消耗大量的gas和链的资源。通过使用 ZKP 压缩这些流程，我们只将必要的信息和证明传输到链上。这种方式可以将gas成本和交易数量降低100倍以上。

我们会提供这类回合压缩的电路和必要的智能合约，让开发者能够在不撰写电路的情形下，只需完成必要的游戏经济逻辑和前端包装，就可以打造游戏。

多人游戏：以下是一个 Trading Card Game (TCG) 游戏全部都用到的范例。

要参加 TCG（集换式卡牌游戏），玩家需要使用matchmaking来寻找对手。游戏开始后，双方的牌都使用ZK Shuffle进行洗牌。然后，每一轮都会利用 ZK Shuffle 的翻牌功能。此外，我们使用Data Rollup将每轮的详细信息压缩到一个交易内。这种方法实现了一个完全链上的TCG，交互和交易费用都很低。

3.2.2 Slow-paced ZK 游戏

对于像上面讨论的2048游戏这样的Slow-paced游戏，我们提供了两种基于零知识证明的方案。

2. SNARK：众所周知为 ZKP 设计约束系统是一项艰巨的任务，只能由熟练的开发人员完成，并且很难确保约束系统没有错误，这是限制零知识证明的开发和使用的因素之一，但是我们提供游戏电路开发中使用的各种小工具，包括基本算术电路、哈希，ecc, zkshuffle, zkmatchmaking等，大大降低了开发全链游戏的入门门槛。

3. ZKVM： 我们提供通用的zkvm去编写游戏逻辑，例如RISC Zero，RISC Zero是一种专为RISC-V架构设计的通用零知识证明系统，允许开发人员使用 Rust 和 C++ 等成熟语言构建 ZK 应用程序。这意味着RISC Zero 能够支持使用现有的 Web2 编程语言编写的应用程序，无需构建plonk相关电路，也无需使用DSL语言进行编写。

目前，Bonsai 允许用户为其 zkVM 应用程序远程生成证明，而无需使用自己的硬件来生成证明。然而，使用 Bonsai 并不能保护用户隐私。同样，对于 zkSNARK，我们还需要一个远程证明者，将客户端证明计算委托给一组不可信的服务器，以更快地生成证明并保护用户隐私。现有的解决方案结合 MPC 协议来构建具有多服务器协作的 zkSNARK 证明。根据【28】，椭圆曲线和域上的点可以直接加密共享，并且MPC技术可以应用于这些共享。当前使用的主要方法是打包加密共享。

因此，使用打包加密共享及其属性很容易为相应的 zkSNARK 证明者实现高效的 MPC 协议。

3.2.3 Z4 引擎

AW 引擎, 既可以用来解决单人的链下游戏，也可以推进到支持快节奏的多人在线实时游戏。为了管理多人在线环境的复杂性，我们设计了一套 Z4 引擎。简单概括就是游戏会在第三方的节点上进行，游戏结束后，第三方节点提供游戏过程的 zk 证明，用于验证游戏的结果。第三方节点需要 staking，才可以在公开的 room market 上进行 accept game，类似于赏金猎人。

Z4 引擎配备了几个模块:链交互模块、链上事件监听模块、HTTP和P2P网络启动模块、具有零知识证明模块的证明器、游戏逻辑接口。 基于对模块的整合，开发者只需要定义游戏逻辑，就可以运行完整的专属自己游戏的 z4 节点。

Z4 引擎架构图

在Z4引擎工作流中, 玩家在链上进行游戏房间的创建，一旦其他玩家看到这个房间，他们可以选择加入，当房间满员或者房主主动点击开始后，房间会处于 ready 状态，房间也会出现在赏金猎人的 acceptable 列表中，促使他们抢夺该房间。，第一个抢夺成功的 z4 节点，成为这局游戏的 provider。该房间内的玩家通过监听链上动态，观测到房间的 provider，并根据合约中 provider 的地址进行本地网络连接，这种连接包括 HTTP 与 P2P 的双重连接，以确保网络的稳定性和兼容性。。当网络中不存在任何 Z4 节点的时候，任意玩家都可以充当 provider，而且无需提供对外的可访问的HTTP地址，可以通过P2P来实现快速启动和点对点连接。游戏结束后，provider 会将游戏的过程进行 zk 证明，将游戏结果和 zkp 一起提交上链，验证通过后，房间状态更新为 over。

游戏的 zk 证明电路同样可以采取PLONK进行定制，或者使用ZKVM或DSL进行编写，形成自己游戏特定的 z4 节点。鉴于 zk 的学习曲线和电路的编写难度，我们提供了一套将 Z4 和 Risc Zero 深度整合的通用游戏运行平台。这个通用的 Z4-RISC0 节点运行 RISC-VM 沙盒环境，游戏开发者只需定义游戏逻辑并将其作为 Z4-RISC0 节点提交到链上。该通用节点可以运行任意基于RISC-VM框架下开发的游戏，在游戏结束后，自动进行游戏的 zk 证明。并且通过整合 bonsai proof market，达到快速证明的目标，提高了链上游戏验证的效率和可靠性。

涉及大规模的操作的游戏，会导致证明时间过长，为了进一步提高游戏的证明效率，我们同时提供了一套基于Thresh-old ECDSA的证明解决方案。玩家在游戏结束后，对游戏结果进行签名，一旦达到 n-m 签名的阈值，就可以判断游戏结果的有效性。该方案有效缓解了 zkp 生成和验证时间过长的问题，同时它还为一些无法进行 zk 证明的环节，提供了一套可行的证明方式，比如射击类游戏中，谁的操作率先被 Z4 节点处理，谁的击杀可能性更高，而时间是无法被写在ZK 电路中，因此，需要借助这种社会化共识，作为游戏可验证的途径。以下是 ZK 证明和 Threshold ECDSA 签名之间的比较：

上表表明，虽然zk证明为更简单，确定性的游戏事件提供了高水平的安全性和不可否认性，但Threshold ECDSA为复杂和实时场景提供了更快，更具可扩展性的解决方案，依靠社区共识来解决zk证明无法有效处理的方面。

参考文献 ：

【28】Ozdemir A, Boneh D. Experimenting with collaborative zk-SNARKs:ZeroKnowledge proofs for distributed secrets[C]//31st USENIX Security Symposium (USENIX Security 22). 2022: 4291-4308.