Private BlockChain Implementation on Ethereum — QA strategy (Testing Techniques & Tools for Essential components — BlockChain Data Storage — Part 7

Let me start with Elon Musk best advice “ If you need motivational words or inspiration to accomplish something then you should not do that.” This phrase really helps me to decide where I should focus & where not. In other words I got some clarity in terms of deciding when you are in situation with multiple choices or opportunities. Recently that happened to me when I started to learn Blockchain technology as there were Deep learning, Machine Learning & Artificial Intelligence for me to go about however I choose BlockChain. Reason was simple — I always wanted to understand networking concepts along with cryptographically secure communication of data over the various networking layers. By now if you are reading this post then you would have this sense that BlockChain platform is P2P networking with use of cryptography concept to store data in hash form within chain of blocks to ensure immutability of data.

Block Data Structure — In which format data gets stored in blockchain as name itself suggests that it is a chain of Blocks.So next question comes in mind What is block & how it stores the data then? As far as I understand the Ethereum implementation, Block Structure is completely depends for which business use case blockchain platform is being used & what kind of data is required to support that application. Since Ethereum blockchain stores everything in the form of hashes so it is necessary for us to know what is Hashing. Hashing is way of encryption which consumes variable size inputs & generates fixed length encrypted value. In general, following are the generic fields which I think are important for QA to understand first.

1. Previous block hash
2. Block Header
3. Current block hash
4. Transaction data
5. Nonce
6. Gas Limit & Gas used
7. logs bloom, difficulty, block number & many more

No need to worry about other fields as there are many more but as per my experience for functional testing we should first understand first 6 fields in more detail followed by some basic understanding for rest of the fields as those are more conceptual for having other fields.

1. Previous block hash — I thought to explain Previous block hash first as having previous block hash in current block ensures the integrity of chain. It is really important for QA to verify whether the hash of previous block is same as it is present in current block. Follow this pattern to check whether the integrity of blocks has been maintained or not. This verification can be easily framed in any programming logic but you need to know in which kind of DB data is being stored. As performance for any application is utmost important so any key-value storage lying within node itself is most suitable option. Ethereum client implemented in GO language uses levelDB & due to better performance developer can choose RocksDB as well. BadgerDB is also claiming some performance improvement over RocksDB so it is completely depend what suits to your development team to choose data storage database.

2. Block Header — In ethereum, Block Header is used to reduce the overhead of replicating complete blockchain data on all the involved nodes. So having only block header helps nodes to verify the data. Now question arises how can block header do that for any specific node? To answer that we need to understand the what information Block header contains. Block header contains — 1. State Root , 2. Transaction Root, 3. Receipt Root

These roots are derived from Patricie Merkle Trie ( please click me to get more insight) which is nothing but a kind of data structure which stores data into hash form. To understand about Merkle tree ( please refer What is Merkle Tree?) In simple words hash value of any of the root represent complete information about data store within it & which can be used to verify the underlying data. State root represents the state of network as it is really important to know about the state of network at any given point in time. Transaction Root can be understood like what data has been requested to process to get the sense about transaction rather knowing complete detail of each transaction. Receipt Root is the response of the network for each message which is processed by the network. From QA standpoint, these level of insight is not needed at the moment but good to know these concepts from overview perspective.

3. Current block hash — Block hash is just hash generated by passing various fields along with some mandatory fields likes previous block hash, nonce, timestamp, transaction data, blockheader etc.

4. Transaction Data — Transaction data can be referred as change in state of the network. Now, we need to understand what is State & what is State Root. I am really thankful to following post to explain the data storage along with state & state root in ethereum (Refer for more detail) in very simple language that can be understood easily.

5. Nonce — I remember this word as Number used ONCE. This nonce is really interesting to understand in the context of cryptocurrency implementation as this number gets generated with the difficulty configured for mining. Most important use is to assign some random number to any block so that block can not be forged.

6. Gas Limited & Gas Used — Gas is basically a kind of unit to calculate the resource consumption in executing any transaction. By assigning value to this field, BlockChain network ensure that long running transaction to be rejected with Out Of Gas once Gas reaches to defined value. e.g. if there is infinite loop with any contract then once resource consumption reached to defined GAS limited, it will throw Out Of Gas error.

There are many more fields which are part of any single block along with message receipt, consensus information etc. Those fields are also important for QA to know. Now, Question arises in which kind of database we store block chain data so answer is, Key-Value storage is being used. e.g. Ethereum’s Go, C++ and Python clients use Leveldb and this can be replaced with other key-value storage like RocksDB, BadgerDB etc. I read somewhere that Ethereum’s Rust client uses RocksDB. This can be replaced with any other key-value storage if there is any new key-value db emerge which claims to have improvement on any read/write amplification.

Why Ethereum stores data into key-value storage instead of RDBMS — We need to understand where do we use key-value storage instead of RDBMS. Wherever performance is utmost priority over the readability of stored data then key-value storage like LevelDb, RocksDb etc are preferred choice over relational database. It is quite evident in blockchain, only few hashed fields are needed to refer in doing future transaction so RDBMS does not seem to be right choice as it degrades the performance by having properly defined schema’s entity relationship etc. Challenging part is how to verify the data which is store in Key-Value storage as there is no SQL query kind of support available for any key-value storage database. This is what I mentioned in my earlier post that doing QA for blockchain based application is not traditional testing. To verify data from kay-value storage, there is 3 operations each key-value storage database supports & those are put, get & delete. To use these operation to verify the data, QA needs to know what programming languages can be used. Now a days almost all the programming languages are having support for key-value storage databases but I prefer nodejs-javascript, Python, Go, java however any progamming language can be used to verification of data form these key-value storage databases.

I was thinking that this part will be easy for me to cover but it looks like there are plenty of concepts which are still missing. May be I will try to articulate all the missing concepts in another post once I covers rest of the components of blockchain. In my opinion, readers would have got some sense through which QA strategy can be defined.

Stay tuned for the next post where I will try to cover rest of the components as we are approaching towards the post where I will consolidate the outcome of all the post to have one very generic QA strategy for blockchain based decentralized application.

Keep learning & stay tuned…..

BlockChain Evangelist & Enthusiast-Building Generic Automation Framework for BlockChain DApps for Ethereum at Startup

Originally published at https://www.linkedin.com on May 20, 2018.