Blockchain based consensus checking in decentralized cloud storage

Simulation Modelling Practice and Theory xxx (xxxx) xxxx

Contents lists available at ScienceDirect

Simulation Modelling Practice and Theory journal homepage: www.elsevier.com/locate/simpat

Blockchain based consensus checking in decentralized cloud storage ⁎,b

Zhiqin Zhua, Guanqiu Qi

, Mingyao Zhenga, Jian Sunc, Yi Chaid

a

College of Automation, Chongqing University of Posts and Telecommunications, Chongqing 400065, China Computer Information Systems Department, Buffalo State College, Buffalo, NY 14222, USA School of Electronic and Information Engineering, Southwest University, Chongqing 400715, China d College of Automation, Chongqing University, Chongqing 400044, China b c

ARTICLE INFO

ABSTRACT

Keywords: Blockchain Consensus Decentralized Distributed system Byzantine fault tolerance Cloud storage Cloud computing

As a popular application of cloud computing, cloud storage has been widely used. In distributed computing system, blockchain as a secure mechanism is often used to store data, such as account information, trading record, and others. Once any data is saved in blockchain, it is sealed and cannot be changed any more. All the data copies must be consistent in blockchain. In cloud computing, data is always duplicated to prevent the data loss. However, the consensus issue of different data copies may appear in various data operations. Sometimes the results of data operations may be seriously affected. As a useful technique, blockchain can effectively maintain the data consistency in a distributed computing system, including the cloud-based applications, such as cloud storage. Based on a specific type of blockchain called practical Byzantine fault tolerance (PBFT), this paper proposes a synchronous Byzantine fault tolerance (SBFT) algorithm that not only maintains the data consistency, but also has much higher efficiency than other general blockchain algorithms. In a small cloud environment, SBFT is simulated to compare with both Byzantine fault tolerance (BFT) and PBFT. The experiment results demonstrate the better performance of SBFT in data consistency, efficiency, and reliability.

1. Introduction Following the development of cloud computing, faster, cheaper, and more reliable internet access coupled with ever decreasing prices on digital storage and computing power has given viability to cloud services [1]. Here it refers to cloud services as any computer service provided on demand via the internet. All indications show that cloud services are on the rise and fundamentally changing the way that industry deploys web services and computing infrastructure. In tradition, web services are deployed on the owner’s servers. It involves the purchase and maintenance of servers. It may cost a lot on building infrastructure for the large-size deployment. Moreover, IT technicians and developers are also required to do the related maintenance and development. It incurs additional costs. Since large-size companies usually have a large number of users, they would like to pay for the related construction and maintenance costs of servers in most cases. It is worth to invest on the construction of infrastructure. At the same time, they can also manage the related data on their own end. It is helpful to keep data secure.

Corresponding author. E-mail addresses: [email protected] (Z. Zhu), [email protected], [email protected] (G. Qi), [email protected] (M. Zheng), [email protected] (J. Sun), [email protected] (Y. Chai). ⁎

https://doi.org/10.1016/j.simpat.2019.101987 Received 31 May 2019; Received in revised form 3 September 2019; Accepted 15 September 2019 1569-190X/ © 2019 Elsevier B.V. All rights reserved.

Please cite this article as: Zhiqin Zhu, et al., Simulation Modelling Practice and Theory, https://doi.org/10.1016/j.simpat.2019.101987

Simulation Modelling Practice and Theory xxx (xxxx) xxxx

Z. Zhu, et al.

In most cases, small- and mid-size companies have the limited operation budget, so it is difficult for them to build and maintain the computer infrastructure on their own end. Public cloud-based services provide more flexibility and availability, while service charges are much cheaper than the corresponding costs of traditional solutions, and the companies are free from some or all of the server-room burdens as well [2–4]. As a painful work, the related maintenance is transferred to service providers. In the era of cloud computing, small- and mid-size companies can use the relatively low IT operation costs to run the whole business. One of the many tasks being moved to cloud services is distributed computing. Within the traditional field of distributed computing, reaching agreement/consensus is a well-known problem. Examples of agreement/consensus issues include leader election/ mutual exclusion, commit or abort in distributed transactions, reaching agreement about process failures, clock phase synchronization, having multiple views from different aircraft that requires synchronization for air traffic control systems, and so on. As there are specific requirements for different situations, various solutions exist in the literature for these different scenarios [2,3]. Traditional distributed computing is extended to cloud computing. However, new consensus issues appear with the emergence of cloud computing. As a new delivery model, cloud computing provides various computing services, such as servers, storage, databases, networking, software, analytics, and more over Internet or ”cloud”. In cloud computing, the data always has multiple copies that store in different servers/locations. The multiple copies are often used in data recovery. Besides, the same work may also be processed in multiple servers/locations. Any inconsistency may cause troubles in future operation. No matter private or public cloud environment, the consistency in multiple data copies is always an issue, and may seriously affect the system performance. How can we make the multiple date copies consistent? As a classical problem in operating system, reading and writing operations are directly related to the data consistency. Existing solutions of reading and writing operations are also applicable to cloud computing. Generally, reading operation is easier than writing operation. It does not affect existing data. But writing operations, such as adding, deleting, updating and so on, always involve the changes of data. Traditionally, lock mechanism is used to manage synchronization. When a writing operation occurs, the related data is locked, and any writing operation is not allowed for the locked data. Even though lock mechanism provides good support for keeping data consistency, it is still difficult to avoid data inconsistency, when various operations are applied to the same data simultaneously. For instance, air ticket booking always has the issue of data inconsistency. Airline companies have different sales channels, such as their own websites, online third-party agents, local third-party agents, and others. Although different prevention mechanisms are applied, overbooking always happens. The same ticket may be sold to several travelers. Any query from different sales platforms may pull an available ticket that is currently in the booking process or has already been reserved. It is difficult to synchronize the data across multiple copies in real time. Before the overbooked flights take off, airline companies provide extra money or vouches for those people that would like to change their schedules. Overbooking may be acceptable by airline companies. However, the date inconsistency may cause serious issues, even irreparable disasters in large-scale transaction platforms. Blockchain techniques integrate well-known research results from distributed computing, cryptography, and game theory [5,6]. As a secure design, blockchain is resistant to data modification, and guarantees the persistence of ledger data as well. Meanwhile, it also exemplifies a distributed computing system with high BFT [7]. As a consensus algorithm, BFT can effectively keep data agreement, even though parts of data are fabricated. Based on BFT, PBFT was proposed for network file system (NFS) [8,9]. Consensus algorithms are used to analyze and handle the context of replicated state machines [10]. State machines are distributed in a set of servers to compute identical copies of same state. Even if some servers are down, the remaining state machines can still continue doing the related operations. A variety of fault tolerant problems in different distributed systems, such as Google file system (GFS) [11], Hadoop distributed file system (HDFS) [12], RAMCloud [13], and fault-diagnosis system for reciprocating compressors [14], are solved by replicated state machines. Cloud computing utilizes multiple copies of data and multiple processes for the same work [15,16]. In order to maintain the state consistency, each replica must be copied in the same order using the same operations. Even if the same data is replicated and the same work is repeated, errors can still occur for a multitude of reasons. How then does one deal with disagreeing the replicated data? This is the heart of the consensus issue. Various consensus algorithms have been proposed to handle the consistency in multiple replicas connected unreliably or asynchronously as well as any replication failure [17,18]. Consensus is the key to maintain the consistency among multiple data copies in cloud computing. The consensus synchronization can be reduced to Byzantine generals problem. Existing solutions of Byzantine generals problem can be introduced to the maintenance of consensus synchronization in blockchain [5]. Most of existing blockchain solutions, such as PBFT, assume there is no any traitorous activity. However, traitorous activity often appears in blockchain and seriously affects the maintenance of data consistency. The traitorous replica cannot be identified and processed using most of existing solutions. So this paper proposes a consensus solution based on PBFT to solve the traitor issues, which has three main contributions as follows.

• It applies blockchain techniques to analyze the consensus in cloud storage. • It proposes SBFT algorithm to do consensus checking in cloud storage, which can capture the traitorous node in the blockchain. • The proposed solution supports concurrent processing and has higher efficiency than existing solutions. This paper is extended from the previous publication on ”Blockchain based Consensus Checking in Cloud Storage”, which was published in the Proceedings of IEEE 14th International Symposium on Autonomous Decentralized Systems (ISADS) [19]. Significant extension and revisions have been included in this paper, including the followings: literature survey, proof of SBFT, technical details of implementation, and comparative experiments. The rest of this paper is structured as follows: Section 2 discusses related existing solutions; Section 3 proposes the system 2

Simulation Modelling Practice and Theory xxx (xxxx) xxxx

Z. Zhu, et al.

architecture; Section 4 introduces the proposed algorithms; Section 5 shows the mathematic proof of proposed solution; Section 6 discusses the implementation; Section 7 shows the simulation; and Section 8 concludes this paper. 2. Related work This section discusses the consensus and blockchain related work, including the failure in data replication, consensus problem, Byzantine generals problem, PBFT, and Merkle Tree. 2.1. Failure in data replication Data replication process may be affected by a number of unpredictable sources, such as communication delays, site failures, and the interaction between the ongoing transaction and operating system [20]. The availability of replicated data can also the failure in date replication. The replicated data is stored at multiple servers/sites. When a user tries to access the stored data, some copies may not be available due to the failure of server/site [21]. Messages/data may be lost, delivered out of order, or duplicated during the transmission. In general, three types of failure may occur during the process of replication. 1. Fail-stop: Nodes/actors may fail by stopping. 2. Byzantine: Nodes/actors may fail without stopping. It could be affected by arbitrary, erratic, or unexpected behavior. It may also be caused by malicious or disruptive behavior. 3. Unfaithful behavior: It is complicated. Actors may behave unfaithfully from self-interest. It could be rational, then it is Byzantine or expected. It may also be expected, but it is under control. Another possibility could be design in incentives for faithful behavior, or disincentives for unfaithful behavior. 2.2. Consensus problem The system performance and the transaction results can be directly affected by the inconsistency among different data copies. As a consensus, an agreement on a common value can be reached among multiple agents by negotiating with their neighbors [22]. So consensus is the key for multiple copies of data in cloud computing. Practical factors, such as communication constraints and actuator saturations, play a decisive role in consensus [23]. In the consensus problem, each duplicated process proposes a value. If this value is not unique, it then must choose one of these values. A solution to the consensus problem is the key to solving many problems in cloud computing such as: total order broadcasts, atomic commits, and terminating reliable broadcasts [24]. There are four main properties for correct consensus as follows.

• C1. Validity: Any value decided is a value proposed. It means that each non-faulty process must eventually decide. • C2. Agreement: No two correct processes decide differently. It means that the final decision of every non-faulty process must be identical. • C3. Termination: Every correct process eventually decides. It means that if every non-faulty process begins with the same initial value v, then their final decision must be v. • C4. Integrity: No process decides twice. Problem is specified as follows. As shown in Fig. 1, each process pk has an input value uk. These processes run a program to exchange their inputs. Finally, the outputs of all non-faulty processes become identical, even if one or more processes fail at any time. Furthermore, the output v must be equal to the value of at least one process. So consensus in synchronization can be reduced to Byzantine generals problem that can describe and solve the consensus problem on the synchronous model of communication. The Byzantine failures can be processed.

Fig. 1. Input and output of each process. 3

Simulation Modelling Practice and Theory xxx (xxxx) xxxx

Z. Zhu, et al.

Fig. 2. Process steps of PBFT.

2.3. Byzantine generals problem In computer system, a component is not independent and often involves different parts. Any failure of a component may send the conflicting information to different parts of the system. A reliable computer system must handle the failed component, which is abstracted as the Byzantine generals problem [25]. The Byzantine generals problem can be summarized as follows. Assume n generals {0, 1, 2, …, n 1} decide about whether to ”attack” or to ”retreat” during a particular phase of a war. The goal is to agree upon the same plan of action. Every general will broadcast his judgment to everyone else. These are also the inputs to the consensus protocol.

• Some generals may be ”traitors” and therefore send either no input, or send conflicting inputs to prevent the ”loyal” generals from reaching an agreement. • Devise a strategy, by which every loyal general eventually agrees upon the same plan, regardless of the action of the traitors. Every general will broadcast his judgment to everyone else. These are inputs to the consensus protocol. 2.4. PBFT In Fig. 2, PBFT algorithm [8,26] works as follows: 1. 2. 3. 4.

A client sends a request to replica 0. Replica 0 sends the request to others (e.g., replica1, replica2, replica3). Others execute the request and send a reply to the client. The client waits for f + 1 replies from different replicas with the same results, where f is the maximum number of faulty nodes; this is the deemed consensus.

PBFT has three important phases: pre-prepare, prepare, and commit [27,28]. PBFT is used to implement an NFS service resulting in a new service that is only 3% slower than a standard unreplicated NFS implementation in Digital Unix. The impressive performance is achieved by a set of important optimizations, including replacing public-key signatures by vectors of message authentication codes, reducing the size and number of messages, and incremental checkpoint-management techniques. As a foundational consensus algorithm, PBFT is used in the design of newly proposed algorithms. An egalitarian practical Byzantine fault tolerance (ePBFT) consensus algorithm was proposed to improve the consensus efficiency, in which the primary node was diluted and each node in the chain was equal and efficient [29]. Jiang proposed the high performance and scalable Byzantine fault tolerance (HSBFT) algorithm, which improved the PBFT protocol and reduced the communication complexity in the consensus process from PBFT’s O(n2) to O(n) [30]. Group-hierarchy (GH) algorithm proposed by Zhang divided all the replicas in a distributed system into several groups. Each group had its own primary node. As a local consensus, replicas in each group reach an agreement respectively. Based on the local consensus, all the primary nodes reach a global consensus [31]. 2.5. Merkle tree In cryptography and computer science, a hash tree or Merkle tree is a tree in which each non-leaf node is labeled with the hash of the labels or values (in case of leaves) of its child nodes [32–34]. Hash trees facilitate efficient and secure verification of the contents of large data structures. Hash trees are a generalization of hash lists and hash chains. Currently the main use of hash trees is to make sure that data blocks received from other peers in a peer-to-peer network are undamaged and unaltered, and even to check that the other peers do not lie and send fake blocks. The original purpose of hash trees was to make it possible to efficiently handle many Lamport one-time signatures. Each Lamport 4

Simulation Modelling Practice and Theory xxx (xxxx) xxxx

Z. Zhu, et al.

Fig. 3. Multiple data copies in cloud.

key can only be used to sign a single message. When Lamport keys are combined with hash trees, they can be used for many messages. This feature is well-suited for a blockchain system. A block in a blockchain contains many messages and the hash of each message is a leaf node, so the root hash of a Merkle tree is able to sign these messages. If any message is modified, the root hash will also change, ensuring the consistency of messages. Merkle tree was used in the design of a redactable signature scheme specialized for tree-structure data, which generates a digest of given tree-structured data using the keyed hash function [35]. Based on Merkle hash tree, Li proposed an electronic user information encryption technique in e-commerce field to solve the data vulnerability issues in the information encryption process [36]. A Merkletree-based File System (MTFS) was proposed, in which the blockchain was an abstract of a cluster system rather than only a trust machine. Without a central controller, a tree network cluster formed by distributed random node can provide secure private storage service and fast message propagation. Merkle tree ensured that the files were distributed among the service nodes in a balanced way [37]. In cloud storage, data is distributively stored over cloud. The increase and frequent update of data are two issues in data management. A large-size dataset sharing system called Picky was proposed based on Merkle tree, which allows users to download the selected portions and receive the incremental updates as well [38]. In a blockchain, all the transactions are recorded permanently. The integrity maintenance is one key technique of blockchain. A cryptographic protocol was proposed and integrated into existing blockchain solutions to record the peer transactions without any central supervision, in which Merkle tree was used to ensure the integrity of recorded transactions [39]. 3. The proposed architecture The original data may have multiple copies in cloud as shown in Fig. 3. Multiple copies may be accessed by different processors at the same time. In this section, it starts with an example to introduce the architecture used in this study. Fig. 4 shows data operations over multiple data copies in cloud. There are four clients: client0, client1, client2, and client3. There are also four databases: DB0,

Fig. 4. Data operations over multiple data copies in cloud. 5

Simulation Modelling Practice and Theory xxx (xxxx) xxxx

Z. Zhu, et al.

Fig. 5. The proposed consensus model.

DB1, DB2, and DB3, where DB0 is the primary database. Client0 writes new data into DB0, and DB0 sends an acknowledgment to client0. At the same time, the new data is also replicated in DB1, DB2, and DB3. DB1, DB2, and DB3 send acknowledgments to the primary database DB0. Client1, client2, and client3 read the data from DB1, DB2, and DB3 respectively. DB1, DB2, and DB3 respond to the reading request from client1, client2, and client3 respectively. No matter write-write or write-read requests, the proposed solution uses the locking mechanism to ensure the consensus among different data copies during the synchronization. Once a write request is processed, the related data copies are locked. Any other write or read request about these data copies is banned. When the write request finishes and the related data is synchronized over different copies, the lock is removed. Another write or read request can access these data copies. Based on existing blockchain solutions such as BFT, it now applies an SBFT algorithm to handling the Byzantine fault problem of replicated data copies. Specifically, SBFT can be used to process the concurrent operations in different data copies. This proposed consensus model shown in Fig. 5 has three important parts, such as Redis, consensus checking model, and blockchain that are explained as follows. 1. 2. 3. 4.

Messages are first sent to Redis, a cache database, to store the messages from clients temporarily. The consistency of messages is checked for all read/create/modify using the consensus checking model in Redis. The messages are then sealed into blockchain. Then it updates the corresponding duplicated copies of data and sends replies to the clients.

In general, local area network (LAN) has finite connected nodes. To achieve higher efficiency and lower latency, high-speed network actually needs to connect nodes in the system. The system can also tolerate faults. For instance, LAN may fail to deliver messages, delay them, deliver them out of order, or deliver one message repeatedly. However, LAN cannot break the related cryptographic primitives, such as cryptographic hash, message digests, and digital signatures. Let N = {n0, n1, n2, n3} denotes the set of nodes and f is the maximum number of faulty nodes. Since |N| = 4 and |N| ≥ 3f + 1 [8,26], it knows that f = 0 or 1. This paper does not consider any traitorous node in system initialization, so f cannot equal 0. If f = 1, the traitorous node can be recognized in the last phase of the proposed model, called the agree phase. Beyond using PBFT, the agree phase is an additional step in the proposed SPFT. In the agree phase, each node checks the corresponding messages from all the nodes, including itself, to check for inconsistent or traitorous nodes. Each data copy related to the corresponding message contents is checked. In real world, the operations of data requests are always changing. There may be the periods of inactivity followed by the bursts of requests. This paper uses an ”adaptable window” to collect request messages. In blockchains, two blocks are connected by a hash link that acts from the beginning of a block itself to the end of the next block. As the essential part in blockchain, Merkle Tree is typically used to create hash values [40,41]. In a Merkle Tree, all the nodes are hashed, and each leaf node is a hash of one message. Thus any tampered message causes the changes in the root hash, allowing the integrity of message to be verified. As a data storage method, the stored data cannot be easily changed in a distributed or decentralized manner, so blockchain is applied to solving the consensus issues of cloud data storage. Four main features of using blockchain for the decentralized or distributed data storage are highlighted as follows:

• A nearly 100% probability is used in the detection of any alteration, whether incidental or intentional, in stored data. • Multiple copies of the same content are stored in different sites. • A consensus protocol, such as Byzantine consensus protocol, is applied to ensuring the consistency in different data copies. • The stored information is encrypted, and thus private. 6

Simulation Modelling Practice and Theory xxx (xxxx) xxxx

Z. Zhu, et al.

Fig. 6. The process steps of SBFT.

Blockchain provides a distributed and shared database, where contents are almost impossible to be changed. With the following three functions, blockchain can efficiently and effectively maintain the integrity of stored data as legal evidence, and the corresponding consensus in different data copies.

• Real-time consensus checking: The involved data is collected in real time. Any data operation in the system cannot bypass the • •

consensus checking mechanism. For example, when a query is sent to access one copy of data, the system checks the other copies of corresponding data to make sure the consensus is reached in all copies before doing data operations. Otherwise, the query cannot be processed unless the related data passes the consensus checking. Data operation monitoring: It tracks all the data operations. Not only the beginning of each data operation, but also all the related key steps in the data operation are recorded. So any inconsistency can be traced to figure out the corresponding issue. That is, any reading, writing, or modifying operation in data is monitored and recorded. Unchangeable data: Any change in recorded data can be detected within blockchain. It avoids the unattended inconsistency that might occur in copies.

4. Algorithms in SBFT As shown in Fig. 6, the proposed SBFT has four unique phases: preprocess, process, vote, and agree. M = {m 0, m1, m2, …, mi , …} is used to denote a set of messages, where mi represents any message from client c, and i is an integer from 0 to ∞. Within one phase, multiple operations can be processed concurrently. The details of proposed SBFT are specified as follows:

• Request: Client c sends M to n , ..., n . • Preprocess: It denotes Mn = {m n , …, m n , …}, which represents each message m in n . It assumes there are unexpected faults 0

0

•

•

3

0

0

i

i

0

0

and delays during the transmission. So each mi in n0, ..., n3 is not same, as min0 ≠ min1 ≠ min2 ≠ min3. Then n0 creates a bitarray whose element is a bit and maps Mn0 into the bitarray. It means each element of min0 is converted to a bit of bitarray correspondingly and its bit value becomes 1. After mapping, the bitarray is called ⟨bitarray⟩Mn0. Similarly, n1, n2, and n3 yield corresponding bitarray respectively. Then n0, ..., and n3 send each bitarray to others. Process: every node needs to elect a primary node. It defines commonbitarray = bitarray Mn 0 bitarray Mn1 bitarray Mn2 = bitarray Mn 0 bitarray Mn1 bitarray Mn3 = bitarray Mn 0 bitarray Mn2 bitarray Mn3 = bitarray Mn1 bitarray Mn2 bitarray Mn3 The overlap of all the bitarrays is obtained. According to PBFT, the number of bitarray is greater than or equal to 3. So it can tolerate a faulty node. Possibly, n0 may not get the bitarray of faulty node. Then only primary node n0 needs to get ⟨commonbitarray⟩. ⟨commonbitarray⟩ obtained by n0 is denoted by ⟨commonbitarray⟩n0. After that, n0 collects m corresponding messages to ⟨commonbitarray⟩n0 and seals m in block_body and fills block_header. Then n0 sends the block to others. Vote: Each node identifies the block and determines whether the block is accepted or not (shown in Section 6). ni sends vote message D(ni)(〈vote: value〉ni) to other nodes. ni represents any node in N. D(ni)(〈vote: value〉ni) represents the digest of 〈vote: value〉ni. A value is true or false that is directly related to whether ni accepts the block or not. It uses the digital signature to guarantee the authentication of messages. According to the corresponding public key, all the nodes can verify each digital 7

Simulation Modelling Practice and Theory xxx (xxxx) xxxx

Z. Zhu, et al.

Require: request messages from each client Ensure: replies to each request from every node 1: while true do phase 1: 2: 3: client c sends m to n0 , …, n3 phase 2: 4: ni maps m to hbitarrayini 5: 6: ni sends hbitarrayini to others 7: phase 3: ni calculates hcommonbitarrayi 8: 9: ni creates block according to hcommonbitarrayi 10: ni sends the created block to others phase 4: 11: 12: ni votes for each block 13: ni sends D(ni )(hvote : valueini ) to others phase 5: 14: 15: ni calculates D(ni )(hvoteini ) 16: ni identifies traitorous node 17: end while Algorithm 1. The Proposed SBFT Algorithm.

signature from other nodes.

• Agree: In the proposed SBFT, n has four D(n )(〈vote: value〉n ) messages in total, including itself. Then n decrypts these messages i

i

i

with private key respectively. It denotes the decrypted four messages as a set by

i

vote ni = { vote: value n 0, vote: value n1, vote: value n2, vote: value n3}.

•

ni sends D(ni)(〈vote〉ni) to other nodes. Similarly, the other three nodes also have four D(ni)(〈vote〉ni) messages. Then they decrypt and check the message contents of each 〈vote〉ni. If they find that a node sent different messages 〈vote: value〉ni to different nodes, this node is identified as a traitorous node (shown in Section 6). Reply: Finally, all the nodes send replies to client c. If client c gets the total f + 1 replies from different nodes with the same results, client c must accept the message contents of these replies.

An error may occur in the data copy during the process of data storage. In the proposed SBFT, there are total four data copies consisted of a primary one and three copies. If any three data copies do not have any error, no matter what happened to the other one copy, SBFT can still process the corresponding operations. Only if all the three copies reach the consensus, the decision can be made and the error one can be recovered as well. Otherwise, it cannot decide the results based on the majority vote. In this case, it must redo the previous operations. Similarly, if more than one data copy have errors, the previous operations must be redone. According to PBFT, if one node receives three messages from other nodes in each phase from second to fifth phase, it keeps on running. Otherwise the node stops running. Assuming |N| = 4, the proposed SBFT algorithm shown in Algorithm 1 can tolerate one faulty node that cannot send or receive messages. In the preprocess phase, a message m is regarded as a string, and then the string is converted to an integer by proposed mapping algorithm shown in Algorithm 2. Finally, the integer is mapped to an element of a bit array. In the process phase, each node needs to elect a primary node, and only primary node can create a block. The primary node is elected by the following hash function. (1)

n = Hash (height + + round )%|N |

where height is the id of current block, and the initial round is 0. If all the nodes accept the current block, and the number of nodes is less than |N|-f, the value of round increases 1. 5. Proof of SBFT According to the above discussion, SBFT is proposed based on PBFT. In the proposed SBFT, preprocess is a completely new phase, and the other three main phases correspond to the three main phases of PBFT (shown in Fig. 2). Process, vote, and agree are corresponding to pre-prepare, prepare, and commit in PBFT respectively. It means that process, vote, and agree is a PBFT. As PBFT was proved [9], this paper does not need to prove process, vote, and agree phases. So it only needs to prove that preprocess 8

Simulation Modelling Practice and Theory xxx (xxxx) xxxx

Z. Zhu, et al.

Require: a string Str Ensure: a bit array bitArray 1: int hash(String Str) 2: h = Str.hashCode(); //hashCode is a Java API 3: return (Str==null)? 0 : h 4: int index = hash(Str)%bitArray_length 5: int r = index/8 6: int w = index%8 7: byte bitArray[r] = (byte)(bitMap[r] | ((byte)(Math.pow(2,w)))) 8: return bitArray Algorithm 2. Mapping Algorithm.

phase fits the other three main phases for the proof of SBFT. The proof process is reduced to prove that it can accurately get common messages in preprocess phase. The set of messages is denoted as M = {m 0, m1, m2, …, mi , …}, where mi represents one message, and i is an integer from 0 to ∞. It assumes that a client sends M to four nodes: n 0 , n1, n2 and n3 . The messages received by n 0 are denoted as Mn 0 = {m 0n 0, m1n 0, m2n 0, …, mi n 0 , …} . Similarly, the messages received by n1, n2 and n3 are denoted as Mn1 = {m 0 n1, m1n1, m2 n1, …, mi n1, …}, Mn2 = {m 0 n2, m1n2, m2n2, …, mi n2, …}, Mn3 = {m 0 n3 , m1n3, m2 n3, …, mi n3 , …} . Since the same set of messages is sent to four nodes, Mn 0 = Mn1 = Mn2 = Mn3 . As a client may fail to deliver messages, delay messages, deliver messages out of order, or deliver one message repeatedly, each node may receive different messages. It assumes that messages in each node are not exactly same. So it is denoted as min0 ≠ min1 ≠ min2 ≠ min3. Next, each node uses Alg. 2 to generate one bitarray respectively based on Mn 0, Mn1, Mn2, and Mn3. The generated bitarrays are denoted as ⟨bitarray⟩Mn0, ⟨bitarray⟩Mn1, ⟨bitarray⟩Mn2, and ⟨bitarray⟩Mn3. Alg. 2 can map one message to an element of bitarray uniquely, so the generated bitarrays can represent the corresponding sets of messages. For each mi of M in node n 0 to n3, it generates corresponding bitarray, such as ⟨bitarray⟩min0, ⟨bitarray⟩min1, ⟨bitarray⟩min2, and ⟨bitarray⟩min3. Each message mi n3 n0 of M in node to generates corresponding bitarray, such as bitarray mi n 0 = bitarray mi n1 = bitarray mi n2 = bitarray mi n3. In preprocess phase, these messages are not changed. It assumes n 0 as the primary node in process phase. n 0 needs to find the overlap of different messages to seal in a block. As the bitarrays represent the messages, so it needs to find the overlap of bitarrays. Since Mn 0 = Mn1 = Mn2 = Mn3, it gets the following equation. bitarray Mn 0 = bitarray Mn1 = bitarray Mn2 = bitarray Mn3 According to the defined ⟨commonbitarray⟩ in Section 4, PBFT can tolerate a faulty node in four nodes, so ⟨commonbitarray⟩ as the overlap of bitarrays only needs to extract at least three bitarrays from four nodes. Then n 0 gets the common messages from clients based on ⟨commonbitarray⟩ correspondingly. It gets the following results. bitarray Mn 0 = bitarray Mn 0 bitarray Mn1 bitarray Mn2 = bitarray Mn 0 bitarray Mn1 bitarray Mn3 = bitarray Mn 0 bitarray Mn2 bitarray Mn3 = bitarray Mn1 bitarray Mn2 bitarray Mn3 Based on the definition of M, it extends the above equations. bitarray Mn 0 = bitarray (m 0, m1, …, mi, …) n 0 bitarray (m 0, m1, …, mi, …) n1 bitarray (m 0, m1, …, mi , …) n2 = bitarray m 0 n 0 bitarray m 0 n1 bitarray m 0 n2 bitarray m1n 0 bitarray m1n1 bitarray m1n2 … bitarray mi n 0 bitarray mi n1 bitarray mi n2 … = commonbitarray m 0 commonbitarray m1… commonbitarray mi … Similarly, the other three equations can also be extended. When ⟨bitarray⟩Mn0 is processed by PBFT in a sequential way, it gets the following results. bitarray Mn 0 = bitarray (m 0, m1, …, mi, …) n 0 = bitarray m 0 n 0 bitarray m1 n 0 … bitarray mi n 0… … 9

Simulation Modelling Practice and Theory xxx (xxxx) xxxx

Z. Zhu, et al.

⟨bitarray⟩m0n0 to ⟨bitarray⟩min0 in PBFT have their corresponding components ⟨commonbitarray⟩m0 to ⟨commonbitarray⟩ mi in SBFT. The concurrent processing does not affect the results. The preprocess phase is compatible with the other three main phases in SBFT. n0 can get the common messages, create a new block, and seal them in the created block. It maintains the consistency of messages. After that, messages are sent to other nodes. Then the consensus checking is processed in the vote phase. 6. Implementation 6.1. The proposed blockchain structure The proposed SBFT-based system uses many blocks to implement a blockchain. A block has two parts: Block_header and Block_body. Block_header consists of the following components: 1. Id: the index of a block, it starts from 0 and increases by 1. 2. Hash: the hash value of Block_header except Hash. It means all the items, except Hash, concatenate together in a certain order. It calculates a hash value of the concatenated items. Then it fills the hash into an item Hash. 3. Pre_Hash: the Hash in previous block. 4. Timestamp: the time of creating block. 5. Merkleroot: the value of Merkle tree’s root. 6. Length: the number of messages in the block. In the proposed system, a new block is added to the tail of last block. The chain is a hash that links a block to next one. Due to a large number of transactions, hash collision may not be evitable. The separate chaining is used to solve the collision issue in the proposed solution. In the vote phase, each node must identify the block and decide whether it accepts or not by checking the above components. A block is accepted, when it satisfies the following conditions: 1. Id is one greater than the previous block Id. 2. Timestamp is less than the previous block Timestamp. Block_body is a collection of messages. There is a link from Hash to Pre_Hash. Fig. 7 shows the structure of the blockchain. 6.2. Merkle tree structure Hash is the next block’s Pre_Hash. Merkleroot is the root of Merkle tree. In Merkle tree, each leaf node is a hash of one message and any other node is a hash value. It means Merkleroot changes, if a message is tampered. Merkle tree can keep the data untampered. Fig. 8 shows the structure of Merkle tree. The proposed system uses four servers and treats each one as a node. All four servers run in the same environment simultaneously. HTTP and Redis are used as the communication mode and a temporary storage to receive messages. 6.3. Adaptable window In this paper, adaptable window is used to collect messages from Redis adaptively. Adaptable window not only determines the capacity of Block_body, but also guarantees that Block_body is not empty and not greater than a certain value (the certain value is chosen, according to the system efficiency). To implement adaptable window, it should check whether Redis is empty or the number of messages is less than a certain value W (W is the minimum number of messages in block, e.g. W = 500). If yes, it does nothing, but waits for a time interval called TI (e.g. TI = 2 s). If the interval finishes, a variable wait_time is added by 1. In the following intervals, if Redis is not empty and the value of wait_time is greater than a certain value WT (WT is the number waiting times, e.g. WT = 5 s), or the number of messages is greater than W, it grabs the messages and seals them in a block. Adaptable window guarantees the block size is appropriate, i.e. Block_body is not empty and not too large. Empty Block_body is meaningless and oversize Block_body reduces

Fig. 7. The proposed blockchain structure. 10

Simulation Modelling Practice and Theory xxx (xxxx) xxxx

Z. Zhu, et al.

Fig. 8. Merkle tree structure.

Require: message Ensure: a suitable set of messages 1: wait_time = 0 2: while set.size < W do 3: set.add(messages) 4: wait(T I) 5: wait_time 6: if set.size ≥ W k (set.size > 0 && wait_time > WT ) then 7: break 8: end if 9: end while 10: return set Algorithm 3. Adaptable Window Algorithm. Table 1 Benchmark. Benchmark

µ (s 1)

σ

Sign Verify

249.117 4947.813

11.491 22.697

the system efficiency. Adaptable window is implemented as Algorithm 3. 6.4. Reputation Each node maintains a list that represents the reputation of each node. The reputation value is used to identify the traitorous node. A node reputation value Re(nj) = 0.6 is initialized as the threshold. At the end of agree phase, all the nodes update the list as follows: 1. If 〈vote: value〉ni ∈ 〈vote〉nj ≠ 〈vote: value〉ni ∈ 〈vote〉n j where n j are nodes that exclude nj, then Re(nj) = 0, i.e., nj is a traitor. 2. If value = false in any 〈vote: value〉ni then Re(ni) = Re(ni) * (1−0.05) (0.05 is used as reputation deduction value). Until Re(ni) less than 0.6 then ni is a traitor. 3. If value = true in any 〈vote: value〉ni then Re(ni) = Re(ni) * (1+0.05). If updated Re(ni) more than 1, Re(ni) could be set to 1. It must check whether one node is a traitor. 11

Simulation Modelling Practice and Theory xxx (xxxx) xxxx

Z. Zhu, et al.

Fig. 9. The relationship between latency and blocks – SBFT.

Fig. 10. The relationship between latency and blocks – PBFT.

7. Comparative experiments In this section, the proposed SBFT is compared with PBFT and BFT, that involves the analysis of communication results and the evaluation of efficiency. According to the theoretical communication analysis of SBFT algorithm in Section 4, it assumes N is the number of nodes in the comparative experiments. In the preprocess phase, a node sends messages to other N 1 nodes. So one node communicates N 1 messages, and N nodes communicate N (N 1) messages in total. Similarly the vote and agree phase have the 12

Simulation Modelling Practice and Theory xxx (xxxx) xxxx

Z. Zhu, et al.

Fig. 11. The relationship between latency and blocks – BFT.

Fig. 12. The relationship between latency and blocks comparison – 2000/s.

same number of communications. But process phase is different. In process phase, only the primary node sends messages to other N 1 nodes. Other nodes do not send any messages. So the process phase only communicates N 1 messages in total. So the total number of messages in four phases is N (N 1) + N (N 1) + N (N 1) + (N 1) = (3N + 1)(N 1) . For each node, the average number of messages is (3N + 1)(N 1)/N . Due to the limitations of computation resources and real transaction data, the comparative experiments are simulated in a small cloud environment that consists of four same servers. Each server is equipped with an Intel Core i7-7700 3.60 GHz CPU (4 cores and 8 13

Simulation Modelling Practice and Theory xxx (xxxx) xxxx

Z. Zhu, et al.

Fig. 13. The relationship between latency and blocks comparison – 5000/s.

Fig. 14. The relationship between latency and blocks comparison – 8000/s.

threads), 32GB RAM, and 64-bit Windows 10. Additionally, Mysql database is used to store logging information of created blockchain. The proposed SBFT based system is implemented by Java in Spring Boot framework. Each block size is 1MB. The transaction information is randomly generated, which contains transaction ID, amount, time stamp, and so on. SBFT, PBFT, and BFT are applied to the same transaction information. The basic cryptographic operations in the experiment including Sign and Verify are implemented with JAVA API RSA-1024. Table 1 illustrates the mean and standard deviation of Sign and Verify operations in per second. 14

Simulation Modelling Practice and Theory xxx (xxxx) xxxx

Z. Zhu, et al.

Fig. 15. The relationship between latency and blocks comparison – 10000/s.

Fig. 16. The relationship between latency and messages – SBFT.

The relationship between latency and blocks/messages and the latency of generating blocks are explored in the comparative experiments. In the experiments, it sets W = 10000, TI = 2 s, and WT = 10 s for adaptable window as the initial settings. Fig. 5 illustrates that the number of blocks if one client sends messages at different frequencies (1000, 2000, 5000, and 10,000 messages per second) and repeats the sending operation 100 times. When W, TI, or WT changes, the corresponding performance also changes. For instance, TI and WT keep as same as the initial settings and W changes to 5000. The maximum number of messages in each block is 5000 now. When W decreases from 10,000 to 5000, the number of messages stored in blockchain also decreases. Practically, the initial values should be set based on the frequency of received messages and the total number of messages. If messages are sent to 15

Simulation Modelling Practice and Theory xxx (xxxx) xxxx

Z. Zhu, et al.

Fig. 17. The relationship between latency and messages – PBFT.

Fig. 18. The relationship between latency and messages – BFT.

Redis slowly enough, it may not even need adaptable window. However, if the number of received messages is large enough and messages arrive successively, adaptable window is indispensable and can avoid the overload in proposed SBFT based system. As shown in Fig. 9, the two upper lines are nearly overlapping. It means if messages come in a high speed (e.g. 10000/s), adaptable window delays the creation of new block to reach the balanced status with higher efficiency (e.g. 8000/s). So the threshold of processing speed is closely related to W, TI and WT. For PBFT and BFT, the corresponding relationships between latency and blocks are shown in Figs. 10 and 11 respectively. Figs. 12–15 compare the relationship between latency and blocks at 2000/s, 5000/s, 8000/ s, and 10000/s respectively. For the same latency, the number of blocks created by PBFT is smaller than the proposed SBFT, and BFT has the smallest number of created blocks. Besides the small number of blocks, the number of blocks created by BFT fluctuates a lot, 16

Simulation Modelling Practice and Theory xxx (xxxx) xxxx

Z. Zhu, et al.

Fig. 19. The relationship between latency and messages comparison – 2000/s.

Fig. 20. The relationship between latency and messages comparison – 5000/s.

when the speed reaches 8000/s and 10000/s. The number of messages in each fresh generated block in the same scenario is shown in Fig. 16. The messages are sealed in Block_body introduced in Section 6. The capacity of Block_body is a key element of all blockchain systems. If Block_body is too thin and small, this will waste the computing resource and reduce efficiency. The reason is that blockchain system can only store few messages in a short period. Fig. 16 shows that the capacity of Block_body is almost located in a suitable interval by using adaptable window. This makes the blocks are the nearly same size as others. For PBFT and BFT, the corresponding relationships between latency and messages are shown in Figs. 17 and 18 respectively. Figs. 19–22 compare the relationship between latency and messages at 2000/s, 5000/s, 8000/s, and 10,000/s respectively. For the same latency, SBFT and BFT has the largest and smallest number of 17

Simulation Modelling Practice and Theory xxx (xxxx) xxxx

Z. Zhu, et al.

Fig. 21. The relationship between latency and messages comparison – 8000/s.

Fig. 22. The relationship between latency and messages comparison – 10000/s.

generated messages respectively. When the speed is 2000/s, the number of generated messages for SBFT, PBFT, and BFT is between 5000 and 7000. SBFT is better than PBFT, and PBFT is better than BFT. When the speed increases to 5000/s–10,000 s, there is a big difference in the number of generated messages among three methods. For SBFT, the max number can be reached is 14,000, and the average number is above 12,000. For BFT, the number is between 85,000 and 11,000. PBFT’s performance is between SBFT and BFT. When the speed increases, the number of messages also increases. It is necessary to know the latency time of building one block shown in Fig. 23. As the adaptable window, the latency is located in an interval, and at some time the latency is 0. The reason is that when the latency is less than one second, it regards the latency as 18

Simulation Modelling Practice and Theory xxx (xxxx) xxxx

Z. Zhu, et al.

Fig. 23. The latency of generating blocks – SBFT.

Fig. 24. The latency of generating blocks – PBFT.

zero. Actually the latency is not zero, but a few milliseconds. According to the experiment results shown in Fig. 23, when the frequency of sending messages increases, the latency of generating blocks decreases at a certain time. The reason is the parameters of adaptable window. In Algorithm 3, it learns that if the number of messages is less than W, the node should wait. If it is larger than W, the node is not necessary to wait and begins to build the block immediately. So the latency may be very small. For PBFT and BFT, the latencies of generating blocks are shown in Figs. 24 and 25 respectively. Figs. 26–29 compare the latencies of generating blocks at 2000/s, 5000/s, 8000/s, and 10,000/s respectively. When the speed increases, the amplitude of latency in generating blocks 19

Simulation Modelling Practice and Theory xxx (xxxx) xxxx

Z. Zhu, et al.

Fig. 25. The latency of generating blocks – BFT.

Fig. 26. The latency of generating blocks comparison – 2000/s.

increases. Comparing PBFT and BFT, the corresponding amplitude of SBFT is smaller. 8. Conclusion and future work This paper constructed an algorithm called SBFT for the consensus checking in cloud data storage. Based on the traditional PBFT system, SBFT provided a reliable mechanism to build the trust during the data duplication. The involved data was safely stored in a tamper-resistant blockchain. Any inconsistency in the duplicated copies can be successfully detected and identified by SBFT. The 20

Simulation Modelling Practice and Theory xxx (xxxx) xxxx

Z. Zhu, et al.

Fig. 27. The latency of generating blocks comparison – 5000/s.

Fig. 28. The latency of generating blocks comparison – 8000/s.

mathematical analysis and comparative experiment results confirmed that the proposed solution achieved high efficiency and reliability in consensus checking. Blockchain will be the fundamental technique for the future development of Internet. As the core technique of blockchain, the performance BFT system directly affects the reliability and efficiency of blockchain. So the proposed blockchain solution will be improved in the following two aspects.

• The proposed solution uses HTTP protocol to transmit messages. In a reliable P2P communication channel, TCP protocol can be 21

Simulation Modelling Practice and Theory xxx (xxxx) xxxx

Z. Zhu, et al.

Fig. 29. The latency of generating blocks comparison – 10,000/s.

used in socket programming to improve the efficiency of current transmission efficiency.

• With the development of computational law, smart contract will be embedded in blockchain to ensure the stored data cannot be tampered by anyone.

References [1] W. Tsai, G. Qi, DICB: dynamic intelligent customizable benign pricing strategy for cloud computing, Proceedings of 5th IEEE International Conference on Cloud Computing, Honolulu, HI, USA, June 24–29, 2012, (2012), pp. 654–661. [2] W.T. Tsai, G. Qi, Y. Chen, A cost-effective intelligent configuration model in cloud computing, 2012 32nd International Conference on Distributed Computing Systems Workshops, (2012), pp. 400–408. [3] W.T. Tsai, G. Qi, Y. Chen, Choosing cost-effective configuration in cloud storage, 2013 IEEE Eleventh International Symposium on Autonomous Decentralized Systems (ISADS), (2013), pp. 1–8. [4] Y. Chen, Service-Oriented Computing and System Integration: Software, IoT, Big Data, and AI as Services, sixth ed., Kendall Hunt Publishing, 2018. [5] V. Gramoli, From blockchain consensus back to byzantine consensus, Future Gener. Comput. Syst. (2017). [6] A. Panarello, N. Tapas, G. Merlino, F. Longo, A. Puliafito, Blockchain and IoT integration: a systematic survey, Sensors 18 (8) (2018) 2575. [7] K. Driscoll, B. Hall, H. Sivencrona, P. Zumsteg, Byzantine fault tolerance, from theory to reality, Computer Safety, Reliability, and Security, Springer, Berlin, Heidelberg, 2003, pp. 235–248. [8] M. Castro, B. Liskov, Practical byzantine fault tolerance, Proceedings of the Third Symposium on Operating Systems Design and Implementation, OSDI ’99, (1999), pp. 173–186. [9] M. Castro, B. Liskov, A Correctness Proof for a Practical Byzantine-Fault-Tolerant Replication Algorithm, Technical Report, Massachusetts Institute of Technology, 1999. [10] F.B. Schneider, Implementing fault-tolerant services using the state machine approach: a tutorial, ACM Comput. Surv. 22 (4) (1990) 299–319. [11] S. Ghemawat, H. Gobioff, S.-T. Leung, The google file system, SIGOPS Oper. Syst. Rev. 37 (5) (2003) 29–43. [12] K. Shvachko, H. Kuang, S. Radia, R. Chansler, The hadoop distributed file system, Proceedings of the 2010 IEEE 26th Symposium on Mass Storage Systems and Technologies (MSST), MSST ’10, (2010), pp. 1–10. [13] J. Ousterhout, P. Agrawal, D. Erickson, C. Kozyrakis, J. Leverich, D. Mazières, S. Mitra, A. Narayanan, G. Parulkar, M. Rosenblum, S.M. Rumble, E. Stratmann, R. Stutsman, The case for ramclouds: scalable high-performance storage entirely in dram, SIGOPS Oper. Syst. Rev. 43 (4) (2010) 92–105. [14] G. Qi, Z. Zhu, K. Erqinhu, Y. Chen, Y. Chai, J. Sun, Fault-diagnosis for reciprocating compressors using big data and machine learning, Simul. Model. Pract. Theory 80 (2018) 104–127. [15] G. Qi, W. Tsai, W. Li, Z. Zhu, Y. Luo, A cloud-based triage log analysis and recovery framework, Simul. Model. Pract. Theory 77 (2017) 292–316. [16] W. Tsai, W. Li, G. Qi, LTBD: a triage framework, 2016 IEEE Symposium on Service-Oriented System Engineering, SOSE 2016, Oxford, United Kingdom, March 29–April 2, 2016, (2016), pp. 91–100. [17] M. Castro, B. Liskov, A Correctness Proof for a Practical Byzantine-Fault-Tolerant Replication Algorithm, Technical Report, (1999). Cambridge, MA, USA [18] D. Ongaro, J. Ousterhout, In search of an understandable consensus algorithm, Proceedings of the 2014 USENIX Conference on USENIX Annual Technical Conference, USENIX ATC’14, (2014), pp. 305–320. [19] G. Qi, Z. Zhu, M. Haner, J. Sim, J. Sun, Y. Chai, Y. Chen, Y. Li, Blockchain based consensus checking in cloud storage, 14th International Symposium on Autonomous Decentralized Systems (ISADS), April 8–10, 2019, Utrecht, the Netherlands, (2019). [20] U. Shanker, M. Misra, A.K. Sarje, Distributed real time database systems: background and literature review, Distrib. Parallel Databases 23 (2) (2008) 127–149. [21] V. Hadzilacos, S. Toueg, Distributed Systems, (second ed.), ACM Press/Addison-Wesley Publishing Co., New York, NY, USA, 1993, pp. 97–145. [22] W. Ren, R.W. Beard, E.M. Atkins, A survey of consensus problems in multi-agent coordination, Proceedings of the 2005, American Control Conference, 2005. 3 (2005), pp. 1859–1864. [23] H. Gao, T. Chen, J. Lam, A new delay system approach to network-based control, Automatica 44 (1) (2008) 39–52.

22

Simulation Modelling Practice and Theory xxx (xxxx) xxxx

Z. Zhu, et al.

[24] E.A. Alchieri, A.N. Bessani, J. Silva Fraga, F. Greve, Byzantine consensus with unknown participants, Proceedings of the 12th International Conference on Principles of Distributed Systems, OPODIS ’08, Springer-Verlag, Berlin, Heidelberg, 2008, pp. 22–40. [25] L. Lamport, R. Shostak, M. Pease, The byzantine generals problem, ACM Trans. Program. Lang. Syst. 4 (3) (1982) 382–401. [26] X. Hao, L. Yu, L. Zhiqiang, L. Zhen, G. Dawu, Dynamic practical byzantine fault tolerance, 2018 IEEE Conference on Communications and Network Security (CNS), (2018), pp. 1–8. [27] N. Chondros, K. Kokordelis, M. Roussopoulos, On the practicality of practical byzantine fault tolerance, Middleware 2012, Springer, Berlin, Heidelberg, 2012, pp. 436–455. [28] L. Ren, K. Nayak, I. Abraham, S. Devadas, Practical synchronous byzantine consensus, CoRR (2017). abs/1704.02397 [29] L. He, Z. Hou, An improvement of consensus fault tolerant algorithm applied to alliance chain, 2019 IEEE 9th International Conference on Electronics Information and Emergency Communication (ICEIEC), (2019), pp. 1–4. [30] Y. Jiang, Z. Lian, High performance and scalable byzantine fault tolerance, 2019 IEEE 3rd Information Technology, Networking, Electronic and Automation Control Conference (ITNEC), (2019), pp. 1195–1202. [31] L. Zhang, Q. Li, Research on consensus efficiency based on practical byzantine fault tolerance, 2018 10th International Conference on Modelling, Identification and Control (ICMIC), (2018), pp. 1–6. [32] H. Li, R. Lu, L. Zhou, B. Yang, X. Shen, An efficient Merkle-tree-based authentication scheme for smart grid, IEEE Syst. J. 8 (2) (2014) 655–663. [33] J. Buchmann, L.C.C. García, E. Dahmen, M. Döring, E. Klintsevich, Cmss – an improved merkle signature scheme, in: R. Barua, T. Lange (Eds.), Progress in Cryptology – INDOCRYPT 2006, Springer, Berlin, Heidelberg, 2006, pp. 349–363. [34] M.S. Niaz, G. Saake, Merkle hash tree based techniques for data integrity of outsourced data. GvD, volume 1366 of CEUR Workshop Proceedings, CEUR-WS.org, 2015, pp. 66–71. [35] S. Hirose, H. Kuwakado, Redactable signature scheme for tree-structured data based on Merkle tree, 2013 International Conference on Security and Cryptography (SECRYPT), (2013), pp. 1–8. [36] Q. Li, Research on e-commerce user information encryption technology based on Merkle hash tree, 2019 International Conference on Robots Intelligent System (ICRIS), (2019), pp. 365–369, https://doi.org/10.1109/ICRIS.2019.00098. [37] J. Kan, K.S. Kim, Mtfs: Merkle-tree-based file system, 2019 IEEE International Conference on Blockchain and Cryptocurrency (ICBC), (2019), pp. 43–47, https:// doi.org/10.1109/BLOC.2019.8751389. [38] D. Hintze, A. Rice, Picky: Efficient and reproducible sharing of large datasets using merkle-trees, 2016 IEEE 24th International Symposium on Modeling, Analysis and Simulation of Computer and Telecommunication Systems (MASCOTS), (2016), pp. 30–38, https://doi.org/10.1109/MASCOTS.2016.25. [39] S. Dhumwad, M. Sukhadeve, C. Naik, M. KN, S. Prabhu, A peer to peer money transfer using SHA256 and Merkle tree, 2017 23RD Annual International Conference in Advanced Computing and Communications (ADCOM), (2017), pp. 40–43, https://doi.org/10.1109/ADCOM.2017.00013. [40] R.C. Merkle, Protocols for public key cryptosystems, 1980 IEEE Symposium on Security and Privacy, (1980). 122–122 [41] S. Nakamoto, Bitcoin: apeer-to-peer electronic cash system, ”http://bitcoin.org/bitcoin.pdf”, 2008.

23