Whatever happened to nested plasma chains?
The idea of “nested plasma chains” was first mentioned in the original plasma white paper. Basically, the proposal was that plasma chains could be attached to plasma chains, which themselves could be attached to other plasma chains, ad infinitum.
Here’s the famous diagram from the original paper:
One fundamental flaw of the original plasma design is that every user on a plasma chain needs to download and check every single transaction on that chain in order to keep their funds safe. This puts a cap on the total number of transactions that an individual chain can process every second! Nested chains were supposed to solve this problem (and thereby make the design more scalable) by putting plasma chains inside of plasma chains.
The purpose of plasma is really just to bundle a bunch of transactions together in a very efficient way. People can move funds into the plasma chain by depositing those funds into the chain’s smart contract, and people can move funds out of the plasma chain by going through some withdrawal process (the “exit game”). Although we usually think of this smart contract as a piece of code running on top of a blockchain like Ethereum, the plasma white paper proposed that we could also put this code on a form of smart contract sitting on another plasma chain.
Let’s demonstrate with pictures (just the original duplicated with some added color):
Whenever a user wants to deposit funds into the yellow plasma chain, they first need to send funds to the blue chain. To do this, they’ll send money to a smart contract running on Ethereum (green). Next, now that the user has funds on the blue chain, the user sends those funds to a special address on the blue chain that acts as a smart contract for a yellow chain. The user now has funds on the yellow chain!
To get funds out, the user can repeat the process in reverse — they’ll first move their funds from the yellow chain back to the blue chain, and then move their funds from the blue chain back to Ethereum. That’s pretty simple, but it does mean that users have to pay some (probably minimal) fees whenever they’re moving funds between chains.
Of course, this is a simplified, high-level version of the actual process. There’s a lot of hidden complexity that I’m handwaving for the sake of brevity.
Again, the reason why this design was proposed is because each individual plasma chain (as originally designed) could only handle 100–200 transactions per second. By nesting chains within other chains, you could increase total throughput significantly.
The problem with the idea was that it was simply too complicated to be implemented right away. It quickly became apparent that putting the EVM on a plasma chain is really hard. Without any great framework for putting smart contracts on plasma chains, we’re generally stuck with adding a bunch of really complex rules to the root chain (Ethereum) smart contract. Unfortunately, if you modify the architecture of the child chains in any significant way, you’re also forced to rewrite most of the root chain smart contract. So it made more sense to focus on a very solid base layer before starting to think about adding more layers.
The idea of nested plasma chains hasn’t died, but it’s become much less necessary. Research advancements like Plasma Prime have shown that there are simpler (and easier!) ways to scale by significantly reducing the amount of data that end-users need to process in order to keep their funds secure. These designs don’t reduce the computational load on validators compared to nested chains, but that’s a trade-off we’re willing to make (because dealing with that load is exactly what validators get paid for and they can can set fees commensurate with their costs).
That said, I still think there’s room for research into nested plasma chains, but they’re definitely not an immediate priority (because we have better and simpler options we can explore first!).
Hopefully that was helpful! Feel free to leave comments if you have other questions/feedback/inevitably find a typo.
