Written by: Mohamed Fouda
Compiled by: TechFlow
For on-chain games, the horizontal expansion of Rollup is very suitable for single-player games. But for multiplayer games, zk state channels are a better expansion option. So, what are zk state channels?
State channels are not new. In fact, they are one of Ethereum’s earliest scaling solutions. State channels are essentially:
Get part of the on-chain state;
Constantly changing this state off-chain;
Commit the final state to the chain when needed.
Apparently, the concept is an extension of the Bitcoin Lightning Network design, which is essentially a payment channel.
However, without zero-knowledge proofs, state channels don’t make much sense. Without zero-knowledge proofs, all signatures (off-chain) authorizing changes to state must be subsequently verified on-chain. This does not result in a significant fee reduction compared to on-chain transactions.
Zero-knowledge proofs easily solve this problem. State channel participants simply generate a proof (off-chain) that all their interactions and signatures are valid. This proof is cheap to verify on-chain, greatly saving costs.
So, what does this have to do with scaling on-chain multiplayer games?
Many multiplayer games, such as poker, are tournament-based, where a group of players creates a game, competes in it, and changes everyone's assets based on the outcome of the game.
For this type of game, you need a shared layer to store everyone's assets.
The details of each game process are not as important as the final result of the game (changing the asset balance). In addition, players cannot participate in multiple games at the same time.
This makes these games ideal candidates for zk-state channels. Once the game begins, the state of the participating players is locked on the Rollup. During the game, players generate ZKPs that prove the validity of their actions. ZKPs recursively build on previous ZKPs, and so on.
When the game ends, only the final ZKP and associated state changes are submitted to the Rollup for settlement. Since intermediate transactions are not processed on the Rollup, this achieves up to 100x scalability.
This approach also works for non-turn-based games, such as Among Us. However, in this case, an entity is needed to act as a "temporary" sorter, sorting channel transactions and generating intermediate recursive ZKPs. I call this scenario "ephemeral L3".
The main challenge of the zk state channel approach is the liveness requirement of the channel participants. A disconnected player may force the remaining players to continue executing on the Rollup. Thus, forcing other players to pay higher costs,
The potential of this approach is huge, and many teams are working in this direction, including Ontropy, Paima Studios, and Cartridge.