The figure above outlines this process. The user first proves some UTXO was generated in a transaction that happened in a valid block. After establishing the anchor, the user now provides data and signatures for all the spent UTXOs between the anchor point and the UTXO being withdrawn (shown in red).

The size of the necessary data grows with the number of spends since the anchor point, which makes this method significantly more expensive than the normal withdrawal. Theoretically, the user could go all the way back to inception (i.e. creation from deposit), but it shouldn’t be necessary for reasons that will be explained shortly.

Data Availability

Withdrawals are only possible if a user has the necessary data — namely, the recent provenance of the UTXO he or she is trying to withdraw. As mentioned before, a system operating normally should provide this data to the user when the UTXO is generated. This data can be stored in the user’s browser and is utilized if the UTXO is withdrawn. Another option (depending on your comfort with centralized solutions) could be to let the watchers hold onto this data and let users query it when needed.

Once the system gets flagged by a watcher, users should stop using that system and withdraw immediately. Users should not trust any new data generated by a flagged system.

Attacks and Prioritization

What if the authority tries to withdraw your tokens before the user does? As long as the system is parameterized properly, this shouldn’t be a problem. Priority is given to withdrawals referencing earlier checkpoints and withdrawals finalize in order of priority. Even if the attacker submits a withdrawal first, there is a waiting/challenge period during which the user can submit a withdrawal to block the attacker.

To avoid having this tactic used against honest users, a “security deposit” is included with the withdrawal request. If the request is proven to be false (either through a double spend or an earlier withdrawal successfully claiming the money), the requester’s security deposit is sent to the prover.

But what if an attacker simply chooses the same (or an earlier) checkpoint? Well, this should be impossible because the attacker can’t prove the subsequent provenance chain. Because spends are cryptographically signed, the chain of UTXO spends can only end at the true owner. Thus, the attacker can only attack using the current block and the method described in the previous section, but we have shown this will fail due to prioritization of your withdrawal, which is based on an earlier block.

Challenging a Withdrawal

Once any withdrawal is initiated, there is a challenge period during which incorrectness may be proven. There are two types of challenges in this system, both of which have already been discussed:

1. You have spent the UTXO you are trying to withdrawal

Double spends are easy to challenge. All a watcher needs to provide is your signature spending the UTXO you are trying to withdraw.

2. You are withdrawing money that isn’t yours

It is impossible to prove that a malicious operator doesn’t own a UTXO if we don’t trust the state being checkpointed. However, the priority given to withdrawals on earlier checkpoints avoids this scenario by requiring the withdrawer prove the recent provenance of the UTXO, which only the true owner should be able to do.

The Need for Security Deposits

Because there are two types of challenges, withdrawals should be backed with a security deposit that is awarded to a successful challenger. In the first case, the challenger is any watcher who submits the double spend proof. In the latter case, the challenger is the true owner of the UTXO being maliciously withdrawn by the attacker. This means that if someone tries to steal your money and you have to withdraw to the main chain, you should at least get paid for proving the attack.

One other fun idea we’ve discussed is for the Plasma system maintainers to post a bond that is given out if they are proven to be acting maliciously. This could potentially be quite large and would act as a trust mechanism for using their system.

Second Layer Performance

Plasma acts as an anchor between the public Ethereum network and a more performant second layer. The cool thing about this design is that your second layer doesn’t need to be a blockchain.

You may have noticed I never used the words “child chain”. That is because I am imagining this child system running on a traditional SQL database. The reason should be obvious: SQL is much more performant than any blockchain will ever be and, as I have shown in this article, a blockchain is not necessary for a Plasma second layer.

SQL inserts per second (http://www.fromdual.com/how-good-is-mysql-insert-trigger-performance)

In the above chart we see that using MySQL “triggers” (a special kind of database object), we can get 10,000–30,000 inserts per second on a single machine (with multiple threads). This is slightly faster than vanilla SQL, which is still within the same order of magnitude. At its peak, we saw Ethereum do about 1.3M transactions per day, which is 15 transactions per second. Thus, we can reasonably expect that SQL increases write throughput by ~1000x relative to a public blockchain. Even if sharding brings a 10x increase to blockchain throughput, SQL will still beat it by two orders of magnitude.

What is most exciting to me is that Plasma gives us the best of both worlds. We get trustless, censorship-resistant money and compute execution at the base Ethereum layer while also being able to utilize SQL’s performance on a second layer. In Plasma, a user deposits money on Ethereum and can then spend that money instantly and with no transaction fees on a second layer web application. When the user is dissatisfied with the service, he or she can trustlessly withdraw that money with no intermediaries and deposit into another service.

This is the internet of money we were promised and it will facilitate a new wave of permissionless innovation in the financial technology space. And like the web enabled new business models, so too will Plasma.

The Road Ahead

As I mentioned at the top, this is not meant to be a proposal. I am spending some time at Grid+ researching scalable Ethereum systems, but I am not officially working on Plasma. I have enjoyed the scaling efforts being made around the broader ecosystem over the last few months and I hope it is helpful that I lend my voice to the larger conversations which will eventually shape how these systems are designed. It is encouraging to see a more diverse set of engineers working on protocol-level problems. Let’s keep building.

Resources

Please see the following resources for more information on Plasma:

Thanks to Mark D’Agostino and Ameen Soleimani for the discussion that created and/or helped solidify some of these ideas.