Fast Finality Predicate

[syuhei176]

original fast finality idea is from https://github.com/omisego/research/issues/29.

I suppose that Fast Finality contract, which we develop for plasma-chamber can be implemented for the predicate.

Any buyer can pay for a merchant in instant finality without channel between the buyer and merchant.

Setup collateral

1. operator has a range
2. operator lock the range for certain merchant by ff-predicate state

Payment

1. a buyer transfer a range to the merchant.
2. operator also sign this transfer transaction.(promise for inclusion)
3. merchant receives a payment by instant finality.

Disputation

merchant can dispute for getting money from collateral.

1. merchant can dispute by non-inclusion of transfer transaction which operator has signed
2. The operator can challenge by showing inclusion
3. Merchant can dispute again, showing double spending.

Code for plasma chamber is here.
I didn’t write the predicate version yet.

[ben-chain]

Awesome, it definitely seems like you can do this with a predicate! One way I’ve been imagining this recently (a similar mechanism is also used in NOCUST) is that basically this represents a payment channel between the operator and merchant. The operator is making a conditional payment in the channel which is redeemable by the merchant if the payment is not included.

Do you think that it requires a signature from the merchant to unlock the collateral and use with another merchant? My intuition is that it does, but maybe there is a way to avoid this if all the conditional payments have been revoked.

Another question is, what is the purpose of step 3) in the dispute process? What is a double spend if the collateral is already locked to a specific merchant?

[syuhei176]

Thank you for replying!

One way I’ve been imagining this recently (a similar mechanism is also used in NOCUST) is that basically this represents a payment channel between the operator and merchant. The operator is making a conditional payment in the channel which is redeemable by the merchant if the payment is not included.

It seems almost same scheme

Do you think that it requires a signature from the merchant to unlock the collateral and use with another merchant? My intuition is that it does, but maybe there is a way to avoid this if all the conditional payments have been revoked.

Do you mean the expiration date of the collateral? I think operator and merchant agree on the expiration date of the collateral first. And I guess the expiration date is enough long, the collateral can be unlocked securely after expired without merchant’s signature. But I’m not sure yet.

Another question is, what is the purpose of step 3) in the dispute process? What is a double spend if the collateral is already locked to a specific merchant?

Sorry, It may be invalid history rather than double spending.
There are 2 ranges. And range B isn’t locked.

• The range A which is locked by operator and merchant.(collateral of operator)
• The range B which buyer transfer to merchant.(payment of buyer to merchant)

In dispute process, merchant show non-inclusion of the payment in range B. And if B is already included, operator can challenge by showing inclusion of B. But if range B has invalid history, second disputation will be occurred.
Merchant should show the payment they receive is invalid.
Merchant know there are no invalid history before block 1.

block 1                2                 3
     Buyer ->                          Merchant  : normal case
     Buyer -> malicious operator -x>   Merchant  : invalid case

In chamber spec, merchant can prove double spending showing the transaction to “malicious operator” in block 2. hmm, I should think how merchant show the payment is invalid in predicate. Maybe operator should sign the payment, and this signature should represents the promise of not only inclusion in block 3 but also non-inclusion of blocks between 1 and 3.

[ben-chain]

Okay, that makes sense! I like thinking of double spends as just invalid history, since the first spend makes the second one’s history be invalid There is one attack I would be worried about which I’m curious if you’ve considered–this is something we’ve been thinking about a lot for atomic swaps:

There is a danger that the operator includes the buyer transaction, with a valid history, but withholds the buyer transaction. Then, they create an invalid block later than the buyer transaction, and begin an exit from the invalid state. Because the buyer transaction has a valid history, it would pass the collateral exit game and return the money to the operator–but, by the time the merchant sees this and knows the buyer transaction is valid, the operator’s malicious exit from the later block may be finalized, stealing both ranges.

This is an issue for trading/DEX predicates as well, where the trading predicate does not want to specify the range it swaps with in advance because the trader is waiting for any other user to agree to the other side of the exchange.

Our solution, which can probably apply here as well, has been to completely reuse the exit game of the main plasma contract for the collateral dispute. In this model, if the merchant exits the collateral, the way for the operator to deprecate the exit is for them to exit the buyer payment on the merchant’s behalf. So, if the merchant exits the collateral, the function call which the operator makes to deprecate the merchant’s exit contains a sub-call to finalizeExit on the buyer’s payment. This guarantees the merchant absolutely that they will either get the collateral exit, or get the buyer payment exit.

Does this make sense? I like it because it is easier to reason about safety–the only way to cancel the merchant withdrawal is to finalize the buyer payment exit. Further, it makes the predicate simpler, since it may simply call finalizeExit instead of having its own custom logic for determining the validity of the payment.

One concern I would have is that if the payments are very small, it might not be worth the gas to play out. In that case, it may be better to use channels entirely (e.g. the plasma debit predicate).

[syuhei176]

Does this make sense? I like it because it is easier to reason about safety–the only way to cancel the merchant withdrawal is to finalize the buyer payment exit. Further, it makes the predicate simpler, since it may simply call finalizeExit instead of having its own custom logic for determining the validity of the payment.

That’s really make sense for me. Thank you for explanation!

One concern I would have is that if the payments are very small, it might not be worth the gas to play out. In that case, it may be better to use channels entirely (e.g. the plasma debit predicate).

Yes, I understood it like this.
In above simple scheme, the cost to deprecate becomes a bit expensive than the predicate which has complex exit-logic. But very very simple and obviously safe. So, this has trade-off between complex logic and the cost to deprecate.

I can update dispute logic using finalizeExit.

Disputation(Updated)

merchant can dispute for getting money from collateral.

1. merchant can dispute by non-inclusion(possibility) of buyer payment which operator has signed
2. The operator can challenge merchant’s dispute by 2 ways below.

• operator can challenge showing correct deprecation of the buyer payment
• operator can challenge with successful finalizeExit of buyer payment