Problem with the current solution (blockchain)
Blockchain gives us a reliable, trust-less secure system with no central governance. In spite of having such capabilities, enterprises do not prefer to use public blockchain for building solutions. The primary reasons for this are privacy and scalability. Since all blockchain data is publicly available, one can use blockchain analytic tools to get insights such as a linked public address, spending habits of a user or public address and then who transferred what to whom. The second reason is that scalability is a critical issue with any blockchain. Currently, blockchains handle [3-30] transactions per second, which is nowhere near the mainstream centralized payment system. Example: Visa processes around 1700 transactions per second.
Proposed Solution
Since privacy and scalability are major and widely known interests in the blockchain community, all are trying to solve it in their own way. Joseph Poon and Vitalik Buterin came up with the idea of a child chain called Plasma. A plasma framework is a smart contract that will be deployed on the Ethereum main chain (parent chain). The smart contract will enforce the child chain to follow predefined rules. The plasma child chain is not empowered to create or burn any artifacts such as fungible ERC 20 tokens or non-fungible ERC 721 tokens (NFT). Therefore, to operate on the plasma child chain, users need to transfer their parent chain ERC tokens to the plasma child chain. The plasma child chain is built on the top of the parent chain in a way that whenever it appends a block in the child chain, it must add the Merkle root of that block to the smart contract on the parent chain otherwise that block will be invalid. The plasma framework will solve the privacy problem since no transactional data history will be added to the public parent blockchain. It is using Proof of Authority consensus so that it is far better scalable in terms of transactions per second and will have all the benefits of blockchain technology.
Figure (1) shows different variants of the Plasma Framework. Since the idea of the plasma child chain came up, the whole Ethereum community is working on improvements. Therefore, today, multiple designs of plasma framework exist such as Plasma-MVP, Plasma-MoreVP, Plasma-Cash. Individual plasma also has multiple variants with slightly different use-cases.
Figure (2) shows the generic idea of the Plasma Framework. Each variant of the Plasma Framework implements its Smart Contract using this abstract idea. Therefore, each Plasma smart contract implements the following interface.
Interface:
- DEPOSIT
- EXIT
- CHALLENGE
Including the above-mentioned function, all methods/functions of the smart contract can have different implementation depending on the idea of that Plasma variant.
For example – In Plasma-MVP users must sign a transaction when they make a transfer and again when it gets confirmed. Therefore, for a single successful transfer, the user must sign it twice. Plasma Cash users need to sign only once for a transaction, and each token behaves like NFT.
Plasma Cash
We are working on the Plasma Cash framework and building a decentralized application (DApp) on top of it. The Authority (The Operator) of the child chain is the public address who deployed the smart contract to the parent chain. Only the operator has the authority to append a block into the child chain. The operator can append a block in two ways. First, when a deposit occurs in the parent chain, then the operator will create a block having one UTXO equivalent to the deposited amount. The other way is to create a block by including all token transfer transactions. The smart contract emits a distinct event for each activity in the parent chain so that users listening to the smart contract will get to know all state changes of the smart contract. These events are like meta-data of the child chain.
Let’s take an example of how useful these events are. Assume a user deposited an asset to the plasma smart contract if the operator will not listen to events from the smart contract, it will never get to know that a deposit transaction happened on the parent chain and will not include that transaction’s equivalent NFT token to the child chain. That is why it is necessary for the child chain operator and for the users to listen to the smart contract events.
Once a token is added to the child chain, it can be transferred to any user. The plasma cash is UTXO based model. Therefore, transferring a token implies spending a UTXO and creating another UXTO which holds new ownership. Whenever a user wants to create a transfer request, it will need to provide the UTXO details such as UTXO’s unique ID (UID) and the index of the block in which the UTXO was created.
At any time in the future, a user can transfer its token from the child chain to the parent chain. This process is called the Exit process. The exit process can be initiated by a token owner to the smart contract on the parent chain. The exit process consumes the given token from the child chain and molds it into the equivalent amount to the parent chain.
The operator performed all safety validations on the child chain side, and the Plasma smart contract handles all the security checks on the parent chain side. The operator keeps all UTXO states; therefore all double-spent and invalid state transition attempts can be rejected. Figure (3) shows the legitimate operator case. Assuming the operator is behaving according to the predefined rules, there will be no case of block withholding scenario so that the only way of either stealing money from the child chain is invalid Exit request on the Plasma Smart contract. The Plasma smart contract enforces the whole exit process.
Figure (4) shows the invalid exit scenario and related activities on the child chain and the parent chain. Since the parent chain holds no transactional details of the plasma child chain, therefore, the smart contract will not be able to confirm or decline the upcoming exit requests. Plasma smart contract adds all upcoming exit requests to a waiting queue and either confirm or reject after a predefined waiting period. This waiting period is described as the Exit Period. The exit request refers to a UTXO, and the UTXO describes a unique NFT token and the owner details. All exit requests referring to different NFT tokens are independent of others and can be processed in likewise order. However, exit requests referring to the same NFT token can cause stealing if they are processed in likewise order. The plasma smart contract evaluates all exit requests in priority order. The priority order is calculated using the exit request’s UTXO details. The exit request referring to UTXO with a lower block index will be executed with a higher priority. Therefore, the last valid token owner can always successfully transfer it to the parent chain.
In the case of the legitimate operator, there will be no invalid transfer possible in the child chain. As described earlier, the only possibility will be an invalid exit request on the parent chain. Any invalid exit request will only finalize after the exit period is over and if there is no valid challenge raised with Merkle proof against it. Merkle proof is the valid transfer history of the NFT token in the Plasma child chain, and it can be either calculated or retrieved. Therefore, valid owners must look at exit requests and need to raise the challenge so.
In the case of the malicious operator, the operator can accept double-spent and invalid state transitions and include these invalid transactions in the upcoming block. Figure (5) shows the malicious operator scenario. The operator can also withhold a block that symbolizes a block that is added to the child chain but available to users. Due to withholding the blocks, users are not able to decide how to react now. Since an invalid exit request referring to either double-spent or invalid state transition UTXO cannot be declined via any challenge with Merkle proof. When these situations occur, affected users will only have one option to create an exit request referring to the last valid UTXO. In the above-mentioned scenario, no invalid exit request can be executed as finalized if the owner is observing the token states.
This extra burden on users makes the child chain independent of the operator for security.
All security points are mathematically proven in the white paper by Joseph Poon & Vitalik Buterin.
Architecture
The figure (6) exhibits a simplified architectural overview for a side chain DApp.
Conclusion
If you are curious to see our work, check out the GitHub repository.
In the upcoming blog, I will cover the possible use-cases and DApp implementation of Plasma Cash.
