Home > Unitalks > Articles

【UNITALK】David Knott: The solution of Blockchain Scalability Problem–Plasma  


The scalability problem of blockchain is one of the main concerns of the technology nowadays. Plasma is one of the solutions proposed by Ethereum for scalability problem. Today, we are honoured to have David Knott, the core researcher of Plasma, to share with us the latest development of Plasma. David Knott is the core researcher of OmiseGo Plasma, the implementer of Plasma MVP and one of the maintainers of the smart contract language –Vyper.

This interview is divided into two sessions: Fixed Q&A  and  Free Q&A.

UNITALK AMA–Fix Q&A Session:

1. How has your love nature and adventure influenced who you are now?

My love of nature and adventure has led to me being exposed to different experiences and perspectives which has granted me insight into how the world works and how the people who inhabit it think and feel. The ability to create games that allow people from many different backgrounds to win is one of the things that drew me to Ethereum initially and is one of the reasons I’m still working in the Ethereum ecosystem today.

2. How did you get started in blockchain, become immersed in the Ethereum ecosystem, and then start working on Plasma?

I was studying economics in college but decided to leave to learn how to program. Got my feet wet by playing around with Ruby on Rails. Then I learned about Ethereum and started writing Solidity smart contracts. But I kept running into constraints imposed by the Ethereum Virtual Machine and so I decided to dive into the infastructure level to learn how it worked. I started contributing to a few python Ethereum codebases and eventually ended up working for Ethereum Research on Vyper. Working next to researchers I became increasingly interested in mechanism design and wanted to do more of it. Around that time I came into contact with OmiseGO and had the opportunity to work on Plasma. Note: Contributing to open source projects on github is a great way to learn and get familiar with the Ethereum ecosystem.

3. Using a real world analogy, how does Plasma tackle blockchain scalability?

The Plasma architecture can be thought of as a court system. In the case of the OMG Network, Ethereum is the highest court as it’s responsible for securing everything. When everything’s running smoothly the OMG Network will function as a lower level court and won’t need Ethereum to be involved. But if a Plasma child chain becomes malicous, all users who have value or state on said child chain may submit a transaction to the higher court (Ethereum) to maintain custody of their funds.

4. The OMG Network was designed in anticipation of Plasma. How will Plasma support a scalable, fully on-chain exchange without sacrificing security, and what are your most pressing concerns right now?

The Plasma architecture will allow the OMG Network to have the bandwidth necessary to support a DEX without sacrificing security. It does this by periodically sending snapshots of state (block roots) to Ethereum, this allows Ethereum to act as an arbiter if the child chain becomes malicious. 

My most pressing concern right now is creating standard implementations of Plasma smart contracts so the projects who want to use Plasma can push the ball forward as opposed to reinventing the wheel. To generalize this, blockchain technology is young, therefore interdisciplinary skills are more valuable.  If researchers focus on creating reusable primitives and standards they not only help their own project, but the entire ecosystem. The three fields where I see the most intersection are cryptography, distributed systems, and cryptoeconomics. 

5. What’s Plasma Cash and why does it require less data checking?

Plasma cash requires less data checking because each user only has to verifier their own data as opposed to every state transition on the child chain in order to protect their funds. This is achieved by representing all value within the Plasma child chain as non fungible tokens (NTFs) much like cash. NFTs are a usefule representation because they allow the Ethereum smart contract to only worry about discrete values tied to specific users whereas Plasma MVP pools all deposited funds together within the Ethereum smart contract. 

Fun Fact: Plasma Cash also has less time constraints than Plasma MVP.

6. Does Plasma need some sort of off-chain centralized system or oracle to detect and deal with root chain network congestion?

If a Plasma MVP chain becomes malicious, users must exit to Ethereum within a given amount of time to maintain safety. In other words, Plasma MVP requires Ethereum to be available. But Ethereum is used for many different things and transaction costs are based on demand. One way to track Ethereum transaction costs (aka network congestion level) would be to have a centralized oracle tell the Plasma smart contract on Ethereum. But this would introduce a single point of failure and so is not a viable option. We’ll improve upon this by letting a group of stakers submit information about Ethereum transaction costs, this information will be verifiable because it will be based on information that’s included in the Ethereum block roots. And Ethereum smart contracts already have access to these block roots. The game we’ll use to prove that network congestion information is correct, you can check something like the Truebit bisecting game described in this paper: https://people.cs.uchicago.edu/~teutsch/papers/truebit.pdf

7. What are fast withdrawals and mass withdrawals and how are they different?

Fast withdrawals are a way to shorten the root chain withdrawal period from a minimum of a week to a few minutes. They do this by allowing users who’re exiting to trade their exit to a liquidity provider for a small fee. Then the liquidity provider waits for the exit to be processed and the user who was initially exiting is in the clear. It’s especially important with value that’s volatile as many users will not want to be exposed to the risk of waiting a week. 

Mass withdrawals allow multiple UTXOs (Unspent Transaction Outputs) to be exited with a single Ethereum transaction. An exit leader collects signatures from UTXO owners and aggregates them. Then the exit leader submits a mass withdrawal transaction to Ethereum signalling which UTXOs are being exited and also submits the root of a sum-merkle tree that proves the total value of the UTXOs being exited. After a period of time if no challenges are made against the mass withdrawal, it is processed and mass withdrawal participants may claim their funds.

8. How can we get faster economic finality on Plasma?

Child chains are secured by root chains. Therefore, for a transaction to be considered finalized a user must first submit it to the child chain, wait for their transaction to be included in a child chain block, wait for the child chain block root to be submitted to the root chain (we’re using Ethereum), and than wait for finality on the root chain. This process takes a few minutes, but the child chain’s consensus can perform bonded countersigning to speed things up, essentially shifting liability from users to the child chain’s consensus. If the child chain’s consensus is a single operator then when Alice submits a transaction to the child chain she’d have the operator sign her transaction right away guaranteeing that it will be finalized eventually. If it’s not, Alice receives money from the operator that’s greater than the value she has lossed from her transaction not being included. With this construction Alice can have near instant economic finality on her child chain transactions.

9. How can the Plasma architecture interact with Ethereum and how will it’s use effect Ethereum?

The OMG Network’s Plasma architecture will be rooted to Ethereum via smart contracts. Users will make deposits and withdraws to the OMG Network via Plasma smart contracts on Ethereum. If everything’s working correctly only child chain block roots will need to be submitted to Ethereum regularly. With each block having many transactions, the cost of block submission to Ethereum is paid for by child chain transaction fees. 

UNITALK AMA–Free Q&A Session:

1. In terms of the availability of plasma. Have you ever considered a recovery protocol after a block withholding attack is detected and every user has exited?

Yes, we’re thinking a lot about that. Everyone being able to recover funds is great but that’s just the beginning. If a child chain breaks, if there’s no recovery mechanism, then that either leads to the businesses who relied on the child chain being offline or having to pay expensive Ethereum transaction fees. The solution we’re looking into now is letting anyone submit plasma chain blocks to a smart contract and then have users who’re exiting specify a plasma chain ID.

2.Can you clarify the plasma cash chain id part a bit? Does that mean that you actually will allwo users to run multiple child chains at the same time?

The idea would be to allow anyone to submit block roots of their own Plasma chain to a smart contract. Each Plasma chain would have it’d own id, and so users exiting would be able to exit into another Plasma chain. Anyone can run as many Plasma chains as they want, that’s the beauty of permission-less innovation.

3.Will you issue tokens for OMG plasma chain? What do you think about the incentives for the child chain? Also curious what’s the TX speed and volum do you think plasma can handle? Have you done any benchmark? How close do you think your plasma will be ready to be rolled out to prod?

There’s already an OMG token that will be used for staking the OMG Network child chains.

Economic incentives are critcial for designing the child chain.  Data unavailability, is a huge issue, as there’s no way for the root chain to know if the child chain consensus is withholding blocks or not, it’s only able to see child chain block roots.  Theirfore we have to deal with the problem using economic incentives, one of which being the native OMG token.

For our initial iteration, conservatively 120 tps on a single Plasma chain. We’re working towards production, but given the stakes when it goes live, doing it the right way is much more important than getting it out the door.

4.I’ve read some discussions about off-chain validation with Plasma on-chain smart contract recently. Here’s one question: Even if STARK mechanism is used to mitigate the load of main chain , the computation overhead for Plasma operators may still be expensive if the number of Plasma accounts is big enough. Will it lead to an undesirable multicentralized result banning small operators away?If so, what’s your next plan to deal with it?

When designing these systems it’s essential to keep small operators in mind and to try to even the playing field when at all possible.  As Plasma usage goes up it’ll become unfeasible to have every operator run the entire chain and so we’ll most likely steer towards a shard like solution.

5.Mako: Can EVM  run on Plasma? And could we write smart contrect on Plasma?

Not yet, the EVM’s state transitions are too complex and the EVM’s resources are very expensive.

6.Within the logic of the child chain tree, if we are dealing with the other data structure (such like medical record, car tracking record)  instead of the financial application, will those data be stored in the every child chain’s nodes or only one child chain’s nodes?If we are going to build a permissioned blockchain networks to handle the mass of commercial data first, then backup the header no-real-time on the Ethereum to get the security and decentralized ability, is there any concept we can borrow from the plasma?

You’d have all (Plasma MVP) or some child chain nodes (Plasma Cash) storing a representation of the information (think hash).  Yes, I suggest looking into how Plasma Cash stores information as it cen be used in a permissioned manner to give users the privacy they need.

7.You have mentioned sharding on plasma. Can you do it without support of smart contract on plasma?

It’s still being carved out, but most likely by leveraging smart contracts on Ethereum. We’re also looking into Plasma doman specific languages (DSLs) that will extend functionality while keeping the state transitions simple enough to be tracked by the evm.

8.Every one could submit block roots? What if many users submit the same block?

Everyone can submit a block root for their own Plasma chain.  If child chain consensus’s want to submit the same root they’re welcome to do so, but this would probably force an exit.

9.Heard about Plasma Credit from Eric Olszewski the other day, are you involved in that project? If so can you briefly talk about it?

I’m familiar with it, but did not come up with it.  As far as I understand it’s a design that extends Plasma Cash as opposed to a project.


We would like to thank David Knott for supporting Unitimes. If you have any related questions to David Knott, please leave your questions below, or send an email to contact@unitimes.media. We will do our best to help link you up with David Knott.

Editor: Shuyue Yang, Hulin

Declaration: Please contact us at contact@unitimes.media if you want to repost this article and indicate the source. Opinions expressed by Contributors belong to themselves.