Global High-Tech Innovation

March 19, 2018

Last year I purchased the book Blockchain Revolution by Don Tapscott. Once some of blockchain's privacy and commerce kinks solve, the book posits that the technology will be positioned to revolutionize different aspects of society (e.g., finance, government, voting, etc.).

I've been thinking about blockchain as a storage system and have concluded that it is evolutionary and not revolutionary. It's an interesting thought exercise to trace storage evolution and draw your conclusion as to whether or not you agree. I've re-read some of my storage-related posts over the years and looked for a pattern of evolution onto which blockchain builds (like adding another block onto a chain).

I've concluded that blockchain is an evolution of a decades-long challenge to provide trusted storage platforms. It can also provide a surprising new twist: a data valuation protocol.

The first comment I would make is that storage functionality advances because applications evolve. New storage features typically emerge because new applications outpace them (e.g., they need more capacity, speed, scale, availability, etc.).

When I graduated from college storage was attached to the end of a cable. Applications drove the evolution from a single disk to multiple disks (RAID) by requiring increased capacity and performance. RAID made advancements to the concept of "trust by math". New approaches for data integrity bits, parity shedding, and non-volatile RAM provided better trust in more circumstances. The disk array era began. Cabinets filled with disk drives and increasingly large amounts of raw (block) data flowed onto these systems. For the first time, an application would ask for data on a failed disk and the data would have to be mathematically rebuilt. Storage users, therefore, trusted that when data from a failed drive was returned to them, the math had regenerated their data correctly. Once the market accepted that this form of trust worked well enough, the disk array era took off.

Over the years many layers of functionality were added on top of this layer of trust: mirrored-caching, storage area networks (SANs), multi-pathing, and networked-attached storage (NAS). The trust of the underlying mathematical layer was augmented by redundancy and availability. Failures could now occur at the disk layer, the processor layer, the switch layer, and all the way up to the application layer. Applications asked to receive the data quickly no matter what failed (redundancy/availability) with mathematical correctness in the face of disk failure (data integrity). The metadata traveling alongside this data also required trusted stewardship. More and more mission-critical data flooded onto these trusted systems until the requirements of applications again outpaced these architectures.

New application requirements insisted that all data was checksummed from the application down to the storage to preclude tampering, and in some cases, to enforce data retention and prevent deletion. These features resulted in the rise of content-addressable storage (CAS) and ultimately to the object-based systems that are still popular today. Object-based systems started shipping roughly fifteen years ago and perhaps the most remarkable characteristics of these types of systems were the extensive use of cryptography from the application layer down to the storage system. Systems like Centera became some of the most "trusted" systems in the industry (in fact the engineering team ended up achieving six-nines of availability to go along with the integrity provided by the cryptography).

All of the systems described above began to fill up beyond their capacities. Applications also became increasingly global and expected to read and write data from anywhere in the world. Worldwide availability requirements resulted in the creation of globally-scalable object stores that were driven by trust policies. For example, a copy of a video stored in Los Angeles could be checksummed, encrypted, and stored in four different locations around the world. One of the first storage systems released by EMC with this capability was Atmos (and eventually ECS). Now these globally distributed, trusted data stores are more commonplace.

If we consider blockchain as the next evolution of trusted storage, can't we just think of it as a variant of globally-distributed object stores? While we need to recognize that a blockchain doesn't store large data sets like an object store does, we can certainly draw some comparisons:

Applications insert data into a blockchain from anywhere in the world.

That data is immediately checksummed.

The data is accompanied by identity metadata which must also be preserved.

The data is replicated to multiple, global locations.

The data is tamper-proof and cannot be deleted.

Applications across the world have access to the data.

There are, however, a couple of evolutionary additions that blockchain brings.

First of all, every blockchain transaction has to be digitally signed by the owner via a private key. The storage systems described above don't work that way. This feature permanently associates each storage entry with a specific private key. This enables a wide variety of use cases, not the least of which is data ownership.

The second interesting addition is the insertion of data value into blockchain's storage protocol.

This statement is subtle. The very first blockchain (the Bitcoin blockchain) transported value in the form of a cryptographic token (subsequently associated with fiat currencies). Newer blockchains can now transfer data AND tokens. The industry can now start building a trusted data exchange platform for digital business.

These data exchange platforms may or may not embed value transfer directly into their protocols, but the trust inherent in global ledgers will remove friction and unlock value to the bottom lines of next-generation digital companies that participate in blockchain ecosystems.

Value transfer, when combined with the concept of data ownership, means people can start getting paid directly (and sometimes indirectly) paid for their digital assets.

There is, however, a problem that still exists. There is currently no blockchain storage implementation that can scalably carry forward the performance, availability, resiliency, and trust represented by the decades of evolution described above.

Fortunately, some of the world's experts in building scalable blockchain implementations work within Dell Technologies. They have developed new algorithms that will bring enterprise-classs storage to the blockchain applications that need them (I will describe these algorithms in upcoming posts).

These algorithms, of course, can't exist in a vacuum. They must be packaged and deployed into a solution that runs alongside their existing mission-critical data assets.

March 13, 2018

I used the graphic above in a Data Value presentation at Dell's Field Readiness Summit several weeks ago. The presentation focused on using data to fuel business transformation. I like this picture because it highlights the flow of bits to business processes that impact the bottom line: increasing revenue, reducing costs, and minimizing risks.

My industry colleague Ryan Peterson and I have had frequent discussions on this topic, and our recent dialogue on a LinkedIn post had me thinking about how best to reduce the friction that prevents data from being quickly valued and converted to business results.

Orchestration friction. The management and movement of data require intelligent software that places data in the right place at the right (most valuable) time.

Application friction. Software development and deployment need to happen as fast as possible to extract new business opportunities from ever-expanding data stores.

Business process friction. Many companies have not yet created new business processes that focus on data valuation.

While the first three categories require innovation in the IT (technology) domain, the fourth category requires creative thinking in the area of people and processes.

Ryan mentioned (in his comment) that there's currently a lot of friction:

Legal

Consumer consent

Identity

Risk management

Sovereignty

Etc.

When it comes to the topic of removing friction from data valuation, it can be helpful to highlight someone who is doing it well. Tom Davenport and Randy Beanpublished an article recently describing a company (ADP) that has addressed aspects of friction (anonymization and aggregation). ADP has created a revenue-increasing DataCloud by transforming their data into paid services. Before they could do that, however, they had to transform the data (remove friction) in a way that enabled revenue:

Unfortunately, all that data requires substantial massaging before it can be made available across ADP clients. It needs to be anonymized, of course, so that individual clients or employees can’t be identified. A more challenging data transformation is to aggregate data across different job titles for the same job.

This type of success in extracting value from data is just one of many; I'm hoping to spend more time writing on this topic in the weeks to come. I'm looking for examples in which the four areas of friction are countered with specific forms of innovation:

February 21, 2018

As part of Dell EMC's collaboration with the MIT Media Lab, we had a visit from Alin Dragos last week. Alin works on the Lightning Network at MIT's Digital Currency Initiative (DCI). He shared an interesting graphic with us, and with his permission, I have displayed the slide (and his commentary) below. The slide draws from an article by DCI founder (and current Media Lab Director) Joi Ito.

"We believe that what’s happening in the blockchain space now, is similar to what happened when the Internet was built. We observed four major steps – first the Ethernet, which allowed for a way to move information between two computers. It was housed at PARC (Palo Alto Research Institute), with the IETF consortium encouraging collaboration. This also brought us a few years later a dominant player in its field – 3Com. Then, we had TCP/IP, which has its roots at DARPA, and saw a key ally in ICANN. Cisco came to capitalize on the opportunity brought by this technological advancement. Then, we saw another layer develop in HTTP/HTML – started at CERN, and having its own critical consortium – W3C. And that is how we got Amazon. Finally, we saw SSL 3.0, which happened at Netscape, and it brought us Paypal. And that took more than 25 years." - Alin Dragos (MIT Digital Currency Initiative).

It's a fascinating hypothesis to think that Bitcoin will become a new, open layer that enables a frictionless and direct transfer of value on the internet. In other words, if Ethernet first allowed a way to move information directly between two computers, Bitcoin may enable a way to transfer value directly between two computers.

Whether or not this vision will become a reality is an excellent debate topic!

It's entirely possible that some form of "open blockchain" (one that can carry some other type of value) could emerge as an open standard.

This architecture is attractive because it removes friction and delay from financial transactions.

After my talk to legislators last week at the Texas State Capitol, it occurred to me that some states are already preparing for the eventuality of this type of architecture. One such state is Arizona.

It would appear that Arizona is betting that removing the friction from value transfer (e.g., transferring value directly to a vendor instead of going through an intermediary) will bring economic benefits to small businesses. This would explain the increased attention that Bitcoins and ICOs are getting in the state. The sponsor of the bill can be seen discussing the anticipated benefits here.

The advancement of blockchain legislation (and solutions) will be an exciting space to watch in 2018.

February 12, 2018

This week I was invited by Technet to speak about Blockchain at the Texas State Capitol. It was a different type of talk for me. Instead of focusing on the technical aspects of Blockchain I was asked to discuss what Dell sees from a regulatory perspective. The audience was made up of legislators and staffers.

It ended up being a great experience. Here are some of the key messages that I emphasized.

Don't think Blockchain; think Trusted Data Exchange. Cryptocurrency tokens are only one form of data that can be shared within a trusted data exchange.

I did a brief overview of Blockchain technology and focused on five common Blockchain characteristics. All of them are not strictly necessary to exchange data in a trusted fashion.

Cryptography

Peer-to-peer networking

Consensus

Ledger

Validity

State legislative activity is shifting from the topic of cryptocurrency to the operation of a blockchain-like data exchange.

The State of Illinois passed a bill launching a blockchain task force in the summer of 2017. Last month the task force published their results. We considered one of the critical statements from their report:

At a high level, blockchain and distributed ledger-enabled technologies enable government efficiencies in three ways:

Integrating government services with distributed identity

Efficiently and effectively managing the flow of digitized assets

Combining blockchain with other emerging technologies to “reinvent public services.”

5. We discussed the flurry of state activity that has occurred in the first six weeks of 2018. The table at the end of this article highlights some of this action (including links that describe the activity).

Many of the questions from the audience revolved around understanding the very first blockchain (Bitcoin's blockchain) and then trying to understand its limitations in the face of different state and local use cases.

The room was full, and the conversation was buzzing! See below for a picture of the session.

October 17, 2017

Technologists across Dell have been discussing a variety of Blockchain use cases with our customers. These conversations inevitably lead to whiteboard sketches integrating potential blockchain deployments with existing IT architectures. We use the chart below to drive this brainstorming exercise.

The "Elements of Blockchain" are essentially a framework for asking a set of questions about how a blockchain would be implemented and co-exist with currently-running business applications. Common questions that we try and answer during this process are highlighted below.

New business logic. What new business logic is being written, and for what purpose? Will modern application development processes be used to develop the new logic? How will this code be deployed when compared against existing application deployment frameworks? Will your business logic be portable across blockchains?

Smart Contracts. How are smart contracts deployed compared to existing application deployment? Are these contracts secure (e.g. encrypted)? Are they well-written? How easy are they to consume? Do they lock-in application developers to a certain platform? Are metrics collected to measure usage? Are access attempts logged securely?

Cryptography: Given the liberal use of cryptography within blockchains, which libraries will be used within the underlying ledger? How are these libraries maintained and used across ledgers? What role does cryptography play in different consensus algorithms?

Identity / Key Management: The use of private and public keys in a blockchain is foundational. How are these keys managed in comparison to other corporate key management systems? How do corporate identities translate to shared identities with other nodes on a blockchain network?

Network Programmability: How will the network between blockchain nodes be instantiated, tuned, and controlled? How will application SLAs for latency be translated into adequately-performing network operations? Will blockchain transactions be distributed as cleartext or encrypted?

Consensus Algorithms: How will decisions be made to accept/reject transactions? What is the "speed to finality" of these decisions? What are the scalability limits of the consensus algorithm? How much fault tolerance is built into the consensus? How much does performance suffer when fault tolerance limits are reached?

Off-chain Storage: What kind of data assets are recorded within the ledger? Are they consistently referenced? How are access permissions consistently enforced between the ledger and off-chain assets? Do all consensus nodes have the ability to verify all off-chain data assets?

Data Protection: How is data consistency enforced within the ledger? Do corrupted transactions throw an exception? How are corrupted transactions repaired? Does every consensus node always store every single transaction locally? Can deduplication or compression occur? Can snapshot copies of the ledger be created for analysis purposes?

Integration with Legacy: Does the ledger and consensus engine exist on the same converged platform as other business logic? Will there be integration connectors that copy and/or transform the ledger for other purposes? Is the ledger accessible to corporate analytic workspaces?

Multi-chain: how will the ledger interact with the reality of a multi-chain world (e.g. Quorum, Hyperledger, Ethereum, etc). How will the ledger interact with non-chain ledgers (e.g. Corda)? Will there be a common API to access different blockchains?

September 11, 2017

In August I monitored two more locations in the Sandwich Range: Camp Rich and Square Ledge.

Camp Rich is near the peak of Mt Passaconaway. In addition to monitoring how many people passed through the area, the USFS asked me to monitor solitude by recording (a) how many tent sites were within hearing/seeing distance of each other, and (b) how many people I encountered on the trail. In both cases, the answer was: zero. The picture above was taken while I was hiking out, and on the left, you can see Mt Paugus and Mt Chororua extending to the east.

The next day I re-entered the Sandwich Wilderness and hiked to Square Ledge, which is a known nesting site for peregrine falcons. Imagine my surprise when I arrived at the monitoring location and a tree was on fire! There were no flames but somebody had dumped their campfire ring (rocks, ashes, and all) underneath the root system of the tree and the underside of the tree was smoldering. Fortunately, I had a cell phone signal and hopped on the phone with the Fire Service for USFS. I was able to text some photos and leave a note for anybody else who happened to walk by. A rainstorm was moving in, so the USFS decided to come out and inspect the site after the rains came. The picture below highlights the situation.

After an adventurous two days of monitoring, I spent the following weekend doing a hike to Greenleaf Hut at the base of Mt Lafayette. The pictures below show what a beautiful location it is (which was partly covered over by clouds on our hike out!).

I was fortunate to use up all of my Dell volunteer hours hiking and can't wait to do it again in 2018.

August 07, 2017

Several days each year I use my Dell volunteer days to monitor wilderness trails in the White Mountain National Forest of New Hampshire. In recent years I've written about this volunteer opportunity.

On July 26 I monitored Stairs Mountain, which is located in the Presidential-Dry River Wilderness (just south of Mount Washington, New Hampshire's tallest mountain).

There are six wilderness areas in the White Mountains and each part of a wilderness area is classified into Zones A-D, with Zone A being the most remote (500 or more feet from any trail) and Zone D described as areas within 1/4 mile of developed facilities or within 500 feet of high-use trails. A good definition of the zones can be found here. The zone designations for the Presidential-Dry River Wilderness are highlighted below, and I placed a blue "X" on the location of Stairs Mountain within that wilderness.

The task is simple: count how many people show up at the monitoring location between the hours of 11AM-3PM. During my monitoring experience, I counted four people, and I reported this data to the local USFS office, which in turn will report it to the national office.

One of my visitors was an actual USFS forest ranger who mentioned that when a volunteer offers to perform Wilderness Monitoring the forest rangers are free to manage other areas of the forest (as opposed to staying in the same location for four hours).

Stairs Mountain is a beautiful spot! I decided to hike up the night before my monitoring duties began. I've embedded some of the better photos of my trip below. The following week I monitored two different locations and I hope to write those up soon.

June 21, 2017

This approach focuses first on the business logic that interacts with the ledger and not the ledger itself. The business logic simply desires an API to insert new transactions into the ledger and read old transactions from the ledger. The business logic may make some assumptions about ledger characteristics (e.g. immutability, structure, digital signatures, etc) but it typically desires no knowledge of HOW the underlying ledger is operating.

This integration can be thought of as the "top half" of an application framework (e.g. Cloud Foundry) connecting with new ledger applications via an API.

In this post I'd like to consider the "bottom half". How can an application framework automatically program the ledger for the needs of the application?

While the application itself may not care about underlying ledger details, the infrastructure team most certainly will care that the ledger is implemented in a way that meets a variety of enterprise requirements.

In other words, the next generation of enterprise ledgers will require devops programmability for specific application use cases. Distributed ledgers must present software APIs that allow for on-the-fly adjustments to scale, capacity, horsepower, and a number of other capabilities.

I believe the first step towards automatically programming ledgers is to enumerate required capabilities. Here are some of the items worth considering.

Consensus algorithms. My colleagues at VMware research have been conducting quite a bit of research into scalable, resilient consensus algorithms. They have pointed out that some consensus algorithms (e.g. Paxos) perform well up to a certain node limit (e.g. 5-7 nodes). Beyond this limit, a different, industrial-grade Byzantine approach must be employed (see VMware research paper). Should there be a ledger API for selecting from a menu of consensus options? Consensus algorithms are closely related to scale.

Push-button scalability. Sudden surges or spikes of transaction insertions into a ledger may require immediate scaling in terms of how many ledger entry points exist within a system. This can be accomplished in a variety of ways, including (a) peer-to-peer discovery of new nodes, or (b) controlled communication of new nodes to existing peers. Either of these options (or more) could be invoked via API.

Network Programmability. A ledger may be limited to one geography or it may span the globe. A ledger may exist entirely on a corporate backbone or it may participate in a torrent-like public network. There may be a strong desire for network encryption or there may be a mandate for open, cleartext transfer. Ideally, all of these permutations could be configured and controlled via API.

Service Levels. Public ledgers like Bitcoin can get away with "eventual validation", but enterprise ledgers will mandate a variety of service level agreements in areas such as performance, reliability, and availability. These SLAs must be programmed into the ledger implementation (integration with the network programmability mentioned above will be critical).

Smart Contracts. The execution of smart contracts will require strong distributed computing support from the underlying infrastructure. In the same way that flexibility in distributed consensus algorithms is needed, so it is with the execution of distributed smart contracts.

I believe the industry will evolve towards SDDLs (software-defined distributed ledgers) as a result of prototyping activity. These prototypes will stand up a variety of ledger implementations (Ethereum, Corda, Hyperledger, Multichain, etc) and begin to wrap automation around them. The automation will then need to converge to standard APIs that work against disparate ledgers.

Note that there are multiple companies applying themselves to this problem. One of them is Monax/Eris. Another is BlockCypher.

In future posts I will track the evolution of SDDLs and monitor their integration with frameworks such as Cloud Foundry.

June 14, 2017

Recently I posted about the growing need for corporations to integrate with distributed ledgers. I view this phenomenon in a top-down way; consider ledger integration from the application first and then use these considerations to drive ledger support in the infrastructure.

I'm happy to report that there are. Consider two of the talks that are being held this week.

Deployment of new ledger logic should ultimately be portable and easy. My colleague Gary White has spent a lot of time this year considering how Cloud Foundry can facilitate the integration of new applications with distributed ledgers (you can register for his talk here)

His talk focus on four areas, in which he will....

....introduce himself as a member of the Dell EMC Dojo and a blockchain enthusiast.

The talk should be a good mix of education and hands-on practice. One highlight will be an explanation by Gary of his personal experience integrating Ethereum into Cloud Foundry (the slide below will be discussed during the talk).

If you can't make Gary's CF Summit talk this year please connect with him on Twitter at @garypwhitejr.

May 30, 2017

Recently a colleague and I shared a Dell Technologies' Blockchain point of view to a group of financial services companies. One of the key pieces of feedback we received was the concerning lack of standards when it comes to building a distributed ledger.

Should we use Ethereum? Hyperledger? Corda? Chain? Multi-chain? What are the performance implications of each? How will we interact with different chains? How are smart contracts deployed? How do applications call these smart contracts? Do we consume Blockchain-as-a-service? Should we build our own?

The permutations are numerous.

One of Dell's partners in this area is the MIT Digital Currency Initiative. I recently had an engaging conversation with Director Neha Narula, during which she stated that the answer is a truly interoperable platform that is not controlled or pushed by one company. She believes that the current state of Blockchain is equivalent to the pre-web 1980s internet. We need Blockchain protocols to emerge that are the equivalent of HTTP and TCP/IP.

These views seem diametrically opposed. Should companies dive into first-mover Blockchain implementations or should they wait until the standards evolve?

My opinion at this point is to ask a different question: what business advantage are you seeking by interacting with a shared ledger? When we ask this question we see three different responses:

We believe interaction with a shared ledger can increase our revenues.

We believe interaction with a shared ledger can cut our costs.

We believe interaction with a shared ledger can reduce our risks.

For example, one company we spoke with mentioned that when they accepted Bitcoin payments they saw a bump in revenue (item #1) along with an increase in new customers. They had modified their ordering platform to interact with the Bitcoin Blockchain and this resulted in business advantages.

When considering the introduction of "shared ledger business logic", I believe the best starting point is highlighted by the diagram below.

The first step is not to figure out which ledger to use, or whether to build it on-site.

The first step is to figure out how to write and deploy the business logic in a way that (a) most quickly realizes the business advantage (e.g. revenues, cost, risk), while (b) future-proofing the code against potential ledger changes.

Once a coding and deployment approach has been decided, a logical next step would be to consider how to best program the ledger to the needs of the business logic.

During the next few posts I'll dive deeper into this top-down approach. What we'll find is that the specifics of the business logic will dictate whether or not to be aggressive in the use of Blockchain technologies or to be patient and leverage existing (non-Blockchain) approaches. If the Blockchain approach seems most prudent then there are an interesting set of questions worth answering about the business logic:

Are there emerging technologies and standards that normalize Blockchain implementations? [there are]

What is the interplay between the business logic and smart contracts? Are they both deployed as part of the same framework? [they should be]

Are there emerging technologies and standards that facilitate interaction between multiple Blockchains, and how can the business logic access this functionality?

How is identity management (e.g. the use of private keys) leveraged by the business logic?

How does the business logic handle references to off-chain data assets? [which are typically not stored on the ledger itself]

All of these questions must be considered as part of the application design. Even if the business chooses to go all-in with one Blockchain platform (e.g. Ethereum), all of the questions above should be considered.

More importantly, no matter what choice is made, the business logic should be delivered using cloud-native principles (e.g. test-driven development and continuous delivery). In an upcoming post I will touch on many of these points and also discuss a layered architecture for shared ledger business logic.

Employer

Disclaimer

The opinions expressed here are my personal opinions. Content published here is not read or approved in advance by DELL Technologies and does not necessarily reflect the views and opinions of DELL Technologies nor does it constitute any official communication of DELL Technologies.