## 3 Results and Discussion
Among such examples were protocols which are suitable or partially suitable for IoT [12; 13; 14; 15; 16]: Proof of Stake (PoS), Delegated Proof of Stake (DPoS), Proof of Importance (PoI), Proof of Supply Chain Share (PoSCS), Credit-Based Proof of Work (CBPoW), RapidChain, OmniLedger, Raft, Practical Byzantine Fault Tolerance (PBFT), dPBFT, Proof of Elapsed Work and Luck (PoEWAL), Microchain, Proof of Elapsed Time (PoET), Tangle, Ripple Protocol Consensus Algorithm (RPCA), Steller Consensus Protocol (SCP), CBCIoT [29], Proof of Block & Trade (PoBT) [30], Proof of Accumulated Trust (PoAT) [31], hierarchical and location-aware consensus protocol LH-Raft [32], Proof of Chance (PoCh) [33], Honesty-based Distributed Proof of Authority (HDPoA) [34], Proof of Reputation X [35], and Proof of X-repute [36]. Stage 3. Formation of a set of evaluation criteria. The next critical task was to develop evaluation criteria against which alternatives could be tested. Typically, MCDM divides criteria into two main categories: benefit criteria, which should be maximized, i.e., higher values are preferred, and cost criteria, which should be minimized, i.e., lower values are preferred. Again, the academic literature and research papers could be used. There were already studies in the literature aimed at finding criteria for evaluating consensus protocols. In this paper, the results of works [12; 13; 19; 21] were studied and used in the process of finding criteria. The selected criteria were common to any blockchain-based systems, including in the case of IoT networks. The criteria were among the most well-known solutions for consensus protocols. And their relevance was confirmed by various sources, including various white papers and specialized online resources on distributed ledger technologies. The choice involved the enumeration of the following criteria that could be divided into five groups: throughput, decentralization, incentives, sustainability, and security [21]. For each group, the corresponding criteria (metrics) were taken into account [13]: throughput (C_1--transactions per second (TPS), C_2--transaction latency (s), C_3--finalization (Probabilistic/Deterministic)), Decentralization (C_4--number of consensus nodes, C_5--number of network nodes), Incentivization (C_6--transaction fees (USD/tx), C_7--Reward (USD/day)), Sustainability (C_8--power consumption (Low/Medium/High), C_9--hardware dependency (No/Yes), C_10--storage), Security (C_11--fault-tolerance, C_12--51% attack (Vulnerable/Safe), C_13--double spending (Vulnerable/Difficult/Safe)). Since some multi-criteria decision-making methods can only work with quantitative criteria, the qualitative criteria were converted into quantitative measures. For this purpose, appropriate conversion scales were used. For example, in the case of the criterion \"power consumption\", its qualitative values Low, Medium, and High took quantitative values of 1, 5, and 9, respectively, on the Saaty scale (see Table 2). Stage 4. Selection of optimal methods of multi-criteria decision analysis. Currently, there are many different methods of multi-criteria analysis. In addition, new methods appear, and the existing ones continue to develop. In such conditions, it seems very important to correctly determine the most appropriate method of multi-criteria decision making for the problem under consideration. It was assumed that such a correct choice would provide greater confidence in objectivity and accuracy in assessing and making decisions. This was also important, given that the problem under consideration was characterized by a large number of alternatives (many different consensus protocols) and a large number of criteria (e.g., energy consumption, throughput, resistance to attacks, transaction processing delay, etc.). Currently, there are open software tools designed to automate the process of selecting the most appropriate methods of multi-criteria decision making. Such decision support systems help analysts and researchers in various areas of multi-criteria analysis application.