Loopring 3.5 is an intermediate upgrade over the current 3.1 version which is being used by Loopring Exchange in production. There is no plan to run a trusted setup for 3.5 or launch it into production. However, 3.5 is still a very important milestone for us as Loopring’s next major release, Loopring 4.0, will be built directly on top of the 3.5 codebase.

All changes from 3.1 to 3.5 are captured in the following two pull requests:

We look forward to comments, questions, and bug reports from Ethereum’s developer community. Bug reports will be rewarded with LRC based on their severity and priority.

Changes

Here’s a summary of the most important changes.

1. Custom Deposit Contracts

The deposit contract is the contract that stores all user funds and contains all the logic to transfer funds from and to a certain exchange. In 3.5 we allow exchanges to write their own custom deposit contract which provides them the flexibility to decide how exactly this is handled. In the most basic case, the deposit contract simply stores all user funds and only supports transferring Ether and ERC20 tokens. This is the most secure way to handle user funds, but it is not so capital efficient, because all the value locked up in the exchange is unused.

More productive usage of the funds would be storing the funds in a third party DeFi dApp or protocol that allows borrowing and lending to earn interest. The exchange could pass the earnings on to its users directly or indirectly by having lower (or zero) fees. This is likely, however, to never be risk-free so extra precautions should be built into the deposit contract to make sure users can withdraw their funds at any time. This is a delicate balance, and there is no single best solution, so we allow exchanges to decide for themselves how they want to manage users’ funds.

The deposit contract also allows exchanges to add more token standards without the need to update the main Loopring protocol contracts. All interactions with token contracts are done in the deposit contract, so that’s the only place that needs to know how to interact with a certain token.

2. Agents

An agent is an address that is allowed to authorize on-chain operations for the account owner. By definition, the account owner is an agent for himself. Agents can be simple EOAs or smart contracts. Smart contracts are the most interesting case because they allow extending the exchange functionality by implementing extra logic on top of the basic exchange functionality that’s built into the exchange contract. There are a lot of functionalities that can be added this way. This is also how we can provide composability with layer 1.

3. Conditional Transfers

Conditional transfers are transfers that are approved on-chain by the account owner or an agent of the account owner. No signature or other authorization is needed for the operator to do an off-chain transfer that was approved like this. Conditional transfers allow any (custom) on-chain mechanism (done by the account owner himself or by an agent) to decide if a transfer can be executed or not on layer 2.

4. Simplified On-chain Block Handling

Before v3.5 block submission was done in two steps: first a block was committed on-chain and afterward, it was proven that the block was correct by using a zero-knowledge proof. This was done because generating proofs could take quite some time (20 to 40 minutes). By previously allowing the proof for a block to be submitted later we could allow the on-chain exchange state to be updated sooner, which has some advantages like quicker economic finality. But with our prover optimizations, generating proofs for even large blocks is now pretty fast. By removing the separate stages we significantly simplified some parts of the protocol while also making some things more efficient.

  • Withdrawals are simplified because blocks are immediately finalized the moment they are submitted on-chain.
  • Block reverts are now impossible because blocks are immediately verified using proofs.
  • Multiple blocks can be submitted at once while we only need to store the latest state. This saves on storage costs (a big efficiency gain when using many smaller blocks) and also automatically uses batch verification internally when possible to save gas even further.
  • Operators now only need to care about submitting blocks on-chain. They don’t have to worry about anything else. Everything they need to do is handled in a single function on the exchange contract. No more manually distributing withdrawals, no more manually withdrawing on-chain block fees,…

5. Increased capacity for accounts and tokens

We increased the size of our Merkle tree that is used to store the exchange state. The maximum number of accounts we can support on a single exchange was increased from 2²⁰ to 2²⁴ (16,777,216 accounts). We also increased the maximum number of tokens from 2⁸ to 2¹⁰ (1024 tokens).

Loopring 4.0

The above sets the stage for a much more multifaceted and flexible protocol. We plan for Loopring 4.0 to have an exciting broadening in scope. More information will become available soon. Stay tuned.

Loopring is a protocol for building high-performance, non-custodial, orderbook exchanges on Ethereum using zkRollup. You can sign up for our Monthly Update, learn more at Loopring.org, or check out a live exchange at Loopring.io.

Twitter ⭑ Reddit ⭑ Telegram ⭑ Discord ⭑ GitHub ⭑ Docs ⭑ YouTube