Compare [ Learn Plasma ]

#Compare

Plasma Design	Plasma MVP	Plasma Cash	Plasma Debit
Composition
Block Data Structure	Binary Merkle tree Block proposers create blocks(e.g Operator in PoA)	Sparse Merkle tree with ‘slots’ (representing each coin or user’s unique deposit) Each block has a ‘slot’ for each coin (unique deposit) When a coin is spent, transaction proof is recorded in that coin’s respective slot in the block	Sparse Merkle tree with ‘slots’ (representing each coin or user’s unique deposit) Each block has a ‘slot’ for each coin (unique deposit) When coin is spent, transaction proof is recorded in that coin’s respective slot in the block Unlike Plasma Cash, coin also acts a payment channel where the operator acts as a hub
Consensus	Any consensus (e.g., PoW, PoA, PoS)	Any consensus (e.g., PoW, PoA, PoS)	Single or few operators preferred over many because of payment channel structure
Features
Deposits	Value Representation: UTXOs MVP: ETH, ERC20 support possible MoreVP: ETH, ERC20 support possible	Value Representation: Unique coin IDs for each deposit (e.g., 1ETH deposit = (1ETH) NFT coin) NFTs only (FTs unscalable as merging/splitting creates large Merkle roots for small denominations) Pending coin defragmentation research to support FTs	Value Representation: Accounts with unique coin IDs for each deposit NFTs and FTs (Debit is similar to Cash but allows fractions of tokens as coins represent payment channels not deposits themselves)
Transactions	Users spend UTXOs to create new outputs UTXO transfers in any denomination	Users spend coin IDs to create new outputs Coins non-divisible, merging/splitting difficult to implement	Between account/coin owner and chain operator Coins non-divisible, no merging or splitting Users have payment channels with operators, in the form of coins New users who don’t have a payment channel are provided a channel by the operator to facilitate transactions
Fees	Users pay plasma transaction fees to validators and gas fees when exiting/withdrawing to rootchain or other chains	Users pay plasma transaction fees to validators and gas fees when exiting/withdrawing to rootchain or other chains	Users pay via operator-led payment channel instead of directly to other users, operator subtracts transaction fees from value being transferred
Signatures	MVP: Transaction signature before block inclusion, confirmation signature post-inclusion; signatures must be sent to operator (PoA) MoreVP: Transaction signature only, no confirmation signatures	Confirmation signatures to avoid griefing	No confirmation signatures
Exits/Withdrawals	Proof of unspent UTXO required to exit, confirmation signatures required for MVP MVP: Exit priority based on priority, older UTXOs have priority MoreVP: Exit priority based on youngest input of exit txn, as long as input is from valid txn	Proof of coin’s latest two transactions, proof of block inclusion No exit priority	Proof of coin’s latest two transactions, proof that fraction of coin hasn’t been previously spent proof of block inclusion No exit priority
Bonds	MVP: Exit bond MoreVP: Exit bond and piggyback bond (for in-flight transactions if chain is byzantine, without confirmation signatures	Exit bond	Exit bond
Challenges	Challenge by submitting proofs of spent UTXO Challenger puts up bond against their challenge Challenge period est. 7-14 days (limited by capacity if each exit in a mass exit was challenged)	Challenge by submitting proofs of spent coin, proofs of invalid spending between latest two transactions or proofs of some other invalid transaction in coin’s history Challenger puts up bond against their challenge Challenge period est. 7-14 days (limited by capacity if each exit in a mass exit was challenged)	Challenge by submitting proofs of spent coin, proofs of invalid spending between latest two transactions or proofs of some other invalid transaction in coin’s history Challenger puts up bond against their challenge Challenge period est. 7-14 days (limited by capacity if each exit in a mass exit was challenged)
Proofs Required	State Updates: Proofs of UTXO ownership, state transitions and block inclusion Challenges: Proof of spent UTXO, lack of signatures or no block inclusion	State Updates: Proofs of coin ownership, past transfers and block inclusion Challenges: Proof of spent coins, lack of signatures or no block inclusion Enables much less per-user data checking as users only need to keep track of their own coins Proofs are also passed onto other users and only proofs of spent coins need to be included in blocks	State Updates: Proofs of coin ownership, past transfers and block inclusion Challenges: Proof of spent coins, lack of signatures or no block inclusion Enables much less per-user data checking as users only need to keep track of their own coins Proofs are also passed onto other users and only proofs of spent coins need to be included in blocks
Other Features	MoreVP: Omitting confirmation signatures for user experience introduces increased complexity if chain is byzantine (e.g., block withholding) putting in-flight transactions at risk, solved by requiring an exit bond	Cash: Coins have automatic proof of exclusion if they are not included in block XT: Addition of checkpointing to the rootchain to reduce size of Merkle root per coin, thus limiting storage/computation requirements per chain	Resembles a large ‘Lightning Hub’ on a plasma chain Users hold payment channels with operator alone (not other users) Operators create many channels in advance to ensure new users can transact with existing users
Utility
Pros	MVP: Scalable, all signatures sent to operator in PoA MoreVP: Scalable and more trustless than MVP High fungibility	Very scalable, watchers or users themselves need to only keep track of their own coins not all coins on the chain	Very scalable, watchers or users themselves need to only keep track of their own coins Enables transactions with NFTs and FTs Efficient balance updates don’t need to be included in blocks as agreement can be made between operator and coinholder (similar to channels)
Cons	Watchers or users themselves are required to watch and challenge invalid exits Transaction bonding creates poor UX . Potential for honest bond slashing if operator withholds blocks and user attempts to re-submit transaction (once operator begins creating blocks again, the 2nd transaction will be ‘invalid’)	Watchers or users themselves need to watch and challenge invalid transactions with their own coins, (vigilance is necessary, may be poor UX) Coins are in fixed denomination (no splitting/merging) Coin proofs can be massive (must prove all the way back to block where coin was created) Transaction bonding creates poor UX	Heavy reliance on operator, can be hedged by creating a set of rotating operators Coin proofs can be massive (must prove all the way back to block where coin was created) Requires operator to lock up significant funds in advance to fund payment channels Transaction size constrained by initial coin deposit size (similar to lightning/payment channels) Enabling decentralized exchange on Debit is non-trivial Payment channels can create UX challenges
Use Cases	Transactions of NFTs or FTs Low-trust use cases (PoA) Exchanges, capital markets trading, securities P2P payments, remittances, recurring/bill payments Loyalty/rewards, gaming	Transactions of NFTs only (collectibles, data tokens etc); pending coin defragmentation research to support FTs Asset management (real estate, art, securities) Gaming	Transactions of NFTs or FTs Use cases with high-trust of operators, ewallet or service providers Prepaid or wallet top-up payments P2P payments, remittances, recurring/bill payments Loyalty/rewards, gaming Asset management (real estate, art, securities)
Resources
ethresear.ch	Plasma (All)
learnplasma.org	Plasma MVP	Plasma Cash	Plasma Debit
GitHub	Plasma MVP (OmiseGO)	Plasma Cash (Loom Network)