The quest for a truly decentralized game ideally leads to a fully onchain model such as DeFi. However, there are two significant challenges to achieving this ideal: UX and contract vulnerability.
Needless to say, fully onchain games suffer from inherently poor UX. While some projects are tested on private chain testnets, our goal is to play on the mainnet of public chains.
Contract vulnerability is a worse problem, especially as the game's logic becomes more complex. Given the current state of DeFi, which has numerous security issues, it’s unrealistic to assume games will be any safer.
To address these challenges, we propose a hybrid game model that combines onchain and offchain. This model leverages the strengths of both approaches while mitigating their weaknesses.
Deep Dive into the Hybrid Game
The hybrid game we propose records only specific data onchain: the state at the beginning of the battle, the state at the end of the game, and the random number seed.
All game logic is executed offchain, with the game intermediate state during battle also maintained offchain. The game logic should remain open and transparent to ensure fairness and verifiability.
We drew inspiration for this model from Plasma, so we named this architecture PlasmaEngine. Plasma is a concept that has gained renewed attention in the Ethereum Layer2 community. It retains only the initial and final states on Layer1, with all intermediate states managed offchain. This approach allows Ethereum to scale infinitely.
In our hybrid game system, players send transactions only twice per game—at the start and end of a battle—providing a practical and user-friendly experience, even as game logic becomes quite complex. Currently, PlasmaEngine seems to be suited for auto-battle games.
Risks and Constraints
While PlasmaEngine leverages offchain components, it is not entirely secure:
Centralization Risk: The game operates under the assumption of a central entity, the Minister, which manages the game execution. If the Minister is hacked, battle results could be tampered with. However, such tampering would be limited to the most recent battle and could not alter past results. Since the initial state and random number seed are recorded onchain and the logic is open, any malpractice by the Minister can be detected.
Although there is no direct challenge function, discrepancies in results would be apparent to everyone, allowing temporary halts in the game if necessary. Adding a delay in reward claims (e.g., a 7-day period) can further reduce the incentive for fraud.
Reduced Contract Vulnerability: By minimizing the onchain processing, we can significantly lower the risk of contract vulnerabilities. The smart contract only needs to store some states, create random seeds (or obtain them from external services like Chainlink), and verify the Minister's signature.
Currently, PlasmaEngine is applicable to auto-battle games. For games requiring constant command inputs, intermediate states would also need to be stored onchain, making this approach less feasible.
Auto-battle games have a rich history and a solid standing in the gaming community today. Titles like Auto Chess, SuperAutoPets, Backpack Hero, and Unicorn Overlord exemplify this genre.
Conclusion
Despite its constraints, the hybrid game model offers a promising solution to the challenges of fully onchain games, balancing decentralization with practical UX and minimized risk.
We are currently developing an auto-battle hybrid game using the PlasmaEngine. Follow us on X for updates and to join us on this innovative journey.
