Information Playground

Retirement

One of my co-workers at EMC always wanted to be an EMC Fellow. He said,

"When you're a Fellow, they put you in a corner and leave you alone so you can come up with the next big thing."

I became an EMC Fellow in 2012 and worked in that corner right up until my retirement.

I practiced three primary activities while striving to find the next big thing (e.g., Data Confidence Fabrics).

1. I limited myself to forty hours per week.
2. I avoided visibility.
3. I practiced hyper-productivity.

What will I do in retirement? Well, there are three main things I disliked about my job: sitting, staring at screens, and isolation. So my general retirement framework is to avoid those three things! For example, I'm planning on spending more time hiking and backpacking (see pictures below).

If you have ever been:

• a customer that used any of the products I worked on, or,
• an industry partner that I collaborated with, or,
• a colleague that worked with me,

... I would love to have a memory of our connection. Please consider leaving a comment.

Thanks for a great career,

Steve

Trolltunga, Norway. Sep 2022. Photo credit Matthew Todd

How I feel about retirement. Photo credit Matthew Todd

 

Data Confidence Scores for Carbon Emission Statements

Three years ago the idea of a data confidence fabric (DCF) was first proposed. A white paper described the overall concept.

"A Data Confidence Fabric delivers trusted data to applications with measurable confidence."

During the first year, Dell internally built the first data confidence fabric. The idea was then prototyped publicly and advanced with several partners (IOTA, Intel). The results were then discussed at a webinar.

Two years later, in October of 2022, the LINUX Foundation announced the donation of the internal code to the LF Edge community as part of Project Alvarium.

Once the code was donated, the Project Alvarium community (specifically Dell, IOTA, Zededa, and Climate Check) came together and defined the first-ever hardware instantiation of a DCF.

The project monitored sensor data at a biodigester in Molina Chile. This biodigester processed organic feedstock, and methane reduction sensor data traveled over a DCF to the Dell server, which was running the Alvarium SDK. 

As a result, and for the first time ever, a business insight (carbon emissions reduction amount) was accompanied by a data confidence score (how trustworthy is the insight?).

For more detail on this solution, please review the following:

• The proposal was detailed in a joint presentation by IOTA and Climate Check.
• The overall solution was presented and described at Dell Technologies World in May.
• Dell published two articles about DCF and sustainability on the edge, as well as how DCF fights untrustworthy data on the edge.
• Dell created an introductory video for the project as well as a longer discussion with IOTA's Mat Yarger.
• An August 2022 summary of the project was presented at the LATAM Open Source summit.

The Project Alvarium community is currently meeting every other Monday at 11AM Eastern Time to process the outcomes from this PoC and plan the next steps.

Steve

Dell Technologies Fellow

http://stevetodd.typepad.com

 

Audit Trails of Analytic Operations

Several years ago, in Dell's partnership with the Blocklab project at UC San Diego, we hypothesized that a distributed ledger can be a useful way to track analytic operations in a federated environment.

We subsequently designed a test system that could record federated learning and analytics operations in a distributed environment, and set out to build an example of this test system at UCSD.

The results of our experiment were recently published in Frontiers for Blockchain.

Our system created an API using the Boomi product. The choice of an API abstracted away the distributed ledger implementation choice. For our experiment, the Boomi layer interacted with VMware's blockchain. See the figure below.

The team followed a six step process while building the test system:

With this approach the team has created a tamper-proof ledger that can track the completion of analytic tasks across a federated ecosystem.

The paper goes on to conclude that "FL/FA blockchain will continue to gain traction in a range of industry use cases and in interdisciplinary academic research (Li et al., 2021; Salim et al., 2021; Unal et al., 2021)."

Steve

Dell Technologies Fellow

http://stevetodd.typepad.com

 

Data Confidence Updates at DTW

I traveled to Dell Technologies World in Las Vegas this week. It was my first business trip in years.

The purpose of my trip was to share a current update on Dell's advancement of their latest innovation: the Data Confidence Fabric (or DCF). The title of my talk was "Real-time Carbon Footprint Tracking through a Data Confidence Fabric."

Think of a DCF as a type of "trust overlay" for an edge fabric. A DCF doesn't stop edge data from flowing across a fabric; it simply annotates when and how trustworthy handling of that data occurs. This annotation results in an overall confidence score.

The idea of a Data Confidence Fabric surfaced nearly three years ago (I wrote about it here). Looking back now, one quote stands out from the article.

"We're entering the age of data valuation."

The article assumed that IoT sensor data would eventually travel to data marketplaces, and that a DCF would enable a higher price by adding "measurable trust" regarding the data's lineage.

At Dell Technologies World, we indeed described how environmental sensor data can be monetized by creating "trustworthy" statements about carbon emission savings. Trustworthy emissions statements can result in revenue generation in the form of carbon credit payments.

So indeed we are already seeing DCF technology being evaluated in support of monetization use cases.

The DCF technology was open-sourced by Dell to the Project Alvarium (LFEdge) community six months ago. The real-time carbon footprint tracking project is the first collaboration among Alvarium members.

For more detail about this collaboration, see the video below.

 

DT_ProjectAlvarium_25Apr2022.mp4 from Dean Dollery on Vimeo.

Steve

Dell Technologies Fellow

http://stevetodd.typepad.com

 

 

Chief Trust Officers and Data Confidence Fabrics

There are several quotes from Gil Press' Top 10 Tech Predictions For 2020 From IDC article that I like. The first one is about edge build-out.

Edge Build-Out: By 2023, over 50% of new enterprise IT infrastructure deployed will be at the edge rather than corporate datacenters, up from less than 10% today; by 2024, the number of apps at the edge will increase 800%.

The reason that I like this quote is the same reason I shifted my career from the enterprise to the edge: running apps against decentralized edge data is a tricky engineering problem. It's risky to trust that kind of data. I've thought about a solution to this problem (which I will discuss below).

Which brings me to the second quote that I like:

Trust Is Promoted: By 2023, 50% of the G2000 will name a Chief Trust Officer, who orchestrates trust across functions including security, finance, HR, risk, sales, production and legal.

The increase in the number of apps on the edge brings with it an increased worry in the trustworthiness of edge insights. It will be a requirement for someone (i.e., a Chief Trust Officer) to take ownership of data and application trust at the executive level.

By the time we reach 2023, I believe there will be a new tool in the Chief Trust Officer's toolbox: the Data Confidence Fabric (DCF).

The premise of a DCF is simple: as edge data and applications flow towards each other, trustworthiness will be measurable.

This idea borrows from enterprise storage systems. These systems performed enterprise trust insertion into data as it flowed towards enterprise applications. Applications were able to process the data with high confidence (often because trust insertion occurred as part of a bespoke, closed architecture). There was no need to measure the "confidence level" of the data. The origin, delivery speed, availability, protection, etc., were tightly controlled in a walled environment.

The hypothesis behind a data confidence fabric is that edge data can similarly benefit from trust insertion (read here for a list of potential trust insertion technologies in edge deployments).

Bespoke, closed architectures, however, cannot and will not work on the edge. No one vendor can insert trust across heterogeneous networks, firewalls, vendors, and geographies. This fact was the impetus behind the formation of a community that will collaborate on an industry-standard trust insertion and scoring framework. This framework will allow applications to access confidence scores and provenance metadata directly.

Dell technologists built the first data confidence fabric this past summer, and the code will serve as a seed to Project Alvarium.

The video below does an excellent job of painting a vision of the benefits of a DCF.

Speaking of confidence, I'm quite confident that Chief Trust Officers will insist that all of their data flow over this type of trust fabric in the decade to come. 

Because measurable trust will not only reduce risk (e.g., compliance violations) in the short term. It will also fetch a higher price in the long run.

Steve

Dell Technologies Fellow

http://stevetodd.typepad.com

Edge Data and Trust Insertion

In a previous post I looked at the history of trust insertion technologies for enterprise storage systems. I commented that these enterprise concepts can be applied to data flowing into an edge ecosystem.

In this post I'd like to propose an example stack that highlights trust insertion techniques being applied against incoming device data. The diagram below proposes an example stack and compares it against the enterprise model.

The right-hand side of the diagram above shows a "thing" that is periodically generating data. This data is "augmented" by trust insertion technologies as it flows towards applications.  Each technology is described below (starting from the bottom up):

• Hardware root of trust. if sensor data is ingested into a hardware entity with dedicated trust characteristics, the data can be viewed as "more trustworthy".  This type of hardware, for example, can enable the following:
  • The data is flowing into a device that has undergone a secure on-boarding process.
  • The data is flowing into a device that has completed a secure boot.
  • The data can be digitally signed, for example, by using a securely-stored private key. This provides a level of proof that the data passed through this trusted hardware layer.
  • Note that the "thing" itself may have its own hardware root of trust characteristics (e.g., it was manufactured with a private key that signs data at the time of creation)
• Trusted identity/ownership: Data with a clearly identified (i.e., cryptographically-provable) identity can help reduce compliance fines (e.g., the owners of the data are much more likely to comply with regulations regarding the data) and increase data profits (e.g., if they ever want to sell their data that have proof that they are the original owner). Identity may be built into hardware devices (e.g., TPM) or identity may be assigned to IoT ingest frameworks by using new forms of decentralized identity.
  • A securely-onboarded, secure-boot HW root of trust device can make a strong statement as to ownership of the data if it signs the data before pushing it to other parts of a corporation or to another edge ecosystem.
  • An edge device (e.g., a sensor) may have already signed the data before it arrives at a framework like EdgeX (see below).
  • A non-HW-root-of trust environment may have an owner configured into the system, and if this ownership has already been configured and the identity's private key is used to sign the data, the data may be considered more trustworthy.

• Open Ingest Software: the use of an “open” IoT data ingest platform (like EdgeX Foundry) can give a level of confidence to applications that process edge data. With a closed system it is less possible to know what functionality was present when the data was ingested. If a well-known, fully open release of ingestion software is being used, with a published version number, the data flowing through that software can be thought of as more trustworthy.

• Provenance Metadata: in addition to the use of Open Ingest software being present in the ingest environment, there may be other software or hardware elements present on the ingest device that give additional confidence to the data, (e.g., the version of LINUX) or software elements that guard against intrusion or threats (e.g., RSA’s Iris project).  The presence and versions of these software elements can be gathered and “attached” to sensor data as a permanent record that travels with the data (or is otherwise somehow permanently associated with the data). This provenance metadata is also important for monetization: it can tell where the data came from (e.g., geography, owner) and this metadata can once again be used to enforce compliance laws/regulations, or it can be used as proof-of-ownership when trying to monetize data.

• Authentication/Authorization support: If the ingest environment has strong authentication or authorization software capabilities, it is making a statement (to a potential application) that additional care was taken to verify that only certain people can (a) make changes to the ingest configuration, or (b) subscribe to receive data events from sensors.  If the control path of the ingest device only allows changes to be made by specific administrators (e.g., an EdgeX admin wants to add a new EdgeX microservice), the data can be viewed as more trustworthy. Similarly, the use of a secure on-boarding management stack, for example, can enhance confidence in edge data.

• Secure Transport: as data flows into an ingest ecosystem, and as it flows out of an ingest ecosystem, it may be possible to use encrypted, deterministic network flows to protect and deliver data. VMware Velocloud (SD-WAN) is an example of a technology that can be used for that purpose. If the network channels have a specific degree of security associated with them, this can improve application confidence in data. In addition to the secure transport of data, the protection of management commands (e.g., making configuration changes) may increase confidence. In addition if a secure WAN is used to protect data and deliver it on-time to a cloud environment, the data flowing over the connection may be viewed as more trustworthy.

• Scale-out, Immutable storage: an edge ingest ecosystem may store data locally on an open edge close to the actual devices. The choice of storage can play a big part in data trustworthiness, and many of the following storage attributes can influence this trust:

  • Is the storage system scalable to multiple decentralized parties (e.g., Bit Torrent-like accessibility and performance, which is the claim of the IPFS storage system)? This may improve confidence that the data can be delivered in a timely fashion to applications.
  • Does the storage system have immutability characteristics (e.g., a content-addressable system that assigns a hash value to stored objects)? This can give the application confidence that the data has not changed.
  • Does the storage system have non-delete capabilities or retention of data? If so, this may give the application confidence that the data will still be around if needed in the future (or deleted after a pre-determined amount of time).
• Ledgers: the rise of performant, scalable ledgers (e.g., Ethereum, Hyperledger, Project Concord) provides an immutable, trusted way to register the creation of new data assets and associate rich metadata, provenance, and confidence characteristics. Ledgers can provide the ability to manage edge data as an asset (keeping a “ledger for data” in a similar fashion as creating a ledger for financial assets). In addition, when ledgers are applied in a cryptocurrency environment, they provide the potential to exchange data assets for value (e.g., the rise in activity in the area of data brokers and data marketplaces).  The use of a ledger, therefore, will result in an increase in application confidence:
  • If a ledger is used to register the creation of assets, confidence increases.
  • If a ledger is used to record the fact that policies (see below) are being applied to those assets, confidence increases because now there is an audit trail that can be referenced in the case of an audit, proving compliance and reducing the risk of significant fines.
  • Ledgers can also be used to establish data ownership (a private key is used to sign the ledger entry). If data itself can’t be signed, ledgers can be used to prove ownership.

These trust insertion technologies are exemplary; there are other techniques that can be used (e.g., determining if sensor readings themselves can be trusted through historical comparisons). The ledger section also refers to the application of policies at the point of ingest: this is another great way to insert trust.

These trust insertion technologies can work together to provide trust to applications. How can they be stitched together in an open way?  I will explore this question in a future post.

Steve

http://stevetodd.typepad.com

Dell Technologies Fellow

Enterprise Trust Insertion and IoT

The industry is distributing corporate applications towards decentralized data. The figure below does a good job in framing the challenge of "delivering trusted data" in decentralized ecosystems (e.g., IoT sensor data).

As applications (top right) and IoT sensor data (bottom left) are being brought together across disparate and heterogeneous components, trust is owned by nobody. This brings great risk to the companies that deploy the applications. Applications are designed to positively impact balance sheets, but accessing decentralized IoT data can result in negative economic impact:

• These applications are often meant to save money by improving operational efficiencies. If the data is incorrect, wrong, or malicious, the applications can actually increase expenses (e.g., by making incorrect predictions).
• Improperly labeled IoT data can be accessed by applications that have no business looking at that data. The violation of corporate or federal compliance laws can lead to large corporate fines.
• The rise in data marketplaces has the potential to bring new sources of revenue to many companies. If the data, however, is of poor or questionable quality, or if ownership is not clearly established, the potential payment price for that data will decline (or the data will not eligible for sale).

What can we learn from the successes of the enterprise approach to "delivering trusted data"? Can these lessons be applied in an IoT context?

Certainly within the walls of a corporate data center we see a high degree of trust being delivered between enterprise-class storage systems and corporate applications.

One reason for the synergy between enterprise data and applications is trust insertion. Consider the evolution of storage area networking, and how multiple "trust insertion techniques" were applied throughout the data delivery process, starting at the surface of the disk (520-byte sectors) all the way up to data validation at an application (validating hashes through content addressing). These trust insertion techniques allowed applications to deliver great business value without having to worry about the correctness, timeliness, or availability of the data.

This diagram highlights one dozen trust insertion techniques that facilitated the delivery of trusted data.These trust insertion techniques provided benefits like data integrity and correctness, availability, privacy, and deterministic delivery. Nearly all of these capabilities were "proprietary" or "closed". But data center operators didn't mind; they paid handsomely for proprietary trust insertion solutions to the tune of 100s of billions of dollars over many decades.

So what hypothesis can we bring forward to the IoT use case?  Let's assume that the industry would accept (and value) trust insertion techniques that bring applications together with decentralized IoT data. Let's also assume that any "trust insertion" latency delays could be minimized with performance optimizations.

Can we build such a stack?

The answer is yes, but with one caveat: there is no way that one proprietary solution can own all of the trust; instead we need to weave together as many open "trust insertion" technologies as possible to help bridge the gap across the heterogeneity of an IoT ecosystem.

In future posts we will discuss how to build such a stack.

Steve

http://stevetodd.typepad.com

Dell Technologies Fellow

IoT Data Confidence Fabrics

As we enter the age of data valuation we're starting to witness the rise of data marketplaces.

One of the concepts I've been experimenting with is the routing of IoT data from a sensor to a data marketplace. The diagram below highlights the general idea. How does one route IoT data and eventually advertise it for sale in one of the many emerging data marketplaces?

There are two hypotheses I've been working on in relation to the figure above:

1. IoT data with a higher degree of (measurable) trust will sell for a higher price
2. Data profits will decrease when IoT data is immediately moved to a public cloud

What is meant by measurable trust?  It means that if a potential buyer can look at the provenance of a data set for sale, they can inspect the level of care that the data received as it was moved from sensor to market.  This is called a data confidence fabric (DCF). A DCF description, and a set of measurable provenance attributes, is depicted below.

I've written before about decreasing data profits due to egress fees.  Moving IoT data to the cloud costs very little, but moving it every time it sells results in continual taxation.

When you combine the two hypotheses above you end up with an architectural statement that in theory should bring the highest level of profit during the sale of IoT data:

"Build a data confidence fabric, using open-source technologies, that initially stores the data close to the sensors".

This architecture, most certainly, can be built. There are two main problems to be solved.

1. What are the stages of IoT data creation, local storage, and eventual movement to multiple marketplaces?  To solve this problem we need to turn to VMware. This is a multi-cloud problem (VMware's bread and butter).
2. What are the set of open technologies we can use to store data close to the sensors and prepare it for sale?

After considering these two questions exhaustively, we've come up with a white paper that answers these two questions with a significant degree of depth. The paper, called Getting Started with IoT Data Monetization, starts with sensor ingestion and ends with the technology that nearly all data marketplaces expect: blockchain.  The diagram below expresses the general idea.

We've started to build this framework as a way to test the hypothesis. Open technologies provide a cost efficient way to capture and manage IoT data close to the sensors, and VMware's six-sevens process pattern considers all the complexities that will arise when moving data across heterogeneous environments.

The benefits of initially storing data close to the sensors extend beyond data monetization. A scalable and robust local IoT storage layer can bring latency benefits and compliance/governance benefits as well. Therefore this architecture can not only make money (data sale), but it can save money (e.g., latency speed improves operational efficiencies) and avoid fines (e.g., when data movement would violate local/federal policies).

We're looking for opportunities to share this approach with like-minded companies and individuals; feel free to contact me on Twitter or LinkedIn (see the menu bar above) for more information.

Steve

Dell Technologies Fellow

http://stevetodd.typepad.com

Dell Boomi for Blockchain Data Anchoring

There are many integration aspects to consider when deploying new blockchain applications onto an existing IT architecture. Many of them are listed here.

One of the more intriguing challenges is the integration of existing data assets with a blockchain. Many people consider blockchain a trusted platform for value exchange (e.g., cryptocurrencies).  I like to think of it as a trusted data exchange (with cryptocurrency as one form of data). It becomes critical therefore to have a platform for integrating existing and new data assets into an enterprise blockchain environment.

One new term used to describe the registration of assets onto a blockchain is "data anchoring." Chainpoint.org is "an open standard for creating a timestamp proof of data." They describe anchoring as follows:

Anchor an unlimited amount of data to multiple blockchains. Verify the integrity and existence of data without relying on a trusted third party.

A sensible approach to enable anchoring is the use of Dell Boomi. Recently a team of Dell technologists published a demo that highlights Boomi's blockchain capabilities.

In this post, I'd like to outline the implementation of the demo and the features that make Dell Boomi a leader for blockchain use cases.

Tierion is a new company that has begun to publish APIs for blockchain data anchoring. For example, their API can accept a new hash value (uniquely representing a data asset) and provide a receipt of that asset (proof of data anchoring). The APIs for registration and receipts are listed on Tierion's website and depicted below.

Boomi excels at consuming such APIs to bring different ecosystems (e.g., existing data assets and a blockchain) together.  The demo highlights the integration of Tierion's API by taking data assets from Box and registering these assets onto a blockchain. The diagram below highlights the sequence of events.

There are two aspects of the Boomi implementation that are worth calling out:

1. The Boomi Atom Cloud depicted above implements the Boomi AtomSphere integration platform as a service (iPaaS). This platform allows integration between cloud platforms, software-as-a-service applications, and on-premise systems. In other words, no matter where your data lives, Boomi Atomsphere provides a simple, cloud-based API for data management (without having to install any middleware).
2. Boomi Flow is used to create sophisticated and straightforward workflow-based applications that allow businesses to extend their data integration capabilities with other entities (e.g., online/offline mobile apps and web portals).

The demo described above results in a corporate catalog of receipts. Each receipt is a timestamped-registration of data assets onto a blockchain, and it enables a whole new set of data-based business processes, including data ownership, transfer, broadcast, lineage, etc.

Data anchoring with Boomi can be especially applicable to GDPR. I plan to write about relevant use cases in future posts.

The Boomi team is looking for additional use cases to solve. If you have questions about their work, contact them at [email protected].  For more detail, browse the Boomi website at www.boomi.com.

Steve

http://stevetodd.typepad.com

Twitter: @SteveTodd

SBFT: VMware's Blockchain Consensus Algorithm

The VMware research team's SBFT algorithm achieved 50 I/Os per second when processing four months worth of Ethereum transactions (a 10x speedup).

This statement may not appear noteworthy in the context of how many I/Os per second VISA processes. It is, however, a significant advancement in the art of consensus algorithms, and a promising step in the right direction for enterprise-class blockchains.

I've spent the last few weeks blogging about the fact that new trusted storage features perform slowly at first and then improve over time. My thoughts included a look at the latest evolution of a trusted storage platform: blockchain.

One of the problems with blockchain performance is the speed of the underlying consensus algorithm. In a recent post, I highlighted common scaling problems for consensus algorithms. I ended the article by mentioning VMware's blockchain research team has recently made some breakthroughs with their Scalable Byzantine Fault Tolerant (SBFT) consensus algorithm.

Their latest publication is an example of the inevitable progress that the research community will make as they harden blockchain trust and performance. The publication is not just a white paper; it represents working code. It will only be a matter of time before VMware's work appears in product form.

I've studied the consensus advancements described in their paper. What are the improvements that SBFT brings to the table?  For me, several highlights stand out.

Running in a Permissioned Context 

One of VMware's strengths is their ability to create deterministic, enterprise-class network connections via technologies such as NSX.  Many enterprise customers would like to deploy blockchain applications in this type of permissioned environment (as opposed to a public environment like Bitcoin or public Ethereum). The beauty of VMware network configurations is that they allow network administrators to establish an upper bound on transmission delays.  If a request between nodes exceeds this upper-bound, then the network can assume that the node has either disappeared or has experienced a failure. 

VMware's researchers have been problem-solving in this type of deterministic environment. 

PBFT as Algorithmic Foundation

The consensus improvements realized by VMware's researchers have their foundation in a Partial Byzantine Fault Tolerance (PBFT) approach. PBFT is a leader-based algorithm with two phases. An all-to-all message exchange characterizes each stage. In a previous post I inserted a diagram from a USENIX paper and then highlighted all-to-all messaging exchanges.

These messaging exchanges, showed here for four nodes, become highly problematic as blockchain configurations scale to hundreds of nodes.  As the amount of messages scale quadratically, the system runs the risk of losing liveness (continual progress while processing new requests).  

Removing the problem of quadratic scale is not straightforward, and VMware researcher Dahlia Malkhi has shared her thoughts on how solving it is trickier than one might think.

The SBFT solution has three basic components.

1. Using the Right Amount of Batching

The messaging approach highlighted by PBFT above occurs for every consensus decision. Grouping minimizes messaging, but batching too many transactions together can introduce unacceptable delays (e.g., the first transaction in a group waits the longest). SBFT approaches batching in the following way:

"SBFT strikes a balance between throughput and latency with mild batching only, a few dozens of transactions, maintaining latency under 60 milliseconds."

2. Improving the Zyzzyva Approach

In addition to implementing batching, SBFT adopts the Zyzzyva approach to minimize consensus messaging in the standard case (i.e., all nodes are healthy). The method depicted below (from the USENIX article) makes it clear that all-to-all (quadratic) messaging does not occur with Zyzzyva.

The paper highlights the benefit of using the Zyzzyva approach: 

"Embracing this idea, SBFT is a PBFT variant that incorporates into the protocol an optimistically fast track with linear cost during synchronous, faultless periods.

SBFT leverages the idea of linear scale in the optimum (healthy) case, but it also addresses (and fixes) some of the flaws in Zyzzyva.

3. Single Confirmation to Clients 

The third improvement provided by SBFT is a significant reduction in the number of confirmations back to the client (i.e., the application that wishes to write a new transaction into a blockchain).  The diagram below highlights that a client receives multiple messages from multiple replicas for Zyzzyva, but only one with SBFT.

The minimization of client messages is made possible by using a technique known as threshold signatures. This approach combines messages from rotating collectors (the C-collector and E-collector displayed above) and combines all signatures into one. While this introduces additional computational complexity at the collector nodes, it also has the advantage of (a) a single client message (CPU-friendly for application developers), and (b) a single verification needed by replicas (network friendly for blockchain nodes).

The paper describes how it uses two different threshold signature techniques (BLS for < 70 nodes, and RSA >= 70). The paper states that the use of threshold signatures in this way is unique in the industry.

"no deployed BFT system we are aware of sends only a single confirmation to clients. Not only that, but repeated queries of the same value can return a single response as well."

What's Next for SBFT?

The results published by the VMware research team (and validated by working SBFT code) are being shared both externally with the industry and internally within VMware and Dell Technologies. 

Members of Dell Technologies' Blockchain Steering team will be presenting results from the paper and other Dell Blockchain points of view at several upcoming Dell Technologies World sessions.

Wednesday, May 2nd 8:30 AM: Thinking in Blockchain: How to Apply Blockchain Technology to Business Processes.

Wednesday, May 2nd 12:00 PM:  Blockchain Challenges and Dell Solutions.

Wednesday, May 2nd 1:30 PM: Advancements in Blockchain Development.

Many thanks to the VMware blockchain research team for educating me on SBFT!

Steve

http://stevetodd.typepad.com

Twitter: @SteveTodd