dRAIN: A Distributed Reliable Architecture for IoT Networks

The rapid increase in the number and variety of smart devices connected to the Internet has increased the need to ensure resilience, reliability, and traceability when transferring data within the current Internet of Things (IoT) network. The adoption of distributed ledger technologies (DLTs) can provide data with the above-mentioned features, but the low scalability and high cost related to the adoption of classical DLTs, like the blockchains, results in ineffective integration with most of IoT systems. Conversely, other DLTs, directed acyclic graphs (DAGs), possess benefits comparable to those of blockchains without presenting most of the limitations that prevent their application in the IoT domain. Therefore, we present dRAIN: a distributed Reliable Architecture for IoT Networks. The adoption of this architecture can grant the communication, management, supervision, and updating of distributed IoT devices, guaranteeing the resilience of the system and the reliability and traceability of exchanged data. In order to test the scalability potential and to assess the actual limitation of the proposed architecture, we developed both a physical and virtual (simulated) Proof of Concept. The results of our analysis show adequate execution times for the operations, guaranteeing high levels of security with acceptable performance, and prove the architecture suitable for most IoT applications that do not require to process external data in real time.

dRAIN: A Distributed Reliable Architecture for IoT Networks possess benefits comparable to those of blockchains without presenting most of the limitations that prevent their application in the IoT domain [2], [3].Since 2019, the scientific community has been addressing the issue of the integration between DAG-based DLTs and IoT.After demonstrating the potential benefits of the union between the two [4], [5], [6], the DLT that best fits the requirements of IoT applications has been identified with IOTA [7], whose scalability has been experimentally demonstrated [8], [9], [10].In this work, unlike previous cases, the aim is to provide a complete architecture that is endowed with digital identity and can connect devices that are not known beforehand.In particular, the objective of this work is to design an architecture for IoT systems based on DLT with a focus on security, reliability, traceability, and decentralization.Therefore, we present a distributed Reliable Architecture for IoT Networks (dRAINs).In the proposed architecture each device self-certifies its digital identity on the DLT according to the decentralized identifiers (DIDs) standard.Furthermore, the functionalities developed concern communication, management, supervision and updating of IoT devices.Starting from our previous work [11], which presents our proposed communication framework, in this work we present the complete architecture and a fully functional Proof of Concept (PoC) enabling to assess pros and cons of the proposed solution.This article organization follows a top-down structure: starting with an overview of the state-of-the-art associated to networks architecture for IoT devices, then moving to the description of the general architecture.More in detail, Section II presents the state-of-the-art on DLT, focusing on those supporting directly or indirectly IoT applications.Then, it describes both DAG-type technologies and solutions more akin to classic blockchain.Next, Section III describes related work allowing us to make a brief analysis of the pros and cons of literature approaches, highlighting the differences introduced by the proposed architecture.Finally, Section IV to introduces dRAIN, first giving a general description of it, then explaining the actors that cooperate in it, and finally providing its functional description.After that, Section V presents the PoC of the architecture.The proposed PoC is divided into two stages: testbed of the communication and supervision protocol and simulation of the interaction between the devices and the DLT.For this reason, Sections V and VI show and analyze the results maintaining the division between testbed and simulation.Eventually, Section VII ends this article with our final remarks on the possible adoption of the proposed architecture.

II. DLTS FOR THE IOT
DLTs were designed primarily to enable the exchange of value or to record information; conversely, today they are increasingly being developed for different purposes.Moreover, almost all DLT projects tend to be identified under the name of blockchain.However, this can sometimes cause confusion by making people imagine the structure of the decentralized ledger as a chain of blocks, which is not always the case with today's solutions; or it can lead to think about the classic problems that traditional blockchains have with the IoT integration, such as limitations in terms of scalability and latency.This limitation can be overcome through the adoption of different DLT strategies such as the DAG ones.In order to point out the main differences; a classical blockchain and a DAG are both decentralized data structures used for secure and transparent record-keeping, but there are some key differences between them.A classical blockchain is a linear chain of blocks, where each block contains a list of transactions and the hashed representation of the previous block.This creates a secure, tamper-proof chain of data that can be audited and verified by anyone in the network.A DLT-DAG, on the other hand, is a direct acyclic graph data structure in which nodes represents transactions or group of transactions and arcs represents confirmations.Nodes can be stored and managed by different entities that perform in parallel all the protocol steps required to have a coherent, scalable, and tamper-proof representation of the stored information.In summary, while both classical blockchain and DAGs aim to provide a decentralized and secure ledger of data, they differ in the way they organize and confirm transactions.In the following, we present the most promising DLT projects in the field of IoT-generated data flow monitoring and management.For a more detailed description we suggest these readings [12], [13], [14].
IOTA is a next-generation network, created to be lightweight and used in the IoT.IOTA's distributed ledger is named the tangle, this is a software protocol based on DAG and different from the blockchain protocol.
The innovation of the tangle is that transactions are processed in parallel, this allows IOTA to scale in direct proportion to the growth of the network.There is no mining or a central chain in IOTA, so tangle's transactions are confirmed asynchronously.The tangle stores the transactions in a DAG structure to reduce space and also to accommodate the limited resources of embedded devices.
In order for nodes to get their transactions approved, they must approve at least two other transactions first.This makes the transactions feeless and also means that there is no need for miners in the system.Without miners, it can be argued that the system has less incentive to grow.The specific aim of the network, i.e., enabling data exchange by IoT devices, should be a sufficient incentive for the emergence of the ecosystem.Furthermore, nodes can decide for themselves which transactions to approve.This can prevent certain transactions from being approved.Therefore, currently a coordinator that decides the order in which transactions will be approved is currently used.
In the last four years, the network has evolved in such a way that it can no longer be represented by the tangle alone.In fact, the IOTA network is now made up of several chains implemented on different levels, each with its own characteristic features, able to communicate more or less easily between each other.Moreover, the continuous evolution of the network has led to the emergence of other chains and services linked to the tangle.These include the contract chain, Shimmer [15].On the latter smart contracts updates their state on every request and on each of these state updates a new block is added.All these updates are collected and confirmed in one block.So the chain also contains all the past states.The chain can contain many smart contracts, all working on the same global state of the chain [16].Therefore, we can argue that the contract chain is essentially a blockchain anchored on the tangle.IOTA also allows the publication in the tangle not only of transactions but also of messages, which grants an increased speed of transaction approval and offers a quick method of entering information into the tangle, as shown in more detail in [17].Furthermore, Bhandary et al. [18] demonstrated tamper-proof and secure transferring of IoT sensor data using the masked authenticated messaging (MAM) of IOTA ensuring data confidentiality and data authentication.
Another IoT-oriented DLT project is IoT chain.IoT chain uses a DAG structure similar to the tangle and also uses simplified payment verification (SPV) to facilitate operations on smaller devices.IoT chain also uses practical Byzantine fault tolerance (PBFT) to ensure fast consensus.Despite these benefits, the primary limitation of IoT chain is the requirement of a specific operating system and linking module [19].But despite a promising start, the follow-up of this project in recent years has been lacking, with the company itself not being seen on social media for two years.
Despite being based on a different technology than the above-mentioned solutions, IoTeX is also a DLT that aims to be deployed in the IoT world.IoTeX is a network of many blockchains arranged hierarchically, that can work in parallel with each other while maintaining interoperability [20].In the IoTeX ecosystem, the root blockchain manages many independent blockchains, or subchains.A subchain connects and interacts with those IoT devices with which it has something in common, e.g., they have a similar functional purpose, operate in similar environments, or share a similar level of trust.If a subchain malfunctions, e.g., if it is attacked or a software bug occurs, the rootchain remains completely unaffected.In addition, interblockchain transactions are supported to transfer value and data from subchains to the rootchain, or between subchains via the rootchain.In addition, this system uses the consensus algorithm of the randomized delegated Proof of Stake.
Obyte (formerly ByteBall) aims to create a commonly accepted smart-payments network, made possible with the adoption of DAG technology incorporated with features, such as peer-to-peer (P2P) insurance prediction markets, P2P betting, P2P payments via text messaging, bot stores, blackbytes for private transactions, etc. [21].In the Obyte DAG, each transaction references one or more previous (parent) transactions.Every transaction is identified by its hash, and by referencing parent transactions, a child transaction also includes their hashes.This is similar to the way the next block in a blockchain includes a hash of the previous block but the links are between transactions, not blocks, and there can be more than one parent.After a new transaction is added to the DAG, it quickly gets children's transactions that include its hash, then grandchildren, and the number of future transactions that include it directly or indirectly grows exponentially.
To date, the system works with entities called order providers who are responsible for posting regular transactions on the DAG.This is made in order to ensure that a complete node can determine the correct order of each transaction.It also implements a system to regulate and accurately predict fees due to data transfer.For example, if a transaction's data consumes 800 bytes of disk space, the fee to submit that transaction to the DAG will be 800 bytes of the currency, which is about $0.00001 at the current rate [22].It now also features tools for automating payments between IoT devices and the possibility of creating payment channels.It also offers the possibility of exchanging information in a private chat system between users participating in the network.
In Table I we summarize the main features, to compare the DLT technologies specifically designed for the IoT world, such as average time for transaction approval, smart contract compatibility, the market cap, and if they are hardware related, i.e., their adoption strictly depends on the use of specific hardware.

III. RELATED WORK
Given the strong requirements in terms of data security and inalterability imposed by the use of IoT technologies.Many research groups have questioned the possibility of exploiting blockchain or other DLTs technologies to meet these requirements.Therefore, a number of papers have been published that attempt to address this issue.
Among these, we can identify four main approaches, for which we present the pros and cons to allow the comparison with dRAIN.The first involves the implementation of a permissioned or permissionless blockchain system.This is the case of [24].In which the authors propose a trust-based architecture designed on public and private keys that exploits the blockchain as a validating element of the system.A similar solution is proposed in [25].The authors showcase the potential of using blockchains for IoT devices and data management to achieve end-to-end trust in trading.They do so by implementing both a permissioned and permissionless blockchain on the hyperledger fabric network.However, this approach has two drawbacks.First, in a permissionless blockchain built on classical blockchain technology, all actions on the network are subject to fee costs.Second, in a permissioned blockchain, the network lacks the decentralized properties typical of a blockchain.
The second approach involves the combined use of software defined networking (SDN) and blockchain technology.This is the solution adopted in [26], in which the authors proposed an architecture that automatically adapts to the threat landscape, without administrator needs to review and apply recommendations manually.This is achieved through the combined use of a secure SDN and the blockchain technique.The solution, however, focuses attention toward the mitigation and detection of attacks using the blockchain to update or check the flow rules used by the nodes and it does not use the blockchain to exchange verified data between them.
The third approach involves the use of blockchain combined with a distributed architecture on fog and cloud layers.This is the case of the choice made by Hao et al. [27].In which a double blockchain approach for secure information and reputation data management in large-scale wireless IoT networks is presented.Their solution involves the use of a blockchain for reputation on a fog computing layer and a second blockchain used for information on a cloud layer.They have also investigated in [28] the scalability and the performance of their architecture.
The fourth approach involves the use of DAG technologies to manage the data flow between devices.This solution was adopted by in [29] in which, using the IOTA network, the communication between two Bosch XDK110 multisensor kits was enabled.Obviously, there are a few other cases that fall outside the classification and can be listed individually.Indeed Rathore et al. [30] presents a hybrid solution based on either SDN, blockchain, and an edge and fog computing approach.Their solution is able to detect malicious attacks on the IoT network, through the use of the aforementioned technologies.Moreover, Reilly et al. proposed in [19] an approach with a focus on data integrity to enable communication of IoT devices in a smart city perspective.In their work, they focused mainly on the communication aspect, implementing a light client on the Ethereum network.
Although all these approaches achieve satisfactory results in many aspects, they all share a possible single point of failure.Moreover, they cannot ensure that the data collected by edge devices is untampered and that the devices are still transmitting correct data.dRAIN overcomes these limitations by incorporating a root-of-trust system directly onto the edge device.This not only provides security for the data through digital signature mechanisms, but also enables Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.monitoring and updating of the device's firmware if necessary.In Table II we summarize the differences and clarify the comparison between the architectures described in this section and ours.

IV. DESCRIPTION OF GENERAL ARCHITECTURE
In this section, the network architecture of dRAIN is described in a general way.In the presented architecture all critical operations will be performed by the secure part, while the nonsecure part has the main task of acting as an interface to and from the outside world.First, the structure of the network will be examined.The elements required for this approach to work will also be defined, furthermore, these elements will be identified within the associated necessary technologies.Next, the roles and characteristics of the main network entities that interact in the system will be defined.Finally, the functional aspects will be analyzed, describing how to perform certain operations.

A. IoT Architecture With DLTs
In the IoT field, a system is composed of three main components: 1) edge; 2) fog; and 3) cloud.Following a DLT approach, the cloud could host the DLT itself, thus, bringing all the properties of the latter, such as reliability, total traceability, immutability, and auditability.The fog could include the DLT nodes, which are interchangeable, distributed, and highly redundant, providing a decentralized access point to the network.In fact, there is almost no real difference in using one node over another to access the DLT network, the only one being the reliability of the individual node.Owning a reliable node solves the trust problem, however, it introduces a single point of failure into the system.Therefore, it would be wise to own a set of trusted nodes and rotate the tangle access point from time to time.Furthermore, reputation mechanics allow one to quantify the trustworthiness of a generic node in the network.This allows the use of nonproprietary nodes by relying on a global reliability metric with some degree of confidence.The devices together represent the edge of the system.They are the source of the data that is forwarded to the nodes and subsequently to the DLT.Therefore, all the characteristics of security and reliability of the network are lost if they are compromised.It is evident that the devices represent the first element of a chain of trust that is reinforced by the characteristics of the DLT technologies.However, if the first link of the chain is broken, the chain itself is not able to guarantee anything.Therefore, it is necessary for the devices to behave as a root of trust (RoT), sources of reliability that can then be propagated throughout the system.This can be achieved by coupling the computational capabilities of the devices to a trusted execution environment (TEE) using technologies, such as the Arm TrustZone or a trusted platform module (TPM).A TEE ensures that all critical operations handled by the device are performed from a secure element that is not directly accessible from the outside.Once the devices have been secured, the network must provide services to enable their operations.There are four main components that are required for the system to function properly.
1) Data Communication Layer: To enable traceable and customizable communication between devices and/or entities.2) Digital Identity Provider: To facilitate authentication between devices, enhance traceability and make clear the identity of a device on the network, preventing any identification bias.3) Digital Signature: To ensure ownership and integrity of the published data, is also mandatory to achieve digital identity.4) Distributed List of Devices: To enable tracking and classification of devices roles in the network, it acts like an access point to the network allowing devices to know who should connect with; it also binds in an unambiguous way every device ID to its digital identity ID.In DAG-DLTs digital identity could be easily provided by the DIDs standard by world wide Web consortium (W3C).The data communication layer, on the other hand, should be specifically designed on a higher level of abstraction than the transactions' ledger.In the proposed framework communication is modeled to be asynchronous.Each one of the devices possesses a level-2 data channel where it can publish and read any data, much like a topic in MQTT.When the channel identity is uniquely bound to the device identity through DID, communication can be easily achieved.The DIDs standard states that each identity is associated with a document distributed on a DLT, which is accessible through an URL.To enhance automation and discovery between devices, the distributed list of them should also be published and constantly updated on the ledger by a trusted entity with a certain degree of authority.Thus, devices will be able to interact autonomously with dRAIN without the need to know each other beforehand and without the need to engage a direct communication, as depicted in Fig. 1.

B. Network Entities
Following the introduction of the proprieties owned by the elements composing the network architecture we now shift our attention to network entities, which may or may not have a corresponding physical element in the architecture.The main entities envisioned by the proposed framework are as follows.
1) Edge Devices: Physical devices that possess a digital identity distributed over the DLT.They operate by collecting data and publishing it through the specific data communication layer defined on the DLT.Each device has its own communication channel through which it can communicate with other devices and publish diagnostic logs or informations about itself.These are secure devices that possess cryptographic capabilities in order to manage the authentication processes related to their digital identity.2) Supervisor: Is a decentralized entity identifiable in a smart contract or a nonstatic committee of devices (different from the edge devices).It is responsible for evaluating the operational state of edge devices based on rules defined at the outset, publishing its output on the ledger.It provides noncentralized information management regarding devices, thus, operating a first stage of decentralized data analysis.This is very important to add value and usability to the data directly on the ledger.It possesses a digital identity distributed over the DLT and can also have its own communication channel.By providing an opinion about the operational state of the devices, the supervisor indirectly introduces authority in the network.However, being a decentralized authority, it does not represent a single point of failure.3) Authority of the System: Abstract entity that administers the system by managing its operating rules.It can represent the owner of the IoT service or the owner of the devices.Talking about authority may seem contradictory in a decentralized system as it seems to expose an obvious single point of failure in the system.However, in this case, the authority is not an active component in the processes but is only responsible for setting the rules without participating in the operations.It is not an always-online component, it cannot be reached by others and it is controllable only by those who possess its private cryptographic keys, i.e., the owner of the system or the person acting on their behalf.It interacts with the system by entering instructions directly on the DLT ledger and has a DID to claim its identity.It can also have its own communication channel on the DLT; 4) HW/SW Producer: It is the manufacturer and manager of the hardware or firmware of the edge devices.In general, it does not coincide with the owner of the system authority, since the network services may not necessarily be offered by the same institution that manufactures the edge devices.It holds a DID on the DLT with which it certifies its identity unambiguously, offering services to update components in a verifiable and authentic manner.It may have its own communication channel on the DLT, but this is not a critical feature; 5) Stream Channels: They are the channels on the DLT in which the devices post and read information, following a stream protocol, and it is identified through the use of the ChannelID.They represent the basic structures that constitute the communication layer on the DLT.In order for the device to get granted access to the channel, the channel author has to verify if the device is in the devices list and then give the ChannelID to the device that wants to log.

C. Functional Description
In this section a functional description of the architecture is given, explaining the system operations and the interactions between the various entities of the network.The following schemes of operation are presented as possible options, in other real-case implementations they could be defined in different ways and still be functional.Therefore, the purpose of this section is to demonstrate the feasibility of the operations and to abstractly describe the interaction algorithms developed in the PoC.The functions of communication between devices, supervision and management of devices, and updating of devices will be analyzed.But in order to better understand them a brief description of the actors of the proposed framework is reported in Table III.
Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.

1) Communication:
The communication between devices is managed through an asynchronous logic of subscription to the channels of individual devices.A subscriber who wants to receive data from an author must first find the coordinates of his DID-Document from the list of devices on the DLT, and then proceed to send a subscription request.The author will then verify the identity of the subscriber and will only accept the request if the device is on the list.After the subscription, the subscriber will be able to receive data directly from the author's channel, until the possible revocation of the reading rights.The procedures of subscribing and exchanging messages is represented in Fig. 2. 2) Supervision and Management: Supervision and management of the devices are achieved thanks to the supervisor and authority entities.In a first phase, the authority will configure the supervision rules adopted by the supervisor and will provide the devices with the permissions to use the system (e.g., special tokens).The device, authorized by the authority, will ask the supervisor to be added to the device list, consuming its special permission.Once in the system, the device will publish diagnostic logs on its channel that can be read by the supervisor.The supervisor will proceed to analyze the logs, confirming the good operational status of the device.If the logs are absent or invalid (according to the rules set by the authority), the supervisor will disapprove the operational status of the device, possibly sending an alert to the authority owner.The procedures of device initialization and supervision is represented in the diagram depicted in Fig. 3. 3) Update: Regarding the updates, the firmware manufacturer is expected to possess and manage its own DID, providing an endpoint for certified and secure download of the update.This DID-Document provides also information on the latest firmware version.This information can be as simple as an alphanumeric code, or as complex as the hexadecimal output generated by hashing firmware binary itself.By occasionally checking this DID-Document and comparing the firmware version indicated with the one owned, devices will understand if they are running an outdated version.At this point, it is sufficient to use the download link from the manufacturer's DID-Document to be sure that downloading is achieved directly from the official and reliable source.A secure end-to-end protocol like TLS can be used to ensure privacy and security for the communication, as the provided link could direct to an off-ledger source.Once the file has been downloaded, signature verification will be performed with the public key present on the manufacturer's DID, installation will follow if the signature is valid.Should the device be compromised and willingly not updating its firmware, the supervisor will notice this by analyzing the device logs.Once a certain time window has passed, a log with an outdated firmware version will be considered invalid, with all the consequences described in the management and supervision function.The supervision rules must, hence, be updated by the authority

V. PROOF OF CONCEPT DEVELOPMENT
In this section, we analyze how the PoC of the architecture, described in Section IV, has been implemented.Our PoC consists of two phases: 1) the development of a testbed for the communication and 2) the supervision aspect and the development of a simulation of the system in order to test its scalability potential.

A. Testbed
Starting with the testbed of the communication and supervision.Our implementation has been carried out using the IOTA DLT, described in Section II.This DLT, besides having the advantage of offering great scalability and allowing free data publication, offers the tools to implement three of the four components required by the architecture, which were defined in Section IV.The data communication layer can be implemented through IOTA streams, a library written in Rust that allows the creation of communication channels that follow an author/subscriber logic.The digital signature scheme used by IOTA is Ed25519, and DLT offers the tools to write and verify these signatures directly through its Client library, available in various languages, including Rust and Go.Finally, digital identity via DID is made convenient through the use of the IOTA identity library, written in Rust, which enables the creation and management of DID-Documents and the use of verifiable credentials.The PoC also includes secure hardware to represent the trusted IoT device.The ARM TrustZone is a technology that partitions the execution environment at the hardware and software level into two sections, one secure and one nonsecure.Therefore, it was chosen as the enabling technology for a TEE.Hence, hardware equipped with that technology was chosen and configured ad hoc.All operations exploit the IOTA network as shown in Fig. 5.
Furthermore, as far as the implementation of the supervision protocol is concerned, even if on the one hand the immaturity of IOTA's smart contract network, Shimmer, compromises its proper use, on the other hand, IOTA's choice to implement the Ethereum virtual machine (EVM) directly in their smart contract chain allowed us to develop a fully compatible set of smart contracts on an Ethereum private network.
The following materials were used for the development of the testbed.
1) The IoT device was implemented using Discovery kit B-U585I-IOT02A from STMicroelectronics equipped with STM32U585AI microcontroller certified to PSA level-3 security level, ultralow-power, with 32-bit ARM Cortex -M33 architecture, cryptographic accelerators and ARM TrustZone; the C++ libraries STM32Cube Expansion and Curve25519 were used for cryptographic operations.2) IOTA as a DAG-DLT together with the two software libraries written in Rust, IOTA Identity (for generating and managing DIDs according to the W3C standard) and IOTA streams (for creating and managing communication channels on the register).3) STM32CubeIDE and STM32CubeProgrammer are the software used to configure the microcontroller.4) Remix, Ganache, and Web3 are the frameworks used to develop the supervision process.5) MATLAB R2021b is the software used for data analysis.
Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.A computer equipped with AMD Ryzen 5 3600X 6-Core 3.80 GHz processor and 32 GB of RAM memory was used to simulate the subscriber device and analyze the data.
In our testbed, the B-U585I-IOT02A is the RoT of the system, as such it has been set up to behave like one.To ensure this behavior the following steps have been taken.
1) Configuration of a TEE based on Arm TrustZone with secure boot secure firmware update (SBSFU) framework to secure signing, communication, boot, and update.2) Implementation of cryptographic signing and verification with Ed25519 scheme.3) Programming of a routine to generate and sign 3 bytes data.An IOTA Client acts as an intermediary between the RoT and the tangle, receiving data from the RoT and forwarding them to the DLT.The client manages the digital identity, the stream channel, communicates to the device list its DID URL, and shares/reads data on the tangle.In the developed PoC an author device sets up its identity and stream channel.It provides the channel ID inside the service section of the DID-Document.It is added to the device list and starts publishing data.In the meanwhile a subscriber device sets up its identity and is added to the device list.Then the subscriber checks the list to find the author's DID URL, which is resolved into the author's DID-Document.The subscriber will send a subscription request to the stream channel appointed in the service field of the author's DID-Document.The author then sends the request by checking the subscriber's trustworthiness inside the device list.When the subscription is accepted the subscriber starts receiving all the data published by the author on the ledger.In this PoC the author is directly associated with the HW RoT whereas the subscriber does not have a hardware base, it is just a process that simulates the behavior of another device.The PoC follows the procedure defined in the sequence diagram presented in Fig. 2 while also implementing a simplified device initialization like the one in Fig. 3.The authority of the system and the firmware update have not been included, however, the hardware has been configured to be fully compatible with a secure firmware update.
In order to develop the supervision protocol in a completely automated and decentralized way.We implemented an oracles committee written as a smart contracts system.Smart contracts are code containers that encode and mirror real-world contractual agreements in the cybernetic realm.A fundamental premise for smart contracts is to represent a binding agreement between two or more parties, where each entity must fulfill its obligations under the agreement.This is ensured by the automatic execution of distributed code run and verified by nodes of a distributed ledger network.
The actors envisioned in the supervision process of the PoC are as follows.
1) IoT Device: Its role is to publish on the tangle the data from the sensors connected to it.2) Device Owner: It performs the task of subscribing his devices to the supervision system.3) Oracles Committee: It guarantees the bidirectional transfer of data from the stream to the smart contracts.We can moreover recognize three phases throughout the supervision process.
1) Device Registration: At this stage, the device owner subscribes to the device by calling a particular function.This function passes a string parameter identifying the device's DID URL.After this, the oracular committee will receive the DID URL and through this will subscribe to the device channel.2) Correct Hash Setting: Once the DID URL is acquired, the oracular committee will takes the first log published in the log stream branch, fetches the content hash (assumed correct at the time of the request to the service), and calls a specific function to add the hash.

3) Periodic Check of the Last Log Published by the Device:
Periodically the committee of oracles wakes up by taking the current hash from the last log of the device.This hash is provided to the Smart Contract that then evaluates its correctness and return the result in the form of a boolean value (true if the hash is correct, False if the hash is wrong).This result is then published in the stream configuration branch.The necessary steps for the development of the supervision framework are as follows.
2) Development of the simulation of the device operation flow.3) Development of the simulation of the oracles committee operation flow.4) Deploy the Smart Contract and test the interactions between the constituent parts of the PoC.

B. Simulation
In order to test the scalability of our solution and understand how approval times and confidence rates varies in relation to the tangle configuration, we developed an event-driven simulator that implements all the interactions between the devices and the DLT.In particular, the simulator implements: two message generators, the swarm of nodes, and the tangle.
The simulation objects are as follows.
1) The useful-message generator that is the actor in charge of posting to the nodes all the useful transactions, therefore, all the transactions that have to be tracked in the tangle.
2) The spam-message generator that is in charge of posting to the nodes transactions not related to the process of interest and aimed at simulating coexistence with third-party applications and their impact on measured performance.
3) The swarm of nodes, consumes incoming messages in a first in first out (FIFO) order, posting them as transactions in the DAG structure.Any finite number of nodes can be instantiated.In the end, to model the Tangle we decided to base our simulation on the one presented in [31].This system element allows to anchor transactions to each other following the tangle construction rules and allows us to gather information about the waiting time required to insert the transactions into the tangle.The simulation software was developed in the Python programming language using various libraries, including simply to develop the simulation entities.The functions required to run the simulation are available on github. 1ll entities in the simulation have tunable parameters.For the message generators, these parameters are the ones that compose (1).Where T bm represents the time elapsed between the sending of two messages, m v represents the multiplicative value, and a v the additive factor These parameters are used to make T bm assume values compatible with those expected in application contexts of interest.
As far as the swarm of nodes is concerned, the tunable parameters are: N n that represent the number of nodes developed, as previously mentioned, and I t , the number of initial transactions to be instantiated in the DAG.As far as the DAG type structure is concerned, we have chosen to leave as input parameters λ, which is the transaction rate chosen in set {10, 50, 100}, and the value of α, the multiplicative factor used in the computation of the random walk chosen in the set of values {10 −1 , 10 −2 , 10 −3 }.The flow of operations performed in each simulation can be summarized in three steps.
1) Tangle Initialization: Transactions are posted on the tangle in order to start filling the structure, so that it can achieve a more stable behavior and avoid the effects due to the initial anchoring to the genesis transaction.2) Timer Start: Once an I t number of transactions have passed, the simulation timer starts running.At the same time, the message generators start posting transactions and the nodes in the swarm start consuming them, when available, publishing transactions in the tangle-like structure.3) Operational Status: The simulation continues by iterating the steps expressed in the previous point until the simulation time runs out.It was chosen to run the simulation for a total of 5•10 8 timer steps where each simulation step corresponds to a millisecond.Simulations differ in the amount of spam versus useful messages, and the ratios used in the simulations are {100:0, 50:50, 33:66, 25:75, 20:80, 10:90} where the couples num1:num2 represents indeed the relative amount of useful messages over that of spam messages.

VI. RESULTS AND ANALYSIS
In order to optimally present the results obtained and their respective analysis, it was decided to stick to the same structure presented before, thus, dividing them into two separate subsections.

A. Testbed Results
The test is performed on the IOTA Mainnet and carried out using two separate Clients, each representing a different IoT device, i.e., an Author in charge of publishing data on the tangle and a Subscriber in charge of receiving and verifying them.Acquisitions were made on the clients at 15-min intervals for 7 days.The collected samples record the timing of micro-operations conducted in the following phases: initialization, communication setup, and communication.In addition, the hardware performances concerning the operation of digital signature of the message were collected.Regarding the analysis of times, the mean value, standard deviation, and standard error of the collected times were considered.The samples of the operations involving a publication on the tangle follow an exponential distribution as visible in Fig. 6 while the other timings have Gaussian distributions.
Moreover, our analysis shows that there are no significant changes in performance over time indeed the times remain similar during all seven days of the testbed.Table IV shows the times of partial operations, aggregated in the various phases of communication in the first column.The other columns show the values calculated for each phase to provide an estimate of the performance of the final system.It should be noted that in the test the communication consists of five messages.
Hardware performance was measured for the action of signing or verifying a message, as shown in the first column of Table V.
For each action, we evaluated performance for various modes of operation, represented by the second and third columns of the table.The collected times are shown in the last column and can lead to an estimation of the execution time in a final implementation.The estimated data have been highlighted in green.
The exponential distribution of publication-related transactions is attributed to IOTA's transaction validation method, the weighted random walk.This method assigns weights to the transactions to be approved and makes a pseudo-random choice.The probability that a transaction Y, which validates a transaction X, is chosen by the algorithm is exponential and related to where z ∈ Z which is the set of transactions that directly validate X, Hx, Hy, and Hz are the cumulative weights of X, Y, and Z, and α is the parameter that governs the importance of the weight.Once α is fixed, given the experimentally demonstrated almost direct proportionality of the CTPS-TPS ratio (confirmed transaction per second), the validation times are stable in a certain range as the number of nodes increases.Therefore, the values collected in the test could be partly representative of those that would be found in a more populated network.

B. Analysis
In order to investigate the actual possibility of implementing the proposed architecture on other types of DLT, in addition to DAGs, it was necessary to analyze the implementation and operating costs related to the interaction with the decentralized network.To perform a transaction on classical blockchains like Ethereum, there are fees to pay, these fees are expressed in gas unit.A simple way to estimate execution and transaction costs is offered by the MetaMask portfolio.The formula that is automatically applied by this portfolio is expressed in where Q represents the cost of the operation, G is the gas units that by default is set to 21 000, B f is the base fee, and Tip is dependent on the transaction to be carried out and the unit of measurement associated with it is the Gwei (10 −9 Ether).The execution cost represents the associated costs to interact with the functions of the Smart Contract.The following Table VI shows the cost in Ether needed to deploy the Smart Contract and those related to the call of the functions that constitute it.In fact, not all functions require a gas charge for execution, just writing transactions on the blockchain requires gas.This means that calling a contract to view data does not involve the payment of gas.
Making a conversion between the costs in Ether reported in euro you can see that a system of this type in a classic Ethereum network is not feasible.This is not mainly due to the high cost of deploying the Smart Contract but rather to those functions that must be called periodically to check the device.The defined architecture does not suffer from such a problem because can be implemented on any DLT-type structure.The high costs, however, especially, with respect to recursive function calling, limit the applicability of dRAIN to DLTs that require low costs to perform operations on the ledger.This is the case of IOTA Smart Contract in which you can define a consortium network where the manufacturer of the chain can decide the introduction and the corresponding value of gas and fees.This allows the system to operate periodically keeping costs under control.

C. Simulation Results
For a deeper understanding of the results obtained from the simulation, it is necessary to briefly explain how transactions are considered in the tangle.A transaction n within the tangle can be in one of three possible states.
1) Tip: If no other transaction has ever approved it.
2) Approved: If at least one other transaction has chosen transaction n as the transaction to be anchored to in the approval process.3) Confirmed: If the confirmation confidence of the transaction is not below a predefined level, normally set to 100 for a transaction posted by an unknown author.The transaction confidence can be computed, following these steps, according to [32] and [33].a) Run the tip selection algorithm N times at a given time instant, t. b) Let i be one of the tips in the tangle at instant t, and n i the number of time in which i has been selected after launching N times the tips selection algorithm.c) Given a transaction j, let A j be the set of transactions that directly or indirectly approve j, the confidence of the transaction j will be After running the simulation in 216 different configurations, we extracted for each transaction in each simulation the following data.The confidence dictionary contains for each transaction chosen during the execution of the above-mentioned algorithm the number of occurrences.From this raw data, it was possible to calculate for each transaction the time elapsed from its input into the tangle until the moment of approval.Furthermore, thanks to the use of the confidence dictionary and the information about the directly approved transactions, it was possible to extract information on the confidence status of each transaction already in the DAG each time a new one was entered.We further checked whether if as the number of transactions entered into the tangle like structure increases, the total number of tips and approval times continued to rise or reached a plateau.Our results show that the DAG-type structure achieves stability in a limited number of transactions, and that its approval times are inversely proportional to the rate at which transactions are entered into the system.This argument can be made for both tip and approval times, as can be seen from the cumulative distribution in Fig. 7.
Furthermore, we can see that using a different number of consumer nodes or varying the α of the tangle does not produce a noticeable change in the distribution of approval times.While for the α parameter, the aforementioned depends precisely on the properties of the tangle itself, for the number of nodes this is due to the difference in speed between the publication of a new message in the FIFO queue when compared with the entry time in the tangle of the single transaction.This is because of the limited Proof of Work time that IOTA requires for the release of a new transaction.These considerations can also be made by analyzing the Table VII that reports the average approval times at the end of each simulation.We can also note that the increasing presence of spam messages and, thus, the consequent greater number of transactions entered into the tangle allows for faster transaction approval times.
In Fig. 8 we show the results in terms of the total confidence level, defined as the percentage of transactions with a confidence level of 100%.The graphs report the comparison of the most different tangle arrangements divided into six groups calculated as the average of the results obtained for the simulations that have the same number of spam message generators, respectively: 1) group 1 0% spam message; 2) group 2 50% spam message; 3) group 3 66% spam message; 4) group 4 75% spam message; 5) group 5 80% spam message; and 6) group 6 90% spam message.The simulations showed very good results with regard to the number of transactions required to pass 88% of total confidence level.A strong correlation is observed between the tangle rate λ and the total confidence level, this is shown by the two opposite ends configurations: λ of 10 and α of 10 −1 ; λ of 100 and α of 10 −3 , that reached the 88% of confidence level after the first 1000 transactions and 16000 transactions, respectively.A difference of an order of magnitude between both the number of transitions and the tangle rates is observed.Despite this, the number of transactions required remains small compared to the total number of transactions entered, bout equal to 5 • 10 5 .
Furthermore, we can see in the graphs of approval time versus confidence level that the first reaches a stable value for groups 6 and 5, while the total confidence level continues to rise, albeit slowly.Thus, showing a stable and scalable structure capable of improving its performance as the number of incoming messages to the network increases.
Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.

VII. CONCLUSION
In this article, we presented dRAIN a new network architecture for IoT devices.Its main characteristics are the security, the reliability, and auditability of the data exchanged.The architecture devised is based on two key technologies: the RoT and the DLT.
The former allows us to guarantee the nontamperability of the data directly from the source, and to check the operational status of the edge device.
The second, on the other hand, gives us the possibility of exploiting a secure network to exchange and record data in order to allow access to them and, thus, providing them with a commercial value.
The general proposed architecture is capable of supporting three main functions: 1) communication; 2) supervision; and 3) update.Moreover, according to the results of our PoC, the testbed showed adequate execution times for the cryptographic operations, guaranteeing high levels of security with acceptable performance.Furthermore, thanks to the simulation we were able to show that the system performs adequately in terms of transaction confidence and average approval time.
It must also be taken into account that the same results obtained would also be replicable using other compatible devices or DLTs.This is why we can say that the enormous benefit obtained, in terms of; security, scalability, traceability, and resilience is a consequence of the adoption of the architecture presented.Therefore, making the architecture suitable for most IoT applications that do not require to process external data in real time.
This only limitation is shown by the results of the testbed and the simulation, since the approval times, despite decreasing as the rate of entry of transactions into the tangle increases, still remain high and above all with a standard deviation value too high.Due to the exponential distribution nature of the approval time population.Despite this limitation that is attributable to the use of DLT technologies, the results obtained from the PoC of the presented architecture are overall satisfactory.

Fig. 6 .
Fig. 6.Histogram and empirical cumulative distribution function (CDF) exponential distribution of the publication time.

1 ) 3 )
Transaction Approved: The set of transactions approved directly by the current transaction.2) Read Time: The simulation time in which a node consumed the current transaction from the FIFO broadcast queue.Tangle Insertion Time: The time elapsed with the busy node in order to enter the current transaction into the tangle, corresponding to the time required to perform the PoW and the weighted Random walk.4) Counter of the Lecture: Equals the number of reads made by the nodes up to the current transaction, differing from the transaction number by m.Where m is the number of transactions deployed in step 1 of the simulation in the tangle.5) Sender: It is undefined for all the initial I t transactions.It then assumes different values if the sender of the current transaction is the useful message generator or the spam message generator.6) Node: It is the integer number representing the node in charge of posting the current transaction in the tangle.7) Confidence Dictionary: Each time a new transaction is entered, the tip selection algorithm is executed N times.

Fig. 7 .
Fig. 7. CDF value of the approval times in seconds comparing the most divergent simulation values.The simulations are divided into four sets, to show the variation in the approval times population related to: (I) the number of message generators; (II) the number of consuming nodes; (III) the tangle rates λ; and (IV) the α values.Each simulation is identified in the legend as a tuple like object: (α, λ, number of nodes, and number of spam generator.)

Fig. 8 .
Fig. 8.Comparison of the most different tangle arrangements, λ of 10 and α of 10 −1 for the first row and λ of 100 and α of 10 −3 for the second.3-D graphs are shown with axes: average approval time, number of tips, and percentage of transactions with 100% confidence.Each 3-D graph is associated with two of its projections.The graphs show the trend of the tangle up to the confidence level above 88% for each group of simulations represented.Each group is calculated as the average of the results obtained for the simulations that have the same number of spam message generators, thus: group 1 = 0% spam message till group 6 = 90% spam messages.

TABLE I COMPARISON
OF DLTS SOLUTIONS FOR IOT IN TERMS OF: AVERAGE APPROVAL TIME, HARDWARE DEPENDENT, SMART CONTRACT READINESS, AND MARKET CAP

TABLE II COMPARISON
OF DRAIN WITH THE STATE OF THE ART ARCHITECTURAL SOLUTIONS IN TERMS OF: APPROVAL TIME VERSUS ARRIVAL RATE, SCALABILITY, DLT TYPE, PERMISSION LEVEL, SECURITY FROM THE SOURCE, AND SECURITY DURING DATA TRANSIT

TABLE III TABLE CONTAINING THE
LIST OF ACTORS AND THEIR ROLE AS ENVISIONED IN THE FINAL ARCHITECTURE

TABLE IV TIMES
OF THE FINAL SYSTEM

TABLE VI FUNCTIONS
COSTS OF THE SMART CONTRACT WITH ASSOCIATED FREQUENCIES: ONE TIME FOR DEVICE (OTFD); ONE TIME ONLY (OTO); AND EVERY DEVICE CHECK (EDC)

TABLE VII REPORTED
ALL THE MEAN TIME OF APPROVAL EXPRESSED IN SECONDS FOR EACH OF THE 216 SIMULATIONS AT THE END OF THEM THEREFORE, AFTER THE TANGLE REACHED STABILITY