ROS-Ethereum: A Convenient Tool to Bridge ROS and Blockchain (Ethereum)

Zhang, Shenhui; Tang, Ming; Li, Xiulai; Liu, Boyi; Zhang, Bo; Hu, Fei; Ni, Sirui; Cheng, Jieren

doi:https://doi.org/10.1155/2022/7206494

Security and Communication Networks

On this page

Abstract Introduction Related Works Implementation Conclusion Data Availability Conflicts of Interest Acknowledgments References Copyright Related Articles

Research Article | Open Access

Volume 2022 | Article ID 7206494 | https://doi.org/10.1155/2022/7206494

ROS-Ethereum: A Convenient Tool to Bridge ROS and Blockchain (Ethereum)

Shenhui Zhang,^1,2Ming Tang,^1,2Xiulai Li,^1,3,4Boyi Liu ,^2,5Bo Zhang,⁶Fei Hu,^2,7Sirui Ni,^2,8and Jieren Cheng^1,3

Academic Editor: Helena Rifà-Pous

Received23 Jan 2022

Accepted15 Mar 2022

Published18 Apr 2022

Abstract

Robot Operating System (ROS) has received widespread utilization with the development of robotics, self-driving, etc., recently. Meanwhile, the other technology blockchain is frequently applied to various fields with its trustworthy characteristics and immutability in data storage. However, ROS has no ability to interact with the blockchain, which hinders research in related fields. Therefore, we wonder if we can develop a convenient tool to bridge ROS and blockchain. Inspired by this, we propose ROS-Ethereum. It bridges ROS and Ethereum, a widely used blockchain platform. ROS-Ethereum is based on the User Datagram Protocol (UDP) communication mechanism and the SM algorithm family along with Ethereum technology. Simply put, ROS-Ethereum allows users to invoke the contract when interacting with the blockchain, which makes this process easier and safer. We conduct experiments in real robots to verify the effectiveness of ROS-Ethereum and evaluate it from the following metrics: (1) the encryption efficiency and stability of the algorithm and (2) ROS-Ethereum transaction response time and packet loss rate.

1. Introduction

Robot Operating System (ROS) is a type of operating system consisting of huge nodes running on computers to control the robot. It provides a standard approach to connecting to all the sensors in robots. The ROS nodes which are based on the information collected by these sensors to develop can communicate via the subscription and publication of topics or in a client/server (C/S) mode. This type of flexible structure permits ROS with extremely excellent flexibility and randomness and makes each of the nodes exchange their information at a high frequency.

Researchers in the ROS community now begin to consider the problems exposed in ROS and even other robotic systems constructed by other frames, such as how to improve the security of communication in the robotic operating system [1–3] and how to deal with the typical problem in the field of the cluster of robots: Byzantine fault tolerance [4]. With a certain size of the robot cluster, some nodes with bad efficiency inevitably appear in the process of task execution, even affecting the normal work of other nodes in the cluster. In addition, on account of the transparency of the ROS communication mechanism, the issues of credibility communication between the commercial robots also gain a wide range of attention. To address these problems exposed by ROS, researchers seem to simultaneously select blockchain as the solution to these problems, aiming at these problems exposed by ROS.

Blockchain technology originated from Bitcoin [5] proposed by Satoshi Nakamoto. Vitalik Buterin introduced the concept of smart contracts into blockchain later, proposing the second-generation blockchain named Ethereum [6]. The original intention of blockchain technology is intended to solve the problems of transaction trust crises in the financial sector. As the technology develops, the blockchain has gradually evolved into the storage structure of distributed encryption combined with a point-to-point distributed network [7–9], cryptographic algorithm [10–13], consensus algorithm [14–17], and other technologies. Its superior performance in information storage security and transaction trustworthiness arouses the researchers studying other fields to introduce the excellent characteristics of blockchain into their fields. To satisfy the demands of ROS researchers to interact with the blockchain, this paper proposes a novel interaction tool: ROS-Ethereum, based on the UDP communication technology, Ethereum, Web3, and SM algorithm family. It is the first tool that bridges ROS to Ethereum. And with the help of the SM algorithm family, ROS-Ethereum is born with excellent security in both attack resistance and data transmission.

ROS-Ethereum enables users to monitor the nodes that deliver key information and then preprocess the information (timestamp, format conversion, etc.) in the ROS execution. It hardly limits what type of key information and supports most types of messages interacting with the blockchain. The algorithmic encryption system based on the SM algorithm family can effectively guarantee the security of data transmission while the Ethereum control module interacts with Ethereum via Web3 interfaces to call smart contracts on the blockchain. The superiorities of ROS-Ethereum are shown as follows:(1)ROS-Ethereum provides convenient user interfaces, blocking the complicated implementation of blockchain and the details of the encryption algorithm. The users are just required to input the names of topics or nodes to be monitored to interact with Ethereum.(2)ROS-Ethereum has high safety performance. This interactive tool introduces a symmetric key plain text encryption mechanism, providing a shield for the information against the third party.

The main contributions of the paper are as follows:(1)Providing the ROS-based robot with a convenient, fast, and secure Ethereum interaction tool for the first time.(2)Playing an important role in promoting the combination of blockchain and ROS, and producing new applications.(3)Proposing a secure, efficient, and encrypted interaction scheme bridging ROS and blockchain represented by Ethereum.

The rest of this paper is organized as follows: Section 2 describes the related work, Section 3 formalizes our methodology and introduces our framework, and Section 4 analyzes the results of the experiment. The end is a summary.

In the present national and international study, with the increasing research on robot swarm communication and applications of blockchain technology, the latency of them was measured and analyzed. Besides, the authors have also identified parts of links between them. These studies provide some good examples for our research in this paper and allow us to optimize the top of the research we do. Most themes of these studies focus on blockchain-based communication within robot swarm, secure information sharing through the blockchain network, and behavior control and optimization of robot swarm via blockchain technology. Works with similarities are listed in Table 1.

2.1. Blockchain-Based Communication within Robot Swarm

Ming Li et al. described the possible ways of building wireless mesh networks to enable multiple robots within every cluster to form mobile self-organizing networks [18]. John Harris et al. proposed an approach working on a generic robot swarm communication network architecture through scalable algorithms for autonomous cluster deployment and ROBOTRAK (a socket-based cluster monitoring and control) [19]. Exchange and sharing of information data such as electronic medical records through blockchain networks were presented by Abichandani et al. [1]. Alexandre Pacheco et al. showed that robotic clusters used decentralized mobile self-organizing networks to achieve a high-throughput communication framework and use blockchain as a security layer to neutralize Byzantine robots [4].

2.2. Secure Information Sharing through Blockchain Network

To combat the COVID-19 pandemic, a conceptual, trustworthy framework, which can facilitate the sharing of information, goals, and representation, was proposed by Alsamhi et al. to increase intelligence, decentralization, and autonomous operations of connected multirobot collaboration in the blockchain network [20]. Meanwhile, in the case of mutual collaboration in edge-assisted multirobot systems, Jianan Li et al. adapt alike ideas and proposed a blockchain-based collaborative edge knowledge inference (BCEI) framework for edge-assisted multirobot systems [21]. The architecture of knowledge sharing of the Internet of Things (IoT) platform with the help of the Ethereum blockchain was presented by Xia Qi [22]. Ilya Afanasyev and others firstly presented the analysis and application of blockchain-based multi-intelligent body robotic systems [23].

2.3. Behavior Control and Optimization of Robot Swarm via Blockchain Technology

Siddarth Jain et al. proposed a real-time-based grid search and ad hoc networks for swarm robot optimization in grid navigation [24]. Distributed Bayesian hypothesis testing was used as a novel collective decision-making strategy to solve the collective perception problem in Qihao Shan et al. [25]. Aryo Jamshidpey et al. proposed a multirobot overlay approach, in which the robots self-organize a dynamic ad hoc communication network for planning and coordination control [26]. Trung T. Nguyen et al. utilized robot clusters to form a decentralized peer-to-peer network and used blockchain technology to execute different transactions in their study, demonstrating that the performance of decision-making outperforms classical methods [27]. Anbar et al. analyze the security of intrusion detection systems based on blockchain and made a conclusion about the background of integration of blockchain technology and intrusion detection along with future directions and trending topics in intrusion detection based on blockchain technology [28]. Baothman et al. built an imperial example for a blockchain electronic voting (e-voting) application using digital identity management for fulfilling immutable, transparent, and secure distributed blockchain features which proves that it is time-saving and easy to use [29].

These studies provided a solid foundation for the application of ROS-Ethereum.

3. Methodology

ROS-Ethereum is equipped with a user-friendly framework. Users are just required to input names of topics that transmit key data to configure files. Afterward, process nodes within ROS-Ethereum will monitor the assigned topic or nodes and the encrypted key data which the users need in some specific time (or a period of time) is stored on the chain with persistence and encryption for later interactive use. The framework of ROS-Ethereum is shown in Figure 1.

3.1. SM Algorithm Family

The encryption system of ROS-Ethereum is based on SM2, SM3, and SM4. SM2 elliptic curve public key crypto algorithm involves SM2-1 elliptic curve digital signature algorithm, SM2-2 elliptic curve key exchange protocol, and SM2-3 elliptic curve public key encryption algorithm which are used to implement digital signature, key negotiation, and data encryption, respectively. The SM3 hash algorithm is applied to the generation and verification of digital signatures and message authentication codes as well as the generation of random numbers in commercial applications. Concerning message m with a length of l (l < 2) bit, the SM3 hash algorithm is filled and iteratively compressed to generate a hash value. The hash value has a length of 256 bits, which has high security. The SM4 algorithm is a block algorithm. The structure of the decryption algorithm is the same as that of the encryption algorithm, except that the use order of the round key is reversed, and the decryption round key is the reverse order of the encryption round key. SM4 has high security and can effectively resist a variety of attacks. In this system, we utilize SM4 to encrypt the data communication between the client and the server and use SM2 for digital signature. The data sending end uses SM2 to sign the raw data and encrypts the whole data block including the signature through SM4.

SM4 Key Expansion: the variable size of word type is 32 bits. The variable is the initial key, an array of four 32-bit long elements for a total of 128 bits. The variable is an array containing thirty-two 32-bit long elements generated by the 128-bit initial key for the SM4 cipher algorithm. The variables and are publicly known, where is the system parameter and is the fixed parameter. Their values are as follows:

The pseudocode of the SM4 key expansion algorithm is shown in Algorithm 1.

(i)	Input: the 128-bit initial key
(ii)	listalistaOutput: the round key array of length 32, each element of size 32 bits
(iii)	Initialization: convert to an array of length 4, each element of size 32 bits
(iv)	Begin
(v)	word
(vi)	word
(vii)	For
(viii)
(ix)	For
(x)


(xi)	End
(xii)	SM4 cipher: The variable size of byte type is 8 bits. The variables and are plaintext and ciphertext pairs, and they are both an array containing four 32-bit long elements for a total of 128 bits. The SM4 cipher algorithm works for both encryption and decryption; the only difference is that the order of the round keys is reversed. The pseudocode of the SM4 cipher algorithm is shown in Algorithm 2.

(i)	Input: the 128 bit plaintext and the round key array of 32 bits each
(ii)	Output: the 128 bit ciphertext
(iii)	Initialization: convert to an array of length 4, each element of size 32 bits
(iv)	Begin
(v)	word
(vi)	byte
(vii)	word
(viii)	For
(ix)
(x)	For
(xi)
(xii)	For
(xiii)
(xiv)
(xv)
(xvi)
	For

(xvii)	End
(xviii)	SM2 KDF : KDF is the key derivation function used to derive key data from a shared secret bit string. The bitstring type is a bit string, and the integer type is an integer. The operation implies the operation of converting the type to a bit string for concatenation. is the smallest integer greater than or equal to , and is the largest integer less than or equal to . The variable is the shared secret bit string, and the variable is the length of derived key data. The variable is the output key data bit string of length . The function is the cryptographic hash function whose output is exactly bits in length. The pseudocode of KDF is shown in Algorithm 3.

(i)	Input: the shared secret bit string , the length of derived key data
(ii)	Output: key data bit string of length
(iii)	Begin
(iv)	bitstring
(v)	bitstring
(vi)	bitstring
(vii)
(viii)	For
(ix)
(x)	If is the type of Integer
(xi)
(xii)	Else
(xiii)
(xiv)
(xv)
(xvi)	For


(xvii)	End
(xviii)	SM2 Encrypt: The variable is the message to be encrypted, and the variable is the encrypted ciphertext, both of which are bit string types. The variable is the public key of the point type, and the variable is the random integer generated by the random number generator. The pseudo of SM2 encrypt is shown in Algorithm 4.

(i)	Input: the bit string type message , the public key , and the random number
(ii)	Output: the bit string type ciphertext
(iii)	Begin
(iv)
(v)
(vi)	If equals
(vii)	throw error and exit
(viii)
(ix)
(x)


	End
(xi)	SM2 Decrypt: The variable is the ciphertext to be decrypted, and the variable is the decrypted message, both of which are bit string types. The variable , , and are bit strings extracted from variable according to certain rules. The variable is the private key of the integer type. The pseudocode of SM2 decrypt is shown in Algorithm 5.

(i)	Input: the bit string type ciphertext , the private key
(ii)	Output: the bit string type message
(iii)	Initialization: extract byte strings , , and from
(iv)	Begin
(v)
(vi)
(vii)	If equals
(viii)	throw error and exit
(ix)
(x)
(xi)	If equals
(xii)	throw error and exit
(xiii)
(xiv)
(xv)	If not equals
	throw error and exit

	End

3.2. Encryption Mechanism

To ensure security during the data transmission, we designed the certificate authentication key exchange based on the SM algorithm. Firstly, it can perform the authentication of ID and temporary interaction number N between the server and the client through an identifier. Secondly, the server uses SM2 to encrypt and signal symmetric keys and deliver them to the client. Finally, the client decrypts the key K, recovering and verifying the integrity of the key. The executive process is shown in Figure 2.

As to data communication, ROS-Ethereum encrypts the original and signature of data in communication between the client and the server through SM4, keeping the transmission in the form of ciphertext to guarantee the privacy of communication data. The user selectively specifies the topic that needs to be captured. After ROS-Ethereum captures the text, it will be encrypted, using the SM4 key immediately. The ciphertext will be placed in the loop queue waiting for the sending process reading. Before the client sends messages, some pretreatment operations are firstly performed on the data ciphertext which is firstly encrypted with SM4, such as increasing timestamp and message format Jason conversion. After the pretreatment is completed, the encryption module will call the message-converted message to the second encryption and the ciphertext is sent by the UDP client to the server underthe specified port. The relevantillustrations of the conceptare shown in Figure 3.

3.3. Ethereum Setup

Through Ethereum Virtual Machine (EVM), which is a Turing complete virtual machine that processes and handles all transactions carried out in the Ethereum, a private Ethereum network where every robot which runs an independent ROS system has a relating Ethereum account is set up on the server with the help of Geth. And due to the features of a private blockchain, the identity of every robot is known and verifiable.(1)Geth : Geth client is used to build the private Ethereum blockchain. Ethereum clients are software that can establish P2P communication channels with other users, sign and broadcast transactions, mine, deploy, and interact with intelligent contracts. So far, Geth is one of the most popular Ethereum clients, which is written in the Golang language. There are two types of accounts in Geth : Externally Owned Accounts (EOAs) and Contract Accounts (Smart Contracts). ROS-Ethereum has a built-in Contract Account managed by the administrator in its private Ethereum blockchain, and the rest of the robot-bound accounts are EOA accounts. An Ethereum account is defined by a pair of keys including public keys and private keys, and each account is indexed by its address which is derived from the first 20 bytes of the SHA3 hashed public key.(2)Truffle Development Environment: truffle is an Ethereum resource management channel, development, and testing environment that makes development on Ethereum simple. Truffle can compile, link, and deploy smart contracts. And Truffle can manage the binary files generated by contract compilation. Truffle uses the package management provided by EthPM and NPM and uses the ERC190 standard. Users can directly test the contract through the console. The built-in automation script of Truffle ensures that each node can only call the methods meant for it, ensuring the security of communication between Ethereum nodes.(3)Architecture of Ethereum network: considering the actual scenario, building an Ethereum node on the robot will encounter the bottleneck of Edge Computing. Therefore, the Ethereum network composed of 3 nodes was implemented using a host equipped with a CPU (Intel(R) Core(TM) i9-10900 KF @3.70Ghz), memory (64 GB DDR4 3200 MHz), and a GPU (NVIDIA Geforce RTX3090). The robot only needs to maintain a connection with the ROS Master running on the host. Keeping the ROS system separated from the Ethereum network can avoid the bottleneck of Edge Computing. The structure of the Ethereum private chain is shown in Figure 4. Among the 3 Ethereum nodes, one node is a miner node. This node was also designated as the bootstrap node and was responsible for forming the overlay network with other nodes. 4 ROS-Melodic robots are associated with two EOA accounts in Node2 and Node3, respectively, to obtain the ability to interact with the Ethereum network.(i)Consensus Algorithm: consensus algorithms equip the distributed ledger of the blockchain with immutability, automation, and anonymous transactions without third parties. Without consensus algorithms, blockchain can only be an inefficient distributed storage database. The existence of consensus algorithms endows blockchain technology with core meaning and value. Current consensus algorithms mainly include Proof of Work (Pow), Proof of Stake (PoS), Proof of Authority (PoA), and Practical Byzantine Fault Tolerance (PBFT). Ethereum currently uses the PoW consensus algorithm. With ETH2.0 coming soon, the consensus algorithm of Ethereum will be changed from PoW to PoS. Since Ethereum has not yet fully supported PoS, in our experiments, we evaluated the effect of PoW and PoA algorithms on the time consumption of knowledge on-chain and query. The biggest difference between PoW and PoA is that PoW relies on mining to verify blocks and cannot specify the block times, while PoA relies on preauthorized nodes to verify blocks without mining operations. Therefore, the block time can be specified.(ii)Interaction Scheme: the blockchain end of ROS-Ethereum automatically obtains the message to be processed for interaction. The way to interact with Ethereum is mainly through smart contracts and contracts are developed using Solidity which is unique to Ethereum contract development. The pseudocode of the process of interaction with the blockchain of ROS-Ethereum is shown in Algorithm 6.(i)Initialization: Token which can prove the identity of robot . Ciphertext (ii)Begin(iii)Process of Registration:(iv)(v)Process of ciphertext storage:(vi)If is not registered or does not have enough ETH(vii)throw error and exit(viii)(ix)Process of data checking:(x)If is not registered(xi)throw error and exit(xii)(xiii)Process of ETH allocating: If is not registered or ETH of > 5 throw error and exit End

Genesis Block: genesis block is the first block in the blockchain. Some important parameters defining the blockchain were included in the genesis block. Normally, the file which is used to initialize the genesis block is written in JSON and is shared by all Ethereum nodes. Since we evaluate two consensus algorithms, we prepare genesis files for two consensuses each other. The files we used are depicted in Figures 5 and 6.

Some key parameters include the following:(i)GasLimit: this parameter is the maximum amount of gas that the user of Ethereum is willing to spend for a particular transaction. While gas is a unit used to measure the effort required for a particular computation in an Ethereum Virtual Machine (EVM), gas price is the value the transaction sender is willing to pay per gas unit and is measured in GWei. Ether is the token used to pay for gas.(ii)Difficulty: this parameter represents the difficulty of generating blocks in the blockchain, that is, the difficulty of calculating the hash value of the next block. The higher the difficulty is set, the longer it takes to find blocks.(iii)Alloc: this parameter is used to specify the number of preset accounts in the blockchain and the amount of ether allocated to these preset accounts. The specified amount of ether balance cannot be lower than the preset GasLimit; otherwise, there will be a situation where the amount of ether in an account is not enough to pay for the transactions it needs to execute. In addition, it is worth mentioning that the Alloc parameter only exists in private blockchains.(iv)Both the PoW and PoA based private Ethereum networks share the same set of GasLimit, Difficulty, and Alloc. All EOAs will be created and allocated balances after the completion of the initialization of the genesis block. Meanwhile, a contract account in the miner node will be created for contract deployment. After the deployment, the contract account will turn into a miner, which provides Ethers for other EOAs. Though a private Ethereum network is not part of the public blockchain, we set gas prices to a default value to simulate the true trading situation. Figure 7 depicts the workflow of ROS-Ethereum.

4. Implementation and Simulation Results Evaluation

4.1. Implementation of ROS-Ethereum in Robot

Initialize the Ethereum private chain network in the PC. To facilitate experiments, we set 10 Ethereum accounts with 100 ETH coins. The 10 accounts are shown in Figure 8.

After initialization, the smart contract is deployed to the blockchain. Block information is shown in Figure 9.

Next, we run the ‘easy_register' Python package to register an account named ‘test_account'. The registered account will be tied to an existed Ethereum account automatically for later interaction. The information on command lines is shown in Figure 10.

Finally, we input the configuration file and monitor the/robot_1/odom topic in the robot (this topic is mainly responsible for the relative position, moving line speed, etc.). After the obtained message is stored in the cache, the blockchain operation module will reach the ciphertext and call the corresponding decryption process to decrypt the secondary encryption ciphertext. Finally, the decrypted messages will be used to interact with Ethereum. Figure 11 shows the ciphertext in the cache and the prompt message of a successful interaction transaction.

4.2. Environment Setup of the System

We run experiments in five parts to verify the practicability of ROS-Ethereum: User_end messages sending rates, packet loss rate of message reception at blockchain_end, encryption and decryption efficiency and stability of SM algorithm family, the blockchain interaction ability of ROS-Ethereum in the high concurrency scenario, and effects of consensus algorithms. We ran our experiments on 4 ROS-Melodic robots with a ROS Master on the host. For the same configuration of robots, we only evaluate the performance of one robot. The detailed environment configuration is shown in Table 2.

4.3. Experiments of User_End

The experiment of the user_end mainly focuses on the response time of the message sending. The user_end information of ROS-Ethereum adopts the SM4 symmetrical encryption algorithm to encrypt and the encryption performance of the encryption algorithm largely affects the rate of messaging. It will cause the users to fail to send messages and even lose them if the response time is too long. To make the experiments results more adaptive, we write the Python file to analog the process of message delivery and use it to build bash files to simulate a process of sending 10,000 messages in a sequence. Write the time consumption of successful transmission and SM4 encryption to two CSV files, respectively. The table obtained after the washing analysis of this 10000 sets of data is shown in Table 3:

Since UDP is a transport protocol that can broadcast message broadcasts without establishing a connection, there is an advantage of a high transmission rate (32 subtle), but there are also a few packet losses (0.14%). The response time transmitted by the message is largely dependent on the encryption efficiency of the SM4 encryption algorithm. The average response time is 0.852 ms, and SM4 encryption just costs 0.82 ms. From the experimental result, the time of a single user's message is relatively low, which is in microsecond levels. In actual use, the message transmission interval (second level) is much greater than the response time. Therefore, it can meet the normal using requirements of the users. The extreme time required for SM4 encryption is between 0.50 ms and 1.23 ms, with good encryption efficiency and stability.

4.4. Experiments of Blockchain_End

The UDP server consists of data reception, data parsing, and blockchain interaction in 3 parts. We write the bash scripts simulating user links to create 300, 500, and 700 user analog processes, respectively. Experiments consist of the packet loss rate of the data reception module, the parsing efficiency of the data parsing module to the ciphertext sent by the user (reflected in the processing time), and the blockchain interaction (reflected interface call response time) under different system loads. The experimental results are shown in Table 4.

4.4.1. Packet Loss Rate

Our experiment sets the simulated process of each user analog to send 10 messages. The second column in Table 4 is the number of messages which are accepted successfully, and the third list is the number of the received message successfully going to Ethereum. The experiments results show that ROS-Ethereum can maintain a lower packet loss rate, even in high concurrent scenes. After analysis, we believe that the loss of data is mainly due to the unreliability of the UDP transport protocol.

4.4.2. Time Consumption of Data Decryption

For a different number of messages sent in different load conditions, we set 8 processes to decrypt ciphertexts stored in 8 corresponding buffers at the same time. The experimental results are shown in Figure 12. Although the increase in the total number of messages under different loads makes the overall data parsing time long, the decryption efficiency of single messages is not very fluctuated by it and the average decryption time is maintained at 0.422 ms. The extreme time required for single message decryption lies between 0.311 ms and 0.78 ms, so it can be concluded that the SM4 algorithm has good decryption efficiency and stability.

Users and blockchain interactions are the core of ROS-Ethereum. It is the core issue of our attention whether ROS-Ethereum can maintain the normal interaction of users and Ethereum under the high concurrent scenario and how many users are supported by this scheme to interact. So we assume that all users’ analog processes initiated 9 interactive requests to Ethereum in different system loads. (Mainly through the first three interfaces in the above contract, 1 is a request to register the identity in the Ethereum network, 4 times for the data upper chain request and 4 times for query requests.) We set 8 request processing processes, testing the total response time and success rate of transactions under three different concurrency parts. At the same time, we also evaluate the effect of different consensus algorithms (PoA and PoW) on the response time under the condition of the same block difficulty and GasLimit. The experimental results are shown in Figure 13.

ROS-Ethereum maintains good interaction using both algorithms in high concurrent scenes. For the success rate of transactions, both consensus algorithms reached more than 99%, and it was observed that different consensus algorithms have no significant gap in the success rate of transactions. However, it was obvious that PoA has a clear edge over PoW on the response time. This behavior follows the fact that PoW relies on the mining process to verify transactions while PoA verifies transactions through preset nodes’ voting which causes longer blocking time and verifies time of transactions of PoW. We can draw a conclusion that PoA is a faster option for information transfer in multirobots.

5. Conclusion

This paper proposes a blockchain-interaction-scheme: ROS-Ethereum. With regard to the research based on ROS and blockchain, ROS-Ethereum has good applicability and scalability. Benefiting from the SM algorithm-based encrypted transmission system we design, ROS-Ethereum has excellent safety performance and higher encryption efficiency. ROS-Ethereum provides the ROS application developers with a good choice to interact with blockchain when they need it. In the future, we will further promote the interaction capabilities of ROS-Ethereum and support more types of ROS messages to broaden the applicabilities of ROS-Ethereum through the expansion of user interfaces of ROS-Ethereum.

Data Availability

The data are available at https://github.com/RobAI-Lab/ROS-Chain.

Conflicts of Interest

The authors declare that they have no conflicts of interest.

Acknowledgments

This work was supported by the Key Research and Development Program of Hainan Province (Grant no. ZDYF2020033), Young Talents’ Science and Technology Innovation Project of Hainan Association for Science and Technology (Grant no. QCXM202007), Hainan Provincial Natural Science Foundation of China (Grant nos. 2019RC107, 2019RC098, and 621RC612), and Innovation and Entrepreneurship Training Program for College Students (Grant no. 202110589017X).

References

P. Abichandani, D. Lobo, S. Kabrawala, and W. McIntyre, “Secure communication for multiquadrotor networks using Ethereum blockchain,” IEEE Internet of Things Journal, vol. 8, no. 3, pp. 1783–1796, 2020.
View at: Publisher Site | Google Scholar
M. Ai Duhayyim, F. N, R. Marzouk et al., “Integration of fog computing for health record management using blockchain technology,” Computers, Materials & Continua, vol. 71, no. 2, pp. 4135–4149, 2022.
View at: Publisher Site | Google Scholar
M. Uddin, I. Memon, I. Ali, J. Memon, M. Abdelhaq, and R. Alsaqour, “Hyperledger fabric blockchain: secure and efficient solution for electronic health records,” Computers, Materials & Continua, vol. 68, no. 2, pp. 2377–2397, 2021.
View at: Publisher Site | Google Scholar
A. Pacheco, V. Strobel, and M. Dorigo, “A blockchain-controlled physical robot swarm communicating via an ad-hoc network,” in Proceedings of the International Conference on Swarm Intelligence, pp. 3–15, Springer, Belgrade, Serbia, July 2020.
View at: Publisher Site | Google Scholar
S. Nakamoto, “Bitcoin: a peer-to-peer electronic cash system,” Decentralized Business Review, p. 21260, 2008.
View at: Google Scholar
V. Buterin, “A next-generation smart contract and decentralized application platform,” white paper, vol. 3, no. 37, 2014.
View at: Google Scholar
J. A. Donet Donet, C. Pérez-Solà, and J. Herrera-Joancomartí, “The bitcoin P2P network,” in Proceedings of the International conference on financial cryptography and data security, pp. 87–102, Barbados, March 2014.
View at: Publisher Site | Google Scholar
F. Cornelli, E. Damiani, S. D. C. Di Vimercati, S. Paraboschi, and P. Samarati, “Choosing reputable servents in a P2P network,” in Proceedings of the 11th international conference on World Wide Web, pp. 376–386, Honolulu HI USA, May 2002.
View at: Publisher Site | Google Scholar
A. Biryukov, D. Khovratovich, and I. Pustogarov, “Deanonymisation of clients in Bitcoin P2P network,” in Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security, pp. 15–29, Scottsdale AZ USA, November 2014.
View at: Publisher Site | Google Scholar
M. Szydlo, “Merkle tree traversal in log space and time,” in Proceedings of the International Conference on the Theory and Applications of Cryptographic Techniques, pp. 541–554, Springer, Interlaken, Switzerland, May 2004.
View at: Publisher Site | Google Scholar
H. Gilbert and H. Handschuh, “Security analysis of SHA-256 and sisters,” in Proceedings of the International workshop on selected areas in cryptography, pp. 175–193, Springer, Ottawa, Canada, August 2003.
View at: Google Scholar
D. Boneh, “Twenty years of attacks on the RSA cryptosystem,” Notices of the AMS, vol. 46, no. 2, pp. 203–213, 1999.
View at: Google Scholar
F. Amounas and E. H. El Kinani, “ECC encryption and decryption with a data sequence,” Applied Mathematical Sciences, vol. 6, no. 101, pp. 5039–5047, 2012.
View at: Google Scholar
M. H. DeGroot, “Reaching a consensus,” Journal of the American Statistical Association, vol. 69, no. 345, pp. 118–121, 1974.
View at: Publisher Site | Google Scholar
L. J. Bourgeois III, “Performance and consensus,” Strategic Management Journal, vol. 1, no. 3, pp. 227–248, 1980.
View at: Publisher Site | Google Scholar
A. Fink, J. Kosecoff, M. Chassin, and R. H. Brook, “Consensus methods: characteristics and guidelines for use,” American Journal of Public Health, vol. 74, no. 9, pp. 979–983, 1984.
View at: Publisher Site | Google Scholar
J. E. Innes, “Consensus building: clarifications for the critics,” Planning Theory, vol. 3, no. 1, pp. 5–20, 2004.
View at: Publisher Site | Google Scholar
M. Li, K. Lu, H. Zhu, M. Chen, S. Mao, and B. Prabhakaran, “Robot swarm communication networks: architectures, protocols, and applications,” in Proceedings of the 2008 Third International Conference on Communications and Networking in China, pp. 162–166, IEEE, Hangzhou, China, August 2008.
View at: Publisher Site | Google Scholar
M. Li, J. Harris, M. Chen et al., “Architecture and protocol design for a pervasive robot swarm communication networks,” Wireless Communications and Mobile Computing, vol. 11, no. 8, pp. 1092–1106, 2011.
View at: Publisher Site | Google Scholar
S. H. Alsamhi and B. Lee, “Blockchain-empowered multi-robot collaboration to fight COVID-19 and future pandemics,” Ieee Access, vol. 9, pp. 44173–44197, 2020.
View at: Publisher Site | Google Scholar
J. Li, J. Wu, J. Li, A. K. Bashir, M. J. Piran, and A. Anjum, “Blockchain-based trust edge knowledge inference of multi-robot systems for collaborative tasks,” IEEE Communications Magazine, vol. 59, no. 7, pp. 94–100, 2021.
View at: Publisher Site | Google Scholar
Q. Xia, E. Sifah, A. Smahi, S. Amofa, and X. Zhang, “BBDS: blockchain-based data sharing for electronic medical records in cloud environments,” Information, vol. 8, no. 2, p. 44, 2017.
View at: Publisher Site | Google Scholar
Y. Nishida, K. Kaneko, S. Sharma, and K. Sakurai, “Suppressing chain size of blockchain-based information sharing for swarm robotic systems,” in Proceedings of the 2018 Sixth International Symposium on Computing and Networking Workshops (CANDARW), pp. 524–528, IEEE, Takayama, Japan, November 2018.
View at: Publisher Site | Google Scholar
S. Jain, M. Sawlani, and V. K. Chandwani, “Ad-hoc swarm robotics optimization in grid based navigation,” in Proceedings of the2010 11th International Conference on Control Automation Robotics & Vision, pp. 1553–1558, IEEE, Singapore, December 2010.
View at: Publisher Site | Google Scholar
Q. Shan and S. Mostaghim, “Collective decision making in swarm robotics with distributed Bayesian hypothesis testing,” in Proceedings of the International Conference on Swarm Intelligence, pp. 55–67, Barcelona, Spain, October 2020.
View at: Publisher Site | Google Scholar
A. Jamshidpey, W. Zhu, M. Wahby, M. Allwright, M. K. Heinrich, and M. Dorigo, “Multi-robot coverage using self-organized networks for central coordination,” in Proceedings of the International Conference on Swarm Intelligence, pp. 216–228, Barcelona, Spain, October 2020.
View at: Publisher Site | Google Scholar
T. T. Nguyen, A. Hatua, and A. H. Sung, “Blockchain approach to solve collective decision making problems for swarm robotics,” in Proceedings of the International Congress on Blockchain and Applications, pp. 118–125, Springer, Seoul, Korea, May 2019.
View at: Publisher Site | Google Scholar
S. Al-E’mari, M. Anbar, Y. Sanjalawe, S. Manickam, and I. H. Hasbullah, “Intrusion detection systems using blockchain technology: a review, issues and challenges,” Computer Systems Science and Engineering, vol. 40, no. 1, pp. 87–112, 2022.
View at: Publisher Site | Google Scholar
F. Baothman, K. Saeedi, and K. Aljuhani, “Computational intelligence approach for municipal council elections using blockchain,” Intelligent Automation & Soft Computing, vol. 27, no. 3, pp. 625–639, 2021.
View at: Publisher Site | Google Scholar

Copyright

Copyright © 2022 Shenhui Zhang et al. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

PDF Download Citation

Download other formats

Order printed copies

Security and Communication Networks

ROS-Ethereum: A Convenient Tool to Bridge ROS and Blockchain (Ethereum)

Abstract

1. Introduction

2. Related Works

2.1. Blockchain-Based Communication within Robot Swarm

2.2. Secure Information Sharing through Blockchain Network

2.3. Behavior Control and Optimization of Robot Swarm via Blockchain Technology

3. Methodology

3.1. SM Algorithm Family

3.2. Encryption Mechanism

3.3. Ethereum Setup

4. Implementation and Simulation Results Evaluation

4.1. Implementation of ROS-Ethereum in Robot

4.2. Environment Setup of the System

4.3. Experiments of User_End

4.4. Experiments of Blockchain_End

4.4.1. Packet Loss Rate

4.4.2. Time Consumption of Data Decryption

5. Conclusion

Data Availability

Conflicts of Interest

Acknowledgments

References

Copyright