A Time-Segmented Consortium Blockchain for Robotic Event Registration††thanks: Supported by the Tezos Foundation through a grant for project RobotChain.
A blockchain, during its lifetime, records large amounts of data, that in a common usage its kept on its entirety. In a robotics environment, the old information is useful for human evaluation, or oracles interfacing with the blockchain but it is not useful for the robots that require only current information in order to continue their work. This causes a storage problem in blockchain nodes that have limited storage capacity, such as in the case of nodes attached to robots that are usually built around embedded solutions. This paper presents a time-segmentation solution for devices with limited storage capacity, integrated in a particular robot-directed blockchain called RobotChain. Results are presented regarding the proposed solution that show that the goal of restricting each node’s capacity is reached without compromising all the benefits that arise from the use of blockchains in these contexts, and on the contrary, it allows for cheap nodes to use this blockchain, reduces storage costs and allows faster deployment of new nodes.
Keywords:blockchain robotics Tezos time segmentation
Blockchain technology enables the creation of an immutable electronic ledger of information in a distributed way, and usually leads to innumerable entries over time that new nodes joining the network need to obtain in order to contribute to it. Over time it may amount to a data capacity that embedded systems may not have, and, as such, this paper proposes a time-segmented blockchain. This idea allows cheap blockchain nodes with small resource footprints to still be able to join the network. It also improves the performance, lowers storage costs and supports faster new node deployment. The node may be configured to be either a compute device node, or a cold storage node, where a compute device node will only have the current data segment, and the cold storage node will get all the segments belonging to the blockchain. Our proposal uses the open-source Tezos blockchain and adapts it to our requirements.
Each segment of the network is connected to the previous segment by having the hash of the last block of the previous segment stored in the second block of the new segment and taking advantage of the protocol activation feature present on the Tezos blockchain. This way, the blockchain maintains its integrity through its life span. With this method it is possible to use a faster but limited memory, such as a RAM disk, or cheaper storage methods, improving the speed and decreasing the requirements for the deployment of the blockchain.
2 Related Work
There are already several proposals to integrate the blockchain technology with robots, but none that covers the use cases that RobotChain contemplates, nor contribute with segmentation techniques.
Ferrer  presents how blockchain can improve robotic swarm systems by solving some existing issues. Those issues are data confidentiality, distributed decision making, ability to work in different and dynamic environments without changes to the control program and a way to ensure safety and legal responsibility for the robotic nodes in the swarm in order to be ‘integrated’ with the human society.
In  a proof-of-concept method is introduced that uses blockchain smart contracts technology in order to improve security of the robotic swarm to improve the stability of the swarm coordination mechanisms and expel Byzantine members from the swarm. This concept is also studied for its performance in decision making regards of presence or absence of Byzantine robots. Byzantine Fault tolerance is the concern for fault-tolerance in distributed computer systems where components may fail or be unreliable.
In  a model for a kind of trading marked named robonomics is presented. It is focused on agent-based systems, where the behaviour is described as non-deterministic finite state automata, presenting a Model Checking verification technique in order to detect and filter malfunctioning agents. The validation technique can be implemented on a consensus protocol or part of a blockchain decentralised application. As a real live test, a prototype implementation of Duckietown with moving robots is provided, following a set of instructions related to movement.
In Ferrer et. al. , a learning framework, called RoboChain, is presented. It attempts to solve privacy issues related to using personal information with blockchain technology, sharing data and machine learning models, allowing multiple robotic units to work at different places, sharing their data and their knowledge. Since this approach assumes a situation where the participants are private entities (there is no public access), a level of trust between said parties is assumed and as such, the presence of a ‘malicious entity’ is not considered, but it still provides a way to verify the integrity of the interactions and learning in the blockchain.
In  a blockchain framework for a secure ride-sharing service between autonomous vehicles and passengers is described. Using blockchain as a communication mechanism that is dependable and trustworthy.
In the white paper by Chorus a blockchain operating as a network of vehicles under 5G networks is presented. This rises feasibility concerns regarding transaction processing and smart contract usage. It uses Tezos network as a basis due to its Turing complete smart contract and built-in formal verification of the programming language, allowing higher security for the blockchain and its participants. This allows focusing in the creation of the mobile ad hoc blockchains that allow disconnections from the main network and allowing sub-networks to perform transactions. It also presents smart contracts and ”orchestration and choreography protocols that facilitate, verify and enact with computing means a negotiated agreement between consenting parties”. It presents the concept of vehicles self ownership, exchanging services, like transportation for parking space or battery charging. It also presents a set of goals for this system to be successful, such as scalability, cost efficiency and automation. A prototype architecture for the chorus network is also presented.
3 The RobotChain
3.1 Previous Work
Goodman presents a self-amending crypto-ledger implemented in OCaml called Tezos. Instead of using a genesis block or hash, it starts with a genesis protocol, containing a genesis block similar to other blockchains, but with functions that allow the amending of the protocol such that it can evolve.
The main feature of this blockchain is the fact that it implements a protocol that can adapt itself by transforming a Context object. These amendments work over cycles, these cycles take about three months and are suggested by a submission to the chain, and stakeholders may vote for these amendments. These amendments, if accepted, are first inserted into a testnet, and after that, a second confirming vote is made. If the second vote is successful, the amendments are integrated into the main protocol.
These amendments are considered a positive point due to the fact that this allows the community to enact changes in the blockchain, in order to improve it, similar to a political system, preventing blockchain hard forks, which are a radical change that results in divergence from the already created chain.
In addition to this, the fact that Tezos is open source allows us to adjust it to our proposes, mainly by trying to improve transaction speed, and possibly reduce complex steps in order to make it work on cheap computational units. Another of the positive points of using Tezos blockchain technology is an increase of security with respect to the manipulation of the ledger. Also, smart contracts are proven correct, giving an additional layer of trust on the way the system is implemented. In comparison to other mainstream protocols, the self-amending feature present in the Tezos network and the verifiable security using the OCaml language, are the distinguishing points provided by this network. The self-amending feature provides a way to upgrade blockchain network, such as fine tuning the consensus algorithm, or other algorithms present without creating a hard fork on the already existent network, and the fact that the code is proved correct is of extreme importance when dealing with high cost equipment that can condition the operation of a factory.
Robots are becoming ever more important in modern factories. Currently it is a difficult task to keep track of every single action performed by every robot, in order to understand where possible bottlenecks are present or which robots need tuning, maintenance or even replacement. RobotChain contemplates the use of blockchain technology in order to solve the problem of keeping accurate immutable records of robotic actions in a factory environment. A public access blockchain is not desired, since the factory environment is a private environment and, as such, management does not allow outside access to its internal manufacturing information so RobotChain is a consortium blockchain: it has many of the advantages of a private blockchain, but instead of a single entity being the leader it operates under the leadership of a group, to allow for trust to be developed among the factory owners and the equipment providers.
Due to the fact that we are dealing with a set of robots from multiple manufacturers that are working at the same factor, we need that all the robot manufacturers and also the factory management, trust the event records, in the case that there is an accident and the guilty part has to be determined. The event records, that are stored in the blockchain, can be used for further goals such as understanding and improving manufacturing productivity. This paper deals with the fact that, although these records are important for the managers of the factories, they are not important for the day-to-day processing of the robot, since what a robot did four months ago is not important to the current functioning of the robot, meaning that is not needed on the limited storage of the compute device. So, this paper improves upon the original proposal of RobotChain, with the introduction of the time-segmentation proposal.
RobotChain as already served as basis for controlling and monitoring robots. In , the authors show how it is possible to use RobotChain to register events and with the use of smart-contracts, detect when robots are having abnormal behaviours, which can indicate the presence of internal problems to the robot (faulty bearings or others) and external problems to it, such as problems in a production line.
RobotChain was also shown to be capable of serving as basis to a new way of controlling robots . In this, smart-contracts are used to store information about the analytics that Oracles (external entities that interact with the blockchain through smart contracts) acquire from images, which is used to detect how much material is waiting to be picked, and then, the smart-contracts are also used to control the robot velocity so it adjusts to the velocity of the production line (or even stops if there is no material to be picked). Over this scenario of picking materials in a production line, the authors of  show how multiple Oracles and multiple smart-contracts can be used to both monitor a robot workspace using 3D images and to control the robot to adjust its speed to the entrance of people in its workspace. In that work, the authors define two areas over the robot workspace, the warning zone and the critical zone, which are used to define the robot speed depending if the person that enters the different zones is known or unknown. If an unknown person enters the warning zone, a smart-contract defines that the velocity of the robot should be slowed to 10 seconds per movement and if the person enters the critical zone, the robot is stopped. If the person is known and enters the warning zone, nothing happens but on entrance on the critical zone, the robot is slowed down to 10 seconds per movement.
3.2 The Time-Segmentation Idea
Figure 1 presents RobotChain in a schematic way. Each robot is connected to a computation module, and this connection is bidirectional in order to receive information form the robot to feed the blockchain and allow the blockchain, via smart contracts, to change the robot behaviour. The use of computational modules serves to ensure a uniform input into the blockchain, as different robots may need different connection interfaces. It also ensures that the robots are not negatively affected with additional software running, that could cause degraded performance or other unforeseen consequences. In addition, there can be query nodes connected to the blockchain network in order to query it for information. These are important to understand possible production line bottlenecks, or improve management understanding of the factory without directly interfacing with the robotic units. The main concern is the high transaction volume that the various networked robots will produce. Also important is the fact that RobotChain may not impact in any form the performance of the robots. Due to the fact that our proposal uses compute devices instead of running its code directly on the robot in order to prevent robot performance loss, the embedded compute devices are limited regarding data storage, as such, it is unfeasible to maintain a copy of the entirety of the blockchain on each device in the network in the long term. As such, other nodes can be added to the network with the sole propose of cold storage. Although the proposed time segmentation is applied to a Tezos blockchain network running RobotChain, the modifications made are protocol agnostic, meaning that it can run under any protocol that Tezos supports.
4 Time-Segmentation Implementation
As mentioned in the previous section, this proposal presents a time-segmentation solution for consortium blockchains, implemented using Tezos blockchain technology. This solution of time-segmentation of a blockchain consists in creating linked sub-blockchains, referred as segment or segments throughout the paper, allowing compute devices with lower storage capability the ability to keep only the latest segment instead of the entire blockchain, while maintaining the non-modification of the chain itself. Non-modification is ensured via the first block on the new segment, in our case, the RobotChain protocol activation, containing the segment identifier (an integer) and the hash of the last block of the previous segment. A second block is also created in order to re-insert the various smart contracts present on the previous segment.
On the network, three types of nodes are now introduced, the genesis node, the cold storage nodes and the compute device nodes, where the genesis is meant to serve as a bootstrap point, protocol activation and smart contract initialisation and cold storage of the previous segments. The cold storage type is meant to only store all the segments and to retrieve older segments as needed and aid the bootstrap process, and the compute devices nodes are the interface between the blockchain and the robots as mentioned in the previous section. This solution is presented to solve the storage limitation of the compute devices and the fact that the older blocks are not entirely relevant to the continuous processing of the robot in a factory floor or the current state of the blockchain. This allows compute devices with possibly small storage capacity in relation to regular computer hard drives to support a blockchain solution for an arbitrarily long time period.
4.2 Segment Creation Process
Two approaches were devised and tested during the development this proposal.
The first attempt works as follows. On the -th block, the blockchain creates a copy of its current state, effectively backing it up, then it trims the information of the existent blocks, removing the information regarding transactions from the previous segments, and inserts the new block onto the blockchain, untrimmed, starting the new segment. Cold storage nodes would keep all the various segments and the compute devices would only keep the latest segment.
Node synchronisation problems with this approach and the fact that we could not assert that the occupied storage had a maximum value, deemed it unreliable and development was focused on the second approach.
Regarding the second approach, it works as follows: The first segment, segment 1, starts the network as a regular blockchain, with the activation block receiving as parameters the segment id 1 and the original genesis block predecessor hash. Then, on its -th block, the blockchain increments the segment ID on the node’s configuration file, then shuts down the validation and database parts of the blockchain, leaving the peer to peer interface online. By leaving the peer to peer interface online, there is no need to re-initialise the peer to peer interface or to rediscover peers.
The state and validation are then reactivated with the updated configuration file, creating a new segment from scratch. The genesis node then activates the protocol, receiving as parameter the current segment ID and the predecessor segment hash, the hash from the last block of the previous segment, with the other nodes receiving this activation and resuming normal operations.
Block one is then used to initialise smart contracts present on the previous segment and other features needed. Figure 2 presents this process in a visual way. Considering a new compute device node that joins the blockchain, it will only synchronise the latest segment, the one running on the network currently. In the case that the segmentation process happens before the bootstrap finishes, the node receives a reboot signal sent by the genesis node that instructs the node to create the new segment as described previously.
In the case that the new node is a cold storage node, the node will synchronise previous segments and keep the previous segments saved instead of deleting them.
5 Experimental Results
Tests were made to evaluate the storage capability of this solution, comparing the unsegmented blockchain and the two approaches to build the segmented blockchain, where both approaches segment the blockchain at every 10 blocks. The tests were ran for 20, 50, 100, 200, 500, 1000, 5000, 10000 total blocks. Random transactions were injected into the network up to a maximum of 32 transaction clients running at the same time. These clients inject a transaction between random accounts, with value 1, with a transaction description of a minimum 1000 random characters. The storage test results are provided in figure 3.
Although the first segmentation approach is considered an improvement over the regular non-segmented network, it has the problem of not having a limit value for the necessary normal node storage, unlike the second approach, which has a average size of 5386 Kilobytes per segment. By having a definite hard limit for the maximum storage occupied by each segment, it is possible to increase the longevity of the network arbitrarily. It also aids with bootstrap due to the fact that a new node won’t need to obtain every segment from the start, needing only the latest one to work. With the ability of creating segments limited with respect to the necessary storage space, RAM disk execution on the compute devices is a possibility under investigation in order to improve the blockchain speed.
This paper improves upon the original proposal of RobotChain, a robotic event storage solution, that enables robot monitoring, control and cooperation, with the introduction of the time-segmentation proposal to solve the problems related to the small storage capacity of compute modules. It allows the use of cheap compute modules for the majority of network nodes (all but the cold storage ones) and makes the processing and connection of new nodes faster both by allowing the use of faster memory for storing the segment (such as RAM) and also because only the current segment is needed for syncing the new node with the network. The solution presented allows the creation of a time-segmented blockchain that has a definite hard limit on the segments’ storage capacity, that is independent of how long the blockchain has run for.
As future work, several features related to this time-segmentation solution are going to be implemented such as RPC interfaces for block retrieval for previous segments, allowing query nodes to access information not contained on the current segment or cold storage full synchronisation by allowing new cold storage nodes to obtain previous segments from other cold storage nodes.
-  Danilov, K., Rezin, R., Kolotov, A., Afanasyev, I.: Towards blockchain-based robonomics: autonomous agents behavior validation (may 2018), http://arxiv.org/abs/1805.03241
-  Fernandes, M., Alexandre, L.A.: Robotchain: Using Tezos Technology forRobot Event Management
-  Ferrer, E.C.: The blockchain: a new framework for robotic swarm systems (aug 2016)
-  Ferrer, E.C., Rudovic, O., Hardjono, T., Pentland, A.: RoboChain: A Secure Data-Sharing Framework for Human-Robot Interaction (feb 2018). https://doi.org/arXiv:1802.04480v2, http://arxiv.org/abs/1802.04480
-  Goodman, L.: Tezos - a self-amending crypto-ledger (2008), https://tezos.com/static/papers/white_paper.pdf
-  Hasan, M.G.M.M., Datta, A., Rahman, M.A., Shahriar, H.: Chained of things: A secure and dependable design of autonomous vehicle services. In: 2018 IEEE 42nd Annual Computer Software and Applications Conference (COMPSAC). vol. 02, pp. 498–503 (July 2018). https://doi.org/10.1109/COMPSAC.2018.10283
-  Leiding, B., Vorobev, W.V.: Enabling the vehicle economy using ablockchain-based value transaction layerprotocol for vehicular ad-hoc networks (Augst 2018)
-  Lopes, V., Alexandre, L.A.: Robot Workspace Monitoring using a Blockchain-based 3D Vision Approach. submitted
-  Lopes, V., Alexandre, L.A.: Detecting robotic anomalies using robotchain. In: 2019 IEEE International Conference on Autonomous Robot Systems and Competitions (ICARSC) (April 2019)
-  Lopes, V., Alexandre, L.A., Pereira, N.: Controlling Robots using Artificial Intelligence and a Consortium Blockchain arXiv:1903.00660
-  Strobel, V., Castello Ferrer, E., Dorigo, M.: Managing Byzantine Robots via Blockchain Technology in a Swarm Robotics Collective Decision Making Scenario. Tech. rep.