What’s behind Blockchain hashing & proof of work?
Dear Intrachain Community,
In my last blog post I have talked about the Solidity Bytecode. Today, I want to talk about Blockchain hashing and proof of work.
As we all know, Blockchain is the heart of Ethereum ecosystem. It is an append-only structure storing every transaction ever executed in the network. Every block in the blockchain contains the hash of its predecessor. This structure creates a chain of blocks tracing back to the root genesis block which is always the first in the chain. It is not possible to change a block retrospectively when it was present for a longer time in the chain because all subsequent blocks depend on each other and you would need too many resources to recompute all the sequence starting from the block you want to change.
The header among other useful information contains two things: Merkle Tree root and Nonce value. The first one is used for transaction verification and the second one for process mining.
Let me first explain the Merkle Tree root:
To verify the validity of a transaction in a block you need to ensure that no hash value in every transaction was modified. To do this in a scalable way the special data structure is used called Merkle Tree. Using this structure you don’t have to walk through all the transactions in a block to verify the validity. You only need to walk through a short path of Merkle Tree to do this. The Merkle Tree is a data structure that stores a digital signature for the whole list of transactions in a block. It is used to verify the integrity of a transaction in an efficient way with the help of a Binary Hash Tree. Its leaf nodes contain the hash value of the individual transactions of a block. Every non-leaf nodes hash value is the hash of its two children. The resulting root node of this tree is then included in the block that contains the associated transactions.
The Merkle Tree allows a node only to download the header of a block and a small number of nodes from the Merkle Tree to validate a transaction. In the example illustrated on Picture 2, only the nodes Hash(D) , Hash(AB) and Hash(EFGH) are required to proof the inclusion of the transaction Hash(C) in the block. This verification takes on average O(log n) time, and at most O(n) time because the structure is the same as in a binary search tree. If an attacker smuggles in an invalid transaction somewhere at the bottom of the tree, the hash of that transaction propagates upward to the root node and makes the hash of the whole block invalid.
Now, let me explain the Nonce:
The second value called Nonce is used in mining process. It is a part of so called proof-of-work algorithm. More specifically, the miners will run the block’s unique header metadata (including timestamp and software version) through a hash function (which will return a fixed-length, scrambled string of numbers and letters that looks random), only changing the ‘nonce value’, which impacts the resulting hash value. If the miner finds a hash that matches the current target, the miner will be awarded ether and broadcast the block across the network for each node to validate and add to their own copy of the ledger. If miner B finds the hash, miner A will stop work on the current block and repeat the process for the next block. Approximately every 12–15 seconds, a miner finds a block. If miners start to solve the puzzles more quickly or slowly than this, the algorithm automatically readjusts the difficulty of the problem so that miners spring back to roughly the 12-second solution time.
I hope this blog post gave you a better idea of hashing and proof of work when it comes to blockchain. In the following weeks, I will share with you technological insights into the blockchain world. Stay tuned to learn more.
