Foreword
In this article, I will employ a method of deep analysis and step-by-step progression to design a relatively universal Fiber technical architecture solution for turn-based combat games. The design principles of this solution are:
-
Targeting exclusively two-player turn-based combat scenarios involving on-chain asset-based gameplay
-
Implementing a Challenge mechanism to strictly prevent cheating, rule violations, and negative gameplay
-
Allows integration of third-party Relayers, but their responsibilities are limited to message forwarding and coordinating Challenge workflows. Runtime context can be restored by requesting data from both combatants, without storing any private data
Before exploring the technical architecture, it is essential to clarify the turn-based battle process and key considerations. We assume the battle involves Player A and Player B:
-
After Player A and Player B are matched, each contributes a portion of their on-chain assets to be locked within the game
-
Player A and Player B take turns issuing game commands to advance gameplay
-
The game has clear victory/defeat determination rules.
-
The winning player has the right to demand the losing player transfer assets. If the losing player fails to fulfill this obligation, the winning player may initiate a Challenge to forcibly claim the assets.
-
Both Player A and Player B are obligated to advance the game until a winner is determined. If either party refuses to advance the game, the other party has the right to initiate a Challenge to demand the right to enforce the game’s outcome.
The Fiber interfaces primarily include the following:
Framework Analysis
When incorporating a third-party Relayer, the system architecture diagram for this framework is planned as follows:
-
Fiber Node
Each game client must connect to a Fiber node running on its local intranet. Since Fiber nodes lack intranet penetration capabilities, they cannot connect directly to each other. Instead, they must access the Fiber network by connecting to external public nodes.
-
Relayer
Responsible for distributing game operation commands between clients and receiving on-chain settlement requests initiated by clients. The latter bundles all game operation commands and submits them to the on-chain contract. If the instruction set cannot advance the game to its final outcome phase, it enters Challenge mode.
-
Game Client
Accepts player input commands and advances game progress. It stores all game operation commands locally from the start of the game. When the game concludes with a winner or when no opponent’s operation commands are received for an extended period, it can request on-chain settlement from the Relayer and submit all game operation commands. The latter then enters Challenge mode.
-
Channel
Established before the game begins. Both clients pre-pay a deposit to each other via the Channel, signifying “I authorize you to seize this deposit if I lose or violate game rules.” Once gameplay commences, the Relayer coordinates the “deposit seizure” operation.
-
Game Contract
Responsible for validating the legitimacy of game operation instructions submitted by clients. It also replays operation instructions to confirm whether the game has reached the final outcome phase. If so, it reveals the loser’s preimage on-chain to release their deposit. If not, it enters Challenge mode, then reveals the preimage of the party that failed the challenge on-chain. The Relayer handles communication with the contract.
Assuming the third-party Relayer is fully trustworthy, the channel creation sequence diagram for this framework is planned as follows:
Process Explanation
Before the match begins, both players must establish a Fiber channel and lock the agreed-upon game assets into the channel. Asset locking utilizes Fiber’s PayToPaymentHash technology, creating an Invoice based on the Hash of the Preimage rather than the original Preimage itself. At this stage, the payment Invoice remains in a “pending” state. Only after the original Preimage is provided is the payment formally recorded in the ledger.
Key Points
In the diagram above, the Relayer possesses the respective preimages of both combatants. Therefore, the entire combat system’s feasibility relies on the Relayer being “fully trusted.” Consequently, the Relayer must strictly ensure that preimages are disclosed exclusively on-chain, with no alternative disclosure channels.
Assuming the third-party Relayer is fully trusted, the victory/defeat phase sequence diagram for this framework is planned as follows:
Process Explanation
The CKB contract contains the game engine code, capable of replaying all game instructions. When Player A wins, the client sends all locally stored operation instructions to the CKB contract for replay. Upon completion, if the game state indicates Player A’s victory, the Relayer reveals Player B’s Preimage to the contract. Upon retrieving the Preimage from the blockchain, Player A can unlock the payment suspended by Player B within their Fiber node to receive the reward.
Key Points
In the diagram above, Player A unlocks Payment(B ⇒ A), but Payment(A ⇒ B) remains suspended. Since Player B cannot obtain Player A’s Preimage, this payment stays suspended until the channel closes. The Relayer acts as the revealer, requiring constant monitoring of on-chain contract state updates beforehand.
Assuming the third-party Relayer is fully trusted, the challenge phase sequence diagram for this framework is planned as follows:
Process Explanation
The main flow and win/loss phase show no significant differences. The distinction lies solely in the fact that the instruction set provided by the players cannot advance the game process to the win/loss phase, but there is a clearly defined number of combat rounds N. Within the challenge time window, if the CKB contract fails to receive an instruction set that can advance the game process to round N + 1, the player who provided the latest instruction set is declared the winner.
Key Points
If a player maliciously withholds their latest operational instructions from the opposing player and instead directly submits a command set containing their latest instructions to the CKB contract to force a challenge mode advantageous to themselves, the opposing player cannot obtain the malicious player’s operational instructions via the Relayer but can access them through the CKB contract. In this scenario, the command exchange mode for the game match will degrade from the original offline mode based on the Relayer to an online mode based on the CKB contract.
This framework imposes no mandatory requirements on the player command exchange process, meaning security levels are determined by the framework user. For those sensitive to data security during exchanges, the recommended command exchange sequence diagram is planned as follows:
Key Points
Compared to simple command exchange, the above exchange logic requires both combatants to exchange their public keys beforehand. Then, before sending each game operation command, the command must be signed. The command data and signature are sent together. This way, upon receiving the command, the opponent can verify the data’s correctness using their public key.
Conclusion
Unlike consensual tipping scenarios, this framework addresses the more challenging adversarial context where the Invoice payer possesses an incentive to refuse payment. Therefore, introducing a Challenge mechanism to prevent payment refusal constitutes the core problem this framework solves.
This framework is designed with a maximal decentralization approach. However, since Fiber’s payment actions inherently lack programmability, it still relies on the Relayer as a single point of trust. Consequently, the framework’s minimum trust requirement for the Relayer is: Never unlawfully disclose the Preimage of either party. Only by meeting this baseline requirement can the framework’s security hold. That said, introducing ZKPs might eliminate this security dependency on the Relayer. I believe there is significant room for discussion here.