Blockchain is a platform that has a few key characteristics:
- it holds blocks containing data about transactions between parties
- it has a data structure that links those blocks together into a ledger of all transactions
- the block contents are cryptographically signed in such a way as to prevent alteration and the spread of any corrupt entry in the chain
- it has many participant nodes that have full or partial copies of the blockchain and act as validators and consumers of the blockchain
- it has a consensus algorithm that allows all nodes participating in the blockchain to agree what will be, and verify what has been written to the ledger
In addition, in some blockchain platforms the nodes participating in the blockchain platform emulate a virtual machine that executes code called a smart contract that has been written into the ledger. This is more similar to the java VM that executes a limited set of instructions based on a domain specific language than a vSphere VM that emulates a full computer. The example below relies on a blockchain that runs an implementation of the Ethereum VM, which uses Solidity as its language.
Many entities, as individuals or as part of a consortium, participate in using a blockchain. The participants may run one or more nodes, each of which get a full or partial copy of the blockchain data, and there is no difference between replicated data. There is no master copy, and there is no central entity that is responsible for the operation of the blockchain.
The data in the blockchain is immutable once committed. The data can be verified as accurate by all parties before or after being committed to a block. Data in the form of a smart contract can be put into the blockchain, and when executed, it runs on many nodes participating in the consortium to verify that they all get consensus on the results before committing the transaction to a block. The nature of smart contracts is that the rules are strictly defined, the results of execution can be verified on all nodes by any entity, and results of execution are stored on the blockchain, or in some case off blockchain, but referenced from the blockchain.
The result of the above paragraph is trust that is distributed among all the participating nodes. All transactions are validated by many parties before being agreed upon and committed to the blockchain. This is in contrast to centralized trust networks like the banking system, or the Department of Motor Vehicles, where there is a single authority that can validate accuracy of data.
When we talk about a blockchain application, we’re really talking about a smart contract and interacting with it to provide some outcome that can be verified by any participant in the blockchain. This type of app is often called a Dapp, for “distributed application”. The key here is that the app runs without a central authority; if there are nodes participating in the blockchain consortium, they are all responsible for executing and verifying the app.
Most people identify applications of blockchain in the banking and finance industries, but the distributed trust nature of blockchain has benefits for many kinds of businesses across many industries today.
This blog entry will cover
- some of the common use cases seen in across industries
- what important technical pieces need to be developed for a blockchain application
- a sample application that shows those parts working together on the VMware Blockchain
VMware has identified 4 classes of applications that are well suited to adoption of blockchain. If you have an application in one of these areas, you may want to explore a proof of concept implementation to apply blockchain to your use case. Once you’ve identified an application in one of these areas, look at the NIST Blockchain Overview page 42 for some questions to ask about your application to see if blockchain would still be a good fit.
When data must be shared with appropriate parties, and the integrity and availability of the data are critical, blockchain is an asset. Disease reporting and tracking and emergency response networks are some examples of this use case. In both cases, the goal is to be sure all parties have an accurate view of the situation as it unfolds, and blockchain provides that in a decentralized manner that prevents accidental or malicious alteration of that view. Centralized databases can achieve the same goal with lots of effort to ensure security, resilience, and data replication, but blockchain does this by default as part of its fundamental nature.
General database architecture relies on updating or overwriting particular fields in a table. Each update loses the historical record. Blockchain, on the other hand, keeps a running log of all changes to a field over time. This allows one to look into the history of any record to see how a particular item traversed the supply chain, or to get a full accounting of ownership transitions. Applications regarding part history and provenance, equipment maintenance and repair history, and tracking food or other products from production to delivery are well suited to using blockchain.
Any time an asset is transferred from one entity to another, blockchain finds a good use case. Transfers on the blockchain are one-way only, and there is no ability to revoke a transaction once consensus is reached. These qualities make blockchain a good fit for payment transfers, energy swaps, and deed transfers. Asset tracking from above also contributes to this application, as frequently it is important to be able to see the history of transfers, and not just the last transfer.
When it is important for an entity or application to be able to certify a claim such as “I am Bob, with Social Security number 111-11-1111,” “I have passed certification at a particular institution”, or “I have authority to transact on behalf of another individual”, blockchain has a good fit. Digital transcripts, background check, and digital voting are all applications that involve certified claims. The nature of blockchain means that once a certification has been proven valid, or later revoked, we can go back through the records to validate that is the case.
There are several bits of code involved in creating and managing a blockchain application. I’ll reference The Three Types of Code in DevOps as I really like how that article calls out the important types of code that are important to operating any application.
Feature code is the code that does the thing you need. For blockchain, it is the smart contract executable code that defines a set of rules for how a transaction proceeds, and code to interact with the smart contract.
A simple example of a smart contract is Solidity code that implements the following behavior:
“if you give me a specific sum of money, I will give you a license key to use a product for 1 year, but if you fail to pay the full amount by a specific time, I will keep a percentage of the payment and you will get no license”.
Smart contracts should be deterministic and achieve set requirements. We should all be good DevOps practitioners and ensure tests are written and validated in development and test networks before deploying to production.
Let’s run through a simplified version of events to make that code execute.
First the code is compiled and put into the blockchain as part of a deployment and resides at a particular address in the blockchain after consensus. It does nothing on its own. Later, another application makes a transaction or a call request to the contract that resides at that particular address in the blockchain. If a call was made, then there is a single execution of the code locally against the blockchain as it exists at that moment. A later call may return a different result.
If a transaction was made, then as part of the the consensus algorithm, the code is executed and the results validated by several nodes in the consortium. If the results of that transaction reach consensus, then the results are committed to another block on the blockchain, and the results as they were committed on the blockchain are the official execution results. All parties can verify that the code execution results in the same outcome, and incorrect or non-consensus results will not be committed.
There are some interesting things to see here. What if transactions against the contract have random results? Can consensus be reached if all the resulting transactions are different? What if just some or most of them are different? Different consensus algorithms will have different results, and I wouldn’t be able to predict what would happen in these cases, but if the transaction completes and ends up on the blockchain, we can see the result that met consensus.
Now we can look into the deploy and testing code we alluded to above.
Infrastructure code is code that deploys and configures the infrastructure needed to run an application. Infrastructure code for a production blockchain is a little different from traditional applications, because the infrastructure is all of the nodes that participate in the blockchain consortium. There is no need to instantiate the infrastructure like we would for running an application on a VM, it exists by its nature. In testing environments, however, we use can and should use simulated nodes and blockchain data to ensure smart contracts are written to expectations.
Reliability code for traditional applications is code that helps with observability or monitoring of the application, as well as code that helps scaling or fault remediation. This is a relatively un-explored area of blockchain that contributes to making blockchain difficult to operationalize. We can monitor our smart contracts to see how the application is running but this practice isn’t talked about much outside of academics. Also, there is no way to scale the performance of a Dapp or to “fix” a deployed contract. The immutable nature of blockchain means that bugs found after deployment must be fixed by deploying a new, correct contract, and phasing out use of the previous contract.
It’s critical that contracts be bug free at deploy time, as bugs can be exploited that have real consequences for real assets and deploying new contracts does not disable access to the buggy contract.
If bad code is released, there are a some options for preventing execution of the bad contract:
- use selfDestruct()
- use an emergency stop
- implement a proxy or a delegate pattern to re-route requests from the bad contract to a fixed contract
Now that you have seen the parts needed to implement a blockchain based application, let’s go through a concrete example. Following this blog entry on data classification for security, we will create an application for incident reporting.
Data Classification is an area of study that covers how to classify various types of data, what breach of that data means to the business, and how to report and respond to breaches. Incident Reporting is a critical piece of ensuring that detected breaches get to the proper response teams in a reasonable timeframe.
Existing solutions for incident reporting were originally based on manual paper-based processes, and now are generally based on web applications with a secured database. Tampering, maliciously or otherwise, with the people, the process, or the data could result in lack of knowledge that key data has been and may still compromised.
We will describe an incident reporting application that leverages the distributed trust provided by blockchain, and a go-lang web application to interact with it. This application allows for multiple parties, automated systems, or third-party organizations to call attention to an incident. It allows auditors to be sure that no manipulation of the record has occurred, and it allows the appropriate parties to respond quickly to incidents without regard to which organization they belong.
You can find the full code and how to use it at github.
This is the smart contract that implements the incident log. The log is a simple array of incidents, and some public functions to create and retrieve items in that array.
There are some inefficiencies in the code that would need to be worked out for production code. If this contract were running on the Ethereum blockchain instead of the VMware Blockchain, this data structure,an endlessly growing array, would become very expensive with regards to money.
Note that we can use the same smart contract on both Ethereum and VMware blockchains, and porting between them isn’t very difficult. In fact, the code below was initially written for Ethereum, and it runs without change on the VMware blockchain. The VMware blockchain supports API contains an endpoint that implements much of the Ethereum API.
Below is the important part of the web application written in Go for interacting with the smart contract above. It allows using a REST API or a web UI to report a new incident, look up a given incident by ID, or get the full list of incidents.
Note that retrieving the full log of all incidents or single incidents near the end of the chain, as allowed by the web UI, could take a large amount of time when the incident log is long. Definitely room for improvement there.
This bit of code configures the Truffle Suite to deploy the smart contract to a few environments. For more information on using truffle to deploy, see running migrations at the truffle website.
The dev and devui environments allow using Ganache, an Ethereum blockchain simulator that is part of the Truffle Suite, to test smart contracts before deploying them to the production blockchain.
Ethereum is a public blockchain, not a permissioned blockchain like the VMware blockchain, so those environments can be connected to without authentication. The production network is configured to allow connecting to the VMware Blockchain using HTTP authentication. This difference in connection to the blockchain API is the largest change to make when porting an application from Ethereum to the VMware blockchain.
To actually deploy to production, we run the following truffle command. Of course, we can also deploy to the development networks by changing the network parameter.
This is some simple testing code that leverages the Truffle Suite, Mocha, and Chai frameworks to verify the functionality of the smart contract. Tests could also be written in Solidity. If you want to go deeper into testing smart contracts, see testing functionality of the Truffle Suite.
To test, we run:
In traditional applications, we would follow good DevOps or SRE practices and instrument code to supply metrics that would be used to monitor the application as it runs. We could also use distributed tracing to watch transactions as they flow across multiple services. Blockchain is a different beast.
None of the code above has any method of observing what is going on in the running system. Surprisingly, most Dapps don’t. This seems to be a deficiency in most Dapps that exist today, and it is large enough to require its own blog entry to address. In that future entry, I’ll dig into how to instrument and monitor activity in the smart contract and in the application calling the smart contract, and how to disable contracts that are behaving bad.
You should now have a good idea what kinds of applications are suited to blockchain. In addition, you should know what three types of code you need to implement to get your own blockchain application running, and how that relates to good DevOps practices.
Tom Scanlan has been in the technology industry for roughly 20 years. He started in systems and network engineering roles, but found a passion for automating everything. This led him into software engineering, where the bulk of his career has been spent in DevOps-y roles. He is currently an architect responsible for researching and applying emerging technologies to business problems.