Introduction
Paper organisation
Related work
Blockchain simulators
IoT simulators
Simulator | Simulator | Programming | Core | Simulator | Features | |||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Scope | language | Type | End to end IoT layers | Blockchain layers | ||||||||||
IoT | Edge | Network | Network | Cloud | Support | Network | Consensus | Data | Support | |||||
device | communication | Protocol | blockchain | IoT | ||||||||||
VIBES [19] | Blockchain | Scala | N/A | Discrete-event | ✓ | ✓ | ||||||||
BlockSim [20] | Blockchain | Python | N/A | Discrete-event | ✓ | ✓ | ✓ | |||||||
BlockSim [21] | Blockchain | Python | N/A | Discrete-event | ✓ | ✓ | ||||||||
BlockSIM [22] | Blockchain | Python | N/A | Discrete-event | ✓ | ✓ | ||||||||
CloudSim [23] | Cloud | Java | N/A | Discrete-event | ✓ | |||||||||
CloudAnalyst [24] | Cloud | Java | CloudSim | Discrete-event | ✓ | ✓ | ||||||||
iFogSim [25] | Edge | Java | CloudSim | Discrete-event | ✓ | ✓ | ||||||||
IoTSim [26] | IoT | Java | CloudSim | Discrete-event | ✓ | ✓ | ||||||||
IoTSim-Osmosis [27] | End to End IoT | Java | CloudSim | Discrete-event | ✓ | ✓ | ✓ | ✓ | ✓ |
Research methodology
-
Objective 1: To evaluate the generalizability and quality of the conceptual model.
-
Objective 2: To determine the extent to which the IoTOsmosis simulator meets the requirements of participants.
-
Objective 3: To evaluate the effectiveness of the blockchain component of the conceptual model in meeting the needs of the participants.
-
Objective 4: To identify areas of the conceptual model that may need improvement.
Utilized methods to gather requirements
Participants
Research tools
Research procedures
Findings
Questionnaire
Interviews
Recommendations
Motivating blockchain-based IoT scenario
-
complexity of real IoT deployment merely for experiments: The complexity of real IoT deployment can be a major challenge when it comes to testing and evaluating the viability and performance of a blockchain-based IoT system. Setting up a real IoT deployment can be a time-consuming and resource-intensive process, as it requires the deployment of physical hardware and infrastructure, as well as the integration of various components and technologies. This complexity can make it difficult to conduct experiments and tests in a real deployment setting, particularly if the deployment is large or complex.
-
Lack of resources: The lack of resources can be a significant challenge when it comes to testing and evaluating the viability and performance of a blockchain-based IoT system. Conducting experiments and tests in a real deployment setting can be resource-intensive, as it requires the deployment of physical hardware and infrastructure, as well as the integration of various components and technologies. This can be particularly challenging for organizations that do not have access to the necessary resources, such as funding, personnel, or technical expertise.
-
Lack of technical workforce: The lack of a technical workforce can be a major challenge when it comes to testing and evaluating the viability and performance of a blockchain-based IoT system. Setting up a real IoT deployment can be a complex and technical process that requires specialized skills and expertise. This can be particularly challenging for organizations that do not have access to a sufficient number of technical personnel or do not have the necessary expertise in-house.
-
Cost inefficiency: Conducting experiments and tests in a real deployment setting can be costly and inefficient, particularly if the deployment is large or complex. Setting up a real IoT deployment requires the deployment of physical hardware and infrastructure, as well as the integration of various components and technologies. This can be a time-consuming and resource-intensive process that may not be cost-effective for organizations, particularly if the deployment is only being used for testing and evaluation purposes.
Conceptual architecture
Configurator
Generator
Simulation core
-
The transaction factory and workload feeder are components in a simulation environment for a blockchain-based IoT system. The transaction factory is responsible for generating transactions based on the data collected from the workload feeder, while the workload feeder manages the flow of transactions and ensures that they are processed efficiently and accurately. The transaction factory follows a specific process to create and broadcast transactions, including:The process of generating and managing transactions is typically repeated until no more transactions are being fed into the system by the workload feeder. Overall, the transaction factory and workload feeder play important roles in the simulation process by generating and managing the flow of transactions within the system, and by helping to test and evaluate the performance and viability of the blockchain-based IoT system. In a blockchain network, miner nodes are responsible for creating blocks of transactions and adding them to the blockchain. When a miner receives transactions in its transaction pool, it will typically try to create a block by selecting a subset of the transactions from the pool and adding them to a new block. The process of creating a block is often referred to as an “event,” as it represents a significant event in the operation of the blockchain network. In order to create a block, a miner must typically perform a consensus algorithm such as a proof of work, which involves using cryptographic algorithms to demonstrate the work that has been done to validate and include the transactions in the block. In a simulation environment, the aim may be to simulate the process of creating blocks and adding them to the blockchain in order to test and evaluate the performance of the network and the miner nodes. In the conceptual mode, we create a Block Factory component.
-
Construct a Transactions Structure: The transaction factory prepares the format of the transactions to match the structure required by the blockchain network. This includes defining the data structure and required fields for the transactions, as well as any other requirements or constraints.
-
Broadcast transactions to miner nodes: Once construct a transaction structure, then broadcasts the prepared transactions to all nodes in the network in order to inform them of the new transactions.
-
Appending the transactions to the transaction pool a collection of pending transactions that are waiting to be added to the blockchain.
-
-
The block factory is a component in a simulation environment for a blockchain-based IoT system. It is responsible for simulating the process of creating blocks and adding them to the blockchain. The block factory follows a specific process to create and execute transactions, including:Overall, the block factory plays a crucial role in the simulation process by helping to simulate the operation of the blockchain network and by providing valuable insights into its performance and viability. Once a block has been broadcasted to the blockchain network, it becomes the responsibility of the block receivers to validate the block and decide whether to accept it and add it to their copy of the blockchain. The process of validating a block involves verifying that the block meets all of the requirements and standards of the blockchain network. This may include checking the block header to ensure that it includes a valid reference to the previous block in the blockchain, and verifying the transactions contained in the block to ensure that they are valid and properly formatted. In the conceptual mode, we create the Received Blocks component.
-
Invoking and Executing Transactions: The miner selects a subset of pending transactions from the transaction pool based on certain criteria, such as the time the transactions were created, the gas price associated with them, or the order in which they were received.
-
Append Transactions to Next Block: When a miner node receives transactions in its transaction pool, it will typically try to create a block by selecting a subset of the transactions from the pool and adding them to a new block. This process is known as “appending” the transactions to the block, as it involves adding the transactions to the block and preparing them for inclusion in the blockchain.
-
Constructing block and append it to the local blockchain: After the block has been created with its set of transactions.
-
Append Block to local Blockchain: Once the block has been constructed, it is ready to be appended to the local copy of the blockchain. This involves adding the block to the end of the local copy of the blockchain and updating the local copy to reflect the new block.
-
Broadcast the block to other nodes: The miner broadcasts the newly added block to all other nodes in the network in order to inform them of the new block and update their copies of the blockchain.
-
-
Received Blocks: a component in a simulation environment for a blockchain-based IoT system. It is responsible for receiving blocks that have been broadcasted to the network and deciding whether to accept them and add them to the local copy of the blockchain. The received blocks component typically follows a specific process when receiving a new block, which may include the following steps:
-
Check Validity of Received Block when receiving a new block, one of the key tasks of the Received Blocks component is to check the validity of the received block. This involves performing a series of validation checks on the block to ensure that it meets all of the requirements and standards of the blockchain network.
-
Updating and Append it to the Local Blockchain if the received block is deemed to be valid, the next step in the process is to update the local copy of the blockchain and append the received block to it. This involves adding the received block to the end of the local copy of the blockchain and updating the local copy to reflect the new block.
-
Updating the transaction pool Once the new block has been added to the local blockchain, the node will update the transaction pool by removing the transactions that were included in the block. This leaves the transaction pool with only the transactions that have not yet been included in a block, allowing the node to continue the process of verifying and adding new transactions to the blockchain.
-
Reporter
-
Configuration: This provides important information about the parameters used to conduct the experiment, such as the type and number of nodes, the blockchain protocol used, and any other relevant system parameters. This information is important for understanding the context in which the simulation was conducted, and can help to identify any factors that may have influenced the performance of the system.
-
Overall result: A benchmark report provides a summary of the overall performance of a blockchain-based IoT system. This includes a range of statistics that can be useful for understanding the system’s performance and identifying any issues or opportunities for improvement. Some examples of the types of statistics that might be included in the “Overall result” section include:
-
Total number of blocks: This is the total number of blocks that were added to the blockchain during the simulation.
-
Total number of blocks including transactions: This is the total number of blocks that contained at least one transaction.
-
Total number of blocks without transactions: This is the total number of blocks that did not contain any transactions.
-
Average block size: This is the average size of the blocks in the blockchain.
-
Total number of transactions: This is the total number of transactions that were processed during the simulation.
-
Average number of transactions per block: This is the average number of transactions included in each block.
-
Average transaction inclusion time: This is the average time it took for a transaction to be included in a block.
-
Average transaction size: This is the average size of the transactions processed during the simulation.
-
Total number of pending transactions: This is the total number of transactions that were waiting to be processed at the end of the simulation. Average block propagation time: This is the average time it took for a block to be propagated (i.e., disseminated) to all nodes in the network.
-
Average transaction latency: This is the average time it took for a transaction to be processed and added to the blockchain.
-
Transaction execution: This is the percentage of transactions that were successfully processed during the simulation.
-
Transaction throughput: This is the number of transactions that were processed per second.
-
-
Blocks overview: A benchmark report provides details about the individual blocks that were added to the blockchain during the simulation. This includes information such as the block ID, previous block ID, block depth, block timestamp, block size, number of transactions, and the minter (the node responsible for creating the block). This information can be useful for understanding the overall performance of the system at the block level.
-
Transactions latency overview: A benchmark report provides details about the latency of individual transactions in a blockchain-based IoT system. Latency refers to the time it takes for a transaction to be processed and added to the blockchain, and it can have a significant impact on the overall performance of the system. Included in this section are details about the transaction latency of each transaction, including the transaction ID, creation time, confirmation time, and transaction latency. This information can be useful for understanding the overall performance of the system at the transaction level.
-
Pending Transactions overview: A benchmark report provides details about transactions that were not executed during the simulation. These transactions may not have been executed for a variety of reasons, such as being delayed due to insufficient resources or other issues.
-
Statistic: A benchmark report provides statistical information about the performance of a blockchain-based IoT system. Specifically, it provides details about the distribution of block time and block latency, including the minimum, maximum, mean, and standard deviation of these metrics.
Evaluation
Participants
Participant | Research Interest |
---|---|
1 | Blockchain technology and IoT applications |
2 | Blockchain performance |
3 | Blockchain-based SLA in the context of IoT |
4 | Data privacy in the context of IoT via blockchain |
5 | Allocating Cloud resources & blockchain |
6 | Optimization blockchain with the internet of Vehicles (IoV) |
7 | IoT & Blockchain |
8 | Research related to IoT, Cloud and Blockchain |
9 | IoT data management, and blockchain |
10 | Remote health monitoring using IoT and blockchain |
Procedure
-
Questionnaire1To what extent are you satisfied with the conceptual model?2To what extent are you satisfied with the conceptual model’s generality?3Assuming that IoTOsmosis is the base IoT simulator in the conceptual model, to what extent do you agree that it covers your requirements?
-
ease of use
-
configurability
-
extensibility
-
maintainability
-
network topology
4To what extent does the blockchain part cover your requirements? -
-
Focus Group1What are your overall thoughts on the conceptual model for the blockchain simulator?2Do you believe the conceptual model for the blockchain simulator is comprehensive and well-designed, or are there any areas that you feel need further improvement or refinement?
Experimental results
Questionnaire
Question | Objective (1) | Objective (2) | Objective (3) |
---|---|---|---|
Q1 | ✓ | ||
Q2 | ✓ | ||
Q3 | ✓ | ||
Q4 | ✓ |
Focus group
Participant | Overall Thoughts | Areas for Improvement |
---|---|---|
P1 | Well-designed and comprehensive | |
P2 | Solid and well-thought-out | More granular control over parameters and settings |
P3 | Promising concept | More options for customizing the simulation |
P4 | Easy to understand and well-organized | Consensus algorithms |
P5 | Very promising | Flexibility to deploy BC in different IoT layers |
P6 | Well-designed | |
P7 | Comprehensive and well-designed | Ability to simulate enterprise blockchain and support different IoT simulators |
P8 | Good | |
P9 | Strong foundation | Configuring the blockchain network |
P10 | Good |
Question | Objective (1) | Objective (4) |
---|---|---|
Q1 | ✓ | |
Q2 | ✓ | ✓ |