Plasma. So hot right now.

Plasma and the Internet of Money

I’ve become more enthusiastic about Plasma as of late, especially once I started thinking of the “child chain” as more of a “child compute” (I’ll explain later). In this article, I’ll discuss a system I’ve been contemplating and describe why this type of system could enable the internet of money we were promised: namely, infinitely scalable financial applications and permissionless innovation. This isn’t meant to be a proposal or specification — it’s more of a [fairly technical] outline for various characteristics that I currently think could lead to a scalable Plasma system. Note that this is a slight deviation from the Plasma designs I have seen so far, but it retains many of the same characteristics.

If you aren’t familiar with Plasma, I encourage you to read up on it — please see the links at the bottom of the article. Also, if you haven’t read my previous article about Plasma and UTXO tokens, you probably should do that first.

Deposits on the Root Chain

As in any Plasma system, deposits happen on the root chain. A deposit of your tokens or ether creates a new Deposit record and allows an authority on the child compute system to generate a new UTXO corresponding to the amount you deposited.

Side note: we’ve been kicking around the idea of Plasma chains counterfactually instantiated within a given state channel, potentially allowing users to move between Plasma child systems without any on-chain transactions. I haven’t really investigated the mechanics of this design, but it may be fun to think about.

Spending on the Child Service

Now let’s consider the Plasma child system/service. Imagine you have a standard web app (let’s stay system agnostic for now) that utilizes cryptographic signatures of the end users to move money in the form of UTXOs, which look like this:

{
  id: <string>,         // id of this UTXO
  to: <string>,         // recipient of payment
  value: <int>,         // atomic units of payment
  depositId: <string>   // id of original deposit UTXO 
}

Spending this UTXO splits the value into the spent amount and the remainder (if applicable), creating one or two new UTXOs whose ids are determined based on the previous spend:

id = sha3(depositId, previousId, to, value)

Where depositId is the id of the UTXO that was created from the original deposit, which would be defined as keccak256(0, 0, <toAddress>, <value>).

Each spend event is nothing more than a signature on the new id, which is generated deterministically based on the spend amount and the recipient. You can think of these spend events as “transactions” in the “plasma block”, which is made of UTXO spends. Note that although there is only one signature (the spend signature), the rules in this system can be used to prove a remainder UTXO from that spend signature.

Let’s assume, for now, that the child system keeps track of and prohibits double spends. A “transaction” in a “plasma block” (which should not be confused with a blockchain transaction/block) is a hash of:

1. The id of the new UTXO
2. The signature that created the new UTXO

For example, suppose owner1 spent a UTXO and created id1 using the format shown above. The resulting signature would be hashed with the id on which the signature was made to form the “transaction hash”:

id1 = sha3(depositId, id0, recipient, value);
sig = owner.sign(id1);
txHash1 = sha3(id1, sig);

A “block” is nothing more than a set of such “transaction hashes”:

block = [ txHash1, txHash2, ... ]

Checkpointing State

Each spend event should be associated with a “block number”, which is equal to the number of state snapshots that have been committed to the root chain. Periodically, the child system will stop adding transactions to the current block and checkpoint that block to the root chain via its Merkle root.

Spends are labeled A-H and only the header is checkpointed to the root chain

This Merkle root is saved to an array in the root chain’s plasma contract:

bytes32[] blocks;
checkpoint(bytes32 root) {
  blocks.push(root);
}

Thus, if someone wanted to prove a transaction, they would need to provide the block number, the index of the transaction in that block’s Merkle tree, and the Merkle proof which yields the Merkle root of the block.

Data Availability and Watchers

Users receiving funds on the child compute system should be served the index and block number of the spend that led to the user’s new UTXO. This allows a quick lookup of the transaction in the event of a withdrawal. This information can be stored, for example, in the user’s browser client and would have a negligible data footprint (~10kb).

Larger sets of data should be published (e.g. dumped to S3) for each block so that watchers can check correctness of spends as well as the correctness of the root hash itself when it is committed to the root chain. This should ensure there are no double spends and that the transaction data are being correctly checkpointed. In the event of foul play on the service’s end (fake transactions, withheld data, etc), watchers are responsible for publishing the concern and transferring the service to a black list before suggesting users withdraw funds.

One can imagine watchers maintaining a blacklist and charging a subscription fee to utilize its API. These watchers would likely monitor many Plasma chains as data is checkpointed.

Normal Withdrawals

Under normal circumstances, withdrawing in this architecture is quite compact. If we know that the checkpointers are behaving properly, we can utilize the Merkle hashes saved to the root chain. All a user needs to do is wait for the checkpoint that includes the UTXO he or she is trying to withdraw.

Once the checkpoint is committed, the user can start the withdrawal in one transaction. This process should do the following:

1. Get new id with the spend that created the UTXO

bytes32 newId = keccak256(depositId, prevId, to, value);

2. Form the transaction hash, which is a hash of the new id and the spend signature.

bytes32 txHash = keccak256(newId, v, r, s);

3. Use a Merkle proof to prove the spend happened in a specified block whose root has been committed.

Here the user reconstructs the hash C with spend data and proves it was in a checkpointed block header

4. Start the countdown for the challenge period (more on this soon).

This process is very compact (and therefore inexpensive) because it is relying on recent state checkpoints. As long as the user can trust the committed state, the withdrawal process is nice and easy.

Withdrawing in Duress

But what if we can’t trust the committed state? What happens when the child system starts creating and checkpointing fake transactions, withholding data, or doing other mischief? If this occurs, we assume the watchers will raise the alarm and users will start exiting.

The withdrawal process under duress is similar to a normal withdrawal, but with additional proofs. Note that this process can be invoked for any of the following reasons (and probably others):

1. The child system is censoring transactions or otherwise broken
2. The child system is trying to withdraw a UTXO you own
3. Another user is trying to withdraw a UTXO you own
4. You don’t trust recent blocks and just want to leave

NOTE: if a user never received a UTXO on the child chain, a withdrawal would not reference a block; it would simply be a withdrawal of the initial deposit.

Going Back in Time

As before, the process starts by forming a new id from the spend that created your UTXO. However, we can no longer reference the recently checkpointed states because we either don’t know (or don’t trust) what’s in them.

The solution is now to find the most recent state update that we do trust (because either we or our watchers have verified it) and prove spends from that point.

Prove the first UTXO was included in a trusted block and then provide data + signatures on transactions since. Only the items filled with red are needed.

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:

• The Plasma whitepaper
• Making Sense of Ethereum’s Layer 2
• Minimum viable Plasma
• Bridges, Plasma, and UTXO Tokens
• Plasma Cash
• Plasma Cash Simple Spec

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