by Luke Davitt

November 04, 2019

Blockchain And The 51% Rule – Part I

In 2009, a mysterious person using the pseudonym Satoshi Nakamoto introduced his/her version of a cryptocurrency system to the world.  A few years later, any person who had invested an amount in the cryptocurrency (Bitcoin) saw the return on their investment exponentially increased at a level that most had not anticipated.  Due to this skyrocketing return, its societal impact had an equal (if not greater) growth.  Bitcoin had become a mainstream cultural icon; the currency gained further legitimacy.  Since then it has seen validation from not only the Tech Sector but the Financial as well.  Banks such as Chase (one of the most powerful financial institutions in the United States) have jumped tentatively on board and allotted a portion of their resources into cryptocurrency.

As exciting as this currency is, few regular investors (or people for that matter) truly understand what a Blockchain system is and how it works.  This paper will discuss a generic form of the Blockchain.  It will provide conceptual insights into the technique and will address a known problem: the 51% Rule.  Part III concludes with a proposal to address this issue.

What Blockchain Is

In accompaniment with this post, a basic block chain system (naïve in construction) will be provided to articulate the concepts discussed. The programming language Ruby was used, which has an OOP philosophy (Object-Oriented). The goal will be to provide the reader with concrete examples of the concepts enforced by the system/structure. The code can be read at: [3]

As a Linked List 

In many ways, the Blockchain System is reminiscent of a simple aspect of Operating Systems: Linked Lists.  The Block can be thought of as one of the Nodes in a Linked List, and the Chain can be thought of as the List itself. 

 Fig. 1 [1]

As the figure shows, the Blockchain possesses a root block, known as the Genesis Block.  Each block contains data concerning its identity, and the data that it is meant to hold.  A significant part of data is the reference to the previous block in the chain.  The Genesis block has a previous node reference of null, however each subsequent block contains a reference to the id of the preceding block.  For now, it is important to understand that this id is close to impossible to corrupt, and that any attempt to do so will invalidate the blocks after it.  “Hash values are unique and fraud can be effectively prevented since changes of a block in the chain would immediately change the respective hash value.”[1]. The chain then becomes a reference to this collection of blocks.

In the code of our example program, these relationships are stipulated in the Block.rb class.  Make note specifically of the “previous_hash” attribute for this object.  This is not only how the nodes are listed together, but as we will see, also is part of the validation process for a block. 

Fig. 2. [3]



Another key aspect of the Blockchain Operating System is the validation technique that it employs.  Blockchain is basically a peer validated system.  Every participant in the system validates a proposed change to the chain, and as long as the other participants approve of the change and verify it as valid, the addition can be made.  A benefit of this technique, apart from peer approved validity, is the reassurance that the system is fully backed up across all its peers.  If one participant is corrupted or loses its copy, there are multiple copies of the chain within existence, making it virtually impossible to lose.

“Blockchain provides a transparent infrastructure in which chances of any fraudulent entry is minimum because the decision of addition of any data is broadcast to the whole network, and any critical decision is taken with consent of majority of users instead of a single centralized administrator/system.”[2] So while this is an initially appealing technique, there are security implications that arise that would otherwise not be a factor in a centralized system.  Alas, nothing is fool proof.  An obvious vulnerability is that if a blockchain system is monopolized by a particular resource (or resources), the proof can be altered as long as the majority of participants verify its validity.  This is what’s known in the Blockchain community as the “51% Rule”.

To simulate what a network of blockchains may look like, the Network.rb object was created. When initialized, it simply builds a network of users, which each owns their copy of the block chain:

Fig. 3. [3]

While here, take note of methods such as “ask_for_consensus” and “user_balance”.

My next post (Part II) will address Proof of Work and signing transactions. 



Gomber, O. Hinze, M. Nofer, and D. Schiereck, “Blockchain,” Bus Inf Syst Eng, vol. 59, pp. 183-187, 2017.

Hassan, M. Rehmani, and J. Chen, “Privacy Preservation in blockchain based IoT sytems: Integration issues, prospects, challenges, and future research directions, vol. 97. Future Generation Computer Systems, Swinburne Universityof Technology, pp.512-529.

Davitt, “Rudimentary Block Chain”, August 24, 2019, Repo Source:,

Mohanta, S. Panda, D. Jena. “An Overview of Smart Contract and Use cases in Blockchain Technology.” 9th ICCCNT 2018, July 10-12, 2018, IISC, Benglaru, India.

Penard, T. Wekhoven. “On the Secure Hash Algorithm Family.” Faculty of Science, Utrecht University. 2015.

Qi, Y. Zhang, Y. Wang, J. Wang, Y. Wu. “A Cascade Structure for Blockchain.” Proceedings at 2018 1st IEEE Confernce on Hot Information-Centric Networking. University of Science and Technology, Shenzen China.

Bugday, A. Ozsoy, S. Oztaner, H. Sever. “Creating Consensus Group Using Online Learning Based Reputation In Blockchain Networks.” Pervasive and Mobile Computing Science Direct, Volume 59, 2019.

Konstantopoulos. “Understanding Fundamentals, Part1: Byzantine Fault Tolerance.” . Accessed August 15, 2019.

Li, l. Shen, G. Huang. “Blockchain-enabled workflow operating system for logistics resources sharing in E-commerce logistics real estate service.” Computers & Industrial Engineering, Vol. 135 p. 950-969. July 02, 2019.

Yeung. “Regulation by Blockchain: the Emerging Battle for Supremacy between the Code of Law and Code as Law.” The Modern Law Review, Vol. 82 No.2. 101 Station Landing, Medford MA.

Androulaki, C. Cachin, C. Ferris, C. Stathakopoulou. “Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains.” EuroSys ’18, April 23-26, 2018, Porto, Portugal

Luke Davitt

Luke has been a Web Developer for seven years, focusing primarily in Ruby, but also Javascript and Native Android. In his off time he's either taking care of his kids, mowing the lawn, or studying as a Grad Student for Computer Science via Syracuse University.

search posts