Befuddled by Blockchain - Part 1

Back to Listing

Hanover, MD, 09 August 2018


Introduction

So you want to propose a serious software solution to your team but find yourself hesitating before stepping forward to suggest using a blockchain. The term has come to have a skewed meaning in today’s world with the hysteria surrounding the cryptocurrency phenomena. In reality, a blockchain is essentially a chain of data that uses hashes to ensure integrity.

There are many uses for blockchain technology that have nothing to do with cryptocurrencies, and many people are aware of this. For those who are not, this article serves to introduce how simple blockchain technology can be implemented without any need for a “coin”.

For the purpose of this discussion we will create our own blockchain from scratch to see how easy it is to maintain and what kinds of problems it can solve.

Defining a block

The first step in this process will be to define what a block is and what data is in it. To make a block, there are 5 critical elements: The hash of the block, the hash of the previous block, the proof, the timestamp, and the data itself. For the sake of convenience the data structure will also have an index. To make sense of any of these things, we will start by creating the first block in our blockchain, known formally as the Genesis block. The following is the stub we can use to generate the genesis block.

{
	"index": 0,
	"prev": "0",
	"message": "My spiffy new Genesis block!",
	"time": "2018-08-01 13:40:17 -0400",
	"hash": "",
	"proof": 0
}

So now that we have everything defined in a readable format, let’s briefly cover the entries. index is the number of the block entry. We are starting at index 0 so that the first useful block will be at index 1. prev is the hash of the previous block. There is no block before this, so we arbitrarily set its value. message is the data we wish to store. This can be any kind of data, but for this application we will store a simple message. time is our timestamp which we will use for integrity purposes. hash is going to be the hash of the current block. This is the field we are actually going to be searching for; we refer to this as mining. proof is the field that we will use to mine the block, as described below.

What is ‘mining’

To mine the hash, we are going to take all of the fields except hash, and place them into a string and run a SHA2 sum on it. If the hash contains a certain number of consecutive 1s at the beginning, then the block is valid. The number of 1s is what determines the difficulty of mining. The more 1s there are the longer it will likely take to mine a block. This concept of generating consecutive 1s is one of the most important pieces of the technology, and we will demonstrate why after creating our block. Since we don’t want to change any of the data we are submitting, we increment the proof field to adjust the hash. We’ll use the following string format to generate a hash

"<index><time><previous_block><message><proof>"

If we try with our current block, we get the following hash:

$ echo -n '02018-08-01 13:40:17 -04000My spiffy new Genesis block!0' | sha256sum
962d7db4cca509d6a418e9b269e925b244fbb6d7ef5b5e5e90fdb7dc38680450

This is an invalid block, because there are no 1s at the beginning. Let’s try incrementing the proof field with this small ruby script and see how many tries it takes to reach 5 consecutive 1s.

#!/usr/bin/ruby
require 'digest'

# The part of the block string that is constant
block_string = "02018-08-01 13:40:17 -04000My spiffy new Genesis block!"
# The proof we will be incrementing
proof = 0 

# string to hold the hash for printing
hash = ""

sha = Digest::SHA256.new

puts 'Mining...'

loop do
  # Hash the full string and keep incrementing proof until we get 5 consecutive 1's
  hash = sha.hexdigest("#{block_string}#{proof}")
  break if hash[0..4] == "11111"
  proof += 1
end

puts "Hash found!"
puts "Proof: #{proof}"
puts "hash: #{hash}"

After this executes we are given the following output:

$ ./quick_mine.rb 
Mining...
Hash found!
Proof: 383402
hash: 1111195fe17492d98c34cd3be291805c044de71ab8243d06c7e951b41b4cc78c

Let’s try it out to make sure the output is accurate:

$ echo -n '02018-08-01 13:40:17 -04000My spiffy new Genesis block!383402' | sha256sum
1111195fe17492d98c34cd3be291805c044de71ab8243d06c7e951b41b4cc78c

Sure enough we have a proof value that gives us our hash. We can see that it took 383,403 hashing attempts to ‘mine’ this block (one additional since we began at 0). And of course to validate it, we only had to run it once. This is the true strength of utilizing a blockchain: it’s arbitrarily hard to mine and incredibly fast to verify. Because we must provide a proof of work, we cannot just generate blocks. Instead we must put in some time to add valid data to a block. This is important because as the blockchain grows, it will become harder and harder to fake blocks created before it.

Adding a second block

Now that we have our genesis block, let’s make it an actual blockchain by adding another block to it. We can create an arbitrary message that we want stored in the block and then start mining for a valid proof. Here’s our stub:

{
	"index": 1,
	"prev": "1111195fe17492d98c34cd3be291805c044de71ab8243d06c7e951b41b4cc78c",
	"message": "The Malayan Tapir is a fantastic creature",
	"time": "2018-08-01 13:40:18 -0400",
	"hash": "",
	"proof": 0
}

Notice that the hash of the previous block has filled in the prev field. This is important as it is part of the string in the mining process. Because of this, one cannot attempt to mine ahead of the chain as the resulting SHA2 sum will not be valid. This forces miners to reference the latest block, which helps maintain the integrity of the blockchain. After a bit of mining we are handed the following block:

{
	"index": 1,
	"prev": "1111195fe17492d98c34cd3be291805c044de71ab8243d06c7e951b41b4cc78c",
	"message": "The Malayan Tapir is a fantastic creature",
	"time": "2018-08-01 13:40:18 -0400",
	"hash": "11111489fabe19bddc9a06e025e9d9a1831cd17671eaa445280ef8752e532e45",
	"proof": 1410218
}

We can then verify the validity of the block:

$ echo -n '12018-08-01 13:40:18 -04001111195fe17492d98c34cd3be291805c044de71ab8243d06c7e951b41b4cc78cThe Malayan Tapir is a fantastic creature1410218' | sha256sum

11111489fabe19bddc9a06e025e9d9a1831cd17671eaa445280ef8752e532e45

Let’s take a look at what we have so far:

[{
	"index": 0,
	"prev": "0",
	"message": "My spiffy new Genesis block!",
	"time": "2018-08-01 13:40:17 -0400",
	"hash": "1111195fe17492d98c34cd3be291805c044de71ab8243d06c7e951b41b4cc78c",
	"proof": 383402
}, {
	"index": 1,
	"prev": "1111195fe17492d98c34cd3be291805c044de71ab8243d06c7e951b41b4cc78c",
	"message": "The Malayan Tapir is a fantastic creature",
	"time": "2018-08-01 13:40:18 -0400",
	"hash": "11111489fabe19bddc9a06e025e9d9a1831cd17671eaa445280ef8752e532e45",
	"proof": 1410218
}]

At this stage we can pat ourselves on the back because we have just created a legitimate blockchain!

Conclusion

There are two main points that should be emphasized at this stage. Firstly, we can now observe that if you try to modify the genesis block in any way, the hash for that block will change. Even if you re-mine a valid hash, the second block will be invalid because it references the original hash of the genesis block. This is why the proof of work is important. As the blockchain grows, the blocks inside of it grow in difficulty to change. If you change one piece of data in it anywhere, all of the subsequent blocks will become invalid. Secondly, notice that there is no notion of coins. Instead there exists data and hashes which can be validated to ensure integrity.

When the elements of a cryptocurrency are removed from a blockchain, the technology becomes simpler to work with and understand. In its current state, the blockchain created has the potential to store and distribute data that is immutable. We will continue to expand on this project in future articles as we construct a functional client and add network capabilities with blockchains.

Click here to learn more about how Onyx Point, Inc's professional services and development teams can help you leverage new technologies, and Click here to read more about our work on blockchains.

Jesse is a software engineer at Onyx Point. He's currently a developer on the SIMP Console, SIMP Enterprise, and SIMP Lite. He also consults on other projects such as Exascale Computing's Continuous Integration initiative

At Onyx Point, our engineers focus on Security, System Administration, Automation, Dataflow, and DevOps consulting for government and commercial clients. We offer professional services for Puppet, RedHat, SIMP, NiFi, GitLab, and the other solutions in place that keep your systems running securely and efficiently. We offer Open Source Software support and Engineering and Consulting services through GSA IT Schedule 70. As Open Source contributors and advocates, we encourage the use of FOSS products in Government as part of an overarching IT Efficiencies plan to reduce ongoing IT expenditures attributed to software licensing. Our support and contributions to Open Source, are just one of our many guiding principles

  • Customer First.
  • Security in All We Do.
  • Pursue Innovation with Integrity.
  • Communicate Openly and Respectfully.
  • Offer Your Talents, and Appreciate the Talents of Others

programming, open-source, security, blockchain

Share this story

We work with these Technologies + Partners

puppet
gitlab
simp
beaker
redhat
AFCEA
GitHub
FOSSFeb