Blockchain Programming Part 4: Consensus
We have arrived at the final section, where we will be discussing the consensus mechanism that will be implemented in the Blockchain, this post is the continuation of the Blockchain Programming series which is a detailed and practical hands-on guide to build your very own Blockchain.
Step 4: Consensus
This is very cool. We’ve got a basic Blockchain that accepts transactions and allows us to mine new Blocks. But the whole point of Blockchains is that they should be decentralized. And if they’re decentralized, how on earth do we ensure that they all reflect the same chain? This is called the problem of Consensus, and we’ll have to implement a Consensus Algorithm if we want more than one node in our network.
Also Read: Blockchain Programming Part 1: ‘Building A Blockchain’
Registering new Nodes
Before we can implement a Consensus Algorithm, we need a way to let a node know about neighbouring nodes on the network. Each node on our network should keep a registry of other nodes on the network. Thus, we’ll need some more endpoints:
/nodes/registerto accept a list of new nodes in the form of URLs./nodes/resolveto implement our Consensus Algorithm, which resolves any conflicts—to ensure a node has the correct chain.
We’ll need to modify our Blockchain’s constructor and provide a method for registering nodes:
Note that we’ve used a set() to hold the list of nodes. This is a cheap way of ensuring that the addition of new nodes is idempotent—meaning that no matter how many times we add a specific node, it appears exactly once.
Also Read: Blockchain Programming Part 2: Our Blockchain as an API
Implementing the Consensus Algorithm
As mentioned, a conflict is when one node has a different chain to another node. To resolve this, we’ll make the rule that the longest valid chain is authoritative. In other words, the longest chain on the network is the de-factoone. Using this algorithm, we reach Consensus amongst the nodes in our network.
The first method valid_chain() is responsible for checking if a chain is valid by looping through each block and verifying both the hash and the proof.
resolve_conflicts() is a method which loops through all our neighbouring nodes, downloads their chains and verifies them using the above method. If a valid chain is found, whose length is greater than ours, we replace ours.
Let’s register the two endpoints to our API, one for adding neighbouring nodes and the another for resolving conflicts:
At this point you can grab a different machine if you like, and spin up different nodes on your network. Or spin up processes using different ports on the same machine. I spun up another node on my machine, on a different port, and registered it with my current node. Thus, I have two nodes: http://localhost:5000 and http://localhost:5001.
I then mined some new Blocks on node 2, to ensure the chain was longer. Afterward, I called GET /nodes/resolve on node 1, where the chain was replaced by the Consensus Algorithm:
And that’s a wrap… Go get some friends together to help test out your Blockchain.
Also Read: Blockchain Programming Part 3: Interacting with our Blockchain using Postman
Featured Photo by Christopher Gower on Unsplash
Disclaimer: The opinions presented here are of the Authors. Readers should do their own due diligence before taking any actions related to the promoted company or any of its affiliates or services. CoinScenario.com is not responsible, directly or indirectly, for any damage or loss caused or alleged to be caused by or in connection with the use of or reliance on any content, goods or services mentioned in the press release.
Here is a list of Contributors on Coin Scenario. If you wish to submit a Press Release, please Click Here. If you wish to Advertise with us, please Click Here.
