Plasma-The Solution for Security and Scalability

The Scalability Issue

Blockchain always faces the trade-off issue between security and scalability. Though their PoW consensus protocol guarantees near perfect security, it also slows down the processing speed significantly.  Currently, the Ethereum processing speed is 15 transactions per second while Bitcoin is 7 transactions per second. Both platform’s processing capacities are nowhere near Visa’s processing speed of 45,000 transactions per second. Furthermore, the increase in the number of dapps deployed on the main Ethereum main chain has caused congestion and slows down transactions tremendously. One of the most famous cases is Cryptokitties, it clogged up the Ethereum network in just a few weeks of deployment due to its unprecedented popularity.

In seeking a viable solution to the scalability issue, Vitalik Buterin and Joseph Poon have joined hands in conceptualizing and developing Plasma, a framework that can scale Ethereum processing power.  Joseph is also the co-founder of the Lightning network, a framework that has greatly increase Bitcoin processing speed. Both plasma and Lightning network are trustless multilayered blockchain networks.

Plasma

Plasma is a  system that comprises the main blockchain and the ‘child blockchains’ that branch out from the main blockchain(aka parent blockchain or root blockchain). The child blockchains can co-exist but function independently from the parent chain and each other. 

The Plasma system allows anyone to create their own child blockchains a.k.a plasma chains with their own smart contracts. Therefore, the Plasma system enables the creation of all kinds of use cases based on different business logic in their smart contracts. To ensure security, the root chain monitor and enforces the state in all the plasma chains and penalize the bad actors if there is proof of frauds.  In this way, the Plasma system makes off-chain transactions possible while relying on the Ethereum main blockchain to maintain its security. 

The Plasma Structure

Actually, the Plasma architecture is like a tree structure with the main Ethereum blockchain as the root. The child blockchains then branch out from the root blockchain, similar to branches grown out from the root of a tree. Every child chain, in turn, can spawn new child chains, the process can go on.  Therefore, the plasma structure constitute a hierarchy of blockchains,  as shown below:

Plasma Blockchain Structure

How does Plasma Works?

Plasma can greatly increase processing speed and throughput on the Ethereum blockchain because it allows off-chain transactions, similar to the payment channels of the Lightning network and other off-chain technologies. All the off-chain techniques take operations away from the main Ethereum blockchain.

State Channels

The concept of Plasma was derived from State Channels but improved on the latter. State channel works by creating an off-chain communication channel (a.k.a state channel )where transactions are not sent to the smart contract on the main chain, instead, they are sent through the Internet without touching the main blockchain.  It is only after all the transactions have been completed (for example, a crypto game has finished) that the final state is sent to the smart contract on the main chain, closing the channel in the process. The smart contract will check the legitimacy of the transactions and release the asset (such as some ETH or a prize) to the recipient. 

The state channel technique can improve scalability because it can reduce the number of transactions on the main blockchain. For example, a crypto chess game played between two players may involve hundreds of moves, which means hundreds of transactions will be executed on the Ethereum blockchain. However, if we use the state channel, we need to execute only 3 transactions that include registration of the players to initiate the game, submission of the final state to the blockchain and closing the channel. 

Steps in Implementing Plasma

Plasma works in a similar way but with a different approach. Instead of creating the channels, it creates the child blockchains, as illustrated earlier. Smart contracts are created on the main Ethereum blockchain(The root chain) and they  define the rules in the child blockchains. In other words, the smart contract serves as the root of the child blockchains. The child blockchains can employ their own consensus algorithm, such as proof of stake.  The blocks validator will submit the state of the child chain to the Root Chain smart contract periodically. The smart contract will register the state of each Child Chain in the form of block hashes of the Child Chain.

We can illustrate how Plasma works by examining a crypto game such as crytant crab or cryptokitties. The smart contract on the main chain will set the rules of the game, then deploy the actual game application smart contracts on the child-chain, which contains all of the game logic and rules.  The game assets such as characters or collectibles are created on the Ethereum main chain and then transferred onto the child-chain using the plasma root.  When the players play the games, all the executions are confined to the child chain, without interacting with the root chain. 

Plasma Exits

Plasma Exits is a  security mechanism behind Plasma that allows users in a Plasma Chain to stop participating in the chain, and move their funds or assets back to the root chain. When a user wishes to exit a particular child chain, he or she needs to submit an exit application.  The application is not immediately approved because a proof is required. This waiting period is called the challenge period, which means anyone can challenge the user’s claim by submitting a fraud proof. If the challenge is not valid or there is no challenge, the application will be approved and the user can exit and collect back his assets or funds.

Plasma is still evolving and now the Plasma team has come out with the improved version of Plasma known as Plasma cash.  We shall discuss this new version in coming articles.

References

ETHKL #5 : Security Audits & Scaling

The meetup was at HelloGold office , KL on Friday 23, Nov.

Speakers:

  1. Petar Tsankov-Chief Scientist/co-founder of ChainSecurity AG & Senior Researcher at the ICE center. ETH Zurich. 
  2. Andras Kristof- Founder and Advisor of Akomba Labs
  3. Lai Ying Tong- Researcher at Ethereum Foundation
  4. Ken Chan

The session began with Ken Chan introducing the audience about Zero-Knowledge Proofs. I was sure many developers among the audience understand what it is but the concept sounds strange to me. Fortunately, Ken was good in demonstrating the concept by using the scenario of the American presidential election involving Trump and Clinton as well as a “live demo” with Harith of HelloGold as the co-actor.

Apparently, the Zero-knowledge proof method, or more exactly zk_SNARKS, is a consensus protocol used by Zcash to validate its shielded transactions that are fully encrypted on its blockchain. According to Zcash(https://z.cash/technology/zksnarks/), the acronym zk-SNARK stands for “Zero-Knowledge Succinct Non-Interactive Argument of Knowledge,” and refers to a proof construction where one can prove possession of certain information, e.g. a secret key, without revealing that information, and without any interaction between the prover and the verifier.

Zcash further pointed out that “Zero-knowledge” proofs allow one party (the prover) to prove to another (the verifier) that a statement is true, without revealing any information beyond the validity of the statement itself. For example, given the hash of a random number, the prover could convince the verifier that there indeed exists a number with this hash value, without revealing what it is.

Ken illustrated the process of Succinct and Non-interactive using a diagram, where the prover begins by generating a proof string and then the verifier needs to verify the proof string, as shown below:

The above process is actually more complex than illustrated in the diagram. According to Zcash,  zk-SNARKs work by first turning what you want to prove into an equivalent form about knowing a solution to an algebraic equation, as follows:

Computation → Arithmetic Circuit → R1CS → QAP → zk-SNARK

Here is an example of what an arithmetic circuit looks like for computing the expression (a+b)*(b*c) :

Diagram Adapted from Zcash

The output is then verified by the verifier. However, Ken pointed out that the process might be compromised by some malicious codes which he called toxic waste that produce false proofs. Ken concluded with the following points:

Why ZK SNARKs?

  • Strong cryptography research by Zcash team
  • Math-based- not coin joining
  • Short proofs

Why not ZK SNARKS?

  • Trusted setup for every contract
  • No transparency for counterfeiting
  • Computationally expensive

Next, Dr.Petar from ChainSecurity discussed the importance of security audit. His topic was “How Not to get Hacked”. ChainSecurity is a smart contract auditing platform. They can identify security vulnerabilities and certify the functional correctness of smart contracts and blockchain projects. 

ChainSecuity has developed an Audit platform that can perform Automated Security Check on smart contracts. This platform can test and audit both Ethereum smart contracts (Security Scanner)and the Hyperledger Fabric chaincode(Chaincode Scanner).

According to Dr.Petar,  more USD$1 billion have been stolen this year due to crypto hacks. He stressed that writing secure smart contracts is difficult.  Developers might fail to see bugs and security flaws, therefore we need to audit the smart contracts.  However, currently, most audits are done manually and tend to miss many issues. Furthermore, in the post-development stage, most anomalies are invisible. 

To work around the aforementioned issues, ChainSecurity has developed some AI-based automated tools to help in every stage of smart contract lifeline. At the developmental stage, the automated tools will assist in certifying the correctness of the code. At code audit stage, the machine-checked audit will generate the audit report by committing the smart contract onto the Audit platform which runs security auditing using the security scanner, the symbolic verifier and the AI-based Tester. Finally, in the post development stage, there are monitoring tools to help track the smart contract health.

More information on security audit can be found on ChainSecurity website.

The final topic was scaling presented by Andras Kristof and Lai Ying Tong.  This is a topic where all Ethereum enthusiasts are concerned about. According to the speakers, the solution is to develop a two-layer architecture. Layer 1 is called serenity which comprises sharding, casper, random beacon, and p2p networking. Layer 2 comprises payment channels, state channels, sidechains, and plasma. The solution also comprises succinct proofs using snarks and starks. Furthermore, there are more integrations that include swarm, light clients and client optimizations.

In more details, the layer 1(serenity) structure includes the Main Chain(provides staking and PoW), the Beacon Chain((provides random number and PoS), the Shard Chain(provides data) and VM(provides state execution result).

For the payment channels, there are two channels, the Open Channel and the Close Channel. The transactions include blockchain transactions and Off-chain payments. Besides that, Lai also spoke on payment channels on the lightning network. The layer2 solutions are to move state-modifying operations off-chain, which include payment channels and state channels.

Besides that, Lai also covered topics on sidechains, plasma mvp, morevp, swarm, light clients and more. These are heavy topics and I shall discuss them in future articles.

Hyperledger Fabric Architecture Part 2

In my article ” Hyperledger Fabric Architecture Part 1“,  you have learned about the client applications, endorsing peers and committing peers as well as well as the ordering service. We have also discussed the transaction workflow and how consensus is reached. In this article, I shall explain the channels and membership service provider.

Channels

In permissionless blockchains like Bitcoin and Ethereum, all peers share and have access to the same ledger. However, this kind of blockchain may not be suitable for business applications. For example, a supplier may want to set different prices for different wholesalers, and he would not want everyone in the supply chain to view this information. In this scenario, he or she will prefer to deal with the different wholesalers separately. To solve this issue, Hyperledger Fabric came out with the novel concept of channels that allow private transactions within the same network.

Channels partition the Fabric network in such as way that only the stakeholders can view the transactions. In this way, organizations are able to utilize the same network while maintaining separation between multiple blockchains.  The mechanism works by delegating transactions to different ledgers. Members of the particular channel can communicate and transact privately. Other members of the network cannot see the transactions on that channel. The concept is illustrated in the following diagram:

The diagram above shows two channels, channel 1 and channel 2. Each channel has its own application, peers, ledger and smart contract (chaincode). In this example, channel 1 has two peers, P1 and P2 and channel 2 also has two peers, P3 and P4.  Ordering service is the same across any network and channel.

Application 1 will send transaction proposals to channel 1. P1 and P2 will then simulate and commit transactions to ledger L1 based on chaincode S1. On the other hand, Application 2 will send transaction proposals to channel 2. P3 and P4 will simulate and commit transactions to ledger L2 based on chaincode S2. 

Though our example shows peers belong to two distinct channels, in actual case peers can belong to multiple networks or channels. Peers that participate in multiple channels simulate and commit transactions to different ledgers. In addition, the same chaincode can be applied to multiple channels.

Membership Service Provider (MSP)

Hyperledger Fabric is a permissioned blockchain, therefore, every user needs permission to join the Fabric network. In order to obtain permission to join the Fabric blockchain network, the identity of every user must be validated and authenticated. The identity is  important because it determines the exact permissions over resources and access to information that user has in the Fabric network.

To verify an identity, we must employ a trusted authority. In Hyperledger Fabric, the trusted authority is the membership service provider (MSP).  The membership service provider is a component that defines the rules in which identities are validated, authenticated, and allowed access to a network. The MSP manages user IDs and authenticates clients who want to join the network. This includes providing credentials for these clients to propose transactions, defining specific roles a member might play and defining access privileges in the context of a network and channel.

The MSP uses a Certificate Authority to authenticate or revokes user certificates upon confirmed identity. In Fabric, the default Certificate Authority interface used for the MSP is the Fabric-CA API. However, organizations can choose to implement an External Certificate Authority of their choice.  Hyperledger Fabric supports many types of External Certificate Authority interfaces. As a result, a single Hyperledger Fabric network can be controlled by multiple MSPs.

The Authentication Process

In the authentication process,  the Fabric-CA identifies the application, peer, endorser, and orderer identities, and verifies them. Next, a signature is generated through the use of a Signing Algorithm and a Signature Verification Algorithm.  The Signing Algorithm utilizes the credentials of the entities associated with their respective identities and outputs an endorsement. The generated signature is a byte array that is bound to a specific identity.

In the following step, the Signature Verification Algorithm will accept the request(to join the network) if the signature byte array matches a valid signature for the inputted endorsement, or reject the request if not. If the user is accepted, he or she can see the transactions in the network and perform transactions with other actors in the network. On the other hand, if the user is rejected, he or she will not able to submit transactions to the network or view any previous transactions.

We shall explore chaincode in the next article.

Hyperledger Fabric Architecture Part 1

In a previous article, you have learned that Hyperledger Fabric has a highly modular and configurable architecture.  In this article, we shall examine the architecture in more details.

Hyperledger Fabric Network

Hyperledger Fabric is a permissioned blockchain network that provides ledger services to application clients and administrators. It allows multiple organizations to collaborate as a consortium to form the network.  The permissions to join the network are determined by a set of policies that are agreed to by the consortium when the network is configured. The network policies may change over time subject to the agreement of the organizations in the consortium.

The Hyperledger Fabric network comprises the following components:

  • Ledger 
  • Peers
  • Ordering service
  • Chaincode (aka smart contract)
  • Channels
  • Membership service provider

The Hyperledger ecosystem also consists of the client applications that allow users to interact with the network.  Moreover, The Hyperledger Fabric application SDK provides a powerful API for developers to program applications to interact with the blockchain network on behalf of the users.  

Peers

The Fabric network is comprised primarily of a set of peers or nodes. Peers maintain the state of the network and a copy of the ledger. In addition,  they also host smart contracts(chaincode).

There are two different types of peers in Fabric, the endorsing peer and the committing peer. The endorsing peers (aka endorsers) simulate and endorse transactions. On the other hand, the committing peers (aka committers) verify endorsements and validate transactions before committing transactions to the blockchain. On a separate note, the endorsing peers can also commit transactions to the blockchain. Indeed, the endorsers are special kind of committers. However, the committers cannot be the endorsers.  All peers can commit blocks to the distributed ledger.

Ordering Service

The ordering service is  made up of a cluster of special nodes known as orderers. The ordering service accepts the endorsed transactions and specifies the order in which those transactions will be committed to the ledger.  However, It does not process transactions, smart contracts, or maintains the shared ledger. 

The Transaction workflow

Let’s examine the transaction workflow that involves the client applications, the peers and the orderers.  By examining the entire transaction workflow, we will learn how consensus is reached in the process.

The transaction flow to reach consensus consists of three phases:

  • Transaction endorsement
  • Ordering
  • Validation and commitment

Phase 1 Transaction Endorsement

Transactions begin with client applications sending transaction proposals to the endorsing peers, as shown in the following diagram:

Phase 2 Transactions Simulation

At this phase, the endorsers will simulate the proposed transactions, without actually updating the ledger.  The Endorsers must hold smart contracts in order to simulate the transaction proposals. In the simulation process, the endorsing peers will capture the set of Read and Written data, known as RW Sets.

These RW sets contain data that was read from the current world state while simulating the transaction, as well as data that would have been written to the world state had the transaction been executed. The endorsing peers then sign these RW sets and send them back to the client application for use in the next phase of the transaction flow, as shown below:

Phase 3 Ordering 

At this phase,  the client application submits the endorsed transactions and the RW sets to the ordering service. The ordering service will take the endorsed transactions and RW sets and orders them into a block and delivers the block to all committing peers.

The order of transactions needs to be established to ensure that the updates to the world state are valid when they are committed to the network. Unlike the Bitcoin blockchain or Ethereum, where ordering occurs through mining, Hyperledger Fabric allows the organizations to choose the ordering mechanism that best suits that network.

Hyperledger Fabric provides three ordering mechanisms i.e. SOLO, Kafka, and Simplified Byzantine Fault Tolerance (SBFT). However, SOLO is used only for experimentation purposes and SBFT has not yet been implemented. Therefore, Kafka is the default ordering mechanism for production use. The Kafka mechanism provides a crash fault-tolerant solution to ordering.

Phase 4 Transactions Validation

At this final phase, the committing peers validate the transactions by checking that the RW sets still match the current world state. In addition, they need to ensure that Read data that existed during the simulation process is identical to the current world state.

After the committing peers validated the transactions, the transactions are then written to the ledger, and the world state is updated with the Write data from the RW Set. Committing peers are responsible for adding blocks of transactions to the blockchain and updating the world state.  Lastly, the committing peers asynchronously notify the client application the results of the transactions.

I shall discuss channels, membership service provider and chaincode in another article.

Gas, Gas Price and Gas Limit

What is Gas?

By definition, gas is a unit that measures the amount of computational effort that it will take to execute certain operations on the Ethereum blockchain. The operations include sending tokens, deploying a smart contract, interacting with a contract, sending some ETH, launching an ICO, or anything else on the blockchain. Gas is needed to power the Ethereum Ecosystem, just like fuel is needed to power a car.

What is Gas Price?

As I have mentioned earlier, we need to use gas for every operation made on ethereum, regardless of whether your transaction succeeds or fails. Gas does not come free, we need to pay for it, just like paying for the gasoline in order to drive our cars. How much transaction fee we need to pay depends on the gas price and the gas limit.

Gas price is the amount of Ether you need to pay per unit of gas. It is measured in Gwei (1Gwei=0.0000000001 ETH).  Its value is determined by the miners, who can refuse to process the transaction with less than a certain gas price. The transaction fee is paid to the successful miner as a form of incentive that motivates the miners to maintain the nodes. Therefore, they have the controlling power over the gas price. We must have enough ether in our wallet to pay for the gas fees.

The transaction fee is calculated using the following formula

Transaction fee= Gas unit used x Gas price

For example, for a certain transaction,

gas unit used=103631

Gas price= 1Gwei or 0.000000001 Eth

So transaction fee= 103631×0.000000001 Eth=0.000103631 Eth  

You can see the actual output in a smart contract deployment on Etherescan, as shown in the figure below:

In addition, you can “bribe” the miners to do your work first by paying more gas fees. In this way, you can jump to the front of the queue so that your transaction can be processed first.  Even if the transaction fails, you still need to pay for the transaction fee because the miners must validate and execute your transaction.

Gas Limit

The Gas Limit is an estimation of the total amount of work to perform a transaction. It is not easy to compute the gas limit. Fortunately, there are many apps that set the limit for us. Typically, 21,000 Gas will satisfy most transactions. However, for more complex transactions such as sending ETH to an ICO smart contract, the gas limit will be much higher. The reason is such a transaction requires much more computational power.

If you set the limit is too low, your transaction may take too long to process and even fail. As a result, you will lose ETH for nothing. On the other hand, if your transaction was completed before reaching the gas limit, you get back the balance ETH. The Gas Limit protects you from spending unlimited ETH, just like what banks set your credit card limit so that you will not overspend.