Understanding Blockchain Frameworks: Ethereum and Hyperledger Fabric
In training classes and workshops about blockchain framework (or platform) and application development, I always encounter questions showing that some concepts are mingled together. Question like “do I need an Ethereum mining node in order to get my ERC20 tokens” reminds me that we need a better way to understand blockchain frameworks.
To better articulate a blockchain framework, I find it helpful to divide it into two portions: the infrastructure and the application. This division helps us understand which concepts belong to which portion, and also understand how and why blockchain applications can be developed independently on top of the infrastructure.
Infrastructure, or sometimes it can be called network, is composed of the nodes and the software running on them. The nodes can be physical machines, virtual machines or containers. Software is the most soul, providing features and capability such as users (identity or accounts), transaction formation and processing, consensus protocol, and something unique to specific frameworks, like native currency and mining for permissionless blockchains, channel and identity management for permissioned blockchains, etc.
Application is composed of the code running inside the infrastructure (known as smart contract in general) and the client application interacting with the infrastructure. The latter serves as the accessing point from external world. A good blockchain framework should allow application development outside the actual deployment of the network. We do not need to deploy the network before develop the application. If our application can run on a small network (even of one node), it should run well in a bigger infrastructure.
With these, let’s examine these two most popular blockchain frameworks.
Ethereum and Hyperledger Fabric
These are the most popular blockchain frameworks currently. Ethereum is more a public blockchain, running for several years, and people keep developing application on this public blockchain. Hyperledger Fabric is an enterprise blockchain platform, enabling consortium application across business entities. At this point they are different.
Nevertheless, there are some common points that both are sharing as blockchain frameworks. Here I try to do a quick table for them.
Ethereum: the Infrastructure Portion
The infrastructure portion of an Ethereum network is a network of nodes running Ethereum client. These nodes have all the required capability to form a functioning Ethereum network.
As a public and permissionless blockchain, the Ethereum Mainnet is already up and running for years. It is a network of thousands of nodes, where the real ethers are used, and many miners are competing one another to maintain the robustness of network with economic incentive. Node can join and leave the Mainnet at any time.
Therefore in many cases we do not worry too much on the infrastructure, sometimes take it for granted that “it is working”. We keep developing new types of application on top of this robust and decentralized infrastructure. This is in the application portion of Ethereum network.
In real application development, we won’t begin with the Mainnet, due to the cost, speed of testing, etc. Instead we can use other Ethereum infrastructure to speed up our application development.
There are several live public Testnets, of real nodes running the software somewhere. As the name indicates, they are for application testing before being deployed on Mainnet. Testing ethers are used in Testnets. Currently we have Ropsten, Kovan and Rinkeby as the Testnets.
There are some good tools for Ethereum application development. Remix (link) is an online IDE for Solidity contract development and deployment, and Truffle Framework (link) provides additional testing capability and supports client application development as well. These tools come with Ethereum Simulators. An Ethereum Simulator gives you something like a real Ethereum network with user accounts and testing ethers. However it is just a process inside your localhost. They are good tools when you begin with Solidity contract coding. With them, we are good moving to the Application portion.
Ethereum: the Application Portion
Ethereum application is always known as Decentralized Application (DApp) as the contract code is executed across the network in a decentralized way.
The application can be roughly divided into two part, the contract code, and the client application interacting with the Ethereum network and the deployed contract code.
Currently the de-facto contract coding language is Solidity, although it is not the only one when this idea was born. A new coding language Vyper is also coming, claiming better security and auditability than Solidity.
The contract code after compilation is running inside the Ethereum nodes (in Ethereum Virtual Machine, EVM), and the result of contract code execution is to update the world state and/or any contract state.
Ethereum network comes with JSON RPC, a light-weight remote procedure call protocol, acting as the interface for external world. Besides directly calling, there are libraries for different programming languages and frameworks. For JavaScript it is the web3.js. With web3.js, client application written in JavaScript can perform any Ethereum operations including deployed contract code.
As mentioned above, a good framework guarantees that, the application developed on one Ethereum network should work fine in another. Tools like Remix and Truffle allow you to select which Ethereum network to deploy your contract code. For example, you always begin with coding on the Simulator, and after that moving it to one of the Testnets and finally Mainnet for application deployment. During this process you do not need to customize your contract code.
Here is an example of an ERC20 Token Contract. The same contract works across these Ethereum networks.
Hyperledger Fabric: the Infrastructure Portion
Unlike Ethereum being public and permissionless, Hyperledger Fabric is positioned as an Enterprise blockchain application framework. It is deployed in the business world, and mainly in a consortium model instead of as public as Ethereum network. For example, we can see a Hyperledger Fabric network deployed in the datacenters of participating banks for a trade finance network. There is no a public Hyperledger Fabric that we are deploying application on top of it, like what we do on the Ethereum Mainnet.
Hyperledger Fabric network is composed of nodes of different roles. Peers are those nodes keeping the ledger (blockchain of transactions and a world state database). Generally Peers are deployed in every participating organizations. Some designated Peer nodes, called Endorsing Peers or Endorsers, also execute contract code (called chaincode in Hyperledger Fabric). Orderers (or Ordering Service Nodes) are nodes providing consensus and generating block for Peer nodes to maintain the ledger. Membership Service Provider (MSP) and Certificate Authority (CA) handle the identity and permission in the network, etc.
A network can be as simple as a single peer and a single orderer, or complicated when it involves many organizations. As there is no public network that you can directly use, we need to have a network before we test our an application.
The network deployment involves the proper generation of signing key and certification for identity, initial configuration transaction for channel setup, docker containers as nodes of different roles, correct matching of certificates to the nodes and users, etc. Fabric-Samples from Hyperledger Fabric comes with tools and container images for bringing up networks.
Once the infrastructure is ready, and we can deploy the application on it.
Hyperledger Fabric: the Application Portion
The Application portion is composed of the chaincode and the client application. The chaincode is the code being executed inside the endorsing nodes when requested by the client application. After processing by Orderer and verification by all other Peers, the result is to update the ledger (the transaction logged in blockchain and the world state updated accordingly).
The activities related to chaincode include installation, instantiation and invoke/query. The actual chaincode deployment happens in instantiation when one specifies which channel the chaincode is to be deployed and the proper arguments requested in the chaincode. Upcoming interactions with the deployed chaincode are through invoke and query.
We only have Golang as the chaincode coding language at the beginning, and as of today we also have Node and Java. Hyperledger Ledger comes with software development kit (SDK) which facilitate the client application development when interacting with Hyperledger Fabric network. For example, we can use the Node SDK for Hyperledger Fabric (fabric-client module) if our JavaScript application interacts with a deployed Hyperledger Fabric network and the instantiated chaincode. Currently Node and Java SDK are officially released, while some other platforms like Python, Go and REST are available as well.
As mentioned above, a good blockchain framework should allow application development independent from the infrastructure. Therefore when we develop and test our chaincode, we can run a minimum setup of Hyperledger Fabric network so that we can focus only on the chaincode and client application, ignoring most complicated part in the infrastructure. So far I found the Basic-Network inside the Fabric-Samples are good enough. It comes with one CA, one Orderer and one Peer. It also provides CLI such that we can interact the network for testing. After chaincode and client application work in the basic setup, we can move it to another infrastructure to simulate a more real life use cases (e.g. multiple organizations and multiple peers)
For example, the Simple Asset Chaincode (sacc) in Fabric-Samples can run on Basic-Network, and can also run on the First-Network (also in Fabric-Samples), in which total four Peers are defined in two organizations, which more complicated endorsing policy.
Here is how the same chaincode can be deployed in various Hyperledger Fabric networks.
Conclusion
In this small article I try to use a way to better understand blockchain frameworks, by dividing them into the infrastructure and application portion. Each portion has its own design, and application development should be independent on how the infrastructure is evolving. We have some further exploration on both Ethereum and Hyperledger Fabric frameworks, and see how this division helps understand what is what and where.
Hope you find this article helpful. Don’t forget to give some claps.
