A Decentralized Context Broker Using Byzantine Fault Tolerant Consensus

A context broker is a reliable message-relaying service used to connect devices by integrating all device protocols and communication methods, and reliably transporting messages while isolating data from other application service layers and networking complexities. A highly scalable decentralized context broker stack is composed of three layers—starting with a peer-to-peer network connecting a byzantine fault-tolerant (i.e., blockchain-based) consensus protocol—and it manages the communication using a web-socket streaming protocol as interface to other applications. This paper presents such a concept for a decentralized context broker stack for intercommunication between heterogeneous materials handling systems, and deploys the stack as proof-of-concept using ROS-based robots in a logistics scenario.


1A. Review Reviewer A:
This paper presents an architecture that decentralizes a 'context broker' to provide reliability in message relay systems. The proposed architecture uses several layers that together provide secure communication services (peer-to-peer networking + blockchain consensus + streaming service). The authors compare their new architecture to other currently used brokers; the main claim is that prior systems are not truly decentralized, and that this is what DezCom can offer. The idea is relevant to this community. ii Comments: Section 2.1 provides a list of requirements, but does not address which available architectures satisfy them, and which do not. Section 4 provides a prosaic description of the system, but no results that illustrate its utility.

Details:
Figures: the labels are much too small to read.

Reviewer B:
The paper presents a decentralized context broker using Byzantine Fault Tolerant Consensus. Aims, and experimental design are included in the manuscript. However, results for the proposed approach are not present in the current manuscript. Therefore, even though this paper is relevant for this symposium it needs significant changes to reach publication quality. In the following lines, I will describe the proposed changes in order of appearance in the text:

-Introduction
This reviewer wonders how the proposed work is different from the current algorithms for byzantine fault tolerant consensus, especially, W-MSR, and the swarm blockchain approach described in Strobel et. al (Managing Byzantine Robots via Blockchain Technology in a Swarm Robotics Collective Decision Making Scenario).

-Figures
In order to increase the readability of the paper, you need to increase the size of the figures and make the inner text more visible. Fig. 2,3,5 are extremely hard to read.
-Page 4, first paragraph Node connection and consensus process should be displayed chronologically in a figure.
-Page 4, Implementation of DezCom Adding a results and discussion (with performance metrics) section to the paper would be appreciated.

-Conclusion
Please change "decentral" to "decentralized" throughout the paper. This paper presents an architecture that decentralizes a 'context broker' to provide reliability in message relay systems. The proposed architecture uses several layers that together provide secure communication services (peer-to-peer networking + blockchain consensus + streaming service). The authors compare their new architecture to other currently used brokers; the main claim is that prior systems are not truly decentralized, and that this is what DezCom can offer.
The idea is relevant to this community.
The article itself is in a premature state (no results nor tests). It is therefore hard to identify what the contributions are.
 Added performance testing using robots in an industrial use-case and tested dezCom in industrial mobile robots.
Comments: Section 2.1 provides a list of requirements, but does not address which available architectures satisfy them, and which do not.
 Centralised architectures have those requirements but are not capable to work in a decentralized manner.  This is tested using dezCom in an industrial test platform.
Section 4 provides a prosaic description of the system, but no results that illustrate its utility.
 The whole section has been rewritten with results to show its utility.

Reviewer B:
The paper presents a decentralized context broker using Byzantine Fault Tolerant Consensus. Aims, and experimental design are included in the manuscript. However, results for the proposed approach are not present in the current manuscript. Therefore, even though this ISSN 2379-5980 (online) associated article DOI 10.5915/LEDGER.2019.173 iv paper is relevant for this symposium it needs significant changes to reach publication quality. In the following lines, I will describe the proposed changes in order of appearance in the text:

-Introduction
This reviewer wonders how the proposed work is different from the current algorithms for byzantine fault tolerant consensus, especially, W-MSR, and the swarm blockchain approach described in Strobel et. al (Managing Byzantine Robots via Blockchain Technology in a Swarm Robotics Collective Decision Making Scenario).
 The ambiguity is addressed, here the blockchain is used only for decentralized consensus without overhead of mining.  In a customized product manufacturing industry where robots play an important role in lean production planning as described by project SMARTFACE is used as use case definition where dezCom is used for messaging between the process machines in decentralized manner.

-Figures
In order to increase the readability of the paper, you need to increase the size of the figures and make the inner text more visible. Fig. 2,3,5 are extremely hard to read.
 Some figures are redone and some figures were removed.
-Page 4, first paragraph Node connection and consensus process should be displayed chronologically in a figure.
 Changed the stack figure to depict messaging and consensus is show in another picture to enforce that dezCom is independent of decentralized consensus used.
-Page 4, Implementation of DezCom Adding a results and discussion (with performance metrics) section to the paper would be appreciated.