Recourse for MVP1

[boolafish]

Why

In MVP1, we rely on "trade verifier" to be our trust oracle. Two question/problems are:

1. Who is gonna be our trade verifier?
2. What value does OmiseGo network provide here? As when venue and trade verifier got hacked, custody is lost.
   • We still provide some value via Accountability, however, security-wise do we enhance anything?

Goal

1. Find and list potential "recourse" we could have from the network to provide value.

[boolafish]

Idea1: TrueBit style challenge

Pepesza has the idea of using truebit for the fraud proof. By using truebit, you basically put the computation on chain when game starts, but instead of running all n steps, you run with log(n) complexity to challenge the computation. Whenever a settlement tx is mined, traders must start the challenge immediately if anything seems wrong to them. The truebit game would have some short period eg. 1 hour. Once timeout, it is considered finalized to the result of the game. This means operator can only mine next settlement tx after the truebit game period.

Some obvious cons:

1. complexity, truebit game is pretty complex
2. next settlement tx need to wait a certain period to be able to be mined, this might limit what we can support on the style of trading

[edit: there is a tool solEVM, might be useful for this.]

[boolafish]

Idea2: Provision capacity

We allow venue to setup the max capacity of funds transferring per period of time. This mitigates the max amount of money could be stollen when both venue and trade verifier got hacked. Potentially each exchange would have some emergency fund so it would be more promised to be coverable.

[boolafish]

Idea3: Check trader sign off output (in order)

Network check there exists some message from the trader that sign-off the output (usually in order). It does not need to check order detail like price and amount. This make sure trader can at most lost the fund he sign-off and not settled yet. So it's like limited custody design.

One issue of this is that this makes owner obfuscation only exists for a short period of time. Whenever consumed, it will be revealed.

Pepesza further gives the idea of combining truebit concept here. If so, then it does not need to be revealed unless game starts. Guess we can have some short challenge period for trader to game the fraud proof for this. I guess it can potentially game all chained tx in one block together. Next chained tx must wait certain gaming time period. (Might be fine?)

[boolafish]

Idea4: Slash bond or Insurance contract

Venue provide a contract with some fund inside. When a fraud settlement proven with that contract, the bond would be either slashed or return to user as recovery (insurance).

We could possibly has some fancy setup like the venue's fee would have some percentage going to this contract until certain MAX value of contract. This would works well with idea2 I guess.

[slavamirovsky]

Thanks for sharing all that.

Idea1: TrueBit style challenge -> seems to be more difficult than SNARKs ;) Idea2: Provision capacity -> doesn't really sound like a flexible solution Idea3: Check trader sign off output (in order) -> I would like to learn more Idea4: Slash bond or Insurance contract -> this would be sth fancy, but at the end of a day we are not securing funds here, just ensuring that there is ongoing "cash flow" available.

Let's discuss them today.

[boolafish]

An naive implementation on idea3: (If privacy is not an issue)

When trader submits an order, it would have both info of the output_id and signature that signs the output_id.

Order: {
    utxo_info: {
        output_id: xxx,
        signature: xxx,
    },
   ..... // other fields
}

Venue put the utxo_info as part of witness data in the transaction. Operator and watcher would verify that. ExitGame contract would check this data during challenge an output is used.

Basically nothing changes as the UX experience.

cc. @whoisjeremylam @kasima @Nikodemek18

[slavamirovsky]

Ok, cool. How the operator (OmiseGO) can check it? Not sure I understand how the verification itself should look like. Also what do we wanna verify? A) if there is data at all? B) correctness?

[boolafish]

 utxo_info: {
    output_id: xxx,
    signature: xxx,
}

For all tx inputs, this data would be as part of settlement transaction as witness. And the operator would block the settlement tx if the signature does not match the output_id and the trader address from the tx input.

[slavamirovsky]

Ok, so my understanding this is both: A and B. Cool beans!

[boolafish]

Idea5: Proving Trader's wiliness in shorter challenge period

This comes from the idea of truebit's challenge period different with Plasma plus the fact that to prove a trader's wiliness is actually easy.

For example, with limit order, we can challenge by asking disclose the input and output used in the order, it can be a one step computation. Probably it would need to be two steps due to invalid output of tx. So, user challenges the input and venue must respond with order data + output.

What is hard is to prove exchange's rule, like pricing algorithm. This needs to gather all order data to prove. Then in MVP1 that would basically be something we need to get from the trade verifier. (Or to use idea 1 to make it log(n) with truebit)

Confirm "predicate" for chained tx

Since this is from the idea of truebit that introduce a second type of period for challenge, how the txs can be connected and used is a question. In previous chained construction, it relies on a "confirm sig" to prove the input usable. Probably we can use a separate predicate contract instead of confirm sig for here. The predicate would only returns true when:

1. challenge period has passed
2. venue submits confirm sig of the block
3. no challenge succeed within the challenge period (if any challenge of a tx failed, all fails)

How does the new challenge period impact the settlement?

For batch settlement, if the batch time is long enough (eg. an hour?), that means there would only have one tx per batch time. Then we can take any time shorter than the batch settlement time (eg. 30min?) to be as the truebit challenge period.

For continuous trading or short batch settlement time, venue can chain all settlement txs and settles only, let's say per hour. This would need to work with the idea of "confirm predicate" or any alternative setup.

[boolafish]

[Side Note] In today's call, Because it is expensive to verify signature in snark, so we probably still beed to do sth similar to Idea3 in snark version actually.

[slavamirovsky]

Ok, not sure I understand the side note. Would it be possible for you to say that again? Maybe some more details?

I understood: a) we need more time for snarks, b) we suggest to go for idea 3.

Is that correct?

[boolafish]

ah....I am just saying that might be something we need anyway no matter where we go. This might influence decision on how we do it.

[slavamirovsky]

Clear. Ok.

[boolafish]

We've decided to mover forward Snark. see: https://github.com/omisego/research/issues/76#issuecomment-505693887 and
https://github.com/omisego/research/issues/87