So, you think you know Consensus Algorithms?

When I started writing this post, the first thing I did was start diving into the different, and most common, consensus algorithms. Sometime during my first paragraph, it occurred to me that I may be taking for granted that anyone actually understands, fundamentally, what that even means. Perhaps I’ve got it wrong too. So lets start at the beginning…

What is an algorithm.

Wikipedia has a rather large entry on this (I was surprised at how in depth it was). Essentially, an algorithm is “a set of rules that precisely defines a sequence of operations”. Right, so the rules are a formula that defines how a task is accomplished. The steps you follow when making a cup of coffee is an algorithm. If you want to know more about algorithms, here’s a great video to watch.

But for now, we have enough to go on.

The next question you may ask is: What’s a consensus?

The best definition I’ve found is that of Merriam-Webster: “It is  the judgment arrived at by most of those concerned”

We now know that a consensus algorithm is a set of steps that are followed (an algorithm) so that an agreement can be formed by most (or all) of the parties involved.

Alright, but what are these consensus algorithms agreeing to?

They need to agree whether a block should be added to the blockchain. If you’re not sure what that is, take a look at my previous post.

With regard to blockchain, various technologies use different algorithms to arrive at this outcome. This post will cover the most popular ones.

Alright, so why should you care? As long as it works, does it really matter? If smarter people say it’s okay, it must be okay! So set it up, run it and Bob’s your uncle.

Not quite. There are many factors to consider when looking at consensus algorithms, some of them are:

  • Algorithms may be unreliable or fault intolerant and may crash under some circumstances – see  byzantine fault tolerance.
  • They may take a really long time to process – not great if you’re expecting something to be done in 5 minutes but it takes 5 months.
  • Some consensus algorithms are compute intensive and may require enormous amounts of power to run. Think electricity costs; think the environment – Did you know that in the U.S, 24.25 households could be powered for 1 day by the electricity consumed by BitCoin for a single transaction.

Usually, a blockchain platform implements a specific type of consensus algorithm. Selecting this platform also means that you’re adopting the consensus algorithm. Better to be informed I say!

In this post I’ll cover the most common consensus algorithms you’re likely to encounter.

Proof-of-Work

This algorithm has been popularised because of it’s use by BitCoin.

Proof of work is a requirement to solve a complicated math problem, this is called mining. ‘Mining’ is used to add a block to the chain. Given this, miners compete against each other to solve a blocks’ problem. Whenever a miner wins, it is rewarded (e.g. BitCoin).

To understand how this algorithm works, we need a basic understanding of what a hash is and how its generated. So here goes.

A hash is a mathematical algorithm that converts a sequence of characters into a string of 64 letters and numbers. This process is so sensitive that even the smallest change in those characters will result in a completely different hash.

There are different types of hashing algorithms but, BitCoin uses the SHA256 algorithm and we’ll use that for this example.

If we took my name, and hashed it:

burhaan = 172a0a60b8097a65c789e101c89c7d33e4344ba92926e7850de2703725e00d3e

However, if we changed the initial letter to uppercase:

Burhaan = fd1127f54ced787632f16f94f3f3c02cedd4d1bdffee8a217250f3915148407b

Any amount of text can be hashed. For instance, the hash value of the first paragraph of this post is:

344b06ccbd10f95095dd7c41993551e58a6879c91857b796328579b4f0b1a52d

Remember that an algorithm is a set of “rules”. One of the rules for the proof-of-work consensus algorithm states that the expected time to mine a block (i.e. solving the math problem) be a certain amount of time (in the case of Bitcoin, this is 10 minutes, Ethereum’s is 10-19 seconds). This rule determines the difficulty and the measurement of this is performed by taking the average time taken to mine n number of blocks. If the average time is above the expected time, the difficulty is reduced. If the average time is below the expected time, the difficulty is increased.

Difficulty is moderated by specifying the number of zeroes required at the beginning of the hash and more zeroes increase the difficulty of solving the mathematical problem.

Computing a hash value is best demonstrated through a simple example:

Using the example of my name, we need convert something like this:

fd1127f54ced787632f16f94f3f3c02cedd4d1bdffee8a217250f3915148407b

Into something like this: (where 1 zero is required)

0{the rest of the hash}

However, we’re not allowed to alter the existing string i.e. “Burhaan”. This is where a nonce fits in.

A nonce is an arbitrary, 32-bit, number that’s appended to our string. This resultant string is then hashed and if it meets the rule (of the specified number of zeroes), it’s calculated a successful hash and wins.

To illustrate:

Burhaandd34 = e8114f79a388a15328280d43c878313b693cf9f91e9105e46f238d8356d2b34f

That doesn’t meet our rule, so lets try again:

Burhaan1234 = ca93ecf5fa607fb4e5ab72aed056568a1d08ac05479676c28346050a4bea5910

…and so we can go until we find a suitable hashed value that meets the criteria. Effectively, it’s like playing the lottery, and any guess may work.

The number of times (per second) this ‘guess’ is attempted is the hashrate.

The steps (i.e. algorithm) that proof-of-work uses to reach consensus is as follows:

Step 1:  Get the hash of the previous block.

Step 2: Append the data in the current block to that hash.

Step 3: Append a nonce to all the data from Step 1 and Step 2.

Step 4: Hash.

Step 5: Do we have a hash that meets the hash requirement? If not, go to Step 3. Otherwise SUCCESS, get a reward! and start of the next block

And that folks, is how Proof-of-Work, works.

Proof-of-Stake

Proof-Of-Stake is also an algorithm and has been touted as the salvation to energy hungry Proof-of-Work algorithm. Unlike Proof-of-Work however, where miners who solve mathematical problems are rewarded, Proof-of-Stake miners are chosen in a deterministic way based on various random selection mechanisms, for example wealth or age – i.e. their stake. There is no reward for validating (i.e. mining) a block so, miners in Proof-Of-Stake are instead called forgers and their participation on the network is relative to their stake.

As you can imagine, there may be some resultant centralisation in the implementation of these deterministic mechanics, as the rich would get richer and some may have a permanent advantage. There are some proposed options to deal with this and you can read about those in this Wikipedia article.

Of course, not having to consume as much power as Proof-Of-Work introduced other problems, most notably the case of forgers participating on multiple blockchain histories and preventing a consensus from ever resolving. That is, if I (as a forger) can participate on multiple histories, I can act against myself and stall the entire algorithm.

One of the solutions proposed by Ethereum (who hasn’t implemented this consensus algorithm at the time of this post) is that of the Casper protocol, which forces each forger to provide a deposit for each of it’s ‘mining’ activities on the network. If it is determined that the forger acted in a malicious way, it would lose its deposit.

Byzantine Fault Tolerance (BFT) 

When dealing with distributed computing, a problem that needs to be considered is explained by the Byzantine Generals problem. Effectively, some generals are laying siege to a city and can win if they all act in unison. That is, if they all attack, they win; if only some attack, they lose. The generals rely on messages to be sent between each other to communicate however, a rogue general sends mixed or arbitrary messages. Telling some generals to attack and some to withdraw.

In computer science, this problem can occur when a computer (or group of them) operates incorrectly or maliciously and sometimes sends the wrong message.

In a consensus driven, distributed compute, environment this can be a significant problem and there are a number of protocols around to address this. One of more popular applications is the Practical Byzantine Fault Tolerance algorithm.

Practical Byzantine Fault Tolerance (PBFT)

Daniel Feichtinger, co-founder of Hyperledger, that utilizes PBFT, explains how its distributed system works:

“Each node publishes a public key. Any message coming through the node is signed by the node to verify its format. Once enough responses that are identical are reached, then you can agree that is a valid transaction.”

The PBFT algorithm provides safety when, at most, (n-1)/3 out of a total of n nodes are faulty. In other words, the network can tolerate a maximum of 33% of the nodes acting in a malicious manner.

The original whitepaper by Miguel Castro and Barbara Liskov, that describes the algorithm in detail, can be found here.

Other Consensus Mechanisms

At this stage, I need to draw a line – It’s easy to disappear down a rabbit hole given the number of different algorithms. However, I need to point out that your selection of a platform needs to take into account the purpose of the application and what your requirements are. For example, if you need fast(er) throughput, you probably don’t want to consider anything that uses proof-of-work.

 

So what some of the considerations you can use to whittle down the options available to you:

  • Throughput – How many transactions need to be processed within a timeframe.
  • Cost – Both in terms of implementation and transaction costs.
  • Energy – Does the implementation need to be energy efficient?
  • Scale – Can the network scale to your requirements efficiently?
  • Customisation – Do you have a requirement to customise the incentive or other aspects of the network?
  • Limitations – Are the nodes required to be trusted?
  • Infrastructure – Do you need to have a permissioned or public network? And do you know who the nodes are?

 

 

Creating a simple DApp for Ethereum using Truffle and Ganache

I find that I’m enjoying the theory behind blockchain and am tempted to continue along the path of exploring the different implementations, consensus algorithms, and pros and cons.
However, now that there’s a basic understanding of why we would/should look at it, and some fundamental knowledge of how it works, it seemed a good idea to actually build something – I’ve heard many people complain about the amount of theory they’ve seen but how little they’ve seen in the way of anything having been developed.

In that spirit, I’ve come up with a contrived (but practical) example that I will implement:
I would like to provide proof that a vehicle I drive actually belongs to me and that the history of that vehicles’ ownership can be traced.

I’m opting to develop this for Ethereum, but the same thing could be done on Quorum or Fabric, among others. In future posts, I’ll explore these platforms too – so stay tuned.

The source code for this application can be found here.

Firstly, ensure that you have some prerequisites setup: I’ll be using the Truffle Framework – I like the scaffolding it provides and it makes my life as a developer easier with contract compilation, automated testing and scriptable deployments and migrations.
My test net will be using Ganache.
Visual Studio Code will be used as my IDE along with the Solidity Language Extension.

Once you have that all setup, lets begin.

I want to store some details of the vehicle:

  • What the owner’s address is (the address, in this context, is the blockchain address)
  • The owners name
  • Registration
  • VIN
  • Make; and
  • Model

In my “contracts” folder I’ll create a contract called Vehicle.sol and, similar to a usual class, define my properties.
Simplistically, consider a contract as the template that defines what information you want stored on the blockchain and how you want to interact with that information.

A vehicle needs an owner on creation so who ever creates the vehicle, the first time, will be the owner and I only ever want the owner to have the ability to transfer that vehicle to a purchaser – I’ve used the modifier for this purpose – in that case it check that the entity executing the function is the owner.

Below is what my contract looks like.

The very first line (pragma solidity….) specifies the minimum version of solidity that’s required to compile this contract. This will prevent future compiler versions from compiling the contract where there may be incompatible changes.

You’ll notice functions to:
create a vehicle – This will be used when I create a vehicle and will set the values for some properties, for example, who the owner is.
change the owner – in particular, when the vehicle is sold, ownership transfers to the purchaser.

I’ve also got a strConcat function which is the best implementation I’ve come across (so far) to handle string concatenations in solidity.

Ensure Ganache is running then switch over to terminal and run truffle compile.

Once our contract has compiled we can now deploy it to our Ganache testnet by running this truffle migrate.

This gives us the following output:

It may be the case where you receive an error like this

In this case, truffle was unable to detect the network you’re attempting to deploy to. All that’s required to correct this is the addition of network settings to truffle.js

More configuration information can be found here.

If you look at the output, you’ll notice that the migrations were run, but….
There’s no mention of the contract just created!

What we’re missing is the instruction to deploy the Vehicle contract. To do this, we need to create a migration. This migration will then, automatically, be executed when calling truffle migrate.
The migration files need to be numbered sequentially – when looking at the project, you’ll notice there’s already a 1_initial_migration.js file. We will add our own and call it 2_vehicle_contract.js.

The migration code is relatively simple and looks as follows:

It is important to note that ‘require‘ needs to provide the actual name of the contract and not the file name, as a file can contain multiple contracts.

Once you’ve got this in place, running truffle migrate migrates this contract and the output look like this:

If you switch to Ganache, you’ll notice that the current block has advanced and taking a look at “transactions” reveals our contract deployments.

I’m going to use truffle console to interact with my contract – Truffle console is a basic interactive console that can connect to any Ethereum client.
I’ve opted to use console because I already have a network deployed in the form of Ganache – if this wasn’t the case, I would use truffle develop.

Navigating to the path of our project using terminal, execute truffle console. This spins up the interactive console.

The first thing we need to do is determine where the contract is (i.e. the address of my contract). Using truffle, this is easily done by running truffle networks from within the truffle console.
This lists the contracts I have and their addresses.

Using the address we can then call our function createVehicle(…) like this:

Lets now discover who the owner is by calling the OwnerName property.

We can also see the owners address.

Lets now sell our vehicle to a purchaser. In this contrived example, running on a test network, that’s going to be enacted by the owner transferring the vehicle to someone else. Recall, that only the owner can execute the changeOwner function.

I’m going to select a random address from Ganache (that’s not currently the owner) and use that as the new owner.

Let’s check the new owner and the address.

So our contract works and we can at any time, determine who the owner is or look at any of the other properties.

You would have noticed that there was an event recorded in the code, and looking at the output from the function call after changing owners, there was an “event” property that alluded to the code tying up with this property. Let dig into that event to see what’s recorded.

We do this by first getting all the events from the beginning of time then outputting those events

We can then see out event – Owner Changed – is the last entry in the logs.

Be aware, that typically, this is not how you handle events. Yes, it can be used to store some information like you see here. However, you would usually have other DApps listening for and responding to these events.
Also, in a production environment, be cautious of querying events in this way as it has been reported to (sporadically) crash your JSONRPC endpoint.
Read more here.

So folks, there you have it, a really simple Distributed Application (DApp) that stores some data and queries it.

In the next post I’ll dig a deeper into consensus algorithms; why we should care what they are and what they mean to developers.

Blockchain: Chaining-the-blocks

Leading on from my previous post, no blockchain topic would be complete without the obligatory explanation of how blockchain works at a high-level.

I say high-level because the intricacies of how things like consensus algorithms work, how they address Byzantine Fault Tolerance (BFT), how nodes ‘speak’ to each other, what the purpose of a nonce is, etc. will come later in my journey.

Ideally, I would like to take the ‘this is how we create something’ approach but that wouldn’t be much of a journey and some of the boring stuff is actually needed to build a foundation we can work on.

So, here we go.

One of the fundamental concepts when talking about blockchain is that of a distributed ledger (more on that later). The terms distributed and decentralised are often used interchangeably and thought to apply to the same thing – I assure you they are not the same.

The difference is probably best described by the image below.

As you can see, centralised is, as the name implies, where a single node controls the entire network. A failure at this node would incapacitate the entire network.

In a decentralised network, there is a greater degree of redundancy and fault tolerance however, faults at critical nodes would cripple substantial parts of the network and, potentially, orphan nodes.

Blockchain’s resilience comes from the underlying implementation of a distributed architecture. In this topology, a node is able to operate as a discrete unit. Each node has it’s own copy of the ledger and is not dependant on any other node(s) on the network.  A failure at a node would only affect that node and no other portion of the network.

We now have an abstracted understanding of the topology of the network – great. In this post, I’ve mentioned this thing called a (distributed) ledger. Lets dig into that a little.

Wikipedia says a ledger is “…a permanent summary of all amounts entered in supporting journals which list individual transactions…”

And that’s the same as a blockchain ledger:

Assume we have a deposit of $100 , this is recorded in our ledger and looks like this

We then continue to append more transactions

  • A deposit of $125
  • A withdrawal of $200; and
  • A deposit of $25

Eventually, our ledger look like this

In a blockchain implementation (usually after an amount of time), all these transactions are grouped together into a block and the transactions are ‘hashed’. Think of a hash as a fingerprint that uniquely identifies some data. Any change in the data (no matter how small) will dramatically affect what the hash looks like. So our hash uniquely identifies our block of transaction any may look like this

That hash then becomes an entry in the next block of transactions and this value is taken into account when generating a hash for that block. To understand this better, take a look at the illustration below.

This process continues on with each blocks hash becoming the ‘seed’ for the next block and we end up with something looking like this

We end up with a chain of blocks – hence the term ‘block-chain’.

You may be wondering what the point of this is. Well, lets take a look:

Imagine, if we tried altering a transaction somewhere within our chain

The hash for that block, now, would not match the original hash for that block. Further, because that hash is used as the seed for subsequent blocks, none of the subsequent blocks would be correct.

If a transaction was to be altered, not only would that blocks hash need to be altered but, also, every subsequent block.

Computationally, that’s a very difficult task.

However, that’s not all that lends immutability to a blockchain. Not only would you have to alter every block on that ledger, you would need to alter that ledger on every node in the network.

This is the incorruptible aspect of blockchain and this is what gives us certainty that what we see is really what transpired. Furthermore, the details of these transactions (in a public, unpermissioned, blockchain implementation) are transparent.

We’ve now established what a block is, how they are chained together and why blockchain lends itself to immutability, incorruptibility and resiliency.

We know we can’t alter transactions already committed to the chain but, at this point it would be logical to question the validity of transactions appended to the blockchain. If any node can add transactions, how do we validate and verify that the transactions SHOULD be added to the chain. This is where consensus comes into play and there are a few different ways to reach this consensus. I’ll discuss some of these in my next post.

A foray into the chain of blocks – The human element

Its been a while since I felt passionate about some technology that was beyond a drive in the industry, determined by current need. That need, being fulfilled by a proven and established technology. The MVC’s, SQL’s and C-Sharp’s of the world that, usually, ended up in an implementation with a solid outcome and left some client with a smile.

I read an article by Haseeb Qureshi in the not too distant past that changed my perception of the current fad: blockchain. After some consideration and my own readings I’ve come to a conclusion that herein lies a technology that speaks to the very core of who I am; the core of who we are as human beings really. That is, our intrinsic capability and desire to help others; and in that bring about a directed purpose and nourishment to the “soul”.

Since the beginning of human interaction, we have transacted on the premise that our trust will be respected and acted on accordingly. Trust, that some currency will be exchanged in return for goods or services.
We pour money into financial institutions in the trust that they will safe guard the fruits of our hard-earned labour.

If you you’ve heard about blockchain, your ears have also been inundated with the associated keywords: immutability, tamper-proof, and transparency. We’ve heard promises from other technologies of the then-forthcoming benefits that would be delivered to businesses and individuals but, there are some differences this time around.

Inspired by Daniel Gasteiger’s TEDx talk, lets delve into the past a little bit to explain where I’m coming from:
Over time, we have experienced human innovations that change the way we exist. They are so remarkable that, most times, we can clearly identify them and also agree, across cultural boundaries, that they are significant. A notable few can be summarised as follows.

In the 1400’s, the printing press saw a change in the distribution of knowledge. This knowledge changed hands from a privilege of the wealthy and entitled to everyone. It was the beginning of the revolution of thought.

knowledge-1400

The 1800’s was witness to a shift from manual labour, slave labour and a dependency on man power.
The internal combustion engine represented the beginning of innovation in transport, manufacture and the way business was done in general.

Power-1800

1900’s; Well, The internet changed everything! But importantly, it reduced the distance between each other. It brought us closer together, and among its many benefits it fostered immediate communication and the global village was born.

Distance-1900

The 2000’s ushered in the remarkable piece of work undertaken by Satoshi Nakamoto which addressed the double spending problem and an implementation of blockchain made its way into the world. The next wave of human evolution begins with a fundamental shift in the way we trust each other – blockchain – and its many implications. Blockchain offers the promise of no longer having to rely on faith (or a legal contract) and a gentleman’s handshake to provide security for our transactions. This technology now provides us the opportunity to empirically prove ownership and trace transactions in a trustworthy manner.

blockchain-2000

Skip ahead to the end of 2017 (when I’m writing this). Bitcoin is valued at around US$13,000 per coin and every industry is looking to how they can use blockchain to provide efficiencies, lower costs and maximise profits. I’m sitting back and thinking, where’s the human element in all this?! – Sure, business is important. It pays the bills and in a manner drives society. But I’m not seeing the direct ability to make peoples lives better. So this is the beginning of my journey. I want to educate myself on the technology, become a thought leader on the subject and drive change personally and through organisations that help people.

My intention is to publish my journey and learnings and help developers, businesses and laymen see the potential of the technology and buy into the collective desire to help others.

Unit Testing and Coding Best Practices for Unit Tests: A Test-Driven Perspective

Unit testing is an essential instrument in the toolbox of any serious software developer. However, it can sometimes be quite difficult to write a good unit test for a particular piece of code. Having difficulty testing their own or someone else’s code, developers often think that their struggles are caused by a lack of some fundamental testing knowledge or secret unit testing techniques.In this article, I would like to show that unit tests are quite easy; the real problems that complicate unit testing, an

Source: Unit Testing and Coding Best Practices for Unit Tests: A Test-Driven Perspective | Toptal

Summary: Omega has a long history of replica watches uk making beautiful ladies' watches, and in this new series of replica rolex famous discs, each watch has a delicate and pure design style, interpretation of replica watches the most cutting-edge fashion concept, and the image of fake watches modern independent women.