ZK State Channel vs. State Channel

The benefits of Zero-Knowledge State Channels compared to the first version

A state channel involves locking funds into a smart contract then trading the rights to this escrow over a P2P (peer-to-peer) network. Because the funds are already locked and the signature exchanges occur directly between users, it’s trustless while being gas and latency-free.

The catch is that the costs associated with locking and unlocking funds (i.e., opening and closing the state channel) means users must perform at least three zero-gas P2P transactions to receive a cost-benefit. The addresses of the transacting users must also be predefined in the smart contract.

Necessitating a predefined relationship limits utility. After all, most DeFi transactions are between two strangers who transact once.

The advent and incorporation of zero knowledge into state channels (ZKSC) by Virtual Labs brings three innovations that exponentially increase their use cases: unlimited participants with a fixed cost; dynamic channels overcoming rigid and predefined user flows; and self-validated, easy-to-verify proofs for trustless cross-chain access.

Virtual Engine (ZK State Channel)	Traditional State Channel
Features: Unlimited users Dynamic entering and exiting Self-Validated proofs for instant cross-chain access Seamless, abstracted use	Features: Two users Predefined addresses (new users force channels to close down and re-open) Single chain Difficult to set up

This vastly increases the use cases of state channels from transaction batching to gaming, DeFi, and SocialFi:

Virtual Engine (ZK State Channel)	Traditional State Channel
Can be used to: Onboard 100% of gameplay and game assets onchain Create seamless day trading sessions without gas or latency Enable censorship-resistant, global SocialFi Streamline loyalty points, bundled liquid staking, and more	Can be used to: Batch transactions, like the Lightning Network Establish recurring transactions, like those between merchants and vendors

To understand the difference and power of a ZK State Channel, first consider poker powered by a traditional state channel:

Alice and Bob can deposit 100 USDC into a smart contract, and play an unlimited amount of hands. Here, the state channel is beneficial because every previous fold, check, and raise would have needed to be an onchain transaction to maintain trustlessness. Alice and Bob benefit from saving 3 wallet interactions, 20 seconds, and a dollar in gas fees per game action.

However, if their friend Carol wants to play as well, Alice and Bob need to close the state channel with an expensive onchain transaction, and immediately reopen one including Carol. The closing fees scale linearly with the amount of participants which is why traditional state channels are best suited for only two users at a time.

If Carol, now part of the state channel, wants to leave the game before Alice and Bob, all three must close the channel and Alice and Bob must reopen a new one. Finally, if Carol or any other user wanted to join from a different chain, they would need to wait to bridge funds first.

Now consider poker powered by a ZKSC, like the Virtual Engine:

Alice and Bob deposit 100 USDC into a smart contract, and can play an unbounded amount of hands. Now if Carol wants to join, she must deposit 100 USDC into the same smart contract. Crucially, Alice and Bob do not need to close the channel nor perform an onchain transaction for Caroland to join. Underlying complexity is abstracted away from them.

If Dylan, Evelyn, and Frank also want to join, they all must perform their opening transaction onchain, but they join the existing ZKSC so the current users are not affected. This is why ZKSCs are dynamic. The Virtual Engine uses the deposit timestamp as immutable proof that all previous transactions do not include the new user's signature, but all subsequent interactions must. With 5, 50, or 500 users, the signature size has a constant amount of data, resulting in decreasing marginal cost.

Finally, if Grace has funds locked in the Virtual Engine contract on a different chain, she will be able to use these funds to immediately begin playing the poker game on the original chain. No bridging necessary! We’ll dive into more detail later, but in short, this is possible because her already locked funds are resistant to reorgs, so she can send a publicly-verifiable proof to the poker dApp (and other users), and trade against her escrow the same way Alice, Bob, and others are. Because users communicate P2P, the location of escrow is not important, so long as you trust the underlying chains themselves. To close the channel when funds are on different chains, users will balance what they owe to each other by performing an atomic swap.

To clarify one point, the Virtual Engine does not overcome reorg attacks on cross-chain transactions. But because the behavior of ZKSCs involves depositing funds up front and leaving it there, these same reorg-resistant funds can be utilized to overcome the traditional chain 1+chain 2 finality bridging wait period.

Now, how do we achieve this?