Plasma Debit, Simplified
This is my attempt at the simplest explanation of Plasma Debit, as it was proposed by Dan Robinson.
What is it?
Plasma Debit is an extension of Plasma Cash, a second-layer on top of Ethereum that allows for fast payments with non-fungible tokens (like exchanging physical coins). The difference being that Plasma Debit allows for arbitrarily-sized payments between different Ethereum addresses (like a debit card). It can aptly be compared to the lightning network with the only real difference being that it is regularly notarized to the main chain (in a Merkle root with the operator’s other channels).
Note: At present, the Plasma chain is facilitated by an ‘operator’ (a single validator) in a Proof of Authority network who supplies all of the liquidity for the Plasma chain.
Why does it matter?
Plasma Debit matters because it allows for cheap payments as well as micro-transactions on the Ethereum network with very little work needed to validate them.
Joining the Network
In order to join the network, you must either make an on-chain deposit or have an existing deposit transferred to you — this can be facilitated with a smart contract which performs a mapping between addresses and account balances. After having made your initial deposit, an account will be automatically generated and assigned to you. This account will correlate to a slot in the transaction merkle tree will be assigned your public key / address. This slot serves more or less as a bidirectional payment channel between you and the operator.
Accounts
Within each account, there is a maximum value that it can hold v and the current value a. You can think of a being the amount which you can withdraw to the main chain and v being the total amount bonded to your slot.
struct Balance {
uint256 bonded;
uint256 withdrawable;
}mapping (address => Balance) public balances;
So, immediately after joining the network, you will be unable to receive any payments because a = v. This is problematic, because everyone initially has a=v, which would lead to a deadlock of the system if not for the operator.
The Operator / Transacting
The operator of the network serves to provide liquidity and notarize transactions from the plasma chain to the root chain. If you were to sum the difference of v and a in every slot in the transaction merkle tree, it would amount to the total amount of liquidity put into the network by the operator. So, if you want to accept a transaction for 2 ETH after joining with 5 ETH deposited (a, v= 5), you will need to do one of the following:
- Send 2 ETH to someone who has an account where (v-a ≥ 2)
- Ask the operator to provide liquidity and raise your v to 7.
The former is a simple change of two of the slots in the merkle tree while the latter involves the operator providing liquidity to your account with an on-chain deposit (this would only effect one slot in the merkle tree).
After having 2 ETH deposited on-chain into your account, you will have a=5, v=7. This will allow you to accept 2 ETH, which will allow the sender of that 2 ETH to also accept 2 ETH. So, the total value that can be transacted in the network at any time is the total amount of liquidity that the operator has provided to all accounts.
Here is an example of the sort of data that would be held by the transaction merkle tree (for those interested) :
Fee Structure
The operator can set their own fees for the network for providing liquidity and updating account balances. There will likely be multiple operators offering the same services, so price will be driven through competition / demand.
Exiting / Settling
Members of the plasma chain can choose to exit / settle at any time to the main chain. This will send the updated account balance to the member and return all additional liquidity to the operator.
The operator can also choose to settle his / her lent out ETH from various accounts or exit completely at any time. Naturally, without an operator present, the plasma chain will cease to exist and those participating will need to exit as well. Operators are disincentivized from doing this as it would preclude them from collecting more transaction fees.
Benefits
Assignability
Something that was not noted in here is the fact that you can transfer an entire account to another address. This is roughly equivalent to transferring an open payment channel to another party and functions in the same way as Plasma Cash.
Improvements
Multiple Counterparties
Having a single operator leaves this model open to unprovable censorship of transactions (because there is only one validator of the merkle tree). This also limits the amount of liquidity that can be transacted in the network to whatever that one operator can provide.
Further Reading
Thank you, Dan Robinson, for your feedback!
