search

omgnetwork / research

43 stars 2 forks source link

Restricted Custody proof design #53

Closed kasima closed 5 years ago

kasima commented 5 years ago

Description

As a trader I can check that my orders were matched correctly by the exchange So that I can exit the chain if something goes wrong

As a plasma operator I can verify the settlements are correct So that I can block invalid transactions to the network.

Notes

boolafish commented 5 years ago

[NOTE]

I've been reviewing our previous proof construction with the MVP requirement doc.

Somethings current proof might be insufficient are:

  1. F2: A trader should be able to cancel an order immediately without incurring a network cost for doing so.
    • the current proof relies on plasma transaction to cancel. So if there's a cost on plasma tx then it might be hard.
  2. F3: An exchange should be able to offer a pricing model that is decoupled from the network costs of using the OMG network
    • I think there are two things here: fee for network and fee for exchange.
    • as they should be decoupled, we might not only need to support settlement to have output to exchange fee address but also, in some case, we might need to let exchange to cover the network fee instead of the user.
    • the current proof design uses all two tx input in settlement already, might need to bind extra tx for fee?

(BTW, this doesn't mean current proof satisfied others already. But I think we need to solve the above first and take care of the remainings)

whoisjeremylam commented 5 years ago

the current proof relies on plasma transaction to cancel. So if there's a cost on plasma tx then it might be hard. Can we separate cancel order which can happen internally in an exchange's order book to cancel and return my funds?

boolafish commented 5 years ago

Can we separate cancel order which can happen internally in an exchange's order book to cancel and return my funds?

Yes and No. The reason for No is that after trader sends the "cancel order", if plasma operator does not know that the order is canceled, it is hard for the operator to block such invalid settlement with the old order.

Probably one way to solve this is exchange need to stake some fund and trader can get the fund back if canceled order ends up being settled by the exchange. (Need to think a bit more, current one issue I can think of is timing, as it's impossible for exchange to promise the staked fund forever, probably exchange can only promise a certain period and trader needs to move their fund back to prevent order abuse)

pdobacz commented 5 years ago

Can we separate cancel order which can happen internally in an exchange's order book to cancel and return my funds?

back at the workshop, in terms of child chain fees, there was this idea to charge only for doing deposits (to an exchange address) and to have settlements and cancels free - basing on a (possibly far reaching) assumption that such deposit-and-settle-or-cancel combo can have a reasonable price tag attached.

whoisjeremylam commented 5 years ago

@ja11sop would you be able to add some of your thoughts with respect to fees?

Please see comments above from @boolafish and @pdobacz .

I also wanted to propose another fee scheme -

Would this work?

boolafish commented 5 years ago

FYI, doc mentioned from Jeremey: Alternative DEX proof

(Sorry, I don't know how confidential the doc is, so again using confluence as reference link)

boolafish commented 5 years ago

Move the main ODEX batch settlement doc here: https://hackmd.io/s/Bk3Sugz9N from #59 . Also, our main notes on the design: here

boolafish commented 5 years ago

From DEX MVP Functional Requirements doc:

F4 & F5 are not related to proof, more about network recovery.

Remaining: F3 is for about decoupling DEX fee and OMG network fee. F7 is for order anonymity. However, probably not the goal of this story as the story here is scoped to provide proof design without order anonymity feature yet.

boolafish commented 5 years ago

We've collected most of the idea/info we need. As we are prioritizing off-chain DEX without operator verification first, I think we can close this. The issue of anonymity of orders would be kept open to keep trace of snark or any alternatives.