Plasma in Action

Scalability has been a known problem of Ethereum network and there is huge effort to resolve this. Ethereum can currently only process 15 transactions per second, where Visa is processing around 45000 transactions per second. So far there has been few solutions in place that are tremendously increasing throughput of the network. The first set of efforts, “Layer 1” means that the solution is based on the blockchain directly. These two solutions that are trying to achieve better scalability on the blockchain are:

1. Proof of Stake (PoS)
2. Sharding

The second set of efforts, called “Layer 2” is a set of solutions that are based on off-chain solutions. Currently there are two main designs that are trying to improve scalability:

1. State Channel
2. Plasma

Plasma is a side-chain and the two main design implementations of Plasma are called Plasma MVP and Plasma Cash. In this article, as title is saying I will be talking about Plasma Cash as a solution for addressing scalability problem.

Plasma Cash is design pattern that is actually adding layer of smart contracts which can interact with the main blockchain and allows off-chain messages to dictate the transfer of on-chain assets. In principles Plasma is similar to Bitcoin Lightning Network, it makes off-chain transactions and using main blockchain only as a guarantee of correctness and security, but Plasma Cash is the one that is promising more long term solution in bringing Ethereum to enterprise level. Plasma Chain scales the main chain by offloading transaction throughput to site-chain. The two leading implementations of Plasma Cash are Loom Network and OmiseGo and in this article I will walk you through Loomis implementation.

Three main architectural components of Plasma Cash are:

1. Client application
2. Root Chain
3. Plasma Chain

Root Chain hosts two smart contracts: ERC721 token contract (or any other custom implementation) and Plasma Contract. Role of the Plasma contract is to provide following functionality: handle deposit events and handle exit events.

Deposit

In order to transact ERC721 token on Child Chain one must first deposit its tokens to the Plasma Contract and in return receives Plasma Coin. Role of the Plasma Contract is to do following: handle deposit events and handle exit events.

Plasma Chain is operated and hosted by Operator. Role of the Operator is to listen to deposit events on the main chain, register the tokens, making the consensus that forms in the side chain and posting its information on to the main chain. An Operator is the bridge between the main chain and Plasma Cash side chain.

Proof-of-authority (PoA) is an algorithm used with blockchains that delivers comparatively fast transactions through a consensus mechanism based on identity as a stake. In PoA based blockchains, transactions (blocks) are approved by authorized validator account — Operator.

Plasma Chain is an Operator hosted blockchain. Plasma Chain core characteristics are:

• It consists of block and each block can contain one or more transactions. Each block maintains its own Sparse Merkle Tree.
• Users are free to spend or send to other users their Plasma Coins on the Plasma Chain.
• Periodically Plasma Chain submits the Merkle root of the current block to Plasma Contract, showing any changes in ownership of Plasma Coins.

Following diagram shows the interaction between user, smart contracts and Plasma Chain.

First step is that user sends some ETH to ERC721 smart contract. This triggers the transaction informing Plasma Contract that Root Chain has received deposit. In return User receives Plasma Coin (or what ever Operator is providing through his smart contract implementation). Each token has associated tokenId. Following structure presents the set of information that are related to the received coin:

struct Coin {
    Mode mode;
    State state;
    address owner; 
    address contractAddress;
    Exit exit;
    uint256 uid; 
    uint256 denomination;
    uint256 depositBlock;
}

When Plasma Contract is done with depositing users coins it emits Deposit event. For each deposited token user will receive back slot number and blockNumber. This information is cought by listening for Deposit emit.

// create a utxo at `slot`
emit Deposit(
    slot,
    currentBlock,
    denomination,
    from,
    msg.sender
);

UTXO (Unspent Transaction Output) is a transaction output which can be spent as input in a new transaction.

On the other side Plasma Chain is listening for Deposit events and when it receives the event calls the side-chain and creates the new block for deposit.

There are two types of blocks on Plasma Chain:

1. Deposit Block — includes only one transaction, DepositTransaction and it is always initial block
2. Plasma Block- may include many transactions

Type of the blocks can be identified by following

if (blockNumber % N != 0) then DepositBlock else PlasmaBlock

For every block in Plasma Cash chain the Merkle root of the Sparse Merkle Tree is stored in the main chain. This Merkle root is then checkpointed by an operator into the main Ethereum chain.

Spending Plasma Coin

So now that User has obtained Plasma Coins he can spend it or send it to someone else. As we have seen each token has associated tokenId. In order to send token to another user transaction object needs to be constructed. Transaction object has following data:

1. uid: unique position in Sparse Merkle Tree
2. previousBlock: pointing to previous transaction block. If this is a deposit, value is “0”. This creates a chain of history.
3. denomination: This is how much the specific token holds.
4. new_owner
5. signature: signature on the transaction’s hash
6. hash: unsigned hash of transaction details
7. merke_hash: signed hash of transaction’s details that is going to be included in the merkle tree
8. sender

Transaction is signed with Users private key and encoded using Recursive Length Prefix (RLP) encoding Schema. Transaction is sent to HTTP end point /send_tx on Plasma Chain API. Plasma Chain decodes the transaction object and performs validation. If transaction is valid it gets added to current block in Plasma Chain.

In order for receiving party to claim the token, sending party also needs to send to receiving party the history of the sent token. The history of the token consist of inclusion proof and exclusion proof.

Merkle proofs are used in order to decide upon following questions:

1. If the data belongs in the Merkle tree.
2. To prove validity of data being part of a dataset.
3. To ensure the validity of a certain dataset being inclusive in a larger dataset without revealing either the complete dataset or its subset.

Inclusion proof validates that token has at least one transaction associated with it from block with deposit transaction onwards and exclusion proof that there is no transaction related to token in question for block number that is bigger then block with deposit transaction.

So receiving user needs to verify token history to insure that token is valid before spending it. Following picture shows interaction between participants:

Exit

After sending and receiving tokens within the Plasma Chain, a user can exit to the main chain with the tokens they own at that current point in time. In order to exit, user has to submit a bond and proof that user currently owns the tokens.

In order to exit user needs to call startExit transaction and to provide following: slot number, blockNumber for the Plasma Coin in the previous block, Merkle proof for the Plasma Coin in the previous block, blockNumber for the Plasma Coin of the exiting block, Merkle proof for the Plasma Coin of the exiting block, and bond amount. Below is the function implementation:

function startExit(
    uint64 slot,
    bytes prevTxBytes, bytes exitingTxBytes,
    bytes prevTxInclusionProof, bytes exitingTxInclusionProof,
    bytes signature,
    uint256[2] blocks)
    external
    payable isBonded
    isState(slot, State.DEPOSITED)
{
    require(msg.sender == exitingTxBytes.getOwner());
    doInclusionChecks(
        prevTxBytes, exitingTxBytes,
        prevTxInclusionProof, exitingTxInclusionProof,
        signature,
        blocks
    );
    pushExit(slot, prevTxBytes.getOwner(), blocks);
}

By listening to the event StartedExit that is emitted from Root Chain, the user has a chance to protect themself from fraudulent transaction. This listening task can be automated by user application. If fraudulent exit has been detected user or user application can challenge it.

There are three types of exit challenges:

1. Exit Spent Coin Challenge — In this attack User 1 has sent coin to a User 2, after both parties verify its inclusion User 1 immediately attempt to exit the spent coin. User 2 must login before the end of the challenge period and provide proof of a direct spent of the coin. This challenge is implemented via challengeAfter function.
2. Exit Double Spent Challenge — in this case it is required that Operator allows inclusion of double spend transaction. The attacker, User 1 sends a coin to the victim User 2. After transaction has confirmed inclusion User 1 sends another transaction to User 3. From mainchain point of view both of users, User 2 and User 3 are valid owners of the coin. This challenge is implemented via challengeBetween function.
3. Exit With Invalid History Challenge — Consider that case that victim User 2 has coin that he does not intend to spend. Attacker, User 1 in collaboration with Operator creates the transaction that references invalid transaction from User 2 to User 1, effectively giving User 1 ownership of the coin and sends the transaction to User 3. After transaction gets included, transaction to User 3 can be used as a valid ancestor transaction. Taking advantage of the situation User 3 can use this coin to spend or sent to another user. This is exactly the reason why it is required for receiving party to validate the coin history. This challenge is implemented via challengeBefore and respondChallengeBefore function.

In summary challenge cases are modeled as following:

Conclusion

Plasma Cash is just one construction of Plasma that is helping to improve performance and scalability of Ethereum. Plasma Cash can be used to offload computational need from mainchain and provide high availability solution from app perspective, also enables cost effective and secure solution. For my analysis and research I used Loom implementation of Plasma Cash.

References

[1] https://medium.com/crypto-economics/what-is-plasma-plasma-cash-6fbbef784a

[2] https://medium.com/novamining/plasma-cash-new-scalability-solution-for-the-ethereum-network-f7c0b889db7d

[3] https://medium.com/finc-engineering/a-view-of-plasma-cash-for-ethereum-b608b934ec67

[4] https://ethresear.ch/t/plasma-cash-plasma-with-much-less-per-user-data-checking/1298

[5] https://medium.com/loom-network/plasma-cash-initial-release-plasma-backed-nfts-now-available-on-loom-network-sidechains-37976d0cfccd

[6] https://github.com/loomnetwork/plasma-cash

[7] https://github.com/loomnetwork/plasma-cash/blob/master/FullSpec.md

[8] https://karl.tech/plasma-cash-simple-spec/

[9] https://ethresear.ch/t/loom-network-plasma-cash-for-erc721-tokens/2385

The Blockchain Hub is an inclusive education and innovation hub, with a strong network of diverse alumni from many industry verticals. Would you like to add your voice to ours, and have your articles featured in The Blockchain Hub? Just send us a note at content@theblockchainhub.com

Disclaimer: The views and opinions expressed in this article are those of the author. They do not purport to reflect the policies, views, opinions or positions of The Blockchain Hub, any other agency, entity, organization, employer or company.