Plasma Blockchain Scalability Framework — An Off-chain Scaling Solution for Ethereum Blockchain
The size of the entire Ethereum blockchain has been growing exponentially and it leads to a situation that network participants have been trying to limit the blocks’ size as much as possible to prevent blockchain networks from sizing up with weaker processing performance and capability. This is namely the scalability limitation and the concerns have been growing over blockchain networks such as Ethereum as dApps built on it are currently unsustainable and many of us in the developer communities are searching for alternatives to move on.
There are two general approaches to scale blockchains namely the first-layer and second-layer solutions. The former is the so-called on-chain scalability solutions for which the base layer and the protocol level of a blockchain network are fundamentally re-architecuted, such as sharding and the transition of consensus protocol (PoW to PoS) in Ethereum 2.0. While the latter is the so-called off-chain scalability solutions, mainly for crypto-economics rearrangements rather than re-engineering or re-architecturing on the system core of specific networks, for which it extends its functionalities to the existing base layers such as the lightning network of Bitcoin blockchain and Plasma on Ethereum network which we will have a deep-dive in the following paragraphs.
So what is the craic with Plasma Scaling System?
There has been an off-chain scalability solution for the Ethereum blockchain network named Plasma — the scalable autonomous smart contracts. Plasma is a series of smart contracts running on top of a root-chain (Ethereum Mainnet) forming a trusted sidechains-of-sidechains network connected to a root-chain in a hierarchical and tree-like structure with enforced blockchain histories and MapReducible computations committed into a series of merkle proofs.
Plasma offers the necessary relief for the Ethereum network to help it scale to the required levels. It is a set of protocols and guidelines enabling the easy deployment of trusted side-chain layers connected to the overall jurisdiction on the root-chain. The goal is to enhance the scalability and reduce the transaction fees for the smart contracts and dApps as only merkleized commitments are broadcasted periodically to the root-chain with non-faulty states.
The idea is basically an application-specific scaling system developing layers of Ethereum smart contracts constructed on a per use-case basis, which can efficiently interact with the Ethereum mainnet (aka the “root-chain” in Plasma language) through branching off trusted side-chains within a mainnet smart contract, with bunch of off-chain transactions in later stages using mainnet as a guarantee of correctness and security, enabling the trusted sidechains-of-sidechains architecture and exponential increase in terms of scalability. The construction is achieved by having the root-chain to process only a small amount of commitments (or significant interaction only necessary in the event of dispute) from the child-chains so that the root-chain could act as the most secure and final settlement layer for all of its child-chains connected. Each child-chain functions as if its own blockchain with its own consensus protocols, and the proof of child’s validity is submitted and stored on the chain immediately below, instead of storing with entire computations.
A key property of Plasma chain is the so-called exit mechanism allowing users to abandon the chain and withdraw their funds to the root-chain should anything go wrong. This can then keep the related off-chain or on-chain parties in check by making it easy for every honest party to provide solid proofs about the ordered history of transactions and quickly challenge on-chain in the event of illegitimate exits/withdrawals.
Different Plasma Prototypes and Implementations
Once the Plasma chain is connected with the Ethereum mainnet, users will be able to send, receive and store cryptocurrencies such as ERC-20, ERC-721, stable-coins, and so on using the applications such as crypto-wallets. There has been a variety of Plasma implementations, examples could be like:
Plasma MVP (Minimum Viable Plasma)
As we all knew that Ethereum mainnet itself is account-based blockchain while Plasma MVP made use of the UTXO-based concept, which is more like a settlement blockchain consisted of stateless objects designating spendable coins/tokens as remainder transactions outputs that only the person who possesses the keys could spend them, similar to what we have had for the Bitcoin blockchain network. Plasma MVP allows for the creation of PETHs (Plasma Ethers) removing the need for two-phase confirmations providing for simpler transaction finality, resulting in increased throughput. UTXO model furthermore makes both fraud proofs and exits/withdrawals much easier via reducing the complexity significantly, and therefore anyone on the Plasma chain can exit with the unspent coins/tokens. The following is the implementation of checking if specific UTXO input (with unique utxo_id) has already existed in a specific block on specific chain (implying it has been spent already if found):
# To confirm if a specific UTXO has already been spentutxo_id = encode_utxo_id(blocknum, txIndex, outputIndex)if utxo_spent or utxo_id in temp_spent:
raise TxAlreadySpentException('unable to validate tx')if not validated_signature:
raise InvalidTxSignatureException('unable to validate tx')
Plasma made use of MapReduce, a framework for high-scale computation across thousands of nodes on the trusted side-chains (Plasma chain or its child-chains), formulated as complementary functions of mapping and therefrom, reducing the big data of transactional records across chains into smaller chunks between states. Plasma is also PoA-based (Proof-of-Authority) under which transactions are validate and blocks produced by authorised nodes (a group of designated validators who supply all of the liquidity for the participants of a PoA network in any Plasma chain). Implementing Plasma MVP includes a root-chain contract written in Solidity with a deployment script, Plasma client and wrapper for the root-chain API.
Plasma Cash
On top of the Plasma concept, there is one implementation called Plasma Cash (which is still compatible with the Plasma with DPoS as a consensus algorithm) which will only focus on the blocks containing the digital assets, ones in the network would like to track. Imaging a situation that a user redeposits a certain amount of ETH in an exchange, a new Plasma coin of the same value as the deposited ETHs will also be generated with a single unique ID which will then be identified in the Plasma chain and at that point to trace those tokens will be sufficient enough to simply read the position of the specific coin (aka the PETHs) in the Plasma chain, without reading all the previous blockchain histories of which the deposited ETHs have passed.
Plasma Cash prototype involves assigning unique token identifiers to ETH deposits (essentially for any cryptocurrencies in the future). This is based on the merkle tree model under which users need to only process the subsections of the merkle tree storing the transaction records without the need to go through the entire chain. It allows owners for transferring assets to the trusted side-chains while keeping the original values secure on the Ethereum mainnet and is done by assigning a unique ID to each of the Plasma operators. As such, much less data will need to be verified per user with the architecture structured in this way. The following code snippet demonstrates the merkle root computed to prove a specific leaf is actually in the merkle tree through returning true if both the computedHashand _rootHashdo match:
// To compute merkle rootbytes32 proofOfElement;
bytes32 computedHash = _leaf;
uint256 index = _index; for (uint256 i = 32; i <= _merkle_proof.length; i += 32) {
assembly {
proofOfElement := mload(add(_merkle_proof, i))
}
if (_index % 2 == 0) {
computedHash = keccak256(abi.encodePacked(computedHash,
proofOfElement));
} else {
computedHash = keccak256(abi.encodePacked(proofOfElement,
computedHash));
}
index = index / 2;
}// To validate if the specific hash and the computed hash matchreturn computedHash == _rootHash;
With the Plasma Cash implementation, it is essential for a decentralized exchange (DEX) acting solely as the operator/validator role and is limited to only an order-matching engine, and so the users possess the private keys to their own assets withholding blocks with rights to always resort to the exit procedures to get their digital assets out of the root-chain (e.g. via the PlasmaCash bridging) anytime as they wish. Features of Plasma Cash also facilitate significant larger blocks coupled with sparse merkle registry of digital assets traceable with an assigned ID, greatly increased scalability with streams of transactional activities in volumes much larger than what we can have on the existing Ethereum network.
Plasma Debit
Plasma Debit is fundamentally an extension of Plasma Cash, a second-layer solution on top of the Ethereum mainnet with partial payments and divisibility enabled. It is a set of bidirectional payment channels between asset holders, the chain users and the chain operators/validators, but with regular on-chain notarisation from the Plasma chain to the root-chain.
The Plasma Debit implementation is arguably much closer to an account-based model than an UTXO-based one (Plasma Cash is UTXO-based). For each account, there is a maximum cap that an account can hold and a fixed amount for which one can withdraw to the mainnet. Plasma Debit matters because it allows for cheap payments as well as micro-transactions with non-fungible tokens on the Ethereum network with very little resources needed to validate them, also allowing to transfer the entire account to another address.
// To demonstrate the account balance is consisted of maximum cap and the withdrawable amount and so all the related wallet address are mapped to the specific account balancestruct accountBalance {
uint256 maximumCap;
uint256 withdrawableAmount;
}mapping (address => accountBalance) public accountBalances;
The implementation is currently on one-validator-structure of the merkle tree which will limit the amount of liquidity and this leaves the model open to unprovable censorship of transactions (due to the fact that there is only one validator in the merkle tree). The validator can set their own fees for the network of providing liquidity and updating the account states. When it comes to potential withdrawal/exit from the Plasma chain, it will send the updated account balance to the members and return all the additional liquidities to the validator specified.
So A ‘Trusted Sidechains-of-sidechains Architecture’ is the key!
On top of the Plasma Cash, one may form a 3-layer blockchain network (or more than 3 layers based on the need of intended use cases which will anyway be a trusted sidechains-of-sidechains network) of running different trusted side-chains in production with different functions linked with the Plasma chains and the Ethereum mainnet as a backbone.
Plasma Chain will be the central clearinghouse/hub of the token transactions for different tokens involved in the use cases which will eventually linked with the Ethereum mainnet bridging with PlasmaCash for native ETH, ERC20, ERC721, etc.
In case further on-chain multi-cryptocurrency transactions would be carried out, for instance, we can enable the BTC/stable-coin transactions in the system, a built-in decentralized-exchange functionalities could be added on to the layer 2 — PlasmaChain, for this case a PETH (Plasma ETH) will be the native currency for payments and so the respective identical value with the ETH in the mainnet will be processed with a single unique ID assigned so that all the processed transactions on the PlasmaChain could later be integrated with the mainnet in one go without paying the gas fee every single time when there will be a transaction processed.
On top of the PlasmaChain, there will be trusted child-chains (layers with a bunch of smart contracts designed for specific purposes based on the use cases) deployed and linked with the PlasmaChain instead of linking with the Ethereum mainnet directly. With that logic being deployed, incentives and rewards for the miners or governance-related activities such as voting on certain initiatives for the communities or amongst the platform users/validators could happen and be processed instantly without paying any gas fees per transaction as it will be “cached” and processed in the exchange with ETH in PlasmaChain which will eventually be synced with the mainnet, be withdrawn the necessary ETHs, and then settled the total amount of gas required for a series of transactions all in one go.
The trusted sidechains-of-sidechains blockchain network could be a solution for frictionless blockchain platform for different sorts of ‘on-chain’ transactions in our future token system, as the layer-3 child-chains would handle all the individual mechanisms with specific purposes while all the transactions will take place and be stored on the layer-2 PlasmaChain for later withdrawal to the Ethereum mainnet. Building on top of the Ethereum mainnet also allows network operations to be carried out more efficiently as it will separate the transactions processed on the trusted side-chains from the security layer of Ethereum mainnet.
Is there any concern over all the existing Plasma implementations?
A major concern with the Plasma implementations is the concept of mass exits/withdrawals from the trusted side-chains (when it happens in a relatively short period of time for the worst-case scenario). For the situation of mass exits from the Plasma chains (including child-chains), a coordinated and simultaneous exit from the child-chains would potentially result in a lack of processing capacity to withdraw all the requested funds in one go, based on the fact that Plasma MVP was initially designed to only support exits of individual UTXOs. Consequently, platform users could lose funds carrying out such processes when tons of exit/withdrawal operations would happen simultaneously on the platform as each of the exit/withdrawal transactions will be open to challenges among the platform users before being validated and so the merkle proof of the required challenge transactions will need to be computed, not to mention there will be different checking efforts required for different child-chains, related blocks, groups of individual utxo_idanduid, before finalizing an exit/withdrawal request. A sample function of finalizing the exit request (to move all the funds from all the related wallets and remove the uid involved) could be the following:
// To finalize the exit request, given different checking efforts have been done, so as to move all the related funds from consisting wallets and remove the uid specifiedfunction finalizeExitRequest(uint uid) public {
require(exits[uid].hasValue);
require(now >= exits[uid].exitTimestamp);
for (uint i = 0; i < challenges[uid].length; i++) {
require(!challenges[uid][i].hasValue);
} exits[uid].owner.transfer(wallet[uid].amount);
delete exits[uid].hasValue;
}
The concern on mass exits/withdrawals has been taken into account and the Plasma community has been working on the mitigation to it: even in the original Plasma paper, one could already notice a suggestion on a mass-exit protocol representing UTXOs using a bitfield, which is essentially a big pointer to a list of UTXOs in which each bit is pointing to a specific UTXO, optimizing the UTXO aggregations based on a pre-defined consensus mechanism under which these aggregated UTXOs will be combined into another merkle tree with a root called ‘aggregations root’ alongside different related transactions linked under individual block roots.
Summing up The Plasma Framework Implementation
It is a widely held view that the off-chain Plasma scaling solution could bring a whole new realm of transaction speeds to current Ethereum blockchain systems which are fundamentally limited at the moment. By using trusted sidechains-of-sidechains structure, Plasma can take the pressure off the root-chain with additional security protocols and bunch of trusted side-chains.
Users will be able to send, receive and store cryptocurrencies via the trusted side-chains using the applications such as crypto-wallets, while the Plasma chain connected with the Ethereum root-chain. The capability and interoperability could further be extended to support additional cryptocurrencies, working toward a fully cryptocurrency-agnostic exchange and it is what the decentralized exchange networks such as OmiseGo (OMG) has been working very hard to achieve. Plasma already has a working MVP with OmiseGo and the group is currently working on a Plasma Cash implementation along with Ethereum.
There have been off-chain scaling solutions for other blockchain networks such as the Raiden Network — Ethereum’s version of Bitcoin’s lightning network which is also compatible with ERC-20 token transfers onthe so-called bidirectional payment channels with add-on features such as instant payments, micro-payments, improved transaction privacy and atomic token swaps.
While Plasma is still under development and is expected to take time to achieve with full PoS alongside the Tesuji Plasma mainnet depolyed, attention has been drawn to zero-knowledge blockchain implementations such as zk-snarks and zk-starks (there will be another deep-dive on them written up in the future) which are forms of cryptography allowing developers to aggregate transactions into batches, pioneered by the privacy-centric cryptocurrency such as zcash. In fact, many startups have already been embracing the tech and look to scale the network amid other efforts to upgrade and expand the Ethereum network with finality and interoperability across multiple blockchain networks as well as the further minimization of blockchain exit risks with the aforementioned zero-knowledge blockchain frameworks. Though the Plasma concept has been widely heralded as Ethereum’s best bet for short-term scaling solutions, it looks like SNARKs and STARKs might steal the show and be able to save the crypto-world as a whole or at least come up with scaling solutions dealing with privacy limitations…
