by Luke Davitt

December 16, 2019

Blockchain And The 51% Rule – PART III

In my previous post (Part ll), Proof of Work and Signing Transactions were addressed.  This final post will speak to the meaning of the “51% problem”, a proposed solution, and consensus groups.

  

Performance, Consensus Groups, And The 51% Problem

Throughout the posts we have been hinting at the term “51% Problem.” We are now ready to introduce what this means. A large number of cryptocurrency networks perform validations by checking a user’s proposed blockchain against the other remaining users. Since each person has their own copy of the chain, any proposed modifications to the chain must at the very least, coincide with what the other users have.  For instance, if User 1 decides they would like to corrupt the system and add an additional 1000 units to their wallet at point B in the chain, the proposal will get rejected, since every other user in the network has a copy of the chain and any modifications to it will break and invalidate it. A problem arises though if a user, or group of users, decide to work together to create a consensus against the system.  An extreme example would be, what if a country, with a huge amount of resources, decides that it wants to modify the chain?  It introduces enough users into the network to take a 51% stake in the network, thereby allowing it to make invalid and corrupt changes to the chain.

Another known issue with the noted form of validation is performance. Across a huge network, with millions and millions of users, how can a blockchain system perform its validations in an efficient manner? With millions of users needed to perform a consensus, the processing time for a transaction increases exponentially at a dizzying rate.

 

The Cascade Solution

In their paper “A Cascade Structure for Blockchain,” the authors make note of the problems inherited from the legacy system of blockchains. The primary concern was performance, how can transaction process be improved so that the system doesn’t become overloaded and stopped via the action of validation of transactions? The proposed solution was “microblocks.”

Fig. 10[6]

These blocks are given a strict “height” (number of transactions per block.)  In Operational System terms, this is like avoiding the dynamic loading of data.  The System only permits the addition of a set number of transactions per block, meaning that other areas can be streamlined, and memory saved since each microblock has a pre-determined size.  These blocks also possess an ID generated by the miners that independently notes their position in the chain.  Miner 1 can generate a block at a given point and does not necessarily need the validation of the preceding or appending blocks, since its valid ordered ID is generated independently.  In other words, the microblocks are generated in parallel.

Granted, the paper doesn’t stipulate exactly how this is done, so a degree of skepticism is required for this solution.  It is a design proposal that is not implemented, either because the authors don’t know how to implement their solution, or more likely because the authors want ownership of the solution without others copying their work.  Either way, while this solution does tick all the boxes, the author of this paper cannot say definitively that this is a viable solution, as the intricacies of the solution are not elucidated.

 

Consensus Groups

Another paper proposes a different solution for the performance, and consequently security, issues. In “Creating Consensus Group Using Online Learning Based Reputation In Blockchain Networks,” the authors propose an elegant solution. Each user, through a known algorithm, formulates and builds “reputation” by performing mining activities. As time moves on and “experience” is gained (analogous to common Role-Playing Game Systems), their reputation builds and the mining roles they perform are more dependable and require less verification.

“Test results indicate that the proposed model, which is a new approach in the literature making use of machine learning for the construction of consensus committee, successfully selects the node with the higher reputation for the consensus group.”[7]

The verification pool needed is minimized, to not be dependent on at least 51% of the network, instead machine learning and Artificial Intelligence algorithms are utilized for the network to learn which nodes (users) are dependable and their responsibilities are increased. The procedures used to conduct this philosophy center around “Byzantine Fault Tolerance” [7].

“Byzantine Fault Tolerance has been needed in airplane engine systems, nuclear power plants and pretty much any system whose actions depend on the results of a large amount of sensors. Even SpaceX was considering it as a potential requirement for their systems.”[8]

BZT is a known thought modification to the Algorithmic problem of the Two Generals Problem. The entire explanation to this is outside the scope of this paper, but in essence it deals with the idea that numerous participants in a proposed solution are unreliable, and a tolerance must exist for this problem.

By enacting an AI algorithm to account for this, and to build reputation among various nodes across the system, not only is the requirement for 51% validation eliminated, but the nodes performing this mining are also verified as dependable.

 

Proposed Solution

Out of the previous two solutions, the latter seems to be better (at least to the author). There is however a modification to this proposal, more philosophical in nature than algorithmic. In order for the financial markets of the world to readily accept the blockchain form of currency, the need for regulation is undeniable. The exact nature of the regulation is flexible, for example, the countries that choose to participate in the currency could form their own independent organizations for the regulation. This would negate the performance problem of consensus by delegating the responsibility to a set group.

In the example project, this is achieved by simply assigning a “regulator” attribute to a user, and then in the consensus method on the network, restricting that proof to only those users where regulator == true.

Fig 11[3]     

 

Fig 12[3]

The issue of less decentralization is not lost on the author; however, the benefits outweigh the cost. It is undeniable that cryptocurrency in its current form is being used for nefarious means, as well as positive.  At present, it is too easy for corrupt organizations to hide their activities inside this system. Furthermore, faith in the system would overall increase if separate known and respectable bodies/organizations would hold the system in check. Keep in mind, all users still possess a copy of the blockchains themselves. It is entirely within the power of each user to perform their own validations and proofs of work. The framework of the blocks still retains the anonymity desired.

A side benefit for a set group of regulators would also mean that governments participating in the system would automatically generate their own form of income. And, most appealing of all, the world would create its first universal currency. The blockchain system would create the backbone for a system of commerce with a philosophy of cooperation unseen in the current systems available. One can then contemplate the implications of a universal currency adopted by the world and its governments, but those ideas are outside the goals of this paper.

 

References

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: GitHub.com, https://github.com/LukeDavitt/block-chain.

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.” https://medium.com/loom-network/understanding-blockchain-fundamentals-part-1-byzantine-fault-tolerance-245f46fe8419 . 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