This was probably my favorite talk, primarily due to Karl’s energy and enthusiasm about the concepts he described. At the moment, Plasma is designed for simple token transfers (ERC20/Ether), but it is extensible for more complex tokens such as ERC721 or even more general state transitions.

It should be understood that Plasma is not a protocol, it is a design pattern, a technique. The main requirement is that a Plasma Chain must be as secure as the root chain.

The main security mechanism behind the Plasma technique is “Plasma exits”, which is the process that allows a user who participates in a Plasma Chain to stop participating in the chain, and move their funds back to the Root Chain. Every Plasma Chain is also governed by its own “Plasma Operator”.

When a user is transacting in a Plasma Chain and wants to transfer their funds to the mainchain, they submit an “exit transaction” (i.e. a merkle proof of their transaction history proving they own a certain amount of money). At that moment, there is a “challenge period”.

The challenge mechanism has been seen in most off-chain solutions. Essentially, you allow anyone to challenge your claim by submitting a proof which marks your claim as invalid (in Plasma this can be a Merkle proof of the transaction history, in Payment Channels this can be a signed message from the other party).

In addition, when making a transaction that can be challenged, you are also required to attach a small bounty to it, in order to incentivize people to challenge you, if they believe your behavior was malicious. It’s like trying to steal something and saying “I’ll pay you $5 if you can catch me”.

In the normal case, if Bob wanted to transfer 5 PETH (Plasma Ether) back to the Root Chain, he’d submit an exit transaction (plus the bounty as collateral), and if it went unchallenged he’d be able to claim 5 ETH on the Root Chain. If Bob’s exit transaction was successfully challenged, it would get cancelled and the challenger gets the bounty