ZK State Channels

With a large bulk of underlying theory discussed, let’s take a look at how the Virtual Rollup practically works.

1. Users deposit funds on smart contract, receives state root

2. Users find each other over a P2P gossip network, identifying one another through the public addresses that have deposited capital in their state channel

3. Users complete an action, which reaches finality when every users completes a handshake, exchanging their proofs of agreement

4. Users maintain their own updated state through the public deposit history as a the first state, followed by updates they approve

5. Instead of storing N (users) *S (states) proofs, users instead continuously reaggregate proofs using a ZK Accumulator

6. So, a user can prove the final state and cash out by one lightweight proof which agrees to their final balance

Let's begin by analyzing how Virtual Rollup transactions work, powered by ZK state channels. It is good to remember that Virtual Rollups are not blockchains, but ZK state channels. Virtual Labs believes that no amount of blockchain scaling will ever truly eliminate the problems of gas and latency. Block creation is periodic and finite in nature, so delay and scarcity, the ingredients of gas and latency, are built in and immutable.

At a glance, a ZK state channel is made up of two parts: a peer-to-peer communication and settlement layer and a blockchain escrow and arbitration contract. The idea is to allow applications to achieve finality with local consensus, decided among the relevant parties, and to store their deposits and balances in a locked contract with predetermined unlock conditions. This combines the security of a blockchain with the speed and ease-of-use of self-verified P2P channel. Interaction with the blockchain only occurs at deposit and withdraw, eliminating most of the gas and latency.

The smart contract processes 3 main requests: accept deposit, arbitrate dispute, and distribute withdrawal, but most functionality occurs on the peer-to-peer layer in the form of state updates.

Accept Deposit:

A user will deposit accepted ERC-20 tokens into the smart contract in exchange for a genesis state root. This state root acknowledges the deposit and sets up the approval of subsequent state updates by a 2/2 signature scheme: VDEX and the user.

State Updates:

If the user wishes to purchase an asset, the user, they will sign the state update, which includes the position, balance data, and time stamp, and send it it to VDEX. VDEX will check the available balance and the market maker's orders, and sign the trade, sending it back. VDEX will store the user's signature. The user will store VDEX's signature.

Finality is achieved at the moment both parties complete the handshake. This is not dissimilar to a multisig. As further trades are made, both parties store complete ledgers of their counterparty's acknowledgement. If a dispute were to arise, the user can prove that VDEX signed off on the trade, and vice-versa.

When the user wishes to withdraw, they will request to flip the Boolean "isSessionFinished" with a final state update.

Distribute Withdrawal:

If the user's state update contains "isSessionFinished==true" then the contract will read the balance within and distribute it to the depositor's original address, as defined in the contract and state update, immediately.

Process Dispute:

If both parties cannot agree on a final state update, perhaps because one has gone offline or is acting maliciously, then "isSessionFinished" will not be true and they have entered into a dispute. Note that this cannot happen is both parties are acting honestly and properly. Because both parties record all transactions, it is not possible for this to occur during normal circumstances. Perhaps the user has gone offline when VDEX is attempting to liquidate or a user is attempting to submit an old state update when their balance was higher.

If this situation does occur, the previously recorded state updates are used. One of the parties will submit a state update onto the contract. Of course, the contract has no way of knowing the private date of the peer-to-peer channel, so this could be an old state update. So, in cases of dispute, the contract will function optimistically within a 24-hour window. If the user submits an old state update, VDEX will have the opportunity to submit a more recent one. The contract will evaluate that the second state update is indeed signed by the user and has a more recent UTC timestamp. The balance in this state update will thus be observed.

1. Buying in:

• Action: Initiated through traditional wallet on Ethereum mainnet

• Cost: Normal EOA or AA transaction cost ($1.26 EOA, $6 AA)

• Time: 20 seconds

2. ZK State Channel state root updates:

• Action: In-game click, akin to Web2 UX

• Cost: $0.00

• Time: 1ms 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

The lightweight MuSig2/Blind Schnorr 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!

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

Besides the Virtual Rollup, the Virtual Bridge is another super exciting use case of the ZK State Channel. The Virtual Bridge enables 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. Here's how it works.

The ZK state channel is made up of two parts: onchain escrow contracts and self-verified peer-to-peer state channels. All transactions occur within the state channels while the smart contracts only handle deposits and withdrawals. So, it is the smart contracts job to accept the deposit and create the state channel.

After the state channel is created onchain, the user and VDEX sign each subsequent trade, not dissimilar to a 2/2 multisig. The user and VDEX store each other's signatures on their own devices. Therefore, at any one time the user stores the deposit signature and N trade signatures. To withdraw and unilaterally claim their capital, the user runs a function to combine the previous signatures into one 520-bit withdrawal signature.

Here's the trick: the smart contracts deployed across multiple chains are identical. Therefore, this 520-bit withdrawal signature can be submitted across any chain that has deployed Virtual Rollup and holds enough liquidity. However, if the chains are identical, then why can a user not submit the same signatures across all chains and double-spend?

The deployed smart contracts are identical except for one variable: chainID—the blockchain know which chain they are in relation to other chains. Say Ethereum is chainID:0 and Bitlayer is chainID:1. When the withdrawal signature is generated, its chainID is set to a specific value: 0,1,2... If this signature is submitted onto a chain that does not match the chainID, it will reject the signature.

So, ZK state channels enable chain abstraction. This of course be used to bridge funds into and out of different blockchains as well. It also has the side effect of bypassing reorg latency if the user trades for some time. For example, if a user deposits on Ethereum, trades for 10 minutes and withdraws to Bitlayer, the funds will reach the user's EOA within one block time. This is because the reorg attack window on Ethereum has already passed when the user traded, so withdrawals are now instant.

ZK state channels enable a no-compromises alternative to centralized exchanges, Web2 gaming, and social networks. ZKSCs utilize a P2P gossip network and underling decentralized escrow layer, employing blockchains for what they are good at: settlement. This cooperation has the power to streamline Web3 UX by eliminating gas, latency, and wallet frictions the three major inhibitions to mass adoption. The resulting product, the Virtual Rollup, does this while maintaining scalability, self-custody, and trustless execution.