## 7 Conclusions  
We proposed two protocols to distribute a firmware update: direct firmware update and peer-to-peer firmware update distribution. Both protocols check the firmware update to a smart contract. However, the direct firmware update protocol downloads the update directly from the manufacturer's server. The peer-to-peer firmware update protocol happens between devices with the same specifications and from the same manufacturer. Therefore, IoT devices can share the available newest updates through IoT gateways. As the gateways provide update distribution on behalf of the manufacturer, single-point-of-failure is prevented, and firmware update availability is increased. For the blockchain network, we use Ethereum because the creation speed is faster than Bitcoin, which is around 10-20 s on average to create one block. Besides, Ethereum can utilize smart contracts to build a decentralized application because smart contracts will execute when the conditions are met. In the case of firmware update's distribution, each version of firmware released by the device's manufacturer will be recorded in the smart contract. When devices want to download the new firmware, they can verify it through the smart contract. Furthermore, Ethereum provides a lightweight node for constrained and low capacity devices that cannot afford to store multiple dozen Gigabytes of blockchain data.  
We implemented our proposed protocols in Raspberry Pi 3 Model B and the VMWare virtual environment. There are three nodes in the blockchain network: one manufacturer and two gateways. We evaluated the proposed system's performance by measuring the average latency, average throughput, and duration of both protocols to finish two main steps, Check New Version step and Download Update step. With request/second values, we measured the total duration that it takes to handle 10,000 requests. The direct firmware update needs 11 min, and the peer-to-peer firmware update needs 9.6 min. These evaluations show that the peer-to-peer firmware update protocol has better time performance than the direct firmware update protocol. We also evaluated the computational complexity and data transmission size for the direct firmware update and the peer-to-peer firmware update. Compared to the direct firmware update, the peer-to-peer firmware update requires the extra computation of one hashing, one digital signature, and one signature verification. Additionally, it requires 197 bytes of extra data transmission. One gateway will need an extra 7.85 KB of memory space to implement a peer-to-peer update. With this cost, the peer-to-peer firmware update can increase overall firmware update availability and disseminate the manufacturer's server's traffic burden to the gateways.  
Conceptualization, E.N.W. and Y.E.O.; data curation, E.N.W. and Y.E.O.; formal analysis, E.N.W. and Y.E.O.; funding acquisition, S.-G.L. and J.-H.L.; investigation, E.N.W. and Y.E.O.; methodology, E.N.W. and Y.E.O.; project administration, S.-G.L. and J.-H.L.; resources, S.-G.L. and [PERSON]-H.L.; software, E.N.W. and Y.E.O.; supervision, [PERSON]-G.L. and [PERSON]-H.L.; validation, E.N.W. and Y.E.O.; visualization, E.N.W.; Writing--original draft, E.N.W.; writing--review and editing, E.N.W., Y.E.O., S.-G.L., and J.-H.L. All authors have read and agreed to the published version of the manuscript.  
This work was supported by Basic Science Research Program through the National Research Foundation of Korea (NRF) funded by the Ministry of Education (grant number: 2018R1D1A1B07047601) and also supported by Dongseo University Research Fund of 2020.  
We would like to thank the anonymous reviewers for their comments and suggestions that helped us improve the paper.  
The authors declare no conflict of interest.