Plasma Design Comparison
 Share
The version of the browser you are using is no longer supported. Please upgrade to a supported browser.Dismiss

 
Comment only
 
 
ABCDE
1
2
Plasma DesignPlasma MVP (& MoreVP)Plasma Cash (& XT)Plasma Debit
3
Composition
4
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 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
5
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
6
Features
7
DepositsValue 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)
8
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
9
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 transfered
10
SignaturesMVP: 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 griefingNo confirmation signatures
11
Exits/Withdrawals-Proof of unspent UTXO required to exit, confirmation signatures required for MVP
MVP: exit priority based on priority on Plasma, 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
12
BondsMVP: Exit bond MoreVP: Exit bond and piggyback bond (for in-flight transactions if chain is byzantine, without confirmation signatures-Exit bond -Exit bond
13
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)
14
Proofs RequiredState Updates: proofs of UTXO ownership, state transitions and block inclusion Challenges: proof of spent UTXO, lack of signatures or no block inclusionState Updates: proofs of coin ownership, past transfers and 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 Challenges: proof of spent coins, lack of signatures or no block inclusionState Updates: proofs of coin ownership, past transfers and 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 Challenges: proof of spent coins, lack of signatures or no block inclusion
15
Other FeaturesMoreVP: omitting confirmation signatures for user experience introduces increased complexity if chain is byzantine (e.g., block witholding) putting in-flight transactions at risk, solved by requiring an exit bondCash: 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
16
Utility
17
ProsMVP: 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)
18
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 witholds 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
19
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 -Gaming -Asset management (real estate, art, securities)-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)
20
Research
21
ethresear.chPlasma (All)
22
learnplasma.orgPlasma MVPPlasma CashPlasma Debit
23
Example GithubPlasma MVP (OmiseGO)Plasma Cash (Loom Network)
24
Loading...
Main menu