Plasma Debit: Arbitrary-denomination payments in Plasma Cash

Nope. Counterintuitively, in Plasma Debit, when there’s an atomic transaction incrementing slot A and decrementing slot B, you need to validate almost nothing about one slot in order to validate the history of the other slot. (The exception is that if you are trying to validate slot A, then you need to check that the transaction was included in slot B in the same block. But that’s a negligible increase in overhead. (EDITED to correct and rephrase.)) The reasoning behind this is pretty involved, and I’m afraid I haven’t written it up yet, but I think it’s right. (EDITED: written up below.)

1 Like

Re:

So the way I was thinking of composing them doesn’t quite work, but the construction in State Channels and Plasma Cash should be enough. It achieves the assignability and atomicity criterion with the same collateralization requirements, as well as all 4 extensions.

You’re going to have to use hashlocks if you want to cover microtransactions or smaller transactions - I think ecrecover costs ~$10 to use on the main chain right now?

Sure, you could say that the cost could be greatly diminished on plasma, but i would prefer we stick to a standard across all chains :slight_smile:

Can you provide more detail, I’m failing to see how this works given that plasma cash won its scalability from the fact that it was non-fungible. How can this achieve the same property while being fungible?

Paying through payment channels should always not incur ethereum gas fees “in the optimistic case”, since the payment involves just exchanging some messages. In that sense the cost of an ecrecover doesn’t affect the cost of paying through a payment channel. It does affect the kinds of griefing attack one can do through channels, so we would want to optimize it for that situation.

Unless you’re talking about hash locks in some other context?

The only thing I care about is optimizing for griefing - everything else is pretty straightforward, otherwise (imo).

You don’t get perfect fungibility—you get “capped” fungibility. Remember, you can only receive money in a Plasma-Debit-style payment if you have a coin/channel with the operator. Effectively, every incoming payment is actually from the operator, and every outgoing payment is to the operator. These limitations are what allow us to preserve almost all of the per-coin-isolation of Plasma Cash.

Suppose Alice and Bob own coins on a Plasma Debit chain. Alice and Bob are obviously aware of the history of their own coins, and know that they are valid. Bob’s coin has some receiving capacity (i.e., the operator owns some of the balance in that coin).

Alice makes a Plasma Debit payment to Bob. That takes the form of an atomic transaction where Alice pays the operator by decrementing her balance in her coin/channel, and the operator pays Bob by incrementing the balance in Bob’s coin/channel. This transaction is signed by both Alice and Bob. For this transaction, Bob doesn’t care if the history of Alice’s coin is valid! He only cares that his own coin’s history is valid (which he already knows, up to the present), and that the balance in his coin goes up. For this reason, even after this transaction, there is no way for someone to challenge the history of Bob’s coin by showing something invalid in Alice’s coin’s history.

Now suppose you are a later recipient of Bob’s coin, validating its history. You see this transaction where Bob’s balance was incremented—effectively, a payment from the operator to Bob. You shouldn’t (and don’t) have to check anything about Alice’s account (either the validity of its history or even whether the transaction was included in Alice’s slot) to consider this a valid transaction with respect to Bob’s coin, because any malfeasance could only be committed by the operator, and would only hurt the operator.

Next let’s suppose you are a later recipient of Alice’s coin, validating its history. The only thing you need to check is that the transaction was also included in Bob’s slot in the same block. If the history of Bob’s slot is invalid, that’s Bob’s problem! As far as Alice was concerned, she sent him the money.

I’d thought that this requirement would actually need to be more onerous, due to the possibility that the operator could insert an invalid transaction, such as a spend from a prior owner, into Bob’s slot before including this transaction, thus cheating Bob by forcing him to exit from the previous state, where his balance was unincremented. But I just realized that reverting from the exit game that I proposed here to the one initially proposed by Vitalik should address it, because it prevents an exit from being challenged by some non-double-spend invalid transaction inserted between the transaction and its parent.

1 Like

Mostly agree with this, but I don’t see how this implies that the smaller your (marginal) transactions are, the smaller the griefing bounds have to be for safety reasons. I can have a channel with someone where we collectively own 10 eth, and the fee for resolving any dispute is capped at 0.1 eth (assuming I have a bound I believe gas fees are unlikely to go over), and it is perfectly safe for me to update the balance to transfer 0.00001 eth to my counterparty

So, say that Alice and Bob both join the plasma chain and wish to pay one another but have no receiving capacity - what happens here?

I’m still a bit confused as to why the operator by default has some of the balance of Bob’s coin.

“You shouldn’t (and don’t) have to check anything about Alice’s account (either the validity of its history or even whether the transaction was included in Alice’s slot) to consider this a valid transaction with respect to Bob’s coin, because any malfeasance could only be committed by the operator, and would only hurt the operator .”

  • So you’re replacing merkle proofs with trusting the operator here? How would any malfeasance hurt the operator? What are the repercussions for their maliciousness?

Then Alice can’t make a Plasma Debit payment to Bob yet. (She could still make a Plasma Cash payment to him by transferring the entire amount of her channel to him.)

The operator could enable this transaction by depositing some of its own liquidity into Bob’s coin, so that that coin now has some operator-owned balance. (This is different from making a payment to Bob—the operator still owns their ETH, they’re just holding it in that coin, next to Bob’s ETH.) But of course, this does requires the operator to lock up some capital.

The operator is like a Lightning hub. When you open a channel with a Lightning hub, you can’t receive any payments over that channel unless either a) the hub puts some of their own liquidity into that channel, or b) you make some payments through that channel, thus reducing the portion of it that you own and increasing the amount that your counterparty owns, and thus your own receiving capacity.

So enabling Plasma Debit payments requires some liquidity commitment by the operator.

Not by default, just by assumption of the above example. When you initially deposit, you own the entire balance in your coin, until you make a Plasma Debit payment, or the operator commits some of their own capital into the coin. The above example assumed that one of those things had already happened, so Bob already had some receiving capacity.

No, there is no trust requirement.

The reason any malfeasance would hurt the operator is that in the example I was discussing, the malfeasance would basically be “incrementing Bob’s balance without decrementing Alice’s balance,” which is equivalent to “the operator paying Bob, without the operator getting paid by Alice.”

So the repercussions for this misbehavior would be that Bob still gets paid, but the operator is the one bearing the cost of the payment, rather than Alice.

1 Like

How could the operator deposit liquidity into Bob’s coin if Bob has no receiving capacity and ergo could not receive from Alice?

So if the lightning hub requires liquidity on the part of the operator - the operator will need to have coin(s) as well as receiving capacity. This is fine in the case of plasma cash, because we can reassign owners, but if the operator, bob, and alice have all just started on this plasma chain, how can they free up any space to be able to receive?

Here’s what you stated in the initial post:

In Plasma Debit, each slot would track not only a public key, but a number a between 0 and v , where v is the total amount of ETH that was deposited into that account on the main chain.

Alright, so everyone has deposited and can’t exceed their deposit amount in that slot. So how do they free up any space?

tl;dr - This design starts in a deadlock and I don’t see a way for it to break out of it.

The operator can deposit into any coin from the main chain, which increments v but not a. So if Bob has a 5 ETH coin and a current balance of 5 ETH (i.e. v is 5 and a is 5), then the operator can deposit 1 ETH into the coin, making it a 6 ETH coin where Bob has a balance of 5 ETH (i.e. v is 6 and a is 5), which gives the operator an implied balance of 1 ETH.

(Apologies, I see that this mechanism wasn’t mentioned in the original post. I will edit it to add that.)

I should make clear that the operator does not need any receiving capacity to receive a Plasma Debit payment. Any coinholder can pay the operator any amount simply by signing a transaction that decrements a for their coin. This is an another way that the bootstrap problem can be avoided—when any user makes a Plasma Debit payment to the operator, their coin becomes undercapitalized, allowing them to receive Plasma Debit payments.

3 Likes

So everyone’s collective balance is stored in percentages of coins in slots in the merkle tree - except for the operator.

  1. Where is the operator’s running balance stored?
  2. If I send something to the operator, they can’t withdraw on the main chain?
  3. I assume the operator has to put up some stake or bond as well, no?
  4. What if I send something to the operator - how do I get it back in the case I want to withdraw from the main chain?
1 Like

Well not percentages, balances. And theirs is too, it’s just inverted.

  1. Where is the operator’s running balance stored?

It’s not stored in any one place. It’s just the sum of v - a across every coin on the Plasma chain.

  1. If I send something to the operator, they can’t withdraw on the main chain?

They can. See the original post: “When a coin is withdrawn, the coinholder receives a , and the operator receives va . (The exit rules need to be altered slightly to allow either the owner or the operator to exit a coin.)”

  1. I assume the operator has to put up some stake or bond as well, no?

No, not necessarily. At least, nothing depends on that.

  1. What if I send something to the operator - how do I get it back in the case I want to withdraw from the main chain?

Could you please clarify? If you make a payment to the operator, you can’t get it back.

To all those following, we’re elected to take this discussion offline to avoid further flooding, here. :slight_smile:

We are more so referring to the cost of closing a channel in the happy case. Assuming that you are checking the signatures of state being passed into close a channel. https://github.com/counterfactual/research/blob/master/mc-multisig/multisig.sol#L46

Ecrecover is certainly painful in dispute cases but can also be in consensus if your channel is only running very low micropayments. However this is probably why we introduced more complex off-chain systems so that transaction value is worth the eventual close out fee.

There are ways to engineer around this and use the ecrecover from the msg.sender, but this would limit the calling parties to only the participants of the channel and possible expose a griefing issue.

I don’t think you have to check any signatures, or even Merkle proofs, in the happy exit case. See Optimistic cheap multi-exit for Plasma (Cash or MVP)

1 Like

I’m sorry I may have pulled this thread a bit off topic into state-channels land with the “quick” finality exit where the main-chain can require consensus from N parties in the channel by checking the signatures. So to pull off the “fast” exit in a state-channel we seem to hit this cost requirement.

If you are willing to wait then it is cool how you can aggregate the sigs under one exit and only check them if incorrect (i think that’s correct if i understand the plasma optimistic exit)

Ah, I see, right. In Plasma Debit, there is never an option for immediate exit anyway (since the “channels” are assignable, so until the challenge period is over you don’t know who has authority to sign off on the exit).

How would you check that participants want to close a channel, without using ecrecover (including the implicit ecrecover in msg.sender)?

I don’t know of a good way and see these costs as a potential issue to deal with for all layer2 systems, but using msg.sender instead of raw signatures would be like going back to using the old gnosis msig where each party called the tx independently, where state was “preloaded” and agreed to by the calls made by msig owners. This way you wouldn’t have to check the signatures with ecrecover but it’s slower.

EDIT: STK just released their channel code and use what seems to be a “cheap” channel exit doing the above description here. Again this limits exits to the parties involved in the channel.