Operating System:
Big library: https://golang.org/pkg/math/big/Bytes library: https://golang.org/pkg/bytes/In this Golang tutorial, we take a look at how to build out a Proof of Work consensus algorithm for the prototype blockchain that was built in part one. This PoW algorithm mirrors the original Bitcoin Hashcash algorithm. It also implements a validation function which checks to see that the work was properly done to sign a block. The difficulty in this PoW algorithm is static for now, but the developer can select to make the work harder or easier. We also discuss shifting bytes in hashes, using big integers to create a "infinite" loop, the nonce and some other topics.
In the last tutorial we discussed building independent modules outside of the GOPATH. Go supports applications that are made up of multiple module namespaces. This can be helpful for organization as well as execution purposes. In a windows console, when you go to execute a multi-file Go program, you have to reference each file so that the go run command links the files together. If you create a new directory with a new module name and reference this module from one of your other Go files, you can execute the main package and the library package will automatically be built as a dependency. In this project, we make use of this convention to create a blockchain module which is separate from the main entry-point module.
One of the most important concepts of a blockchain is security. Because the chain is distributed across multiple machines which could potentially be malicious, a consensus algorithm is needed. This algorithm is what decides which blocks contain valid data and which blocks do not. In the cryptocurrency world, there are many different Consensus protocols: Proof of Work, Proof of Stake, Proof of Brain, Delegated Proof of Stake, Proof of Authority etc. In this tutorial, we build a Proof of Work system to allow the machine to sign the blocks.
The main data structure used in our Proof of Work implementation is this Proof of Work structure which binds the block to a target. The block contains data and a hash pointing to the last block and the target is a numerical representation of a set of requirements that we want apply to valid hashes. In this case, if the big integer of the hash is less then the target, then the block is signed with that hash. Above is this PoW data structure.
Our PoW implementation also features a static difficulty. This difficulty is what allows the blockchain to devise the target for the PoW struct. The higher the difficulty, the more computational power is required to sign/create the block. In a normal PoW algorithm, this difficulty is not a static number and is increased according to its own algorithm.
In a very general sense, the difficulty is a representation of the number of bits that we want to shift the hashes by. A SHA-256 hash is 256 bits in length so we subtract this difficulty from 256. The hexadecimal of this target is represented by a bunch of zeroes and a single one based on this difficulty.
In the image above, there are three different hashes. The hash in the middle is a representation of the target. The one on the top is a hash that is not valid to sign a block in our chain. The bottom hash however, is valid to sign our chain. This is because the hash above is greater than the middle hash and the hash below is less than the middle hash.
The work itself is fairly expensive and hard. This is required for security reasons; the longer it takes to compute the hash for a block, the harder it is to tamper with the values inside of the blockchain. If an individual was to create fake data and put it into a block, they would then have to sign that block and every block after to make that information valid.
On the other hand, the validation of this work is fairly simple. While a miner could try to mine a few million hashes to sign a single block, a validation function only needs the signed hash and the nonce to validate the block. In our example, the validation function is the same algorithm that is used for the PoW. The nonce is already known for each block on the chain so this validation function only needs to execute the PoW algorithm a single time.
The Source Code for this video may be found here: https://github.com/tensor-programming/golang-blockchain/tree/part_2