We Take ‘The Ultimate Non-Custodial Test’

Last week, Argent published a nice post, showcasing how their wallet stands up to the ‘ultimate non-custodial test’. Spoiler: they stand up very well, and users can always access their funds. It inspired us to take the same test.

Our foremost duty is towards user sovereignty & security — ensuring that Loopring-based DEXes can never access user funds, nor prevent users from accessing their own funds. Even if Loopring (the team, the foundation, anything) shut down or became malicious, it would not matter.

As the article says:

The unique benefit of a non-custodial wallet is to give you control. The wallet should never be able to access your assets, or prevent you from accessing them yourself.

The ultimate test of this is: what would happen if the company that built the wallet shut down? Or was cracked down on by a malicious government?

Custodial wallets, like Coinbase and Binance, would leave you exposed. Importantly, so too would some non-custodial wallets.

Change the word ‘wallet’ for ‘exchange’, and you’ve got Loopring’s (and hopefully all DEX protocols’) prime motivation. [Truthfully, wallet & exchange are blurred lines at some point in the DeFi paradigm, and, here, can practically mean “anywhere users hold funds”].

Loopring 3.0: Secure First, Scalable Second

It’s not revolutionary for a DEX to proclaim that users are always in control of their own funds — that’s the whole point, after all.

However, when a DEX protocol begins working towards scalability (high throughput, low settlement cost), and that takes you to layer 2, it is no longer obvious for users to enjoy 100% Ethereum-level security guarantees. Tradeoffs abound.

Specifically, it’s not trivial to scale the protocol and still ensure a user can be completely self-sufficient: always able to access their funds with absolutely no dependence on anyone or anything — just Ethereum existing.

That’s exactly what Loopring 3.0 provides — high-performance, non-custodial orderbook exchanges with the strongest security guarantees. We achieve this by using zkRollups with on-chain data availability, and are the first such DEX protocol on Ethereum.

In our design, wherever a tradeoff exists between security and scalability — or between security and generalizability — we choose security.

The lowdown on Rollups

First, let’s describe what a rollup is as a scaling solution, and distinguish between the 2 types you may have heard of recently. What better way than in under 280 characters!

As we see, zkRollups prove every state transition with a cryptographic proof, as opposed to Optimistic, which relies more heavily on game-theoretics.

In our construction, a state transition is anything a DEX does — processing trades, cancellations, withdrawals, etc.,— which updates a Merkle tree off-chain, is proven in a zkSNARK, and ultimately submitted to Ethereum.

ZK-style asks every little thing that happens off-chain to be proven (by math), whereas Optimistic is, as it sounds, more optimistic, and only asks for proof if someone suspects wrongdoing.

I won’t go into further detail, safe to say that, broadly, the trade-off is: you can do more general-purpose smart contract stuff with Optimistic, but ZK provides greater security guarantees.

ZK is well suited for scaling specific use cases, such as our DEX protocol. It also allows certain actions to achieve quicker finality, roughly because things are ‘set-in-stone’ sooner, and so the game theory needn’t play out for as long.

[To dive deep on the differences, check out this great article by Matter Labs.]

On-Chain vs Off-Chain Data Availability

Next up is the question of where to store the pertinent trade data, so anyone can reconstruct past and current states of the Merkle tree, which represents the state of the DEX.

While the Merkle root is stored on-chain in both types, the deltas between the leaves (accounts) also need to be known if someone is to be able to reconstruct the state at any time. Without the ability to do so, a user cannot ‘prove’ their account balance, and cannot withdraw their funds.

If that data is available, you can always access your own funds. If it is not available, the DEX operator cannot arbitrarily steal your funds, but you cannot access them either, so it is as good as gone.

So, the question, critically, is does the protocol keep this data on-chain or off-chain?

Keeping it on-chain means it’s possible for you (or anyone) to glean from the Ethereum blockchain — always there, eminently available. Specifically, the protocol uses transaction data for this.

Keeping it off-chain means keeping it anywhere else. In some databases off of the Ethereum blockchain. Maybe that is the DEX’s own database, or maybe it is a consortium of trusted partners and auditors and notaries and the like.

Of course, Loopring 3.0 enforces on-chain data availability, so if a DEX shuts down abruptly, or is being pressured by a state, it would not and could not hamper users’ ability to access their own funds. Not the DEX owner/operator, and not the Loopring protocol itself can get in between you and your funds.

However, if stored in some off-chain scheme, the data could easily fold in the face of such pressure, malice, or even human error.

Worst Case Scenario: Withdrawal Mode

Normally the bulk of work on the exchange is done completely off-chain by the operator. This is great for scalability, but requests done off-chain are completely unknown on-chain, which makes it impossible to know on-chain if an operator is still actually doing what they need to be doing.

That’s why we also support certain on-chain requests, most notable here, the on-chain withdrawal request. These on-chain withdrawal requests are done directly by users on-chain. If the operator refuses to process them, the Loopring smart contracts know this and take action:

• The smart contracts force the operator to do these on-chain withdrawal requests; it cannot process any other requests (trades, etc) if such a request remains outstanding. [This force happens after ~1 hour]
• If the operator keeps refusing to process them, the exchange goes into withdrawal mode, and the operator is slashed. [Happens after ~1 day]

The parameters are configurable, but <1 hour and <1 day are targets for now.

• At this point, the exchange is completely shutdown. The only thing still possible is for users to withdraw their money using a Merkle inclusion proof from the latest valid state. For a user to be able to create this Merkle inclusion proof, he needs the complete state of the exchange.

As we learned above, with on-chain data availability this is easy. It’s all there. Loopring will create tools to do this, but all information needed to do so is public and open source.

With off-chain data availability, however, users are dependent on a third party to provide the exchange state data. If a user can’t get access to this data, the funds are stuck in the exchange with no hope to ever recover it.

Any protocol which introduces a less-than-Ethereum link in the chain is liable to fail the ultimate non-custodial test.

Loopring is a protocol for building high-performance, non-custodial, orderbook-based exchanges on Ethereum. You can sign up for our Bi-Weekly Update, learn more at Loopring.org, or check out:

Twitter ⭑ Reddit ⭑ Telegram ⭑ GitHub ⭑ Discord ⭑ YouTube ⭑ LinkedIn