The Raft algorithm is designed as an easy alternative to Paxos. The basic idea behind Raft is that nodes collectively select a leader and rest of the nodes become followers. The leader is responsible for state transition log replication across the followers. Record entries flow in only one direction from the leader to the followers. Unlike Paxos, here each node can be at any of the three states namely leader, candidate and follower at any particular time. The Raft algorithm runs in rounds which are known as term. Each term starts with an election where one or more candidates strive to become leader. Initially, we have a set of follower nodes, who look out for a leader. If within a certain time interval they do not find one, then the leader election process starts. In this election phase, some of the followers volunteer to become a leader and request votes from all other nodes. Then these candidate nodes send request messages to other followers of the system for a vote. When a node receives the request, it compares the term and index in the received message with corresponding current known values. Like Paxos, the followers vote for one of the candidates and based on the majority of votes, a leader is selected. Then in the next part, the elected leader will propose values which the followers will choose so that the system can reach consensus. The leader sends out heartbeats (signals) to all followers at regular intervals in order to maintain its authority. Compared with Paxos and PBFT, this algorithm has high efficiency and clarity. Hence it has been extensively employed in distributed systems. The Raft algorithm achieves the same safety performance as Paxos and is better suited in real- life implementation and comprehension. As mentioned, the Raft algorithm cannot support byzantine nodes and can stand up to failure of 50% of nodes. As in the case of permissioned blockchain, nodes are verified members. Hence, it is more essential to resolve crash faults rather than Byzantine faults for private blockchain.
Byzantine Fault Tolerance and Its Variant
In relation to distributed systems, Byzantine Fault Tolerance is the capability of a distributed network to execute as required and correctly reach a consensus despite malicious nodes. It is derived from the Byzantine General Problem, where the general sends an attack message to one group of lieutenants whereas he sends a retreat message to another group of lieutenants. Hence it becomes difficult for the system to find out what action to take. Byzantine fault-tolerant systems are typically built using replication. For this, the state machine approach is used which helps to implement fault-tolerant services. The variant of BFT that has been designed for synchronous distributed systems is called the “Lamport-Shostak-Pease” algorithm. This ensures consensus in presence of a number of faulty nodes, provided we have (2f + 1) number of lieutenants apart from the commander. But our real systems behave in an asynchronous way as there is no guarantee that a message will be received within a certain time interval. For this reason, a variant of BFT known as Practical Byzantine Fault Tolerance (PBFT), has been developed for real-life asynchronous systems. As in the case of a pure asynchronous system, achieving consensus is impossible even in the presence of a single faulty node. So to ensure liveness property, instead of pure asynchronous system, a weak asynchronous system has been considered. Coming to the algorithm, the byzantine model consists of three types of nodes: the clients, a commander and the lieutenants. The entire algorithm runs in three phases: pre-prepare, prepare and commit phase. In the pre-prepare phase the commander assigns a sequence number to the request submitted by a client and multicasts it to the network. Among other data, the request message also contains the digital signature and message digest for verification. The lieutenants of the network confirm the block by verifying the digital signature and message digest. Once the validating lieutenants accept the pre-prepare message, they enter the prepare phase by multicasting the message to the rest of the network. Once again both the commander and lieutenants verify the prepare messages before accepting them. The messages commit, when (2f) prepare message from different backups match with the corresponding pre-prepare messages. Hence, the total (2f + 1) votes one from primary from the non-faulty replica help the system to reach to a consensus. With the evolution of ICT, the blockchain technology has attracted interest from various directions. The consensus algorithm is the main technology of blockchain. In the case of permissionless systems, it is easy to achieve robust consensus among large number of untrusted nodes using complex computations though transaction, finally remains non-deterministic. On the contrary, permissioned blockchain provides high throughput in less time while sacrificing a degree of decentralization.
Since the concept of IoT arose, much development has taken place in a different application. The architecture of IoT is basically three layer perception, network, and application layer to make real use of the IoT technology for efficiency and reliability of the system. Security and privacy issues are the challenges  to implement a different application using the IoT concept. Some of the challenges are access control, authentication, centralized or distributed network, and the identity of the things. Visualization is one the important aspects  of the IoT application. The end-user monitors the environment using either mobile phone or smart tablets, although IoT applications use both centralized and decentralized architecture. The decentralized architecture has an advantage over centralized architecture. The IoT application system has different stages. Processing and doing computation may depend on cloud computing or the recent development of fog computing. The storage purpose IoT application can store at the edge device or at the cloud server depending upon the storage space availability. In IoT / physical layer all the required sensors are deployed in the application area. The sensors are connected to the next layer using WiFi or through a wire. IoT application demands faster processing and quick response for better utilization of the system. Most of the application collecting data from sensors need to process in the edge of the network for faster processing and temporary storage for quick analysis of the data. The decision can be taken by analyzing the data either in a collaborative way or a distributed way by mutual agreement. All these activities can be done in the Fog Layer / Processing layer. The Cloud Layer provides different types of sendees such as infrastructure, platform, and software as a service. In an IoT application as different sensors collect information from environment continuous way, it is not possible to provide large memory space. Also, IoT devices are low in memory capacity. Similarly, the storage capacity of a fog device is also limited, so the final storage must be provided by cloud computing. For establishing security and privacy in communication and user data, authentication of IoT devices is highly essential. When devices perform any operation in an application, the devices need to be identified using their unique ID. Using the unique ID, devices can connect to the next layer also performing different computation in a collective way. The authentication of the devices means the communication can be done securely; all the nodes are identified using their ID. The decentralized scheme for IoT device authentication can be considered one of the best approaches for secure communication. The process of device authentication is done in blockchain-based technology. Implementation takes place using the Ethereum platform and Web3 client is used to integrate block chain smart contract with Frontend.
IoT implementation requires many security and privacy issues to be addressed. Here a decentralized approach is proposed for authentication to increase IoT network connectivity and build trust among all the devices. In an IoT system not only information needs to communicate securely it also needs to identify which devices are authenticated devices. Each of these devices identify using their public key which is a unique key generated from the system. Security and integrity of the IoT system are ensured without using a centralized system. The proposed authentication protocol
 is secured against some of the attacks described below:
- 1) MITM (Man-In-The-Middle): In the proposed scheme, MITM attack is not possible as whatever message is sent from one node to another node, it is sent using hash techniques and public-private key concept so that only the authorized user will get the message. Any modification done on the message will be ignored by the receiver side. The message communication also uses a digital signature as one of the concepts of blockchain technology.
- 2) Impersonation Attack: Whatever transaction is done in the blockchain network, all are verified and mined by the network using mining process and digital signature concept. Each user has their own identity added to the system using the authentication process.
- 3) Replay Attack: In a blockchain environment, no node can capture more than half of the network power. Each transaction sent or received is recorded in a digital ledger after verification and mining. So no transaction can transmit multiple times in the network.
- 4) Denial-of-Service (DoS) Attack: As each message is broadcast in the network and it goes through a verification process to check valid or invalid transaction, there is no chance that a DoS attack is possible.
Due to all the above security issues, a decentralized web authentication system using blockchain is proposed which is not a password-based authentication and authentication is done using AuthKey which is a 160-bit hash and is secured enough to prevent all the above attacks.
Decentralized authentication is an attempt to make a decentralized site login and authentication protocol. It is analogous to the “Log In with Facebook” button that we have probably become accustomed to. It is a smart contract that will store user IDs and their associated wallet addresses. The user ID is simply a UTF-8 string with size ranging between 2 and 32 bytes. The user himself creates it on inception of the wallet and will later use it to enter any site that supports decentralized authentication. It would also be possible to add a restriction on the possible characters included in the string. One could restrict it to Latin characters and Arabic numerals in order to limit the possibility of creating visually similar IDs. When creating an account with decentralized authentication, a pair of keys is created. We will create an authorization key and a key to restore access. When created, both addresses are the same as the address of the wallet which first made the transaction. Users who care about their security should create a separate Master Key and store it in a place that is inaccessible from online. Recovery seeds are a set of 12 mnemonic words that when used can recreate the key pairs for our wallet. If we are going to be using a wallet for authentication then it is also recommended we use a separate address from the one that keeps all of our ether. Doing this allows us to avoid any hackers from tracing our Authkey to the wallet with our assets. Decentralized Web Authentication System using Ethereum-based blockchain protects our assets.This is something that could be updated in later iterations of the smart contract. If we want to further protect ourselves, then we consider VPN services.
Using Decentralized Authentication
There is a dedicated web page intended for user interaction with the smart contract. We can create an account there, change the keys or delete it. To work with it, the user will need to install the well-known browser plugin called MetaMask. Of course, if we are already an experienced user of the Ethereum network then we will already have used MetaMask and will probably have an idea of how it interacts with the network. The overall user authentication process using DecAuth looks as follows: The site (backend) contacts the smart contract and receives the user’s Ethereum address.
Then the site (backend) generates and records a message, and asks the user to sign this message with the help of the authKey address. And the user being on the site (frontend) signs the message using the MetaMask plugin and sends it to the backend. Finally the site (backend) verifies the signature, and if everything is correct, it activates the user’s session. It is important that authentication checks should take place in a user-uncontrolled environment. So, in other words, all of the checks should be completed on a server instead of on a user’s browser.
The decentralized system is not subject to censorship by the large entities, such as Google or Facebook. If it is necessary to censor something, each website should implement it independently. Yet this would only affect the user’s interaction with that site and not any others. The Ethereum network currently has quite slow transaction speeds when creating an account; the user may have to wait a few minutes, but sites can get the data and verify users quite quickly. This solution scales well, because there are a lot of data nodes, and anyone can add another one at any time. The complexity of implementing such a solution for site owners is no higher than the complexity of implementing OAuth 2.0. Using blockchain-based authentication, all devices are connected in a peer-to-peer way. Each of these devices identifies using their public key which is a unique key generated from the system. Security and integrity of the IoT system is ensured without using a centralized system. Due to different kinds of security issues, a decentralized web authentication system using blockchain is proposed which is not a password-based authentication and authentication is done using AuthKey which is a 160-bit hash and is secure enough to prevent all the above attacks and the blockchaining method makes it secure against all kinds of attack.