Skip to content
Brecht Devos edited this page Jun 4, 2020 · 1 revision

Loopring

Loopring is a protocol for scaling Ethereum exchanges and payments using zkRollup. A zkRollup manages accounts in an off-chain Merkle tree, and verifies each state transition with a validity proof. In addition to submitting the proof to Ethereum, it provides enough data to the chain so that anyone can rebuild the state of the Merkle tree, and assert and reclaim their rightful balances, so long as Ethereum exists. This is also important for a fully decentralized system, any block producer can jump in at any moment and process new rollup transactions on top of the latest state. A full technical specification can be found here (the design focuses mainly on trading as this is our core business, but transfers are fully supported as well, if support for trading is unnecessary please skip those parts).

Some quick scalability stats:

  • The proving cost is $25/1M transfers or $50/1M trades
  • With full onchain data-availability the onchain gas cost is 250 gas/transfer or 350 gas/trade (3000+ TPS for transfers, 2000+ TPS for trades).
  • Without onchain data-availability the gas cost is just 10 gas/transfer or 20 gas/trade (80,000+ TPS for transfers, 40,000+ TPS for trades).

Protocol 3.1 is live on mainnet and is being used by two exchanges, loopring.io and wedex.io, for the past 3 months. These products use our closed source relayer in a single operator model. This setup is non-custodial and censorship resistant for deposits and withdrawals, but not fully decentralized.

The complete protocol is open source. The protocol consists of smart contracts and zero-knowledge circuits. Our optimized zero-knowledge prover is also fully open source. However the relayer, the glue between the smart contracts and the zero-knowledge prover, is closed source.

Protocol 3.1 is fully audited, but has some limitations that makes it unfit for mainstream adoption. We have already released protocol 3.5 which contains small but important changes to mitigate these problems. We are also currently working on protocol 3.6 which will contain further improvements. Actual changes compared to protocol 3.1 will be limited, if an audit is deemed necessary for these versions that audit will not take long to conduct. Protocol 3.5 and 3.6 will also decrease the complexity of a relayer implementation.

We will need to conduct a new trusted setup ceremony for the updated circuits in 3.5 or 3.6 (we did one for 3.1). The initial release of the product does not need to wait on this ceremony to end so this isn't really a bottleneck for launch. The ceremony can keep running after the initial release on mainnet. The zero-knowledge keys used can be updated as more participants have participated, so the initial number of participants at launch can be relatively small.

We would advise using protocol 3.5 or protocol 3.6 (depending on the time of launch).

We would be glad to help implement improvements requested to the protocol itself or the smart contracts interacting with the protocol. For example, while all versions of the protocol can be used fully decentralized, there are several ways we could help to actually use this feature and improve on it.

For the relayer there are several options:

  • We can provide our relayer as a service. This service could be used either permanently or temporarily until an open-source relayer is developed.
  • Loopring develops an open-source relayer implementation for layer-2 payments (not trading). We'd like to do that, but not for free.
  • A third party implements an open-source relayer from scratch. We can provide some limited technical assistance for that.

nothing here

Clone this wiki locally