This article was first published on Loopring Protocol - Medium
This post is meant to provide a quick overview of how Loopring 3.0 works, and how we use zkSNARKs to enable scalable, secure DEXs. For a deep dive, you can check out the full design doc on GitHub.
The third version of the protocol tackles the scalability problem of decentralized exchanges. Previous versions of the protocol already did the order matching off-chain, but the settlement was completely on-chain. This still has a high computational and storage cost on-chain.
Protocol 3.0 solves this by moving almost all data off-chain as well as moving all computations for all requests off-chain using zero-knowledge proofs (zkSNARKs).
Data is stored in a Merkle tree using an account model. Each user has a single account with a one-to-one mapping to his Ethereum address. This account can store balances for all tokens the exchange wants to support and also stores all the trading history data for the user. Requests modify the Merkle tree and the state transitions are verified on-chain using proofs.
For efficiency reasons, requests are batched together in blocks. The cost for verifying a proof remains constant no matter the number of requests in a block, but we are limited in how many requests we can include in a block, otherwise, the proof verification on-chain would not be efficient anymore. How many requests we can include in a block depends on the complexity of the request. If multiple requests types would be included in a block there would be some overhead of doing computations that are only necessary for a single request type so we limit blocks to a single request type for now.
We currently support 5 different requests:
- Trade settlement
- On-chain withdrawal
- Off-chain withdrawal
- Off-chain order cancellation
Only the first three are necessary for building a fully functional ...
To keep reading, please go to the original article at:
Loopring Protocol - Medium