The problem ZK State Channels solves

State Channels + Zero Knowledge

In implementing BattleZips-Plonky2, we used proof-carrying data (PCD) recursion to create a novel privacy and scalability solution that works cohesively with rollups to achieve superior scaling properties. State channels were once touted as the future of blockchain scalability. However, despite their apparent advantages, the optimistic fraud-proof implementations suffered from data leakage and delays during challenge periods. Recent zk advances in speed and recursion with systems like Plonky 2 have made these trade-offs obsolete. Unlike fraud proofs, validity proofs allow for instant finality for all settlements but liveliness. Zero-knowledge can also ensure data security for sensitive parties with zk recursive shielding.

What did we build?

Simply put: Using Plonky 2, we built a working zk state channel. In classic Mach34 style, we used the game Battleship to show a basic implementation of a multiparty, adversarial, and hidden information interaction. This type of relationship with counterparties pervades our economic exchanges. By modeling it in a simple toy demonstration, we are creating a foundation for more complex and impactful applications to be explored.

What can it do?

1. Recursively wrap all state transitions into a single proof posted to an L1
2. Use ZK Circuit logic to build ordered state with no need for any sequencer or intermediate state witness
3. Notarize the integrity of state execution with instant finality on EVM chains when posting "channel close" proofs.
4. Use recursive ZK shielding on the "channel close" proof to shield all private state, then exporting only the winner and loser
5. Use "channel close" proofs as generic state objects for further on-chain (or off-chain) actions. Like proving your battleship skills w/ELO scores

Circuit Flow:

Challenges we ran into

Recursion

The biggest roadblock to the development of zk state channels has been the lack of accessible recursion. Since 2022 we have rewritten Battle Zips in Circom, Halo-2, and Nior, trying to solve this problem. Plonky 2 has delivered its promise of fast, ready recursion and enabled this project.

ECC-based identity encryption

Our current project does not link the user's addresses in the state channels to their public addresses on the L1 settlement layer. This must be resolved for any state changes to translate from the state channel to the settlement layer. While we did not have time during the hackathon to tackle this, we believe IBE is the correct solution.

Hash Salt

We found that there needs to be hash salt added to make the board commitments computationally binding.

Add Merkle Tree

We need to add a Merkle Tree to nullify the shot coordinates. That way, they can only be made once per game. For battleships specifically, we don't want users to be able to guess the same coordinates multiple times.

Proving speed

A "channel state increment proof", which contains an inner "shot proof", takes about 1 minute to prove. We are very new to Plonky2 and suspect that further R&D would find readily adoptable methods to reduce the proving time. However, while this proving time is prohibitive for a turn-based video game, 1 minute per proof is entirely acceptable in scenarios like invoice factoring. Even if we struggle to hit < 10 second proof speeds needed for a remotely usable video game, we believe that we can immediately begin applying the ZK State Channel pattern to enterprise DeFi usecases that depend on confidentiality and minimal onchain transaction costs.