5.1 Proof of Identity (PoI)
The PoI algorithm allows only authorized nodes to mine blocks and thus, creates a permissioned blockchain. However, in contrast to the typical Proof-of-Authority (PoA) algorithms, the authorized nodes are not declared before the blockchain is run (Ferdous et al., 2020). To allow new miners into the network during runtime, the PoI algorithm introduces a novel swarm controller that uses a private-public key pair to sign authorized miners. This allows PoI to create dynamically permissioned blockchains.
When the swarm controller is spun up, a private-public key pair is generated. To add a new miner, the miner first sends its coinbase to the swarm controller. The swarm controller signs the coinbase with its private key and returns its signature. The miner also obtains the swarm controller’s public key.
When mining a block, a miner adds its signature to the header of the block and seals it. When verifying blocks, the verifying node decrypts the signature of the block with the public key of the swarm controller and checks if the decrypted value is equal to the coinbase of the miner. If the values match, then the authenticity of the miner can be affirmed.
This solves the 51% attack threat because no node, however powerful it might be, cannot compromise the network if it is not authorized by the swarm controller. At the same time, since the algorithm does not involve producing the right block through trial and error, the performance concerns are also rectified.
5.2 Benchmarking Tool
The benchmarking tool was developed to benchmark the performance of the PoI algorithm using the collective perception scenario on top of the benchmarking tool developed by Valentini, Brambilla, et al. (2016) and Strobel et al. (2018). This benchmarking tool improves the existing tool by introducing a live dashboard to carry out experiments, a database to store experiment data, and a service layer to facilitate communication between the dashboard and the simulator.
5.2.1 The Architecture of the Benchmarking Tool
The architecture of the prototype consists of the frontend layer, service layer, simulator layer, and blockchain layer. The frontend layer provides the user of this prototype with a user interface to interact with the prototype. The service layer sits in between the frontend layer and the simulator layer and provides the necessary APIs to the frontend layer to communicate with the simulator layer. The simulator layer interacts with the blockchain layer to solve the collective perception scenario using the smart contract deployed in the blockchain. The forthcoming section discusses these layers and the modules belonging to them elaborately.
5.2.1.1 The Frontend Layer
This layer consists of the Graphical User Interface (GUI) that a user will be using to interact with the prototype. It consists of the following modules:
- Experiment Creation Form—This is a form that allows a user to configure the parameters of the experiment such as the number of robots, the decision rule to be used, the percentage of black and white tiles, the number of Byzantine robots and the approach to be used.
- Experiment Queue—Since, to benchmark different solutions, a user may need to run experiments in batches, experiments created using the Experiment Creation Form are added to this queue. This queue allows users to delete experiments that are later deemed unnecessary, specify the number of times each experiment should be repeated and provides a button to start running the experiments in the queue.
- Experiment Data View—This view shows the result of each experiment live as it is completed in a tabular format. This view also allows the user to download the results as a Comma-Separated-Values (CSV) file. Moreover, this view also shows a progress bar to give the user an idea about how many experiments have been completed and how many more remain.
5.2.1.2 The Service Layer
This layer allows the frontend layer to communicate with the simulator layer by providing the necessary APIs. The configurations of the experiment entered through the frontend layer are fed to the simulator via this layer. This layer also communicates the results of the experiment from the simulator layer to the frontend layer. The modules contained in this layer are as follows:
- REST API Service—This provides REST API services to be consumed by the frontend layer. Users can configure experiments, start experiments and get experiment results using these REST API services. The experiment configurations sent to this service by the frontend are also persisted in a database in the data layer.
- Websocket—This allows live experiment results to be streamed to the frontend layer so that users can view the experiment results in a GUI that gets updated automatically.
- Message Queue—This is used to capture the experiment results from the simulator layer. This allows process-to-process communication between the server and the simulator. The experiment results in the message queue are also persisted in a database in the data layer.
5.2.1.3 The Simulator Layer
This is the layer where the experiments are run. This layer gets the experiment configuration from the service layer, runs the experiments, and communicates the results of the experiments back to the service layer using the message queue. This layer consists of the following modules:
- Test Grid—This is the environment in which the robots will operate on. This is a 200 × 200cm2 grid consisting of 10 × 10cm2 tiles of colors black and white. The ratio between the number of black and white tiles is configurable. Moreover, this grid is bounded by walls that can be detected by the robots to avoid collisions.
- e-puck Robot—This is a small robot with a footprint of 7cm2 that is used to sense the color of the tiles and to take part in the consensus achievement task to find the color of the majority of the tiles. When blockchain is used, this robot also acts as a miner.
- ARGoS 3—This is the simulator that controls the robots. This simulator runs the robots on the test grid and finds out if consensus has been reached or not. Apart from this, the simulator also gathers evaluation metrics such as the exit probability and consensus time and communicates them to the service layer.
5.2.1.4 The Blockchain Layer
The blockchain layer consists of the blockchain, the mining nodes, the validators, and the swarm controller. The e-puck robots in the simulator layer publish their opinion to the blockchain and receive updated opinions from the smart contract running on the blockchain. The functionality of the modules in this layer is discussed below.
- Swarm Controller—This module signs the coinbase of the miners with its own private key and distributes its public key to the miners. This allows the PoI algorithm to create a dynamically permissioned blockchain.
- Miner—The e-puck robots also act as miners who mine blocks to be added to the blockchain. When the robots publish their opinions as transactions, the miners verify these transactions and add them to a new block before sealing them with their signature.
- Validator—The e-puck robots also act as validators. The validators validate the blocks mined by the miners before adding them to their blockchain. The blocks are validated by verifying the signature found in the blocks using their coinbase and the public key of the swarm controller.
- Blockchain—The smart contract that runs the decision rule algorithm is deployed in the blockchain.
5.2.1.5 The Data Layer
The data layer consists of a database that is used to persist the experiment results so that this data can be later serialized into a different format or used as it is for data analysis. Aside from this, experiment configurations sent by the frontend to the REST API service are also persisted in the database.
5.2.2 The Functioning of the Benchmarking Tool
Figure 3 shows the data flow diagram that shows how data flows between different components of the benchmarking tool. Accordingly, it can be seen that a user first inputs the experiment configuration to the frontend app, which is then sent to the REST API service. This data is persisted in a database while being fed into the ARGoS 3 simulator. The simulator then configures the e-puck robots using this configuration data.
The e-puck robots sense the color of the tiles in the test grid and transact their opinion about the color to the blockchain miners. The miners verify these transactions, pack them into blocks and broadcast them to the validators. The validators validate these blocks and add them to their blockchain. The blockchain smart contract runs the decision rules and updates the e-puck robots with the new opinion. The ARGoS 3 simulator reads the opinions of the robots to decide if consensus has been reached.
Once consensus is reached, the evaluation metrics of the experiment are pushed to the message queue. These metrics are persisted in the database and emitted to the frontend using a WebSocket so that the user can view the data live.