Plasma Cash: Plasma with much less per-user data checking

It looks to me that Plasma Cash (similar to MVP) is vulnerable to a self-transfer-then-exit vulnerability.

If Alice has a coin and she transfers it to herself 1000 times, and then she cooperates with the Plasma operator, she seems to be able to exit intermediate UTXOs without a challenge, since only she will be possessing the fraud proofs.

I wonder if it has been addressed anywhere ? In my understanding users are not supposed to store unrelated transactions, so it seems that if Alice sends money to herself, then no one will have proofs because no one will care to save the proofs for these transactions.

In plasma cash the coin id does not change between transactions, and the plasma contract enforces that every coin can only be withdrawn once

Thank you - what about exiting once then ? What does prevent Alice to exit one of intermediate self-payment transactions (lets supposed the coin is now owned by Bob.

May be one needs to amended exit procedure so that it accepts as a fraud proof any future transaction involving the coinid? (not just the subsequent one?)

The exit game as written here only lets you cancel an exit by showing a “direct” spend of the exiting coin; if you modify the game to allow cancelling an exit by showing any future spend of that coin (and don’t change anything else), the construction becomes broken

The exit game here is secure because there is a client rule that a coin owner should be aware of (have inclusion proofs of) all transactions involving the coin, so that whatever intermediate payment Alice tries to exit, Bob knows how to cancel it

I think this system needs to be modified so that the user explicitly burns the coin before exiting it and provides proof of burn

The current mechanism seems to be incredibly computationally consuming. How can I use a system where for each 1c coin I got, I need to check a linearly increasing set of Merkle proofs. If I am paid a $0.01 coin and then I have to first to dowload megabytes of Merkle proofs and then keep on monitoring it forever, how viable is this solution?

If I have $10 as 1000 coins 1c each, the amount of dowload, storage, verification and monitoring I need to do seems overwhelmingly huge and growing linearly with time.

Explicit burn proof solves all these issues, you simply do not need to store anything

The linearly increasing set of proofs for 1 coin is indeed a downside. Note that there are some mitigations like Plasma XT: Plasma Cash with much less per-user data checking.

If you have a design that modifies plasma cash with “proof of burn” that solves this problem, feel free to create a separate post (I feel like this one is getting long) and I can look at it

Xuanji - I will, thank you

An alternative way to accomplish this might be for the operator to construct a merkle tree T committing to the number of times every coinid has been spent since the genesis plasma block, and to use snarks to verify the integrity of the root hash of the tree. Then a client checking the validity of a coin can download the witness for the branch of this tree that tells him that his coin has been spent h times, and then download h inclusion proofs.

For clarity, an example of this is shown below for 2-bit coinids. The top row shows the transactions in each block, and the bottom shows T after those transactions have been applied.

This has the advantage that the prover only needs to construct one proof per plasma block (I’m not sure what the prover burden is for the scheme where a snark is constructed for each coin).

We can also place the verification on-chain, for instance both the transaction root and T would be placed on-chain for every plasma block, and the plasma contract verifies a proof that T was correctly computed. @JustinDrake points out that this is a case where we can use cryptoeconomic verification, i.e., the operator just places the proof on-chain and makes a bonded claim that the proof will verify, and anyone can collect the bond by paying the gas cost to refute the validator.

Also, we can include T once every n blocks, and just force clients to download the (at most n) exclusion proofs for the blocks that were included after the last time T was included.

1 Like

This is very interesting. Is it possible to put this “# of time spent” into the UTXO itself (avoid having a separate tree and increase the block header size)? Meaning the output of the signed tx now is an object.

[blknum1, txindex1, oindex1, sig1,       # Input 1
 blknum2, txindex2, oindex2, sig2,       # Input 2
 newowner1, denom1, #spent1 +1           # Output 1
 newowner2, denom2, #spent2 +1           # Output 2

Ah yes, that might be better. Then the snark can prove that # of times spent is nondecreasing.

Plasma cash doesn’t have the two inputs and two outputs scheme you pasted, though.

True, but still, I think it’s possible to have leaves in Plasma Tx Tree as an object with affiliated fields . I haven’t thought it through, but possibly we could put a { historical owners => # tx } object for each output. And a possibility from this is when this coin is being exited, root chain will charge historical owners for the number of tx being done on this coin. So that you could imagine over time, as more coin being exited, the tx will be eventually paid out. (assuming constant tx fee for each tx.)


Hello Dan.

After the last Plasma call I really liked your idea of “Plasma Debit” with quasi-channels user <-> owner. I work on the More Viable Plasma in parallel, but do you want to join some forces to make a “debit” prototype? The most interesting problem I see there right now is how to supply initial “empty” coins, so a user can get one and be able to accept the payment. One option is just deposit a full one and “split” it to “completely full” and “completely empty”, but I’d like to about splitting operation entirely and leave only transactions of A <-> operator <-> B type.

Sincerely, Alex

Hello everyone. I want to get a better understanding of the proof used in Plasma. I have a very basic understanding of cryptographic proofs at the moment.

Do any of you know of good resources that can help me catch up to the cryptographic proof conversation?

Thank you.

What proof are you referring to?

Do I understand this correctly: if Bob transfers his coin to someone else and then attempts to fraudulently exit to the root chain, anyone including the operator can challenge the exit and claim the bounty (assuming transaction data is available normally from the operator).

In the implementations I could find, only information similar to this seemed to be required to challenge an already spent exit, all of which I understand should normally be publicly available to all observers:

 function challengeSpent(uint coin_id, uint blk_num, bytes tx1, bytes proof)

So as long as there is at least a single honest observer, users do not realistically have to check the root chain every week since the bounties incentivize third parties to do this monitoring. This would seem like a much more friendly situation for end-users, especially if they have only sporadic access to internet for example. Would this seem correct or am I totally on the wrong track here? :smiley:

Indeed, challenges can be done by any incentivized party that has access to the information required to make the challenges happen.

However, delegating challenges (and/or exits) is not trustless - currently. Essentially, if you give a 0.1 ETH bounty to someone for challenging all exits for your 5 ETH coin, that someone can be bribed by any faulty exitor to not challenge for any amount bigger than the bounty, say 0.2 ETH.

Work on trustless delegated challenges has been done on the state/payment channels end in this paper which may interest you by @stonecoldpat et al in


Interesting. If I got this straight, in the case the attacker tries to exit a coin worth 10 ETH, there is a bounty of 0.1 ETH and 100 observers are watching the chain, to bribe all observers it would then cost > 10 ETH.

So if the bounty is bigger than the value of the coin attacked / N of observers, either observers will not gain anything by accepting the bribe or the attacker will spend more on the bribes than what he stands to gain from the attack.

Thank you for the paper reference also! :slight_smile:

A perspective change that I think is important for Plasma Cash is to abandon the idea that Plasma chain data is public by default. There should probably be nobody other than the operator who is observing the entire chain.

You might voluntarily provide some third party with your coin history every time you spend a coin, so that they can challenge attempted outdated withdrawals. But the operator shouldn’t just make your coin history public unless you told them to.

(I’ll also note that this only covers outdated-coin exits, as you mentioned. The possibility of a malicious operator means that you need to be online once a week anyway, since you might be the only one who knows that an attempted exit was actually a malicious attack by the operator.)

1 Like

If the chain data should not be public henceforth, wouldn’t that massively alter the promised future in the original white paper? That we can have more than one operator, they all agree on a state (optionally with MapReduce delegation to child chains) and the resulted blocks are published on Ethereum to obtain its security? Or is it just Plasma Cash which makes these trade-offs in order to achieve fast and reliable coin transfers?

This is my attempt at making a comprehensive document about Plasma Cash, feedback much appreciated!

Plasma is a framework for scalable off-chain computation. We describe and evaluate Plasma Cash, an improved Plasma construction which leverages non-fungible tokens and Sparse Merkle Trees to reduce the data storage and bandwith requirements for users. We analyze the cryptoeconomic exit and challenge mechanisms used to keep user funds secured, even when the Plasma Cash chain’s consensus algorithm is compromised. A reference implementation is provided for evaluation. Finally, we briefly discuss further improvements that can be made to the Plasma Cash protocol such as arbitrary denomination
payments, less user data checking, fast and optimistic exits.