## 6 Evaluation and Discussion
### Discussion  
We can consider two cases of a single-point-of-failure problem for a firmware update distribution server. First, when the adversary disables the manufacturer's server service. Second, when the adversary successfully modifies the firmware update. For the first case, our proposed protocol has two ways to distribute the firmware update. Thus, if at least one of the gateways has downloaded the firmware before the manufacturer has disabled it, a device can get the firmware update by downloading the firmware from the gateway with the peer-to-peer firmware update. However, without this gateway's participation, we cannot provide peer-to-peer updates. To encourage gateways' participation, manufacturers can give gateways an incentive when they successfully participate in peer-to-peer update distribution. We consider this incentive mechanism viable future work. For the second case, if an attacker wants to modify the firmware update without being detected, the attackers should have to successfully modify the firmware update and the blockchain network's transaction block. To do that, the attacker needs to control more than 50% of the blockchain network. However, it is very difficult and costly to have that amount of computing power. Thus, our proposed protocol can overcome this kind of attack. References [21; 22] proposed the idea of blockchain-based firmware update distribution. In [21], their method gives some possibility to check the firmware version before the update begins, regarding which one has a higher or lower version. However, this will later cause redundancy checking that may cause unnecessary network traffic and increase nodes' computational power consumption and operations. Besides, the method only provides showcases for firmware updates from one manufacturer instead of the various manufacturers. In fact, many IoT devices from various manufacturers will exist in an IoT environment. In contrast, our protocols support multiband firmware updates because our protocol is based on the OCF specification that supports the various IoT devices category [31]. Reference [22] has innocuousness checking nodes that check the update against bugs and known attacks every time the manufacturer releases an update. Nevertheless, before the manufacturer releases a new firmware update in our proposed scheme, a trusted party (such as certified cybersecurity companies) must have already checked it. This process will shorten the firmware updates' distribution time. These previous two solutions use Bitcoin technology. It takes around 10 min to verify a transaction and create a new block in Bitcoin--however, our proposed protocol is based on Ethereum. For Ethereum, the average time for one block creation is 10-20 s [23]. Time is an essential factor when distributing a newer version of firmware to the IoT devices. Moreover, developers can utilize smart contracts in Ethereum to build a decentralized application. The manufacturer will store each firmware update's metadata in the smart contract. When devices want to download the new firmware, they can verify it through the smart contracts. Furthermore, Ethereum provides a lightweight node \begin{table}
\begin{tabular}{c c c} \hline \hline
**Parameters** & **Direct Firmware Update** & **Peer-to-Peer Firmware Update** \\ \hline Code size in gateway (KB) & 8.86 & 7.85 \\ Total \# of Hash & 2 & 3 \\ Total \# of Digital Signature & 2 & 3 \\ Total \# of Signature Verification & 2 & 3 \\ Total data transmission size (bytes) & 455 & 652 \\ \hline \hline \end{tabular}
\end{table} 
Table 6: Comparison of computational complexity and data transmission size between direct firmware update and peer-to-peer firmware update. for constrained and low capacity devices that cannot afford to store multiple dozen Gigabytes of blockchain data [24; 25]. In [26], the author also proposed a firmware update protocol based on blockchain, and it was designed based on Ethereum. The components in this protocol send the messages without any integrity protection.