The philomath and the blockchain

Published in

Red Squirrel

9 min readOct 14, 2021

Blockchain… just another trendy buzz word and technical challenge for a developer curious about how things work. But not just curious. Intimidated. I’ve had interest in this particular technology for a few years. While I have dug a bit into the theory and feel like I understand the abstract power and problem solving potential, I still have apprehension about my deeper understanding and my technical abilities, and how to go about building and/or learning more.

As it turns out, just like anything else, step by step, and with a friend (aka accountability buddy) leads to creation — of a blockchain. Or in this instance — to WombatChain! My goal in writing this article is to solidify and share a bit of what I learned, not only about blockchain, but also about reinforcing the importance of certain patterns and concepts that are important and helpful while learning something new.

So first, what is a blockchain? A blockchain is chunks (blocks) of information strung together, secured by cryptology. It’s just a database! Simple, right? These information structures are powerful because they are:

Immutable — meaning the blocks and data within them can’t be changed
Decentralized —there is no central entity controlling it, making them more resistant and immutable than our typical banking and government centralized systems
Sequential — in conjunction with the above, new blocks are continuously appended after old blocks
Transparent — in terms of data, but private for individuals in terms of identifying information
Secure — use of algorithms* to secure data in secret or encrypted forms, that when combined with the above, lead to additional security because decentralization builds trust when the group of users agree on to the validity of the blocks and ordering, also known as the power of consensus

*An algorithm is just a fancy and technical way of describing a set of rules to follow while making a calculation. In other words, even the process for baking a cake is an algorithm. It’s just usually a term used for maths calculations.

Ok. That seems pretty digestible. Let’s break it down a bit more, and I will also provide some additional resources sprinkled in, as well as at the end of the article, for more information. To start, there is an origin block. That origin needs to contain, at minimum, some details including its own identifying information, or hash, a timestamp, and whatever other information is needed. After that, every proceeding block will contain the hash of the block preceding it.

Analogies and visual aids are great learning tools!

And that’s it! This is really the simplest of blockchains, or at least the structure. It might not sound like such helpful nor valuable information. And what exactly is a hash, and why is it needed? To get into more valuable information and learn where and why blockchain technology became such a hot topic, look no further than cryptocurrencies. Specifically, Bitcoin (BTC). It was the first public blockchain — a ledger for transactions for a new digital currency. In the case of BTC, that ‘other information’ is transactional information which includes details like addresses and how much BTC is going from one to another. Here is a screenshot of a BTC transaction, showing all the basic information as described above, and more.

To learn more about BTC specifically, check out this video by 3Blue1Brown on how BTC works. My focus is on general concepts rather than getting too specific, but I would like to mention two additional concepts implemented by BTC that I will also be modeling for my own blockchain: digital signatures and proof of work.

But before, let’s circle back to hashes. Hashes are an algorithmic function that take inputs and returns a fixed-sized output of text converted into encoded form (enciphered). And then there are the hash pointers, which make up part of a larger data structure that point to where that enciphered information is stored, which can return the information and verify that it hasn’t changed.

Going back to the important concept of security and transparency, and also privacy- BTC utilizes digital signatures. As straightforward as the name, digital signatures verify authenticity, integrity, and non-repudiation (undeniability). There are two parts to a digital signature — the public key and private key. A person can sign a transaction with their private key and a message (or a hash), which allows others to confirm this signature using the public key and message (hash), thereby confirming ownership. Thus, a user’s information and account, as in the case of BTC, is confirmed, only for that specific transaction, while also keeping their personal information secret and safe from others.

Another important concept is proof of work, or Hashcash, as it is called in the BTC network. Proof of work is an algorithm to solve, usually resulting in a number or number pattern which solves a maths problem and allows for the creation of a new block. The beauty of such an algorithm is that it is difficult to find, but easy to verify. This has an effect of slowing down the blockchain, which makes it computationally challenging to commit fraud. This is not necessarily super obvious, but when the power of decentralized consensus is taken into consideration in addition to the time it takes to provide the proof of work, other blocks are being added and proven, which will result in easily identifiable “bad” blocks.

Sometimes it takes awhile for this information to sink in and understand the power of it, and that’s ok. Like stated in the introduction, I’ve been fascinated by this technology and cryptocurrencies for a few years now, and I’m still wrapping my head around it, especially the details! Plus it is so easy to quickly get overwhelmed with all of the information out there and complexities of the way things work. Just remember Rome wasn’t built in a day, and neither was a blockchain, as it turns out.

So on that note, let’s get to the good stuff — the actual building!

So, what do we need to start actually building a blockchain? As I mentioned already, a crucial first step was having a buddy working on it with me. Luckily, a coworker of mine, Josh Cheek, is always down to pair and help me learn something new. He was also curious about learning a bit more about blockchain by building one too, so he really helped with motivation and getting it going.

Next we needed a starting point. We found Daniel van Flymen’s article on Hackernoon and thought it was a great resource to get started. The original article was written with Python, which I do love, but having recently learned Ruby and pairing with a bonafide Ruby wizard, we decided to take the learning to another level and write our own blockchain in Ruby. And with a Tuple session started and a new GitHub repo initiated, we were building our first blockchain.

We built our blockchain- which ultimately became WombatChain- over the course of a few stolen hours over a handful of weekends. In our first pass, we were able to complete enough of the tutorial to finish a basic, centralized blockchain. (And for clarity again, I’m not going to go into the details of how we built this blockchain because the original article linked above already does that, and I will just focus on some deviations and discoveries along that way that can be further explored via our code that was also linked above.)

Having realized the fun connection between block transactions and wombat cubic poop, I quickly became taken with the idea to turn our blockchain into a bit of a fun front-end playground as well. The next few commits were all about some fun css and styling as well as learning more deeply about command line network requests (curl requests) versus url requests from a form. Which then of course spiraled into some security checks, validations, adding JavaScript and front-end feedback in the form of flash messages, and some css art and animations.

In the midst of getting carried away with the fun on the front-end side of things and excitement over the idea of presenting the blockchain transactions as poo, we also made a big push to get back into the Learn Blockchains by Building One article to decentralize our blockchain. This would take it to another level and stay true to the core principles of blockchain. It was during this refactoring that we realized the initial article has a little bug in the simplicity of the proof of work. (And how exciting it is to be able to learn one step further from a simple educational exercise! Also note that in the original author’s python code repo, this bug had been fixed, but the article was not updated to reflect it, which is why we had the surprise discovery ourselves.)

After confirming our suspicions with some examples and then reviewing some comments of the article, we took a bit of time to understand proof of work better, and re-evaluated our code. At this moment, we realized it was a great time to pause a bit and to do a big refactoring push and add some tests.

The best lessons are learned from examples like this! Refactoring and testing are practices that truly make one think through the logic, understand the theories, and then figure out how to get each piece working together.

This was perfectly exemplified by the proof of work bug. If we go back to the beginning of the article and the breakdown of a block — recall the part of that identifying information on the transaction block — which when combined with the concept of proof of work creates the “hard to solve, but easy to verify” security feature of Bitcoin and other cryptocurrencies. In the article, the algorithm that needed to be solved was- “Find a number p that when hashed with the previous block’s solution a hash with 4 leading 0s is produced.”

Let’s break that down a bit further. The requirement that the resulting solution must lead with four 0s is the difficulty requirement. The number p mentioned above, or the nonce, is an arbitrary number that when combined with all other inputs results in a new output hash. The hash which in this case must lead with four zeros. A nonce is also a ‘number only used once’ so that the same hash function with the same input cannot be run twice. The result of the above algorithm, in addition to the nonce, is the proof of work which can be easily verified using the inputs and the nonce.

The problem that we uncovered, that is still pending in our repo, is that the proof of work “is a SHA256 hash of the previous proof and the nonce” as our test says, along with a big “(FIXME: THIS MEANS YOU CAN REWRITE THE CHAIN)”. But why is this possible? As much as I might try to explain it better, when we were researching if our hypothesis that the proof of work was off, we did come across others who had already discovered this too and this response by Konstantin Schubert I found to be as good as any I might attempt to make-

“Because the way you implemented the proof of work, it isn’t tied to the transaction history.

This means that somebody could re-write the transaction history, compute the new block hashes, and re-use your proofs of work.

He could then mine a single new block, and thus create a new longest chain and cause everybody to accept this chain.”

So, as I said, that still does need to be fixed, and I would like to expand and build more. But as it currently stands, we have built a blockchain in Ruby! The blocks can be mined via a front-end interface or via curl requests, with validations on the front-end and back-end. Plus, I got to play around with some css art. And we decentralized the chain! I experienced some problems that I needed to break down and use other tools like Seeing is Believing. I had to really challenge myself to break everything down, understand it and then explain everything simply.

Visit our heroku site to interact with the blockchain we built!

Addddd… I’m not even finished yet! Other next steps include- smart contracts, or storing programs on the blockchain! And proof of stake vs proof of work, because this is where cryptocurrencies seem to be heading.

Resources:

The philomath and the blockchain

Written by Marissa Biesecker