Optimizing Blockchains Structures Based on Entropy and TOPSIS Model ()
1. 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 which occurred by heavy cost on computation, power, and memory for every full participant in a wide network of peers. As of May 2018, the Bitcoin ledger size surpassed 196 GB (BitInfoCharts, 2018). Also, other Bitcoin limits are well-documented in works such as (Croman et al., 2016; Eyal & Sirer, 2013). For instance, as mentioned by (Vukolić, 2016) in the early days of Bitcoin, the performance of its probabilistic proof-of-work (PoW) based consensus fabric, also known as the blockchain, was not a major issue. The situation today is radically different and the poor performance scalability of early PoW blockchains no longer makes sense. Also, (Croman et al., 2016) stated that the increasing popularity of blockchain-based cryptocurrencies has made scalability a primary and urgent concern. Also, (Eyal & Sirer, 2013) believe that Bitcoin mining is vulnerable since Bitcoin’s mining protocol is not incentive-compatible. Higher revenues can lead new miners to join a selfish miner pool, a dangerous dynamic that enables the selfish mining pool to grow towards a majority. They show that at least 2/3 of the network needs to be honest to thwart selfish mining; a simple majority is not enough. These works and references notice that Bitcoin is very 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 addition, 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.
2. 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).
2.1. 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).
1) Lottery Election: Lottery election, such as Proof of Work (PoW), relies on the probability to “elect” a consensus leader who determines the order of incoming transactions, usually for a set amount of time. In Bitcoin, peer nodes append a nonce to a block and calculate the hash value. The resulting value must have some pre-determined number of leading zeros. Peers constantly hash new values in order to find the correct “answer.” The first peer to find the right nonce broadcasts its results to the network, who verifies and appends the block organized by the winning leader. This temporary leader is the one that determines the order of transactions within its announced block. In this case, the difficulty is determined by the number of leading zeros and the leader is only the leader for one block. Other lottery election examples include Proof of Stake (PoS) and Proof of Elapsed Time (PoET) (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).
2.2. 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 (Ben-Sasson et al., 2014). Private, permission Blockchain like Hyperledger Fabric (Yang & Enyeart, 2020) target enterprise applications, where businesses may want the fault tolerance and self-management offered by Blockchain within a private network. Smaller networks reduce communication overhead but tend to be less secure as a result—large, public networks have the advantage of peer numbers, where a 51 percent majority attack is more difficult to execute.
2) Block Handling: Block handling refers to methods that try to reduce Blockchain latencies, either in writing to the ledger or reading from it for transaction validation. These methods include block ordering, pruning, and ledger sharing. Block ordering can be handled in a number of ways. Bitcoin can result 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 (Gencer et al., 2016). 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.
![]()
Figure 1. Possible attack vectors on a Blockchain network. In this case, the peer node outside the inner shaded area is the only non-malicious actor.
2.3. 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.
4) Insecure Wallet Implementations: Probably the most publicized weaknesses of Blockchain networks are insecure wallet implementations (Boireau, 2018). Crypto-currency networks rely on public-private key infrastructure for transaction addressing. Possession of private keys provides proof of ownership of currency like bitcoin. These private keys can be managed by applications called wallets, which, if compromised, in turn, compromises the security of the linked currency. This vulnerability falls back upon user-end passwords and implementation design, not upon Blockchain technology itself.
2.4. 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.
3. 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) mention the need for edge devices and the leveraging of a cloud service for data persistence. Other suggestions like (Dorri et al., 2017) utilize a locally centralized design. Many approaches such as in (Aniello et al., 2017; Daza et al., 2017) suggest a layering of Blockchains to handle the delay. Edge-level devices would have a Blockchain tailored for faster verification and higher throughput of data, while higher levels could utilize more robust, yet slower consensus methods in a larger network of peers at the cloud level. The layers would be linked by some form of verification process depends on the specific framework’s algorithms. Figure 2 represented trend patterns for the blockchain-IoT framework. The use of edge computing in the IoT, as well as cloud and fog computing, can be seen on the IoT in Figure 3. Figure 3 presents an overview of the architecture which is categorized into three layers, i.e. Edge, Fog, and Cloud. As represented in Figure 3 data acquired by the sensors transmit to the edge devices. The edge layer transmits the data to the fog layer. Each fog node covers the small associated community and is responsible
![]()
Figure 2. Trend Patterns for Blockchain-IoT Frameworks.
![]()
Figure 3. Cloud, fog and edge computing in IoT environment.
for data analysis and service delivery in a timely manner. The fog layer provides localization, while the cloud layer provides wide-area monitoring and control. A fog node can access the distributed cloud over the internet to flexibly deploy the application service and computing availability. As mentioned by Sharma et al. (2017) rather than transferring raw IoT data streams to the cloud, we can locally gather, categorize, and analyze data by deploying a number of fog nodes in the IoT network. Fog computing is an emerging computing model that brings computing abilities to the edge of the distributed IoT network. This distributed computing infrastructure includes a set of physical machines with high-performance capabilities that are linked to one another this can greatly mitigate traffic in the core network and potentially speed up the processing of large amounts of IoT data.
4. 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 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.
2) Epoch Time: Peer leadership for consensus methods could last longer than the lifetime of the most recent block. This is sometimes referred to as the epoch time, which could help reduce communications by reducing the count of elections required. On the other hand, a longer epoch time in the hands of a compromised node could prove disastrous.
3) Consensus Protocol: Aniello et al. (2017) suggested using different consensus protocols at the edge versus at the cloud. Investigating changes in the consensus protocol at the edge layer could be worthwhile, especially if those changes are made to accommodate environmental changes. Such changes could involve noisier networks, spotty connections, or even momentary peer failures. 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.
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 are used in the equation of this research which is placed in the form of a table to avoid redundancy of the description. The parameters and the indexes inside the table are taken from the proposed model relationships and mathematical model defined by the author.
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.
(1)
![]()
Table 1. Proposed model main parameters.
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).
(2)
Given the fact that the confidentiality of data is possible under the conditions of Equation (1) and (2), the average difference between raw data
and the summarized data
. 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).
(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).
(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).
(5)
(6)
(7)
In Equation (5),
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 the Blockchain in IoT system. It is worth noting that the calculation of delay has been done end-to-end.
5. 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 validation from ledger block ordering into separate containers. Peer nodes carry out validation and ledger maintenance. Orderer nodes handle consensus and block broadcasting to their peers. The Fabric equivalent to smart contracts is called “chain code”. Figure 4 depicts the general framework that has been planned for use in our project. 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.
B. Sensor Device Layer: Our setup uses sensors hardwired to Raspberry Pi devices. Multiple sensors can be connected to one Pi for the sake of clarity, Figure 4 shows one sensor per edge device.
C. Edge Device Layer: We use Raspberry Pi devices for our Edge Device Layer. Each Pi is installed with a Fabric Peer Container equipped with a chain
![]()
Figure 4. Data workflow of the proposed framework.
code that packages sensor data into proper transaction format for the ledger. Figure 4 shows several bidirectional arrows pointing between peers for cleaner representation; however, connections can be assumed between any two peers in the network.
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.
6. 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.