The Plasma Framework solves the privacy and scalability issues of the public Ethereum blockchain. In this blog, we will take a closer look at the possible use cases that can be implemented as decentralized application (DApp) using Plasma Cash, and how can those be implemented.
Plasma Cash Use Cases
Plasma Cash converts all deposit tokens into a non-fungible-token (NFT), wherein each NFT token holds a unique and stagnant behavior. Therefore, Plasma Cash can be an ideal fit for applications where assets aren’t divided and ownership is changed frequently. Gaming Dapps can use the scalability potential of Plasma Cash where users exchange game objects modeled as token, for instance any character’s card, suit, or any power. In addition, non-gaming models can also benefit from the scalability and privacy potential of Plasma Cash. For example- Artifact review workflow application (developed as DApp) in an Enterprise, where a given artifact is transferred between users and the artifact can hold one of the states, namely Created, Submitted, Rejected, Accepted, and many more.
Document Review Workflow Use Case
In any enterprise, artifacts such as Product (Service) specifications, quotations, proposals, etc. are created and transferred to multiple departments for evaluation. Each stake holder can reverse it conclusively, accept it, or transfer it ahead, and Plasma Cash is the best fit for an application like this. Here, the artifacts can be modeled as NFT tokens and state changes are similar to NFT ownership transfers. The final state will be transferred to the Ethereum parent chain.
Figure (1) shows a simplified workflow of an artifact.
Consider a document created by a user and the document owner has submitted it to another user for review. In this step, the document moves from ‘created’ state to ‘submitted’ state. After successful review, the reviewer will send this document for publication to the third user and the document moves from the ‘submitted’ state to the ‘reviewed’ state. Post publication, the document state is changed to ‘published’ state.
The deposit function of the plasma contract will take document hash as the input and produces an equivalent NFT token as output. As document state is altered, it’s equivalent NFT token goes through corresponding state changes; after publishing the document, the NFT token will be transferred to the Ethereum parent chain using the plasma contract exit function.
DApp Components
DApp built using plasma would be based on a similar set of components i.e. every DApp consists of an operator process, a user component to ensure child chain security to arrest double spend, and a client application responsible for interacting with the child and the parent chain.
The client application deposits a token to the Plasma Chain smart contract on the parent chain, then the smart contract will return an unsigned integer and emit a DEPOSIT event. So far, DApp only has UID knowledge and DApp needs to fetch the deposit block index. For that, DApp needs to monitor all the upcoming blocks on the child chain and check whether the upcoming block has a deposit block with the same UID. The block index is the utmost important property either for security or transferring it to another user. The user component maintains all token’s UID of the user and corresponding block index details and watches the child chain at least once during the exit period. The user component fetches all the upcoming blocks and smart contract states to check incoming tokens, or if anyone has tried an invalid exit or a double-spent, and then, raise counter action appropriately.
Conclusion
We are working on Plasma Cash for use-cases where we need to change one or more states including NFT transfer. In case we have got you interested enough, do check out our work on the GitHub repository.
