Fundamentally, Plasma currently does most of the work with very simple UTXO or non-homologous tokens. Many people want to know if it is possible to create a Plasma chain that allows users to deploy EVM smart contracts. Unfortunately, achieving this is much more complicated than you think. If you don't have a lot of work on Plasma, you may not be able to figure out why. The purpose of this article is to give a quick overview of why Plasma is having difficulty fully supporting the operation of EVM, and then make some suggestions on how to create a Plasma chain that can run more types of smart contracts.
Why is it so difficult to create a Plasma chain that supports EVM? Before we start to reveal the secret, let's talk about Plasma again. One of the basic characteristics of Plasma is that the state on the Plasma chain must be able to be retracted back to the root chain (for example, Ethereum) to ensure state integrity. Assets on the Plasma chain must be free to move to the root chain and vice versa. This feature is very important. When Plasma's consensus mechanism is corrupted, users must withdraw their assets on the Plasma chain back to the root chain.
To understand this, imagine a simple Plasma chain that allows users to transfer or receive funds through their accounts. If you are one of the users on this Plasma chain, you want to withdraw your funds. What should you do? You can tell the contract on Ethereum that you have a fund on the Plasma chain and you want to withdraw the funds. Of course there is a condition here - you can't lie about the balance in your account. That's why we're introducing a "challenge" mechanism during which invalid refunds can be locked.
Now, let's extend this concept to a familiar EVM smart contract, with a simple multi-signature account as an example. If this account is currently on the Plasma chain, we need to provide a way to withdraw the wallet back to the root chain. However, we don't want to take the funds out of the multi-signature account – we want to withdraw the entire smart contract back to the root chain. Be aware that each EVM contract is made up of status, balance, and code. Therefore, we are actually moving the status, balance, and code of this multi-signature contract from the Plasma chain to the root chain. After the transfer, the contract should be able to function properly on the root chain.
So, who actually decides to transfer things from the Plasma chain to the root chain? If we are talking about a simple account, the account owner should be able to withdraw the balance at any time. If we are talking about multi-signature accounts, then we can design some different mechanisms to decide when to transfer the multi-signature account to the root chain. Each user signature on a multi-signature account may be required, or an n/m user signature, or a user signature. All of these mechanisms are likely to work—the designers of multi-signature accounts need to decide which mechanism is most appropriate.
But the problem is coming – not every time you can determine who wants to move the contract from the Plasma chain to the root chain. Imagine running a smart contract on a virtual cat (on a Plasma chain). Assuming that the consensus mechanism is corrupted, everyone needs to leave the Plasma chain to ensure the security of the funds. How do we deal with this virtual cat contract? As discussed above, we need to withdraw this contract back to the root chain. Unfortunately, if we allow everyone to withdraw the contract, the user will rush to withdraw the contract as much as possible, causing the Plasma chain to be void. Therefore, we must come up with a better mechanism.
We can come up with some mechanisms, but these mechanisms are not too centralized or too costly. It seems feasible to use the voting mechanism to decide when it is possible to withdraw the contract. The problem is that if the number of legitimate voters is small, the degree of centralization of contract control is too high; and the more legal voters, the higher the cost of the voting mechanism.
Let's talk back to the process of withdrawing things from the Plasma chain. Don't forget, once we find that a state to be revoked is invalid, we can prevent it from exiting. Suppose that our virtual cat contract states that I am the owner of Cat 123. Now we want to withdraw the contract and need to indicate the current status of the contract. One record in the current state is "Kelvin has a cat 123". What happens if I transfer the ownership of Cat 123 to another person during the challenge period of the contract? The "real" status becomes "User X has a cat 123". At this point, the state of evacuating Plsama is invalid (so it can be challenged successfully). We are welcoming the second big problem - if anyone can modify the status of the contract, then anyone can stop the exit ( proofreading note: that each user's permissions become a veto).
This has led to our ultimate problem - we need to verify that the challenged state change is a valid change, but it is difficult to verify the EVM state changes inside the EVM is hard in the EVM. For a contract like the account, a valid state change only requires the signature of the account owner and is easy to check in the EVM. However, for complex EVM contracts, the situation is much more complicated. One way to verify EVM execution is to use a project like TrueBit. While this may be the easiest option, it will make Plasma too dependent on external systems, thereby fundamentally stifling its security. Ideally, if we want to verify the steps of an EVM without trust, we need to run another EVM in this EVM. Based on this consideration, Vitalik even proposed an Ethereum improvement plan for this purpose. I really recommend that you take a look at this Ethereum improvement plan. After reading it, you will understand (the gas limit is set in the gas limit, oh...).
That's why the Plasma chain can't run so many contracts like Ethereum. Finally, a quick review:
It's not always possible to determine who wants to move the contract from the Plasma chain to the root chain.
If anyone can modify the status of the contract, then anyone can lock the withdrawal.
It is difficult to verify the status change of the EVM in the EVM.
So where do we go from here? Fortunately, we have begun to come up with some concepts that weaken these issues primarily by breaking down typical types of smart contracts. Also take the virtual cat contract as an example. If each user wants to transfer their own virtual cat instead of the entire contract, it is much easier to determine who is transferring the things on Plasma to the root chain. We can use a smart smart contract to represent each cat, and only the owner of the cat has the right to modify the contract. The first two problems are solved by simply changing the design.
I have discussed with Dan Robinson about how to modify the design and make it more suitable for developers, after which I will post some preliminary ideas. The point is that the easiest way we've found is perhaps to use something like the Transaction Virtual Machine (TXVM) and a high-level language that can compose and automatically decompose EVM smart contracts. We call this "Plasma VM" because this method is feasible and backward compatible with MVP.
If you have any feedback / questions / comments, welcome to. If there are still some incomprehensible, please let me know and I will improve it!