ZK State Channel vs. State Channel

A state channel involves locking funds into a smart contract then trading the rights to this escrow over a P2P (peer-to-peer) gossip 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. Most importantly, ZK state channels are Turing-complete whereas state channels are not. So, any DApp, not just payment channels, can be supported with ZeroGas and sub-millisecond finality.

Specifications

ZK State Channel (Virtual Rollup)	Traditional State Channel
Unlimited users Dynamic entering and exiting Chain Abstraction Seamless ephemeral creation ZeroGas Sub-Millisecond Finality Turing-Complete computation network support (Virtual Rollup)	Two users Predefined addresses (new users force channels to close down and re-open) Single chain Difficult to set up ZeroGas Sub-Millisecond Finality

Use Cases

ZK State Channel (Virtual Rollup)	Traditional State Channel
Batch transactions, like the Lightning Network Establish recurring transactions, like those between merchants and vendors Turing-complete computation network (Virtual Rollup) can support any DApp Sub-millisecond finality perpDEXes Fully onchain gaming Censorship-resistant SocialFi	Batch transactions, like the Lightning Network Establish recurring transactions, like those between merchants and vendors

ZKSC vs SC Example

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 Rollup:

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 Rollup 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 Rollup 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 Rollup 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.

Conclusion

ZK State Channels are dynamic and can support N users, as compared to 2 users. But perhaps the biggest innovation is that their versatility allows them to power Turing-complete computers, so that DApps can be run on top of them. This computation network is called the Virtual Rollup. Here is our full paper that detail how this computation network can support orderbook applications.