November 12, 2019
In Part I of this post, I provided a description and key aspects of Blockchaining. In this post I will discuss the proof of work and signing transactions.
One form of validation for a block is known as Proof of Work. This is known as a type of “Smart Contract” in the cryptocurrency world. “The importance of smart contract integration of blockchain technology became a focus area to develop because it gave peer to peer transaction and database … maintained publicly in a secure way in a trustful environment.” .
This practice is also known more commonly as “mining.” There are known server houses, all over the world, that are fully committed to this singular purpose, due to the fact that one of the rewards of mining is earning currency in the crypto network.
There are several characteristics that one can look out for to recognize a Smart Contract (Proof of Work) system:
“Smart contracts are machine readable code run on blockchain platform”
“Smart contracts are part of one application program”
“Smart contracts are event driven program”
“Smart contracts are autonomous once created, no need to monitor”
“Smart contracts are distributed” 
Simply put, by delegating the responsibility for verification to an automated system trusted by millions of users, the mining process can be trusted, since it can be performed multiple times across many users to achieve and agree upon the same result (more on the agreeing at a later part of the post).
An example of how this is achieved is by enforcing a particular format of the hash attributed to each block. A complex algorithm is developed that only a computer can solve in a reasonable amount of time but also not immediately done by the computer (CPU). This is why GPU processor costs have been fluctuating at extreme rates. The GPU’s can perform complex algorithms in parallel at desirable rates, making them ideal for performing mining operations for crypto currency.
In our Block.rb class, we can see a rudimentary form of this enforced. First, let’s take note of the “calculate_hash” method.
Fig. 4 
Here we are using a version of the SHA-2 algorithm known as the 256 digest version. It is specifically “a set of cryptographic hash functions designed by the United States National Security Agency” . This method is called in the block code by method mine:
Fig. 5 
This is one of the most distinguishing features in a blockchain (in the real world this implementation is more complex). Make note of line 7, where the hash is set for the block. The SHA-256 algorithm is given a set of characteristics exclusive to the block (the time, the transaction, the previous hash, and a “nonce”). Consequently, a hash is generated from the algorithm. The loop then begins again and checks for the criteria set by the network (the difficulty). In this case, the difficulty is set by the number of 0’s that exist at the beginning of the hash string. For example, say that a difficulty of 2 is set. In this case, the while loop will execute until the 256 algorithm generates a hash with 2 zeros at the front of the hash. The algorithm will need to be performed countless times in order to find the correct hash. If it is not found, we increment the nonce variable and try again. The mining can be further extended by increasing the 0’s desired at the front of the hash (say, to 4 zeros instead of 2). This will further restrict the randomized generation of the hash, and consequently, make the CPU work harder to find the correct combination of nonce, timestamp, transaction, and previous hash to generate the proper format. As CPU’s get better at performing these calculations, we can simply increase the number of 0’s desired at the beginning of the hash string.
The question then arises, how do we motivate users to perform these mining transactions? Why would anyone purchase and devote real energy (as in electricity), money (ironically), and time to mining/verifying these transactions? The answer that most blockchain systems have come to is a reward system to those users/nodes that perform the mining.
Again, blockchains are at their base, an Operating System with a particular form of implementation. Its technique can be applied to any number of systems. In cryptocurrency’s case, this reward consists of the generation of currency to the user who performs the mining. This policy’s benefits are twofold: 1) Users are properly motivated to “work” for the system by verifying/validating the proposed transactions by being rewarded for their work. 2) This also provides a way of introducing new currency into the system, thereby allowing for the cryptocurrency to expand in use and applicability for its users.
An example of this solution is again, shown by the code in the example program. Take note of the fact that there is a transaction object in the project that handles the exchange of currency. The network object then stores these transactions in the “pending_transactions” attribute (simply an array of transactions). These pending transactions are not executed, they are simply proposed transactions that a user requests to be mined. A user then signals their desire to mine the transaction and they are given a list of pending transactions by the network.
Refer to the parameters passed to the block_chain object for a user: reward_address, network_pending. The reward_address is an identifying signature assigned to each users wallet.
The Bitcoin service is utilized to generate a secure key every time a user is generated. In this case, we then assign it a wallet_address attribute that is formulated from the key assigned. This is randomly generated and entirely unique to the user. This attribute is then passed to the mine_pending_transactions method. The next line is where the reward is generated for the address, Transaction.new is called and the reward is passed as the transaction, and this new transaction is then added to the pending_transactions listed on the network. In this case, the network is letting the requesting miner to process and mine its own reward. The concern may be that a miner shouldn’t process its own reward, but the beauty of a decentralized system is that part of its verification process lies in the rest of the network agreeing with the chain (list of new nodes) generated and proposed to be added to the end of that chain.
An interesting part of the code to make note of at this point is how User balances are assessed by the network.
In essence, the balance of a user in a blockchain system is the sum of all its transactions across the linked list. The method simply checks to see if the address of the transaction being checked matches the one requested, if so, it adds that transaction to the overall balance. Since some transactions will be negative (ie. the address sends a negative transaction over the network for payment), these will also be assessed. This loop also shows another characteristic of a blockchain, all transactions and blocks stored on the chain must be in order of the time they were generated. If a block is added to a chain at the inappropriate spot, the balance will not be a valid representation of what has transpired in real-time.
We have now reached a point where we can say that the reader understands a basic implementation of what a blockchain is, and what it performs. It is a collection of blocks, (in Operating System terminology: nodes) that contain a verified list of information regarding the evolution of the system itself. Proposed operations/transactions are contained within each block, and each user within the network can perform the proposed transactions through mining. The obvious question then arises, how to safeguard against corruption? How do we know that a user’s proposal for additions to the change are in fact valid and not corrupt?
In my final post (Part lll), I will speak to the meaning of the “51% problem” and a proposed solution.
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