This is a proposed extension to Plasma Cash, partially inspired by an on-going Twitter discussion about the taxonomy of layer 2 scaling solutions and how they relate to each other, as well as discussions with @kfichter, @vbuterin, @jcp, @karl, and others.

Mechanics

In Plasma Cash, the transaction Merkle tree is divided into slots, each of which stores a fixed denomination of ETH (the amount that was deposited) and tracks a public key. Each transaction in that slot updates the public key currently associated with that coin.

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. v does not change, but a can vary in each transaction, and represents the portion of the current coin that is owned by the owner. The remainder of the money deposited in that slot is owned by the operator. A transaction in which a is changed, like any other transaction, requires a signature from the current coinholder. (The operator does not need to sign the update, since their consent is implied by their inclusion of the transaction.)

When a coin is withdrawn, the coinholder receives a, and the operator receives v – a. (The exit rules need to be altered slightly to allow either the owner or the operator to exit a coin.)

When a coin is initially created, a is equal to v. The operator can increase v (and thus increase their balance held in the coin) by depositing additional ETH into that coin, using a separate operatorTopUp function on the parent chain’s contract.

This would allow users to pay arbitrarily small fees to the operator. (Vitalik proposed almost this exact solution to the fees problem here).

Even more usefully, however, this allows any user on the Plasma Cash chain to pay any amount to any other user on the chain (as long as the recipient’s coin is undercapitalized by a sufficient amount). They can do this by creating an atomic transaction (i.e. a transaction that updates multiple coins and is only valid if it is included in both slots in the same block), where the sender’s account is debited by that amount, and the recipient’s account is credited by that amount.

For example, suppose Alice has an 8 ETH coin with a 4 ETH current balance, and Bob has a 5 ETH coin with a 3 ETH current balance. Alice would be able to send 1.3 ETH to Bob, by creating a transaction where the balance of her coin is reduced to 2.7, and the balance of Bob’s coin is increased to 4.3. The operator will accept and include the transaction (in both Alice’s and Bob’s slots) because it does not change the operator’s total balance (which remains, with respect to those two coins, at 6 ETH).

Theory

The above explanation defined Plasma Debit as Plasma Cash with partial balances.

However, there’s an equivalent way of approaching this construction. Each Plasma Debit coin is essentially equivalent to a bidirectional payment channel (similar to the multisig-based payment channels used in the Lightning Network) between the current coin owner and the operator. The only difference is that the state of the payment channel is regularly notarized on the main chain (in a Merkle root with the operator’s other channels).

This notarization gives Plasma Debit coins two significant capabilities that payment channels do not have:

Assignability. A Plasma Debit coin can be transferred from one owner to another (the same way a Plasma Cash coin can). This is equivalent to allowing one of the participants in a payment channel to permanently assign their interest in that payment channel to some new party, which is not possible with previous payment channel constructions. Most significantly, this allows new parties to join the payment network without doing an on-chain transaction (which is a disadvantage of the Lightning Network). Atomicity. Plasma Debit coins can be updated atomically with other coins on the same Plasma chain, without the need for HTLCs. (There are limbo-exit-like edge cases around data availability that make this slightly less of a win than it seems at first, but it is still potentially powerful.)

Limitations

To receive one of these kinds of transfers, the recipient must have (or receive) a coin that is undercapitalized by at least the amount of the transfer. This is similar to the constraints on Lightning Network channels, where the net balance between yourself and your counterparty is constrained by the balance that was initially deposited into your channel, and may require significant capital lockup (particularly on the part of the operator). However, the assignability of channels should make it easier to work around these limitations.

This simple design only works for Plasma Cash chains with single operators. However, you could implement a more general form of this idea using merged and split coins, as described below, which would not be subject to this limitation.

Extensions