Category: Blockchain Testing

Blockchain Testing

Battling Blockchain Vulnerabilities through Quality Audits

03 May 2019


The original promise of blockchain technology was security. However they might not be as invulnerable as initially thought. Smart contracts, the protocols which govern blockchain transactions, have yielded under targeted attacks in the past.

The intricacies of these protocols lets programmers implement anything that the core system allows, which includes inserting loops in the code. The greater the options given to programmers, the more the code needs to be structured. This makes it more likely for security vulnerabilities to enter blockchain-based environments.

The Attacks that Plague Blockchain

Faulty blockchain coding can give rise to several vulnerabilities. For instance, during Ethereum’s Constantinople upgrade in January of this year, reentrancy attacks became a cause for concern. These are possibly the most notorious among all blockchain attacks. A smart contract may interface with an external smart contract by ‘calling it’. This is an external call. Reentrancy attacks exploit malicious code in the external contract to withdraw money from the original smart contract. A similar flaw was first revealed during the 2016 DAO attack, where hackers drained $50 million from a Decentralized Autonomous Organization (DAO). Note the following token contract, from programmer Peter Borah, of what appears to be a great endeavor at condition-oriented programming:


contract TokenWithInvariants {   

mapping(address => uint) public balanceOf;

uint public totalSupply;

   modifier checkInvariants {

         if (this.balance < totalSupply) throw;


   function deposit (uint amount) checkInvariants {

     balanceOf[msg.sender] += amount;

     totalSupply += amount;


  function transfer(address to, uint value) checkInvariants {

        if (balanceOf[msg.sender] >= value) {

        balanceOf[to] += value;

        balanceOf-msg.sender] -= value;



  function withdraw() checkInvariants {

      uint balance = balanceOf[msg.sender];

      if ( ()) {

        totalSupply -= balance;

        balanceOf[msg.sender] = 0;

The above contract executes state-changing operations after an external call. It neither carries out an external call at the end nor does it have a mutex to prevent reentrant calls. The code does perform excellently in some areas, such as checking for a global invariant wherein the contract balance (this.balance) should not be below what the contract perceives it to be (totalSupply). However, these invariant checks are done at function entry in function modifiers, thereby treating a global invariant as a post-condition rather than holding it at all times. The deposit function is also flawed since it considers the user-mandated amount (msg.sender) instead of msg.amount.


Finally, the seventh line has a bug in it. Instead of,

if (this.balance < totalSupply) throw;

It should be,

if (this.balance != totalSupply) throw;

This is so because instead of checking for a stronger condition, we are now confirming a somewhat weaker condition of the contract’s actual balance being higher than what it thinks it should be.

These issues enable the contract to stock more money than it should. An attacker can potentially withdraw more than their share, heightening the danger of reentrancy even when the contract codes are watertight.

Overflows and underflows are also a significant vulnerabilities which can be used as a Trojan Horse by non-ethical hackers. An overflow error occurs when a number gets incremented above its maximum value. Think of odometers in cars where the distance gets reset to zero after surpassing, say 999,999 km. If we affirm a uint8 variable that can take up to 8 bits, it can have decimal numbers between 0 and 2^8-1 = 255. Now if we code as such,


uint a = 255;a++;


Then this will lead to an overflow error, since a’s maximum value is 255.

On the other end, underflow errors effect smart contracts in the exact opposite direction. Taking an uint8 variable again:


unint8 a = 0;


Now we have effected an underflow, which will make a assume a maximum value of 255.

Underflow errors are more probable, since users are less likely to possess a large quantity of tokens. The Proof of Weak Hands Coin (POWH) scheme by 4chan’s business and finance imageboard /biz/ suffered a $800k loss overnight in March 2018 because of an underflow attack. Building and auditing secure mathematical libraries that replace the customary arithmetic operators is a sensible defense for these attacks.

The 51% attack is also prevalent in the world of cryptocurrency. A group of miners control more than 50% of the mining hashrate on the network and control all new transactions. Similarly, external contract referencing exploits Ethereum’s ability to reuse code from and interact with already existing contracts by masking malevolent actors in these interactions.

Smart contract auditing that combines the attention of manual code analysis and the efficiency of automated analysis is indispensable in preventing such attacks.
Solving the Conundrum
Fixes to such security risks in blockchain-based environments are very much possible. A process-oriented approach is a must with agile quality assurance (QA) models. Robust automation frameworks are also crucial in weeding out errors in coding and therefore strengthening smart contracts in the process.

In the case of reentrancy attacks, avoiding external calls is a good first step. So is inserting a mutex, a state variable to lock the contract during code execution. This will block reentry calls. All logic that changes state variables should occur before an external call. Correct auditing in this instance will ensure these steps are followed. In the case of overflow and underflow attacks, the right auditing tools will build mathematical libraries for safe math operations. The SafeMath library on Solidity is a good example.

To prevent external contract referencing, even something as simple as using the ‘new’ keyword to create contracts may not be implemented in the absence of proper auditing. Incidentally, this one step can ensure that an instance of the referred contract is formed during the time of execution, and the attacker cannot replace the original contract with anything else without changing the smart contract itself.

Magic BlockchainQA’s pioneering QA model has created industry-leading service level agreements (SLAs). Our portfolio of auditing services leverage our expertise in independently verifying blockchain platforms. This ensures decreased losses on investments for fintech firms, along with end-to-end integration, security, and performance. Crucially, this will usher in widespread acceptance of blockchain-based platforms. With the constant evolution of blockchain-based  environments, we are constantly evolving as well, to tackle new challenges and threats, while ensuring that our tools can conduct impeccable auditing of these contracts.

Blockchain technology first came with the promise of unprecedented security. Through correct auditing practices, we can fulfill this original promise. At Magic BlockchainQA’s, we aim to take that promise to its completion every single time.

Anuraj Soni

As a President of MagicBlockchainQA, Anuraj is building Financial Services business grounds-up based on new-age technologies like AI & Blockchain.

Blockchain Testing

Merkle tree and Its linkage to Blockchain

03 Oct 2018

What is Merkle Tree?

Merkle Tree is also called as a Binary Hash tree, a type of data structure used for the large set of data. Merkle tree is used where the data required being efficiently summarized and verification of data integrity.

It provides critical features necessary for Blockchain Network.

  1. Compress large data set, it removes any superfluous branches and keeping only the ones needed for establishing the proof.
  2. It has the ability to verify which transaction is included in the block.
  3. Its light weighted, as the entire chain doesn’t needs to be downloaded for each and every transaction

Overall performance and scalability.

A complete merkle tree looks like the below diagram.


In Level 2 of the above structure, “a.txt”, “b.txt”, “c.txt” and “d.txt” is the leaf node of the merkle tree and each leaf node is the hash of the block data. Level 1 is a hash combination of two child node pair thus parent hash “a3d71b5” is combination of (Hash of a.txt + hash of b.txt). Likewise, Parent hash “0787912” is combination of (hash of c.txt + hash of d.txt) and so on. Level2 is the root which is combination of the hashes of “a3d71b5” + “0787912”. In this manner there can be N number of levels in the binary tree with each node having either 0 or 1 or 2 children. However, the root is a single hash of its two immediate children node pair

Merkle tree within Blockchain

Merkle tree is used inside the block of the Blockchain to represent all the transactions within that block. Thus, the block content can be validated using single string of fixed length and their by eliminating the need to store individual transactions.


A continuously growing block of records where each block is linked to its successor block securely via cryptography is nothing but a Blockchain.

Now each block contains hash pointer of its previous block, the current timestamp and the transaction data in hash format. The data once stored within the block cannot be deleted or changed. For any changes it creates an altogether a new block which gets linked to the future chain. The transaction data are usually stored in the leaf node of the merkle tree. The root hash is then stored in the block thus creating the tree structure. So each block in the blockchain hold hash transactions and are encoded into a merkle tree.

When we say that each block is a permanent block within the Blockchain i.e. it neither can be deleted nor modified. For example supposes anyone who wants to change or modify the data within a current block in the blockchain. If they manage to manipulate the data somehow, then they have to change the hash of its previous block so that it points correctly to the modified block.

Changing the hash of its previous block would also mean to change the hash of its previous to previous to block, so that it remains in the same structure tree. Likewise in order to have the tree structure valid, the entire block hashes needs to change which are connected to each other. It has to traverse all the way to root in order to change a single block. And in distributed ledger it will become virtually impossible since in distributed network there is continuous consensus to verify any transaction that is being added to block within the blockchain.

Thus, blockchain is tampered proof free; hence making it’s the most secure structure for any transactions.

Merkle tree testing can be accomplished by verifying the hashes of a block and state root for each level. At Magic BlockchainQA, we are helping the global FinTech companies to test and implement their Blockchain model successfully. Our highly skilled Blockchain QA team offer end to end product testing on Blockchain network and smart contracts. With in-depth domain understanding, can help in automating the regression test bed for easy and production-ready solution.

To know more about our FinTech focused BlockChain please contact us at

Sharmistha Ghosh

Sr Consultant - Magic BlockchainQA

As a managing consultant at Magic Finserv, Sharmistha is actively involved as Test architect, providing testing solutions for Blockchain applications and building capabilities within the organisation.

Official Integration Partners

	MythX Logo- Magic BlockchainQA

Security Testing

Securitize, Magic BlockchainQA Integration Partner

Platform Partner