How to Use zkSNARKs to Scale DEX on Ethereum Blockchain?

By Jay Zhou   May 31, 2019 7 Min Read

Fast, trustless, token trading. Not an oxymoron anymore. It’s with great excitement that Loopring unveils the design of our newest, fastest, and most forward-looking protocol, Loopring Protocol 3.0.

Protocol 3.0 has two main benefits:

1) Way higher throughput & lower costs.

2) Apparent immediate settlement.

Combined, this means that trading on a DEX will no longer feel like trading on a DEX.

Using blockchains to trade blockchain-based assets makes sense. We all know it. Any other situation is rather puzzling. So why, as traders, are we giving our cherished, trustless, magical money to trusted intermediaries? Why are we trading IOUs? Why would we ever move our assets off the open platforms that promise to permeate all corners of finance and beyond?

Many of us are guilty of doing just that. Meanwhile, with the current state of centralized exchanges, we don’t know whether to be more fearful of losing crypto to outside hackers, or inside jobs. We also haven’t a clue what is real volume and what is fake. Although, people are figuring it out.

To be honest, however, there are (were) good reasons that cryptocurrencies and tokens traded on centralized exchanges: trading on a DEX is not (always) fun or feasible. There, we said it.

UX, liquidity, and scalability are the three big obstacles commonly listed. Our fellow builders, particularly in the Ethereum DeFi community, have made absolutely incredible progress on many fronts: deeper liquidity is awakening, and beautiful dapps are offering an experience as simple as web 2.0.

Scalability, though, especially as it pertains to trustless trading, has remained elusive. And let’s face it, without massively scaling DEXs (or massively scaling Ethereum a layer below) we won’t realize our ambitions. With that in mind, Loopring R&D has been focusing heavily on scalability solutions over the past 6 months.

Our new release, Loopring Protocol 3.0, stares squarely at scalability, and uses one of the most promising tools to help solve it: zero knowledge proofs.

High Level Overview of Zero Knowledge Proofs

We’ve always had scalability on our minds. That’s what influenced our design decision from the beginning (1.0 and 2.0): a hybrid model, with off-chain order messaging, and on-chain settlement. Do as much as possible off-chain, and use the blockchain only when needed, for mission critical guarantees.

Protocol 3.0 is kind of like that — just taken to its extreme and logical conclusion. Now, we can do much, much more off-chain, including settlementwhile still remaining secure.

We achieve this by using zero knowledge proofs (ZKPs), a cryptographic tool that can be used by someone, a prover, to prove they’ve done some computation or know some ‘secret’ — without actually peeling back the curtain to give a verifier a look at said computation or secret.

That sounds like it’s pretty useful for privacy, right? I can, for example, prove to some investment group that I have >X dollars, the threshold to join their club, without divulging exactly how many dollars I have. And the group can be certain I’m telling the truth. Pretty mind-bending. It’s also the stuff that powers (or shields) some of the leading privacy focused coins like ZCash.

Besides privacy, though, ZKPs are also extremely useful for scaling complex systems. Instead of proving I have >X dollars, I can also prove that, as a DEX owner, my users’ have their proper balances in their accounts, that I’ve settled their trades appropriately, processed withdrawals, etc… all the DEX-y computations you can think of. And instead of executing this in blockchain smart contracts, I do this off-chain, and come up with a small proof that still makes everyone know I’m telling the truth.

That’s what Protocol 3.0 aims for: scalability without sacrificing security.

In 3.0, pertinent data such as account balances and trade history are kept off-chain in Merkle trees. By doing so, trades can be settled between users just by updating the tree off-chain, with no need for slow, expensive token transfers on-chain.

We do not give up security guarantees by doing this. ZKPs assure that what was claimed to be true and executed, is true and executed. The protocol is still 100% non-custodial, and fully secure for end users — even when DEX operators are malicious, they cannot steal your tokens.

With all computations done off-chain, we can speak to the Ethereum chain much less frequently, and with much lighter loads. In fact, all DEXs submit to Ethereum is that proof we mentioned — a proof that certifies everything that a DEX has done off-chain is correct.

With ZKPs, specifically zkSNARKs — the form we have chosen to work with — the proof can be checked trivially and efficiently (in milliseconds) by verifiers, or, in our case, a smart contract built to verify proofs.

High Level Overview of Loopring Protocol 3.0

Anyone can create a new exchange on the Loopring protocol. An exchange has an owner and an operator.

The owner is who handles business-related functions, like registering tokens, putting the exchange in maintenance mode, and setting the operator.

The operator is responsible for creating, committing and proving blocks.

Blocks are not Ethereum blocks in this sense — they are simply chunks of DEX related work, such as trade settlements. A block changes the Merkle tree from the existing state to the new state by doing the state changes required in all the work in the block. The correctness of the work in a block needs to be proven and submitted to the Ethereum chain. This is done by creating a ZK proof.

For the highest throughput, 3.0 currently supports off-chain balances only. These balances are stored in Merkle trees. Users deposit and withdraw tokens to our smart contracts, and their balance will be updated in the Merkle trees. [Note: You don’t need to trust a custodian. It is trustless. No risk of losing funds.]

Going it alone

Block submission needs to be done sequentially so the Merkle tree can be updated from a known old state to a new state. To allow concurrent settling of orders by independent parties, we allow the creation of stand-alone exchange contracts. Every exchange contract operates independently. User accounts and orders cannot be shared over different exchanges contracts.

Or working together

Alternatively, DEXs can decide to use the same exchange contract so orders and user accounts can be shared — if they desire. This also avoids the need to setup its own infrastructure to handle block creation and creating proofs.

The operator can be a simple Ethereum address, or can be a complex contract allowing multiple operators to work together to submit and prove blocks. It is left up to the exchange for how this is set up.

Such an operator contract can also be used to enforce an off-chain data availability system. A simple scheme could be that multiple parties need to sign off on a block before it can be committed. This can be checked in the operator contract. As long as one member is trustworthy and actually shares the data, then data availability is assured.

Similarly, the exchange owner can also be a contract! One scenario is that the exchange owner can be some sort of governance contract, or DAO, managing many DEXs within.

All of this is completely left up to the DEX and can be updated when needed without disrupting the exchange.

Statefulness, Stickiness

Because of the above, we envision most trading will be done on a single exchange contract using contracts as the exchange owner/operator. This not only increases liquidity, but also improves the efficiency, latency and throughput because blocks contain work from all DEXs.

This is also important because it dramatically enhances the possibility for ‘statefulness’ in the Loopring protocol — the act of holding valuable state, users, and liquidity. A coordinated, thriving group of DEXs will not easily disband/fork. This adds to Loopring’s defensibility, continuity, and value.

[For more details on how such a group of DEXs built on one contract can implement flexible business logic and share orders/fees, see here.]

One final remark on that note is, given the off-chain account balances, there is some baked-in user stickiness to a DEX that a trader uses (and likes) under this framework. So a well-performing DEX, or group of DEXs using the same contract, can build and hold a devoted user base. We’re pleased with this, because after all, it is our goal to support successful DEXs atop the protocol.

Throughput and Cost Figures

So let’s get to the good part— how much improvement are we looking at?

Our current implementation achieves 525 trades per second on Ethereum without on-chain data availability and 160 trades per second on Ethereum with on-chain data availability. For reference, past versions of Loopring (and other DEXs) did ~2 trades per second.



About the author

Jay Zhou
Jay is a Chief Marketing Officer of Loopring. He has extensive skills across online payment & financial operation with a particular focus on risk management and innovative solution. Prior to Jay’s work in the cross-border payment at PayPal, he worked in a spectrum of different industry sectors including; Risk&Compliance at Ernst&Young and a member at Global Shapers Community. Jay has been supported and published articles on blockchain tech at Chinese Smart Contract (Ethereum) community and mentoring blockchain course at Stanford University.

Like this post:
Read More