What is Virtual Labs?

Virtual Labs is the creator and maintainer of blockchain's first ZK state channel, the Virtual Engine.
The Virtual Engine enables users to pay open a channel, and subsequently never pay gas again for that DApp. You could, for example, deposit 100 USDC on Polygon, and trade WBTC and ARB on Ethereum's liquidity. While the channel is open, you could make an unlimited amount of transactions while trustlessly finalizing your trades at the speed of your internet connection.
This is our Web3 Vision at Virtual Labs: zero-gas, zero-latency, and zero-friction to incentivize trustless onchain activity and boost liquidity. Here's how this works:
How Virtual Labs Achieves Zero-Gas on Any Chain, Including Ethereum
Essentially, whenever you or your users will interact in a recurring manner—gaming, day trading, or SocialFi—the Virtual Engine SDK can enable seamless, Web2 UX within decentralized applications.

Why Integrate or Use the Virtual Engine?

• Say goodbye to high gas and long settlement times. DApps powered by the Virtual Engine SDK have higher engagement and retention
  • Wallet and bridging frictions are eliminated
  • Capital previously used to pay gas remains with the user and your platform
  • Incentive alignment: while further traditional transactions have an adverse incentive—playing another game round or making another trade induces an additional gas cost, period of waiting, and several MetaMask clicks—Virtual Engine users only pay to close their session, encouraging more inter-ZK State Channel interactions
• The Virtual Engine seamlessly integrates in under an hour, and the Virtual Labs team is here to help!
• The Virtual Engine is not a blockchain or appchain, meaning you can easily use it within your current tech stack
• Access more user without multi-chain deployment
  • The Virtual Engine enables users on different chains to use their locked funds to seamlessly engage with your DApp, settling on your DApp's default blockchain
  • If your DApp rests on Arbitrum, Optimism, OPBNB, Polygon, ZKSync, NEAR, Solana, or Manta, for example, you will be able to seamlessly access these users from all other chains, 5-10xing your TAM

If you are new here, keep learning About Virtual Labs and how we are category-defining ZK State Channels, and how this technology will achieve mainstream adoption.
If you are a developer or project lead, begin building with the Virtual Engine SDK here!
If you are a community member, or would like to join and learn about Virtual Points and $VRTL, check out the Virtualizer Community Zone.

History

Virtual Labs began as "Ontropy" in September 2022 and got accepted into Binance's prestigious S5 Incubator. In the bottom of the bear market in June of 2023, OP Crypto VC led Virtual Labs' $1.3M Pre-Seed round at a $20M valuation. Participation included the NEAR Foundation and highly technical investors focused on zero-knowledge proofs.
Virtual Labs was founded by José Betancourt, a Yale Dropout and economics analyst. He leads a team from Harvard, Composable Finance, the Defiant, and more, representing 40 years of engineering and Web3 experience.
We choose the name "Virtual" to represent our vision and product—streamlined, abstracted, and easy: Virtual.

Vision

Virtual Labs is singularly focused on one thing: bringing about blockchain mainstream adoption by improving user experience. It is our belief that lowering barriers to entry and eliminating frictions is how blockchain will become accessible and used by the masses.
Virtual Labs is a cryptography company with experience in atomic swaps, game theory, and zero-knowledge proofs. This background led Virtual Labs to develop blockchain's first ZK State Channels: a user-verified transaction bundling scheme. This as-of-yet underhyped technology is they key to achieving the zero-gas, zero-latency, and zero-friction experience to which most of the world population is accustomed.

Progress and Roadmap

Virtual Labs has been in stealth for most of 2023, proving that ZK State Channels were theoretically possible, and then testing MVPs with DApps and community members. These testnet integrated 26 DApps, onboarded 6,000 users, and processed over 1,000,000 transactions.
2023 saw development of the underlying technology of the Virtual Engine, with little focus on the application layer. In December 2023, cryptographic testing concluded and the size of the Virtual Labs team doubled in anticipation of new testnets and the upcoming mainnet launch.

How Virtual Engine Transactions Work

Virtual Rollups are powered by the Virtual Engine to deliver Self-Validated, Zero-Gas Transactions on the application layer
Virtual Rollups bundle transactions from multiple users to lower costs and latency. However, as opposed to optimistic or ZK rollups, Virtual Rollups have no nodes, validators or sequencers. In a Virtual Rollup, these roles are fulfilled by the user! You verify the transactions and order proofs. This makes Virtual Rollups unilaterally fault tolerant. This means that you alone can prove and eliminate user cheating and collusion.
Here's how it works:

1. Players "buy-in" by depositing collateral to a smart contract. This balance is represented and changed in an in-game virtual wallet. If the application does not require funds, then a deposit is not necessary.
2. The players in the lobby, or users in an application, regenerate ephemeral keys to include the new user. Existing players need not interact with the blockchain.
3. When a player makes an interaction, and data leaves their device, a Plonky2 MuSig is added and sent out to all other players. These other players also sign and send back this data. All players add this agreement to a Merkle root so that they can later prove that the interaction was received by everyone else.
4. Once a player is ready to leave, they will request that the other players knowledge this by completing a "lock-and-key" method that points the virtual balance back to the player's MetaMask wallet. This way, the player cannot double spend the balance in the lobby. The player submits the lightweight proof on-chain and receives funds immediately.
   • If one or multiple of the other players refuse to unlock the player who is attempting to leave, they may reaggregate the signatures they received during game interactions in step 3 and submit this similarly lightweight proofs. Therefore, as finality is achieved at the point of making the interaction, and not during cash-out, malicious players can only incur a slightly more expensive proving process (6,500 gas, or 0.003 MATIC).

The result is an SDK that can make Web2 games fully on-chain in under an hour, all without cost, latency, or wallet friction.

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

• 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 ChannelCan 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?