A Lightweight Blockchain Scheme for a Secure Smart Dust Iot Environment

applied sciences

Article A Lightweight Blockchain Scheme for a Secure Smart Dust IoT Environment

Joonsuu Park and KeeHyun Park * Department of Computer Engineering, Keimyung University, Daegu 42601, Korea; [email protected] * Correspondence: [email protected]; Tel.: +82-53-580-5266

Received: 28 September 2020; Accepted: 12 December 2020; Published: 14 December 2020

Abstract: Since a smart dust Internet of Things (IoT) system includes a very large number of devices sometimes deployed in hard-access areas, it is very diﬃcult to prevent security attacks and to alleviate bottleneck phenomena. In this paper, we propose a lightweight blockchain scheme that helps device authentication and data security in a secure smart dust IoT environment. To achieve our goals, (1) we propose the structure of the lightweight blockchain and the algorithm of processing the blockchain. In addition, (2) we reorganize the linear block structure of the conventional blockchain into the binary tree structure in such a way that the proposed blockchain is more eﬃcient in a secure smart dust IoT environment. Experiments show that the proposed binary tree-structured lightweight blockchain scheme can greatly reduce the time required for smart dust device authentication, even taking into account the tree transformation overhead. Compared with the conventional linear-structured blockchain scheme, the proposed binary tree-structured lightweight blockchain scheme achieves performance improvement by up to 40% (10% in average) with respect to the authentication time.

Keywords: Internet of Things; blockchain; lightweight; security; smart dust; authentication

1. Introduction Smart dust is the concept of smart dust which sprays dust-like tiny sensors on physical spaces such as buildings, roads, clothing, and the human body in order to detect information such as ambient temperature, humidity, acceleration, and pressure over the wireless network [1–3]. Smart dust is a network in which very small devices communicate organically, which can be thought of as an Internet of Things (IoT) [2–7] that deals with very small devices. That is, a smart dust IoT system can be considered as one of the special IoT systems dealing with smart dust devices which have very low computing power/resources and a very small size [1,2,8,9]. There have been many studies on security issues for IoT systems [10–13]. However, few studies have been done for the secure smart dust IoT system, although a smart dust IoT system is much more vulnerable to security attacks since smart dust devices have very limited computing power. For example, smart dust devices refer to devices that have very low communication speed and a small memory of less than 1 kb [14]. That is, the enormous amount of smart dust devices in a smart dust IoT environment can easily be exposed to widely known security attacks. In a smart dust IoT environment, where a very large number of devices collect data, unauthorized devices can interfere with data collection, resulting in data contamination. In general, a blockchain is considered one of the good solutions to data reliability problems such as data forgery and tampering [15–17]. We introduced the concept of a blockchain into a smart dust IoT environment to solve the problems of authentication and data security. However, a blockchain constitutes linear chaining for the veriﬁcation of ledgers, and unfortunately, the veriﬁcation speed of ledgers is proportional to the number of nodes participating in the chain [18]. Since a smart dust IoT

Appl. Sci. 2020, 10, 8925; doi:10.3390/app10248925 www.mdpi.com/journal/applsci Appl. Sci. 2020, 10, 8925 2 of 18 environment assumes hundreds of millions of devices, it would experience a significant slowdown when using a conventional or pure blockchain scheme that has proof-of-work-based proof and linear chaining configuration. Therefore, in this paper, we propose a lightweight blockchain scheme that helps device authentication and data security in a secure smart dust IoT environment. To achieve our goals, we reorganize the linear block structure of the conventional blockchain into a binary tree structure and lighten the blockchain operations to be efficient in a secure smart dust IoT environment. That is, we propose a simplified tree structure for Directed Acyclic Graph (DAG) and a tree transform structure required for the system. Experiments show that the proposed binary tree-structured lightweight blockchain scheme can greatly reduce the time required for smart dust device authentication, even taking into account the tree transformation overhead. Compared with the conventional linear-structured blockchain scheme, the proposed binary tree-structured lightweight blockchain scheme achieves performance improvement by up to 40% in the time required for authentication. The remainder of this paper is structured as follows: Section2 introduces the general concept of a smart dust IoT system and a blockchain. Section3 introduces a lightweight blockchain for a smart dust IoT environment. Section4 shows the experimental results that verified the validity of the proposed lightweight blockchain. Section5 discusses the conclusion and future research.

2. Background and the Related Studies

2.1. A Smart Dust IoT System A smart dust technology integrates technologies such as Microelectromechanical Systems (MEMS), an optical receiver, signal processing, and a control circuit, thick-film battery, and a solar cell [1–4,8,9]. One of the key features of smart dust device is that the devices are very tiny, though not nearly as small as dust. In a smart dust IoT systems, the enormous amount of smart dust devices can be sprayed using airborne devices (e.g., drones, aircraft, airplane, etc.) in areas that are difficult to access by most people (e.g., Amazon rain forest, lunar surface, polar regions, etc.). The nature of being deployed in hard-to-reach areas makes it difficult to follow up on the management of smart dust devices [3,9]. In a broad sense, a smart dust system can fall into the category of an IoT system. What makes a smart dust IoT system special is that it uses very tiny sensing devices with very low computing power/resources. The features of smart dust devices leave a variety of challenges such as bottlenecks, security, and device authentication in the smart dust IoT system. We proposed a framework of a smart dust IoT system to solve problems such as bottleneck removal and speed improvement through our previous studies [3,9]. Figure1 shows the basic physical device configuration of a smart dust IoT system proposed in our earlier study [9]. As shown in the smart dust IoT system in Figure1, the system is composed of multiple layers. SDDs (smart dust devices) in Figure1 refer to sensing devices and have all the features of smart dust devices described above. RDDs (relay dust devices) are responsible for consolidating, transforming, and compressing data to remove bottlenecks, or as operating as a buffer, thereby distributing the load from a vast number of SDDs/RDDs. Processing Nodes are nodes that process the collected data and are mapped to AE (application entities) from a general IoT system perspective. Finally, the smart dust IoT server control and manage processing nodes. Appl. Sci. 2020, 10, 8925 3 of 18 Appl. Sci. 2020, 10, x FOR PEER REVIEW 3 of 18

Appl. Sci. 2020, 10, x FOR PEER REVIEW 3 of 18

FigureFigure 1. 1. AnAn overview overview of of physical physical devices devices in in a asmart smart du dustst Internet Internet of of Things Things (IoT) (IoT) environment environment [9]. [9].

2.2. The Blockchain 2.2. The BlockchainFigure 1. An overview of physical devices in a smart dust Internet of Things (IoT) environment [9]. A blockchain is a technology based on distributed computing technology that connects the A 2.2.blockchain The Blockchain is a technology based on distributed computing technology that connects the managed data to the data structure called “block” in the form of a hash chain so that no user can managed dataA blockchain to the data is a structuretechnology called based "block"on distri inbuted the computingform of a technologyhash chain that so thatconnects no userthe can arbitrarily modify it, and anyone can view data (including the change history) [15–21]. A blockchain arbitrarilymanaged modify data it, to and the anyonedata structure can view called data "block" (including in the form the changeof a hash history) chain so [15–21]. that no Auser blockchain can also refers to an algorithm that bundles multiple data transaction details (creation and change history) also refersarbitrarily to an algorithmmodify it, and that anyone bundles can multiple view data data (including transaction the change details history) (creation [15–21]. and A change blockchain history) into blocks, connects multiple blocks like a chain using hashes, and then copies and stores them to be into blocks,also refers connects to an algorithmmultiple thatblocks bundles like multiplea chain datausing transaction hashes, and details then (creation copies and and change stores history) them to be distributedinto blocks, by multiple connects people multiple [15 blocks,16,21 like]. a chain using hashes, and then copies and stores them to be distributed by multiple people [15,16,21]. Figuredistributed2 is an by examplemultiple people of a generic [15,16,21]. block in a blockchain. Figure2 contains only the minimum Figure 2 is an example of a generic block in a blockchain. Figure 2 contains only the minimum componentsFigure to introduce 2 is an example the concept of a generic of a block block. in Thata blockchain. is, concepts Figure such 2 contains as the only Merkle the minimum tree root hash components to introduce the concept of a block. That is, concepts such as the Merkle tree root hash and miningcomponents [15,16 to,18 introduce] are omitted, the concept and of we a block. only discussThat is, concepts how the such integrity as the Merkle of ledgers tree root is maintained. hash and miningand mining [15,16,18] [15,16,18] are omitted,are omitted, and and we we only only di discussscuss how the the integrity integrity of ofledgers ledgers is maintained. is maintained. The most important point of the ledger integrity using blocks is that the block has a hash of the previous The mostThe importantmost important point point of theof the ledger ledger integrity integrity usingusing blocks is is that that the the block block has hasa hash a hash of the of the block (see Hash of the previous block in Figure2). previousprevious block block(see Hash(see Hash of the of theprevious previous block block in in Figure Figure 2).

HashHash of of thethe previous block previous block Time Time Nonce stamp Nonce stamp TX #1 TX #2 TX #1 TX #2 … TX #N

… TX #N FigureFigure 2. 2.An An exampleexample of of a a generic generic block. block.

Figure 2. An example of a generic block. Appl. Sci. 2020, 10, 8925 4 of 18 Appl. Sci. 2020, 10, x FOR PEER REVIEW 4 of 18

Figure3 3 shows shows anan example example ofof a a chain chain configuration configuration using using blocks blocks (see (see Figure Figure2 ).2). As As shown shown in in Figure3 3,, eacheach blockblock hashas thethe hashhash valuevalue ofof thethe previousprevious block, block, except except for for the the GenesisGenesis BlockBlock (the(the blockblock locatedlocated inin thethe firstfirst position), position), which which is is the the block block that that does does not not have have a previous a previous block. block. When When a block a block has ahas hash a hash of the of previousthe previous block, block, it means it means that inthat order in or toder falsify to falsify or alter or thealter specific the specific data, thedata, hashes the hashes of all blocksof all blocks in front in of front it must of it be must calculated be calculated and changed. and changed. The important The important point is that point blocks is that are constantlyblocks are beingconstantly created being while created calculating while thecalculating hashes ofthe previous hashes blocks.of previous When blocks. a block When is created, a block additionally, is created, calculationsadditionally, are calculations eventually are increased. eventually That increased. is, it is impossible That is, it to is change impossible the entire to change ledger the because entire blocksledger thatbecause must blocks be constantly that must calculated be constantly are added calculated even duringare added an attackeven during [15–21 ].an As attack can be[15–21]. seen intuitively As can be inseen Figure intuitively3, the time in Figure required 3, the for time authentication required for increases authentication dramatically increases as the dramatically number of nodes as the increase, number dueof nodes to the increase, linear structure due to the of alinear blockchain structure [20 ].of Therefore, a blockchain it is [20]. very Therefore, difficult or it impossible is very difficult to use or a generalimpossible blockchain to use a general in a smart blockchain dust IoT in system a smart with dust very IoT system limited with computing very limited power computing as well as power a vast numberas well as of a devices. vast number of devices.

Figure 3. An example of chain conﬁgurationconfiguration using blocks.

2.3. Blockchain for Resource-Constrained Environments There are variousvarious previousprevious studies that have consideredconsidered IoT limited devices. [[22]22] applies a lightweightlightweight hashhash function function in in consideration consideration of limitedof limited devices devices in the in IoTthe environment.IoT environment. Their Their main focusmain wasfocus to was prioritize to prioritize encryption encryption performance, performance, and performance and performance evaluation evaluati also evaluateson also theevaluates simulation the ofsimulation the hash. of In the [23 hash.], the authorsIn [23], definethe authors and deal define with and the deal resources with the of IoTresources devices of as IoT necessary devices foras calculationsnecessary for tailored calculations to each tailored system’s to each purpose. system’s They purpose. propose They a system propose in[ a23 system] in which in [23] IoT in devices which leaseIoT devices resources lease required resources for computationrequired for fromcomputatio virtualn resources.from virtual In addition,resources. in In [24 addition,], similar in to [24], [23], thesimilar resource to [23], required the resource for the required operation for suitable the operation for each suitable system for purpose each system is defined purpose and treated is defined as a resource.and treated The as di aff resource.erence between The difference [24] and between [23] is that [24] it notand only[23] solvesis that theit not resource only solves problem, the resource but also improvesproblem, but communication also improves effi communiciency bycation using efficiency a new type by of using transaction a new type and block,of transaction which reduces and block, the amountwhich reduces of computation the amount and of storage computation overhead. and storage overhead. 3. A Tree-Based Lightweight Blockchain for the Smart Dust IoT Environment 3. A Tree-Based Lightweight Blockchain for the Smart Dust IoT Environment One of the well-known problems of chain algorithms included in the blockchain is slow processing One of the well-known problems of chain algorithms included in the blockchain is slow speed [16,20]. Presently, the Bitcoin, the most well-known implementation of the blockchain, takes about processing speed [16,20]. Presently, the Bitcoin, the most well-known implementation of the 10 min to construct a new block [15,16], and in many cases, takes much more time to verify a block. blockchain, takes about 10 min to construct a new block [15,16], and in many cases, takes much more The slow processing speed problem worsens as the number of nodes increases, which is inefficient for time to verify a block. The slow processing speed problem worsens as the number of nodes increases, a smart dust IoT environment that encompasses so many devices. which is inefficient for a smart dust IoT environment that encompasses so many devices. The main features of a smart dust IoT system include a large number of devices and low computing The main features of a smart dust IoT system include a large number of devices and low power, which make it difficult for the normal blockchain to be used in a smart dust IoT environment. computing power, which make it difficult for the normal blockchain to be used in a smart dust IoT SDDs, with very limited computing power/resources, inherently cannot have ledgers for blockchains environment. SDDs, with very limited computing power/resources, inherently cannot have ledgers and the ability to perform operations such as comparing ledgers. for blockchains and the ability to perform operations such as comparing ledgers. Table1 shows a comparison between a linear-structured blockchain and a tree-structured blockchain. Table 1 shows a comparison between a linear-structured blockchain and a tree-structured blockchain.

Appl. Sci. 2020, 10, 8925 5 of 18

Table 1. A comparison between a linear-structured blockchain [15,16,20] and a tree-structured blockchain.

Conditions Linear-Structured Tree-Structured Topology shape Linear Tree Data propagation time N logN Additional operations Not needed Needed Implementation complexity Low High Process speed Slow Fast Fee Needed Not needed Scalability Low High

RDDs also do not have suﬃcient resources for the normal blockchain, though they are marginally improved than SDDs. Therefore, we need to make the blockchain light enough to run on RDDs. In order to improve the processing speed of the blockchain and to design a lightweight blockchain that can be used in the Smart Dust IoT environment, this study examined two considerations as follows:

Simple authentication process considering RDD’s computing power/resources • Ledger validation performed at a faster rate than the normal linear blockchain • Figure4 shows the lightweight blockchain for the smart dust IoT environments proposed in this study. In this figure, each block has six fields of information. The description of each field is as follows:

Authentication Information: contains authentication results. • Device’s Information: has the device information of the SDD that has requested authentication. • Prev. Hash: performs a chaining role (arrows in Figure4) by having the SHA 256 hash information • of the previous block. Hash (header): has the SHA 256 hash of fields including the header. • Sync Time: has the synchronization time of the block that has set by the Time Node. • Time Node is a node that determines the synchronization time (Sync Time) and is an external • physical device. Transaction: has data sensed by SDDs. • When each device (SDD/RDD) of the system is deployed in the field, the authentication process is performed with the help of the Auth Node (Authentication Node). An SDD and an RDD are each authenticated by the related RDD and the SDD, respectively (See Section 3.1 for detailed descriptions). We tried to keep the transaction as close to Ethereum [25] as possible, taking into account the possibility of future expansion. The difference is that there are “from” and “empty” fields. We wanted to reduce the amount of computation in consideration of low performance. Therefore, one can check “from” without calculation using the elliptic curve digital signature algorithm (ECDSA). Although this is a tradeoff between memory and computing power, we have considered a relatively expensive resource. Table2 shows fields of the transaction on proposed system. Among the transaction fields in Table2, There is the sender of the message in the “From” field, and the “Empty” field is an extra field considering future expansion. Appl. Sci. 2020, 10, 8925 6 of 18 Appl. Sci. 2020, 10, x FOR PEER REVIEW 6 of 18

Figure 4. The lightweight blockchain proposed for smart dust IoT environments.environments.

We tried to keep the transactionTable as close 2. Fields to Ethereum of transaction. [25] as possible, taking into account the possibility32 Bytes of 32future Bytes expansion. 32 Bytes Th 20e Bytes difference 20 Bytes is that there 32 Bytes are “from” 1 Bytes and 32 Bytes“empty” 32 fields. Bytes We 23 wanted Bytes to reduceNonce the amount Price ofLimit computation To in consideration From Value of low performance. V R Therefore, S one can Empty check “from” without calculation using the elliptic curve digital signature algorithm (ECDSA). Although this is a tradeoff between memory and computing power, we have considered a relatively expensive Table3 shows the authentication and block chaining process using the proposed lightweight resource. blockchain. A detailed explanation for each step is described in Sections 3.1–3.5. Table 2 shows fields of the transaction on proposed system. Among the transaction fields in Table 2, There is the sender of the message in the “From” field, and the “Empty” field is an extra field considering future expansion.

Table 2. Fields of transaction.

32 bytes 32 bytes 32 bytes 20 bytes 20 bytes 32 bytes 1 bytes 32 bytes 32 bytes 23 bytes Nonce Price Limit To From Value V R S Empty

Table 3 shows the authentication and block chaining process using the proposed lightweight blockchain. A detailed explanation for each step is described in Section 3.1 through 3.5.

Appl. Sci. 2020, 10, 8925 7 of 18

Table 3. The algorithm of the authentication and block chaining process using the proposed lightweight blockchain.

Stages Steps Explanation Step 1 An SDD sends an authentication request to RDD. SDD/RDD 1 authentication The RDD authenticates the SDD with the help of the Auth Node. (see Section 3.1) Step 2 The RDD in turn sends an authentication response to the SDD. The SDD authenticates the RDD with the help of the Auth Node. The RDD creates a new block. The RDD stores into the block the authentication information (result), Step 3 Creation and the hash of the previous block, the SDD’s device information, verification the sensed data by the SDD, and the SHA 256 hash value. (see Section 3.2) The RDD verifies the block through the lightweight tree-structured Step 4 ledger verification (see Section 3.2.1). Step 5 The RDD requests a commit time to the Time node. Scheduling On receiving the commit time from the Time node, the RDD stores the (see Section 3.3) Step 6 commit time to the Sync Time field in the block. The RDD propagates the block (created through Step 3–Step 6) to Step 7 Propagation other RDDs using the lightweight tree-structured ledger verification. (see Section 3.4) Every RDD that receives the propagated block writes the block to its Step 8 standby ledger. When the commit time has been reached, the Time node sends Synchronization Step 9 notifications to all the RDDs, and RDDs receiving the notification (see Section 3.5) commit their standby ledgers to their commit ledgers. 1 SDD (Smart Dust Device), RDD (Relay Dust Device).

3.1. SDD/RDD Authentication Stage In the authentication stage, an SDD and the related RDD authenticate each other with the help of the Auth Node. That is, each SDD is authenticated by an Auth Node, and RDD is an intermediary of authentication. We assume that an SDD and an RDD have the SDD’s private key and the RDD’s private key, respectively. The Auth Node has the public keys and the device information of all the SDDs/RDDs. Figure5 shows the SDD /RDD authentication process. When an SDD sends an authentication request to its neighboring RDD (Message 1 in Figure5), the RDD forwards it to the Auth Node (Message 2 in Figure5) because the RDD does not have any SDD information. The ECC (elliptic curve cryptosystem) [26] with the SDD’s private key is used for the encryption of these request messages. On receiving the request Message 2 from the RDD, the Auth Node decrypts the message using the public key of the SDD. Then, the Auth Node compares the SDD’s device information obtained from Message 2 with the information stored in the Auth Node’s database. If the information of the two devices is identical, Message 4 including the authentication result (ok), and the SDD’s public key is sent to the RDD. The message is encrypted with the RDD’s public key and hence the RDD can determine whether or not the SDD authentication is successful. In turn, the RDD sends Message 6 for the SDD to authenticate the RDD. In order to authenticate the RDD, the SDD needs to compare the RDD’s device information sent by the RDD itself and by the Auth Node. When the Auth Node sends Message 4, the RDD’s device information stored in the Auth Node is included. The device information is encrypted with the SDD’s public key and hence the RDD cannot alter the device information. If the comparison by the SDD matches, the RDD is authenticated successfully by the SDD. Appl. Sci. 2020, 10, 8925 8 of 18 Appl. Sci. 2020, 10, x FOR PEER REVIEW 8 of 18

FigureFigure 5.5. SDDSDD/RDD/RDD authentication process process..

3.2.3.2. Creation Creation and and ValidationValidation StageStage InIn the the creation creation and and validation validation stage,stage, aa newnew blockblock isis createdcreated and validated. When When a a new new block block is is created,created, the the RDD RDD stores stores the the related related information information in thein the new new block. block. The The Authentication Authentication Information Information field infield the blockin the contains block contains the authentication the authentication result, authentication result, authentication target, authentication target, authentication time, etc. time, The Prev.etc. HashThe Prev. field, theHash Device’s field, the Information Device’s Information field, and the fiel Transactiond, and the field Transaction of the block field contain of the theblock hash contain of the previousthe hash block, of the SDD’s previous device block, information, SDD’s device and the information, sensed data and by thethe SDD, sensed respectively. data by the The SDD, RDD hashesrespectively. the Header The RDD part of hashes the block the Header with the part SHA of 256 the algorithmblock with and the stores SHA 256 it in algorithm the Header and (hash) stores field. it in theThen, Header the validation(hash) field. step is performed. The RDD checks if the SDD has been authenticated using the lightweightThen, the validation ledger validation step is performed. method proposed The RDD in checks this study. if the SDD The lightweighthas been authenticated ledger validation using method,the lightweight described ledger in the validation next section, method converts proposed a linear-structured in this study. The blockchain lightweight into ledger a tree-structured validation blockchainmethod, described and removes in the some next unnecessarysection, converts operations. a linear-structured It helps to quickly blockchain perform into ledgera tree-structured validation, evenblockchain if a large and number removes of devicessome unnecessary constitute theoperations. blockchain. It helps to quickly perform ledger validation, even if a large number of devices constitute the blockchain. 3.2.1. The Proposed Ledger Verification Method Using a Binary Tree-Structured Lightweight3.2.1. The Proposed Blockchain Ledger Verification Method Using a Binary Tree-Structured Lightweight BlockchainThe unique linear chain structure of the conventional blockchain can be fatal in a system with a very largeThe unique number linear of devices,chain structure such as of athe smart convention dust IoTal blockchain environment. can be For fatal example, in a system more with than a 50,000,001very large communicationsnumber of devices, are such required as a tosmart validate dust aIoT ledger environment. of a smart For dust example, IoT system more than with 100,000,00050,000,001 devices,communications and all validation are required operations to validate are “linear”. a ledger Figure of a6 smartis an example dust IoT to system demonstrate with the100,000,000 problem devices, caused byand a all linear validation chain structure.operations Inare this “linear.” example, Figure the 6 shadedis an example nodes to are demonstrate RDDs that participatethe problem in thecaused ledger by verification,a linear chain and structure. the unshaded In this nodes example, are the the RDDs shaded that nodes do not are participate RDDs that in theparticipate ledger verification. in the ledger If verification, Node 1 requests and the the unshaded ledger validation, nodes are the the validationRDDs that processdo not participate is performed in linearly.the ledger That verification. is, the process If Node is repeated 1 requests until the moreledger than validation, half of thethe nodesvalidation confirm process that is the performed ledger is identical.linearly. InThat the is, example, the process a communication is repeated until time more of 50 than ms ishalf required of the nodes to validate confirm the ledger.that the If ledger the time is foridentical. Node 6 In to the notify example, the Node a communica 1 is 10 ms,tion a total time communication of 50 ms is required time to of validate 60 ms is the required. ledger. If the time for Node 6 to notify the Node 1 is 10 ms, a total communication time of 60 ms is required. Appl. Sci. 2020, 10, 8925 9 of 18 Appl. Sci. 2020, 10, x FOR PEER REVIEW 9 of 18 Appl. Sci. 2020, 10, x FOR PEER REVIEW 9 of 18

Figure 6. An example of a linear chain structure of the conventional blockchain. FigureFigure 6.6. An example of a linear chain structurestructure ofof thethe conventionalconventional blockchain.blockchain. Let us consider the proposed lightweight blockchain consisting of a binary-structured blockchainLetLet usus consider asconsider shown the inthe proposed Figure proposed 7. lightweight In thelightweight figure, blockchain the bl shadedockchain consisting nodes consisting ofare a binary-structuredRDDs of thata binary-structured participate blockchain in the asblockchainledger shown validation, in as Figure shown7 whereas. In in the Figure ﬁgure, the 7.unshaded theIn shadedthe figure, nodes nodes the are are shaded the RDDs RDDs nodes that that participate are do RDDs not participate in that the ledgerparticipate in validation, the inledger the whereasledgervalidation. validation, the If unshaded Node whereas 1 requests nodes the are va unshaded thelidation, RDDs Nodenodes that do1 arebecomes not the participate RDDs the root that in node do the not ledger(RDD) participate validation.of the binary in the If tree Node ledger and 1 requestsvalidation.the root validation, node If Node requests 1 Node requests validation 1 becomes validation, to the Node root Node node2 and 1 becomes (RDD) Node of3 the in the rootthe binary tree node treestructure. (RDD) and theof Since the root binary nodethe validation requeststree and validationtheprocesses root node toat Node requests 2 2 and and validation Node Node 3 3 can in to the beNode performed tree 2 structure. and Node in pa Sincerallel, 3 in thethe only validationtree 10 msstructure. is required. processes Since In atthe the Node validation next 2 andstep, NodeprocessesNode 32 can and at beNode Node performed 2 and3 request Node in parallel, 3validation can be only performed to 10 Nodes ms isin required.pa4, rallel,5, 6, onlyand In the 107 in ms next parallel. is step,required. NodeTherefore, In 2 the and next the Node step,total 3 requestNodecommunication 2 validation and Node time to 3 Nodes requiredrequest 4, 5, validationuntil 6, and mo 7re in thanto parallel. Nodes half of Therefore, 4, the 5, nodes6, and the participate total7 in communicationparallel. in the Therefore, validation time requiredthe is 20 total ms. untilcommunicationIf the more communication than halftime of required time the nodes for until Node participate mo 6 tore notifythan in half the Node validationof the1 is nodes 10 ms, is 20participate a ms.total If communication the in communication the validation time is timeof 20 30 ms.for ms NodeIfis the required, 6communication to notify which Node is time 1far is 10less for ms, thanNode a total that 6 to communication ofnotify the liNodenear-structured 1 timeis 10 ofms, 30 a msblockchain total is required,communication mentioned which is time above. far lessof 30 If than msthe thatisexamples required, of the linear-structuredshown which in is Figures far less blockchain 6 andthan 7 that are mentioned increasedof the linear-structured above.to up to If 1,000,000 the examples blockchain device shown units, mentioned in the Figures linear-structured above.6 and 7If are the increasedexamplesblockchain toshown uprequires to in 1,000,000 Figures the communica device6 and 7 units, aretion increased the time linear-structured ofto up5,000,020 to 1,000,000 blockchainms, dewherviceeas requires units, that the theof linear-structuredthe communication binary tree- timeblockchainstructured of 5,000,020 blockchainrequires ms, whereasthe takes communica 230 that ms. of thetion binary time tree-structuredof 5,000,020 ms, blockchain whereas takesthat 230of the ms. binary tree- structured blockchain takes 230 ms.

FigureFigure 7. 7.The The proposedproposed binarybinary tree-structured tree-structured lightweight lightweight blockchain. blockchain. Figure 7. The proposed binary tree-structured lightweight blockchain. Appl. Sci. 2020, 10, 8925 10 of 18

The Auth Node designates the first RDD among all RDDs. The first RDD constructs a logical overlay network in a binary-structured fashion that connects all RDDs registered in the Auth Node. Each RDD also has its binary-structured overlay network. Except for the first RDD, the tree in each RDD may not have all RDDs. This means that each RDD has the subtree of the first RDD’s tree. In addition, each RDD has a connection path to the first RDD. When a new RDD is connected, the first RDD adds the RDD to its logical overlay network. Then, the first RDD notifies the parent RDD of the new RDD that it has registered a child RDD, and the parent RDD adds the child RDD to its tree. Table4 shows the ledger validation algorithm using the binary tree-structured lightweight blockchain proposed in this study.

Table 4. The ledger veriﬁcation algorithm using the binary tree-structured lightweight blockchain.

Steps Explanation 1 The RDD that wants its SDD verification requests other RDDs to compare the commit ledgers. The RDD performs the tree transformation (see Section 3.2.2 for details). 2 Make logical connection paths from the RDD’s descent RDD to the first RDD temporally. 3 The RDD requests verification of the commit ledger from itself down to descent RDDs. 4 The descent RDDs send verification results to the RDD.

3.2.2. An Example of the Ledger Verification Using the Binary Tree-Structured Lightweight Blockchain The ledger verification occurs continuously whenever authentication is performed in order to prevent attacks through false authentication on devices. In addition, when collecting and transmitting sensed data, the ledger verification must be continuously performed to prevent duplicate data and data insertion attacks. This means that ledger verification occurs frequently, and that it can be requested from an arbitrary RDDs location. However, if the number of descendant RDD nodes is smaller than half of the total number of RDD nodes, verification cannot be performed. Another problem is that it is not possible to propagate locally generated blocks to ancestor RDD nodes due to the characteristic of a one-way tree structure. In order to solve these two problems, the tree structure must be flexibly changed whenever verification is requested. Figure8 shows a scenario for solving the above problems by transforming the tree structure. As shown in this figure, when an SDD requests registration (or authentication) to RDD D, only RDD D’s descent RDD nodes (RDD H and RDD I) can participate in the verification, due to the characteristic of a one-way tree structure. This means that the number of RDDs that participate in the verification is smaller than five, half of the total number of RDDs. The tree transformation of RDD described below is performed by the RDD requesting registration/change/verification of the ledger. In order to solve the above problem, we changed the structure so that each RDD has an overlay path to the first RDD. Using the overlay path, the first RDD was temporarily registered as a child node of the leaf RDD at the lowest level. Figure9 shows an example of the transformation of the tree in Figure8. The shaded part in Figure9 indicates that RDD A (the first RDD) is connected temporarily as a child node of RDD H (the leaf node) at the lowest level. This does not actually change the tree. Rather, it is simply a temporary tree transformation (i.e., connection of the first RDD node as a child node of the leaf RDD H). Since the overhead of the tree transformation is constant, the overhead cost increases linearly as the number of verification requests increases. Since verification can be performed in parallel in the tree structure, we need to perform verification in at most log N/2 times (N: the total number of RDD nodes). Appl. Sci. 2020, 10, x FOR PEER REVIEW 11 of 18

Appl. Sci. 2020, 10, 8925 11 of 18 Appl. Sci. 2020, 10, x FOR PEER REVIEW 11 of 18

Figure 8. An example where more than half of the total number of RDDs cannot participate in validation.

The tree transformation of RDD described below is performed by the RDD requesting registration/change/verification of the ledger. In order to solve the above problem, we changed the structure so that each RDD has an overlay path to the first RDD. Using the overlay path, the first RDD was temporarily registered as a child node of the leaf RDD at the lowest level. Figure 9 shows an example of the transformation of the tree in Figure 8. The shaded part in Figure 9 indicates that RDD A (the first RDD) is connected temporarily as a child node of RDD H (the leaf node) at the lowest level. This does not actually change the tree. Rather, it is simply a temporary tree transformation (i.e., connection of the first RDD node as a child node of the leaf RDD H). Since the overhead of the tree transformation is constant, the overhead cost increases linearly as the number of verification requests increases. Since verification can be performed in parallel in the tree structure, we need to perform verification FigureinFigure at most 8.8.An An example logexample 𝑁/2 where where times more more than(N: than halfthe of halftotal the of total numberthe number total numberof of RDDs RDD of cannot RDDsnodes). participate cannot participate in validation. in validation.

The tree transformation of RDD described below is performed by the RDD requesting registration/change/verification of the ledger. In order to solve the above problem, we changed the structure so that each RDD has an overlay path to the first RDD. Using the overlay path, the first RDD was temporarily registered as a child node of the leaf RDD at the lowest level. Figure 9 shows an example of the transformation of the tree in Figure 8. The shaded part in Figure 9 indicates that RDD A (the first RDD) is connected temporarily as a child node of RDD H (the leaf node) at the lowest level. This does not actually change the tree. Rather, it is simply a temporary tree transformation (i.e., connection of the first RDD node as a child node of the leaf RDD H). Since the overhead of the tree transformation is constant, the overhead cost increases linearly as the number of verification requests increases. Since verification can be performed in parallel in the tree structure, we need to perform verification in at most log 𝑁/2 times (N: the total number of RDD nodes).

Figure 9.Figure An example 9. An example of the of thetree tree transformation transformation inin aa case case where where more more than than half of half the totalof the RDDs total RDDs cannot participatecannot participate in validation. in validation. 3.3. Scheduling Stage In the scheduling stage, the commit time for synchronization is determined. In order to synchronize the ledger, the conventional blockchain propagates the transaction, stores the transaction in the mempool, and sequentially applies it to the ledger. Therefore, conventional blockchain cannot validate transactions until the ledger is synchronized above a certain level. In addition, mempool is constantly Figure 9. An example of the tree transformation in a case where more than half of the total RDDs cannot participate in validation. Appl. Sci. 2020, 10, 8925 12 of 18 running in the background of the node, so it is difficult to use it in a smart dust IoT environment with limited computing power/resources. Therefore, in this study, we propose a light synchronization method without using a mempool. To do this, we introduce three concepts to apply commit to the system: the standby ledger, the commit time, and the Time Node. The commit time is the time at which synchronization is performed as determined by the Time Node. The standby ledger is a temporary ledger in which transactions that have not been committed are stored because the commit time has not yet been reached. The commit ledger is the ledger of the blockchain to which the standby ledger is committed. The commit ledger matches to the ledger in the conventional blockchain. That is, all blocks are stored in the standby ledger above all, and when the commit time has reached, all the blocks in the standby ledger are committed to the commit ledger. Both ledgers types (standby/commit ledger) are owned by each RDD. The Time Node determines the commit time and notifies the related RDDs that the commit time has been reached. The Time Node operates as a single thread, ensuring the order of transactions. This is a very simple but important process because it becomes a tool that can uniquely identify transactions. In the previous procedure (Section 3.2), after the RDD performs the ledger validation for the block, the RDD requests the Time Node to schedule a commit time. The scheduling is a simple task of recording the names of RDDs in an empty slot in a table divided by 3 min (enough time for the block to be committed, which of course can grow depending on the size of a block). Then, the time of the slot is returned to the RDD. The RDD records the slot time as the commit time in the Sync Time field in the block.

3.4. Propagation Stage In the propagating stage, the RDD propagates the block created by the RDD to all other RDDs. After the RDD writes the commit time to the Sync Time ﬁeld in the block, there should be no more data to be written to the block (i.e., the block is complete). The block propagation process is very similar to the ledger validation process. The block propagation can use the same path used for the ledger validation. Therefore, the propagation uses a lightweight ledger validation using a tree structure. Finally, all the RDDs store blocks in their standby ledger.

3.5. Synchronization Stage The final stage, synchronization of the ledger stage, is the stage at which every RDD commits its standby ledger to its commit ledger. When the commit time scheduled in the scheduling stage has been reached, the Time Node sends a notification to all the RDDs in the system. The RDDs receiving the notification commit their respective standby ledgers to the commit ledger.

4. Implementation and Experiments Figure 10 shows the software module conﬁguration for the binary tree-structured lightweight blockchain developed for this study. This system consists of SDD devices, RDD devices, the Auth Node server, and the Time Node server. The software modules in common are Init Module, Session Module, Sending Module, and Receiving Module. The Init Module performs initialization according to the role of each device. The Session Module manages the communication connection to the device. The Sending Module sends data generated to other devices or servers. The Receiving Module receives data from other devices or servers. Appl. Sci. 2020, 10, 8925 13 of 18 Appl. Sci. 2020, 10, x FOR PEER REVIEW 13 of 18

SDD RDD Auth Node Time Node

Init Init Init Init Module Module Module Module

Session BlockMng Sending TaskRe gi ster Module Module Module Module

Sensing TransMng Receiving TimeCheck Module Module Module Module

Sending Auth Auth Notificati on Module Module Module Module

Receiving Broadcast Sending Module Module Module

Sending Receiving Module Module

Receiving Module

Figure 10. The software module configuration for the binary tree-structured lightweight blockchain. Figure 10. The software module conﬁguration for the binary tree-structured lightweight blockchain.

The softwaresoftware modulesmodules in in the common SDD device are Init are: Module, Session Module, Sending Module, and Receiving Module. The Init Module performs initialization according to the role of each device. The SessionSession Module Module: manages maintains the communication and manages the connect connectionion betweento the device. the device The connected Sending Module and this devicesends • data Sensinggenerated Module: to other senses devices and or collects servers. data The in Re theceiving neighboring Module area receives data from other devices • or servers. The software modules in the RDD device are: The software modules in the SDD device are: • BlockMng Module: creates and manages blocks • Session Module: maintains and manages the connection between the device connected and this device • TransMng Module: records transactions • Sensing Module: senses and collects data in the neighboring area Auth Module: performs authentication • The software modules in the RDD device are: Broadcast Module: propagates the standby ledger • • BlockMng Module: creates and manages blocks • TheTransMng software Module: modules records in transactions the Auth Node server are: • Auth Module: Module: performs keeps authentication authentication data in its database and manages authentication across • theBroadcast system Module: propagates the standby ledger The software modules in the Auth Node server are: The software modules in the Time Node server are: • Auth Module: keeps authentication data in its database and manages authentication across the system TaskRegister Module: registers tasks in its schedule table • TimeCheckThe software Module: modules allocates in the Time synchronization Node server time are: • • NotiﬁcationTaskRegister Module: Module: notiﬁes registers when tasks the in synchronizationits schedule table time has reached • • TimeCheck Module: allocates synchronization time • Notification Module: notifies when the synchronization time has reached Appl. Sci. 2020, 10, 8925 14 of 18

Appl.We Sci. also 2020,implemented 10, x FOR PEER REVIEW the conventional linear-structured blockchain for comparison.14 Table of 18 5 shows the experiment environments for this study. We also implemented the conventional linear-structured blockchain for comparison. Table 5 shows the experiment environmentsTable for 5. thisExperiment study. environments.

Component #1 #2 #3 Table 5. Experiment environments. CPU Intel i7-6700 Intel i7-6700 Intel i9-9900 ComponentRAM 16#1 GB 32#2 GB 64 GB#3 CPUOS Ubuntu Intel i7-6700 18.01 LTS Ubuntu Intel i7-6700 18.01 LTS Ubuntu Intel 18.01i9-9900 LTS RAM 16 GB 32 GB 64 GB OS Ubuntu 18.01 LTS Ubuntu 18.01 LTS Ubuntu 18.01 LTS We measured the authentication time required by gradually increasing the number of SDDs from 2000 toWe 7000. measured Ten percent the ofauthentication SDDs was assigned time required as RDDs. by Ingradually addition, increasing in consideration the number of the of overhead SDDs requiredfrom 2000 for to tree 7000. transformation Ten percent of of SDDs the proposed was assigned tree as structure RDDs. In lightweight addition, in blockchain, consideration additional of the experimentsoverhead required were performed for tree transformation on the overhead of timethe proposed required, tree the totalstructure time lightweight required, and blockchain, the ratio of theadditional overhead. experiments Figure 11 shows were performed the total authentication on the overhead time time of required, all SDDs. the total time required, and the ratio of the overhead. Figure 11 shows the total authentication time of all SDDs.

Figure 11. The total authentication time of all SDDs. Figure 11. The total authentication time of all SDDs. When the number of SDDs is 2000 to 3500, it can be seen that the conventional linear-structured When the number of SDDs is 2000 to 3500, it can be seen that the conventional linear-structured blockchain provides better results than the binary tree-structured blockchain. However, when the blockchain provides better results than the binary tree-structured blockchain. However, when the number of SDDs exceeds about 3700, the performance of the binary tree-structured blockchain is number of SDDs exceeds about 3700, the performance of the binary tree-structured blockchain is better than that of the conventional linear-structured blockchain. Due to the limit of the experiment betterenvironments, than that ofwe the could conventional not perform linear-structured the comparison experiment blockchain. beyond Due to 6000 the SDDs. limit of However, the experiment with environments,the trend of the we two could curves, not we perform can predict the the comparison performance experiment gap between beyond the two 6000 blockchains SDDs. is However, much withwider the beyond trend of 6000 the SDDs. two curves, This means we can that predict the bina thery performancetree-structured gap blockchain between is the more two appropriate blockchains is muchin a smart wider dust beyond IoT system 6000 with SDDs. an enormous This means amount that theof SDDs. binary tree-structured blockchain is more appropriateCompared in a smart with dust the IoT conventional system with antree-struct enormousured amount blockchain of SDDs. (simple DAG-structured blockchain)Compared and with the the linear-structured conventional tree-structuredblockchain, the blockchaintotal authentication (simple DAG-structuredtime of the proposed blockchain) tree- andstructured the linear-structured blockchain is blockchain,lower by about the total 7% authenticationand 10% on average, time of respectively. the proposed Since tree-structured the only blockchaindifference is between lower by the about proposed 7% and tree-structured 10% on average, blockchain respectively. and the Since conventional the only di tree-structuredfference between theblockchain proposed is tree-structured the tree transformation blockchain (Step and 2 thein Tabl conventionale 4), it can tree-structuredbe said that the blockchaintree transformation is the tree operation contributes to the improvement. Appl. Sci. 2020, 10, x FOR PEER REVIEW 15 of 18 Appl. Sci. 2020, 10, 8925 15 of 18 Figure 12 shows the average authentication time per SDD. The average time required transformationto authenticate (Step one 2 SDD in Table for 4the), it binary can be tree-structured said that the tree blockchain transformation is almost operation constant contributes (about 450 to ms), whereas the average authentication time required for the conventional linear-structured the improvement. blockchain continues to increase. This means that the conventional linear-structured blockchain Figure 12 shows the average authentication time per SDD. The average time required to authenticate would become more difficult or inefficient to use as the number of SDDs increases. It shows that the one SDD for the binary tree-structured blockchain is almost constant (about 450 ms), whereas the performance of the binary tree-structured blockchain is more improving than the linear chain as the average authentication time required for the conventional linear-structured blockchain continues to number of SDDs incre increase. This means that the conventional linear-structured blockchain would become more difficult or inefficient to use as the number of SDDs increases. It shows that the performance of the binary tree-structured blockchain is more improving than the linear chain as the number of SDDs increases.

Figure 12. The average authentication time per SDD.

The conventional tree-structured blockchain does not show much diﬀerence from the proposed tree-structured blockchain when less than 2000 devices are connected, but shows an average performance diﬀerence of about 10% after more than 3000 devices are connected, and the gap cannot be narrowed. Figure 13 shows the overhead time required for the tree transformation with regard to the number of SDDs. The overhead time required for the tree transformation increases as the number of SDDs increases. This is because the number of validations increase as the number of SDDs increases, which is very reasonable. What is considerable to note here is the ratio of the overhead time for the tree transformation to the total authentication time. Appl. Sci. 2020, 10, 8925 16 of 18

Appl. Sci. 2020,, 10,, xx FORFOR PEERPEER REVIEWREVIEW 16 of 18

Figure 13. TheThe overhead overhead time required for the tree transformation.

Figure 1414 showsshows the the ratio ratio of of the the tree tree transformation transformation overhead overhead time time to the to totalthe total authentication authentication time. time.It can It be can seen be that seen as that the totalas the number total number of SDDs of increases, SDDs increases, the ratio the of the ratio tree of transformation the tree transformation overhead overheadtime to the time total to authentication the total authentication time decreases time dec andreases converges and converges at about 10%.at about This 10%. also This means also that means the thatbinary the tree-structured binary tree-structured blockchain blockchain is more appropriate is more appropriate in a smart in dust a smart IoT system dust IoT with system an enormous with an enormousamount of amount SDDs. of SDDs.

Figure 14. The ratio of the tree transformation overhead time to the total authentication time. Figure 14. The ratio of the tree transformation overhe overheadad time to the total authentication time.

The results of the experiments mentioned above show that the proposed binary tree-structured lightweight blockchainblockchain cancan reduce thethe time required forfor SDD SDD authentication,authentication, even even taking taking into into accountaccount the treetree transformation transformation overhead. overhead. Even Even the performancethe performance of the of proposed the proposed blockchain blockchain is more improved is more improvedcompared tocompared the conventional to the conventional blockchain asblockcha the numberin as ofthe SDDs number increases. of SDDs The increases. experimental The experimentalresults show thatresults the show performance that the improvementperformance im isprovement up to 40% (10%is up in to average) 40% (10% with in average) respect to with the respectauthentication to the authentication time. time.

Appl. Sci. 2020, 10, 8925 17 of 18

5. Conclusions Since a smart dust IoT system includes a very large number of devices sometimes deployed in hard-access areas, it is very difficult to prevent security attacks and to alleviate bottleneck phenomena. There have been many studies on security issues for IoT systems. However, few studies have been done for the secure smart dust IoT system, although a smart dust IoT system is much more vulnerable to security attacks since smart dust has a very limited computing power. In this paper, we propose a lightweight blockchain scheme that helps device authentication and data security in a secure smart dust IoT environment. A smart dust IoT system includes a large number of devices and low computing power, which make it difficult for the normal blockchain to be used in a smart dust IoT environment. SDDs, with very limited computing power/resources, inherently cannot have ledgers for blockchains nor the ability to perform operations such as comparing ledgers. Therefore, we propose the structure of the lightweight blockchain and the algorithm of processing the blockchain. In addition, we reorganize the linear block structure of the conventional blockchain into the binary tree structure in such a way that the proposed blockchain is more efficient in a secure smart dust IoT environment. However, due to the characteristic of a one-way tree structure, if the number of the descendant RDD nodes in a binary tree-structured blockchain is smaller than half of the total number of RDD nodes, verification cannot be performed. In order to solve these two problems, the tree transformation is also proposed. Experiments show that the proposed binary tree-structured lightweight blockchain scheme can greatly reduce the time required for smart dust device authentication, even taking into account the tree transformation overhead. Compared with the conventional linear-structured blockchain scheme, the proposed binary tree-structured lightweight blockchain scheme achieves performance improvement by up to 40% (10% in average) with respect to the authentication time.

Author Contributions: Conceptualization, K.P. and J.P.; methodology, K.P. and J.P.; software, J.P.; validation, K.P.; formal analysis, J.P.; investigation, K.P.; resources, J.P.; data curation, J.P.; writing—original draft preparation, J.P.; visualization, J.P.; review—editing and supervision, K.P.; project administration, K.P.; funding acquisition, K.P. All authors have read and agreed to the published version of the manuscript. Funding: This research was funded by the Basic Science Research Programs through the National Research Foundation of Korea (NRF), grant number funded by the Ministry of Education, Science and Technology (No. NRF-2018R1D1A1B07043982). Conﬂicts of Interest: The funders had no role in the design of the study; in the collection, analyses, or interpretation of data; in the writing of the manuscript, or in the decision to publish the results.

References

1. Anderson, R.; Chan, H.; Perrig, A. Key infection: Smart trust for smart dust. In Proceedings of the 12th IEEE International Conference on Network Protocols, ICNP 2004, Berlin, Germany, 5–8 October 2004; pp. 206–215. 2. Kahn, J.M.; Katz, R.H.; Pister, K.S.J. Next century challenges. In Proceedings of the 5th Annual ACM/IEEE International Conference on Mobile Computing and Networking—MobiCom ’99, Seattle, WA, USA, 15–20 August 1999; pp. 271–278. 3. Park, J.; Park, K. A Dynamic Plane Scaling Method for Smart Dust Environments. Lect. Notes Electr. Eng. 2019, 536, 381–384. [CrossRef] 4. Warneke, B.; Last, M.; Liebowitz, B.; Pister, K. Smart Dust: Communicating with a cubic-millimeter computer. Computer 2001, 34, 44–51. [CrossRef] 5. Gubbi, J.; Buyya, R.; Marusic, S.; Palaniswami, M. Internet of Things (IoT): A vision, architectural elements, and future directions. Future Gener. Comput. Syst. 2013, 29, 1645–1660. [CrossRef] 6. Ray, P. A survey on Internet of Things architectures. J. King Saud Univ. Comput. Inf. Sci. 2018, 30, 291–319. [CrossRef] 7. Miorandi, D.; Sicari, S.; De Pellegrini, F.; Chlamtac, I. Internet of things: Vision, applications and research challenges. Ad Hoc Netw. 2012, 10, 1497–1516. [CrossRef] 8. Kahn, J.M.; Katz, R.H.; Pister, K.S.J. Emerging challenges: Mobile networking for “Smart Dust”. J. Commun. Netw. 2000, 2, 188–196. [CrossRef] Appl. Sci. 2020, 10, 8925 18 of 18

9. Park, J.; Park, K. A Dynamic Plane Prediction Method Using the Extended Frame in Smart Dust IoT Environments. Sensors 2020, 20, 1364. [CrossRef] 10. Alcaide, A.; Palomar, E.; Montero-Castillo, J.; Ribagorda, A. Anonymous authentication for privacy-preserving IoT target-driven applications. Comput. Secur. 2013, 37, 111–123. [CrossRef] 11. Granjal, J.; Monteiro, E.; Silva, J.S. Security for the Internet of Things: A Survey of Existing Protocols and Open Research Issues. IEEE Commun. Surv. Tutor. 2015, 17, 1294–1312. [CrossRef] 12. Kalra, S.; Sood, S.K. Secure authentication scheme for IoT and cloud servers. Pervasive Mob. Comput. 2015, 24, 210–223. [CrossRef] 13. Nguyen, K.T.; Laurent, M.; Oualha, N. Survey on secure communication protocols for the Internet of Things. Ad Hoc Netw. 2015, 32, 17–31. [CrossRef] 14. Shariﬁ, M.; Kashi, S.S.; Ardakani, S.P. LAP: A Lightweight Authentication Protocol for smart dust wireless sensor networks. In Proceedings of the 2009 International Symposium on Collaborative Technologies and Systems, Baltimore, MD, USA, 18–22 May 2009; pp. 258–265. [CrossRef] 15. Dai, H.-N.; Zheng, Z.; Zhang, Y. Blockchain for Internet of Things: A Survey. IEEE Internet Things J. 2019, 6, 8076–8094. [CrossRef] 16. Nguyen, G.T.; Kim, K. A Survey about Consensus Algorithms Used in Blockchain. J. Inf. Process. Syst. 2018, 14.[CrossRef] 17. Portmann, E. Rezension “Blockchain: Blueprint for a New Economy”. HMD Prax. Wirtsch. 2018, 55, 1362–1364. [CrossRef] 18. Wright, C.S. Bitcoin: A Peer-to-Peer Electronic Cash System. SSRN Electron. J. 2008.[CrossRef] 19. Brito, J.; Castillo, A. Bitcoin: A Primer for Policymakers; Mercatus Center at George Mason University: Arlington, VA, USA, 2013. 20. Kiayias, A.; Panagiotakos, G. On Trees, Chains and Fast Transactions in the Blockchain. In Proceedings of the Computer Vision—ECCV 2020, Glasgow, UK, 23–28 August 2020; Springer Science and Business Media LLC: Berlin, Germany, 2020; pp. 327–351. 21. Zheng, Z.-B.; Xie, S.; Dai, H.N.; Chen, X.; Wang, H. Blockchain challenges and opportunities: A survey. Int. J. Web Grid Serv. 2018, 14, 352. [CrossRef] 22. Seok, B.; Park, J.; Park, J.H. A Lightweight Hash-Based Blockchain Architecture for Industrial IoT. Appl. Sci. 2019, 9, 3740. [CrossRef] 23. Samaniego, M.; Deters, R. Hosting Virtual IoT Resources on Edge-Hosts with Blockchain. In Proceedings of the 2016 IEEE International Conference on Computer and Information Technology (CIT), Nadi, Fiji, 7–10 December 2016; pp. 116–119. 24. Xu, C.; Wang, K.; Li, P.; Guo, S.; Luo, J.; Ye, B.; Guo, M. Making Big Data Open in Edges: A Resource-Eﬃcient Blockchain-Based Approach. IEEE Trans. Parallel Distrib. Syst. 2018, 30, 870–882. [CrossRef] 25. Wood, G. Ethereum: A secure decentralised generalised transaction ledger. Ethereum Proj. Yellow Pap. 2014, 151, 1–32. 26. Koblitz, N. Elliptic curve cryptosystems. Math. Comput. 1987, 48, 203. [CrossRef]

Publisher’s Note: MDPI stays neutral with regard to jurisdictional claims in published maps and institutional aﬃliations.

© 2020 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (http://creativecommons.org/licenses/by/4.0/).