Optimizing Blockchains Structures Based on Entropy and TOPSIS Model

In this study, a new and applicable model is proposed which represents the opportunities of implementing blockchains into IoT framework in the sensor data acquisition. We aim to propose a simple perspective of blockchain in IoT which is flexible with high throughput in sensor networks. This method is based on probabilities that use the combination of the Entropy and TOPSIS model and the blockchain parameter configuration used in the proposed model in this study includes: Parameters, Block, Epoch Time, Consensus Protocol, Throughput Queuing, Network Topology and Containerization. We selected Hyperledger Fabric as our blockchain solution to deploy across our network with the use of Docker Swarm. Our framework leverages the containerization of Fabric so that the network can operate between the edge devices and the cloud in a single, private system. This model contains some areas in security, such as privacy policy and delay versus the value of the task to be processed.


Introduction
Blockchain technology has shown promising application prospects, which is a distributed means of securing data in a way that is auditable, immutable, and fault-resistant. Blockchain introduced in 2009 (Nakamoto, 2008), which debut of Bitcoin served as a functional proof-of-concept and removed any necessary access for trusted third parties in the transaction with any strange people in the world. These transactions need to validate from banks, but Blockchains carried out by network peers. Blockchains are based on trust which created in a trust-less platform to act as rules. When it created, Bitcoin had some faults slow to process any transactions and it is not scalable when participants grow and may still be susceptible to a number of different attacks. On the other hand, the number of smart devices with wireless communication capabilities has risen to a scale of billions (Gartner, 2015). This kind of growth is to occur the manufacturing costs of electronics and will develop a smart device with sensors connected to the Internet. These sensors have a lot of tasks by using the Internet, but these sensors nodes which defined and determined in smart devices have some limitations, such as processing power, preventing them from running CPU intensive tasks locally, privacy policy, and security. Because of these limitations, these sensor nodes can offload their processing tasks to run in a cloud area server which can be faced with some other challenges, such as delay and low access and response time to users. This challenge can be solved by defining some edge devices as an intermediary between the end-users nodes which use smart devices and cloud. These edge devices can bring the local connection to the smart devices and challenges, such as delay and low access and respond time to users run in local when other tasks are offloading to the cloud. For solving this problem, a cloud and edge computing model should be improved to optimize delay and low access and respond to time to users.
By combining Blockchain to these edge-centric IoT systems, some other challenges will be taken which surveyed in (Dorri et al., 2016;Yeow et al., 2017). Because IoT is not expensive as Blockchain in power consumption, communication, computation, and memory usage, combining IoT and Blockchain supposed to be a creative work that is a distributed ledger. The traditional approach of centralized services has a single point of failure, but Blockchain does not have it. Every participating node has a copy of the Blockchain ledger, and changes to that ledger are very difficult to make without the proper consensus of some determined number of participants. By securing the IoT system with an optimized structure of Blockchain can bring decentralized management of devices. In addi-Journal of Service Science and Management tion, Blockchain's immutability can offer a way to audit and track data sources.
In this study, we aim to propose a simple perspective of blockchain in IoT which is flexible with high throughput in sensor networks. This model contains some areas in security such as privacy policy and delay versus the value of the task to be processed. Also, we propose framework trends present in the literature and how to implement them. In Section 2, an overview of the core Blockchain concept studied; Section 3, presented trends in the IoT framework; Section 4 discussed Blockchain parameters used in the proposed model; and Section 5 tried to describe applying Blockchain to an IoT system implementation.

Blockchain Overview
The name "Blockchain" itself refers to the structure of the Blockchain's data can be thought of as an immutable chain of events. Data, mostly in the form of transactions, are grouped together in a block. This block is then packaged with a reference to the previous block, which contains a reference to the block before that, etc. Blockchain is "distributed" because every participant in the network holds a copy of this append-only ledger. All participants, or peers, must agree on the state of the ledger and unauthorized changes to that ledger must be reasonably detectable. In reality, Blockchain technology requires 1) a distributed ledger among peers, 2) a consensus protocol to ensure that all peers have the same copy, and 3) a cryptographic infrastructure. Every other detail is determined by the desired application. Since public blockchain platforms are open to the world, they can rapidly draw the attention of software development companies and communities to the strengths of blockchain technology (Sicilia & Visvizi, 2019). presently, the intricacy of supply chains and the issues that exist in the administration of this chain prompts an exercise in futility and cash. Utilizing new innovations, for example, blockchain will improve quality and diminish costs (Troisi et al., 2020).

Consensus Protocols
We provide an overarching classification for consensus methods. In-depth protocol algorithms and mathematical proofs of robustness are beyond the scope of this paper. Consensus protocols have their own massive pool of research effort and are well-reviewed in other works: (Vukolić, 2016;Yeow et al., 2017;Christidis & Devetsikiotis, 2016;Cachin & Vukolic, 2017 (Cachin & Vukolic, 2017). Although this is by no means an exhaustive list. Note that election difficulty and leader term lengths could be configurable parameters.
2) Majority Election: The majority election refers to a majority of peers voting on a particular value. Peers could vote to validate a transaction, or vote upon a block leader. The distinction here is that majority election does not rely on probability, but is instead far more communication-bound-the notable example being Practical Byzantine Fault Tolerance (PBFT) (Castro & Liskov, 2002).
The consensus in this manner must take care to manage its upscaling to prevent significant communication overhead. The general trend is to create "round-robin" or subgroup voting pools to mitigate scaling issues (Mazières, 2016).

Implementation Differences
1) Read-Write Access: Blockchain systems can be defined by what entities have read and write access to the ledger. As aforementioned, write access is append-only. If any peer can read the ledger, it is public. If the read access is limited, it is private. If any peer can append to the ledger, it is permissionless. If write access is limited, it is permission. Bitcoin serves as the prime example of a public, permissionless Blockchain network. Anyone can participate in the network and the ledger is open to the public. Anonymity is preserved by the use of public-private key pairs. Public networks tend to require computationally heavy consensus methods-or, in the case of Ethereum's hash method (Buterin, 2015), computation, and memory-intensive. This is mainly to protect against Sybil attacks and prevent double-spending (see II-C). A network like Sovrin (Windley & Reed 2018) is public and permission. Anyone has access to ledger information, but additions to the ledger can only be made by a specific set of participants. Permissioned Blockchain has the benefit of not requiring consensus methods as resource-intensive as permission-less systems since unauthorized parties could be revoked for not being part of a whitelist. Privacy is not a goal for Sovrin, which is an identity management system. Alas, even for Bitcoin's anonymous addressing, true privacy is not guaranteed on a public network ( in forks when more than one peer concurrently broadcasts a valid block to append to the ledger. At that point, peers will continue to "race" against one another to find the next hash value, and once the longer chain is created, the other peers will adopt that chain. Ethereum mitigates this wasted effort by creating incentives to include so-called "orphaned" blocks into the main chain. Directed Acyclic Graphs (DAG) have also been suggested for block ordering to decrease ordering delay (Lewenberg et al., 2015;Popov, 2017). Whereas traditional Blockchain is mostly linear in structure, DAG Blockchain allows for more complex web chains. Block pruning has been suggested to reduce ledger size (Kokoris-Kogias et al., 2017), generally by reducing older blocks into a new "jumpoff" point from which the ledger can continue. As long as all peers reach consensus and agree to prune, the ledger can be collectively reduced. This method needs to carefully define at which point old data is considered "old enough." Ledger sharing is another method to reduce ledger read times. A system could provide service-specific Blockchain, such as in . Transaction validations would avoid searching through unnecessary blocks in order to find relevant information, but be linked at common blocks for some set interval.
Other proposed protocols with ledger sharing can be found in (Luu et al., 2016).
Possible attack vectors on a Blockchain network. Which the peer node outside the inner shaded area is the only non-malicious actor presented in Figure 1.

Common Attack Vectors
Common attack vectors involving Blockchain systems include Sybil attacks, 51% attacks, routing attacks, and insecure wallet implementations (Figure 1). Keeping these attacks in mind that are as follows help to remember the limitations and requirements of a Blockchain system. 1) Sybil Attack: Sybil attacks refer to the generation of multiple virtual peers by a malicious party with the intent to influence a network. Permissioned Blockchain will throw out unauthorized requests to the network. Public networks such as Bitcoin and Ethereum utilize CPU-intensive algorithms to prevent such attacks, forcing participants to "vote" with computing power.
2) 51% Attack: The 51% attack is similar to the Sybil attack, but more broadly refers to a malicious party controlling the majority of the network to influence the Blockchain. In a system that relies on computing resources to build a Blockchain, the majority pool will be able to dominate the ledger.
3) Routing Attacks: Since Blockchain networks are heavily communication-dependent, routing attacks can affect block propagation, and thereby block ordering on more remote peers (Apostolaki et al., 2017). This can be especially detrimental to implementations of Blockchain that make use of timeouts to throw out potentially invalid or malfunctioning peers.

Applications
Blockchain is inherently transactional, its functionality has been expanded to include smart contracts-code stored on the Blockchain that executes upon fulfillment of programmed criteria (Szabo, 1996). Instead of requiring some trusted third party to verify an agreement between parties, a contract stored on the Blockchain could automate specified transactions. Smart contracts provide a way to create a system that is, to some degree, self-managing. With smart contracts, blockchain networks can accomplish more than crypto-currency. They can provide proof of existence, intellectual property rights, public notaries, supply chain management (Christidis & Devetsikiotis, 2016;Bahga & Madisetti, 2016;Pureswaran & Brody, 2014;Crosby et al., 2016), any application that could benefit from an immutable record. Blockchain has been investigated for smart grids, smart homes (Andersen et al., 2017;Dorri et al., 2017), decentralized program applications (Buterin, 2015) database storage (McConaghy et al., 2016), and the list of potential uses continues to grow with every passing day.

Proposed Method
Though merging Blockchain and IoT is not without its challenges, a common theme in overcoming issues of delay and computation overhead is to utilize edge, fog, and cloud computing. Edge devices serve as gateway nodes for data aggregation and packaging while leveraging the more plentiful resources of the cloud. This emerging hierarchy of computing resources tends to follow the patterns shown in Figure 2: centralized, locally centralized, decentralized, or layered. Works such as (Stanciu, 2017) and (Liang et al., 2017)

Proposed Model Parameters Configuration
IoT networks tend to produce large amounts of data that need to be analyzed for further action. This need incites requirements for the delay, throughput, authentication, integrity, and likely privacy while minimizing resource consumption. In an environment of numerous devices, a system also needs to be careful with the management of identities and cryptographic keys.
In this study, we aim to propose a simple perspective of blockchain in IoT which is flexible with high throughput in sensor networks. This model contains some areas in security such as privacy policy and delay versus the value of the P. Sabbagh Journal of Service Science and Management task to be processed. In this section, we discuss the blockchain parameter configuration used in the proposed model that includes Parameters Block, Epoch Time, Consensus Protocol, Throughput Queuing, Network Topology, and Containerization. Blockchain parameters used in the proposed model seek aims to propose a simple perspective of blockchain in IoT which is flexible with high throughput in sensor networks. Also, contains some areas in security such as privacy policy and delay versus the value of the task to be processed.
1) Block Parameters: Block size can be varied by restricting the number of transactions to each block, or placing a limit on data size. Data size will affect propagation times and communication channel overhead. Block intervals, the time allowed between block creation, can also be controlled. Bitcoin aims to create blocks roughly every 10 minutes (Abraham et al., 2016), whereas Ethereum will create a new block about every 15 seconds (Buterin, 2015). This affects the time it takes for a transaction confirmation since blocks that have been in the chain longer are more secure it would take more effort for a malicious party to change older blocks than newer ones. To some degree, dynamic consensus parameters are already utilized in the Bitcoin network. Hashing difficulty is altered to ensure block intervals at a set rate, which is a response to peer activity. We could take this further and have a system respond to peer count, channel conditions, peer status, etc. Other difficulty controls for consensus systems are reviewed in (Kraft, 2016).

4) Throughput
Queuing: In the case of changing environments, end devices that are trying to submit data to the ledger may not be able to transmit at an optimal rate. If an end device is functioning but its gateway node loses connection, ideally the data should be preserved. Once the connection is restored, the peer may need to make use of some kind of queuing policy to prevent flooding the network with requests.

5) Network Topology: Since Blockchain implementation is dependent upon
the distribution of peers by necessity, having the actual network reconfigure in response to the environmental conditions could prove an interesting adaptation.
This would work best in a permissions environment, else the system would risk a 51 % attack from malicious peers. Additionally, difficulties would arise with key and certificate distributions. Journal of Service Science and Management 6) Containerization: The suggestion to utilize containers in IoT-Blockchain systems has been investigated in (Stanciu, 2017), and indeed projects such as Hyperledger Fabric are closely coupled with Docker containers for pluggable operation. Container orchestration across environments could be handled with Docker Swarm or Kubernetes. Table 1 represents the main parameters of this study to model optimizing blockchain in IoT system by using the Entropy and TOPSIS method. All of these parameters mentioned in Table 1  At first, the confidentiality of data must be modeled. Hence, the local error is in the form of Equation (1) at the Blockchain in IoT system.   In the above equation, each section is the difference between raw data and summary in the provider i (sender or receiver of data). A higher level local error in detecting attacks gives greater security and confidentiality. It should be noted that local error does not depend on cumulative function. The precision of the confidentiality of data in detecting attacks is calculated by general error which is in accordance with Equation (2).
Given the fact that the confidentiality of data is possible under the conditions of Equation (1) and (2) The higher the overall error, the lower the response will be to maintain the confidentiality of information in communicating and detecting attacks in Blockchain in IoT system. To maintain the confidentiality of data when communicating devices, they must compute a cumulative distribution function between raw data and cumulative data, which is called a local group error whose relationship is as Equation (3).
, , , Similarly, the cumulative distribution function must be computed between aggregated data and cumulative data, which is called the sum of the group error by calculating with Equation (4).
The calculation of the throughput in the Blockchain in IoT system is given by the Equation (5), the delay calculation is in the form of the Equation (6), and the bit error rate calculation is in the form Equation (7).

Window
Max is the maximum window size in the evaluation of sending and receiving data, which can be calculated after calculating the delay in Equation (6). RTT is the time it takes to send data in sweep along the way in Journal of Service Science and Management the Blockchain in IoT system. It is worth noting that the calculation of delay has been done end-to-end.

Blockchain Implementation for the Proposed Framework
In this section we try to describe applying blockchain to an IoT system implementation as following: A. Hyperledger Fabric: We selected Hyperledger Fabric as our blockchain solution to deploy across our network with the use of Docker Swarm. Fabric is a private, permissions blockchain whose functions are closely coupled with Docker containers (Yang & Enyeart, 2015). The fabric also decouples transaction va-   D. Cloud Layer: The Cloud Layer is where multiple peers can be deployed for fault-tolerance. The optimal number of backup peers will ultimately depend on the overall system environment. The Cloud Layer will also contain the Orderer nodes so that the Edge Device Layer does not have to handle the overhead of block-creation. E. Data Workflow: As represented in Figure 4, data acquired by the sensors transmit to the edge devices. The data is packaged by chain code hosted on the peer nodes. The peer that packages the respective data into a "transaction" will request validation from a configurable number of peers. The selected peers will be able to determine transaction validity by way of criteria that can be determined by the Blockchain designer, typically this will include transaction structure and peer signature authenticity. If the data transaction passes validation, the Peer that created the transaction will send it to the orderer nodes in the Cloud Layer. If the selected peers deem the data transaction invalid, it will not be sent to the orderer nodes. Once the orderer nodes receive enough transactions to create a block, or the Block Epoch time has expired, they will reach a consensus on the order of transactions they have received since the last block's creation.
The block will be created and broadcast back to the peer nodes. Data acquisition frequency should be related to Epoch time in order to control overall latency from sensor detection to ledger access by an authorized client.

Conclusion
Combining blockchain with IoT provides a stable and robust decentralized way to manage the rapidly increasing number of networked devices. By reconfiguring some parameters of Blockchains, it can lead to enable these dynamic features to lead a system that is capable of enduring changing environments. Choosing what parameters of Blockchain in viewing mode and design in the process, helps to analyze management in a stand-alone system. By considering some security advantages and quality of services criteria such as processing power, preventing them from running CPU intensive tasks locally, privacy policy versus the value of the task to be processed to gain the best rates of throughput and delay, it will be possible to enhance the structure of blockchain in IoT systems.
The blockchain parameter configuration used in the proposed model in this study includes: Parameters Block, Epoch Time, Consensus Protocol, Throughput Queuing, Network Topology and Containerization. In this study, a new and applicable model is proposed which represents the opportunities for implementing blockchains into IoT framework in the sensor data acquisition. This method is based on probabilities that use the combination of the Entropy and TOPSIS model. We aim to propose a simple perspective of blockchain in IoT which is flexible with high throughput in sensor networks. This model contains some areas in security such as privacy policy and delay versus the value of the task to be processed.
The main contribution of the study is that we selected Hyperledger Fabric as our blockchain solution to deploy across our network with the use of Docker Swarm. Our framework leverages the containerization of Fabric so that the network can operate between the edge devices and the cloud in a single, private system. We selected Hyperledger Fabric which guarantees interoperability and confidentiality through the creation of channels, as well as the optimization of the timing of operations as our blockchain solution to deploy across our network with the use of Docker Swarm. The proposed framework leverages the containerization of Fabric so that the network can operate between the edge devices and the cloud in a single, private system. The architecture proposed in this paper lays the groundwork for further research in this area paving the way for new business models and novel, distributed applications.
For future studies, we propose that the new concept of "consensus games of IoT" that play a key role in the study of data trading under the framework of IoT associated with blockchain ecosystems would be used to establish a general framework for new business models and also novel distributed applications.

Conflicts of Interest
The author declares no conflicts of interest regarding the publication of this paper.