First of all, I would like to clarify that I am not very familiar with Flow nodes and FVM implementation. I just want to bring up this topic for discussion.
Recently, I read Amit’s Cadence Game Engine and was amazed by the ‘Tick’ on game via Cadence Script. (Github: CadenceGameEngine)
It is a very unexpected design, and I never thought that scripts could be used in this way before.
In fact, as a game engine, the Tick method is a crucial concept. It is the core method that handles logic changes in the game and brings about visual changes.
But in a sense, this implementation has big issues:
Because the business state of all games and their historical states before being persisted are cached on the front-end rather than on-chain. This is because on-chain updates cannot occur at a frequency of 100ms.
Therefore, this solution cannot be used for a commercial game (we assume that the front-end is filled with cheaters and scammers).
Recently, I have been researching some fully on-chain games on EVM and Starknet (which is currently a frequently mentioned topic in the crypto community)
Check the onchain game list: Composable Hub
I found an interesting solution:
- The game is written in Cairo contract language (the smart contract language of Starknet).
- The game runs on cairo-vm (Github: cairo-vm), This Cairo VM runs on the game server.
- Submit the results of multiple calculations to Starknet through ZK Proof, and complete the final on-chain process.
By using this method, the separation of data computation and data on-chain has been achieved, while also achieving high-frequency data updates suitable for gaming scenarios.
So can we also introduce similar mechanisms in our ecosystem? Have we achieved a truly usable solution for on-chain commercial gaming?
Because within our ecosystem, we actually already have all the technical elements to implement similar mechanisms: for example, the Flow simulator(an indenpendent FVM), independent Verification Node and Execution Node, and the SPoCK mechanism similar to ZKProof.
Imagine if there were such a mechanism:
- A game developer can create a state locking contract to lock assets on the main chain within that contract.
- All assets locked in the contract can be managed by the game developer’s own FVM. This FVM only needs to periodically submit ZKProof to the mainnet(Only verify the proofs for this contract).
- Game developers can operate their FVM at any frequency according to their own needs, and they can even instantiate a separate FVM for each of their users.
This can completely make FVM a full-chain computing engine, completely replacing traditional web2 backend computing engines.
Mainly some thoughts, there may be significant conflicts with the current implementation of Flow.
But I want to say something I have observed in other ecosystem and bring some possibilities.