Compare

Learn about the differences between the most popular plasma design applications.

#Compare

Plasma DesignPlasma MVPPlasma CashPlasma 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
ConsensusAny 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.chPlasma (All)
    learnplasma.orgPlasma MVPPlasma CashPlasma Debit
    GitHubPlasma MVP (OmiseGO)Plasma Cash (Loom Network)