search

omgnetwork / research

43 stars 2 forks source link

Reduce risk for fast withdrawal providers by using Plasma MVP #99

Open whoisjeremylam opened 5 years ago

whoisjeremylam commented 5 years ago

A fast withdrawal service provider takes on two risks:

  1. Time value cost where the tokens are locked up
  2. The withdrawer may try themselves to exit the UTXO, double spend etc.

For the latter case, would it make sense if we used Plasma MVP- ie the withdrawer must give a confirm-sig to the fast withdrawal service. This confirm-sig can be used to prove the service can exit the UTXO. As long as the fast withdraw service runs a Watcher and acts on the respective notifications, they will be protected.

If this is possible, this makes it easy for the fast withdraw service to price their service.

boolafish commented 5 years ago

ref: #96

boolafish commented 5 years ago

2/ is not really an issue. If we are using Kelvin’s construction, it will need to send the fund to a contract first. The contract would become the “owner” to exit instead of withdrawer, and the contract itself should be able to prevent double spending.

whoisjeremylam commented 5 years ago

@boolafish what if we don't use Kelvin's construction? There are a few issues with the construction:

  1. The token issued for the right to claim the funds may be a considered a derivative, so the token needs to be listed on a regulated venue
  2. The delivery date and time (block) doesn't fall upon well known dates. What this means is each token has different characteristics, therefore it would be difficult for a market to form for such a token.

In the simple scenerio where OmiseGO or a partner wanted to run a centralised fast withdrawal service, what options do we have to protect the fast withdraw service from the withdrawer?

boolafish commented 5 years ago

@whoisjeremylam

I think we can tweak the construction a bit and do it.

First, the "token" is nothing more than a mapping in the contract to be honest. So let's get rid of the thinking of token and think of it as some data in this contract. So user can exit to contract (or the contract can exit on user's behalf), and the contract would record the withdrawer and the according amount of tokens.

Then we have a function for the withdrawal service provider to send fund here and claim the swap of withdrawer with such fund. I think we can do it two ways, one by the contract itself hardcode some exchange rate, whenever such exchange rate is meet, it enables the swap. Or we verify withdrawer's signature to make sure he/she agrees the swap with such amount. There would be another mapping on the funds withdrawer can withdraw. After the swap, it would record the fund there.

At anytime, withdrawer can ask for withdraw on the amount of fund recorded in the above mapping.

Also, in worth case, if nobody is willing to provide the service, the user should be able to withdraw from this contract after the exit processed. [edit: it can possibly be done by checking "isFinalized" mapping of the vault with output_id]

How do you think about the above proposal?

boolafish commented 5 years ago

Alternative proposed by Karl is to do atomic swap on eth and plasma: link

This comes from the idea to swap with people who wants to deposit.