Plasma Debit: Arbitrary-denomination payments in Plasma Cash

[gakonst]

Not sure if I fully understood your question, could you rephrase?

The main difference here is that each coin can be considered as a payment channel between the operator and the owner of the coin

[suenchunhui]

Hi @danrobinson,
Thanks for the proposal. Just wondering if instead of having the operator provide liquidity, we have an new type of ‘empty’ deposit where a new token is created on root and plasma chain, with a=0 and v=(some defined max value). So, that we allow recipient users to potentially receive transaction in plasma, for a generalized value transfer network?

[danrobinson]

@suenchunhui

Thanks for the proposal. Just wondering if instead of having the operator provide liquidity, we have an new type of ‘empty’ deposit where a new token is created on root and plasma chain, with a=0 and v=(some defined max value). So, that we allow recipient users to potentially receive transaction in plasma, for a generalized value transfer network?

For each slot, v needs to be the total amount deposited into that slot on-chain (otherwise, if you received that token with some positive a and then tried to withdraw it, what money would you receive? The Plasma chain would be operating at a fractional reserve). So this would require the operator to deposit that amount of liquidity into that token, so it doesn’t get around the requirement that the operator provide liquidity.

[DZack]

@sourabhniyogi

So because that “close the Plasma debit coin” transaction is signed and included on MainNet, Bob can be satisfied that it knows the last balance.

This exchange was helpful for me. Another way of framing the conclusion:

The transfer of a Plasma Debit Coin requires the mutual consent of both Alice and the Operator (Alice needs to sign it, Operator needs to include it in the block). Since it requires mutual consent, we can ensure that it settles on its latest state using state channel-style logic in the case that either party withholds consent; i.e., Alice can always exit her coin and then settle with her latest state, or Operator can withdraw v-a onto the chain.

[DZack]

@sdtsui

From my point of view, the advantage of this construction being able to (eventually, I suppose after everything is thought through) accept new participants to the plasma debit chain without an on-chain transaction. It otherwise is very similar to multi party state channels.

There’s another advantage Plasma Debit has over a single hub payment channel construction — in short, smaller lockup requirement for the operator:

In a payment channel hub, the total value available for all of the users to transact with can never exceed the amount of liquidity the operator has provided; this is a hefty lockup requirement.

In the extreme case for Plasma Debit, the operator can provide this same 1:1 liquidity, but they can also potentially still facilitate fungible payments between users with a smaller capital lockup; this is possible to the extent that can users make payments via full coin transfers as opposed to debit-channel payments.

Some simple optimizations can encourage the likelihood of such payments being possible. For example, we can “encourage” debit coins to be deposited in base-two denominations, i.e., a single 16 ETH coin requires a full 16 ETH of operator collateral for full fungibility, whereas if we instead have coins of values 8, 4, 2, 1, 1, this requires only 1 ETH of operator collateral (against one of the 1 ETH coins) for full fungibility (this assumes we can combine transfers of multiple coins and debit payments atomically).

As coins start moving around, if a user requires fungibility that they don’t have available, the operator, who has a global view of the network, can find opportunities to ask users for parity atomic swaps (trade a 4 ETH coin for 4 1 ETH coins, say) to help out. A more interesting (but trickier) functionality would be “involuntary parity atomic swaps”, i.e., same as above, but without either user’s permission. Not sure if this has been discussed (though involuntary defragmentation is described here: Plasma Cash defragmentation, take 2); but I can’t figure out a simple way of doing this without reintroducing mass exit vulnerabilities (basically, at any point your coin can suddenly be in-flight, so you can’t tell if some arbitrary is actually rightfully yours).