Information Playground

Blockchain Consensus: Trust and Speed at Scale

 

When a storage system provides new trust features, it is not uncommon for these features to perform quite poorly.

In a previous post, I looked back at the early-1990s introduction of RAID-5 as a new trust feature. Performing a write to a RAID-5 storage system required four disk operations. Heavy write workloads, therefore, experienced "slow trust."

The first RAID-5 system we ever worked on delivered 12 I/Os per second for all-write workloads (e.g., restore operations). After we avoided getting fired, we responded by releasing performance improvements: a fast mirrored write cache on top of RAID-5.

This evolution of implementing "ever-faster trust" continues with blockchain. As increasingly larger numbers of enterprise applications experiment with permissioned (private) blockchains, they experience the same "slow trust".

It is not uncommon for these applications to experience 5 I/Os per second for specific workloads. This slow behavior is unacceptable for enterprise-class applications, so the industry is now working on performance advancements that still maintain trust.

The BLOCKBENCH project at the Computing Department of the University of Singapore has created a blockchain performance testing framework. In their paper, BLOCKBENCH: A Framework for Analyzing Private Blockchains, the authors make the following statement:

“Multiple platforms for private blockchains are being actively developed and fine tuned. However, there is a clear lack of a systematic framework with which different systems can be analyzed and compared against each other.”

The researchers point to the underlying network (and the Practical Byzantine Fault Tolerant protocol, or PBFT) as a primary culprit for slow time-to-finality at scale.

“In fact, we also observe that as time passes, client requests took longer to return, suggesting that the servers were over saturated in processing network messages. We note, however, that the original PBFT protocol guarantees both liveness and safety, thus Hyperledger’s failure to scale beyond 16 servers is due to the implementation of the protocol. In fact, in the latest codebase (which was updated after we have finished our benchmark), the PBFT component was replaced by another implementation. We plan to evaluate this new version in the future work.”

The USENIX paper BFT Protocols Under Fire contains a diagram that highlights how excessive inter-node network messaging can cause significant performance problems. I've circled the number of messages that occur for a simple PBFT example where the number of nodes  (replicas) is n=4.

This inter-node messaging, in the context of the blockchain, occurs so that all nodes can come to a consensus on whether or not an application's new entry is valid.  

Performance suffers when the messaging approach depicted above executes with an increased node count (e.g., n = 100). Messaging delays for large configurations will scale quadratically.  "Quadratic scale" is another unacceptable symptom for the enterprise; there is an expectation that adding nodes will result in linear performance scaling.

PBFT consensus algorithms are one of the latest in a spectrum of algorithms considered for enterprise-class permissioned blockchains. The diagram below highlights this evolution.

What is the next step in this evolution?  Within Dell Technologies, the VMware blockchain research team contains some of the industry's most experienced researchers in the area of consensus algorithms:

VMware Research is actively participating in advancing the infrastructure underlying the Blockchain technology in order to provide the most secure, reliable, and scalable Blockchain platforms.

They've developed new algorithms that provide linear scaling as node counts increase. 

In an upcoming post, I will explore how their approach differs from PBFT and why their new algorithm (SBFT) will result in faster levels of trust.

Steve

http://stevetodd.typepad.com

Twitter: @SteveTodd

 

 

Blockchain as Storage: Evolution not Revolution

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.

As a proof point for this trend, one only needs to look at the research for an internet standard for value transfer at the Digital Currency Initiative at MIT Media Lab

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.

We're working on that ;>)

Steve

http://stevetodd.typepad.com

Twitter: @SteveTodd

 

Data Value Friction Removal

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.

There are four categories of friction worth considering:

1. Infrastructure friction. The simultaneous need for compute intensity and data intensity requires new architectures that facilitate fast processing of vast amounts of data.
2. Orchestration friction. The management and movement of data require intelligent software that places data in the right place at the right (most valuable) time.
3. Application friction. Software development and deployment need to happen as fast as possible to extract new business opportunities from ever-expanding data stores.
4. 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 Bean published 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:

• Infrastructure innovation: new IT paradigms
• Orchestration innovation:  new data management constructs
• Application innovation: the shift to agile
• Business process innovation: a data-centric business mindset

More to come in future posts,

Steve

http://stevetodd.typepad.com

Twitter: @SteveTodd

Transfer of Value as an Internet Protocol

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.

Arizona has taken the unique step of legislating against any restriction prohibiting the running of a blockchain within the state. 

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.

Steve

http://stevetodd.typepad.com

Twitter: @SteveTodd

Trusted Data Exchange at the State Capitol in Austin

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.

1. 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.
2. 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.
   1. Cryptography
   2. Peer-to-peer networking
   3. Consensus
   4. Ledger
   5. Validity
3. State legislative activity is shifting from the topic of cryptocurrency to the operation of a blockchain-like data exchange.
4. 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.

Steve

http://stevetodd.typepad.com

 

2018 Blockchain State Legislative Activity (up to February 12th)

Georgia	Resolution for funding C.S. blockchain education
Tennessee	Bill recognizing blockchain signatures as legal records
Maryland	Consumer protection act requires crypto and blockchain recommendations
Arizona	Bill prohibiting restricting blockchain nodes in private residences
Florida	Bill recognizing blockchain signatures as legal records
Wyoming	Bill exempting blockchain tokens from securities regulations
Vermont	Bill to implement strategies related to blockchain
Virginia	Resolution one-year study on blockchain technology.
Illinois	Final blockchain report to the General Assembly.
Colorado	Bill to adopt blockchain for data security

The Elements of Blockchain

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.

1. 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?
2. 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?
3. 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?
4. 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?
5. 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?
6. 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?
7. 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?
8. 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?
9. 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?
10. 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? 
11. Cloud automation: Can routine blockchain tasks be automated? Will cloud providers offer non-repudiation and/or blockchain governance?  Can blockchain app developers execute test/dev processes in one cloud provider environment and then push to a (different) cloud production environment?

While this exercise appears complex at a high-level, all of these questions are critical to answer in order to build towards a final system implementation.

In order to bring an element of simplicity to this discussion, two high-level services are required:

• A definition of a "core blockchain" stack.
• A management and orchestration approach that integrates the stack into existing systems and processes.

In future posts, we will drill down into these areas.

Steve

 

 

 

Sandwich Wilderness Monitoring

In late July I wrote about monitoring Stairs Mountain for the US Forest Service.

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.

Steve

 

Stairs Mountain Monitoring

 

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 maps depicting each zone can be found here.

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.

Steve

 

 

SDDL: Software Defined Distributed Ledgers

In a previous post, I discussed approaching the topic of Blockchain from a top-down point of view. 

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.

At last week's Cloud Foundry Summit we began to see a discussion on application integration with ledgers.

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.

Steve

http://stevetodd.typepad.com

Twitter: @SteveTodd

CF Summit: Blockchain and Cloud Foundry

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. 

If this is true, then we should be seeing ledger discussions this week at the Cloud Foundry Summit.

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.
• ....spend some time on ledger education by discussing Blockchain.
• ....discuss the value of integrating with a ledger.
• ....relate his experience creating a Cloud Foundry Blockchain service. 

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.

Steve

http://stevetodd.typepad.com

Twitter: @SteveTodd