State channels, like the Lightning Network, have long been seen as an alternative scaling solution to layer 2s, but have never seen large-scale adoption. They were costly, required predefined user flows, and offered low utility. Powered by ZK Accumulators, the Virtual Engine is a ZK state channel enabling unlimited participants to complete unlimited transactions on Any Chain, with new state channel use cases like capital-efficient, zero-gas DEX day-trading and fully onchain gaming.
Why You Should Care about Zero Knowledge State Channels
Before heading back into some tech, let’s review the benefits, drawbacks, and use cases of ZK state channels.
ZKSCs achieve a Zero-Gas, Zero-Latency, and Zero-Friction Web3 experience. Day traders can now open sessions where they exchange ETH for RPL, RPL for USDC, USDC for XRP, etc. with no fees and no latency, matching the experience offered by a CEX with the crucial benefit of self-custody and trustlessness.
Fully Onchain Gaming can be truly achieved with all game actions becoming decentralized. Some argue that only assets need to be onchain, but when these assets, and tournament pots, are determined by who wins, it is important to reach this conclusion in a trustless manner. Currently, these winnings are distributed custodially through a server because it is expensive and latent to direct gameplay through the blockchain. The Virtual Engine makes this possible and profitable.
Federated social platforms like Mastodon and Bluesky, and Web3 platform FriendTech, could become truly decentralized, with all posts, likes, and comments arriving onchain, but without the associated cost and bad UX. True censorship resistance without compromise.
The utility goes on, with loyalty point systems and file storage projects possibly benefiting from ZKSCs. But, it is important to mention the drawbacks.
ZKSCs will never replace L2s. Nor is that their intention. In fact, ZKSCs work on L2s, and even appchains. They do not compete because ZKSCs are an extremely powerful tool to Streamline Web3 UX within recurring transactions. However, as aforementioned, a majority of blockchain volume is used for making one-time payments for services, NFTs, and swaps. ZK State Channels, by their very name, involve updating states. They are effective if and only if there are multiple states to update and bundle.
But even if fully onchain gaming, day trading, and SocialFi represent a minority of volume, improving throughput and UX will increase the size of the pie. The Web2 Gaming market size, for example, is $250 billion, larger than NFTs, $16 billion, Web2 social networking, $70 billion, and even stable coins, $125 billion, all combined. However, the Web3 Gaming market size is a poultry $24 million, only representing 0.0096% of gaming’s value onchain.
Web3 gaming has significant advantages over its centralized counterpart, including interoperability, immutable assets, censorship resistance, and the possibility for token appreciation. Therefore, its limited size must be chalked up to boring games, bad UX, and the failure to fully offer Web3’s benefits. Employing the Virtual Engine allows developers to worry less about blockchain compatibility and focus more on building good games; eliminates gas, latency, and other Web3 frictions; and enables true trustlessness and interoperability.
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) 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) 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.
Consider poker powered by a 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?
Achieving Game Theoretic Optimal ZKSC
Blockchain is already a P2P electronic cash system, as proposed by Satoshi. Consensus must take into account disagreement, which is solved by Proof of Work in Bitcoin, Proof of Stake in Ethereum, or bank rules and laws in any centralized system.
However, there is another type of consensus: self-validation. Whereas blockchain requires majority or supermajority consent, self-validation requires unanimous consent. You can imagine a ZKSC as a private ledger between three friends. Alice may borrow $10 from Bob, Carol loans $20 to Bob, and Alice borrows $5 from Carol. When they settle up, it’s crucial that every party is represented to align everyone's interests: Alice, Bob, and Carol agree, creating “N-of-N” consensus. They could, of course, submit their transactions instead through a decentralized network, but this has associated costs and latency and still relies on a 51% trust assumption.
A natural objection to this self-validation system is what happens if Alice, Bob, and Carol do not agree at the end. Let’s reimagine the private ledger between Alice, Bob, and Carol, but every transaction must be acknowledged by every party in real time, so finality is instantly achieved at the point of every individual interaction, and not at the end. If Alice borrows $10 from Bob, she sends her signature to Bob and Carol, Bob sends his signature to Alice and Carol, and Carol signs this to both Alice and Bob. Now, every user has a record of account. It is immutable. When they settle up, every user can unilaterally prove the balances because they self-validated every transaction themselves.
Yet, there are still more problems. Like what happens if Carol refuses to sign Alice and Bob’s transaction or how does the money get trustlessly withdrawn at the end? This is where the blockchain comes into play. We can use public ledgers as objective bystanders for our private ledgers.
First, the trustless depositing and withdrawal of funds becomes straightforward with smart contracts. Written signatures transitions map nicely to digital signatures too. For the dropout problem, the issue described above where Carol refuses to sign Alice and Bob’s transactions, malicious or not, there are a few solutions.
For verifiable randomness, time-locked encryption shuffling and Dynamic User Entropy, proposed by Virtual Labs, work well. For state channels at-large, we can use the same dynamic properties achieved through ZKSCs to allow for game theoretic optimization.
Dispute Scenarios and Relay Resolution. All past interactions are self-validated and recorded by each player, therefore every player can unilaterally prove the legitimacy of their claims. The only possible method of attack is by preventing the game from moving forward.
If Alice makes a P2P transaction to Bob, but Carol does not acknowledge it, either through network failure or malicious intent, Alice will place the P2P transaction between her and Bob onchain while alleging that Carol is not “live.” If Carol does not prove her liveness onchain within a specified timeframe, say one minute, then Carol’s signature will no longer be required after Alice’s initial allegation. However, if Carol does commit onchain to prove her liveness, then she can do so confirming Alice’s transaction as legitimate—admitting that she was not live before but has become live again—or proving her liveness but stating the reason she did not accept Alice’s transaction was because Alice is malicious.
The naive solution to what happens if Carol is live but rejects Alice’s transaction is to close the channel. All transactions beforehand are self-validated, so they are provable by every user. These can be verified onchain trustlessly. Alice was not able to make her transaction to Bob, so she can do so now over a new channel without Carol.
There is a better solution, especially for games and trading sessions where latency is of the utmost priority: use other Virtual Engine users as relays.
If it comes to the point where Alice and Carol are still claiming liveness, but are still disagreeing on the transaction, we can conclude for certain that at least one of them is malicious. Either Alice and Bob are colluding against Carol, or Carol is blocking the transaction as an annoyance. With this stated, the goal becomes clear: prove who is malicious and allow the game to continue by ensuring neither cannot claim their counterparty is not live.
Allow me to specify one note: if Carol alleges that Alice is malicious, she is not stating that the transaction itself is illegitimate. This is impossible, as any proposed illegitimate transaction could immediately be posted onchain as proof of malintent and cause slashing. This self-validation system is so secure, the only way a user can attempt to break it is by claiming they did not receive the transaction in question at all. If Alice and Carol both claim this, it is impossible to prove who is telling the truth over a P2P network and move forward.
Because proposing illegitimate transactions is impossible, attempting to “prove who is malicious and allow the game to continue by ensuring both are live” makes sense as a final step in ensuring trustless and seamless self-validation.
So, how is it done? Extend the P2P network from Alice, Bob, and Carol to all live Virtual Engine users. The main drawback of this is that it will increase latency, but as the competition finalizes transactions after 12 seconds, US EAST-EUR SOUTH-equivalent ping is acceptable as a last resort.
An initial conclusion might be that this is now a blockchain and these other network participants are going to vote on who is live and who is malicious. This is actually not the case. Instead, Alice, Bob, and Carol will begin communicating through the other N participants. Because Carol now receives communication through Dylan, Evelyn, Frank, Grace, and others, she can not allege that Alice is not live. Alice, in turn, can also not allege that Carol is not live. It could be argued that Alice or Carol could attempt to bribe some of the relays, but this is impractical as only one honest participant is required, making this fallback Byzantine Fault Tolerant.
Say Alice bribes Dylan, Evelyn, and Frank to claim they received no communication from Carol. Grace will still receive the communications from Alice and Carol. Her ledger alone could be posted onchain, proving that Alice was, in fact, live. Even though Alice has bribed the majority of the relays, the presence of Alice and Carol’s signatures in just one record of account ensures the fair continuation of the ZKSC. As the number of Virtual Engine users increases, successfully bribing 100% of them will become impossible - and because this is not consensus, acting as a relay can be done by any user with a phone and WiFi connection.
This is the case because if all relays show both Alice and Carol’s interactions, then Alice and Carol are provably live. If only Alice’s transactions are displayed, and no relay receives transactions from Carol, then she is not live. If only Carol’s transactions are displayed, then Alice is verifiably not live. If there a mix of these three states (AC, Ac, aC), then this necessarily means that both Alice and Carol were live, as the relays who received Alice and Carol’s transactions could not produce valid timestamped proofs from both of them without them having sent in those proofs themselves. Even more, this relay will not actually need to post their record of Alice and Carol’s transactions, because a claim from either of them that alleged the other was not live could be proven incorrect, resulting in a slashable offense. Because not all relays can be feasibly bribed, there will always exist at least one honest record of account that can prove the liveness of both users. This record and entire system is a deterrence from malicious behavior, ensuring the health of the protocol.
The best part of this system is that a record of malicious users who needed to use relays can be constructed, eventually prohibiting those with bad records and possibly slashing them. And finally, because this game theoretically optimal system allows no profitable attack route, the relay system will seldom ever be used, keeping latency to a minimum.
Virtual Engine Mechanism Design
With a large bulk of underlying theory discussed, let’s take a look at how the Virtual Engine practically works.
- Users deposit funds
- Users find each other over a Lib P2P Network, identifying one another through the public addresses that have deposited capital in their state channel
- Users complete an action, which reaches finality when every users completes a handshake, exchanging their proofs of agreement
- Users maintain their own updated state through the public deposit history as a the first state, followed by updates they approve
- Instead of storing N (users) *S (states) proofs, users instead continuously reaggregate proofs using a ZK Accumulator
- So, a user can prove the final state and cash out by one lightweight proof which agrees to their final balance
Some specifications of the Virtual Engine are as follows:
1. Buying in:
- Action: Initiated through MetaMask or other wallet traditionally
- Cost: Normal EOA or AA transaction cost ($1.26 EOA, $6 AA)
- Time: 20 seconds on mainnet
2. Within Virtual Engine:
- Action: In-game click, akin to Web2 UX
- Cost: $0.00
- Time: 10ms proof generation + 2*K (user with highest ping), ~110ms for an average American mobile user
3. Closing:
- Action: Aggregate proofs submitted via traditional wallet, or for a sequencer to process
- Cost: 1.30 times EOA or SC transaction cost ($1.64 EOA, $7.8 AA) but can be bundled with other exits for decreasing marginal cost
- Time: 20 seconds on mainnet
The lightweight MuSig/BLS signatures only represent a portion of total gas. Because the majority of an EVM transaction data load is made up of boilerplate metadata, a sequencer can combine multiple exit proofs from a closing channel to exponentially lower user costs. Just three proofs would result in a total transaction cost of 39,000, split across three users is 13,000, or $0.78 EOA and $3.72 AA.
Whereas traditional state channels allow users to break even above three transactions, this theoretic ZKSC model achieves it at less than two!
What are ZK Accumulators?
ZKSCs are made possible and cost-effective through MuSig2, BLS, and Plonky2 (soon Plonky3), which form an overarching primitive we call a ZK Accumulator.
An Accumulator is a membership test formed from a one-way hash function that enables an objective bystander to make conclusions on user agreement and participation in an extremely lightweight data structure. The term “ZK Accumulator” might be redundant, as Accumulators are already widely associated with zero knowledge proofs. However, it is important to draw a distinction between RSA and other non-dynamic structures from those that are fit for high frequency interactions with arbitrary N users as well as other device and game rule constraints.
To explain what ZK Accumulators are, I believe it prudent to start with how we’re using them and why they are important.
To enable multi-user, dynamic ZKSCs, we need a lightweight signature-proof scheme that can accept new members, while maintaining the ability to prove that all members agreed to the signed data. It also must be easy-to-verify across multiple chains, both for secure bridging, but also to reduce costs when unlocking funds.
MuSig2, BLS, and Plonky2 all represent types of accumulators, with increasing complexity and power. MuSig2s are the simplest and only grant the verifier binary agreement: 1) all participants have signed the data or 0) at least one participant has not. These two-round Schnorr Multisignatrues do not allow the verifier to know which participant has not agreed. In this sense, they are zero-knowledge, although not in a traditional or particularly helpful way.
Next up on the latter is BLS, that’s Boneh, Lynn, and Shacham, not Barreto, Lynn, and Scott, although we’ll be discussing the BLS12-381 curve as well. BLS is well known for its pairing capabilities and is the signature scheme for Ethereum PoS. BLS signatures do allow the verifier to discern the individual agreements and disagreements from the aggregate key pairs, which is useful in several scenarios (ETH Research).
According to 0xParc, “Verifying a BLS signature involves a pairing check that two elliptic curve pairings are equal and is thus directly enabled by zkPairing. This unlocks potential scaling applications like signature aggregation for light clients and bridges.” This means that BLS can be recursively verified and compiled inside SNARKs. This is useful for both of BLS’ two main drawbacks: limited blockchain support and quantum attacks.
Despite numerous proposals, pushes, and promises by the core devs, BLS verification is expensive on mainnet and simply cannot be done on other chains, like Polygon. Bundling BLS inside Plonky2 (or Halo2), SNARKS would decrease marginal costs without a substantial increase in latency. The other main disadvantage of BLS is that they are not quantum secure, which zero knowledge proofs also solve.
Finally, Plonky2 is the last scheme Virtual is employing for ZK Accumulators. There are three ways Plonky2 powers ZKSCs. First, these SNARKs can bundle existing BLS signatures. Because BLS aggregation is instant and SNARK bundling is cheap at scale, this combination works well. Second, Plonky2 can form a light client to prove that a user is running the correct version of a game or trading application, providing anti-cheat measures. If users are able to attain these proofs up-front, it could rule out future disputes. Finally, this SNARK can directly form the ZK Accumulator itself. An advantage here is that a Plonky2-powered Accumulator could allow efficient state updates for multiple Virtual Rollups and for all users within them. This means that users would not need to cash out, as one user signing out and proving their own state would necessitate proving onchain the balances of all other users.
Virtual Labs is employing all three options across this spectrum of ZK Accumulators. Native MuSig2s validation is common across most chains, and is therefore the version running in the current Virtual Engine by our partner protocols. The BLS version has been up and running for some time, but verification remains prohibitively expensive or impossible across Polygon, BNB, Ethereum, and Arbitrum, which represent 90% of our users. The team has achieved working Plonky2 Accumulators internally and is excited for them to pass security checks before wider deployment.
Virtual Rollup
The Virtual Engine is the ZK State Channel protocol that powers trustless, self-validated transactions. It is the cryptography, P2P network, and system of smart contract verification. The Virtual Rollup is the specific use case of eliminating transactions and latency, and creating sessions for users to deposit, interact, and withdraw.
Virtual Rollups is our flagship product and is closely associated with the Virtual Engine. We’ve drawn this distinction to emphasize that while there is significant overlap with the Virtual Engine and Rollup, the VE is capable of powering so much more.
For more details, check out our full piece on Virtual Rollups.
Virtual Bridge
The Virtual Bridge is a super exciting use case of the Virtual Engine which will enable instant cross-chain access in a theoretically trustless setup. The Virtual Bridge will allow a user on chain 1 to use a dApp on chain 2 without even realizing the dApp is on a different chain.
Note: There is always smart contract and malware risk, so no financial application is ever “risk-free.” Be cautious of those who claim that, but we will outline how the Virtual Bridge and its atomic swap model theoretically eliminate user-risk.
The Virtual Bridge utilizes two underused concepts: atomic swaps and reorg-resistant escrow.
Atomic swaps are supported by Vitalik as an alternative to bridging, which has seen billions in exploits the past few years. Bridging is systemically risky because it involves trusting a third party across more than one consensus layer, where it is difficult to hold them accountable.
Atomic swaps, meanwhile, are completely user-validated. They function by Alice and Bob double-locking Alice’s funds on chain 1 in a ZKSC. Alice and Bob then double-lock Bob’s funds in a ZKSC on chain 2. Bob will then send the key to Alice, who will add her own key and unlock Bob’s funds on chain 2, delivering them to her wallet. Bob will now be able to see Alice’s key on the public blockchain and use it to unlock Alice’s locked funds on chain 1, delivering them to his wallet. There is no node, validator, or third-party involved. Although sequencers can be used to trustlessly streamline the process with the users holding final custody. This method, which is also outlined below, eliminates trusted middlemen, returning power back to the users themselves.
There are two downsides to consider, however. The first is that users must complete multiple operations across several chains. The second is liquidity and the necessity of a counterparty who holds the desired assets and wishes to trade.
The ZKSC model solves both of these. In the same way that traditional state channels were complicated to set up and required extensive knowledge but Virtual Labs made them virtual, the same can be done to atomic swaps. In fact, ZKSCs already handle some of these interactions through the already established sessions, which allow the passing of keys across a P2P network. Further, these can be delivered to the aforementioned sequencer which will perform these actions on the users’ behalf. The sequencer cannot unlock the funds without the correct keys, so Alice and Bob maintain custody.
The goal of the Virtual Bridge is to allow a user on chain 1 to use a dApp on chain 2 without even realizing the dApp is on a different chain. This therefore solves the second problem of liquidity as users are already set up with counterparties in a dApp on a different chain.
In reorg-resistant escrow, previously locked funds from the ZKSC are utilized to immediately begin bridging funds. This is a rather unique opportunity for Virtual, because it requires locked funds waiting in a contract. In other protocols, there is no reason to do this, but VE users will be encouraged to leave funds in the contract after closing a Virtual Rollup dApp session. This makes sense for users who plan to use any of Virtual Labs’ partner games or dApps again, as they can save on gas to withdraw their funds now and on the gas to restart the Virtual Rollup next session. They will also earn yield in the meantime.
Because these users will already have funds in self-custody ZKSCs, any reorgs during transfers will result in their return back to the ZKSC, not their EOA. So, the opposing party (a bridge or counterparty in an atomic swap), can grant funds immediately (instead of chain 1 finality + chain 2 finality) because they will be able to submit the same proof back to the contract in the event of a reorg with no risk.
This is pretty cool. Even more, a dApp on an opposing chain can be sent an easy-to-verify proof by the user over the Virtual Engine P2P network to allow the user to begin using the dApp immediately through the assurance that the funds are on their way, even before they actually arrive.
A natural question is how to maintain the balance between locking funds and self-custodianship. The user’s balance is always the sum of their deposits and their state balance when they are currently interacting with the Virtual Rollup. So, it is not possible to dispute a user’s balance and the objective bystander in the form of the smart contract will always display the correct Virtual Balance. However, the contract can not allow the user to withdraw funds immediately, as this could interrupt the bridging process. Instead, the user will submit their withdrawal request, and a 10-minute timer will begin. At the end, the funds will be sent directly to the user’s EOA or desired destination. Therefore, other chains and dApps are assured that these funds are reorg-resistant so long as this withdrawal request has not been submitted.
For more information, read the full piece here.
Virtual Wallet
The Virtual Wallet ties everything together, allowing the user to interact with the Virtual Rollup and Virtual Bridge. The Virtual Wallet, now live on testnet, represents ZKSC balances in a clean UI and contains a Virtual Engine client that facilitates user proof generation and P2P communication.
Users will also be able deposit funds in the ZKSC through Virtual Wallet, which will automatically earn yield without any staking action necessary. This is made possible by enabling Virtual Engine to Lido, MakerDAO, and RocketPool corridors. On top of ETH and USDC rewards, users will also enjoy $VRTL distribution.
The Virtual Wallet is a smart account and interface that can be controlled by an EOA or through social sign in powered by our partners at Biconomy. To further Streamline Web3 UX, users will not need to install an extension or store keys within the Virtual Wallet.
More information is coming about the Virtual Wallet soon!
Conclusion
The Virtual Engine is Streamlining Web3 UX Through ZK State Channels. It enables Instant Cross-Chain Access, Self-Validated, Zero-Gas Transactions, and Automatically Staked Yield. The VE utilizes ZKSCs to make web3 workable - usable and scalable - so that when the first billion users arrive to blockchain, we can keep them.
Please Tweet any questions to my personal account or follow Virtual’s X for updates. Subscribe below if you enjoyed!
Sources
Social Networking Market Size & Share Analysis - Growth Trends & Forecasts (2024 - 2029)
Global Non fungible token (NFTs) market insights
Stablecoin Market to Soar to Almost $3T in Next 5 Years: Bernstein
