## 3 System Architecture and Implementation
### Architecture Metrics  
We can identify two distinct metrics that encapsulate the capabilities of the proposed architecture. Those two metrics are:  
1. Iota Transaction throughput
2. PoW  
**Iota Transaction throughput** Regarding the Iota Transaction throughput, that is, the number of transactions per second (TPS) that the network can support, we are referring to a metric that solely depends on the inherent characteristics of the protocol (IOTA) is important because it directly influences the average time that a transaction needs to be accepted by the network. The current implementation of the tangle supports a TPS of 4-5 [40] with an average confirmation time of 10 min. The Tangle is thus mature enough to support the described architecture as it offers an acceptable transaction time with no fees. Finally, this latency, although adequate for real-time transactions is bound to be decreased through improvements of the IOTA network architecture itself.  
**Proof of Work** This metric is important because it highlights and ultimately defines the scalability of the proposed system. The PoW must be done for each transaction (in the current state of the network, and for the foreseeable future). PoW can either be conducted on the hardware, which is preferable as it increases the autonomy of the IoT device, or can be offloaded to a server to be offered as a service. Latest advancements in FPGA implementation [41] of the PoW algorithm has illustrated the possibility of adding a relatively cheap dedicated PoW core to the IoT hardware, which will be able to conduct PoW in an extremely efficient manner, both in terms of time and power consumption. By implementing an FPGA array in a cloud based PoW, the cost is reduced even more, proving the architecture to be extremely cost effective even with a large increase of IoT nodes.  
Each transaction can encapsulate 1 to n data transmissions. By increasing the number of data log packets in each transaction, we decrease the required PoW (by lowering number of transactions needed to transmit the same number of information) but we also decrease the granularity of the data access (since access is granted on transaction basis). The current time needed to perform PoW is shown bellow:  
* A median computing time of 90 s on Raspberry power 3:4\(\times\) ARM Cortex-A53, 1.2 GHz [41]
* Natively on our IoT Hardware (IoT Node): Unfeasible, both in terms of time and power consumption. (M-cortex)
* On \(\times\)86 CPU (4\(\times\)cores + GPU, upgrade ccurl implementation \"dcurl\" [42]): 9 s
* FPGA implementation: 70 ms  
Each MAM message can encapsulate up to 1300 bytes of information, or 65 SDL, since each Sensor Data Log has a size of 20 bytes as dictated in the specification. In a scenario where each node emits an SDL every 10 min and there are 12,000 nodes that are used in various applications and are supported by the same backend server, the following metrics are found, in regards to data access granularity and PoW cost. In the scenario, it is assumed that each MAM message demands 3 distinct IOTA transactions to be fully transmitted (this can change in the future as MAM is still in development). The final number of transactions is enlarged by a factor of 10% in order to allow for unforeseen errors that may appear and may lead the IOTA node to re-perform PoW. Figure 14 shows on a per node basis, the amount of transactions issued per day versus the access control granularity, translated in number of SDLs that will be encapsulated into every MAM message. Figure 15 illustrates the linear increase of the daily cost to conduct PoW for the whole system, assuming that it is conducted in a centralised data center on FPGA arrays that consume approximately 8 W and the cost of 1 Kwh is $0.2.