Full Self-Custody
Explaining Virtual Rollup (ZK state channel) state updates
Last updated
Explaining Virtual Rollup (ZK state channel) state updates
Last updated
Because VDEX offers ZeroGas transactions and sub-millisecond finality, many assume that the protocol is custodial, trusted, and centralized. The reason VDEX took 3 years to come out was because this is not the case. In fact, the protocol has the fewest trust assumptions possible: smart contract risk, oracle manipulation, and the hard forking of Ethereum itself.
The standard for our red-teaming is if SBF himself were to escape from jail, hack into VDEX wallets and devices, and try and steal user funds. Our team of PHDs, Ivy-League game theorists, and IIT engineers have identified no possible way for this to happen. Neither have our quantitative or technical auditors. But as the adage goes, trust but verify. So, here is how we do it and why we are special.
Topics:
ZK State Channel
Standard for red-teaming
Bifurcated pools for user funds
Novel freeze mechanism enabling stage 2 decentralization
Letter of the law
Let's begin by analyzing how Virtual Rollup transactions work. 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.
For further detail, read our VR1.2 whitepaper.
The Liquidation Problem:
Because both parties are needed to process a state update, VDEX will be unable to liquidate a user if their balance falls below the maintenance margin and the user refuses to agree to the state update. So, for the user to enter into leverage, they must sign a state update agreeing to a stop market order for balance<=maintenance margin. This way, the user will not be able to later refute the agreement of the liquidation level. VDEX uses a third-party oracle to prove to the onchain arbiter that the asset prices have sufficiently reduced account balance—as otherwise VDEX could incorrectly claim that the funds were liquidated and steal funds.
Oracles are decentralized, but are not perfect solutions. It is for this reason we have identified oracles as a potential vulnerability. However, because nearly all of DeFi relies on decentralized price feeds, this trust assumption is not any larger than it is for any other protocol. In Virtual Rollup 2.0, we plan to bring about Death to Oracles.
The Censured Closing Problem:
If a user wishes to close out their position, but VDEX is acting maliciously or otherwise not responsive, then they can withdraw onchain. However if they hold active positions, how will these positions be sized? If the buy price was used, then users could lose out on profit, or break even on unrealized losses. Trusting VDEX to provide this price would not be very decentralized, now would it?
So, an oracle will be used here as well. If the user holds an open position and VDEX is unresponsive, the user will open a dispute by submitting an unfinalized state update to the smart contract. The smart contract will call the latest price for each unrealized position and process a withdrawal with the calculated balance.
The Collusion Problem:
Protecting user funds is VDEX's number one priority. It has already been proven that user can unilaterally prove their correct balance and trustlessly withdraw that balance. But what if their is no money left to do so? What if VDEX were to create a fake user. Being in control of VDEX and the fake user, we would be able to claim any balance possible and withdraw all of the user funds!
This is why VDEX has bifurcated user funds from the insurance pool. All possible profits must be withdrawn from the insurance pool. So even if the total contract balance includes, say $12 million, but $11 million is from user deposits, then VDEX can only withdraw this $1 million.
But $1 million is still a lot! True, but only VDEX can perform this hack, and VDEX is unilaterally responsible for funding the insurance pool. So rather ironically, a malicious VDEX could only steal its own funds with this method.
However, what if a user has genuinely profited an amount greater than what is in the insurance pool? Because perpetual trading is a zero-sum game, the existence of a winner guarantees losers of equal amount. The winning user will submit their state update into the contract. The insurance pool will immediately pay out its balance. If more remains, then an alert triggers the movement of unprofitable users balances from the user funds pool to the insurance pool.
This process is self-verified and decentralized to avoid the titular collusion problem, so it can take up to 24 hours to resolve.
The Upgradable Contract Problem:
Most L2s are infamously just multisigs that are centrally controlled. VDEX wanted to achieve stage 2 decentralization from the beginning. This was not only to protect user funds, but to meet the relevant legal definition of a decentralized exchange.
If the VDEX smart contract was upgradable, then a hacker could steal all user funds if they used our private keys to alter the contract. VDEX would effectively hold custody of user funds. So then why not make the contract static? Well, good engineering practice dictates that nothing is ever perfectly secure. If a hack did occur, VDEX would need to act quickly to freeze withdrawals so user funds were not lost. Going too far in either direction introduces problems.
To my knowledge, the Virtual Rollup 1.2 solution to this is completely novel. It's called freeze. If funds are being stolen from the exchange, VDEX will initiate a freeze. This freeze will automatically expire after 24 hours, but VDEX could end it earlier if it was determined that the hack was a false alarm. During this 24 hour period, VDEX operators will have the time to contact multisig holders and upgrade the contract.
The 24 hour freeze period allows us to meaningfully decentralize the multisig. The first version will be a security council of non-Virtual Labs teams members. the VR2.0 solution will be of $VRTL holders.
This makes VDEX legally not an exchange. We are the only perpDEX unable to stop trading, and thus the only exchange able to claim this truth and eventually enable trading for US customers.
The Chain Abstraction Problem:
Another seemingly centralized VDEX process is the ability to trustlessly deposit on one chain and withdraw on another. This is explained in detail in Virtual Bridge, but the gist of it is that the state updates the users generate can be accepted by any Virtual Rollup smart contract. Because the smart contracts will be identical across multiple chains, save for their chainID, the state updates can be accepted there so long as isSessionFinished is true. If there is some dispute, then the the dispute process must occur on the chain where the original deposit occurred. So it is not a permissionless bridge, but the funds are self-custodial in transit.
P.S. If you are a competitor looking to borrow ideas, we are currently selecting beta partners for VR1.3. Get in touch: jose@virtual.tech :).
