Private BlockChain Implementation on Ethereum — QA strategy (Essential components of private blockchain) — Part 3
In continuation to my last blog where I was not able to cover the essential components of private blockchain platform with their intended functionality, I will not deviate from the topic as most of you will be interested more on this topic as it will actually provide you the insight of private blockchain platform. Before starting that I would recommend to go white paper on Ethereum https://github.com/ethereum/wiki/wiki/White-Paper to understand some of technical jargon. I do understand that going through the link I mentioned is not that interesting but I would suggest to at least search for technical words which you don’t understand in following section.
Why Ethereum is first choice for private BlockChain platform based decentralized application?
Generally, Ethereum is programmable blockchain platform where features of the decentralized application can be programmed based on the specific need. This is the reason Ethereum has been the first choice for designing private blockchain for other industry apart from building cryptocurrencies. Please refer following video link to understand how can Ethereum blockchain platform be installed How to install private Ethereum blockchain.
Ethereum Components that support BlockChain platform defined guidelines
- Virtual Machine (EVM) — Ethereum has EVM which is same concepts of having run time environment like JRE. EVM component is actually makes Ethereum platform Turing complete machine where you can execute contract written in Solidity, Serpent etc. Now a days, there is high attraction towards Solidity programming to design contract.
- Peer to Peer Networking — Ethereum also support Peer to Peer networking (go-ethereum/p2p) which helps to make connected nodes to communicate with each other. Adding can be done by using geth client (I will soon upload a video on you tube on setting up local ethereum network with adding peer in running network).
- Consensus Algorithm — In private blockchain platform, there is no need to have reward based mining like Proof of Work & Proof of Stake. Any consensus algorithm like RAFT & PAXO which are like to have Leader of the nodes of predefined number of node clusters. When I say predefined it means Network knows how many nodes are there in network. Raft & Paxo algorithm is designed to have one Leader that would validate the messages ( in other word collection of transactions sent in a block within defined block creation time) sent over the network for processing. I would suggest to go through with following video to understand RAFT consensus in simple words (RAFT Consensus by Diego Ongaro). I am really thankful for this video as it is really easy to understand how does it implemented.
- Storing of BlockChain Data & its state — Ethereum supports to store blockchain data into Merkle trees for the scalability. As per github explanation, it says “Merkle Patricia tries provide a cryptographically authenticated data structure that can be used to store all (key, value) bindings.” There are lot of key-value storage db available with very performance e.g. RocksDB, LevelDb etc. Recently I heard about BadgerDb that is so much faster then RocksDB. As per wiki definition, “A trie is also known as digital tree which is a kind of search tree — an ordered tree data structure that is used to store a dynamic set or associative array where the keys are usually strings”. In Private blockchain, Key-Value storage can be implemented to be synced within RDBMS where user can easily query the data as extracting data from key-value storage needs bit technical expertise or additional component to support accessing data for business user.
Additional Components that helps to design private blockchain infrastructure by using Ethereum guidelines & components (Controlling involved infrastructure with proper permission control for various functionalities)
- Restful web service Endpoint — As Ethereum supports lots of inbuilt functionalities (refer my videos how to setup Ethereum on window machines with default functionalities offered by Ethereum) that can be exposed to various interested parties within Domain. Next topic explains what is Domain in simple words (I know most of you will be knowing Domain more than me). By exposing restful endpoints, parties given access to specific functionalities can be used without being part of blockchain network. In reality, within any organization IT infrastructure, there is always a need to integrate within existing upstream & downstream applications. Integration of private blockchain within existing infrastructure gets stabilized by defining these end points without even participating in blockchain.
- Permission on BlockChain components — Let me clarify what is domain as you know each organization has domain to control the access of their infrastructure. Similarly while designing private blockchain decentralized application, it becomes imperative to setup permission on the blockchain network infrastructure & their involved components. Major difference between public & private BlockChain is any node/server/computer can join public blockchain whereas to join private network node/server/computer should have right permission to join the network. Permission to join network can be controlled by main Leader of the network. To segregate these roles like who can be either Leader or Follower or Candidate, there is need to defined group like we our IT people usually do to control the access within organization or user groups for any application etc.We can consider something like Validator group whosoever will be part of this group can only be leader of the network. Major role of leader is to support message/contract processing & consensus process for all the involved nodes. Another group can be Observer, nodes which are part of this group will get all the messages/contracts processed on the network with capability to send request to process message/contracts. Observer can not participate in Consensus. There is no need to define Candidate as Consensus algorithm automatically takes care for making any node candidate. Whosoever node gets down becomes candidate. There is concept with consensus that candidate may become next leader of the network but for now keep it very simple as within Private BlockChain we need to maintain only one Leader as long as we can which is quite opposite to what RAFT consensus recommend.
- Storing of BlockChain Data in Relational Database — In order to achieve high performance over the network, Key-value pair database are used to store blockchain database. Accessing these databases are not very user friendly & requires some technical expertise to do so. It is good idea to have one node where we can have key-value pair DB dump into Relational database so user can access the data by SQL queries.
By combining Ethereum Components & Additional Components, A private blockchain can be designed to facilitate interaction between multiple trusted parties (interaction through nodes) by executing codes automatically or on wish of involved parties. There are many more components like key-value storage syncing in Relational database to ease down the data extraction from blockchain data for analysis or reporting….
Stay tuned for next part where I will be covering how those components can be tested with which technology & tools. Also, My plan is to come up with some generic approach or framework to do QA of private blockchain product development within Agile methodology so if anyone has any suggestion or real time experience to share, please feel free to share with me……Keep learning & stay hungry for upcoming transformation…..
BlockChain Evangelist & Enthusiast-Building Generic Automation Framework for BlockChain DApps for Ethereum at Startup