Loopring at ETHNewYork
Loopring is excited to sponsor ETHNewYork, an Ethereum hackathon held by ETHGlobal that is sure to bring Ethereum’s best and brightest to Brooklyn on May 17–19! We will be requesting 2 challenges, with 2 prizes totaling $4250 in LRC.
Besides the prizes, Loopring founder/CEO, Daniel Wang, will be giving a talk on how we use zkSNARKs to scale v3 of our DEX protocol.
Loopring Challenge #1: Build an Oedax UI
Prize: $2500 in LRC
Loopring has historically and predominantly been an order-based exchange protocol — meaning we build infrastructure to support building orderbook-based exchanges. Binance or Nasdaq are examples of order-based exchanges.
While that is still the case, we’ve also designed and developed an auction-based protocol: Open-Ended Dutch Auction Exchange, or, Oedax. Auctions don’t function like orderbook-based models, and can allow for certain benefits such as trading less liquid assets, and more easily obtaining price discovery.
Compared to the more common dutch auction model, this open-ended dutch auction allows both sellers and buyers to participate in an auction after the auction starts, so Oedax auction’s final settlement volume is not restricted by the initial deposit of either token and can potentially be much larger than a dutch auction. Oedax is well-suited for large trades and is market-making friendly.
You can and should read full details about Oedax design here, and find the repo here. You can also find a cool curve UI here to experiment with.
As for the challenge, we simply ask for you to create a web UI to display auctions, integrate with MetaMask, and allow users to participate in open auctions. Prize: $2500 in LRC.
For details on how to get started with this task, see here: https://github.com/Loopring/protocols/blob/master/docs/hackathon.md
Loopring Challenge #2: Write an Operator contract that allows multiple independent sub-operators to work together in v3’s zkSNARK-based DEX
Prize: $1750 in LRC
As we said above, Loopring’s bread and butter is powering high-performance orderbook-based DEXs. This became even more apparent with the recent release of Loopring v3, where we use zkSNARKs to allow DEXs to scale without sacrificing security. The throughput improvements have been remarkable.
Requests (ring settlements, deposits, …) are bundled into blocks and these blocks are committed and verified on-chain. Data is stored in Merkle trees, but only the Merkle tree root is actually stored on-chain. For this to work state changes need to be done sequentially: we need to start from a known old state (the Merkle root stored on-chain) and go to a new state (the new Merkle root). The entity that is responsible for creating, committing and proving blocks is called the operator.
The operator can be a single entity. In that case, this single entity is responsible for creating all the blocks and generating all the proofs. While this doesn’t have any impact on the security of the protocol there are still good reasons for allowing multiple operators to create and prove blocks:
- The proof generation is computationally heavy. Because committing blocks and verifying blocks are done independently of each other proofs can be generated in parallel by the different operators.
- For off-chain requests, the operator can choose which requests to include (or not to include) in a block. In other words, the operator can censor any request he wants for any reason. When anyone can become an operator an operator can still try to censor requests but another operator will be able to include the request in a block.
- Multiple operators make the protocol more decentralized. A single operator also means a single point of failure.
Once the operator has committed a block he needs to do the following:
- For all blocks types: Generate a proof and verify the proof on-chain. If the operator fails to do so the operator is punished by burning the complete stake.
- For withdrawal blocks: After the block is verified all withdrawals need to be distributed. If the operator fails to do this in time he is punished by burning a part of the stake (depends on the number of withdrawals).
- For deposit and on-chain withdrawal blocks: Once the block is finalized the block fee can be withdrawn.
If a sub-operator does not verify a block in time the block needs to be reverted.
As for the challenge, we ask you to write an Operator contract that allows multiple independent sub-operators to work together. Prize $1750 in LRC.
For further detail on the requirements of this challenge and how to get started, please see here: https://github.com/Loopring/protocols/wiki/Operator-Contract
That’s it for now! We can’t wait to see what you hackers #buidl, and to simply meet all the great developers, enthusiasts, and projects that will make this event unforgettable — and Ethereum undeniable!
If you have any questions about the challenges, please feel free to find us at the event, email daniel@loopring.org, or join any of the groups below. We’ll be using discord.gg/KkYccYp as a primary place for support. See you soon!
To stay up-to-date with Loopring, please sign up for Loopring’s Bi-Weekly Update, and find us at:
⭑ Twitter: twitter.com/loopringorg
⭑ Reddit: reddit.com/r/loopringorg
⭑ Telegram: t.me/loopring_en & t.me/loopringfans (Chinese)
⭑ Discord: discord.gg/KkYccYp
⭑ GitHub: https://github.com/Loopring
⭑ Kakao: open.kakao.com/o/gJbSZdF (Korean)
