Monday, January 1, 2018

What I learned about blockchains today


I have been hearing so much about blockchain recently that I decided to dive in on this first and see if I can get a good understanding of what it is. Why? Because I know how to party. I am in no way an expert on blockchains and the post that follows is my understanding based off of a few hours of research earlier today.

What is it?
Essentially, a blockchain is the entire transaction history of a single unit. This doesn't clear things up much I know. But to truly understand what a blockchain is, I feel that it is important to understand how transaction history is maintained in a standard database management system.

In a relational database model (which is the most common type of database management system) all transactions are stored in a centralized location (think excel spreadsheet) where each individual transaction would make up a row in the spreadsheet. Each row contains all of the important information about each individual transaction so that all details of the transaction can be determined ie. individual, company, date, product type, etc.. This means that there is a single version of transactions that is the master record of all transactions. If you want to learn about a specific transaction you would query the central database.

So with an understanding of how traditional databases store transactions we can look at how blockchains do things a bit differently. Each transaction in blockchain makes up a "block" that contains the relevant information for that transaction (ie. date, amount, etc). This "block" is then appended on the end of the chain in which it is tied to giving us a blockchain containing every transaction for the life of that particular unit. This chain is then dispersed throughout the numerous computers that make up the blockchain network. When any chain is appended, the update is sent to every computer on the network to ensure that they are all showing the recent addition of the new block of data. This means that there is no master record of data, the master lives on every computer dispersed across the blockchain network.

As an example, lets think of a debit card transaction. The basic steps are laid out below for how a relational dbms handles this:

  • you request to purchase a pack of gum from 7-11
  • you insert your card to pay for the gum
  • the software validates that you have enough money to pay for gum by contacting your bank to request the transaction
  • The bank looks up your account and either 
    • Accepts the request and posts a new transaction to your bank ledger
    • Denies and send denial to 7-11 software
  • Pending reply from the bank the sale is either finalized or terminated
How would the same transaction work using blockchain:
  • You request to purchase gum from 7-11
  • You submit your cryptokey that ties to the blockchain for your bank transactions (sounds more difficult than it is. Think PIN#).
  • Using this cryptokey, the requested transaction is broadcast across the network of computers searching for your blockchain that matches the cryptokey.
  • The network validates or denies that the funds are available to make the purchase 
    • They are able to do this because they are all showing identical records for the blockchain
  • If verified, approval is sent to allow the transaction
  • The transaction is finalized and a new "block" for the transaction is added to the existing blockchain
  • The new block is then distributed among all of the computers on the network 
  • Transaction is now complete and you have some gum
Why is this advantageous?
Because blockchains are not only decentralized but also distributed, there are many advantages that are obtained. 
  • Security
    • Because the data is spread out and stored on numerous computers, if someone were to try and corrupt a single computers version of the blockchain, the rest of the network would still have the accurate version and would reject the manipulated version. 
    • Instead of using the "username/password" system to protect data, blockchain uses encryption.
  • No single point of failure
    • If the network that stores a relational database module goes down, no one has access to the data in that model.
    • Because the computers utilized in blockchain are spread out across numerous networks, it is incredibly unlikely that all networks in which the blockchain network operates on would be down meaning that the data is still accessible.
Future Implications
So what does this mean going forward? We have all heard of blockchains in reference to crypto-currencies, but there is so much more that can be done with this technology. What if a person's medical records were stored using blockchain? Hospitals and doctors would always have the most up to date and accurate medical information for each person that they are treating. Supply chain auditing, file storage, protection of intellectual property, identity management, land title registration, etc...

There really is so much more that this technology can accomplish and I am starting to believe that it is going to have a huge role in the IT industry in the coming years. There will always be a need for relational database management systems, but blockchain may take over as the primary dbms in the coming years. 


Sources:
https://blockgeeks.com/guides/what-is-blockchain-technology/
https://youtu.be/r43LhSUUGTQ


Update on 1/8/18:

Read this earlier from another website (link below) and really enjoyed how simplistically they broke down some of the  issues with blockchain.

Bitcoin’s blockchain represents an early step toward manufacturing trust in a peer­to­peer mesh of unknown and untrusted computers. However, significant design choices in current blockchains limit the scope of applications that can be distributed. For example, consider the performance requirements for a notional, distributed game of Minecraft. Let’s assume 1000 players, interacting with each other with no central server. Each player might generate 1 or more transactions per second (e.g., moving in the Minecraft world), resulting in a requirement for more than 1000 transactions per second for the community as a whole. Some scenarios will require the community to agree very quickly on the order of transactions. For example, when two players each attempt to pick up the same object, it’s important for the community to agree who was first. The current Bitcoin blockchain has a theoretical maximum throughput of seven transactions per second, far fewer than that required by our notional game. Additionally, it can take an hour for the community to get enough confirmations to agree on which player picked up the object, which is too slow for meaningful game play. In general, many applications require thousands of transactions per second. Many applications require community agreement on the order of transactions in near real time. Other examples might include distributed office applications like Google Apps for Work (docs, sheets, slides) that can be offered without requiring users to trust Google, or a distributed eBay that doesn’t require a server to enforce the auction rules, or distributed control of SCADA systems to improve system security. The first generation of distributed consensus algorithms served as a proof of concept of what’s possible. The next generation of distributed consensus will enable a cloud of applications, each with a constitution and managed by a democracy, not a dictatorship.


http://www.swirlds.com/downloads/Dictatorships-Democracy-and-Blockchain.pdf