english version: A Universal Turn-Based Competition Framework Based on Fiber
前言
本篇文章我将用深度剖析、层层递进的方式，设计一个相对通用的针对 回合制对战游戏 的 Fiber 技术架构方案，该方案的设计准则是：
-
仅针对 2 人回合制对战游戏场景，同时涉及到链上资产的博弈行为
-
引入 Challenge 机制严格防止作弊、破坏游戏规则和消极游戏等异常行为
-
允许引入第三方 Relayer，但权责限定为转发消息和协调 Challenge 流程，且运行时上下文可通过向对战双方索取数据来进行恢复，不保存任何私有数据
在探讨技术架构之前，需明确回合制对战的流程和注意事项，假定对战双方由玩家 A 和玩家 B 构成：
-
玩家 A 和玩家 B 匹配完成后，各自拿出部分链上资产锁定在游戏中
-
玩家 A 和玩家 B 轮流发出游戏指令，共同推进游戏进程
-
游戏有明确的胜负判定规则
-
胜方有权要求负方转移资产，若负方不履行给付义务，胜方可以向负方发起 Challenge，强制索要其资产
-
玩家 A 和玩家 B 都有义务推进游戏进程，直到游戏决出胜负，若有一方拒绝推进游戏进程，另一方有权发起 Challenge，索要游戏胜利的强制判定权
使用到的 Fiber 接口主要包括以下几个：
框架剖析
在引入第三方 Relayer 的情况下，本框架的 系统架构图 规划如下：
-
Fiber Node
每个游戏客户端都需连接一个运行在本地内网的 Fiber 节点，由于 Fiber 节点没有内网穿透功能，因此无法互相直连，需通过连接外部公共节点来接入 Fiber 网络
-
Relayer
负责在客户端之间分发游戏操作指令和接受客户端发起的链上结算请求，后者会将所有游戏操作指令打包交给链上合约，若指令集无法推进游戏进程到最终胜负阶段，则进入 Challenge 模式
-
Game Client
接受玩家指令输入并推进游戏进程，在本地保存从游戏开始时的所有游戏操作指令，当游戏决出胜负时或者长时间未收到对手方的操作指令时，都可以向 Relayer 请求链上结算并提交所有的游戏操作指令，后者会进入 Challenge 模式
-
Channel
在游戏正式开始前创建，双方客户端会通过 Channel 预先向对方支付一笔定金，代表 “我输了或者违反游戏规则之后允许你拿走这笔定金”，之后游戏对战正式开始，Relayer 会负责协调 “拿走定金” 这步操作
-
Game Contract
负责确认客户端提交的游戏操作指令是否合法，还会重放操作指令以确认游戏是否达到最终胜负阶段，如果是则在链上揭示输家的 Preimage 以释放其定金，如果不是则进入 Challenge 模式，然后在链上揭露挑战失败方的 Preimage，由 Relayer 负责与合约通信
在假定第三方 Relayer 完全可信的前提下，本框架的 通道创建时序图 规划如下：
流程讲解
在对战开始前，对战双方需创建 Fiber 通道并将约定好的博弈资产锁定到通道中，资产锁定的方式采用 Fiber 的 PayToPaymentHash 技术，即基于 Preimage 的 Hash 而不是 Preimage 原象创建 Invoice，此时完成支付的 Invoice 处于 “挂起” 状态，待提供 Preimage 原象后这笔支付才正式计入账本
关键要点
在上述图例中，Relayer 知晓对战双方各自的 Preimage 原象，因此整个对战系统的可行性需建立在对 Relayer “完全可信” 这一点上，因此 Relayer 需严格保证只会在链上揭露 Preimage 原象，无任何其他揭露途径
在假定第三方 Relayer 完全可信的前提下，本框架的 胜负阶段时序图 规划如下：
流程讲解
CKB 合约包含了游戏引擎代码，可重放所有游戏指令，当玩家 A 取得胜利后，客户端会将储存在本地的所有操作指令发送给 CKB 合约进行重放，在重放完毕后，如果游戏状态显示为玩家 A 胜利，则 Relayer 将向合约揭示玩家 B 的 Preimage 原象，玩家 A 从链上获取到 Preimage 原象后，可在自己的 Fiber 节点里解锁被玩家 B 挂起的支付，从而获得回报
关键要点
在上述图例中，玩家 A 解锁了 Payment(B ⇒ A)，但 Payment(A ⇒ B) 仍处于挂起状态，由于玩家 B 无法获得玩家 A 的 Preimage 原象，因此该支付将一直处于挂起状态直到通道关闭，Relayer 在其中扮演着揭露者的角色，在这之前，它需时刻监控链上合约的状态更新
在假定第三方 Relayer 完全可信的前提下，本框架的 挑战阶段时序图 规划如下：
流程讲解
主要流程和胜负阶段没有明显区别，区别仅在于玩家提供的指令集无法将游戏进程推进至胜负阶段，但有明确的战斗回合数 N，在挑战时间窗口内，若 CKB 合约未能收到能将游戏进程推进至回合数 N + 1 的指令集，则判定由提供最新指令集的玩家取得胜利
关键要点
若有玩家恶意不转发自己的最新操作指令给对手玩家，而是直接提交包含自己最新操作指令的指令集给 CKB 合约以迫使进入对自己有利的挑战模式，在这种情况下，对手玩家虽无法通过 Relayer 获取作恶玩家的操作指令，但能通过 CKB 合约获取，此时游戏对战的指令交换模式将从原本的基于 Relayer 的离线模式降级为基于 CKB 合约的在线模式
本框架对玩家操作指令的交换流程不做强制要求，即安全等级由框架使用者自行决定，若对交换过程中的数据安全较为敏感，则建议的 指令交换时序图 规划如下：
关键要点
和简单的指令交换比起来，上述交换逻辑要求对战双方事先交换手中的公钥，然后每次发送游戏操作指令前都需要对指令进行签名，将指令数据连同签名一块儿发送，这样对手方收到指令后可以通过手上的公钥验证数据的正确性
结尾
不同于你情我愿的打赏场景，本框架所要解决的是难度更高的对抗场景，在该场景下，Invoice 付款方具备拒绝付款的动机，所以如何引入 Challenge 机制以防止拒绝付款行为的发生，是本框架所要解决的核心问题
本框架以最大化程度的采用去中心化的思路进行设计，但由于 Fiber 针对的支付行为本身无可编程性，所以仍然需要依赖 Relayer 这一单点信任主体，因此本框架对 Relayer 的最小信任要求为 绝不非法公开对战双方的 Preimage，只有满足这一最低要求，本框架的安全性才能成立，不过也许可以通过引入 ZKP 来消除对 Relayer 的安全性依赖，我想这里应该会有很大的探讨空间