After this proof has been submitted, anyone can challenge that the person exiting is not the truthful owner. A successful challenge will steal the bond of the person exiting as a reward for correctly challenging the exit. This challenge happens on-chain on the main chain. This challenge remains open for selected period of time (say 2 weeks).

There are 3 scenarios in which someone can fraudulently attempt to exit:

The token it’s trying to exit with has already been transferred/spent to another owner. The token it’s trying to exit with has been double spent. It was *also* transferred to someone else and created a separate branch/history. The token has an invalid history before the previous transaction that has been submitted. An invalid history means there is a gap in the state changes.

If the operator didn’t misbehave and the clients successfully validated their history before accepting the token, it’s unlikely that scenarios 2 & 3 will ever occur. However, scenario 1 is always possible if someone who had the token in the past wants to exit with the token without the current owner knowing about it. Client services & other monitoring tools are set up such that they aim to challenge it when it happens in order to claim the bond as a reward. Even the operator who is tasked to monitor the side-chain and the main chain for deposits can challenge.

To challenge the above scenarios, you have to submit the following:

Scenario 1 (Spent Tx Challenge): A transaction that spent the current tx (the one you submitted). This means the token was transferred onwards and not legitimately in possession of it anymore. This invalidates the exit immediately and the reward is claimed.

Scenario 2 (Double Spend): Another transaction that spent the previous transaction and does not result in the current tx. This means that the token was double spent. This invalidates the exit immediately and the reward is claimed.

Scenario 3 (Invalid History):

A fraudulent operator can choose to include a transaction starting from a point that’s not attached to the original deposit, basically creating a history from thin air. This invalid history can also occur if the operator purposely withholds blocks. This challenge is interactive, which means that once it is challenged, another user needs to submit the transaction following it, to prove that the history was indeed valid. In order to challenge, one also needs to submit a bond, which is slashed if a follow-up transaction is supplied. If there isn’t a follow-up transaction, then it implies that the history is indeed valid.

Faster exits:

One issue with Plasma Cash is that in order to exit, the challenge period is a certain period.

There are proposals to make it faster to exit, like this proposal from Kelvin Fichter.

Bloom Filters & Checkpointing

One of the issues with Plasma Cash is that each token needs to keep its own history, which is: the transactions issued along with all the merkle proofs of all the Plasma Blocks. This in itself can grow quite substantially. It is estimated that for a small SMT (2¹⁶), the proof can maximally grow to 1gb for EACH token per year!

Bloom Filters, in being able to probabilistically return whether items are in a set are a proposal to make the history more compact.

Another alternative to keeping the proof size smaller is to rely on regular main chain checkpointing, which would allow users to throw away certain parts of the history.

Fungibility:

Plasma Cash works by having each token static with a certain denomination. In the case of a collectible, it’s always just one. This makes it harder for fungible tokens to work in this context. There are however proposals to utilise Plasma Cash to enable fungibility too, called Plasma Debit.

Plasma Cash @ Ujo Music?

Nihar Dalal & I have been exploring scaling solutions for use in Proof-of-Concepts at Ujo Music: from looking at probabilistic payments, counterfactual state channels & Plasma Cash. There’s many ways these new scaling solutions can aid us making new money for artists & musicians by bringing the costs down substantially.

There’s a multitude of ways to decrease the cost of licensing, add streaming payments & other improvements.

Conclusion:

Plasma Cash is a scaling solution that is currently primarily suited towards tracking ownership of assets in a side-chain. Using SMTs and frequently checkpointing into the main chain, users of the Plasma Chain can be guaranteed that their assets would never be stolen or destroyed.

The benefits are that you get scaling improvements at the cost of having ensure that the operator won’t revoke service at any point in time. It’s not possible in this scheme to lose funds, but it possible that the service might be degraded if the operator isn’t functioning (negligently or maliciously).

Plasma Cash as a whole is still evolving. It still needs additional scaling features to make it more feasible in practice (making token history even more compact). There’s likely to be more innovation in the short term that will prove to be useful in providing trustless, scaling solutions. The first implementations are going live soon!

Exciting times!

References:

http://plasma.io/plasma.pdf

Thanks:

Thanks Koh Wei Jie, Juan Blanco, Kevin Zhang, Hrishikesh Huilgolkar for feedback & comments. Thanks also to Nihar Dalal & the Ujo team (Jon, Kyle, Jack & Alex for discussions & feedback).

Are the problems interesting to you? Take a look at our careers page at Ujo Music: https://ujomusic.com/careers. Say hi!