Explaining 'Blockchain'

After the past few 7 years threading both the Cryptocurrency scene (personally) and the 'Enterprise' Blockchain scene (professionally) I have had the privilege to learned an amazing amount of information, processes, development and architecture. In regards to cryptocurrency I have been actively participating since 2011, mostly in the capacity of POW Mining, but also in regards to purchasing cryptocurrency, trading, spending it on goods and services, such as dApps (Decentralized applications), yes… I own a few Cryptokitties. In 2013 I created BitsBeTrippin on YouTube and felt I would try to help lesson the barrier of entry on mining by showing individuals how to participate. Agnostic to the token, most of the content has been around Proof of Work mining (GPU based), like building a rig, configuring and what it takes to maintain. This approach helped me learn more on optimizations, tips and tricks through a dialog when livestreaming over past years. This information is free and available on YouTube and Twitch. I have chosen the path of no paywalls to ensure access is available to anyone with an internet connect. 5 years later now, 270+ videos, over 4000 hours of content covering everything from mining, to architecture, to value propositions of various decentralized cryptocurrency networks.

With regards professionally, I take the opportunities I can to educate fellow co-workers, customers and business partners on Enterprise Blockchain's, while still ensuring the messaging around cryptocurrency networks and their value remains understood. Not just in what something like Hyperledger is or Enterprise Ethereum, but 'where' specific requirements I receive when answering technical proposals. Coming from a Solution Architecture, previous to that Technical Program Leader on large development contract(s), I work to help forge approaches on the use of Blockchain within the enterprise stack, that meets and exceeds customer requirements. As I have tried to tailor the message, this is an activity that has proven to be quite challenging.

I first start explaining the key difference between Cryptocurrencies and what is considered enterprise implementations of Blockchain Technology by itself, without a 'token'. To understand Blockchain, it is critical to understand the, sometimes fanatical 'hype' around Cryptocurrency and at an elementary level what the breakthrough of solving a 'double spend' problem through a consensus algorithm reinforced through the proof of "work", insert your consensus / Byzantine Fault Tolerance / really brought to us in the way of 'exchanging'.

The most fundamental explanation I can give to you is that Cryptocurrency enables us to transact in a 'trustless' way between two parties, without the need of a third party. I will say it again, but in another way, "I do not have to trust you to transact with you, anywhere on the planet, for any reason we choose to transact, we do not have to ask for permission and I can transfer you a 'token' that effectively has a 'exchange' rate for goods and services and this is all handled in a cryptographically secure way". "It's been running for 10 years and while the quality of service has had some discoveries and some limited changes it continues to function." The facilitation of this service rewards the participants to keep it running and even their participation can come and go freely.

Now if you read through that slowly, understand the power in begin able to independently verify the transaction ledger yourself, get a response of validations from the network that the transaction was valid and ultimately have confidence in the finality of the transaction once posted to the ledger because of the consensus and incentivized activity to facilitate, it's only natural to think, I see the power in fiduciary purposes, but can I do that with information too? When trying understand 'Enterprise' Blockchain, DLT, or just general "Blockchain Technology" is the progression of exploring the idea, "can we have the approach, benefits and processes around what makes Cryptocurrency tick in an information capacity".

When trying to explain 'Enterprise' Blockchains to individuals you quite often will find yourself circling back to an answer, like a circular reference, effectively explaining a decentralized database. What catches most in this loop is because you effectively end up coming to a conclusion that the 'initial' write of any particular record is ultimately a 'trusted' transaction. It comes down to the very fundamental structure of what action you are trying to perform with the Blockchain. If it is to use the technology to facilitate 'information' then you will have to have some level of established trust with whatever process, service, entity, individual that is creating that first transaction. Once the transaction is posted to the ledger, then any update's become future transactions in reference to the first transaction in a later block, reinforced by the participants, distribution and consensus of the Blockchain you have chosen. Effectively the enterprise gains the immutability, non-destructive (delete) and cryptographically proof on data after the initial write, of the record in question. From this perspective, the tone that Permission based Blockchains, ultimately falls into a Simi-trustless capacity, as those initial post of transactions come from the outside, thus always keeping a garbage in scenario.
The story for some unfortunately end there … as most go, "well I might as well go with a database and close the book". This is where the next level of discussion starts to play a critical part. The story is not over! If you do not play that scenario out, even a bit further, you are doing a disservice to whomever you are providing the analysis to. The initial data transactions are important and yes, as in that scenario, they can take in right, wrong or malicious information, however, the fact they take that data in, record it on a decentralized, distributed participant (permissioned) ledger fundamentally changings everything on the future state of that data. The fact is we record right now information in centralized database architecture that is typically is owned/maintained by a centralized data owner, touched by the system of record administrators. While this data could be federated across multiple participants, the linkage to the original source data is typically held together by an ETL process that potentially change the original meta, logging information associated to that data including original update logs, change history for portions of the full record. Blockchains integrated within that concept of federation of systems of records can play a critical first step on a whole new approach to data quality. This would allow key insights on behavior analysis on information that right now would qualify as an immeasurable data 'events/metrics' that often go undetected, non-observed and typically discarded through log cleanup routines. That new level of insight could play a key role in active defense cybersecurity, employee mistakes that are never caught and unauthorized updates, access and changes to original records. To not explorer this as an initial alternative does not help address existing problems with centralized data sources including federated data warehouses.

Bottom line, the fact I can have a single enterprise database administrator with write access to the 'highly secure' database is my ultimate issue. At the leanest minimalist approach, an enterprise Blockchain can be decentralized across multiple sites, including multiple participants at a categorical level of the data scheme provides a quorum of integrity vs a single party that can make 'changes' to original records, one must create new reference transactions of the change, not just go into the centralized data store and update the original record. While databases can be setup to 'track' the changes, down to the most finite level, if they remain centralized, ultimately the rules and original history (system of record) remains under one roof, creating the very issue of "how valid is that data really?".
The next steps in this process is tailoring the message to answer the root problem in business and in our existing infrastructure. Most all approaches to DLT, Blockchain and even cryptocurrencies end up in a detailed data description of how the protocol itself works, or why consensus is important. All valid arguments, but it is the equivalent of explaining to stakeholders the importance of routing tables and business rules within a router facilitating TCP/IP traffic across the internet. The messaging is around the protocol level and needs to move up to direct linkages to the problems we all need to solve around data consistency, ownership of the information being fully centralized and the configuration management around the databases and security can grossly be different between organizations causing countless exposure, risking changes to original records or outright data destruction in the event say a logging VM crashes and looses the history of 'data' change activity. The architecture most modern databases sit on just isn't the raw source record, but the fact the scheme on change history is recorded in another ancillary system that may have IM&R (information management and retention) controls on logging. The fact that the logging history will go away at some point while you keep the original record. These types of situations are throughout businesses commercially and throughout governments, creating a hole when the time calls for a forensic analysis of 'what happened' to an original record in data.

At a minimum set, creating a linkage to the change history of an enterprise system, on chain, sufficiently decentralized with IPFS storage would allow for a measurable, accountable, immutable account of the change history in this example, that would put the source across a quorum of participants. The data engineering, mining and insights that activity would give a level of confidence in the integrity, validity and finality of the original transaction pulls its change history that any counterparty of the information exchange could independently verify as a participant on the enterprise blockchain. Architecture around state channels of that information, group level access would insure their view to the information and the eventuality of that information moving to a public domain to include many more participants through zero knowledge proofs at a future data helps show an innovation path that continues to evolve to a path leveraging existing public, permission less infrastructure.

In closing, we have all just begun in understanding the power and implementation strategies around Cryptocurrency and Blockchain innovation. While initially, participants may have entered the space in the hype train, there are organizing groups of academics, enterprise participants and excited open source contributors that continue to build out the future state of this 10-year old experiment. I personally have a strong believe every industry in the world will start to inherit the fruits of those labors in the form of multiple public and private implementations of blockchain and cryptocurrency, both financially and in exchange of information.